В 2018 лайв был просто HLS, у него всегда есть задержка в N чанков в зависимости от настройки плеера, обычно это отставание секунд в 10 — это нормально. Для событий в realtime сейчас всё чаще транслируют просто в WebRTC.
На самом деле история про футбол красивая, но +- то же самое будет, если смотреть трансляцию по разным каналам, т. к. у них разные политики в задержке (вдруг что-то в эфире произойдет, поэтому там есть некоторый delay).
Про «вы в эту сторону не копали, потому что в статье это не упоминается совершенно» вывод достаточно странный, это же просто speech-to-text с конференции по Go с некоторой редактурой от Онтико :)
P. S.: если хотите поговорить за сетевой стек и улучшения раздачи — мы всегда за, можем работать как фул-тайм, так и парт-тайм ;)
Проблема с клиентами, у которых максимальная версия TLS 1.1, решилась сама собой после того, как Let’s Encrypt «сломал интернет». Людям пришлось поменять устройства или перестать пользоваться интернетом. У нас уже года два или три, в том числе на Nginx, минимальная версия 1.2.
Всё так, но, как вы верно заметили, мы не general CDN и решаем конкретные задачи.
Если мы говорим о live-трансляциях, для которых изначально всё это делалось, то обычно со стороны пользователя это выглядит так:
Открыл TLS-соединение.
Гоняет по нему данные туда-сюда, пока трансляция не закончится.
От клиента обычный GET-запрос, в ответ отдаются данные или с диска через sendfile (обычно от нескольких сотен kb до 5 Mb), или write в какое-то количество kb для манифеста.
При этом все запросы от клиента приходят последовательно.
В принципе, для VOD оно выглядит +- также, за исключением только одного, что там только sendfile (не считая заголовков, разумеется) и соединения живут меньше, т. к. много обучающего контента, а его любят ставить на паузу.
Соответственно, всё это в HTTP/1.1, что сильно упрощает нам жизнь.
С general CDN всё не так однозначно: там и HTTP/1.1 уже не подходит, и важно время ответа. Нам же нужно просто успеть протолкнуть весь контент за +- время чанка пополам. Фактически при норме ответа в 100–200ms мы можем деградировать до 1-й, а в ряде случаев 2-х секунд без ухудшений для пользователя, но при этом обслужив больше подключений на одной машине.
P. S. У Tempesta есть кастомные ядра и возможность допилить их по желанию, в том числе TLS, насколько я понял, у вас есть свой опыт и этой необходимости нет.
Привет, если к «по понятным причинам» отнести то, что шифрование в ядре медленнее, чем в том же OpenSSL, то тут на практике мы не увидели никаких отклонений, кроме случаев, когда мы при большом трафике уже втыкали и время ответа росло, а при переходе на kTLS планка того, что мы можем отдавать с того же железа, выросла.
Для хендшейка с EC у нас достаточно приемлемый результат, и он близок к тому, что мы отдавали с Hith + openssl. У нас обычно соединения живут очень долго, поэтому при нормальной работе время хендшейка тоже не так критично.
Что же касается TTFB, то он нам не так важен, как общее время отдачи контента, так как мы стримим видео и нам важно отдавать чанки быстрее, чем их длина по времени. Часть наших клиентов используют Content Steering, и если бы мы лагали, то трафик бы ушел в другой CDN, поэтому: «Нам важно, что в итоге клиент получает».
P. S. Если скорость kTLS — это прямо блокер для вас, то можно пообщаться с @krizhanovsky и ребятами из Tempesta, они занимаются TLS в ядре (в том числе хендшейками).
P. S. 2: всё же на TTFB связность сети влияет больше, чем TLS/kTLS.
Привет. Всё верно, любое видео, доступное в интернете, можно так или иначе получить.
В подавляющем большинстве видео, которое размещено у нас, является публичным, и защита контента не применяется совсем, его можно скачать тем же ffmpeg без особых проблем, просто указав как источник адрес манифеста.
Часть наших пользователей использует DRM (Widevine, Fairplay), что сильно осложняет подобные действия, часть к шифрованию добавляет еще и авторизацию, когда при запросе ключа мы общаемся с бэкендом владельца видео, и он решает, давать доступ этому пользователю или нет. Однако даже в этом случае можно записать видео с экрана.
Но тут есть важное НО: если видео публичное, то с ним можно делать что угодно; если же оно под защитой, то правообладатель может работать уже в рамках УК, и взлом защиты — это отягчающее (для части лицензионного контента DRM по контракту с правообладателем вообще обязателен). На данный момент в России это не частая практика, и реальных запросов на маркировку контента под каждого юзера у нас не было. Как будет, мы будем маркировать контент и с большой достоверностью определять, кто его «слил».
Нет, это новость о том, что они: испытали, поставили на вооружение; а теперь всем кто будет это делать они будут грозить и при угрозах упоминать: "у нас мораторий"
Это не совсем так. В Go reflect в таком виде (я имею ввиду настолько полную и достатоно неплохую реализацию) сделан по причине того, что в Go очень слабая система типов если ее сравнивать с C++/Rust etc, но при этом хочется давать туже гибкость в плане интерфейсов реализации. Можно посмотреть на `database/sql` который может принимать на вход в методах любые аргументы. И вот тут в Go без reflection никак, даже дженерики в которые сейчас будут не в состоянии решить ряд проблем. Поэтому в Go так и распространена кодогенерация, которая, от части, и решает проблему с типами которые компилятор не может вывести и для этого и используется reflection и выноситься многое на уровень с компиляции в рантайм. И easyjson не исключение, он не reflection выпиливает, а по типу генерит реализацию маршалинга и анмаршалинга под него в настоящий код, который проверяется при компиляции. Ровно как и говорить о том, что reflect и HL вещи несовместимые некорректно, да, там достаточно большой оверхед, но тоже смотря с чем сравнивать и это часть языка и хочешь или нет, но если нужно, то других вариантов бывает что и нет
Выставлять Go наружу с его вебсервером такое себе дело. Nginx сверху ставят для терминирования TLS, limit rate, балансировки трафика etc. Те ровно то, что в нем хорошо работает. Traefik, написаный на Go, как бы ни смешно звучало, не сможет заменить Nginx на проектах с реальным трафиком. Если сравнивать именно перфоманс, то HAProxy опережает Nginx, но, в силу привычки и менее удобной конфигурации, часто на это закрывают глаза.
Что касаемо Envoy, то он сложен в конфигурировании (опять же сравнивая с Nginx), и в нем куча отдельных компонентов, см тот же https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/global_rate_limiting.html. Те мало его засетапить, нужно и сбоку еще какие-то сервисы городить да еще и с REDIS. Те стоимость владения, усложнение эксплуатации и неочевидные точки отказа. Хотя кого это пугает, все с тормозов давно слетели и без k8s даже локально ничего поднять не могут:)
Через nvidia-smi сборка метрик и в правду очень не бесплатна, особенно на Теслах. Для этих целей лучше использовать NVML (биндинг на Go) и писать свой экспортер делая 1 раз Initialize на старте. У автора биндинга есть готовый экспортер для Prometheus (можно в коде подглядеть как и что), но там, как минимум, не было метрик по NVENC/NVDEC.
Не раскрыта тема: "Почему?". Что такое происходило (да и происходит) в systemd, что он есть столько CPU. 10% - это тоже сильно много, не говоря уже о полке в 100%. Надо было тыкать в него strace'ом и смотреть. Хотя, если он и сейчас ест больше 1%, то смело можно это делать.
Почему вообще в данном сетапе такие проблемы, я про связку kubernetes и systemd?
Привет, на самом деле, для сырых данных словарь не используется, данные хранятся как есть. Словарь необходимо использовать только если в агрегированных данных хранятся хэши, а не оригинальные значения (пример). Словарь, по большому счету, представляет некоторый атавизм, на данный момент ClickHouse предоставляет возможность использования LowCardinality(String) и сам построит словарь. Так что его точно пора делать опционально отключаемым.
Собственно основным плюсом решения (не важно PHP или Go) является то, что система предоставляет event-stream в виде сырых данных, а с ними можно строить все что угодно, при этом производительность ClickHouse позволяет комфортно работать с сырыми данными, а при желании или необходимости строить над ними материализованны представляения (репорты, если сравнивать со стандартным Pinba engine).
Если говорить о репортах то, в отличие от Pinba engine, нет необходимости строить множество различных репортов, для ClickHouse может быть достаточно одной таблицы (пример репортов, пример репортов с тегами).
PS: также стоит обратить внимание на возможность использования различных алгоритмов сжатия для колонок в ClickHouse (см. CODEC) и сортировку ;)
Это появилось в 9,4
https://www.postgresql.org/docs/9.4/static/release-9-4.html
Allow SELECT to have an empty target list (Tom Lane)
This was added so that views that select from a table with zero columns can be dumped and restored correctly.
Это из-за того, что до версии 9,4 нельзя было делать SELECT без указания колонок; например для EXISTS приходилось ставить null (SELECT * FROM T WHERE f EXISTS (SELECT null FROM ...), сейчас это не обязательно
чем пытаться понять из какого пакета прилетела функциональность writeln или reduce (соответственно, чем больше проект и больше пактов, тем сложнее, опять же для меня, все это поддерживать), так что только на основании этого я бы не стал утверждать, что он (Go) категорично не подходит для обработки данных
ЗЫ: и у D и у Go есть свои плюсы, но Go, в моем случае, предпочтительнее в силу своей очевидности
В 2018 лайв был просто HLS, у него всегда есть задержка в N чанков в зависимости от настройки плеера, обычно это отставание секунд в 10 — это нормально. Для событий в realtime сейчас всё чаще транслируют просто в WebRTC.
На самом деле история про футбол красивая, но +- то же самое будет, если смотреть трансляцию по разным каналам, т. к. у них разные политики в задержке (вдруг что-то в эфире произойдет, поэтому там есть некоторый delay).
Про «вы в эту сторону не копали, потому что в статье это не упоминается совершенно» вывод достаточно странный, это же просто speech-to-text с конференции по Go с некоторой редактурой от Онтико :)
P. S.: если хотите поговорить за сетевой стек и улучшения раздачи — мы всегда за, можем работать как фул-тайм, так и парт-тайм ;)
Проблема с клиентами, у которых максимальная версия TLS 1.1, решилась сама собой после того, как Let’s Encrypt «сломал интернет». Людям пришлось поменять устройства или перестать пользоваться интернетом. У нас уже года два или три, в том числе на Nginx, минимальная версия 1.2.
Всё так, но, как вы верно заметили, мы не general CDN и решаем конкретные задачи.
Если мы говорим о live-трансляциях, для которых изначально всё это делалось, то обычно со стороны пользователя это выглядит так:
Открыл TLS-соединение.
Гоняет по нему данные туда-сюда, пока трансляция не закончится.
От клиента обычный GET-запрос, в ответ отдаются данные или с диска через sendfile (обычно от нескольких сотен kb до 5 Mb), или write в какое-то количество kb для манифеста.
При этом все запросы от клиента приходят последовательно.
В принципе, для VOD оно выглядит +- также, за исключением только одного, что там только sendfile (не считая заголовков, разумеется) и соединения живут меньше, т. к. много обучающего контента, а его любят ставить на паузу.
Соответственно, всё это в HTTP/1.1, что сильно упрощает нам жизнь.
С general CDN всё не так однозначно: там и HTTP/1.1 уже не подходит, и важно время ответа. Нам же нужно просто успеть протолкнуть весь контент за +- время чанка пополам. Фактически при норме ответа в 100–200ms мы можем деградировать до 1-й, а в ряде случаев 2-х секунд без ухудшений для пользователя, но при этом обслужив больше подключений на одной машине.
P. S. У Tempesta есть кастомные ядра и возможность допилить их по желанию, в том числе TLS, насколько я понял, у вас есть свой опыт и этой необходимости нет.
Привет, если к «по понятным причинам» отнести то, что шифрование в ядре медленнее, чем в том же OpenSSL, то тут на практике мы не увидели никаких отклонений, кроме случаев, когда мы при большом трафике уже втыкали и время ответа росло, а при переходе на kTLS планка того, что мы можем отдавать с того же железа, выросла.
Для хендшейка с EC у нас достаточно приемлемый результат, и он близок к тому, что мы отдавали с Hith + openssl. У нас обычно соединения живут очень долго, поэтому при нормальной работе время хендшейка тоже не так критично.
Что же касается TTFB, то он нам не так важен, как общее время отдачи контента, так как мы стримим видео и нам важно отдавать чанки быстрее, чем их длина по времени. Часть наших клиентов используют Content Steering, и если бы мы лагали, то трафик бы ушел в другой CDN, поэтому: «Нам важно, что в итоге клиент получает».
P. S. Если скорость kTLS — это прямо блокер для вас, то можно пообщаться с @krizhanovsky и ребятами из Tempesta, они занимаются TLS в ядре (в том числе хендшейками).
P. S. 2: всё же на TTFB связность сети влияет больше, чем TLS/kTLS.
Привет. Всё верно, любое видео, доступное в интернете, можно так или иначе получить.
В подавляющем большинстве видео, которое размещено у нас, является публичным, и защита контента не применяется совсем, его можно скачать тем же ffmpeg без особых проблем, просто указав как источник адрес манифеста.
Часть наших пользователей использует DRM (Widevine, Fairplay), что сильно осложняет подобные действия, часть к шифрованию добавляет еще и авторизацию, когда при запросе ключа мы общаемся с бэкендом владельца видео, и он решает, давать доступ этому пользователю или нет. Однако даже в этом случае можно записать видео с экрана.
Но тут есть важное НО: если видео публичное, то с ним можно делать что угодно; если же оно под защитой, то правообладатель может работать уже в рамках УК, и взлом защиты — это отягчающее (для части лицензионного контента DRM по контракту с правообладателем вообще обязателен). На данный момент в России это не частая практика, и реальных запросов на маркировку контента под каждого юзера у нас не было. Как будет, мы будем маркировать контент и с большой достоверностью определять, кто его «слил».
Только к Bona Fide привыкли, теперь еще женские футболки которые будут создавать отверстия на спине и груди на мокром теле.
Нет, это новость о том, что они: испытали, поставили на вооружение; а теперь всем кто будет это делать они будут грозить и при угрозах упоминать: "у нас мораторий"
Это не совсем так. В Go reflect в таком виде (я имею ввиду настолько полную и достатоно неплохую реализацию) сделан по причине того, что в Go очень слабая система типов если ее сравнивать с C++/Rust etc, но при этом хочется давать туже гибкость в плане интерфейсов реализации. Можно посмотреть на `database/sql` который может принимать на вход в методах любые аргументы. И вот тут в Go без reflection никак, даже дженерики в которые сейчас будут не в состоянии решить ряд проблем. Поэтому в Go так и распространена кодогенерация, которая, от части, и решает проблему с типами которые компилятор не может вывести и для этого и используется reflection и выноситься многое на уровень с компиляции в рантайм. И easyjson не исключение, он не reflection выпиливает, а по типу генерит реализацию маршалинга и анмаршалинга под него в настоящий код, который проверяется при компиляции. Ровно как и говорить о том, что reflect и HL вещи несовместимые некорректно, да, там достаточно большой оверхед, но тоже смотря с чем сравнивать и это часть языка и хочешь или нет, но если нужно, то других вариантов бывает что и нет
Печально, что при уходе Игоря вспоминают сейчас МВД и Lynwood, а не реально много того, что он сделал. Internet Powered by Nginx
Выставлять Go наружу с его вебсервером такое себе дело. Nginx сверху ставят для терминирования TLS, limit rate, балансировки трафика etc. Те ровно то, что в нем хорошо работает. Traefik, написаный на Go, как бы ни смешно звучало, не сможет заменить Nginx на проектах с реальным трафиком. Если сравнивать именно перфоманс, то HAProxy опережает Nginx, но, в силу привычки и менее удобной конфигурации, часто на это закрывают глаза.
Что касаемо Envoy, то он сложен в конфигурировании (опять же сравнивая с Nginx), и в нем куча отдельных компонентов, см тот же https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/global_rate_limiting.html. Те мало его засетапить, нужно и сбоку еще какие-то сервисы городить да еще и с REDIS. Те стоимость владения, усложнение эксплуатации и неочевидные точки отказа. Хотя кого это пугает, все с тормозов давно слетели и без k8s даже локально ничего поднять не могут:)
Через nvidia-smi сборка метрик и в правду очень не бесплатна, особенно на Теслах. Для этих целей лучше использовать NVML (биндинг на Go) и писать свой экспортер делая 1 раз Initialize на старте.
У автора биндинга есть готовый экспортер для Prometheus (можно в коде подглядеть как и что), но там, как минимум, не было метрик по NVENC/NVDEC.
Не раскрыта тема: "Почему?". Что такое происходило (да и происходит) в systemd, что он есть столько CPU. 10% - это тоже сильно много, не говоря уже о полке в 100%. Надо было тыкать в него strace'ом и смотреть. Хотя, если он и сейчас ест больше 1%, то смело можно это делать.
Почему вообще в данном сетапе такие проблемы, я про связку kubernetes и systemd?
А на чем вы смотрите 4K HDR если вас беспокоит стоимость канала?
Собственно основным плюсом решения (не важно PHP или Go) является то, что система предоставляет event-stream в виде сырых данных, а с ними можно строить все что угодно, при этом производительность ClickHouse позволяет комфортно работать с сырыми данными, а при желании или необходимости строить над ними материализованны представляения (репорты, если сравнивать со стандартным Pinba engine).
Если говорить о репортах то, в отличие от Pinba engine, нет необходимости строить множество различных репортов, для ClickHouse может быть достаточно одной таблицы (пример репортов, пример репортов с тегами).
PS: также стоит обратить внимание на возможность использования различных алгоритмов сжатия для колонок в ClickHouse (см. CODEC) и сортировку ;)
https://www.postgresql.org/docs/9.4/static/release-9-4.html
чем пытаться понять из какого пакета прилетела функциональность writeln или reduce (соответственно, чем больше проект и больше пактов, тем сложнее, опять же для меня, все это поддерживать), так что только на основании этого я бы не стал утверждать, что он (Go) категорично не подходит для обработки данных
ЗЫ: и у D и у Go есть свои плюсы, но Go, в моем случае, предпочтительнее в силу своей очевидности