RFC: 1122
Оригинал: Requirements for Internet Hosts - Communication Layers
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Николай Малых
4.2.3.6 TCP Keep-Alive

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

Пакеты keep-alive должны передаваться только при отсутствии пакетов данных или подтверждений в течение заданного интервала. Значение этого интервала должно быть настраиваемым и по умолчанию должно составлять не менее 2 часов. Очень важно помнить, что для сегментов ACK, не содержащих данных, протокол TCP не обеспечивает гарантии доставки. Следовательно, при реализации механизма keep-alive сбои в ответ на специфические проверки не должны интерпретироваться как «умирание» соединения.

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

  • Обсуждение:
  • Механизм keep-alive периодически проверяет удаленную сторону при простое соединения, даже если отсутствуют неподтвержденные данные. Спецификация TCP не включает механизма keep-alive, поскольку он: (1) может обрывать нормальные соединения в результате транзитных сбоев Internet; (2) приводит к ненужному расходу полосы и (3) повышает расходы для соединений Internet с платным трафиком.

    Некоторые реализации TCP все же включают механизм keep-alive. Для подтверждения работоспособности бездействующего соединения такие реализации передают пробные сегменты, предназначенные для получения отклика удаленной стороны. Такие сегменты в общем случае включают поле SEG.SEQ=SND.NXT-1 и могут также содержать один произвольный октет данных. Отметим, что для бездействующих соединений SND.NXT=RCV.NXT, поэтому значение SEG.SEQ будет выходить за пределы окна. Следовательно, пробный сегмент будет заставлять приемник вернуть сегмент подтверждения, говорящий о том, что соединение сохраняет работоспособность. Если удаленная сторона разорвала соединение, она будет возвращать RST вместо подтверждающего сегмента.

    К несчастью, в некоторых не вполне корректных реализациях TCP возникают сбои при получении сегмента с SEG.SEQ = SND.NXT-1, если такой сегмент не содержит данных. Приложение может дополнительно проверить, способна ли удаленная сторона корректно отвечать на пакеты keep-alive без вставленного в них произвольного (garbage) октета данных.

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

2007 - 2017 © Русские переводы RFC, IETF, ISOC.