Что такое HTTP/3 — описание и возможности нового протокола на основе UDP

В ноябре 2018 года в Бангкоке состоялась встреча Инженерной рабочей группы по Интернету (IETF), и был принят новый проект Интернет . Транспортный протокол QUIC, преемник HTTP/2 , был переименован в HTTP/3. HTTP/3 основан на UDP и уже используется известными интернет-компаниями, такими как Google и Facebook. Если вы используете Chrome и подключаетесь к службе Google, возможно, вы уже используете QUIC.

Новая версия протокола HTTP использует преимущества низкоуровневого протокола UDP низкого уровня и определяет многие новые функции, которые были в предыдущих версиях HTTP на уровне TCP. Это обеспечивает способ устранения ограничений в существующей интернет-инфраструктуре.

Первые результаты являются многообещающими, и когда в июне 2019 года истечет срок действия Интернет-черновика от IETF, можно ожидать, что HTTP/3 будет продвигаться как новый стандарт HTTP третьего поколения.

Как и в HTTP/2, HTTP/3 снова будет опираться на эти достижения, чтобы ускорить работу в Интернете.

HTTP/3 идет

Некоторые говорят, что жажда большей скорости и меньших задержек в веб-индустрии совпадает с жаждой увеличения объема оперативной памяти в Google Chrome.

HTTP/2 Использование

На момент написания этой статьи HTTP/3 был интернет-проектом или идентификатором IETF , что означает, что в настоящее время рассматривается вопрос о готовящемся стандарте интернета, подготовленный Целевой группой по интернет-разработкам — международному органу по стандартизации интернета , отвечающему за определение и продвижение согласованных стандартов интернет-протокола, таких как TCP, IPv6 , VoIP, Интернет вещей и т. д.

Это открытый орган, который объединяет интернет-индустрию и способствует обсуждению направления Интернета.

В настоящее время этап идентификации HTTP/3 является последним этапом перед тем, как предложения будут переведены на уровень RFC, или Запрос на комментарии, который мы можем рассматривать, для всех намерений и целей , в официальных определениях интернет-протокола. Затем реализуются все основные интернет-игроки.

Это означает, что HTTP/3 должен стать официальным стандартом после истечения срока действия проекта в конце этого года (июнь 2019 года).

Что такое HTTP/3 — в терминах Layman

HTTP/3 является третьей версией протокола передачи гипертекста (HTTP), ранее известного как HTTP-over-QUIC. QUIC (Quick UDP Internet Connections) изначально был разработан Google и является преемником HTTP/2. Такие компании, как Google и Facebook, уже используют QUIC для ускорения работы в Интернете.

HTTP/2 принес серьезные улучшения с неблокирующими загрузками, конвейерной передачей и серверной загрузкой, что помогло нам преодолеть некоторые ограничения базового протокола TCP. Это позволило нам минимизировать количество циклов запрос-ответ и рукопожатий.

HTTP/2 позволил задействовать более одного ресурса в одном TCP-соединении — мультиплексирование. Мы также получили больше гибкости в упорядочении статических загрузок, и наши страницы больше не ограничены линейной последовательностью загрузок.

HTTP/2 push

На практике это означает, что теперь один большой ресурс javascript не обязательно равен дроссельной точке для всех других статических ресурсов, ожидающих своей очереди.

Добавьте к этому HTTP/2-заголовок сжатия HPACK и двоичный формат передачи данных по умолчанию, и во многих случаях у нас будет значительно более эффективный протокол.

HTTP/2 HPACK сжатие

Крупные реализации браузеров требовали от веб-сайтов реализации шифрования — SSL — чтобы иметь возможность пожинать преимущества HTTP/2 — и иногда это приводило к накладным расходам на вычисления, что делало улучшения скорости незаметными. Были даже случаи, когда пользователи сообщали о замедлении после перехода на HTTP/2.

Скажем так, первые дни принятия этой версии были не для слабонервных.

В реализации NGINX также отсутствовала функция push-сервера, полагаясь на модуль. И модули NGINX не являются вашими обычными выпадающими модулями Apache, которые вы можете просто скопировать — NGINX должен быть перекомпилирован с ними.

Хотя некоторые из этих проблем уже решены, если мы посмотрим на весь стек протоколов, мы увидим, что основное ограничение лежит на более низком уровне, чем HTTP/2, решившийся рискнуть.

Чтобы уточнить это, мы рассмотрим сегодняшний стек интернет-протоколов от его нижнего уровня до верхнего. Если вы хотите больше узнать об истории HTTP/2, обязательно ознакомьтесь с нашим полным руководством по HTTP/2 .

Интернет-протокол (IP)

Протокол Интернета (IP) определяет нижнюю часть всей интернет-топологии. Это та часть интернет-стека, которая, можно смело сказать, на самом деле не подлежит обсуждению без изменения всего, включая замену всей аппаратной инфраструктуры, от маршрутизаторов до серверов и даже компьютеров конечных пользователей.

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

