Просто о том, чем отличаются HTTP1, HTTP2 и HTTP3, а также почему HTTP3 ещё и QUIC. Статья для junior'ов, http-любознательных и готовящихся к собеседованиям.

В интернете немало хороших статей по теме, однако, как правило, вопрос рассматривается глубоко, подробно, многословно, часто требует знаний по теме. Начинающим IT'шникам, без понимания вопроса и бэкграунда, бывает сложно ухватить суть улучшений, понять какие проблемы были решены и почему они стали актуальны. Постараюсь упрощённо и коротко раскрыть вопрос.

Главное

Причина появления версий 2 и 3 - скорость.

Скорость загрузки страницы в браузере. Скорость установления соединения. Скорость обмена данными между сервером и страницей. Скорость обмена данными между сервисами/микросервисами.

Что мешает HTTP1 работать быстро, в порядке значимости:

• Блокировка соединения.

• Время на установление соединения.

• Объём обязательных данных.

Удобно что 3я версия появилась ровно по тем же причинам что и вторая и запоминать 2 набора причин не нужно.

Далее для HTTP1 мы будем иметь ввиду версию 1.1 и соединение с шифрованием, тк HTTP1.0 как и соединения без шифрования уже мягко говоря неактуальны.

Блокировка соединения

Head-of-Line Blocking или упростим до "блокировка соединения". Как происходит - у нас есть канал для передачи данных, мы отправили запрос в этот канал, ждём ответа, получили полностью ответ, отправили следующий запрос.

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

HTTP1 -> HTTP2

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

HTTP2 -> HTTP3/QUIC

Проблема блокировки была решена в версии 2 — но только на уровне http протокола. На транспортном уровне tcp она все еще есть в виде обязательного последовательного получения пакетов. Поэтому версию 3 собрали на протоколе udp, в которой этой особенности нет, и назвали это QUIC.

Визуализация

Выполнение запросов HTTP1

Выполнение запросов HTTP2

На видео порядок получения картинок для сайта. Линия - это одно соединение, серые засечки на линиях - это отправка запросов, зелёная полоска - это ожидание ответа, синяя - это получение контента.

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

На видео с версией 2 - соединение одно и запросы(засечки) отправляются в него сразу пачками. Соединение практически не простаивает - нет "зелёного" ожидания. Загрузка страницы происходит быстрее, потому-что браузеру не надо ждать медленных ответов.

Время на установление соединения

Дело в том что для того, чтобы передавать данные, клиенту и серверу надо договориться о том, как это будет происходить. Совершить своего рода рукопожатие - Handshake. То есть отправить некий вопрос и получить на него ответ, совершив полный "круг" обмена информацией.

Если при этом нам надо получить данные от сервера, с которым не было установлено соединение, например флаг о наличии обновлений - цифру 1 или 0, то для простейшей операции нам надо совершить N "кругов" обмена информацией = количество рукопожатий + запрос.

HTTP1 -> HTTP2

Для того чтобы установить шифрованное соединение и обменяться данными для http1 или http2 нам необходимо сделать от 2х до 3х рукопожатий. Одно рукопожатие для установления tcp соединения, 1 или 2 рукопожатия, в зависимости от версии протокола, для установления шифрованного соединения. Итого 2-3 рукопожатия.
Так где же улучшение в версии 2?

Возвращаемся к визуализации для первой версии. У каждой линии (соединения) есть желтый участок - это установление соединения, включая рукопожатия. То есть на каждое соединение - отдельный набор рукопожатий. В версии 2 - соединение одно.

http1 = кол-во соединений x кол-во рукопожатий / 1-6 x 2-3 = 2-18
http2 = кол-во рукопожатий / 2-3

HTTP2 -> HTTP3/QUIC

В третьей версии, поскольку собрали новый протокол QUIC, обо всём хорошо подумали и рукопожатия свели к одному. В один запрос упаковали установление соединения и установление шифрования.

Плюс в версии 3 при разрыве соединения не нужно устанавливать новое, то есть не будет повторных рукопожатий, так как используется уникальный идентификатор соединения.

http3/quic = const 1

Объём обязательных данных

Чтобы получить ответ из 1 символа, нам всё равно надо отправить HTTP заголовок в виде текста, в котором могут быть присоединены cookie, который может быть одинаковым для сотни запросов. Почему вопрос именно про заголовок? Потому-что - это не уникальные данные требующиеся для каждого запроса.

В данном случае объединим версии 2 и 3.

HTTP1 -> HTTP2 и HTTP3/QUIC

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

• передавать в бинарном виде, а не текстом, как раньше - такой вид удобнее для машины и занимает меньше места;

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

Заключение

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