HTTP/2 и ALPN: одно соединение, много потоков, один режим отказа

Мультиплексирование: много потоков, одно соединение

Определяющее ограничение HTTP/1.1 — соединение несёт один запрос за раз. Чтобы загрузить страницу с 40 ассетами, браузер открывает до шести TCP-соединений на origin и шлёт запросы по ним последовательно, а медленный ответ блокирует по принципу head-of-line всё, что стоит за ним в очереди на этом соединении. HTTP/2 заменяет это мультиплексированием: одно TCP-соединение несёт множество независимых потоков (stream), каждый — чередующаяся последовательность бинарных кадров, помеченных ID потока. Запрос 7 и запрос 12 едут по одному сокету одновременно, их кадры DATA чередуются на проводе и пересобираются по ID потока на другом конце.

В Node основной модуль http2 даёт это напрямую. Соединение — это Http2Session; каждая пара запрос/ответ — Http2Stream.

import http2 from "node:http2";
import { readFileSync } from "node:fs";

const server = http2.createSecureServer({
  key: readFileSync("key.pem"),
  cert: readFileSync("cert.pem"),
  // ALPN: предлагаем h2 первым, откат на HTTP/1.1 для старых клиентов
  ALPNProtocols: ["h2", "http/1.1"],
});

server.on("stream", (stream, headers) => {
  // Каждый `stream` — один Http2Stream, мультиплексированный поверх общей сессии.
  stream.respond({ ":status": 200, "content-type": "text/plain" });
  stream.end("hello over " + stream.session.alpnProtocol);
});

server.listen(8443);

Событие stream срабатывает раз на запрос, и множество потоков принадлежат одной session. В этом вся модель мультиплексирования: сессия владеет TCP-сокетом и общим для соединения состоянием (управление потоком, SETTINGS), а каждый поток дёшев и независим на уровне HTTP.

Браузеры говорят только на h2 поверх TLS. h2c (HTTP/2 в открытом виде) есть в спецификации — устанавливается либо по prior knowledge (клиент просто предполагает, что сервер говорит на h2c), либо через HTTP/1.1-танец Upgrade: h2c, — но ни один браузер его не реализует, поэтому на практике он встречается лишь между доверенными бэкенд-сервисами или за прокси, терминирующим TLS. Для всего, к чему прикасается браузер, HTTP/2 означает h2, что означает TLS, что означает ALPN.

ALPN: согласование протокола внутри рукопожатия

Как клиент и сервер договариваются говорить на HTTP/2 до отправки хоть одного HTTP-байта? ALPN (Application-Layer Protocol Negotiation — согласование протокола прикладного уровня) — расширение TLS. Во время TLS ClientHello клиент анонсирует протоколы, на которых может говорить, упорядоченные по предпочтению, в расширении ALPN. Сервер выбирает один из этого списка и отражает его в ServerHello. К моменту завершения рукопожатия обе стороны уже знают, h2 это соединение или http/1.1 — ноль лишних round-trip, без запроса Upgrade.

В Node опция ALPNProtocols (и в createSecureServer, и в TLS-клиенте) — это упорядоченный список, который вы предлагаете. На сервере это обычно ["h2", "http/1.1"] — предпочитаем HTTP/2, откат на 1.1 для старых клиентов. Порядок важен: массив сообщает ваше предпочтение, и сервер http2 Node выбирает первую взаимно поддерживаемую запись. Прочитать согласованный результат можно из stream.session.alpnProtocol (или socket.alpnProtocol), чтобы подтвердить реально выбранное.

Управление потоком, SETTINGS и почему умер Server Push

Если мультиплексирование — главная фича, то flow control (управление потоком данных) — сантехника, не дающая ей разорваться изнутри, а Server Push — поучительная история о том, как идея звучала отлично и тихо всё ухудшила. Мультиплексированному соединению нужна координация, и HTTP/2 несёт её как управляющие кадры. При установлении каждая сторона шлёт кадр SETTINGS, объявляя лимиты — прежде всего SETTINGS_MAX_CONCURRENT_STREAMS (сколько потоков пир может открыть разом) и начальное окно управления потоком. Управление потоком (flow control) работает на каждый поток и на всё соединение: получатель анонсирует окно байтов, которое готов буферизовать, а кадры WINDOW_UPDATE пополняют его по мере потребления данных. Это не даёт одному быстрому потоку утопить медленного потребителя, но это и грабли — слишком маленькое окно душит пропускную способность на каналах с большим произведением полосы на задержку (классический случай высокой задержки, где HTTP/2 должен блистать). Node даёт это через опции сессии вроде settings: { maxConcurrentStreams } и peerMaxConcurrentStreams.

Server Push был флагманской фичей HTTP/2: сервер мог послать PUSH_PROMISE и проактивно отправить ресурсы (CSS, JS), которые, по его прогнозу, понадобятся клиенту, ещё до запроса. На практике это провалилось. Серверы пушили ассеты, которые уже были в кэше браузера, тратя полосу на тех самых нестабильных каналах, где байты дороже всего; push было трудно приоритизировать правильно, и он часто задерживал критичный HTML, который должен был ускорить. Cache-hit был удручающим. Chrome удалил поддержку Server Push (изменение приехало в Chrome 106, 2022), а замена — 103 Early Hints: информационный ответ, сообщающий браузеру, какие ресурсы стоит preload/preconnect, пока сервер ещё вычисляет настоящий ответ, оставляя клиенту решать, нужны ли они ему на самом деле.