HTTP и сетевые протоколы
Тема дорожной карты · Backend разработчик
Протокол HTTP (Hypertext Transfer Protocol) — базовый протокол прикладного уровня, управляющий обменом данными между клиентами и серверами в вебе, что делает его обязательным знанием для каждого бэкенд-разработчика. HTTP определяет структуру запросов и ответов, задавая методы GET, POST, PUT, DELETE и PATCH, которые естественным образом соответствуют REST API-операциям. Современные бэкенды обычно опираются на HTTP/2, вводящий мультиплексирование, сжатие заголовков и server push для значительного снижения задержки по сравнению с HTTP/1.1. Stateless модель запрос/ответ протокола HTTP обеспечивает горизонтальное масштабирование бэкенд-сервисов — каждый запрос несёт весь необходимый контекст, позволяя любому экземпляру сервера обрабатывать его независимо. Понимание директив кеширования (Cache-Control, ETag, Last-Modified), постоянных соединений (keep-alive) и заголовков согласования содержимого критически важно для создания производительных, соответствующих стандартам REST API и микросервисов.
Как это работает
HTTP и сетевые протоколы — request/response протокол поверх TCP (или QUIC для HTTP/3). Запрос имеет метод (GET, POST, PUT, DELETE, PATCH), URL, заголовки, опциональное тело; ответ — статус-код (2xx success, 3xx redirect, 4xx client, 5xx server), заголовки, тело. HTTP/1.1 — одно TCP-соединение на запрос (с keep-alive переиспользованием); HTTP/2 мультиплексирует много запросов в одно соединение; HTTP/3 — поверх UDP через QUIC. TLS (HTTPS) обязателен в 2026.
Когда применять
HTTP/REST — для большинства публичных API: lingua franca, поддерживается клиентами, тулинг для отладки повсюду. gRPC — для internal service-to-service, когда важны latency + schema-дисциплина. WebSockets — для двунаправленного realtime. SSE (Server-Sent Events) — для server-push-only. Всегда за reverse proxy (Caddy, nginx, traefik), который держит TLS, сжатие, rate limit.
Типичные ошибки
Ловушки HTTP и сетевые протоколы: 200 OK с {"error": "..."} вместо нормальной 4xx/5xx (ломает client retry и observability); игнор Idempotency-Key для POST, создающего ресурсы (retry дублируют); session-токены в URL (логируются везде); нет gzip/brotli (медленные клиенты на плохих сетях); Server: header выдаёт версию стека. Прочтите RFC 9110 (HTTP semantics) один раз.