Новый стандарт протокола HTTP (обозначенный как HTTP/3), на базе которого работает всемирная паутина, находится в разработке с 2018 года и в настоящее время проходит этап рассмотрения интернет-проекта. Одни браузеры уже поддерживают новый стандарт неофициально, другие официально, но при этом он отключен по умолчанию (Chrome/Firefox).
С момента стандартизации HTTP/1.1 в 1997 году HTTP стал основным протоколом прикладного уровня. За прошедшие годы HTTP пришлось значительно модернизировать, чтобы соответствовать развитию технологий интернета и обеспечивать обмен огромным разнообразием контента всемирной паутины.
Предыистория. Зачем нам нужен HTTP/3?
HTTP послужил толчком для развития интернета
Когда Тим Бернерс-Ли придумал интернет, протокол передачи гипертекста (HTTP) был «однострочным протоколом». HTTP/0.9 состоял из запросов текстовой строки ASCII: GET метод, за которым следовал адрес документа, необязательный адрес порта, заканчивающийся возвратом каретки (CR) и переводом строки (LF). Запрос состоял из строки символов ASCII. Можно было передавать только HTML-файлы, HTTP-заголовки отсутствовали. У него также не было кодов состояния или ошибок.
С годами HTTP эволюционировал от HTTP/1.0 до HTTP/1.1, а затем до HTTP/2. На каждой итерации в протокол добавлялись новые функции для удовлетворения потребностей пользователей того времени, такие как требования прикладного уровня, требования обеспечения безопасности, обработка сеансов и типы мультимедиа. Для более подробного ознакомления с HTTP/2 и его эволюцией от HTTP/1.0 загляните в раздел From humble origins – A brief history of HTTP в разделе HTTP evolution – HTTP-2 Deep Dive. Для более подробного сравнения ознакомьтесь с постом HTTP/2 vs HTTP/3.
Нагрузка на HTTP/2 по мере роста интернета
В ходе развития интернета и HTTP основной транспортный механизм HTTP, по большому счету, остался прежним. Однако по мере роста интернет-трафика из-за появления большого числа мобильных устройств, HTTP как протокол изо всех сил пытался обеспечить плавный и прозрачный просмотр веб-страниц. А с ростом спроса на приложения реального времени недостатки HTTP/2 становились все более и более очевидными.
Во-первых, окончательная версия HTTP/2 не включала в себя многих ожидаемых улучшений по сравнению с HTTP/1.1. Чтобы сохранить обратную совместимость с HTTP/1.1, протокол должен был сохранить те же POST- и GET-запросы, коды состояния (200, 301, 404 и 500) и так далее.
Кроме того, некоторые из реализованных функций вызвали проблемы с безопасностью: отсутствие обязательного шифрования, заголовки страниц сжатия и файлы cookie, которые были уязвимы для атак.
Целью HTTP/3 является обеспечение быстрых, надежных и безопасных веб-соединений на всех типах устройств за счет решения проблем передачи данных (транспортный протокол) в HTTP/2. Для этого он использует другой сетевой протокол транспортного уровня, называемый QUIC, который работает поверх интернет-протокола User Datagram Protocol (UDP) вместо TCP, используемого во всех предыдущих версиях HTTP.
В отличие от упорядоченной схемы обмена сообщениями TCP, UDP допускает многонаправленное транслирование рассылки сообщений, что, среди прочего, помогает решать проблемы блокировки заголовка строки (HoL) на уровне пакетов.
Кроме того, QUIC изменил способ установления связи между клиентом и сервером, уменьшив задержку, связанную с повторяющимися соединениями. На рисунке схематично представлена общая идея. Мы рассмотрим ее более подробно в разделе «Ограничения TCP»:
Уверен, что вы сейчас скажете, что TCP — более надежный протокол, чем UDP, зачем перепроектировать транспортный уровень HTTP поверх UDP? Вскоре мы рассмотрим ограничения работы HTTP поверх TCP. А сейчас давайте рассмотрим, что такое HTTP/3 и углубимся в особенности проектирования HTTP/3 на основе протокола QUIC.
Появление HTTP/3
В то время как Internet Engineering Task Force (IETF) формально стандартизировала HTTP/2, Google самостоятельно создавал gQUIC — новый транспортный протокол. Первоначальные эксперименты с gQUIC оказались очень обнадеживающими в улучшении просмотра веб-страниц в плохих условиях сети.
Поддержка внедрения gQUIC набирала обороты, и он был переименован в QUIC. Большинство членов IETF проголосовали за создание новой спецификации HTTP для работы с QUIC (и действительно назвали ее «HTTP over QUIC»), которая получила название HTTP/3.
HTTP/3 похож по синтаксису и семантике на HTTP/2. HTTP/3 следует той же последовательности обмена сообщениями запроса и ответа с форматом данных, который содержит методы, заголовки, коды состояния и тело. Однако существенное отличие HTTP/3 заключается в порядке размещения уровней протокола поверх UDP, как показано на следующей диаграмме.
Как HTTP/3 и QUIC устраняют ограничения TCP
Преимущества HTTP/3 связаны с лежащим в основе протоколом QUIC. Прежде чем мы поговорим о QUIC и UDP, стоит перечислить некоторые ограничения TCP, которые в первую очередь привели к разработке QUIC.
Ограничения TCP
Скользящее окно получателя TCP не «продвигается», если сегмент с меньшим порядковым номером еще не прибыл/не был получен, даже если сегменты с более высоким номером уже есть. Это может привести к мгновенному зависанию или даже закрытию потока TCP, даже если не удалось получить только один сегмент. Эта проблема известна как Head-of-Line (HoL) блокировка на уровне пакетов потока TCP.
Блокировка Head-of-Line на уровне пакетов может привести к закрытию потока TCP.
1. TCP не поддерживает мультиплексирование на уровне потока
Хотя TCP разрешает множественные логические соединения с прикладным уровнем и обратно, он не позволяет мультиплексировать пакеты данных в одном потоке TCP. При использовании HTTP/2 браузер может открыть только одно TCP-соединение с сервером. Он использует одно и то же соединение для запроса нескольких объектов, таких как CSS, JavaScript и другие файлы. При получении этих объектов TCP сериализует все объекты в одном потоке. В результате он понятия не имеет о разделении сегментов TCP на уровне объекта.
2. TCP использует избыточную связь
При установлении соединения TCP обменивается последовательностью сообщений, некоторые из которых являются избыточными, если соединение установлено с известным хостом.
Новый транспортный протокол – технология QUIC
Протокол QUIC устраняет эти ограничения TCP, внося несколько изменений в базовый механизм передачи. Эти изменения связаны со следующими вариантами проектирования:
1. UDP как выбор основного протокола транспортного уровня
Новый транспортный механизм, построенный на основе TCP, унаследует все недостатки TCP, описанные ранее. Дополнительным бонусом является то, что QUIC создается на уровне пользователя, поэтому не требует внесения изменений в ядро при каждом обновлении протокола, что упрощает внедрение.
2. Мультиплексирование потоков и управление потоком
QUIC вводит понятие мультиплексирования нескольких потоков в одном соединении. QUIC по своей конструкции реализует раздельное управление потоком для каждого потока, что решает проблему блокировки начала очереди (HoL) всего соединения. Первоначально HTTP/2 решал только проблему HoL на уровне HTTP. Однако в HTTP/2 HoL поток TCP на уровне пакетов может по-прежнему блокировать все транзакции в соединении.
3. Гибкое управление перегрузками
TCP имеет жесткий механизм контроля перегрузки. Каждый раз, когда протокол TCP обнаруживает перегрузку, он вдвое уменьшает размер окна перегрузки. Контроль перегрузки QUIC является более гибким и позволяет более эффективно использовать доступную полосу пропускания сети, что приводит к повышению пропускной способности трафика.
4. Улучшенная обработка ошибок
QUIC предлагает использовать усовершенствованный механизм восстановления после потерь и прямое исправление ошибок, чтобы справляться с ошибочными пакетами, особенно в неоднородных и медленных беспроводных сетях, подверженных высокому уровню ошибок при передаче.
5. Установление соединения происходит быстрее
QUIC использует тот же модуль TLS, что и HTTP/2 для защищенного соединения. Однако, в отличие от TCP, процесс установления связи QUIC оптимизирован, чтобы избежать избыточного обмена протоколами, когда два известных одноранговых узла устанавливают связь друг с другом.
Настройка безопасного соединения с помощью TCP и TLS занимает как минимум два периода времени на передачу и подтверждение приема (Round-Trip Times), что увеличивает задержку. При использовании QUIC первое зашифрованное соединение устанавливается на 1 RTT, а при возобновлении сеанса данные полезной нагрузки отправляются с первым пакетом при минимальном нулевом RTT, что обеспечивает постоянное сокращение общей задержки по всем направлениям по сравнению с HTTP/2.
6. Синтаксис и семантика
Объединяя прикладной уровень на основе HTTP/3 с QUIC, вы получаете все преимущества усовершенствованного транспортного механизма, сохраняя при этом тот же синтаксис и семантику HTTP/2. Однако обратите внимание, что HTTP/2 не может быть напрямую интегрирован с QUIC, потому что базовое сопоставление фреймов из приложения в передачу (транспорт) несовместимо. Следовательно, рабочая группа HTTP IETF предложила HTTP/3 в качестве новой версии HTTP с его отображением фреймов, измененным в соответствии с требованиями формата фрейма протокола QUIC.
7. Сжатие
HTTP/3 также использует новый механизм сжатия заголовков под названием QPACK, который является модификацией HPACK, используемой в HTTP/2. В QPACK заголовки HTTP могут поступать не по порядку в разных потоках QUIC. В отличие от HTTP/2, где TCP обеспечивает упорядоченную доставку пакетов, потоки QUIC доставляются не по порядку и могут содержать разные заголовки в разных потоках. Чтобы справиться с этим, QPACK использует механизм таблицы поиска для кодирования и декодирования заголовков.
8. Улучшенный push
Представленная в HTTP/2 функция push-уведомлений сервера может рассматриваться как ожидание запроса, который еще предстоит сделать клиенту. Это все еще присутствует в HTTP/3, но его реализация осуществляется через другие механизмы и может быть ограничена. Хотя серверные push-уведомления экономят половину пути туда и обратно, они по-прежнему занимают полосу пропускания.
Фрейм PUSH_PROMISE отправляется с сервера через поток запросов, показывающий, что будет содержаться в запросе, на который push будет ответом. Затем он отправляет этот фактический ответ в новом потоке.
Отправка сервером может быть ограничена клиентом. Отдельные потоки могут быть отменены с помощью CANCEL_PUSH, даже если ранее это считалось приемлемым.
Почему HTTP/3 важен?
TCP существует уже более четырех десятилетий. Первоначально он был стандартизирован в 1981 году посредством RFC 793. С годами он подвергался обновлениям и зарекомендовал себя как очень надежный транспортный протокол для поддержки роста интернет-трафика. Однако по своей сути TCP никогда не подходил для обработки передачи данных по беспроводной среде с потерями. В первые дни интернета проводные соединения были единственными существующими соединениями, связывающими каждый сетевой компьютер, так что это никогда не было проблемой.
Теперь, когда смартфонов и портативных устройств больше, чем настольных и портативных компьютеров, более 50% интернет-трафика передается по беспроводной сети. С этим ростом общий опыт просмотра веб-страниц ухудшился, поскольку время отклика увеличилось. Это вызвано несколькими факторами, наиболее важным из которых является блокировка линии, как описано здесь, когда беспроводное покрытие является неадекватным.
Первые тесты Google, предназначенные для решения HoL, показали, что внедрение QUIC в качестве базового транспортного протокола для некоторых популярных сервисов Google значительно улучшило скорость отклика и удобство работы пользователей. Развернув QUIC в качестве базового транспортного протокола для потоковой передачи видео на YouTube, Google сообщил о снижении скорости повторной буферизации на 30%, что напрямую влияет на качество просмотра видео. Аналогичные улучшения были замечены в отображении результатов поиска Google.
Эти преимущества были более заметны при работе в плохих сетевых условиях, что побудило Google более активно работать над усовершенствованием протокола, прежде чем в конечном итоге предложить его IETF для стандартизации.
Со всеми улучшениями, полученными в результате первых испытаний, QUIC играет важную роль в развитии интернета. Переход от HTTP/2 к HTTP/3 с поддержкой QUIC является логичным шагом в этом направлении.
Лучшие варианты использования HTTP/3
Целью внедрения HTTP/3 является улучшение работы в интернете, особенно в регионах, где высокоскоростной беспроводной доступ в интернет все еще недоступен. Несмотря на то, что HTTP/2 хорошо подходит для некоторых из этих случаев, HTTP/3 добавляет важные улучшения для следующих сценариях использования.
1. Интернет вещей (IoT)
HTTP не может быть предпочтительным протоколом для Интернета вещей из-за его ограничений, однако при этом есть сценарии, для которых HTTP хорошо подходит. Например, HTTP/3 может решить проблемы беспроводного соединения с потерями для мобильных устройств, которые собирают данные с подключенных датчиков. Это также относится к автономным устройствам IoT, установленным на транспортных средствах или движимых объектах. Поскольку HTTP/3 имеет надежный транспортный уровень, доступ к таким устройствам и с таких устройств через HTTP более надежен.
2. Микросервисы
В сети микросервисов много времени тратится на проход через все микросервисы, чтобы передать данные. HTTP всегда является самым медленным переходом. Следовательно, чем быстрее вы сможете выполнять каждый запрос между каждой системой — за тысячные доли секунды, а не за сотые — тем лучше результирующая изоляция данных и тем меньше будет количество реплицированных данных в вашей сети.
Сильной стороной QUIC является относительное отсутствие подтверждения установления связи, поэтому вы можете передавать эти запросы за однозначные миллисекунды, а ваши микросервисы могут быть относительно чистыми, что позволяет нести настоящую единоличную ответственность. Преимущество HTTP/3 здесь не столько в пропускной способности больших данных, сколько в ускорении каждого микровзаимодействия.
3. «Ставки» на рекламу в реальном времени
Когда реклама показывается в веб-браузерах, на нее делаются ставки в режиме реального времени. Информация о странице и пользователе отправляется на биржу объявлений, которая затем продает их с аукциона рекламодателю, предложившему самую высокую цену. Все компании, которые показывают рекламу потребителю, делают ставки. Это алгоритмическое соревнование за пространство, предоставляемое рекламной сетью.
Наличие соединения, для которого требуется только одно подтверждение установления связи, значительно повышает производительность торгов и позволяет загружать его более оперативно, гарантируя, что загрузка вашей страницы не будет задержана из-за шквала конкуренции. Более быстрая загрузка рекламы означает более быструю загрузку страницы.
4. Виртуальная реальность (VR)
С постоянно совершенствующимися возможностями браузера соответственно меняется пространство контента. Одной из таких областей изменений является виртуальная реальность на базе интернета. Несмотря на то, что все еще находится в зачаточном состоянии, существует множество ситуаций, когда виртуальная реальность играет ключевую роль в расширении сотрудничества. Сеть занимает центральное место в содействии такому взаимодействию с виртуальной реальностью. Приложения виртуальной реальности требуют большей пропускной способности для отображения сложных деталей виртуальной сцены и, скорее всего, выиграют от перехода на HTTP/3 на базе QUIC.
Начало работы с HTTP/3
Программные библиотеки, поддерживающие HTTP/3
Рабочая группа HTTP в IETF выпустила HTTP/3 в качестве официального стандарта в августе 2020 года. Поэтому он еще официально не поддерживается популярными веб-серверами, такими как NGINX и Apache. Однако для экспериментов с этим новым протоколом доступно несколько программных библиотек, а также доступны неофициальные патчи.
Вот список популярных программных библиотек, поддерживающих HTTP/3 и QUIC. Обратите внимание, что эти реализации основаны на одной из черновых версий стандарта в интернете, которая, вероятно, будет заменена более высокой версией, ведущей к окончательному стандарту, опубликованному в RFC.
1. quiche
quiche предоставляет низкоуровневый программный интерфейс для отправки и получения пакетов по протоколу QUIC. Он также поддерживает модуль HTTP/3 для отправки пакетов HTTP по реализации протокола QUIC. Кроме того, он предоставляет неофициальный патч для серверов NGINX для установки и размещения веб-сервера, поддерживающего HTTP/3, а также поддержку оболочки для мобильных приложений Android и iOS.
2. Aioquic
Aioquic — это питоническая реализация QUIC. Он также поддерживает встроенный тестовый сервер и клиентскую библиотеку для HTTP/3. Aioquic построен на основе модуля asyncio, который является стандартной структурой асинхронного ввода-вывода Python.
3. Neqo
Neqo — это реализация Mozilla QUIC и HTTP/3 с использованием Rust.
Если вы хотите поиграть с QUIC, ознакомьтесь с этими реализациями протокола QUIC с открытым исходным кодом, поддерживаемыми рабочей группой QUIC.
Различия в потоках и фреймах HTTP между HTTP/2 и HTTP/3
HTTP/3 исходит из того, что сходство с HTTP/2 предпочтительно, но не является жестким требованием. HTTP/3 отличается от HTTP/2 тем, что QUIC отличается от TCP либо тем, что использует преимущества функций QUIC (таких как потоки), либо тем, что в нем учитываются важные недостатки перехода на UDP (такие как отсутствие общего упорядочивания).
Отношение запросов и ответов в потоках в HTTP/3 аналогично HTTP/2. Однако детали реализации HTTP/3 существенно отличаются.
1. Потоки
HTTP/3 позволяет использовать большее количество потоков (2^62-1), чем HTTP/2. Соображения об исчерпании пространства идентификатора потока применимы, хотя пространство значительно больше, так что вполне вероятно, что сначала будут достигнуты другие ограничения в QUIC, такие как ограничение на окно управления потоком соединения.
В отличие от HTTP/2, параллелизмом потоков в HTTP/3 управляет QUIC. QUIC считает поток закрытым, когда все данные получены, а отправленные данные подтверждены узлом.
Из-за наличия других типов однонаправленных потоков HTTP/3 не полагается исключительно на количество одновременных однонаправленных потоков для управления количеством одновременных push-уведомлений. Вместо этого клиенты HTTP/3 используют фрейм MAX_PUSH_ID для управления количеством push-уведомлений, полученных от сервера HTTP/3.
2. Типы HTTP-фреймов
Многие концепции кадрирования из HTTP/2 можно игнорировать в QUIC, потому что с ними работает транспорт. Поскольку фреймы уже находятся в потоке, в них можно не указывать номер потока. Кроме того, фреймы не блокируют мультиплексирование (мультиплексирование QUIC происходит ниже этого уровня), поэтому поддержку пакетов с переменной максимальной длиной можно удалить. А поскольку завершение потока обрабатывается QUIC, флаг END_STREAM не требуется. Это позволяет удалить поле «Флаги» из общего макета фрейма.
Полезная нагрузка фрейма в HTTP/3 в основном взята из HTTP/2. Однако, поскольку QUIC включает многие функции HTTP/2 (например, управление потоком), HTTP/3 не реализует их заново. В результате в HTTP/3 не требуются несколько типов фреймов HTTP/2. Там, где фрейм, определенный HTTP/2, больше не используется, идентификатор фрейма резервируется, чтобы максимизировать переносимость между реализациями HTTP/2 и HTTP/3. Однако даже эквивалентные фреймы между двумя отображениями не идентичны.
Многие различия возникают из-за того, что HTTP/2 обеспечивает абсолютный порядок фреймов во всех потоках, тогда как QUIC обеспечивает эту гарантию только для каждого потока. В результате, если тип фрейма предполагает, что фреймы из разных потоков все равно будут получены в том порядке, в котором они были отправлены, HTTP/3 «разобьет» их.
HTTP/2 определяет назначение приоритетов в фреймах PRIORITY и (необязательно) в фреймах HEADERS. HTTP/3 не предоставляет средства сигнализации приоритета. Обратите внимание, что, хотя явной сигнализации для приоритета нет, о приоритизации все равно заботятся.
HPACK был разработан с учетом доставки-по-порядку. Последовательность закодированных участков поля должна прибыть (и быть декодирована) в конечную точку в том же порядке, в котором они были закодированы. Это гарантирует синхронизацию динамического состояния на двух конечных точках. QPACK является эквивалентом HPACK в HTTP/3 через QUIC.
Ограничения HTTP/3
Переход на HTTP/3 включает в себя не только изменение прикладного уровня, но и изменение нижележащего транспортного уровня. Следовательно, внедрение HTTP/3 немного сложнее по сравнению с его предшественником HTTP/2, который требовал только изменений на уровне приложений.
Транспортный уровень подвергается тщательной проверке промежуточными узлами в сети. Промежуточные устройства, такие как брандмауэры, прокси-серверы, устройства NAT, выполняют большую глубокую проверку пакетов для удовлетворения своих функциональных требований. В результате введение нового транспортного механизма имеет некоторые последствия для ИТ-инфраструктуры и операционных групп.
Службы безопасности часто строятся исходя из того, что трафик приложений (по большей части HTTP) будет передаваться по протоколу TCP, ориентированному на надежность и соединение из двух протоколов. Переход на UDP может оказать существенное влияние на способность инфраструктуры безопасности парсить и анализировать трафик приложений просто потому, что UDP является протоколом на основе дейтаграмм (пакетов) и может быть ненадежным.
Еще одна проблема с UDP заключается в том, что в настоящее время TCP является предпочтительным протоколом для большей части веб-трафика, а также для служб, определенных IETF. Политики фильтрации пакетов брандмауэров по умолчанию могут не одобрять длительные сеансы UDP с использованием HTTP/3.
Другой сценарий, в котором HTTP/3 может стать слишком громоздким для внедрения, — это ограниченные устройства IoT. Многие приложения интернета вещей используют устройства с низким форм-фактором с ограниченной оперативной памятью и мощностью ЦП. Это требование применяется для обеспечения эффективной работы устройств в ограниченных условиях, таких как заряд батареи, низкая скорость передачи данных и потеря связи.
Дополнительная обработка транспортного уровня HTTP/3 в форме QUIC поверх существующего UDP увеличивает площадь всего стека протоколов. Это делает HTTP/3 достаточно громоздким, чтобы не подходить для этих устройств IoT. Противоположным моментом является то, что таких ситуаций немного, и существуют специализированные протоколы, такие как MQTT, позволяющие обойти необходимость поддержки HTTP непосредственно на таких устройствах.
Вывод
HTTP/3 можно рассматривать как семантику HTTP, передаваемую через QUIC, транспортный протокол Google с шифрованием по умолчанию, который использует контроль перегрузки по UDP. Не все функции HTTP/2 можно сопоставить с QUIC. Для некоторых функций HTTP/2 требуются гарантии порядка, и хотя QUIC может предоставить такую гарантию в пределах одного потока, он не может предложить то же самое для разных потоков. Таким образом, потребовалась новая версия HTTP.
Две ключевые заявленные основные цели QUIC — разрешить блокировку заголовка строки на уровне пакетов и уменьшить задержку в HTTP-соединениях и трафике. QUIC также реализует управление потоком для каждого потока и идентификатор соединения, который сохраняется во время событий переключения сети. Использование UDP вместо TCP позволяет мультиплексировать и устанавливать облегченное соединение, улучшая работу конечных пользователей в сетях низкого качества, хотя и с некоторыми оговорками в отношении качества обслуживания в сетях высокого качества.
UDP-трафик часто может быть агрессивно ограничен по тайм-ауту на уровне промежуточного узла или обычно блокируется внутри организаций в качестве меры предосторожности против усиливающих атак. В таком случае у клиентов должна быть стратегия возврата к TCP.
Поддержка оборудования и ядра по-прежнему отсутствует. Например, процессоры несут основную тяжесть дополнительных обходов стека и передачи дейтаграмм между пользовательским пространством и пространством ядра.
С некоторыми изменениями IETF утвердила концепцию HTTP-over-QUIC и переименовала ее в HTTP/3, чтобы закрепить новый способ привязки семантики HTTP к сети, а также устранить неоднозначность концепции продолжающегося эксперимента QUIC в Google.
После положительных результатов экспериментов Google с QUIC в IETF продолжается работа по стандартизации. Однако по состоянию на июль 2020 года HTTP/3 все еще находится на стадии Internet-Draft (с несколькими реализациями) и еще не перешел на стадию RFC.
IETF завершает работу над стандартом. Все основные браузеры тестируют HTTP/3 посредством своих экспериментальных сборок. В настоящее время ни один браузер или сервер не предлагают официальную поддержку, и нет никаких гарантий, что он станет стандартом де-факто, несмотря на значительные инвестиции в ресурсы со стороны промышленности и официальных органов. Тем не менее, пока он проходит сертификацию, события в этой области, безусловно, заслуживают внимания.
Комментарии