QUIC позволяет мгновенно установить повторное соединение (0-RTT) и обеспечивает минимальную задержку между отправкой запроса и получением ответа
Google Chrome Canary стал первым браузером, в который интегрирована (очень) экспериментальная поддержка протокола HTTP/3, где вместо TCP в качестве транспортного уровня используется протокол QUIC.
HTTP/3 — это новый синтаксис HTTP, который работает на IETF QUIC, мультиплексированном и безопасном транспорте на основе UDP. Хотя некоторые разработчики называют QUIC на UDP «дичайшим экспериментом», новый протокол сулит массу преимуществ.
С момента принятия стандарта HTTP/2 прошло три с половиной года: спецификация RFC 7540 опубликована в мае 2015-го, но пока не используется повсеместно. Протокол реализован во всех браузерах ещё с конца 2015 года, а спустя три года только 40,9% из 10 млн самых популярных интернет-сайтов поддерживают HTTP/2.
Несмотря на принятие HTTP/2 на основе SPDY в качестве стандарта RFC 7540, инженеры Google продолжили эксперименты с ускорением транспорта. До 2015 года они выпустили новые версии SPDY v3 и v3.1, а также начали работать над протоколом gQUIC, первый черновик которого опубликовали в начале 2012 года.
В ранних версиях gQUIC использовался синтаксис HTTP SPDY v3. Такой выбор имел смысл, потому что HTTP/2 ещё не утвердили. Бинарный синтаксис SPDY упакован в пакеты QUIC, которые отправляются в датаграммах UDP. Это отход от транспорта TCP, на который традиционно полагался HTTP. Вся система в сборе выглядела так:
Слоёный пирог SPDY по gQUIC. Иллюстрация из статьи «HTTP/3: от корней до кончиков»
Затем разработку передали в IETF для стандартизации. Здесь она разделилась на две части: транспорт и HTTP. Идея была в том, что транспортный протокол можно использовать также для передачи других данных, а не только эксклюзивно для HTTP или HTTP-подобных протоколов. Однако название осталось таким же: QUIC. Разработкой транспортного протокола занималась рабочая группа QUIC Working Group в Инженерном совета интернета (IETF).
В то же время Google продолжила работу над своей собственной реализацией — и внедрила её в браузер Chrome не дожидаясь стандартизации.
Разноголосицу в версиях и именованиях QUIC объясняет Дэниель Стенберг, ведущий разработчик curl, работающий в Mozilla, который давно следит за этой историей.
По его словам, до стандартизации HTTP/3 в кругу разработчиков получили распространения неформальные названия двух версий QUIC, поскольку варианты от IETF и Google значительно различаются в деталях реализации:
- iQUIC (версия IETF)
- gQUIC (версия Google)
Протокол для передачи HTTP по iQUIC (версия IETF) долгое время называли “hq” (HTTP-over-QUIC).
Объединить iQUIC и gQUIC под названием HTTP/3 в сентябре 2018 года предложил Марк Ноттингем, один из самых влиятельных инженеров IETF, соавтор нескольких веб-стандартов. По его словам, это поможет устранить путаницу между QIUC-транспортом и QUIC-оболочкой для HTTP.
Таким образом, HTTP/3 — это новая версия HTTP, которая будет использовать транспорт QUIC.
Основные преимущества QUIC, из документа QUIC Geek FAQ (в изложении Opennet):
- Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP).
- Контроль за целостностью потока, предотвращающий потерю пакетов.
- Возможность мгновенно установить соединение (0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения) и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time).
- Не использование при повторной передаче пакета того же номера последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов.
- Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках.
- Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.
- Криптографические границы блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов.
- Отсутствие проблем с блокировкой очереди TCP.
- Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов.
- Возможность подключения расширенных механизмов контроля перегрузки соединения.
- Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов.
- Заметный прирост производительности и пропускной способности, по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.
По словам Марк Ноттингема, переход от устаревшего TCP на новые протоколы просто неизбежен, поскольку сейчас очевидно, что TCP страдает от проблем неэффективности: «Поскольку TCP — протокол доставки пакетов по порядку, то потеря одного пакета может помешать доставке приложению последующих пакетов из буфера. В мультиплексированном протоколе это может привести к большой потере производительности, — объясняет Марк Ноттингем. — QUIC пытается решить эту проблему с помощью эффективной перестройки семантики TCP (вместе с некоторыми аспектами потоковой модели HTTP/2) поверх UDP».
Кроме того, любая версия требует обязательного шифрования: нешифрованного QUIC не существует вообще. iQUIC использует TLS 1.3 для установки ключей сессии, а затем шифрования каждого пакета. Но поскольку он основан на UDP, значительная часть информации о сессии и метаданных, открытых в TCP, шифруется в QUIC:
В статье «Будущее интернет-протоколов» Марк Ноттингем говорит о значительных улучшениях в безопасности с переходом на QUIC: «На самом деле текущий "короткий заголовок" iQUIC — который используется для всех пакетов, кроме рукопожатия — выдаёт только номер пакета, необязательный идентификатор соединения и байт состояния, необходимый для процессов вроде смены ключей шифрования и типа пакета (который тоже может быть зашифрован). Всё остальное зашифровано — включая пакеты ACK, что значительно повышает планку для проведения атак с анализом трафика. Кроме того, становится невозможна пассивная оценка RTT и потерь пакетов путём простого наблюдения за соединением; там недостаточно информации для этого».
Некоторые специалисты считают, что принятие стандарта HTTP/3 произошло бы и раньше, если бы компания Google не поспешила внедрить свою реализацию в браузер Chrome. Тем не менее, прогресс неизбежен — и в ближайшие годы можно ожидать дальнейшего распространения HTTP/3. Поддержка протокола в Chrome Canary — только начало. У Mozilla уже есть такие планы для браузера Firefox.
Для включения HTTP/3 требуется запустить Chrome Canary с опциями --enable-quic —quic-version=h3-23. Потом зайти на тестовый сайт quic.rocks:4433 — и вы увидите соответствующее уведомление.
В инструментах для разработчиков активность HTTP/3 отображается как "http/2+quic/99".
Комментариев нет:
Отправить комментарий