System Design Space
Граф знанийНастройки

Обновлено: 24 марта 2026 г. в 11:23

HTTP протокол

medium

Базовый протокол веба: запрос‑ответ, ключевые свойства и эволюция до HTTP/2 и HTTP/3.

Глава про HTTP полезна тем, что показывает эволюцию веб-протокола как историю компромиссов между простотой, кэшированием, multiplexing и стоимостью соединений.

В реальной работе это помогает выбирать между HTTP/1.1, HTTP/2 и HTTP/3 по профилю трафика, учитывать idempotency и caching semantics и не путать уровень API с уровнем транспорта.

В интервью и design review материал полезен тем, что дает структурный язык для разговора о web-performance и protocol-level trade-offs, а не только об API-ручках.

Практическая польза главы

Протокол и продукт

Связывает свойства HTTP с UX-метриками: latency, повторные запросы, кэш и устойчивость API.

Version-aware design

Учит выбирать HTTP/1.1, HTTP/2, HTTP/3 по профилю трафика и сетевым ограничениям.

Performance tactics

Помогает применять keep-alive, compression, caching и multiplexing осознанно, а не шаблонно.

Interview articulation

Дает структурный ответ на вопросы про протокол-уровневые оптимизации web-систем.

RFC

RFC 9110 (HTTP Semantics)

Актуальная спецификация семантики HTTP: методы, статусы, заголовки и поведение кэша.

Перейти на сайт

HTTP - основной прикладной протокол веба и API-интеграций. Он задаёт контракт request-response между клиентами и сервисами, а выбор версий, кэша и retries напрямую влияет на latency, надёжность и стоимость.

Ключевые свойства HTTP

Клиент-серверная модель

Клиент инициирует HTTP-запрос, а сервер возвращает ответ с кодом статуса и телом.

Stateless взаимодействие

Каждый запрос обрабатывается независимо; состояние выносится в кэш, БД, токены и сессии.

Расширяемость заголовками

Headers управляют кешированием, контент-типами, авторизацией и политиками безопасности.

Промежуточные узлы

Прокси, CDN и gateways позволяют масштабировать доставку и снижать задержки.

Эволюция транспорта

HTTP/1.1, HTTP/2 и HTTP/3 меняют производительность, но сохраняют прикладную семантику.

Визуализация содержимого HTTP-сообщений

Независимо от версии протокола логика HTTP строится вокруг структуры request и response.

HTTP Request

Request line

METHOD /path HTTP/version

Headers

Host, Authorization, Content-Type, Cache-Control...

Empty line

Разделитель headers/body

Body (optional)

JSON/HTML/binary payload

HTTP Response

Status line

HTTP/version status-code reason

Headers

Content-Type, Cache-Control, ETag, Set-Cookie...

Empty line

Разделитель headers/body

Body (optional)

Ответ API, страница, файл, stream

Жизненный цикл HTTP-запроса

Подготовка запроса

Клиент резолвит DNS, выбирает endpoint, формирует method/path/headers и body.

Доставка и обработка

Запрос проходит через LB/proxy/gateway, обрабатывается сервисом и зависимостями.

Ответ и повторное использование

Клиент получает статус/данные, применяет кэш-политику и переиспользует соединение.

Как выглядит HTTP-обмен

Базовая схема request-response остаётся общей для REST API, edge gateway и большинства синхронных интеграций.

Запрос ↔ ответ в HTTP

HTTP — это чёткая пара: request от клиента и response от сервера.

Состав сообщения

  • Метод (GET, POST, PUT)
  • URI / путь ресурса
  • Headers
  • Тело (опционально)
КлиентСервер
Клиент
REQ
Сервер
Отправка запроса без сохранения состояния на сервере.

Динамика HTTP под нагрузкой

Пошагово смотрите, как cache hit, error rate и p95 latency меняются при росте трафика.

ШагИнтервал 1 (1 из 6)
p95 latency (ms)Error rate (%)Cache hit (%)

