С момента принятия стандарта HTTP/2 прошло три с половиной года: спецификация RFC 7540 опубликована в мае 2015-го, но пока не используется повсеместно. Протокол реализован во всех браузерах ещё с конца 2015 года, а спустя три года только 31,2% из 10 млн самых популярных интернет-сайтов поддерживают HTTP/2. Из самых популярных сайтов на него перешли Google, Youtube, Wikipedia, Twitter, Vk.com и другие.
Тем не менее, прогресс не стоит на месте — и уже идёт работа над следующей версией HTTP/3. Как сейчас стало известно, разработчики двух альтернативных вариантов достигли совместимости, а протокол HTTP-over-QUIC теперь меняет название и официально именуется HTTP/3. Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC.
Путаница с разными вариантами QUIC
QUIC представляет собой замену TCP, которая работает поверх UDP. Изначально эта технология была создана инженерами Google, как и предыдущий протокол SPDY, который стал основой HTTP/2. В первое время QUIC именовали “HTTP/2-encrypted-over-UDP”.
Затем разработку QUIC передали в IETF для стандартизации. Здесь он разделилcя на две части: транспорт и HTTP. Идея в том, что транспортный протокол можно использовать также для передачи других данных, а не только эксклюзивно для HTTP или HTTP-подобных протоколов. Однако название осталось таким же: QUIC. Разработкой транспортного протокола занимается рабочая группа QUIC Working Group в Инженерном совета интернета (IETF).
В то же время Google продолжила работу над своей собственной реализацией — и внедрила её в браузер Chrome. Хотя тесты показывают, что реализация QUIC от Google работает существенно хуже TCP, если сеть не гарантирует порядок доставки пакетов.
Разница в производительности между 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 достигли совместимости протоколов, и теперь разработка продолжится в общем русле.
Объединить iQUIC и gQUIC под названием HTTP/3 в сентябре предложил Марк Ноттингем, один из самых влиятельных инженеров IETF, соавтор нескольких веб-стандартов. По его словам, это поможет устранить путаницу между QIUC-транспортом и QUIC-оболочкой для HTTP.
Таким образом, HTTP/3 — это новая версия HTTP, которая будет использовать транспорт QUIC.
Транспорт QUIC
В чём преимущества транспортного протокола QUIC перед TCP? Преимуществ очень много, и по словам самого Марк Ноттингема, переход от устаревшего TCP на новые протоколы просто неизбежен, поскольку сейчас очевидно, что TCP страдает от проблем неэффективности.
«Поскольку TCP — протокол доставки пакетов по порядку, то потеря одного пакета может помешать доставке приложению последующих пакетов из буфера. В мультиплексированном протоколе это может привести к большой потере производительности, — объясняет Марк Ноттингем. — QUIC пытается решить эту проблему с помощью эффективной перестройки семантики TCP (вместе с некоторыми аспектами потоковой модели HTTP/2) поверх UDP».
Кроме перехода значительного объёма трафика с TCP на UDP, и Google QUIC (gQUIC), и IETF QUIC (iQUIC) требуют обязательного шифрования: нешифрованного QUIC не существует вообще. iQUIC использует TLS 1.3 для установки ключей сессии, а затем шифрования каждого пакета. Но поскольку он основан на UDP, значительная часть информации о сессии и метаданных, открытых в TCP, шифруется в QUIC.
В статье «Будущее интернет-протоколов» Марк Ноттингем говорит о значительных улучшениях в безопасности с переходом на QUIC:
На самом деле текущий «короткий заголовок» iQUIC — который используется для всех пакетов, кроме рукопожатия — выдаёт только номер пакета, необязательный идентификатор соединения и байт состояния, необходимый для процессов вроде смены ключей шифрования и типа пакета (который тоже может быть зашифрован). Всё остальное зашифровано — включая пакеты ACK, что значительно повышает планку для проведения атак с анализом трафика.
Кроме того, становится невозможна пассивная оценка RTT и потерь пакетов путём простого наблюдения за соединением; там недостаточно информации для этого.
Отсутствие наблюдаемости вызвало серьёзную озабоченность у некоторых представителей сообщества операторов связи. Они говорят, что такие пассивные измерения критически важны для отладки и анализа их сетей.
Одно из предложений для решения этой проблемы — введение спин-бита. Это бит в заголовке, который меняет своё значение один раз по пути туда-обратно, так что наблюдатель может оценить RTT. Поскольку он не привязан к состоянию приложения, то не должен выдавать никакой информации о конечных точках, кроме примерной оценки местоположения сети.
Возможно, принятие стандарта QUIC произошло бы и раньше, если бы компания Google не поспешила внедрить свою реализацию в браузер Chrome, так что сейчас на проприетарную версию iQUIC приходится более 7% трафика в интернете.
Тем не менее, прогресс неизбежен — и в ближайшие годы обязательно продолжится стандартизация и повсеместное внедрение различных протоколов нового поколения, в том числе HTTP/3 на транспорте QUIC.
Автор: GlobalSign_admin
