Кратко

  • URG не открывает боковой канал. Он делает смещение в обычном пространстве последовательности значимым и сообщает состояние до указанной границы.
  • Telnet соединил уведомление с DATA MARK внутри потока, а FTP применил последовательность к ABOR. TCP привлекал внимание; смысл оставался у приложения.
  • Развёрнутый код не принял правило LAST из RFC 1122. RFC 6093 вернул практическое LAST+1, но запретил превращать совместимость в новую архитектурную зависимость.

Срочность без обгона

В RFC 793 шестнадцатибитное поле действует только при URG. Его сумма с номером последовательности сегмента образует срочный указатель. Пока граница впереди уже прочитанных данных, TCP сообщает приложению срочный режим.

Байты не покидают упорядоченный поток. Если указатель продвинулся во время режима, отдельного события может не быть. Число уведомлений поэтому не равно числу команд.

Зачем Telnet оставил метку в потоке

RFC 854 определил Synch как пару: срочное уведомление TCP и DATA MARK. Первое будило специальную обработку, вторая завершала сканирование обычного потока. Несколько Synch могли слиться.

RFC 959 предложил FTP-клиенту послать Interrupt Process, Synch и затем ABOR или STAT во время передачи. TCP не исполнял отмену — он помогал серверу заметить следующую прикладную команду.

Две границы одного RFC

Описание заголовка RFC 793 указывало на байт после срочных данных, а обработка SEND использовала SND.NXT-1, последний срочный байт. RFC 1011 назвал первое описание ошибочным. RFC 1122 потребовал LAST и поддержку срочной последовательности любой длины.

Исправленный текст не передвинул границу во всех уже распространённых ядрах.

Боковой ящик на один байт

RFC 6093 обнаружил почти во всех проверенных популярных реализациях прежнее толкование «следующий байт». Многие socket API извлекали последний срочный байт из обычного чтения и выдавали его через MSG_OOB.

Так потоковый признак стал выглядеть как внеполосные данные. Следующее уведомление могло перезаписать непрочитанный однобайтовый слот. SO_OOBINLINE менял локальную выдачу, но не весь маршрут.

Посредник выключал звонок

Некоторые middlebox очищали URG и обнуляли указатель. Данные продолжали идти inline, ожидаемое событие исчезало. Конечная система и инспектор могли по-разному собрать прикладной поток.

RFC 6093 принял распространённую семантику, сохранил поддержку старых приложений и рекомендовал новым не использовать механизм. Оставшимся пользователям следовало читать inline и работать правильно при удалённом URG. RFC 9293 сохраняет разделение: реализация обязательна, новая зависимость нежелательна.

Источники и пределы

RFC подтверждают замысел, конфликт текста, применения и исследованную практику. Они не доказывают одинаковое поведение всех ОС и устройств. URG не даёт сетевого приоритета, аутентификации или отдельной доставки.

Поле осталось ради совместимости; право определять корректность новых систем исчезло.