HTTP/3 и QUIC: будущее интернета

Как новые протоколы изменят доставку контента.

На момент этой публикации последняя стандартизированная версия протокола HTTP — HTTP/2. Но уже очень скоро будет официально выпущена его замена — HTTP/3, протокол, работающий через QUIC, более быстрый и безопасный. Многие браузеры и IT-сервисы уже его поддерживают.

Мы в EdgeЦентр тоже уже запустили поддержку нового протокола на нашей CDN в режиме бета-тестирования. Новый протокол позволит доставлять контент наших клиентов ещё быстрее.

Давайте разбираться, что такое HTTP/3 и QUIC, и как он помогает ускорять доставку контента.

Содержание:

HTTP/3 — готовящаяся к стандартизации версия протокола HTTP (HyperText Transfer Protocol). Напомним, что HTTP — это протокол прикладного уровня, основной протокол передачи данных в интернете, используется для получения данных с веб-ресурсов.

Первоначальное название HTTP/3 — HTTP-over-QUIC. И главное его отличие от предыдущих версий в том, что он использует новый транспортный протокол QUIC, и за счёт этого передаёт данные быстрее.

QUIC (Quick UDP Internet Connection) — транспортный протокол, основанный на UDP. Был разработан Google в 2012 году.

Чтобы лучше понять, что такое QUIC, давайте сначала поговорим о двух других транспортных протоколах — TCP и UDP.

Во всех предыдущих версиях HTTP на транспортном уровне использовался TCP. Он считается более надёжным, потому что проверяет получение информации. На каждый полученный пакет принимающая сторона должна послать отправителю сообщение с подтверждением. Если через определённое время подтверждение на какой-то пакет не пришло, он отправляется повторно.

Для установки TCP-соединения требуется «тройное рукопожатие».

1. Отправитель посылает запрос на установку соединения — сообщение SYN и порядковый номер переданного байта.

2. Получатель отвечает сообщением SYN, подтверждает получение данных сообщением ACK и отправляет номер байта, который должен быть получен следующим.

3. Отправитель тоже подтверждает, что получил информацию, и посылает номер следующего ожидаемого байта.

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

UDP отличается от TCP тем, что не проверяет правильный порядок и целостность пакетов. Он просто отправляет данные и не требует подтверждать их получение. За счёт этого информация передаётся быстрее, чем по TCP.

Никакой установки соединения UDP не требует. Пакеты передаются сразу, что тоже ускоряет процесс.

Вот поэтому UDP считается более быстрым. Но всё это ведёт к проблемам с надёжностью. Часть пакетов при передаче может потеряться, и нет никакого механизма восстановления.

QUIC решает проблемы обоих протоколов:

Давайте разберём его основные особенности.

Быстрая установка соединения

Мы уже рассказали про «тройное рукопожатие» в TCP. К этому надо добавить, что многие сайты работают через HTTPS. Это значит, что поверх TCP-соединения надо установить ещё и TLS-соединение для безопасной передачи данных.

И для этого клиенту и серверу надо обменяться ещё большим количеством сообщений.

Подробнее об установке TLS-соединения читайте в статье «Как TLS 1.3 стал новым стандартом безопасности передачи данных».

Всё это значительно замедляет процесс доставки данных.

QUIC включает в себя TLS 1.3, обеспечивает безопасное зашифрованное соединение, но при этом не требует такого количества «рукопожатий».

Зашифрованное соединение устанавливается сразу. «Рукопожатие» проходит за 3 шага. А если это повторное соединение, то первые данные отправляются одновременно с «рукопожатием».

Всё это позволяет QUIC передавать данные в несколько раз быстрее TCP и при этом обеспечивать высокий уровень безопасности.

Быстрая доставка и контроль за целостностью пакетов

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

За счёт чего тогда данные передаются быстрее?

Переключение сессий

В QUIC нет привязки к конкретному IP.

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

