Кратко

  • User Timeout в TCP — локальный предел для конкретного соединения: если отправленные данные остаются неподтверждёнными дольше, узел может разорвать соединение. Это не таймер, определяющий момент повторной передачи.
  • RFC 5482 определила четырёхоктетную опцию для объявления текущего значения. Сообщение остаётся советом, а не обязательным согласованием: получатель может его проигнорировать, ограничить своими пределами или не позволить ему заменить значение приложения.
  • Долгий срок помогает сохранить соединение во время перерыва связи, но удерживает очереди и состояние. Короткий освобождает ресурсы раньше, однако способен принять задержку или временную потерю за окончательный отказ.

Двое часов для одного байта без ACK

Соединение установлено, но один байт ещё не подтверждён. Когда истекает таймер повторной передачи, TCP посылает сегмент снова и запускает следующий отсчёт. User Timeout отвечает на другой вопрос: как долго незавершённая работа ещё оправдывает хранение всего состояния соединения с точки зрения приложения?

RFC 793 определяла этот срок как локальный параметр соединения. По истечении USER TIMEOUT TCP не делает ещё одну попытку: он очищает очереди, сообщает об аварийном завершении, удаляет блок управления передачей и переходит в CLOSED. Действующая RFC 9293 сохраняет различие: RETRANSMISSION TIMEOUT повторяет отправку, USER TIMEOUT прекращает состояние.

Приложение получило эту власть раньше появления UTO. Абстрактный интерфейс 1981 года позволял задать срок при OPEN и изменить его при SEND. RFC 1122 затем описала чрезмерные повторы порогами R1 и R2. R1 вызывает предупреждение, R2 закрывает соединение. Приложение обязано иметь возможность назначить R2 для отдельного соединения; рекомендация не менее ста секунд для данных не является единым обязательным значением.

Такое управление оставалось односторонним. Мобильный узел мог увеличить срок, чтобы пережить смену сети, а партнёр всё равно удалял состояние раньше. Загруженный сервер мог стремиться быстро освободить молчащее соединение, не имея способа объяснить клиенту этот бюджет средствами TCP.

Четыре октета без заключения сделки

В 2009 году RFC 5482 назначила UTO номер TCP-опции 28 и длину 4. Бит G выбирает секунды или минуты, остальные пятнадцать бит несут предложенное значение. Ноль зарезервирован. Поле выражает время, а не число повторов и не оценку RTT.

Если включить UTO до открытия, опция может идти в SYN и SYN-ACK. Её следует повторить и в первом пакете без SYN. Реализация без поддержки обязана молча проигнорировать опцию. Если несущий её сегмент потерян, партнёр просто не получает возможности обновить политику. Отдельного надёжного рукопожатия нет, и доставку нельзя считать гарантированной.

Распределение полномочий названо прямо. ADV_UTO — объявленный локальный срок, REMOTE_UTO — последнее принятое предложение, USER_TIMEOUT — применяемое локальное решение. ENABLED включает расширение, а CHANGEABLE определяет, может ли удалённый совет повлиять на значение.

Когда приложение явно задаёт USER_TIMEOUT, CHANGEABLE должен стать false. Пакет партнёра не может незаметно отменить указание приложения. Если адаптация разрешена, RFC рекомендует взять большее из двух объявленных значений, а затем применить локальные нижний и верхний пределы. Даже тогда концы могут выбрать разные сроки, и каждый вправе закрыть соединение сам.

За выживание платят состоянием

Длинный срок помогает при мобильном переходе, нестабильной маршрутизации или временной недоступности. В это время узел хранит память, очереди и контекст. Злоумышленник, завершивший множество рукопожатий и предложивший большие сроки, может увеличить стоимость бесполезных соединений для сервера.

Поэтому RFC 5482 требует ограничений. Нижний предел должен превышать текущий RTO; иначе потеря или высокая задержка способны вызвать разрыв до разумной возможности восстановления повтором. Верхний предел может зависеть от аутентификации, числа соединений партнёра, потребления ресурсов и признаков атаки. Принятие долгого совета не лишает локальный узел права освободить состояние.

Keep-alive решает другую задачу. Если работают оба механизма, его таймер должен быть больше принятого User Timeout, чтобы отдельная политика проверки не закрыла соединение первой. Межсетевой экран с отслеживанием состояния также способен забыть поток по собственному сроку простоя. UTO не проверяет путь, не удостоверяет партнёра и не гарантирует сохранение соединения до объявленного времени.

Есть и физическая граница — сорок октетов пространства TCP-опций. Другие расширения могут не оставить места. Отсутствие UTO само по себе не доказывает отказ.

Что именно изменилось

RFC 5482 не создала право приложения выбирать время ожидания. Она сделала локальную политику слышимой, не передав власть над ней. Поэтому UTO не повторяет Window Scale, который фиксирует трактовку поля после рукопожатия; PAWS, который по меткам времени отвергает старый смысл пространства последовательностей; или SACK, который сообщает о блоках, пришедших за разрывом.

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

Источники