端口与 UDP

16.1先从一个例子理解概念

同一台电脑既开浏览器又打游戏，收到的数据该交给谁？端口和程序使用的通信端点解决这个分配问题。

送到主机之后交给谁：端口

TCP/UDP端口是0–65535的传输层编号，参与把数据分配给通信端点。它不是网线插口，也不是某个程序永久独占的房间号。

程序使用的通信端点：socket

socket（套接字）是程序与网络通信使用的端点/接口。程序可以创建多个socket；同一服务端口也可对应许多不同连接。

直接发送一份消息：UDP

UDP（用户数据报协议）提供一份份数据报，不需要先做TCP式握手，不内建送达、顺序或去重保证。需要这些能力时，由使用它的上层协议补充。

怎样区分TCP连接：四元组

在普通TCP语境中，源IP、源端口、目的IP、目的端口合称四元组，用于区分连接。源与目的是相对这次数据发送方向说的。

下面再用这些概念看原理、命令和结果。规范与官方资料列在本章末尾，类比只帮助理解，不代替协议规则。

16.2为什么需要端口

一台电脑上同时发生的事情：

• 浏览器开着 20 个标签页
• 微信在收发消息
• 后台在下载系统更新
• 你在看视频

数据从网线进来，操作系统必须知道这一份该交给哪个程序。

IP 地址做不到这件事 —— 它只能定位到"这台设备"。所以需要一个更细的标识：端口。

端口是个 16 位数字，范围 0 ~ 65535。 因为 16 位最多表示 65536 个值。

16.3端口被分成三段

65536 个端口不是随便用的，标准（RFC 6335）把它分成三段：

Get-NetTCPConnection -State Listen | Select-Object -ExpandProperty LocalPort -Unique

知名端口 (0-1023)      :  3 个
注册端口 (1024-49151)  : 28 个
动态端口 (49152-65535) : 23 个

16.4实测：本机在监听哪些端口

Get-NetTCPConnection -State Listen | Sort-Object LocalPort |
  Select-Object -First 15 LocalPort, @{n='进程';e={(Get-Process -Id $_.OwningProcess).ProcessName}}

实测结果（TCP）：

UDP 侧：

16.5四元组：一条连接的唯一标识

一个端口号本身不能唯一确定一条连接。真正的标识是四元组：

源 IP 地址 + 源端口 + 目的 IP 地址 + 目的端口

实测：本机一条真实的外出连接

LocalAddress     LocalPort  RemoteAddress    RemotePort
192.168.31.215       65339  154.29.154.3           443

解读：

• 本机用 192.168.31.215，源端口 65339（落在动态端口区间 49152~65535，是系统临时分配的）
• 目标是 154.29.154.3 的 443 端口（HTTPS）

为什么必须是四元组？ 因为同一台机器可能同时：

• 用不同的源端口连同一个服务器（开多个页面）
• 用同一个源端口范围连不同的服务器

只有四元组才能唯一区分每一条连接。这也是 PAT（《网络层》模块）能工作的前提 —— 路由器改的就是四元组里的"源 IP + 源端口"两个字段。

16.6UDP：不要连接，也能传数据

TCP 要先握手、要确认、要重传。这些机制都要花时间。 有些场景不需要这些 —— 于是有了 UDP。

UDP 报文头只有 8 个字节（对比 TCP 的 20 字节起）：

只有四个字段，仅此而已。 没有序号、没有确认号、没有窗口、没有标志位。

UDP 用在哪些地方

共同特点：要么"丢了也没关系"，要么"要快要省"，要么"来不及等重传"。

16.7实测：412 万个无人要的 UDP 数据报

这是本章最有意思的一个数字。看本机的 UDP 统计：

netstat -s -p udp

实测输出：

UDP Statistics for IPv4

  Datagrams Received    = 134218107        收到 1.34 亿个数据报
  No Ports              = 4123543           其中 412 万个"没有对应端口"
  Receive Errors        = 0
  Datagrams Sent        = 261515295         发出 2.6 亿个

No Ports = 4,123,543，占收到总数的 3.07%。

它的含义是：收到了一个 UDP 数据报，但本机没有任何程序在监听那个端口。

UDP 遇到"没人监听"会怎样

对比一下 TCP 和 UDP 在同样情况下的行为：

注意这里的一个细节：《网络层》模块讲 ICMP 时说"ICMP 类型 3 代码 3 = 端口不可达" —— 那个报文的触发场景正是这里。你现在看到了它的来源：UDP 数据报打到了一个没人监听的端口。

为什么这个数字这么大（412 万）？ 合理的原因有几类：

• 发现类协议的广播/多播：比如 SSDP（1900 端口）、NetBIOS（137/138）、mDNS（5353）—— 这些协议会定期往多播地址发包，本机也可能收到别家设备发的，但对应服务没开
• 扫描器和探测流量：互联网上永远有大量机器在扫描端口
• 应用退出后残留的连接：程序关了，但对方不知道，还在继续发
• 我的实验本身：本教程跑过多次网络测试

16.8"UDP 不可靠"到底指什么

初学者容易把这个词理解成"UDP 经常丢包"。这是误解。

"不可靠"是一个协议层的表述，意思是：

注意"不提供保证"和"实际会丢"是两件事：

QUIC 就是最典型的例子：它是在UDP之上实现可靠传输、流和拥塞控制的传输协议，不能把QUIC简单归为应用层或等同于TCP机制原样搬家。这是 HTTP/3 的基础，《应用层》模块会讲。

16.9常见误解

误解一："端口是设备的一部分，像 IP 一样固定"

端口是传输层标识，不要求处于监听状态才有端口。客户端连接也有本地端口，可以由系统分配或应用显式绑定；关闭后还可能有TIME_WAIT等状态，下一次是否复用取决于系统和socket设置。RFC 9293 §3.3、§3.9

误解二："UDP 比 TCP 快是因为协议更简单"

协议简单确实省开销，但真正的大头是省掉了握手、确认和重传的等待时间。对于一次只有一问一答的 DNS 查询，TCP 光握手就要一个往返（几十毫秒），而 UDP 直接发。

误解三："用 UDP 就一定丢包"

不一定。 局域网里 UDP 可能一个都不丢。"不可靠"指的是协议不给你保证，不是"实际一定会丢"。要判断实际丢不丢，得看应用层的统计。

误解四："No Ports 这么多说明机器有问题"

不一定是问题。 这些计数可以来自正常业务，也可能包含异常流量 —— 广播、多播、扫描流量都会造成这类计数。TCP 侧对应的数字是"Reset Connections"，也是同理。

16.10本章小结

16.11自测题

16.12参考资料与适用范围

• RFC 6335 §6：端口区间与分配
• RFC 768：UDP数据报格式
• RFC 1122 §1.1.3、§2–4：TCP/IP分层与主机要求
• RFC 9293 §3.3–3.10：TCP状态、建立关闭、字节流与接口

修订核对日期：2026-10-13。规则按所列协议与实现范围理解；文中的原始命令输出是历史观察，不表示本次重新实测。跨版本、代理/隧道及不同捕获位置需要另行核对。