Keep-alive: как соединение остаётся открытым, когда данных нет

TCP-соединение не требует постоянного обмена: если стороны молчат, соединение остаётся открытым. Проблема в том, что снаружи не видно, жива ли вторая сторона. Если удалённый компьютер выключился или кабель вытащили, ваша программа может ждать вечно. Механизм keep-alive решает эту задачу: после периода простоя стороны отправляют друг другу пробные пакеты и по ответам понимают, что связь жива.

Проще говоря, keep-alive позволяет отличить спокойное соединение, где просто нет новых данных, от мёртвого, где вторая сторона исчезла. Без него зависшее соединение может висеть часами, занимая ресурсы обеих сторон и путая пользователя.

Название используют в двух смыслах. В TCP это пробные сегменты, которые отправляет операционная система по настройкам сокета. Если несколько подряд остались без ответа, соединение считается разорванным. В HTTP это способ не закрывать соединение после каждого ответа и использовать его для следующих запросов. В версии 1.1 такое поведение включено по умолчанию, что экономит время на новых рукопожатиях.

Есть и прикладной уровень: многие протоколы посылают собственные периодические сообщения, например ping в WebSocket или в защищённых туннелях.

В Linux по умолчанию первая проба отправляется после двух часов простоя, затем каждые 75 секунд, до девяти попыток. Похожие значения используются в Windows. Для многих задач два часа слишком много, и приложения задают собственные интервалы, порядка десятков секунд.

Обратите внимание: TCP keep-alive по умолчанию у сокета выключен, и каждое приложение должно запросить его само. Поэтому не все программы им пользуются.

Домашний роутер и провайдерское оборудование хранят таблицу активных соединений, а записи о простаивающих удаляют по таймеру. Для TCP он может составлять от нескольких минут до нескольких часов, для UDP — гораздо меньше, иногда порядка десятков секунд. Если стороны молчат дольше, запись исчезает, и следующий пакет уходит в никуда. Пользователь видит, что чат или удалённый сеанс завис, хотя интернет работает.

Регулярные пробные пакеты обновляют таймеры на всём пути, и потому их используют в SSH, мессенджерах, играх и туннелях. Устройства с NAT и мобильные сети особенно строги к простою.

В клиенте SSH есть параметры интервала отправки служебных сообщений, в браузерных приложениях интервалы задают сами разработчики. В Linux общие значения хранятся в системных параметрах ядра. Слишком частые пробы расходуют заряд батареи телефона и трафик, слишком редкие не уберегут соединение от сброса.

Чтобы убедиться, что проблема в простое, засеките, через какое время соединение обрывается без активности. Если срок стабильно одинаков, например пять минут, виноват таймер на пути, и решение — интервал проб короче этого времени.

Рассмотрим HTTP-вариант подробнее. На заре сети для каждого запроса открывали отдельное TCP-соединение и закрывали его после ответа. Страница с десятками картинок порождала десятки рукопожатий, а каждое стоило времени. Постоянные соединения решили проблему: сервер оставляет канал открытым, и браузер отправляет по нему следующие запросы. В версии 1.1 этот режим действует по умолчанию, если стороны явно не запросили закрытие.

Сервер ограничивает время простоя и число запросов на соединение, чтобы не тратить память на «спящие» подключения. Поэтому иногда соединение закрывается сервером после нескольких секунд тишины. Это норма, и клиент просто откроет новое.

Более новые версии протокола пошли дальше: в HTTP/2 по одному соединению одновременно идут много запросов, в HTTP/3 транспорт другой, но идея переиспользования сохраняется. Мультиплексирование делает вопрос о простое ещё важнее: одно долгое соединение обслуживает целый сайт.

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