TLS и HTTPS
Тема дорожной карты · Backend разработчик
TLS (Transport Layer Security) и HTTPS — протоколы, шифрующие все данные при передаче между клиентами и бэкенд-серверами, защищающие учётные данные REST API, JWT-токены, коды авторизации OAuth 2.0 и пользовательские данные от перехвата и атак типа «человек посередине». HTTPS — это HTTP поверх TLS-соединения: TLS-рукопожатие согласовывает набор шифров и обменивается сертификатами, после чего весь HTTP/2 или HTTP/1.1-трафик шифруется с использованием симметричных сеансовых ключей, полученных в процессе рукопожатия. В бэкенд-деплоях TLS терминируется на обратном прокси NGINX, AWS ALB или Kubernetes Ingress-контроллере (обычно с cert-manager и Let's Encrypt для автоматизированного провизионирования сертификатов), с пересылкой незашифрованного трафика внутренним сервисам по доверенной сети кластера. Конфигурация TLS и HTTPS должна соответствовать современным стандартам: TLS 1.2 как минимум (TLS 1.3 предпочтительнее из-за более быстрого рукопожатия и улучшенной прямой секретности), сильные наборы шифров, заголовки HSTS с большими значениями max-age и OCSP stapling для снижения задержки проверки сертификата. openssl s_client и инструменты вроде testssl.sh используются для аудита конфигурации TLS и HTTPS в CI/CD-пайплайнах, гарантируя, что каждый деплой поддерживает рейтинг A+ и что истёкшие или неправильно настроенные сертификаты инициируют алерты до того, как они вызовут продакшен-сбои.
Как это работает
TLS и HTTPS — 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.
Типичные ошибки
Ловушки TLS и HTTPS: 200 OK с {"error": "..."} вместо нормальной 4xx/5xx (ломает client retry и observability); игнор Idempotency-Key для POST, создающего ресурсы (retry дублируют); session-токены в URL (логируются везде); нет gzip/brotli (медленные клиенты на плохих сетях); Server: header выдаёт версию стека. Прочтите RFC 9110 (HTTP semantics) один раз.