Когда речь заходит о версиях HTTP, обычно возникают такие мысли:

“В любом случае, веб — это всё HTTP, не так ли? Чем они так сильно отличаются, 1.1 и 2?”
“Разве не достаточно просто использовать новую версию HTTP/2?”

Итак, подводя итог:

  • HTTP/1.1 и HTTP/2 — это не «совершенно разные протоколы», а различия в способе более эффективной передачи одного и того же значения HTTP (методы/заголовки/статус-коды и т.д.).

  • На практике это не «выбор одного из двух», а обычная структура, где сервер поддерживает оба варианта, а клиент выбирает подходящий.

Давайте разберем основные моменты с точки зрения разработчика.

1. Краткое введение в HTTP/1.1

Commandbox 광고

1) Протокол на основе текста

HTTP/1.1 — это формат запроса/ответа, который мы обычно видим.

GET /index.html HTTP/1.1
Host: example.com
Connection: keep-alive

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

<html>...</html>

  • Текстовый формат позволяет легко осуществлять отладку,

  • даже инструменты такие как curl, telnet, nc помогут понять структуру запросов.

2) Устойчивое соединение + Пайплайн

Большая проблема HTTP/1.0 заключалась в открытии нового TCP соединения для каждого запроса,
в HTTP/1.1 по умолчанию установлено постоянное соединение (keep-alive),
что позволяет пересылать несколько запросов последовательно через одно соединение.

Кроме того, существовала функция HTTP pipelining:

  • отправка запросов подряд без ожидания ответов

  • получение ответов в порядке их отправки.

Тем не менее, это почти не использовалось в браузерах,
по-прежнему существует структура, требующая «последовательной обработки», что ведет к проблемам производительности.

3) Проблема HOL (Head-of-Line) Blocking

Основное узкое место HTTP/1.1 — это HOL Blocking (блокировка верхней линии).

  • Поскольку запросы обрабатываются последовательно в одном соединении,

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

  • Поэтому браузеры открывают несколько TCP соединений на домен (например, максимум 6), чтобы смягчить эту проблему.

Подводя итог:

HTTP/1.1 — это “создание нескольких трубопроводов для уменьшения узких мест”
(несколько TCP соединений).

2. В чем разница с HTTP/2?

Цель HTTP/2 ясна.

  • Снижение задержек (latency)

  • Более эффективное использование сетевых ресурсов

Ключевые слова:

  1. Двоевое кадрирование (Binary Framing)

  2. Мультиплексирование на основе потоков (Stream-based Multiplexing)

  3. Сжатие заголовков (HPACK)

  4. (Изначально) Серверный пуш (Server Push) – фактически мертва в браузерах

2-1. Текст → Двоевое кадрирование

HTTP/1.1 использует анализ текста по строкам, тогда как в HTTP/2 всё разбивается на кадры (frames), которые являются двоичными частями.

  • Заголовки — это кадры HEADERS

  • Тело — это кадры DATA

  • Эти кадры относятся к определенному ID потока.

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

2-2. Мультиплексирование (Multiplexing)

Это наиболее заметное отличие.

  • HTTP/1.1: обработка запросов и ответов последовательно в одном TCP соединении

  • HTTP/2: одновременная передача нескольких потоков в одном TCP соединении

То есть,

“Нет необходимости открывать несколько TCP соединений,
можно отправлять запросы и ответы одновременно в одном соединении”

Это позволяет:

  • в случае, когда одна HTML страница требует десятки или сотни ресурсов,

  • поддерживать одно соединение и одновременно их забирать

  • Это особенно полезно в мобильной среде и при высоком RTT.

Тем не менее, на уровне TCP все еще существует HOL Blocking, и эта проблема была улучшена в HTTP/3 (QUIC).

2-3. Сжатие заголовков (HPACK)

HTTP заголовки запросов/ответов имеют много дублирующихся данных.

  • Cookie, User-Agent, Accept-* и т.д.

  • Отправляемые размером до нескольких сотен килобайт на каждый запрос

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

  • Часто используемые заголовки регистрируются в таблице и пересылаются с короткими индексами

  • Только измененные части предыдущего запроса кодируются эффективно

Это особенно полезно в случаях с большим количеством запросов SPA / страниц с множеством ресурсов.

2-4. Серверный пуш (Server Push) фактически мертв

В начале HTTP/2 серверный пуш, который предоставляет CSS/JS до того, как клиент запрашивает их, считался большим преимуществом, но на практике:

  • высокая сложность реализации

  • проблемы с кэшированием/дублированием ресурсов

  • незначительное или даже ухудшающееся улучшение производительности

Таким образом, в Chromium по умолчанию отключен с 2022 года (Chrome для разработчиков)
также Firefox планирует убрать поддержку этого в 2024 году, и функция фактически мертва в экосистеме браузеров.

Таким образом, сейчас, когда мы говорим о HTTP/2, серверный пуш можно рассматривать лишь как “историческую функцию”.

3. HTTPS, ALPN и выбор “h2 vs http/1.1”

Commandbox 광고

