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

Обновлено: 21 апреля 2026 г. в 16:55

Протокол HTTP

средний

Модель запрос-ответ, структура HTTP-сообщения, эволюция HTTP/1.1, HTTP/2 и HTTP/3 и влияние сети на поведение веб-запросов.

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

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

В интервью и архитектурных обсуждениях материал даёт структурный язык для разговора о производительности веб-систем и протокольных компромиссах, а не только об API-ручках.

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

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

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

Версионно-ориентированный дизайн

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

Тактики производительности

Помогает осознанно применять постоянные соединения, сжатие, кэширование и мультиплексирование.

Аргументация на интервью

Даёт структурный ответ на вопросы о протокольных оптимизациях веб-систем.

RFC

RFC 9110 (HTTP Semantics)

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

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

Протокол HTTP важен не только как язык веба, но и как договор о том, как клиент просит данные, а сервис отвечает. От выбора версии, кэширования и политики повторных попыток напрямую зависят задержка, устойчивость и цена каждого запроса.

В системном дизайне важен как основная форма между клиентом и сервисом. Он по своей природе , поэтому надёжность приходится собирать из кэша, токенов, баз данных и прикладной логики.

На поведение запроса влияют , , , и выбранная стратегия и . От них зависят , и фактическая стоимость обработки.

Под ростом трафика быстро проявляются , доля ответов из кэша () и . Одновременно путь запроса обычно проходит через , или , а значит выбор между HTTP/1.1, HTTP/2 и HTTP/3 напрямую связан с сетью и профилем нагрузки.

Ниже эта глава связывает поведение протокола HTTP с , , , , , и целевыми показателями .

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

Клиент-серверное взаимодействие

Клиент отправляет HTTP-запрос, а сервер отвечает кодом статуса, заголовками и при необходимости телом.

Работа без сохранения состояния

Каждый запрос обрабатывается отдельно, поэтому состояние выносится в кэш, базу данных, токены и сессии.

Управление заголовками

Заголовки задают кэширование, тип содержимого, авторизацию и правила безопасности.

Промежуточные звенья

Прокси, сети доставки контента и шлюзы API помогают масштабировать доставку, защищать сервисы и снижать задержки.

Эволюция версий

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

Как устроено HTTP-сообщение

Независимо от версии, протокол HTTP сохраняет одну базовую форму: строку запроса или статуса, набор заголовков, пустую строку и тело, если оно вообще нужно.

HTTP-запрос

Строка запроса

METHOD /path HTTP/version

Заголовки

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

Пустая строка

Разделяет заголовки и тело

Тело (необязательно)

JSON, HTML или двоичные данные

HTTP-ответ

Строка статуса

HTTP/version status-code reason

Заголовки

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

Пустая строка

Разделяет заголовки и тело

Тело (необязательно)

Ответ API, HTML-страница, файл или поток данных

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

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

Клиент разрешает имя через DNS, выбирает конечную точку и формирует метод, путь, заголовки и при необходимости тело.

Прохождение по пути

Запрос проходит через балансировщик, прокси или шлюз API, а затем попадает в сервис и его зависимости.

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

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

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

Базовая схема полезна для REST API, пограничных шлюзов и большинства синхронных интеграций, где клиент ждёт понятный ответ на конкретный запрос.

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

Протокол HTTP строится вокруг понятной пары: запрос от клиента и ответ от сервера.

Структура сообщения

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

Как HTTP ведёт себя под нагрузкой

Пошагово видно, как доля ответов из кэша, уровень ошибок и p95 меняются при росте трафика.

ШагИнтервал 1 (1 из 6)
Задержка p95 (мс)Доля ошибок (%)Ответы из кэша (%)

Фаза

Ровная нагрузка

Нагрузка

2.4k RPS

Задержка p95

85 ms

Доля ошибок

0.2%

Ответы из кэша

76.0%

Повторное использование соединений

92.0%

Что помогает: Переиспользование соединений

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

Пояснения к обозначениям

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

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

  • Повторное использование соединений — доля запросов, отправленных по уже открытому соединению.
  • Ответы из кэша — доля запросов, которые обошлись без медленных обращений к сервису и его зависимостям.

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

Балансировка трафика

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

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

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

Повторное использование соединений

Холодные соединения и лишние рукопожатия поднимают p95/p99 даже тогда, когда само приложение работает быстро.

Доля ответов из кэша

Когда сервис чаще промахивается мимо кэша, растёт нагрузка на зависимости и быстрее портится пользовательская задержка.

Политика ожидания и повторов

Слишком агрессивные таймауты и повторные попытки могут сами создать перегрузку и разнести инцидент по зависимостям.

Балансировка на L4 и L7

Балансировщик меняет профиль задержек, путь запроса и поведение клиентских потоков, особенно когда нужен липкий маршрут.

MTU, потери и версия протокола

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

Источник

Evolution of HTTP (MDN)

Ключевые вехи HTTP/1.1, HTTP/2 и HTTP/3 и инженерные компромиссы каждой версии.

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

Эволюция HTTP

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

HTTP/1.1

1997/1999

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

Связь с OSI: Прикладной уровень поверх протокола TCP.

  • Постоянные соединения и передача данных по частям
  • Блокировка в начале очереди внутри одного TCP-соединения
  • Часто приходится держать несколько соединений с одним хостом

HTTP/2

2015

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

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

  • Несколько потоков внутри одного соединения
  • Сжатие заголовков с помощью HPACK
  • Меньше накладных расходов на установку соединений

HTTP/3

2022

HTTP поверх протокола QUIC (UDP)

Связь с OSI: Та же прикладная семантика поверх протокола QUIC, где потери меньше блокируют соседние потоки.

  • Быстрее устанавливает соединение и восстанавливается после потерь
  • Снижает влияние блокировки в начале очереди на транспортном уровне
  • Лучше ведёт себя в мобильных и нестабильных сетях

Где HTTP особенно важен

  • Публичные и внутренние API, включая REST и браузерные прокси к gRPC
  • Веб-приложения, SPA и SSR-фронтенды
  • Слои backend-for-frontend (BFF) и шлюзы API, которые собирают ответы из нескольких сервисов
  • Синхронные межсервисные вызовы, где важна предсказуемая схема запрос-ответ
  • Пограничные слои доступа: авторизация, ограничение частоты запросов и наблюдаемость

Почему это важно для системного дизайна

  • Протокол HTTP задаёт API-контракты и напрямую влияет на задержку, повторы и стоимость обработки запросов.
  • Выбор версии меняет профиль нагрузки: соединения, мультиплексирование и поведение под потерями.
  • Грамотная стратегия кэша, таймаутов и повторов уменьшает радиус поражения инцидента и защищает зависимости.
  • HTTP-метрики часто дают самый ранний сигнал деградации пользовательского опыта.

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

Считать протокол HTTP почти бесплатным и не учитывать стоимость соединений, кэша и повторных попыток в расчётах ёмкости.

Назначать одинаковые таймауты и повторные попытки для всех методов и конечных точек, игнорируя SLA, идемпотентность и критичность операций.

Игнорировать семантику кэша через ETag и Cache-Control и тем самым перегружать сервисы лишними запросами.

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

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

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