Комментарии 48
всё, что нужно знать про http/3:
TCP, который мы использовали с первых дней интернета, не реализуя потенциал максимальной эффективности, поэтому нам и стал нужен QUIC.
Потенциал максимальной эффективности. Видимо, он определяет ток эффективности. Если бы только не сопротивление эффективности...
Тут абзац два раза повторяется вроде как: TCP, который мы использовали с первых дней интернета, изначально был создан не на максимуме эффективности, поэтому нам и стал нужен QUIC.
А как для новых протоколов можно стукнуться в сервер, используя минимальный набор инструментов (и имея максимальный контроль над трафиком, для понимания и отладки)? Что-то в духе echo GET / HTTP/1.1 | nc myserver 80
А чем он лучше? Тем что у него служебной информациине не меньше, а больше чем в TCP и не масштабируется как QUIC?
Мне кажется, что реализация в железе, это утопия. Никто не будет менять оборудование по всему миру лишь затем, чтобы внедрить новый протокол. У нас IPv6 до сих пор не внедрен, хотя большинство железок уже лет 20 знают о нём.
С QUIC тоже ситуация не однозначная, как писалось в статье, многим промежуточным узлам интересно мониторить трафик.
Да даже если протокол требует реконфигурации оборудования, это, в масштабах мира, уже серьёзно замедлит внедрение
Так прикол в том, что QUIC не требует реконфигурации оборудования.
для всего старого промежуточного оборудования это будет UDP.
Например, нормального раздельного управления потоками, которое бы решило head-of-line blocking, в нём нет (хотя в предисловии говорится, что они типа его лечат). TSNы на DATA идут последовательно общим потоком, соответственно, получатель должен принять данные и накопить у себя. Выбрать данные одного конкретного потока нельзя: все варианты recv() позволяют только получить пометку, к какому потоку относится уже принятое сообщение. Ну и чем он тут существенно лучше TCP с каким-то собственным управлением?
Ассоциации со множеством адресов? Непохоже, чтобы массово использовались — тем более, что когда мобильному клиенту переключили IP, он уже не может передоговориться — поэтому подход QUIC с идентификаторами ассоциации тут рабочий, в отличие от.
По сути от SCTP остаётся только одна польза: форсировать тех невеж, которые думают, что посланное двумя разными send() не может быть принято одним recv(), использовать средство, на котором они не налажают. Но так как >95% сетевого взаимодействия идёт опять же поверх HTTP, то и это за них уже сделали.
Протокол классный, особенно во времена, когда пропускная способность выше крыши, а с пингом нужно бороться.
Один вопрос: как к нему относится роскомпозор?
Снаружи непонятно, что бегает внутри TLS - HTTP/1.1 или HTTP/2. Системы фильтрации видят IP и доменное имя в SNI (если оно не зашифровано). То есть нет никакой разницы для РКН, поддерживает там сервер этот новый модный протокол или нет.
Также, похоже, что реализации политики (структуры) доверия тоже решили не касаться — QUIC это отдаёт протоколу выше — HTTP/3, который, в свою очередь, наследует HTTPS и его набор legacy заплаток (например зашитые сертификаты гугла в хроме и сбор статистики подмены сертификатов там-же). Значит возможность использования корневых сертификатов для MitM дешифрования протокола остаётся.
На самом деле клиент и сервер договариваются об общем списке рандомно генерируемых CID, которые связаны с одним и тем же соединением.
Полагаю, эти списки еще и хранятся в памяти каждого в интервале сессии.
И если для клиента это копейки по ресурсам, то для сервера на множестве соединений это будет ощутимо?
А простота масштабирования QUIC учитывает передачу этих списков между различными нодами веб-приложения?
Для HTTP/1.1 все довольно просто, потому что каждый файл получает собственное TCP-соединение
Наверное имелся в виду HTTP/1.0
в 1.1 же можно переиспользовать соединение если запрашивать ресурсы последовательно.
В множестве организаций так или иначе через различные регуляторные требования обязательная норма - мониторить траффик на предмет выявления вирусного трафика, контроля утечек информации и т.п. (см pcidss и иже с ними). Плюс работа web application firewall/IPS тоже завязана на вскрытие/инспекцию содержимого, возможность обрыва нежелательного потока. Как с этим обстоят дела к QUICK?
Последние инициативы в отрасли часто связаны с интересом независимого пользователя (что правильно), но как правило игнорируют интересы корпоративной безопасности. А без этого оно не поедет. Посоветуйте хорошие материалы на эту тему.
WAF — видимо делать как Cloudflare (WAF/IPS просто имеет SSL-сертификаты, если надо — сам их и создает, а потом проксирует запрос настоящему серверу).
А если нет желания сертификаты выпускать из под контроля и сертификаты хочется свои — есть их же https://www.cloudflare.com/ssl/keyless-ssl/ (как я понимаю там сеансовые ключи передаются).
Работает все это за счет того, что DNS соответствующих хостов указывает на Cloudflare а владелец хоста прямо разрешил MITM, а за WAF еще и деньги заплатил (оно только на платных тарифах).
Насчет мониторить трафик — как я понимаю — все также, ставим на клиенты корпоративный CA и слушаем. Ну если нигде нет SSL pinning и вообще есть возможность этот сертификат поставить и заставить клиентское ПО использовать (насколько помню с тем же андроидом с этим — большие проблемы в принципе)
Хмм, а все точно уверены, что лучше пухлые пакеты постоянно, для всех, чем новое соединение для единиц, изредка? CID будет намертво приколочен к каждому пакету? А если я не хочу? Вот, знаю я, что у меня все клиенты сидят за стационарниками и не подключаются к сторонним Wi-Fi, можно как-то оповестить сервер, что в пакетах не нужно использовать CID? Или пакет железно побит на зоны с зарезервированным количеством байт под каждую фичу?
Миграция соединения - это да, заманчиво и как раз про транспорт. Что до переноса шифрования на транспортный уровень - по-моему, это не хорошо.
Уже в работе, опубликуем в сентябре-октябре.
Опубликована вторая часть: https://habr.com/ru/company/southbridge/blog/583434/
Спасибо за понятные картинки! Теперь, когда в далёком будущем клиенты будут обращаться в поддержку с вопросами «а на кой мне HTTP/3», я смогу рассказать и показать максимально понятно для обеих сторон.
Когда уже это чудо начнут имплеметировать? IETF, google, fb - огонь! Браузеры - огонь! А остальные подтянутся..
По поводу споров закрытых портов UDP - эта проблема не велика и не несет относительный глобальный характер. Тем кто закрыл все порты UDP кроме 53, придётся зайти на свою конечную железку(файервол, рутер) и открыть один условный порт - 5335/UDP например. А провайдерам на свитчах и рутерах/L3(а это миллионы промежуточных устройств) этого делать не надо(проблемы затронут лишь сраны с запретительными установками типо Китая и.. которые). То есть, развертывание протокола на глобальном уровне, поверх UDP ничего не стОит, однако администраторам конечных сетей(домашних, корпоративных), если они закрыли все порты UDP, придётся зайти на свой рутер/фаервол и открыть один порт. За это предприятия и платят админам, а частные админы, если и закрыли, что-то на своем домашнем рутере, то разберется, как открыть один "причал" для этого паровоза:) Всем добра и удачи!
Жду продолжение статьи, спасибо.
Когда уже это чудо начнут имплеметировать? IETF, google, fb — огонь! Браузеры — огонь!
Уже — https://caniuse.com/http3 — последние версии Chrome, Firefox, Edge, Opera. Вот Safari — нет
А остальные подтянутся…
Есть еще такая штука как DNS-over-Quic (ну а что — DNS-over-HTTP / DNS-over-TLS — можно ж) — уже поддерживается — https://adguard.com/ru/blog/dns-over-quic.html
nginx — есть но не по умолчанию https://www.nginx.com/blog/our-roadmap-quic-http-3-support-nginx/
Уже — https://caniuse.com/http3 — последние версии Chrome, Firefox, Edge, Opera. Вот Safari — нет
Отлично и спасибо. Может есть уже какая-то метрика, аналитика обзорная по поводу успеха технологии, какие-то промежуточные выводы?
PS: Включил, посмотрим:
Вопрос в том еще(что я выше и имел в виду) - кто мне отдает данные по этому протоколу и взаимодейтсвует со мной? Помню, когда ютуб переходил на хтмл5, я сразу принудительно поставил флажок. И кстати всемирный переход прошел бысто.
Добавили продолжение: https://habr.com/ru/company/southbridge/blog/583434/
Получается что сейчас ютуб использует шифрование 2 раза, сначало в quic, а потом в https, а в будущем будет у всех просто http://, а внутри уже quic.
Нет. И сейчас нет никакого двойного шифрования.
Почитать можно тут https://quicwg.org/base-drafts/rfc9001.html#name-protocol-overview
Своими словами криптографию пересказывать это неблагодарное дело. Ошибки слишком дорого стоят.
Бедные ембедеры. HTTP/2 в ESP32 уже несколько лет впихнуть не могут, хотя gRPC очень хочется. А QUIC, с его обязательным TLS, там точно не увидим.
HTTP/3 от А до Я: основные концепции. Часть 1