Комментарии 18
Если хендшейк настолько дорогой что rsa уже проблема, то что там используется для распределения ключей? Убедитесь что там всегда ECDH или X25519
всё это конечно очень хорошо,особенно учитывая что вы стартап. однако
1 ваше видео можно скачать по кускам - отдельно видео, отдельно аудио,потом соединить. в интернете есть такие сервисы
2 всё намного проще - obs studio и подобные. можно записать экран в хорошем качестве
вопрос - смысл в вашей защите от скачивания, если "индеец Зоркий Глаз увидел,что стены нет"?
Привет. Всё верно, любое видео, доступное в интернете, можно так или иначе получить.
В подавляющем большинстве видео, которое размещено у нас, является публичным, и защита контента не применяется совсем, его можно скачать тем же ffmpeg без особых проблем, просто указав как источник адрес манифеста.
Часть наших пользователей использует DRM (Widevine, Fairplay), что сильно осложняет подобные действия, часть к шифрованию добавляет еще и авторизацию, когда при запросе ключа мы общаемся с бэкендом владельца видео, и он решает, давать доступ этому пользователю или нет. Однако даже в этом случае можно записать видео с экрана.
Но тут есть важное НО: если видео публичное, то с ним можно делать что угодно; если же оно под защитой, то правообладатель может работать уже в рамках УК, и взлом защиты — это отягчающее (для части лицензионного контента DRM по контракту с правообладателем вообще обязателен). На данный момент в России это не частая практика, и реальных запросов на маркировку контента под каждого юзера у нас не было. Как будет, мы будем маркировать контент и с большой достоверностью определять, кто его «слил».
Ну если честно слабовато.
Вон у китайцев sing-box на районных роутерах стоят , там поток гигантский
Мне вот интересно, а был ли проводен анализ клиентских метрик после перехода на kTLS и на сертификаты с EC? Я имею ввиду в первую очередь Time-to-first-byte? Обычно они знатно проседают по понятным причинам. Или вам не важно, что в итоге клиент получает?
Привет, если к «по понятным причинам» отнести то, что шифрование в ядре медленнее, чем в том же OpenSSL, то тут на практике мы не увидели никаких отклонений, кроме случаев, когда мы при большом трафике уже втыкали и время ответа росло, а при переходе на kTLS планка того, что мы можем отдавать с того же железа, выросла.
Для хендшейка с EC у нас достаточно приемлемый результат, и он близок к тому, что мы отдавали с Hith + openssl. У нас обычно соединения живут очень долго, поэтому при нормальной работе время хендшейка тоже не так критично.
Что же касается TTFB, то он нам не так важен, как общее время отдачи контента, так как мы стримим видео и нам важно отдавать чанки быстрее, чем их длина по времени. Часть наших клиентов используют Content Steering, и если бы мы лагали, то трафик бы ушел в другой CDN, поэтому: «Нам важно, что в итоге клиент получает».
P. S. Если скорость kTLS — это прямо блокер для вас, то можно пообщаться с @krizhanovsky и ребятами из Tempesta, они занимаются TLS в ядре (в том числе хендшейками).
P. S. 2: всё же на TTFB связность сети влияет больше, чем TLS/kTLS.
Говорить, что шифрование в ядре заметно медленнее, чем в OpenSSL - некорректно, особенно если речь идет про свежие ", где Eric Biggers сильно оптимизировал всю линейку AES шифров. Под "понятными причинами" я имел ввиду скорость проверки подписи, сделанной на основе EC-сертификата, на клиенте. Это самый большой известный trade off - сервер выигрывает, клиент страдает, тратя больше времени и батарейки в случае мобильного клиента. И вторая причина увеличения этого самого TTFB в случае kTLS - необходимость выполнять дополнительный syscall с передачей TLS контекста в ядро перед передачей первых данных. Вы автоматически лишаетесь возможности передавать зашифрованные данные в одном TCP сегменте вместе с TLS Finished сообщением. Вероятно, для передачи потокового видео это и правда не сильно критично, однако, в случае general CDN может случиться так, что userspace-only вариант успеет положить все нужные данные в сетевой стек быстрее, чем kTLS успеет настроить все необходимое для начала шифрования данных.
Ну и да, TTFB имеет смысл сравнивать на одном клиенте с одним подключением, конечно же, чтобы понять влияние именно изменений в TLS на эту метрику.
Всё так, но, как вы верно заметили, мы не 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, насколько я понял, у вас есть свой опыт и этой необходимости нет.
Фактически при норме ответа в 100–200ms мы можем деградировать до 1-й, а в ряде случаев 2-х секунд без ухудшений для пользователя
Ох, вот тут я бы поспорил насчет "без ухудшений для пользователя". Трансляция чемпионата мира по футболу в 2018 показала очень "интересную" реакцию пользователей, когда деградирующий до 2х секунд Live приводил к тому, что по всему городу было минимум 2 волны реакции на забитый мяч - первая волна от зрителей классического ТВ, а вторая - как раз от деградирующего Live, когда чанки не отдавались вовремя. С того времени я крайне настороженно отношусь к заявлениям о возможности деградации Live трансляций...
Что действительно помогает лучше раздавать и Live, и VOD - это корректно выполненый pacing на стороне сервера. Судя по тому, что в статье это не упоминается совершенно - вы в эту сторону не копали, и чудный мир честного распределения канала между пользователями откроется вам в (вероятно скором) будущем :)
В 2018 лайв был просто HLS, у него всегда есть задержка в N чанков в зависимости от настройки плеера, обычно это отставание секунд в 10 — это нормально. Для событий в realtime сейчас всё чаще транслируют просто в WebRTC.
На самом деле история про футбол красивая, но +- то же самое будет, если смотреть трансляцию по разным каналам, т. к. у них разные политики в задержке (вдруг что-то в эфире произойдет, поэтому там есть некоторый delay).
Про «вы в эту сторону не копали, потому что в статье это не упоминается совершенно» вывод достаточно странный, это же просто speech-to-text с конференции по Go с некоторой редактурой от Онтико :)
P. S.: если хотите поговорить за сетевой стек и улучшения раздачи — мы всегда за, можем работать как фул-тайм, так и парт-тайм ;)
вывод достаточно странный, это же просто speech-to-text с конференции по Go с некоторой редактурой от Онтико :)
Ok, но я почему уверен, что если бы занимались этим, то обязательно упомянули бы в выступлении...
P. S.: если хотите поговорить за сетевой стек и улучшения раздачи — мы всегда за, можем работать как фул-тайм, так и парт-тайм ;)
Поговорить всегда рад. От предложения работать вынужден, увы, отказаться :)
P. S. Если скорость kTLS — это прямо блокер для вас, то можно пообщаться с @krizhanovsky и ребятами из Tempesta, они занимаются TLS в ядре (в том числе хендшейками).
Ну я не совсем понимаю метрику "заниматься TLS в ядре", но:
~/src/linux-kernel$ git log --oneline --author "Vadim Fedorenko" net/tls/ | wc -l
7
~/src/linux-kernel$ git log --oneline --author "Alexander Krizhanovsky" net/tls/ | wc -l
0
@vadimfedorenko , ты - безусловно, крут 8)
Мы так и не заапстримили свои хендшейки - это очень большая работа. Ты, думаю, видел ссылки на нас на LWN и Netdev от Chuck Lever (Oracle) - мы пробовали запустить с ним портирование в мейнстрим для NFS, но поддержки от Oracle мы не получили и в результате они сделали проброс в user space. Портирование в mainstream мы отложили на неопрелеленное время.
Если же нужна "метрика", то я всегда рад рассказать о нас. Есть https://archive.fosdem.org/2021/schedule/event/webperf_fast_tls/ - 40-80% быстрее WolfSSL и OpenSSL, попутно https://github.com/wolfSSL/wolfssl/issues/3184 . Мы первыми реализовали "Fast constant-time gcd computation and modular inversion" Bernstein and Yang, которая потом была реализована в OpenSSL 3.0.
Для kTLS интересен AES-GCM и CACHA20-POLY1305. Вторую не смотрел, но для GCM-AES патч -это https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6e758fa64438082e48272db19ad74ed4fb98938 - да, реализует Karatsuba, которого очень долго не было в ядре https://netdevconf.info/0x14/session.html?talk-TLS-performance-characterization-on-modern-x86-CPUs , есть AVX-512 и AVX10, VAES, как и в OpenSSL. Реализации детально еще не сравнивал и не бенчмаркал. Патч уже есть в longterm 6.12 и имеет смысл пробовать kTLS на 6.12 с включенным AVX-512/AVX10.
Доклад был в декабре 2024 и коллеги, как и все нормальные/простые люди, у которых нет ресурсов Facebook для поддержки mainline ядер в продакшене, работают на longterm ядрах. Патч появился в июне 2024.
Портирование в mainstream мы отложили на неопрелеленное время.
Конечно видел. И как раз сильно расстроило то, что закончилось это ничем. Хотя patchset был воспринят очень позитивно в community. Я как раз обсуждал его с Jakub Kicinski в то время, и он был настроен очень оптимистично...
Если же нужна "метрика", то я всегда рад рассказать о нас. Есть https://archive.fosdem.org/2021/schedule/event/webperf_fast_tls/ - 40-80% быстрее WolfSSL и OpenSSL, попутно https://github.com/wolfSSL/wolfssl/issues/3184 . Мы первыми реализовали "Fast constant-time gcd computation and modular inversion" Bernstein and Yang, которая потом была реализована в OpenSSL 3.0.
Я не хотел никого обидеть или принизить чьи-то заслуги. Я просто хотел отметить, что эта работа от имени сотрудников Tempesta так и не появилась в ядре Linux. Ускорения TLS мы, кажется, уже обсуждали в offline как раз после NetDev Conf, я ни в коем случае не говорю (и не говорил), что вы не занимаетесь улучшением этих алгоритмов.
для GCM-AES патч -это https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6e758fa64438082e48272db19ad74ed4fb98938 - да, реализует Karatsuba, которого очень долго не было в ядре
Именно эту работу в ядре я имел ввиду в предыдущем своем комментарии про производительность TLS в ядре - она не уступает user-space реализациям
коллеги, как и все нормальные/простые люди, у которых нет ресурсов Facebook для поддержки mainline ядер в продакшене, работают на longterm ядрах.
А вот тут можно немного подробнее? Например, с каким минорных версий LTS ядер ты считаешь имеет смысл использовать в проде? И почему поддержка LTS ядер требует меньше ресурсов? Мне кажется, что в community сформировалось некорректное предубеждение к Stable версиям, или отсутствует понимание зачем поддерживаются LTS ядра.
У меня нет здесь хорошего ответа. Мы лично наступали на ядерные баги, которые нам прям мешали, в минорных версях около .10. Это, в любом случае, компромис между стабильностью (из личного опыта) и фичами/производительностью/пр.
Я имел ввиду, что на какой-то конференции ваш DeмOps рассказывал, что вы (и Google тоже, как и другихе hyperscalers) патчите текущее ядро и так или иначе, оно попадает в про. Пусть не на условный YouTube.com/facebook.com, но тем не менее. Когда я его спросил собственно и как если сервер в проде в Oops свалится, он мне сказал, что инфраструктура строится так, что в любой момент любой сервер как угодно может выйти из строя. Так мало, кто может строить. Я занимаюсь балансировщиками и часто - это проста пара машин: пока одна ребутается, под хорошей нагрузкой и хорошим багом, и вторая может лечь. Вообще, люди очень настороженно относятся к ядерным багам.
Буду рад, если, что расскажешь про LTS ядра.
Сетевая community kernel handshakes приняла хорошо, а security - нет. У нас было прилично переписки. Сама по себе миграция патчей и унификация для общего use case для меня выглядит, как 1-2 человека года, может, и больше. У нас просто нет столько рук, чтобы это не повредило продукту.
Интересная статья, спасибо.
А что насчёт совместимости? Если клиент поддерживает только tls 1.1 то вы его реджектить или устанавливаете коннект без ktls?
RSA сертификаты как опцию поддерживаете, если клиент не умеет в ECDSA?
Пересказ статьи:
чем-то не устроил nginx, решили написать своё на Go.
своё решение захлёбывалось от вслесков трафика, взяли готовый Hitch.
своё приложение было жалко выкидывать, приспособили под другие задачи.
попробовали переписать на rust, но решили не плодить языки.
узнали про kTLS в ядре линукса и стали использовать в Go, в итоге выбросив Hitch.
МЯСО!!!
Разгоняем Go TLS до 100 Gbps с сервера: опыт Kinescope