Просто о том, чем отличаются HTTP1, HTTP2 и  HTTP3, а также почему HTTP3 ещё и QUIC. Статья для junior'ов, http-любознательных и готовящихся к собеседованиям. В интернете немало хороших статей по теме, однако, как правило, вопрос рассматривается глубоко, подробно, многословно, часто требует знаний по теме. Начинающим IT'шникам, без понимания вопроса и бэкграунда, бывает сложно ухватить суть улучшений, понять какие проблемы были решены и почему они стали актуальны. Постараюсь упрощённо и коротко раскрыть вопрос. По долгу службы проводил собеседования с соискателями разного уровня, нередко в попытках вытянуть junior'ов задаю вопросы про отличие разных версий протокола HTTP и ещё ни разу не слышал хорошего ответа. Точнее ни разу не слышал хоть какого-то осмысленного ответа, максимум "что-то про использование соединений и шифрование".  Кандидаты в мидлы и сениоры тоже умудряются ничего толком не знать в вопросе, и даже если могут перечислить отличия, часто не могут толком пояснить суть изменений.  Причина появления версий 2 и 3 - скорость.  Скорость загрузки страницы в браузере. Скорость установления соединения. Скорость обмена данными между сервером и страницей. Скорость обмена данными между сервисами/микросервисами.  Что мешает HTTP1 работать быстро, в порядке значимости: Блокировка соединения. Время на установление соединения. Объём обязательных данных. Удобно что 3я версия появилась ровно по тем же причинам что и вторая и запоминать 2 набора причин не нужно. Далее для  HTTP1 мы будем иметь ввиду версию 1.1 и соединение с шифрованием, тк  HTTP1.0 как и соединения без шифрования уже мягко говоря неактуальны. Head-of-Line Blocking или упростим до "блокировка соединения". Как происходит - у нас есть канал для передачи данных, мы отправили запрос в этот канал, ждём ответа, получили полностью ответ, отправили следующий запрос.  Представим что мы отправили запрос, а ответ требует долгих вычислений на стороне сервера - что произошло с нашим каналом? Он заблокирован. Мы должны дождаться ответа на отправленный запрос, перед тем как запросить новые данные — мы не можем дальше загружать страницу. Первая версия протокола http требовала дожидаться получения ответа перед отправлением следующего запроса в рамках одного соединения. Во второй версии протокола - это исправили, соединение может использоваться без ожидания завершения уже отправленного запроса.  Проблема блокировки была решена в версии 2 — но только на уровне http протокола. На транспортном уровне tcp она все еще есть в виде обязательного последовательного получения пакетов. Поэтому версию 3 собрали на протоколе udp, в которой этой особенности нет, и назвали это QUIC. Выполнение запросов HTTP1 Выполнение запросов HTTP2 Посмотреть самостоятельно можно тут - http://www.httpvshttps.com. Сайт образец, любезно созданный Let's Encrypt, для визуализации различий. Спасибо, что он есть. На видео порядок получения картинок для сайта. Линия - это одно соединение, серые засечки на линиях - это отправка запросов, зелёная полоска - это ожидание ответа, синяя - это получение контента.  На видео с версией 1 - чётко видна последовательность, отправка запроса, ожидание, получение данных. Чётко видно что все соединения практически синхронно блокируются и ждут. Причём линий у нас несколько, т.е. несколько соединений. Установление нескольких соединений - это первые попытки решить проблему блокировки для версии 1.  На видео с версией 2 - соединение одно и запросы(засечки) отправляются в него сразу пачками. Соединение практически не простаивает - нет "зелёного" ожидания. Загрузка страницы происходит быстрее, потому-что браузеру не надо ждать медленных ответов. Представьте что у нас сайт с генератором мемов с красивыми шрифтами. Пользователь выбирает картинку, вводит текст, выбирает 7 шрифтов в чекбоксах и нажимает кнопку submit, происходит перезагрузка страницы. На странице 7 картинок <img src='mymeme.jpg?text=hello&font=22', и браузер в процессе отрисовки страницы, отправляет во все доступные нам в http1 коннекты запрос на эти картинки. Сервер начинает генерить картинки, создает в памяти пустую картинку, накладывает фон, грузит шрифт ... 100500 действий ... проходит много врмени, отдает картинку браузеру. Что происходит в это время в браузере - ничего, в худшем случае белый лист, тк все соединения заняты долго генерящимися картинками и получить css, js, xhr, svg чтобы отрисовать страницу до конца мы не можем.В случае http2 мы отправляем запросы на долго генерящиеся мемы в соединение и не ждём, а отправляем запросы за другими данными, рисуем страницу и видим полностью готовую страницу с пустыми местами под мемы, которые лениво постепенно появляются. Дело в том что для того, чтобы передавать данные, клиенту и серверу надо договориться о том, как это будет происходить. Совершить своего рода рукопожатие - Handshake. То есть отправить некий вопрос и получить на него ответ, совершив полный "круг" обмена информацией. Если при этом нам надо получить данные от сервера, с которым не было установлено соединение, например флаг о наличии обновлений - цифру 1 или 0, то для простейшей операции нам надо совершить N "кругов" обмена информацией = количество рукопожатий + запрос. Для того чтобы установить шифрованное соединение и обменяться данными для http1 или http2 нам необходимо сделать от 2х до 3х рукопожатий. Одно рукопожатие для установления tcp соединения, 1 или 2 рукопожатия, в зависимости от версии протокола, для установления шифрованного соединения. Итого 2-3 рукопожатия.Так где же улучшение в версии 2?  Возвращаемся к визуализации для первой версии. У каждой линии (соединения) есть желтый участок - это установление соединения, включая рукопожатия. То есть на каждое соединение - отдельный набор рукопожатий. В версии 2 - соединение одно. http1 = кол-во соединений x кол-во рукопожатий / 1-6 x 2-3 = 2-18http2 = кол-во рукопожатий / 2-3  В третьей версии, поскольку собрали новый протокол QUIC, обо всём хорошо подумали и рукопожатия свели к одному. В один запрос упаковали установление соединения и установление шифрования. Плюс в версии 3 при разрыве соединения не нужно устанавливать новое, то есть не будет повторных рукопожатий, так как используется уникальный идентификатор соединения. http3/quic = const 1 Чтобы получить ответ из 1 символа, нам всё равно надо отправить HTTP заголовок в виде текста, в котором могут быть присоединены cookie, который может быть одинаковым для сотни запросов. Почему вопрос именно про заголовок? Потому-что - это не уникальные данные требующиеся для каждого запроса. В данном случае объединим версии 2 и 3. Для того, чтобы уменьшить объём по сравнению с первой версией, заголовки стали:  передавать в бинарном виде, а не текстом, как раньше - такой вид удобнее для машины и занимает меньше места; сжимать специальным алгоритмом, который позволяет не отправлять повторяющиеся части заголовка, заменяя их указателями на уже полученные ранее сервером такие же части. Всё указанное выше - это базовое описание изменений протокола http и причин этих изменений. Если читатель всё прекрасно понял и запомнил, есть смысл обратиться к более подробным статьям, которые потребуют прочтения ещё более подробных статей. Я знаю про flow-control, 0-rtt, server push и тд, но стоит ли этим загружать новичков?..  web-dev