У меня есть соединение, при котором данные отправляются с сервера клиенту только с довольно высокой скоростью.
Тогда вы никогда не увидите Keepalive. Keepalives отправляются, когда "молчание на проводе". RFC1122 содержит некоторые пояснения относительно поддержки активности.
Механизм «поддержки активности» периодически проверяет другой конец соединения, когда соединение бездействует, даже если нет данных для отправки.
Вернемся к вашему вопросу:
Некоторые другие источники утверждают, что это время бездействия соединения, но не уточняют, что это означает.
Это то, как долго TCP будет ждать, прежде чем ткнуть пиру «привет! все еще жив?».
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
Другими словами, вы использовали TCP-соединение, и это было здорово. Однако за последние 2 часа не было ничего, чтобы отправить. Разумно ли предположить, что соединение все еще живо? Разумно ли предположить, что все промежуточные блоки в середине все еще имеют информацию о вашем соединении? Мнения расходятся, и сообщения поддержки активности не являются частью RFC793.
Спецификация TCP не включает механизм поддержки активности, который может: (1) привести к разрыву совершенно хороших соединений во время временных сбоев в Интернете; (2) потреблять ненужную полосу пропускания («если никто не использует соединение, какая разница, хорошо ли оно по-прежнему?»)
Чтобы протестировать поддержку активности, мы отключили кабель от сетевой карты клиента.
Это не проверка активности. Это проверяет вашу стратегию повторной передачи TCP, т. е. сколько раз и как часто TCP будет пытаться передать ваше сообщение. В системе Linux это (вероятно) заканчивается тестированием net.ipv4.tcp_retries2:
Сколько раз можно повторить попытку, прежде чем убить живое TCP-соединение. RFC 1122 говорит, что ограничение должно быть больше 100 секунд. Это слишком маленькое число. Значение по умолчанию 15 соответствует 13-30 мин в зависимости от RTO.
Но RFC5482 — параметр тайм-аута пользователя TCP предоставляет больше способов повлиять на него.
Тайм-аут пользователя TCP определяет, как долго передаваемые данные могут оставаться неподтвержденными, прежде чем соединение будет принудительно закрыто.
Вернемся к вопросу:
Верно ли, что во время повторной передачи зонды проверки активности не отправляются?
В этом есть смысл: TCP уже пытается получить ответ от другого узла, пустое подтверждение активности было бы излишним.
TCP_KEEPCNT Максимальное количество запросов проверки активности, которые TCP должен отправить перед разрывом соединения.
TCP_KEEPIDLE Время (в секундах), в течение которого соединение должно оставаться бездействующим, прежде чем TCP начнет отправлять проверки активности, если для этого сокета была установлена опция сокета SO_KEEPALIVE
TCP_KEEPINTVL Время (в секундах) между отдельными проверками активности
TCP_USER_TIMEOUT Максимальное количество времени в миллисекундах, в течение которого передаваемые данные могут оставаться неподтвержденными, прежде чем TCP принудительно закроет соединение.
Так, например, ваше приложение может использовать эту опцию, чтобы определить, как долго сохраняется соединение при отсутствии подключения (аналогично вашему примеру с отключением сетевой карты). Например. если у вас есть основания полагать, что клиент вернется (возможно, он закрыл крышку ноутбука? нестабильный беспроводной доступ?), вы можете указать тайм-аут в 12 часов, и когда он вернется, соединение все еще будет работать.
person
cnicutar
schedule
20.06.2016
