Кратко

  • TCP- и UDP-службы RFC 863 слушали порт 9, уничтожали полученные данные и не посылали прикладного ответа; TCP-соединение завершал вызывающий пользователь.
  • Установление TCP и ACK дают транспортное свидетельство, но не подтверждают конкретное чтение или учёт внутри процесса Discard.
  • В UDP молчание совместимо с успешным уничтожением, потерей, фильтром и отсутствием службы. Без независимого наблюдения на стороне получателя причина не определяется.

Правильный ответ отсутствует по замыслу

Для одностороннего измерения удобно убрать обратную работу. Получателю не нужно отражать байты, генерировать строку или вычислять результат. RFC 863 назвал такую службу полезной для отладки и измерения.

Вместе с ответом исчез простой признак успеха. Норма утверждает: если сервер получил данные, он их выбрасывает и молчит. Она не утверждает обратного: если клиент слышит молчание, сервер обязательно получил данные. Такая перестановка превращает правило поведения в недоступное удалённое знание.

TCP рассказывает о транспорте

TCP Discard принимал соединения на порту 9, выбрасывал входящий поток и продолжал до тех пор, пока вызывающий пользователь не прекращал соединение. Сервер не обязан был завершать партию сообщением или собственным закрытием.

Рукопожатие свидетельствует, что удалённая TCP-точка приняла соединение в этот момент. Номера последовательности, ACK, повторы, RST и таймеры показывают дальнейшее движение. RFC 9293 формулирует предел: принимающий TCP подтверждает данные, когда берёт ответственность за доставку своему пользователю. Это не заявление процесса Discard о выполненном read.

Локальный успешный вызов может быть ещё слабее. RFC 9293 допускает интерфейс, где SEND немедленно подтверждается локально до ACK удалённого TCP. Возврат write способен означать лишь принятие буфера местным стеком.

Для доказательства потребления приложением нужен отдельный свидетель: счётчик процесса, контролируемый захват или вспомогательный канал. Его создаёт испытательная система, а не скрытая квитанция RFC 863.

UDP объединяет разные причины в одну тишину

UDP Discard выбрасывал каждый достигший порта 9 датаграмм и ничего не отвечал. RFC 768 не гарантирует доставку и защиту от дублей. Поэтому успешная обработка, потеря, блокировка и отсутствие слушателя выглядят для отправителя одинаково.

Отсутствие ICMP тоже не выбирает причину. RFC 8085 отмечает фильтрацию ICMP промежуточными системами и запрещает UDP-приложению полагаться на их доставку для корректной и безопасной работы. Проверенная ошибка полезна; отсутствие ошибки не доказывает успех.

Контролируемый опыт считает отправки и прибытия в независимой точке, фиксирует место наблюдения и срок. Без этого «ноль ответов» — статистика ответов, а не доставки.

Не петля Echo/Chargen

Echo возвращает запрос, Character Generator создаёт ответ. Discard не создаёт прикладного ответа и потому не образует тот же цикл, где ответ при поддельном источнике становится следующим запросом. Источники не дают современной частоты злоупотреблений или универсального коэффициента.

Молчаливый приёмник всё равно потребляет канал, буферы и состояние. Вопросы управления — кто разрешил нагрузку, каков предел и чем подтверждается атрибуция. Нет ответа не значит нет стоимости.

Назначение порта не подтверждает процесс

IANA хранит имя discard для TCP и UDP на порту 9, а также строки SCTP и DCCP с другими ссылками. RFC 863 непосредственно определяет первые два транспорта. Реестр сохраняет соглашение об имени, но не запускает службу.

RFC 6335 относит порт к System Ports и различает назначенные, свободные и резервные значения. Назначение — факт реестра. Оно не доказывает слушатель, соответствие, личность, разрешение или необходимость публичного доступа.

Поэтому запись не заполняет пустоту UDP. TCP-соединение сообщает больше, но номер всё ещё не аутентифицирует процесс. Полномочие реестра и свидетельство исполнения различны.

Сначала утверждение, затем прибор

Локальное принятие буфера требует данных API. Ответственность удалённого TCP — состояния и ACK. Чтение процессом — метрики приёмника. Доля доставки UDP — числа отправленных и увиденных датаграмм. Это четыре самостоятельных утверждения.

Сохраняйте транспорт, адреса, время, байты, повторы, ошибки, инициатора закрытия и место наблюдения. Неожиданный прикладной ответ надо сохранить: конечная точка не ведёт себя как RFC-863-Discard, а известный порт сам по себе не раскрывает её личность.

Источники и ограничения

Механизм описывает RFC 863, статус elective — RFC 880. Границы TCP берутся из RFC 9293. Негарантии UDP — из RFC 768, современные указания — из RFC 8085.

Управление номером подтверждают RFC 6335 и реестр IANA. Они не измеряют нынешнее развёртывание, скорость, трафик или злоупотребления и не идентифицируют живой сервер.