Протокол HTTP-over-QUIC официально становится HTTP/3

С момента принятия стандарта HTTP/2 прошло три с половиной года: спецификация RFC 7540 опубликована в мае 2015-го, но пока не используется повсеместно. Протокол реализован во всех браузерах ещё с конца 2015 года, а спустя три года только 31,2% из 10 млн самых популярных интернет-сайтов поддерживают HTTP/2. Из самых популярных сайтов на него перешли Google, Youtube, Wikipedia, Twitter, Vk.com и другие.

Как сейчас стало известно, разработчики двух альтернативных вариантов достигли совместимости, а протокол HTTP-over-QUIC теперь меняет название и официально именуется HTTP/3. Тем не менее, прогресс не стоит на месте — и уже идёт работа над следующей версией HTTP/3. Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC.

QUIC представляет собой замену TCP, которая работает поверх UDP. Изначально эта технология была создана инженерами Google, как и предыдущий протокол SPDY, который стал основой HTTP/2. В первое время QUIC именовали “HTTP/2-encrypted-over-UDP”.

Здесь он разделилcя на две части: транспорт и HTTP. Затем разработку QUIC передали в IETF для стандартизации. Однако название осталось таким же: QUIC. Идея в том, что транспортный протокол можно использовать также для передачи других данных, а не только эксклюзивно для HTTP или HTTP-подобных протоколов. Разработкой транспортного протокола занимается рабочая группа QUIC Working Group в Инженерном совета интернета (IETF).

Хотя тесты показывают, что реализация QUIC от Google работает существенно хуже TCP, если сеть не гарантирует порядок доставки пакетов. В то же время Google продолжила работу над своей собственной реализацией — и внедрила её в браузер Chrome.

Разница в производительности между QUIC с TCP (в процентах) в сети с RTT 112 мс и джиттером 10 мс, источник

Разница в производительности между QUIC с TCP (в процентах) в сети с RTT 112 мс и джиттером 10 мс, который меняет порядок пакетов, источник

Некоторые разработчики вообще любые версии QUIC на UDP называют «дичайшим экспериментом».

Разноголосицу в версиях и именованиях QUIC объясняет Дэниель Стенберг, ведущий разработчик curl, работающий в Mozilla, который давно следит за этой историей.

По его словам, в кругу разработчиков получили распространения неформальные названия двух версий QUIC, поскольку варианты от IETF и Google значительно различаются в деталях реализации:

• iQUIC (версия IETF)
• gQUIC (версия Google)

Протокол для передачи HTTP по iQUIC (версия IETF) долгое время называли “hq” (HTTP-over-QUIC).

На семинаре рабочей группы QUIC Майк Бишоп напугал всех собравшихся таким слайдом, как будто это логотип. В общем, устоявшегося названия для разных версий не было.

Слайд из презентации Майка Бишопа

Ведущие семинара попросили Майка больше никогда это не показывать.

Тем не менее, 7 ноября 2018 года один из ведущих разработчиков протокола Дмитрий Тихонов объявил, что LiteSpeed Tech и Facebook достигли совместимости протоколов, и теперь разработка продолжится в общем русле.

По его словам, это поможет устранить путаницу между QIUC-транспортом и QUIC-оболочкой для HTTP. Объединить iQUIC и gQUIC под названием HTTP/3 в сентябре предложил Марк Ноттингем, один из самых влиятельных инженеров IETF, соавтор нескольких веб-стандартов.

Таким образом, HTTP/3 — это новая версия HTTP, которая будет использовать транспорт QUIC.

В чём преимущества транспортного протокола QUIC перед TCP? Преимуществ очень много, и по словам самого Марк Ноттингема, переход от устаревшего TCP на новые протоколы просто неизбежен, поскольку сейчас очевидно, что TCP страдает от проблем неэффективности.

В мультиплексированном протоколе это может привести к большой потере производительности, — объясняет Марк Ноттингем. «Поскольку TCP — протокол доставки пакетов по порядку, то потеря одного пакета может помешать доставке приложению последующих пакетов из буфера. — QUIC пытается решить эту проблему с помощью эффективной перестройки семантики TCP (вместе с некоторыми аспектами потоковой модели HTTP/2) поверх UDP».

iQUIC использует TLS 1. Кроме перехода значительного объёма трафика с TCP на UDP, и Google QUIC (gQUIC), и IETF QUIC (iQUIC) требуют обязательного шифрования: нешифрованного QUIC не существует вообще. Но поскольку он основан на UDP, значительная часть информации о сессии и метаданных, открытых в TCP, шифруется в QUIC. 3 для установки ключей сессии, а затем шифрования каждого пакета.

В статье «Будущее интернет-протоколов» Марк Ноттингем говорит о значительных улучшениях в безопасности с переходом на QUIC:

Всё остальное зашифровано — включая пакеты ACK, что значительно повышает планку для проведения атак с анализом трафика. На самом деле текущий «короткий заголовок» iQUIC — который используется для всех пакетов, кроме рукопожатия — выдаёт только номер пакета, необязательный идентификатор соединения и байт состояния, необходимый для процессов вроде смены ключей шифрования и типа пакета (который тоже может быть зашифрован).

Кроме того, становится невозможна пассивная оценка RTT и потерь пакетов путём простого наблюдения за соединением; там недостаточно информации для этого.

Они говорят, что такие пассивные измерения критически важны для отладки и анализа их сетей. Отсутствие наблюдаемости вызвало серьёзную озабоченность у некоторых представителей сообщества операторов связи.

Это бит в заголовке, который меняет своё значение один раз по пути туда-обратно, так что наблюдатель может оценить RTT. Одно из предложений для решения этой проблемы — введение спин-бита. Поскольку он не привязан к состоянию приложения, то не должен выдавать никакой информации о конечных точках, кроме примерной оценки местоположения сети.

Возможно, принятие стандарта QUIC произошло бы и раньше, если бы компания Google не поспешила внедрить свою реализацию в браузер Chrome, так что сейчас на проприетарную версию iQUIC приходится более 7% трафика в интернете.

Тем не менее, прогресс неизбежен — и в ближайшие годы обязательно продолжится стандартизация и повсеместное внедрение различных протоколов нового поколения, в том числе HTTP/3 на транспорте QUIC.