Connection management и Keep-Alive

Connection management и Keep-Alive

Каждый HTTP-запрос требует TCP-соединения. Трёхстороннее рукопожатие, передача данных, завершение — всё это занимает время. Как сделать это эффективно? Ответ — управление соединениями и Keep-Alive.

Проблема: дорогие TCP-соединения

Без оптимизаций каждая загрузка ресурса требует нового TCP-соединения. Для страницы с 50 ресурсами (HTML, CSS, JS, картинки, шрифты) нужно 50 трёхсторонних рукопожатий, 50 медленных стартов TCP и 50 закрытий. Это медленно и расточительно.

Keep-Alive: reuse соединения

HTTP/1.0 закрывал TCP-соединение после каждого запроса. HTTP/1.1 (1997) ввёл Keep-Alive: по умолчанию соединение не закрывается после ответа, а ждёт следующего запроса от того же клиента:

TCP-соединение открыто
  → GET /page.html    → ответ
  → GET /style.css    → ответ
  → GET /logo.png     → ответ
  ... (ещё 47 запросов)
TCP-соединение закрыто (по таймауту или заголовку Connection: close)

Заголовок Connection: keep-alive держит соединение открытым. Connection: close — просит закрыть.

Keep-Alive — не панацея

Keep-Alive экономит рукопожатия, но не решает проблему head-of-line blocking (HOL blocking): запросы выполняются последовательно. Пока сервер обрабатывает первый запрос, второй и третий ждут в очереди. Медленный запрос к /slow-api блокирует весь поток.

Это ограничение HTTP/1.1. Для обхода браузеры открывают несколько TCP-соединений к одному серверу (обычно 6). Но каждое соединение всё ещё последовательное внутри себя.

HTTP/2: мультиплексирование

HTTP/2 (2015) решает HOL blocking через мультиплексирование: в одном TCP-соединении можно одновременно передавать множество запросов и ответов. Они мультиплексируются в «потоки» (streams):

Одно TCP-соединение:
  Stream 1: GET /page.html   → [обработка] → ответ
  Stream 2: GET /style.css   → [обработка] → ответ
  Stream 3: GET /logo.png    → [обработка] → ответ
  Все три выполняются параллельно, ответы приходят по мере готовности

Это радикально ускоряет загрузку страниц и снижает потребление ресурсов (одно соединение вместо шести). HTTP/2 также использует бинарный формат (вместо текстового) и сжимает заголовки.

HTTP/3 и QUIC

У HTTP/2 есть свой HOL blocking на уровне TCP: если TCP-пакет потерялся, все потоки ждут его повторной отправки. HTTP/3 решает это переходом на QUIC (поверх UDP вместо TCP):

• Каждый поток независим: потеря пакета в одном потоке не затрагивает остальные.
• Рукопожатие быстрее (0-RTT для повторных соединений).
• Смена сети (Wi-Fi → мобильный) не разрывает соединение.

HTTP/3 уже используют Google, YouTube, Facebook и другие крупные платформы. По состоянию на 2026 год около 30% сайтов поддерживают HTTP/3.

Итоговая таблица версий HTTP

Проверь себя

1. Что такое head-of-line blocking в HTTP/1.1?
2. В чём главное преимущество HTTP/3 перед HTTP/2?
3. Зачем браузеры открывают 6 TCP-соединений в HTTP/1.1?

1. Запросы в одном TCP-соединении HTTP/1.1 выполняются последовательно. Медленный запрос блокирует все последующие в очереди.
2. HTTP/3 использует QUIC (UDP), где потеря пакета в одном потоке не блокирует остальные. В HTTP/2 (TCP) потеря пакета останавливает все потоки.
3. Чтобы обойти HOL blocking: 6 параллельных соединений позволяют одновременно выполнять 6 запросов. Но это создаёт накладные расходы на 6 рукопожатий и 6 стеков TCP.

Что унести с урока

• Keep-Alive (HTTP/1.1) повторно использует TCP-соединение для нескольких запросов.
• HTTP/2 мультиплексирует запросы в одном соединении — параллельная обработка.
• HTTP/3 на QUIC (UDP) убирает TCP-уровневый HOL blocking и ускоряет рукопожатие.
• Эволюция HTTP — это непрерывная борьба за снижение задержек.

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