Если пользователь подключается к ресурсу через Wi-Fi, а потом переходит на мобильную сеть, у него меняется IP, и соединение нужно устанавливать заново.

С QUIC такой проблемы нет. В этом протоколе вместо адресов и портов используется идентификатор соединения — Connection UUID. И он не меняется при переходе от Wi-Fi на мобильную сеть. А значит, соединение остаётся, и ничего не нужно открывать заново.

Кроме того, если QUIC может очень легко перейти от Wi-Fi к мобильному интернету, то в теории он может использовать их оба. В передаче данных будет задействовано 2 канала, и пакеты дойдут быстрее.

HTTP/2 использовал TCP на транспортном уровне и TLS на уровне безопасности.

В HTTP/3 эти протоколы заменяет QUIC поверх UDP.

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

Если главное отличие HTTP/3 от HTTP/2 в том, что он использует QUIC, возникает вопрос, а зачем вообще надо было разрабатывать новый протокол, и почему бы просто не использовать HTTP/2 поверх QUIC.

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

1. Сжатие заголовков. В HTTP/2 для этой функции используется алгоритм HPAC. Его работа зависит от порядка доставки запросов получателю.

TCP гарантирует строгий порядок. А вот в QUIC он часто нарушается. И HPAC в этом случае просто не может работать правильно.

Для сжатия заголовков разработали новый алгоритм — QPAC. И он потребовал изменений в HTTP.

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

Итак, главное преимущество HTTP/3 над HTTP/2 в том, что он быстрее за счёт использования QUIC:

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

Какая проблема была у HTTP/2

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

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

Подробнее об этом читайте в нашей статье «Что такое HTTP/2, и как он помогает ускорять сайты».

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

Как HTTP/3 решает эту проблему

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

Потеря элемента прерывает передачу только одного потока. А все остальные типы файлов продолжают передаваться без изменений. И клиент продолжает получать запрошенные данные.

Определение версии

Все версии HTTP до этого использовали TCP. Плюс, было довольно длинное «рукопожатие», во время которого клиент и сервер определяли, как они должны взаимодействовать дальше.

В HTTP/3 клиент и сервер обмениваются UDP-пакетами. Но чтобы начать передачу данных, им нужно понять, какой протокол поддерживает другая сторона, и какие пакеты нужно отправлять.

Проблема решается следующим образом:

1. Если клиент и сервер связываются в первый раз, они сначала устанавливают TCP-соединение.

2. Но в первом HTTP-ответе сервер включает информацию, что он поддерживает QUIC и HTTP/3.

3. Если клиент тоже их поддерживает, он переходит на HTTP/3 и отправляет UDP-пакеты.

4. Клиент запоминает, что этот ресурс поддерживает HTTP/3, и при следующих запросах будет использовать этот протокол.

Да, первое соединение, по сути, занимает столько же времени, сколько и в HTTP/2. Но зато следующие соединения будут значительно быстрее.

Плюс, такая мера необходима, пока интернет ещё не перешёл на HTTP/3. И в будущем всё будет быстрее.

Блокировка UDP-пакетов

Так как UDP считается небезопасным протоколом, многие брандмауэры его блокируют. И первое время могут возникать проблемы с тем, как правильно настроить файрволы, чтобы они не блокировали HTTP/3-запросы.

Но скорее всего, к тому времени, как интернет полностью перейдёт на HTTP/3, проблема будет решена, и большинство брандмауэров будет перенастроено.

На момент написания материала HTTP/3 ещё не стандартизирован. Но это вот-вот произойдёт.

Сервисы Google, Facebook (запрещён в России, компания Meta признана экстремистской) и Twitter активно использовали новую версию уже в 2021 году.

NGINX объявил о поддержке HTTP/3 летом 2021 года.

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

Мы уже поддерживаем HTTP/3 на нашей CDN в режиме бета-тестирования. Некоторые наши клиенты уже попробовали и оценили все преимущества быстрой доставки с новым протоколом.