Под ним находится канальный уровень — часть протокола, так сказать, «голая металлическая». С другой стороны, убедительный аргумент в пользу полного пересмотра можно увидеть по той скорости, с которой создателям IPFS (межпланетной файловой системы) удалось закрыть финансирование ICO, которое в течение одного месяца составило 250 миллионов долларов США.

Мы можем проследить начало протокола IP еще в 1974 году, к статье, опубликованной Институтом инженеров по электротехнике и электронике и автором которой являются Винт Серф и Боб Кан. Он детализировал пакеты, отправляемые по сети, маршрутизируя их по IP-адресам и численно определяемым адресам узлов в сети / сетях. Протокол определял формат этих пакетов или датаграмм — его заголовки и полезную нагрузку.

После определения RFC 760 от 1980 года IETF согласился с определением, широко используемым по сей день, в своем запросе комментариев 791 . Это четвертая версия протокола, но можно сказать, что это первая производственная версия.

Интернет-протокол (Источник изображения: RFC791 )

Он использует 32-битные адреса, что устанавливает ограничение на количество адресов около 4 миллиардов. Это ограничение объясняет загадку того, почему некоммерческие интернет-пользователи получают «динамические IP-адреса» от своих интернет-провайдеров, а статический IP-адрес считается «добавленной стоимостью» и часто требует дополнительной оплаты.

Прошло совсем немного времени, пока не стало понятно, что 32-разрядных адресов недостаточно, и нехватка надвигалась, поэтому было опубликовано много RFC, пытающихся с этим справиться. Хотя эти решения широко используются сегодня и являются частью нашей повседневной жизни, вероятно, можно смело утверждать, что эти суммы взломаны.

Интернет-протокол версии 6 или IPv6 стал способом устранения этих ограничений, в том числе постепенного принятия по сравнению с предыдущей версией. Он был подготовлен в качестве проекта стандарта для IETF в 1998 году и был повышен до стандарта Интернета в 2017 году.

Хотя адресное пространство IPv4 было ограничено длиной 32-разрядного адреса, стандарту IPv6 было присвоено 128 битов, или 3,4 * 10 ^ 38 возможных адресов. Этого должно быть достаточно, чтобы продержаться у нас довольно долго.

По данным Google и IPv6 среди пользователей, внедрение IPv6 составляет чуть более 25% по состоянию на март 2019 года.

Принятие IPv6

IP является рудиментарным уровнем интернет-стека, определяющим самые основные вещи, без гарантий доставки, целостности данных или упорядочения передаваемых пакетов. Само по себе это ненадежно. Формат заголовка IPv4 предусматривает контрольную сумму заголовка, которую узлы передачи используют для проверки целостности заголовка. Это отличает его от версии IPv6, которая основывается на канальном уровне, что делает его более быстрым.

Заголовок датаграммы в Интернете (Источник изображения: RFC791 )

Понимание роли TCP и UDP

Теперь пришло время изучить, где HTTP/3 вписывается в TCP и UDP.

TCP

В то время как IP является базовым уровнем всех наших онлайн-коммуникаций сегодня, TCP (Transmission Control Protocol) является частью более высокого уровня набора интернет-протоколов, обеспечивая надежность, необходимую для Интернета, почты, передачи файлов (FTP) — для приложений слои / протоколы интернета.

Это включает в себя многоэтапное установление соединения с квитированием, гарантированный порядок пакетов и повторную передачу потерянных пакетов. Он обеспечивает обратную связь (Acks) с доставкой отправителю и так далее. Существует также вычисление контрольной суммы для обнаружения ошибок.

Все это указывает на множество шагов, которые делают TCP надежным протоколом, что делает его основой самых печально известных интернет-сервисов, которые мы используем сегодня.

Его спецификации, относящиеся к 1974 году (RFC 675) и 1981 году (RFC 793) , по сей день существенно не изменились.

Однако надежность, которую обеспечивает TCP, не обходится без затрат. Затраты на все обращения туда и обратно, необходимые для рукопожатий, отзывов о доставке, гарантий заказа и контрольных сумм, которые можно считать слабыми и избыточными. Это сделало TCP узким местом современного стека протоколов. HTTP/2 достиг плато улучшений скорости, которые могут быть достигнуты поверх TCP.

Любое существенное изменение TCP не является простым делом, поскольку протокол является частью стека TCP / IP, который восходит к 70-м годам. Он глубоко встроен в операционные системы, прошивку устройства и т. Д.

UDP

UDP ( User Datagram Protocol ) также является одной из частей пакета интернет-протокола, спецификация которого относится к 1980 году (RFC 768) .

