摘要

  • RFC 675 指出，各自选择的端口标识可能冲突；加入 TCP 的地址后，socket 名称才有跨互联网络的范围。
  • 一条连接由两端 socket 配对标识，因此一个本地 socket 可以参与许多不同连接。
  • 后来的规范把主机寻址和协议分派放在 IP，把进程端口留在传输层。这些文本说明规范如何表述层次，不证明所有实现何时采用了它。

连接身份取决于两端的配对

把 socket 当成“连接”的同义词，容易漏掉配对关系。RFC 675 规定，一条连接由两端 socket 组成；本地 socket 可以同时参与多条通往不同外部 socket 的连接，数据也可以双向传送。因而，一个本地名称不必被一段永久对话独占，另一端的名称补齐了连接描述。

这组配对解释了为什么本地端口可以复用而连接仍能区分。一个服务端点可以面对多个远端；即使本地 socket 相同，远端不同，socket 对就不同。RFC 描述的是协议端点的命名方式，并未说 socket 能认证用户、证明机器所有权或永久绑定给某个主体。

规范还显出另一条实际边界：RFC 定义端点怎样命名，但端口与本地进程的绑定由主机处理。跨网络命名和本地选择哪个进程收流量相互关联，却不是同一个决策。

单独的端口无法越过所属范围

端口号不必在全世界唯一；它只需在解释它的系统内区分进程。1974 年 12 月发布的 RFC 675 明确写出了这个边界：操作系统、TCP 或用户各自选择端口标识，所以不同选择可能相同。问题不是数字选错了，而是有人要求一个本地名称承担超出本地范围的识别任务。

设想两个彼此独立的 TCP 都使用同一个端口值。仅凭这个数字，接收方无法知道目标是哪一个 TCP，也无法知道它属于哪一个互联网络。RFC 675 因而把标识 TCP 的 Internet 地址与端口标识组合起来，形成在互联网络中唯一的 socket 名称。它的处理方式不是假设每个本地端口全球唯一，而是把缺少的范围写进名称。RFC 675，第 2.7 节

后来的分层把网络地址放在端口之外

1980 年的 TCP 规范把端口放在每台主机内部，再将它与 Internet 层提供的网络地址和主机地址组合为 socket。连接仍由一对 socket 标识，同一个 socket 也可以用于多条连接。RFC 761 还指出，端口与进程的绑定由各主机独立处理。RFC 761，第 1.4、2.7 节

配套的 IP 规范把主机寻址和协议选择放进 Internet 首部：地址标识源主机和目的主机，协议字段指出下一层协议。1981 年的 RFC 791 保留这个单独的协议字段，RFC 793 的术语表则把 TCP socket 定义为 Internet 地址与 TCP 端口的组合。合起来看，IP 负责网络可达性和下一协议分派，传输层负责进程选择。RFC 760，第 1.1、3.1 节 · RFC 791，第 3.1 节 · RFC 793，第 3.1 节与术语表

UDP 规范也能看到这层分工。它定义源端口和目的端口字段，而 UDP/IP 接口从 IP 首部取得 Internet 地址和协议字段。端口因此必须放在地址和传输协议的上下文中理解；它不是在所有网络、所有协议里都能通用命名应用的数字。RFC 768，“Fields”和“IP Interface”

名称划出了层与层之间的边界

RFC 675 的 socket 解决了协作范围问题，却没有要求建立全球端口分配机关。它把一个本地有用的数字延伸到所属 TCP 之外，加入区分端点所需的地址范围。后续规范把分工写得更清楚：IP 标识主机并分派下一协议，传输端口选择进程，一对端点名称描述连接。

这是一段关于规范边界的历史，不是某个确定迁移日期或普遍部署的证明。RFC 说明字段放在哪里、连接名称由什么构成，却不能证明哪张网络何时采用每个版本，也不能说明具体操作系统的内部表示。可由文本支持的结论更窄：端口只有放在本地上下文中才能标识服务，而连接范围来自两端及其网络地址。

来源与证据边界

主要来源是 RFC 675、RFC 760、RFC 761、RFC 768、RFC 791 和 RFC 793。这些文本证明规范中的术语和字段安排，不证明部署、采用时间线、认证、持久机器身份或当前运行行为。