Существует несколько ситуаций:
- Если проблем в сети нет, то отвалившийся клиент «закроет» порт и сервер получит RST на свои пакеты, т.е. сервер «увидит» падение коннекта практически сразу.
- Если существуют проблемы в сети, когда ответ от клиента не приходит, то есть параметры, которые отвечают за таймауты (выставляются через sysctl):
tcp_retries1
Целочисленная переменная tcp_retries1 определяет число неудачных попыток, после которого должна быть передана информация на сетевой уровень. В соответствии с RFC минимальное значение составляет 3 (по умолчанию установлено именно это значение), что соответствует периоду приблизительно от 3 секунд до 8 минут в зависимости от значения тайм-аута повторной передачи RTO (Retransmission time-out).
tcp_retries2
Целочисленная переменная tcp_retries2 определяет число неудачных попыток, после которого существующее соединение уничтожается. В соответствии с RFC 1122 тайм-аут должен быть больше 100 секунд. Такое значение слишком мало и по умолчания установлено число попыток 15, соответствующее тайм-ауту приблизительно от 13 до 30 минут в зависимости от RTO.
Все параметры описаны в документации к исходинкам ядра (Documentation/networking/ip-sysctl.txt)
Также эти параметры влияют на все TCP соединения данного сервера. Если нужно «тюнить» для конкретного своего приложения, то можно использовать параметр TCP_USER_TIMEOUT для tcp-сокета. Указывает время в миллисекундах ожидания подтверждения (ACK) данных. Параметр появился в 2.6.37.
Для более ранних ядер можно мониторить исходящую очередь на сокете, и если она не уменьшается какое-то время — значит что-то случилось.