Фаза

Стабильная нагрузка

Нагрузка

2.4k RPS

p95 latency

85 ms

Error rate

0.2%

Cache hit

76.0%

Connection reuse

92.0%

Митигация: Базовый keep-alive

Что происходит: Кэш и переиспользование соединений удерживают задержку на низком уровне.

Расшифровка обозначений

  • RPS (requests per second) — число HTTP-запросов в секунду.
  • p95 — время ответа, ниже которого укладываются 95% запросов.

Что означают метрики

  • Connection reuse — доля запросов, выполненных по уже установленным соединениям.
  • Cache hit — доля ответов, отданных без обращения к медленным backend-операциям.

Связанная глава

Load Balancing

HTTP-трафик почти всегда проходит через L7/L4 балансировку и policy-слой.

Открыть главу

Как сеть и маршрутизация влияют на HTTP

Connection reuse и warm-up

Холодные соединения и лишние handshakes поднимают p95/p99 latency даже при быстром backend.

Cache hit ratio

Падение cache hit резко увеличивает давление на сервисы и error rate под пиковым трафиком.

Timeout/retry политика

Агрессивные retries без budget могут вызвать self-induced перегрузку и cascading failures.

L4/L7 балансировка

Роутинг через proxy/LB меняет latency profile и влияет на sticky behavior клиентов.

MTU, loss и protocol version

Потери и нестабильная сеть по-разному влияют на HTTP/2 и HTTP/3, особенно в mobile-сегменте.

Источник

Evolution of HTTP (MDN)

Ключевые вехи HTTP/1.1, HTTP/2 и HTTP/3 и их инженерные trade-off.

Перейти на сайт

Эволюция HTTP

Эволюция протокола была направлена на снижение задержек и улучшение устойчивости под высокой конкуренцией запросов.

HTTP/1.1

1997/1999

Текстовый протокол поверх TCP

Связь с OSI: OSI L7 поверх TCP (L4).

  • Persistent connections и chunked transfer
  • Ограничения с head-of-line на соединении
  • Часто нужно несколько соединений на клиент

HTTP/2

2015

Бинарное фреймирование и мультиплексирование

Связь с OSI: Та же HTTP-семантика L7, но более эффективная передача поверх TCP.

  • Multiplexing потоков в одном соединении
  • HPACK для сжатия заголовков
  • Снижение накладных расходов на установку соединений

HTTP/3

2022

HTTP поверх QUIC (UDP)

Связь с OSI: HTTP L7 на QUIC transport, меньше блокировок на потере пакетов.

  • Быстрый handshake и better recovery
  • Избежание TCP head-of-line в transport
  • Лучшее поведение в мобильных сетях

Где HTTP используется чаще всего

  • Публичные и внутренние API (REST/gRPC-web/proxy patterns)
  • Веб-приложения и SPA/SSR фронтенды
  • BFF и API Gateway слой для orchestration
  • Интеграция сервисов через synchronous request-response
  • Контроль доступа, observability и rate limiting на edge

Почему это важно для System Design

  • HTTP определяет API-контракты и напрямую влияет на latency, retries и стоимость обработки запросов.
  • Выбор версии протокола меняет profile нагрузки: соединения, multiplexing и поведение под потерями.
  • Грамотные cache/timeout/retry стратегии снижают blast radius инцидентов и защищают backend.
  • HTTP-метрики часто дают самый быстрый сигнал деградации пользовательского опыта.

Частые ошибки

Считать HTTP 'бесплатным' и не учитывать transport overhead, кэш и ретраи в capacity-планировании.

Использовать одинаковые timeout/retry параметры для всех endpoint-ов независимо от SLA и критичности.

Игнорировать cache semantics (ETag, Cache-Control), создавая лишнюю backend-нагрузку.

Смешивать 4xx и 5xx в одну метрику и терять сигнал о деградации серверной части.

Связанные главы

Чтобы отмечать прохождение, включи трекинг в Настройки