Принимая во внимание описание TCP_USER_TIMEOUT:
Когда значение больше 0, оно определяет максимальное количество времени в миллисекундах, в течение которого переданные данные могут оставаться неподтвержденными, прежде чем TCP принудительно закроет соответствующее соединение и вернет ETIMEDOUT приложению.
Очень короткие значения USER TIMEOUT могут повлиять на передачу TCP по путям с большой задержкой. Если пользовательский тайм-аут происходит до того, как поступит подтверждение для ожидающего сегмента, возможно, из-за потери пакета, соединение закрывается. Многие реализации TCP по умолчанию используют значение USER TIMEOUT, равное нескольким минутам. Хотя опция UTO позволяет предлагать короткие тайм-ауты, приложения, рекламирующие их, должны учитывать эти эффекты.
Я бы ожидал, что TCP_USER_TIMEOUT в 2 мс будет иметь катастрофические последствия: в сети, где RTT меньше 2 мс, каждый отправленный TCP-пакет будет тайм-аутом на ожидание ACK, и соединение будет закрыто. Однако в моем окружении я этого не испытываю. Соединения могут быть установлены, а данные отправляются и принимаются нормально. Однако я заметил, что если я потяну за шнур или отключаю принимающий интерфейс, TCP_USER_TIMEOUT действительно обнаруживает потерю соединения, и соединение закрывается своевременно. Итак, TCP_USER_TIMEOUT работает, но не так, как я ожидал.
Что я неправильно понимаю по поводу TCP_USER_TIMEOUT? Почему значения ниже RTT не приводят к разрыву соединения?
В случае, если это поможет, моим клиентом является компьютер Scientific Linux 6.1 с ядром 2.6.32.
Реализация UTO в Linux была неточной и была недавно исправлена с помощью этого набора исправлений: (На всякий случай, если вы не являетесь автором этого набора исправлений): https://lkml.org/lkml/2018/7/18/1090
Однако даже после запуска UTO хост прекращает повторную передачу и переходит в состояние TCP_CLOSE, но не сбрасывает соединение. Ответственность за отправку RST лежит на приложении.