Что такое HTTP/3 – Краткий обзор нового быстрого протокола на основе UDP

TL;DR

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

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

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

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

HTTP/3 Прогресс в 2022 году

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

Несколько лет назад мы опубликовали статью о HTTP/2, стандарте, который, по данным W3Techs, в настоящее время достиг примерно 45% мирового уровня принятия. И, согласно Can I Use, он также поддерживается всеми современными веб-браузерами. И вот мы пишем статью о следующей версии протокола HTTP/3.

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

Это открытая организация, которая объединяет веб-индустрию и способствует обсуждению направлений развития Интернета. В настоящее время фаза «Интернет-черновик» HTTP/3 является последней фазой перед тем, как предложения будут переведены на уровень запросов на комментарии (или RFC), которые мы можем считать во всех смыслах официальными определениями интернет-протокола.

Хотя HTTP/3 еще не является официальным Интернет-протоколом, многие компании и проекты уже начали добавлять поддержку HTTP/3 в свои продукты.

Поддержка веб-браузером для HTTP/3

Что касается веб-браузера, в Chrome v87, Firefox v88 и Edge v87 по умолчанию включен HTTP/3. Для пользователей Safari возможность включения HTTP/3 была добавлена ​​в Safari Technology Preview v104. Однако в настоящее время поддержка HTTP/3 недоступна в стабильной версии Safari.

Библиотечная поддержка HTTP/3

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

• Python — http3 и aioquic
• Ржавчина - пирог с заварным кремом, неко и куинн
• C — nghttp3 и lsquic
• Иди - быстро
• JavaScript — Node.js

Инфраструктурная поддержка HTTP/3

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

В Kinsta все сайты, которые мы размещаем, защищены нашей бесплатной интеграцией с Cloudflare. В дополнение к брандмауэру корпоративного уровня и защите от DDoS клиенты Kinsta также имеют доступ к HTTP/3!

Чтобы проверить, поддерживает ли ваш сайт HTTP/3, вы можете использовать инструмент тестирования HTTP/3 от Geekflare. Просто введите свой домен и нажмите кнопку «Проверить HTTP/3», и инструмент сообщит вам, поддерживает ли ваш сайт HTTP/3.

Если ваш сайт поддерживает HTTP/3, вы должны увидеть сообщение, подобное приведенному ниже. Поскольку kinstalife.com размещен на Kinsta, HTTP/3 полностью поддерживается благодаря нашей интеграции с Cloudflare.

Вы также можете использовать инспектор вашего браузера, чтобы проверить поддержку HTTP/3. В этом примере мы будем использовать последнюю версию Google Chrome, которая поддерживает HTTP/3.

Чтобы открыть инспектор, щелкните правой кнопкой мыши страницу, выберите «Проверить» и перейдите на вкладку «Сеть». В столбце «Протокол» вы можете увидеть протокол HTTP, используемый для соединения. Соединения HTTP/2 отображаются как «h2», а соединения HTTP/3 отображаются как «h3-XX» (XX относится к конкретному черновику HTTP/3). Как вы можете видеть на изображении ниже, kinstalife.com поддерживает соединения через «h3-29», что означает «HTTP/3 Draft 29».

Теперь, когда мы рассмотрели текущий статус HTTP/3, давайте углубимся в некоторые различия между HTTP/2 и HTTP/3!

Немного предыстории — все началось с HTTP/2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Они нормируют.

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

Подпишитесь на рассылку новостей

Хотите знать, как мы увеличили наш трафик более чем на 1000%?

Присоединяйтесь к более чем 20 000 других пользователей, которые получают нашу еженедельную рассылку с советами по WordPress, посвященными инсайдерской информации!

Подпишитесь сейчас

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

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

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

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

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

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

TCP

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

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

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

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

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

UDP

Протокол пользовательских дейтаграмм (UDP) также является одной из частей набора протоколов Интернета, спецификация которого восходит к 1980 году (RFC 768).

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

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

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

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

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

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

QUIC и HTTP/3

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

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

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

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

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

Как сказал Лукас Пардью из Cloudflare:

Ориентируясь на потоки 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, по сравнению со старыми версиями, также способствует увеличению скорости протокола, поскольку его рукопожатия требуют меньшего количества циклов. Kinsta поддерживает TLS 1.3 на всех наших серверах и нашей CDN Kinsta.

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

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

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

Хотя UDP предоставляет QUIC и HTTP/3 некоторые неотъемлемые преимущества, он также создает некоторые проблемы.

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

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

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

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

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

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

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

Поскольку обратная совместимость имеет первостепенное значение, IETF продвигает реализацию HTTP/3 и будет включать в ответ старую версию (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-м.

В 2022 году у нас появится поддержка HTTP/3 в основных браузерах, таких как Google Chrome и Brave. Что касается инфраструктуры, веб-серверы, такие как Litespeed и Nginx, имеют рабочие реализации HTTP/3, а сетевые провайдеры, такие как Cloudflare, уже внедрили полную поддержку HTTP/3.

В настоящее время HTTP/3 все еще находится на стадии Internet Draft, а срок действия самой последней версии истекает в августе 2021 года. Этот год будет захватывающим, поскольку мы можем ожидать, что крупные поставщики программного обеспечения предпримут шаги для реализации нового стандарт.