Комментарии 30
всё, что нужно знать про http/3:
TCP, который мы использовали с первых дней интернета, не реализуя потенциал максимальной эффективности, поэтому нам и стал нужен QUIC.
Потенциал максимальной эффективности. Видимо, он определяет ток эффективности. Если бы только не сопротивление эффективности...
Тут абзац два раза повторяется вроде как: TCP, который мы использовали с первых дней интернета, изначально был создан не на максимуме эффективности, поэтому нам и стал нужен QUIC.
А как для новых протоколов можно стукнуться в сервер, используя минимальный набор инструментов (и имея максимальный контроль над трафиком, для понимания и отладки)? Что-то в духе echo GET / HTTP/1.1 | nc myserver 80
Давно пора уходить от TCP к SCTP, но последний почему-то не торопятся реализовать в железе.
А чем он лучше? Тем что у него служебной информациине не меньше, а больше чем в TCP и не масштабируется как QUIC?
Мне кажется, что реализация в железе, это утопия. Никто не будет менять оборудование по всему миру лишь затем, чтобы внедрить новый протокол. У нас IPv6 до сих пор не внедрен, хотя большинство железок уже лет 20 знают о нём.
С QUIC тоже ситуация не однозначная, как писалось в статье, многим промежуточным узлам интересно мониторить трафик.
Да даже если протокол требует реконфигурации оборудования, это, в масштабах мира, уже серьёзно замедлит внедрение
Так прикол в том, что QUIC не требует реконфигурации оборудования.
для всего старого промежуточного оборудования это будет UDP.
Протокол классный, особенно во времена, когда пропускная способность выше крыши, а с пингом нужно бороться.
Один вопрос: как к нему относится роскомпозор?
Снаружи непонятно, что бегает внутри 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?
Последние инициативы в отрасли часто связаны с интересом независимого пользователя (что правильно), но как правило игнорируют интересы корпоративной безопасности. А без этого оно не поедет. Посоветуйте хорошие материалы на эту тему.
Хмм, а все точно уверены, что лучше пухлые пакеты постоянно, для всех, чем новое соединение для единиц, изредка? CID будет намертво приколочен к каждому пакету? А если я не хочу? Вот, знаю я, что у меня все клиенты сидят за стационарниками и не подключаются к сторонним Wi-Fi, можно как-то оповестить сервер, что в пакетах не нужно использовать CID? Или пакет железно побит на зоны с зарезервированным количеством байт под каждую фичу?
Миграция соединения - это да, заманчиво и как раз про транспорт. Что до переноса шифрования на транспортный уровень - по-моему, это не хорошо.
HTTP/3 от А до Я: основные концепции. Часть 1