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

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

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

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

Что такое HTTP/3

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

Первоначальное название — HTTP-over-QUIC. Главное отличие от предыдущих в — он использует новый транспортный протокол и передаёт контент быстрее.

Что такое QUIC

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

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

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

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

1. Отправитель посылает запрос — сообщение SYN, плюс порядковый номер переданного байта. 
2. Получатель отвечает сообщением SYN, подтверждает получение сообщением ACK и отправляет номер байта, который должен быть получен следующим. 
3. Отправитель подтверждает, что получил информацию, и посылает номер следующего ожидаемого байта. 

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

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

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

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

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

• Сокращает установку соединения. 
• Берёт от UDP высокую скорость, но контролирует целостность файлов. 
• Может передавать несколько файлов параллельно, что тоже ускоряет доставку.

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

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

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

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

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

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

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

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

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

Почему тогда ускоряется отдача контента?

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

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

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

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

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

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

Как HTTP/3 использует QUIC

Вторая версия использовал TCP на транспортном уровне и TLS на уровне безопасности.

В третьей их заменяет QUIC поверх UDP. 

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

Почему бы просто не встроить QUIC в HTTP/2?

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

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

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

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

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

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

Преимущества HTTP/3 над HTTP/2

Итак, главное преимущество в большей скорости:

• Быстрее устанавливается соединение. 
• Выше скорость передачи. 
• Лучше работает мультиплексирование.

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

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

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

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

Подробнее об этом читайте в нашей статье.

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

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

Проблема исчезает благодаря мультиплексированию.

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

Сложности, связанные с HTTP/3

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

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

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

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

1. Если клиент и сервер связываются в первый раз, они сначала устанавливают TCP-соединение. 
2. Но в первом HTTP-ответе сервер включает информацию, что он поддерживает QUIC. 
3. Если клиент тоже его поддерживает, он отправляет UDP-пакеты. 
4. Клиент запоминает, что поддерживает этот ресурс, и при следующих запросах будет использовать нужный вариант.

Да, первая связь, по сути, длится, как раньше. Но следующие будут значительно шустрее.

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

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

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

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

Когда интернет перейдёт на новый протокол

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

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

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

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

HTTP/3 в сервисах EdgeЦентр

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

Подведём итоги

1. HTTP/3 — готовящаяся к стандартизации версия HyperText Transfer Protocol. Её главное отличие — она использует QUIC и обеспечивает высокую скорость передачи. 
2. QUIC — транспортный протокол, работающий поверх UDP. Работает быстрее TCP, тратит меньше времени на установку соединения, но такой же надёжный. 
3. HTTP/3 использует QUIC на транспортном уровне и уровне безопасности, заменяя TCP и TLS. 
4. Ещё HTTP/3 имеет другой алгоритм сжатия заголовков и исключает некоторые функции (например, мультиплексирование). 
5. Протокол лучше реализовывает мультиплексирование. Если в предыдущем при потере TCP-пакета обмен сообщениями останавливался до восстановления пропажи, то в новом информация продолжает передаваться. 
6. В использовании стандарта пока есть сложности, связанные с определением типа протокола клиентом и сервером и блокировкой UDP-пакетов некоторыми брандмауэрами. Но проблемы решатся, когда веб перейдёт на новый стандарт. 
7.  Пока версия не стандартизована, но её уже поддерживают многие сервисы и браузеры, в том числе EdgeCDN в бета-режиме.