На практике вопрос “использовать HTTP/1.1 или HTTP/2?”
автоматически согласовывается в процессе TLS Handshake между клиентом и сервером.

Эта задача выполняется расширением TLS, известным как ALPN (Application-Layer Protocol Negotiation).

  • Клиент: “Я понимаю как h2, так и http/1.1”

  • Сервер: “Тогда выберем h2” (или “Я поддерживаю только http/1.1”)

Пример настройки Apache:

Protocols h2 http/1.1

При такой настройке:

  • Современные браузеры, поддерживающие HTTP/2, автоматически используют HTTP/2 (h2)

  • Старые клиенты автоматически общаются через HTTP/1.1

Большинство крупных браузеров уже хорошо поддерживают HTTP/2,
и значительное число веб-сайтов активирует HTTP/2.

4. “В каких случаях их следует использовать отдельно?” – Обобщение с точки зрения разработчика

Разберем волнующий нас вопрос по случаям.

4-1. Общие веб-сервисы (для браузеров)

Ближайшая к правильному стратегии:

“Включить HTTPS + HTTP/2 в качестве основного,
HTTP/1.1 оставить как резервный вариант.”

  • Большинство веб-серверов (Nginx, Apache, Envoy и др.)
    автоматически согласуют поддержку HTTP/2 просто включив соответствующую опцию.

  • Реже бывает необходимость выбирать на уровне приложения, “это отправить через 1.1, а то — через 2”.

Таким образом, если вы создаете новый сервис, то стоит считать ‘HTTPS с включенным HTTP/2’ базовым вариантом.

4-2. Внутренние API / связи микросервисов

Здесь у вас есть немного больше выбора.

  • Если уже REST + HTTP/1.1 работает хорошо,
    то нет необходимости переписывать на HTTP/2.

  • Тем не менее,

    • если вы передаете очень много коротких запросов между одними и теми же сервисами

    • или используете протоколы на основе HTTP/2 как gRPC,
      → использование HTTP/2 будет естественным.

Таким образом,

  • “Существующие наследуемые REST API” → удержание 1.1 с возможностью интеграции HTTP/2 на прокси/балансировщиках нагрузки.

  • “При добавлении нового gRPC, высокочастотные вызовы микросервисов” → активное использование HTTP/2.

4-3. Отладка, ведение логов, наследуемые среды

HTTP/1.1 все еще полезен в некоторых ситуациях.

  • Поскольку это текстовый формат, его легко просматривать в tcpdump, Wireshark

  • Старые прокси, фаерволлы или клиенты могут не поддерживать HTTP/2

  • В простых внутренних инструментах, тестовых серверах нет необходимости использовать HTTP/2

На самом деле, во многих средах:

  • Внешние (браузер) ↔ фронтальный прокси (CDN/Load Balancer): HTTP/2

  • Прокси ↔ бэкенд-сервисы: HTTP/1.1

Часто комбинируются различные структуры.

5. Осмысленный ответ на вопрос “Нельзя ли использовать только HTTP/2?”

Теоретически:

“Если вы создаете новый публичный веб-сервис, вы можете считать HTTP/2 основным вариантом.”

Это правильно.

Но на практике:

  1. Полностью избавиться от HTTP/1.1 сложно

    • Старые клиенты или специфические среды все еще могут поддерживать только 1.1

    • Для отладки/инструментов/внутренних систем 1.1 часто более удобен

  2. С точки зрения сервера, «поддержка обоих протоколов» является обычной практикой

    • Серверные настройки включают h2 http/1.1,

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

  4. Эпоха, когда стоит рассматривать HTTP/3 (QUIC)

    • Современные браузеры уже поддерживают HTTP/3

    • Но его также обычно используют совместно с “HTTP/1.1 + HTTP/2 + HTTP/3”
      и оставляют клиенту возможность согласовать выбор.

Поэтому реалистичный вывод:

“Лучше включить HTTP/2 как основной,
а HTTP/1.1 оставить как естественный резервный вариант.”

Это так.

Сравнение способов передачи по версиям http

6. Краткое резюме

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

  • HTTP/1.1

    • Текстовый формат

    • Устойчивое соединение + (теоретическое) мультиплексирование

    • Из-за проблемы HOL Blocking браузеры использовали несколько TCP соединений

  • HTTP/2

    • Двоевое кадрирование

    • Мультиплексирование для нескольких потоков через одно TCP соединение

    • Сжатие заголовков HPACK

    • Серверный пуш фактически мертв

  • Стратегия использования

    • Внешние веб-сервисы (для браузеров): Включить HTTPS + HTTP/2, оставить HTTP/1.1 как резервный

    • Внутренние API: для существующего REST сохранить 1.1, для высокочастотных/стриминговых/gRPC использовать HTTP/2 побыстрее.

    • Отладка/наследственные системы: HTTP/1.1 все еще полезен и актуален.

Хорошая запоминающаяся строка для разработчиков:

“Не тратьте время на выбор версий в коде приложения,
просто включите HTTP/2 на сервере и оставьте остальное для протокольного согласования (ALPN).”