Сети и протоколы
HTTP: язык запрос-ответ в вебе
TLS запечатал канал. TCP пронумеровал байты. Теперь протокол сверху: HTTP — язык, которым браузеры и серверы говорят, чтобы запрашивать и получать веб-страницы, API, картинки, шрифты и скрипты. Тридцать лет HTTP/1.1 обрабатывал почти весь трафик. Потом браузеры захотели большего.
Что делает HTTP одним предложением
HTTP (HyperText Transfer Protocol) — это язык запрос-ответ, которым браузеры и серверы обмениваются веб-страницами, API, картинками — всем что видно в браузере. Клиент спрашивает, сервер отвечает. Но как именно они спрашивают и отвечают — вот где версии расходятся.
Метафора ресторана
Представьте HTTP как официанта принимающего заказы.
HTTP/1.1: один официант на стол, один заказ за раз — ждёте каждое блюдо до следующего заказа. Ресторан нанимает шесть официантов на клиента (шесть параллельных соединений). Работает, но расточительно.
HTTP/2: один официант берёт десять заказов сразу и приносит блюда в том порядке, в каком кухня успевает. Одно соединение, много запросов в полёте одновременно.
HTTP/3: то же что /2, но задержавшееся блюдо больше не задерживает остальные — они выходят независимо. Построен на другом транспорте (QUIC поверх UDP), который изолирует задержки на уровне потока.
- HTTP/1.1 параллельных TCP-соединений на origin
- 6–8
- HTTP/2 потоков на соединение
- ≥100 (по умолчанию RFC)
- HTTP/3 в трафике (апрель 2026, Cloudflare Radar)
- 21.1% веб-трафика
- HTTP/2 поддержка сайтов
- >95% веба
- Прогрев соединения (HTTP/3 с resumption)
- 0 RTT для запроса
- Экономия заголовков HPACK (в среднем)
- ~80–90% после первого запроса
Один сценарий от начала до конца
Вы заходите на сайт. Браузер делает DNS, TCP, TLS, затем первый HTTP-запрос. HTML страницы называет десятки файлов; браузер отправляет запросы используя HTTP-версию, согласованную сервером через ALPN (Application Layer Protocol Negotiation — расширение TLS, позволяющее клиенту и серверу выбрать h2, h3 или http/1.1 в процессе хендшейка). Современные сайты получают HTTP/2 или HTTP/3; старые origin — HTTP/1.1.
Антон браузер серверу Дима : «GET /index.html». Sven отвечает HTML. Bea видит <script src="app.js"> и сразу говорит: «GET /app.js». В HTTP/1.1 Bea ждёт каждый файл на одном соединении. В HTTP/2 и /3 Bea стреляет все GET сразу, и Sven отдаёт их перемежая потоки.
Главный враг: HOL-блокировка
Блокировка начала очереди (HOL, Head-of-Line Blocking) — паттерн, при котором медленный элемент в начале очереди тормозит всё за ним. В HTTP/1.1 блокировка на уровне запроса: каждое соединение несёт только один запрос-ответ за раз. HTTP/2 устранил HOL на HTTP-уровне через мультиплексирование потоков, но TCP снизу по-прежнему имеет HOL на транспортном уровне. HTTP/3 исправил оба слоя, используя QUIC с восстановлением потерь на уровне потока.
Почему это работает
Почему не просто открыть больше соединений? Обходной путь HTTP/1.1 с шестью параллельными TCP-соединениями стоит шести отдельных хендшейков (каждый 1–2 RTT), шести окон перегрузки с нуля (TCP slow start) и серверных состояний для всех шести. На линии с RTT 100 мс эти шесть холодных стартов обходятся по 100–200 мс каждый. Одно соединение HTTP/2 платит эту цену один раз.
Главная причина медлительности HTTP/1.1 для современных веб-страниц?
Главная победа HTTP/3 над HTTP/2?
Расставьте HTTP-версии хронологически:
- 1 HTTP/1.0 — один запрос на соединение, без keep-alive
- 2 HTTP/1.1 — keep-alive, pipelining (редко работал на практике)
- 3 HTTP/2 — мультиплексирование потоков на одном TCP + HPACK
- 4 HTTP/3 — та же форма но поверх QUIC (UDP) — потеря пакета per-stream
Заполните пропуск: HTTP — это формат _______, которым браузеры и серверы обмениваются веб-контентом.
- 01Одним предложением: зачем изобрели HTTP/2 и HTTP/3, если HTTP/1.1 уже работал?
- 02Что такое ALPN и когда он работает?
- 03Почему HTTP/2 по-прежнему страдает от HOL-блокировки, хотя мультиплексирует потоки?
HTTP — протокол запрос-ответ, которым браузеры и серверы обмениваются страницами, API и ресурсами. HTTP/1.1 параллелизируется через 6–8 TCP-соединений на origin — каждое соединение обрабатывает один запрос за раз. HTTP/2 ввёл мультиплексирование потоков на одном TCP-соединении, устранив HOL-блокировку на уровне приложения, но упорядоченная доставка TCP по-прежнему вызывает HOL на транспортном уровне при потере пакетов. HTTP/3 переходит на QUIC поверх UDP, давая каждому потоку независимое восстановление потерь. Все три версии сосуществуют: ALPN договаривается о выборе во время TLS-хендшейка на каждом соединении.
встречается в5
- MVCC: как Postgres раздаёт согласованные снимкиjunior
- Акт 7 в глубину: шардинг, co-location и семиуровневый каскад трейдоффовmiddle
- Наблюдаемость, антипаттерны и производственный триажsenior
- Raft в реальном мире: partition, медленный диск и клиентская маршрутизацияmiddle
- Raft в production: membership change, Multi-Raft и observabilitysenior