Я такие квесты люблю, поэтому решил поделиться. А в этот раз действительно оказалось удивительное сочетание факторов, при котором проблема возникает, т.е. по логике, сильно сужает частоту, компенсируется ее последствиями - драматическими и дорогими. Редко, но очень метко.      Итак, издалека: обратили внимание на график загрузки интерфейсов, какие-то некрасивые пилы в графане/заббиксе, в произвольное, но чаще рабочее время, по несколько часов длящиеся. И эти же пики, при этом, не заметны в большинстве разрезов в эластике, где у нас уже L7 логи с ингресс-контроллеров. Т.е. появилась мысль про L3.      К позору, sflow на маршрутизаторе поднять мы не смогли, в нашей версии прошивки его нет, а чтобы скачать новую, нужно продлевать поддержку. Поэтому решили собрать на стареньких ASA'х, стоящих перед BGP пирами, но там оказался netflow v5, в котором даже не очевидно направление трафика. Тем не менее, увидеть периодические скачки количества flow от/к нашим серверам раздачи удалось, совпадающие по времени с изначальными пилами на графике.      Уже в эластике по ip таких клиентов, было замечено, что их объединяет: использование http 1.1 вместо 2.0, в основном среди опознаваемых наших клиентов были старое приложение AndroidTV (какой-то древний exoplayer) и СмартТВ телевизоры Hisense на платформе Vidaa. Очень подозрительным было количество запросов за одними и теми же файлами, но мы не сразу подумали начать копать в сторону конкретных файлов.      Нужно было посмотреть на эти запросы вживую, самый простой вариант, запустить tcpdump -AAA | grep непосредственно внутри пода с nginx, отвечающих за раздачу видео. Обычно большие файлы в интернет, особенно видео, если оно не пакетизировано в форматы hls или dash, скачиваются по-кусочкам как ответ на специальные byte range запросы, с кодом 206. И плеер, или другой клиент, постепенно запрашивает все новые и новые кусочки.      Но запросы от этих "проблемных" ребят содержали заголовок Range bytes=оффсет-  , т.е. от какого-то смещения и до конца, и этих запросов визуально было чересчур много.      Начали копать интернет на предмет подобных багов в конкретных версиях плееров Vidaa и ExoPlayer. Единственными упоминаниями подобного поведения были ситуации, когда в mp4 контейнере moov атом находился не в начале файла.      В какой-то момент я попробовал просто открыть один из файлов, запрашиваемый проблемным клиентом у себя в браузере. Он игрался, ничего страшного не происходило. Я перемотал на середину, и тут…загрузка сети на моем клиенте выросла до 400 мегабит и так и осталась, файл продолжал играться, а в консоли браузера в нетворке были видны тысячи запросов вместо единиц.     В общем, long story short. Из всех наших 350.000 исходных mp4 файлов порядка 3000 (1%) были в процессе своей работы подвергнуты операции cut (вырезать/обрезать)  перед публикацией. Старый скрипт в недрах системы, который это делал, последний раз редактировался в 2015 году. По сути в нем 2 строчки, первая это вызов MP4Box -splitx, вторая, закомментированный(!) вызов древней утилиты qtfaststart. Далее, большинство файлов мы давно оттранскодировали в мультибитрейт, за исключением совсем старых или непопулярных. Из 3000 осталось 1257. Затем, помним условие про специфичные клиенты, и последнее - что проблема проявляется в случае перемотки.      И да, если верить AtomicParsley -T и MP4Box -info, то в этих "битых" файлах moov atom находился на своем месте. Но тем не менее с ним что-то было не в порядке, потому что ffmpeg -movflags +faststart чинило проблему с файлом, как и mp4box -inter 500.      В конечном итоге мы наткнулись на https://github.com/gpac/gpac/issues/81 откуда, по всей видимости, и растут ноги с 2015 года.      Судя по нашим серверам, за сутки из 15 млн запросов примерно 3.5 млн - могли бы быть в 1000 раз меньше. Сейчас смотрю логи CDN, чтобы прикинуть, сколько мы денег переплатили за 10 лет. Если больше не напишу здесь, значит много.