3. 背景 (Background)

几十年来，传输控制协议 (TCP) [RFC0793] 和用户数据报协议 (UDP) [RFC0768] 作为互联网上最广泛使用的两个传输协议取得了显著的成功。它们依赖于"端口"的概念作为互联网通信的逻辑实体。

端口有两个目的：首先，它们提供解复用标识符来区分同一对端点之间的传输会话；其次，它们还可以标识进程连接到的应用协议和相关服务。

较新的传输协议，例如流控制传输协议 (SCTP) [RFC4960] 和数据报拥塞控制协议 (DCCP) [RFC4342]，也采用了端口的概念用于其通信会话，并以与 TCP 和 UDP（以及 UDP 的变体 UDP-Lite [RFC3828]）相同的方式使用 16 位端口号。

端口号是互联网上应用和服务识别的原始和最广泛使用的手段。端口是 16 位数字，源端口号和目标端口号的组合以及通信端系统的 IP 地址唯一标识给定传输协议的会话。

端口号还通过其关联的服务名称而为人所知，例如端口号 23 的"telnet"和端口号 80 的"http"（以及"www"和"www-http"）。

所有相关方——运行服务的主机、访问其他主机上服务的主机以及限制服务的中间设备（如防火墙和 NAT）——都需要就哪个服务对应于特定目标端口达成一致。虽然这最终是一个本地决策，仅在连接的端点之间有意义，但许多服务通常都有一个默认端口，这些服务器通常在可能的情况下在该端口上侦听，这些端口通过互联网号码分配机构 (IANA) 的服务名称和端口号注册表 [PORTREG] 记录。

随着时间的推移，特定端口号必然意味着特定服务的假设可能会变得不那么真实。例如，同一主机上同一服务的多个实例通常不能在同一端口上侦听，同一 NAT 网关后面的多个主机不能都在 NAT 网关的外部端拥有相同端口的映射，无论是使用用户手动配置的静态端口映射，还是使用诸如 NAT 端口映射协议 [NAT-PMP] 或互联网网关设备 [IGD] 之类的端口映射协议自动配置的动态端口映射。

应用程序可以直接使用端口号，通过系统调用（如 UNIX 上的 getservbyname()）根据服务名称查找端口号，通过执行 DNS SRV 记录查询 [RFC2782] [DNS-SD] 查找端口号，或以各种其他方式（如 TCP 端口服务多路复用器 (TCPMUX) [RFC1078]）确定端口号。

应用程序和应用层协议的设计者可以向 IANA 申请为特定应用程序分配服务名称和端口号，并且在分配后可以假设没有其他应用程序将使用该服务名称或端口号进行其通信会话。

应用程序设计者还可以选择仅请求分配服务名称而不请求相应的固定端口号（如果他们的应用程序不需要），例如使用 DNS SRV 记录在运行时动态查找端口号的应用程序。

由于端口号空间是有限的（因此保护是一个重要目标），建议尽可能使用服务名称而不是端口号的替代方案。