- PVSM.RU - https://www.pvsm.ru -

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

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

Тем не менее, прогресс не стоит на месте — и уже идёт работа над следующей версией HTTP/3. Как сейчас стало известно [4], разработчики двух альтернативных вариантов достигли совместимости, а протокол HTTP-over-QUIC теперь меняет название и официально именуется [5] 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, если сеть не гарантирует порядок доставки пакетов [6].

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

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

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

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

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

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

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

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

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

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

Протокол HTTP-over-QUIC официально становится HTTP-3 - 4
Слайд из презентации Майка Бишопа

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

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

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

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

Транспорт QUIC

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

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

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

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

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

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

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

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

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

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

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


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

Автор: GlobalSign_admin

Источник [16]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/299142

Ссылки в тексте:

[1] RFC 7540: https://tools.ietf.org/html/rfc7540

[2] с конца 2015 года: https://habr.com/post/378543/

[3] 31,2%: https://w3techs.com/technologies/details/ce-http2/all/all

[4] стало известно: https://twitter.com/dmitri_tikhonov/status/1059998989557395457

[5] официально именуется: https://daniel.haxx.se/blog/2018/11/11/http-3/

[6] реализация QUIC от Google работает существенно хуже TCP, если сеть не гарантирует порядок доставки пакетов: https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop/

[7] источник: https://conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf

[8] называют «дичайшим экспериментом»: https://habr.com/company/qrator/blog/416633/

[9] попросили Майка больше никогда это не показывать: https://youtu.be/uVf_yyMfIPQ?t=6047

[10] предложил: https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0iuz0ZBa35s

[11] словам: https://habr.com/post/345472/

[12] «короткий заголовок»: https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#short-header

[13] атак с анализом трафика: https://www.mjkranch.com/docs/CODASPY17_Kranch_Reed_IdentifyingHTTPSNetflix.pdf

[14] спин-бита: https://tools.ietf.org/html/draft-trammell-quic-spin

[15] Image: https://clck.ru/EhoeK

[16] Источник: https://habr.com/post/429820/?utm_source=habrahabr&utm_medium=rss&utm_campaign=429820