Summary

  • 端口号可以准确标示运输层端点，也可以作为默认会合约定，但不能认证应用、内容、用户、意图或最终服务结果。
  • 把端口与服务的惯常对应关系当成裁决依据，可能误伤合法通信，并促使通信改用其他端口、动态协商、中转、隧道或加密。

先把证据拆开。中途观察者能够确认的是外层协议号、源地址、目的地址，以及在可见条件下的源端口和目的端口。IANA 登记可以说明某个端口通常与某项服务相联系。至于这个具体流量是否真的属于该服务、对端是谁、是否获得授权、用户想做什么、业务是否成功，则属于后续事实。

RFC 3639 明确指出，即便是“众所周知”的端口，其含义也只对通信端有保证。中途设备一般不应自行赋予确定的服务含义，除非通信端明确发出信号，或通信各方与该设备共同遵循一项约定。两端可以约定让任何服务使用任何端口；有些协议还会在控制交换中动态选定后续端口。没有参加协商、也没有收到协商结果的观察者，并不掌握那项映射。

这并不表示端口没有价值。稳定端口有助于默认会合、宏观流量分析、负载观察、防火墙规则和服务质量处理。问题在于一项线索能够承受多重的结论。RFC 3639 用端口 25 举例：为抑制垃圾邮件而拦截名义上的 SMTP 流量，也可能拦截合法邮件。这是标准提出的风险示例，不是对当今某家运营商的测量或指控。

更重要的是反馈效应。当通信双方认为某种基于端口的限制损害其正当利益时，可以改用其他端口、通过中转节点、动态协商，或把原报文装进新的外层报文。GRE 会改变中途可见的外层信息；ESP 还可能隐藏并加密内层信息。加密和用户希望采用的安全措施并非可疑行为。这里的结论只是：对稳定线索施加过强控制，可能促使线索从路径上消失。

后来的规范继续维持这条界线。RFC 7605 将端口同时视为端点分流字段和服务约定，并强调服务与端口的对应最终来自两端协议。一个 Web 服务完全可以运行在端口 53，只要客户端知道去那里连接。RFC 6335 规定 IANA 的服务名与端口分配程序；实时登记表 提供默认协调，不提供应用认证。

TCP、UDP 与 SCTP 都保留了端点通信和分流语义；IP 协议号登记表 协调另一个报文头字段。它们都没有把一个数字变成对应用身份的证明。RSVP 展示了显式通知网络的情形，SIP 则展示了动态协商后续通信参数的情形。合法参加这些交换的设备可能获得更强证据，但信号、对端身份、策略授权与服务结果仍须分别确认。

RFC 的原始范围可由 RFC Editor 信息页、Datatracker 页面、变更历史、勘误页和纯文本版交叉核验。本文采用 Lu Heng 对现实层次、最小共同规范和运行代码优先的分析方法：共同登记可以协调默认值，实际运行的通信端决定具体用途，中途机构不应把符号提升为超出证据的权力。