Как следует из названия, это протокол без установления соединения на основе дейтаграмм. Это означает, что нет рукопожатий и нет гарантий заказа или доставки. Это означает, что любые возможные шаги для обеспечения доставки, целостности данных и прочего оставляются на уровне приложений. Это означает, что приложение, построенное поверх UDP, может использовать стратегии выбора вишен, которые оно будет использовать в зависимости от конкретного случая, или оно может использовать элементы канального уровня , такие как контрольные суммы, чтобы избежать накладных расходов.

Поскольку UDP широко распространен, как и TCP, он позволяет добиться улучшений, не требуя широкой смены прошивки на всех устройствах, подключенных к Интернету, или значительных изменений в операционных системах.

Развертывание новых протоколов затруднено многими брандмауэрами, NAT, маршрутизаторами и другими промежуточными устройствами, которые позволяют только TCP или UDP развертываться между пользователями и серверами, к которым они должны обращаться. — HTTP/3

Этот поток в Hacker News может помочь нам начать понимать причину создания новой версии HTTP поверх существующего сетевого стека, а не изобретать ее заново (хотя это еще не все).

Спецификация формата пакетов UDP довольно минимальна, ее заголовок состоит из порта источника, порта назначения, длины в байтах, заголовка пакета и данных пакета, а также контрольной суммы. Контрольная сумма может использоваться для проверки целостности данных как для заголовка, так и для части данных пакета.

Контрольная сумма является необязательной, если нижележащим уровнем протокола является IPv4, и обязательна для IPv6. До сих пор UDP использовался для приложений VoIP, потокового видео, системы DNS и протокола DHCP .

QUIC и HTTP/3

QUIC (Quick UDP Internet Connections) был впервые развернут компанией Google в 2012 году. Он переопределяет границы сетевых уровней, опираясь на протокол UDP более низкого уровня, переопределяет рукопожатия, функции обеспечения надежности и функции безопасности в «пространстве пользователя», избегая необходимости обновление ядер интернет-систем.

Стек HTTP/2 против стека HTTP/3

Как и в случае с HTTP/2, прогрессом, который был спровоцирован SPDY от Google или быстрым, HTTP/3 снова будет опираться на эти достижения.

В то время как HTTP/2 действительно давал нам мультиплексирование и уменьшал блокировку заголовка строки, он ограничен TCP. Вы можете использовать одно TCP-соединение для нескольких потоков, мультиплексированных вместе для передачи данных, но когда один из этих потоков терпит потерю пакета, все соединение (и все его потоки) остаются в заложниках, так сказать, до тех пор, пока TCP не сделает свое дело ( повторно передает потерянный пакет).

Это означает, что все пакеты, даже если они уже переданы и ожидают в буфере узла назначения, блокируются до повторной передачи потерянного пакета. Дэниел Стенберг в своей книге по HTTP/3 называет это «блоком линейного блока на основе TCP». Он утверждает, что при 2% потери пакетов пользователи будут лучше работать с HTTP / 1, используя шесть соединений, чтобы застраховать этот риск.

QUIC не ограничен этим. Поскольку QUIC основан на протоколе UDP без установления соединения, концепция соединения не несет ограничений по TCP, и сбои одного потока не должны влиять на остальные.

Сосредоточив внимание на потоках UDP , QUIC обеспечивает мультиплексирование без необходимости использовать одно TCP-соединение. QUIC строит свое соединение на более высоком уровне, чем TCP. Новые потоки в соединениях QUIC не должны ждать завершения других. Соединения QUIC также выигрывают от устранения накладных расходов на квитирование TCP, что снижает задержку.

Сотрудники Cisco сделали интересное видео, объясняющее тресторонний обмен данными TCP. Хотя QUIC устраняет функции надежности TCP, он компенсирует это выше уровня UDP, обеспечивая повторную передачу пакетов, упорядочение и т. Д. Google Cloud Platform представила поддержку QUIC для своих балансировщиков нагрузки в 2018 году и увидела улучшение среднего времени загрузки страницы на 8% во всем мире и до 13% в регионах, где задержка выше.

Между Google Chrome, YouTube, Gmail, поисковой системой Google и другими службами Google удалось развернуть QUIC на симпатичной части Интернета, не дожидаясь IETF. Инженеры Google утверждают, что в 2017 году 7% интернет-трафика уже проходило через QUIC.

Версия QUIC от Google была сосредоточена только на HTTP-транспорте с использованием синтаксиса HTTP/2. Люди из IETF (отвечающие за стандартизацию QUIC) решили, что версия QUIC IETF должна быть способна передавать больше, чем просто HTTP. В настоящее время, однако, любая работа над не HTTP-протоколами через QUIC приостановлена.

Еще одна вещь, которую решила рабочая группа IETF, заключается в том, что стандартизированная версия будет использовать шифрование TLS 1.3 вместо пользовательского решения Google. TLS 1.3, по сравнению со старыми версиями, также способствует скорости протокола, так как его рукопожатия требуют меньше циклических переходов.

