摘要

  • RFC 863 为 TCP 和 UDP 定义了同一个极简动作：监听 9 端口，收到数据就丢弃，应用不回任何消息；TCP 连接由调用方结束。
  • TCP 的连接与确认状态比一次 UDP 发送提供更多证据，但本机写入成功、远端 TCP 确认和远端 Discard 进程实际完成读取是三个不同主张。
  • UDP 发送后的沉默同时符合成功丢弃、途中丢包、过滤、无监听者和错误信息未送达等情况。没有接收侧观察，就不能从空白中挑出唯一原因。

空白并不是一个结果码

设想一次容量测试：发送端准备了一千万字节，希望远端只负责接收和销毁，不做计算，也不把内容送回来。这样可以减少返回流量和应用处理，让实验集中在单向发送路径。工程师按下开始，进度条走完，网络上没有应用回复。

此时最诱人的动作，是把沉默填成“成功”。可沉默只说明测试者没有看到回复。它没有说明哪一层接过字节，也没有说明接收进程是否读到了全部内容。RFC 863 没有遗漏确认功能；它刻意定义了一个不确认的服务。

这项设计的价值因此不只在于丢弃。它把证据边界剥得很清楚：协议规定远端应用在成功收到数据后仍保持安静，所以测试系统如果想提出更强的结论，就必须从别处取得证据，而不能把预期中的空白改名为收据。

TCP 的终点由调用者决定

RFC 863 的 TCP 版本监听 9 端口。连接建立以后，服务器丢弃收到的所有数据，不发送响应，并持续这样做，直到调用用户终止连接。最后一句决定了测试的结束机制：不是服务器计算完成后主动交付一个“OK”，而是发送方决定何时不再发送。

因此，等待服务器关闭连接来证明完成，会发明标准里没有的行为。连接能建立，说明某个远端 TCP 端点在当时接受了这个连接四元组。流量继续前进时，序号、确认、重传、复位和超时又能提供不同层次的记录。但这些都不是 RFC 863 的应用回执。

RFC 9293 对确认的职责写得很精确：接收端 TCP 在承担把数据交给用户的责任时确认收到数据。这能支持“远端 TCP 已承担责任”的判断，却没有声称某个应用读取调用已运行、内部计数已经增加，或字节已按预期销毁。

发送端 API 还可能更早返回。RFC 9293 讨论过一种接口：本机 TCP 可以立即确认 SEND 调用，即使远端 TCP 尚未确认相应分段。于是一次成功的 write 可能只证明本机协议栈接纳了缓冲区。要知道它后来是否抵达远端，还要看后续连接状态与实现语义。

Discard 的“无回复”让这些差别无法被应用层成功消息遮住。如果业务真的需要证明远端进程消费了精确字节数，就要增加接收侧进程计数、受控抓包或独立测试代理。那是新的证据面，不是从 RFC 863 中找回隐藏字段。

UDP 让多种事实发出同一种声音

UDP 版本只规定：服务器在 UDP 9 端口接收数据报，收到后将其丢弃，不发送响应。没有连接建立，没有事务编号，没有数量回显，也没有应用错误。

RFC 768 本来就不保证交付和重复保护。RFC 863 又没有在 UDP 上另建可靠性机制。发送一个数据报后什么也没回来，可能是服务按规范完成丢弃，也可能是数据报从未到达、策略设备提前过滤、目标没有监听，或 ICMP 错误没有传到应用。

ICMP 不能自动把问题变成二选一。RFC 8085 指出中间设备越来越常过滤 ICMP，UDP 应用不应依赖 ICMP 必然送达来保证正确和安全。收到并验证过的错误有价值；没有错误却不是成功证明。

所以，单端 UDP Discard 测试没有自然的成功事件。若控制两端，可以比较发送计数与接收侧抓包、进程计数；若控制路径中的独立观测点，可以声明它证明到达了哪个边界。若只有发送端，就只能诚实记录“发出了多少、观察多久、未收到应用回复”，不能再向前跳一步。

一个有用的减法实验

早期诊断服务形成了一组对照。Echo 把请求原样返回，Character Generator 产生新字符，Daytime 返回人可读的时钟字符串，而 Discard 删除应用返回路径。对受控实验来说，这个减法可以隔离单向发送能力，避免把回程数据生成纳入同一测量。

减法也删除了校验材料。Echo 至少允许比较往返字节，尽管它不因此认证对端。Discard 没有可比内容。TCP 还能依靠连接和传输状态形成有限证据，UDP 则必须借助外部观察。

这也使本题与 Echo/Chargen 反馈环不同。后两种 UDP 服务会回复，伪造源地址时，两个回复可以互相成为下一次请求。Discard 不发送应用响应，不能形成该种回路。现有官方资料也没有给出 Discard 的当代攻击频率或统一放大倍数；不应为了安全叙事虚构数字。

真正的运营问题是容量和授权：谁允许这项负载，接收端愿意消耗多少资源，测量能否归因，以及测试结束后是否保留足够证据。没有回复不等于没有成本。

端口登记不能替现场作证

IANA 目前把 discard 登记在 TCP、UDP、SCTP 和 DCCP 的 9 端口。RFC 863 直接规定的是 TCP 与 UDP；后两个条目有各自参考。共同编号让工具和运营者能识别约定的服务名称。

RFC 6335 把 0 至 1023 称为系统端口，并区分已分配、未分配和保留等登记状态。9 端口“已分配”说明号码空间的管理事实，不说明某个地址一定运行服务，也不说明 9 端口后的进程必然遵守 RFC 863。

登记更不能授予测试许可。扫描器看不到 UDP 回应时，IANA 记录不能替它证明成功；TCP 建连时，服务名可以说明预期，却仍需端点控制与行为证据识别真实进程。号码的权威与执行的证据属于两套责任。

先写主张，再选择仪表

“本机内核收下了缓冲区”需要查看本机 API 与队列。“远端 TCP 对这些字节承担了传递责任”需要确认状态。“远端 Discard 进程读取并销毁了全部流”需要接收侧应用观察。“这条 UDP 路径交付率为多少”需要发送分母、接收计数和明确时间窗。

每个结果还要保留地址与端口组合、传输类型、开始结束时间、关闭发起方、重传和错误。把不同层次压成一个绿色“通过”，会让后续人员无法判断究竟测到了什么。

最重要的异常反而是收到应用回复。若声称测试的是 RFC 863 Discard，回复意味着端点行为不符预期；此时应该保存原始回复和端点事实，而不是仅凭 9 端口猜测服务身份。

来源与限制

Discard 的 TCP、UDP 行为来自 RFC 863，1983 年 elective 地位来自 RFC 880。TCP 的连接、确认和用户接口边界依据 RFC 9293。UDP 的基本不保证来自 RFC 768，当代 UDP 与 ICMP 使用边界来自 RFC 8085。

端口治理依据 RFC 6335 与 IANA 服务登记表。这些资料没有测量当前部署、流量、性能或滥用，也没有识别任何在线 9 端口实现；本文不把路由器丢包、黑洞路由、Wake-on-LAN 惯例或治理语境中的“沉默即同意”混入 RFC 863。