![](https://habrastorage.org/webt/7h/cm/vd/7hcmvd7vduenx5wf34twkez4hxk.jpeg)
Тем не менее, прогресс не стоит на месте — и уже идёт работа над следующей версией 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, если сеть не гарантирует порядок доставки пакетов.
![](https://habrastorage.org/webt/pk/um/_m/pkum_mxkkvkmusl2qclvzzxezes.png)
Разница в производительности между QUIC с TCP (в процентах) в сети с RTT 112 мс и джиттером 10 мс, источник
![](https://habrastorage.org/webt/e7/uo/fs/e7uofswtyrj5vq5lyci6_h6kvba.png)
Разница в производительности между 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 Майк Бишоп напугал всех собравшихся таким слайдом, как будто это логотип.
![](https://habrastorage.org/webt/gc/b-/8i/gcb-8iqkj0zc9ofe4dbg4izowlo.png)
Слайд из презентации Майка Бишопа
Ведущие семинара попросили Майка больше никогда это не показывать.
Тем не менее, 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».
![](https://habrastorage.org/getpro/geektimes/post_images/542/add/77d/542add77df513daee49729fd369684e0.png)
Кроме перехода значительного объёма трафика с 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.
![](https://habrastorage.org/webt/rw/hk/1y/rwhk1y-msfqaknqu2kbktqf6g7a.jpeg)
![](https://habrastorage.org/webt/od/n-/xe/odn-xebtl8a5lexzip_kkkezr6s.jpeg)