Прямо сейчас Google продолжает использовать свою собственную версию QUIC в своем продукте, направляя усилия по разработке на стандарты IETF. Большинство других интернет-плееров опираются на версию IETF (они отличаются в некоторых других аспектах помимо шифрования).

Если мы откроем Chrome Dev Tools и загрузим некоторые продукты Google, такие как Gmail, в столбце «Протокол» на вкладке «Сеть», то увидим, что многие ресурсы загружаются через версию протокола QUIC от Google. Это также относится и к таким продуктам Google, как Analytics, Google Tag Manager и т. Д.

Сервис Google QUIC

Cloudflare недавно опубликовал очень обширное обновление о прогрессе стандартизации.

Хотя UDP предоставляет QUIC и HTTP/3 некоторые неотъемлемые преимущества, он также создает некоторые проблемы. В течение многих лет TCP был основным протоколом, а UDP — нет, поэтому операционные системы и программный стек для него, как правило, не так оптимизированы. Следовательно, нагрузка / требования к ЦП намного выше, по некоторым оценкам, вдвое больше, чем с HTTP/2.

Оптимизация идет глубоко в ядро ​​операционных систем, а также прошивок различных маршрутизаторов и устройств . Это руководство по настройке Red Hat может пролить свет на эту тему для тех, кто более склонен к техническим вопросам.

Можно сказать, что QUIC пытается перестроить функции TCP на основе более минимального и более гибкого протокола.

Соединения QUIC, о которых мы упоминали ранее, объединяют TLS и транспортные рукопожатия. После установления они идентифицируются уникальными CID (идентификаторами соединений). Эти идентификаторы сохраняются при изменении IP-адреса и могут помочь обеспечить непрерывную загрузку, например, при переключении с 4G на WiFi. Это актуально, особенно потому, что все больше интернет-трафика проходит на мобильных устройствах. Могут возникнуть вопросы, задуман ли этот элемент Google для облегчения отслеживания пользователей различными подключениями и интернет-провайдерами.

Протокол TLS является обязательным и предназначен для того, чтобы устройства в середине могли вмешиваться или перехватывать трафик. Вот почему нередко провайдеры и поставщики брандмауэров, такие как Cisco, видят проблему с протоколом UDP и предлагают способы ее отключения. Посредникам труднее проверять, контролировать или фильтровать трафик QUIC.

Потоки QUIC отправляются через соединения QUIC, однонаправленные или двунаправленные. Потоки имеют идентификаторы, которые идентифицируют инициатора, и является ли поток однонаправленным или двунаправленным, а также служат для управления потоком в потоке.

В то время как QUIC — это протокол транспортного уровня, HTTP — это уровень над ним, протокол прикладного уровня или протокол приложения.

Поскольку обратная совместимость имеет первостепенное значение, реализация HTTP/3, продвигаемая IETF, будет включать в ответ старую версию (HTT1 или HTTP/2). Он будет включать заголовок, который информирует клиента о доступности HTTP/3, а также информацию о порте / хосте, как описано в RFC 7838 .

Это отличается от HTTP/2, в котором транспорт может быть согласован в рамках рукопожатия TLS. Но так как IETF почти принял HTTP/3 на основе QUIC в качестве следующего стандарта, мы можем ожидать, что веб-клиенты будут ожидать поддержки HTTP/3 все больше и больше. Клиенты могут кэшировать данные из предыдущих подключений HTTP/3 и подключаться напрямую (без обратной связи или 0-RTT) при последующих посещениях того же хоста.

Резюме

Есть люди, которые думают, что из-за того, что стандарт HTTP/2 еще не принят, может быть слишком рано настаивать на использовании HTTP/3 (версия три). Это верный момент, но, как мы уже упоминали, этот протокол уже видел широкомасштабные тесты и реализации. Google начал тестировать его уже в 2015 году , а Facebook — в 2017 году .

С тех пор к стандартизации присоединились другие игроки, такие как Akamai и Mozilla. На последнем хакатоне IETF в ноябре 2018 года список участников проявил интерес к QUIC такими компаниями, как Facebook, Apple, Google, Mozilla, NetApp и LiteSpeed ​​Tech. Были некоторые многообещающие тесты , и похоже, что LiteSpeed ​​может быть первым крупным поставщиком серверов с работающим сервером HTTP/3 . Cloudflare также в настоящее время работает в бета-версии QUIC .

Вскоре после этого QUIC был переименован в HTTP/3 в интернет-проектеIETF . Срок его действия истекает в конце июня 2019 года, и мы можем ожидать RFC или окончательный стандарт где-то в июле.

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

Когда HTTP/3 будет доступен. Как только RFC будет завершен (лето 2019 года) и Nginx официально поддержит QUIC.