HTTP Keep-alive (постоянное соединение, persistent connection) — режим работы HTTP, при котором TCP-соединение остаётся открытым после передачи ответа и используется для последующих запросов того же клиента. Стандарт HTTP/1.1 (RFC 7230) делает keep-alive поведением по умолчанию: соединение закрывается только явным заголовком Connection: close.
Как работает
HTTP/1.0 (1996): каждый запрос — отдельное TCP-соединение. Для загрузки страницы с 50 ресурсами (HTML + CSS + JS + изображения) открывалось 50 TCP-соединений, каждое с TCP three-way handshake (SYN-SYN/ACK-ACK) ~1 RTT и TLS-хендшейком ещё ~1-2 RTT. HTTP/1.1 (1997): keep-alive по умолчанию — все ресурсы страницы загружаются через 1-6 соединений (с pipelining или параллельными соединениями браузера).
Параметры keep-alive в nginx:
keepalive_timeout 65; # секунд ожидания следующего запроса
keepalive_requests 100; # максимум запросов на соединениеВ Apache KeepAlive On, KeepAliveTimeout 5, MaxKeepAliveRequests 100.
Keep-alive между nginx и upstream-серверами (backend): директива keepalive 32 в upstream {} блоке nginx поддерживает пул постоянных соединений к бэкенду. Без этого nginx устанавливает новое соединение для каждого проксируемого запроса.
HTTP/2 и HTTP/3
HTTP/2 (RFC 7540, 2015) полностью решает проблему, которую keep-alive решал частично. Прямой эффект на время отклика сервера: снижается TTFB при повторных запросах: мультиплексирование позволяет передавать неограниченное число потоков данных через одно TCP-соединение параллельно. Keep-alive в HTTP/2 имеет смысл для поддержания соединения при простое. HTTP/3 (RFC 9114, 2022) использует QUIC (UDP) вместо TCP — концепция keep-alive трансформируется в connection ID migration.
История
Persistent connections впервые описаны в черновом расширении HTTP/1.0 (1996) с заголовком Connection: Keep-Alive. HTTP/1.1 (RFC 2068, 1997; RFC 2616, 1999) сделал их стандартом по умолчанию. HTTP/2 (2015) заменил множество параллельных соединений мультиплексированием. Браузеры ограничивают число параллельных соединений к хосту: Chrome — до 6 per hostname в HTTP/1.1.
На что обращать внимание
Слишком высокий keepalive_timeout держит соединения открытыми без необходимости, занимая file descriptors на сервере. При высоком трафике 1000+ RPS оптимальный timeout — 5-15 секунд. Для задержки: keep-alive критично для HTTPS-сайтов — TLS-хендшейк дорог, и переиспользование соединения даёт 30-50% ускорение первого байта при повторных запросах.
Keep-alive и производительность хостинга
На VPS с nginx оптимальный keepalive_timeout — 10-30 секунд для обычных сайтов. Слишком высокое значение увеличивает число открытых соединений и потребление памяти: каждое открытое соединение nginx удерживает ~250 байт структуры. При 10 000 одновременных соединений — ~2.5 МБ только на метаданные соединений. Keep-alive особенно важен для сайтов с множеством ресурсов: HTTP/1.1 ограничен 6 параллельными соединениями с одним хостом, поэтому все ресурсы страницы загружаются поочерёдно через эти 6 соединений.