TCP 与 UDP

1 传输层要解决什么：端点与通信方式

在 S15 中，IP 地址和路由帮助我们判断数据往哪台主机走。可是，1 台主机可能同时运行网页服务、文件同步程序和监控代理。即使数据已经到达正确的网卡，仍然需要回答：交给哪个通信端点？传输层用协议、地址、端口以及套接字的关联关系，把到达主机的数据分给相应的通信对象。这里的端点可以先理解为程序通过操作系统建立的收发入口；端口是描述入口的重要编号，但它本身不是进程名称。

例如，服务器 198.51.100.20 同时提供 TCP 443 的网页入口和 UDP 123 的校时入口。仅写“访问 198.51.100.20”，无法说明希望获得哪种服务。客户端还要选择传输协议和目的端口，服务端才能按相应规则接收。前面学过的分层在这里有了具体用途：路由负责朝目的主机转发，传输层负责在端点之间组织通信，应用协议再规定收到的字节或消息是什么意思。

选择通信方式时，要先问数据的使用条件。传送安装包时，缺少中间 100 B 可能使整个文件校验失败，程序需要完整、有序的数据。每隔 1 秒上报当前温度时，迟到 10 秒的旧读数可能已无意义，程序更关心最新值。TCP 提供连接上的有序字节流和丢失恢复机制；UDP 提供独立数据报，应用可以按自己的需求处理丢失、重复和时效。这是承诺范围的区别，不能只用“快”和“慢”给它们排名。

端点还包含操作系统维护的收发缓冲区。程序调用发送接口后，数据通常先进入本机协议栈，再按网络条件发出；到达对端的数据也可能先排在接收缓冲区，等待程序读取。因此，抓包看见报文到达网卡，只能证明到达了这个观察位置，还要经过协议校验、套接字匹配和缓冲区接纳，应用才有机会读到内容。

例如，温度采集进程暂停读取 10 秒，期间设备仍不断发送。UDP 接收缓冲区被填满后，新到的数据报可能被丢弃，恢复读取也无法找回这些读数。TCP 接收方则会通过通告接收窗口告知对端还能接纳多少数据；缓冲区耗尽时可通告零窗口，使发送方暂停继续发送新的流数据。这叫流量控制，针对的是接收能力，不等于网络拥塞控制。若应用始终不读取，发送端自己的缓冲区也会逐渐填满，阻塞式写入可能等待，非阻塞式写入可能返回暂时不可写。此时“发送卡住”可能来自对端消费过慢，应结合两端缓冲区和进程状态判断。

TCP 的承诺也有条件：网络长期中断时，它不能凭空完成交付，最终可能报告失败。UDP 接口较简单，也不意味着应用总能更简单；如果应用需要补齐缺失消息，就要自行设计确认、重试和去重。我们接下来用端口辨认通信，再用状态和命令观察承诺是否推进。文中的 192.0.2.0/24、198.51.100.0/24 地址用于文档示例，不是需要实际访问的公网实验目标。

2 端口与五元组：如何区分同机上的多路通信

TCP 和 UDP 的端口字段都是 16 位，编号范围是 0–65535。常见服务使用相对稳定的端口，客户端便于事先知道入口，例如 TCP 443 常用于 HTTPS，UDP 123 常用于 NTP。0–1023 通常称为知名端口；客户端发起通信时，操作系统通常选择临时端口。临时端口的实际范围由系统配置决定，不要把某个系统的默认值当成所有主机的规则。端口 0 有特殊用途，也不应写成普通服务的固定访问端口。

设同台客户端打开 2 条到同台服务器的 HTTPS 连接。它们的目的端口都是 443，但源端口不同：

把协议、源 IP、源端口、目的 IP、目的端口合起来，就是本课使用的五元组。在这个观察位置，A 与 B 靠源端口区分，A 与 C 靠源 IP 区分。服务器监听 443，并不表示它只能服务 1 个客户端；接收新连接的监听入口与已经建立的各条连接有不同作用。这里按发起方向记录元组，回包的源与目的会交换，但仍属于对应的连接。

UDP 也有源端口和目的端口，但不能因此把每个五元组都叫作 TCP 式连接。接收 UDP 数据报时，系统会依据目的协议、地址和端口寻找匹配的套接字；套接字如果指定了对端，还常结合来源筛选。某些共享端口的配置会使分流更复杂，本课先掌握普通入口的判断。TCP 53 和 UDP 53 属于不同的传输协议空间，即使编号相同，也要分别确认是否提供服务。

把滑块从 1 调到 4，观察客户端源端口从 53124 增加到 53127，而目的始终是 198.51.100.20:443。这个演示只表示如何区分并发通信，不表示服务器容量等于临时端口个数，也不表示端口一定连续分配。真实容量还受资源、连接寿命和系统配置影响。记录问题时，应同时写明协议、地址和端口，避免只留下“443 有问题”这种缺少观察位置的描述。

3 UDP：数据报模型与适用边界

UDP 把每次发送的内容作为独立数据报。应用发送 80 B，再发送 120 B，接收方通常按 2 个数据报分别接收，不会因为它们相邻就变成 1 条 200 B 的 UDP 消息。如果接收缓冲区不足，某个数据报可能被截断，剩余部分不能当成下一次读取的后半段继续取回。消息边界仍在，但完整读取消息也需要应用准备足够的缓冲区。

发送 UDP 数据之前无需完成握手，因此发送调用成功只说明本地接受了这次发送，不能证明对端在线。假设每秒发送 1 条含序号的温度读数，接收方看到 101、102、104，就能从应用序号发现 103 缺失；UDP 本身不会替它请求补发。接收方也可能先看到 104 再看到 103，或收到重复消息。序号、时间戳、丢失统计与过期规则都属于应用需要明确的部分。

UDP 有校验和机制，用于检查传输中的损坏，但校验和不负责确认到达、排序或重传。在 IPv4 中 UDP 校验和允许不使用；即使启用了校验和并丢弃了损坏数据，也不会自动补回那条消息。因而“存在错误检查”与“可靠交付”不是同个承诺。应用如果决定重试，还必须考虑重复执行：重复查询时间通常无害，重复执行扣款却需要专门的业务保护。

数据报大小也要受路径约束。以普通 IPv4、无选项且路径 MTU 为 1500 B 为例，减去 20 B 的 IPv4 首部与 8 B 的 UDP 首部，1472 B 是不发生 IP 分片时的 UDP 负载上限。它不是所有路径的保证值，隧道等因素可能降低可用大小。将 4000 B 塞进单个 UDP 数据报可能引出分片或发送失败；发生分片时，只要缺少所需的任意分片，完整数据报便无法重组。设计时应控制消息大小，并在目标环境验证。

DNS 的许多查询和 NTP 校时都适合较短的请求与响应，但 DNS 也使用 TCP，不能按服务名断定只有 1 种传输方式。后续会接触的 QUIC 使用 UDP 承载，同时在上面实现更多机制。可见 UDP 为上层留下选择空间，适不适用取决于消息的时效、恢复需求和应用愿意承担的工作。

4 TCP：字节流、连接与可靠交付承诺

TCP 在传输应用数据前先建立连接，向应用提供按序读取的字节流。可以把它想成带位置编号的长串字节：发送方根据确认信息知道哪些位置已被接收，发现需要恢复的数据时进行重传。假设发送的 1000 B 中某段未到达，对端即使先收到后面的部分，也不能把缺口之后的数据当作连续的新内容随意交给应用。这里理解“编号、确认、恢复缺口”即可，不需要先学习拥塞控制的计算公式。

确认通常由对端协议栈产生，不等于对端应用已经读取，更不等于数据已经落盘。例如，服务端确认接收了 1000 B 后进程崩溃，客户端不能仅凭 TCP 确认就断言文件同步完成。若产品要求“保存成功”，应用应在校验、写入或其他必要动作完成后返回相应结果，并定义失败时怎样重试。传输层解决的是字节流的推进，业务承诺必须由应用协议表达。

字节流的另个关键性质是没有应用写入边界。发送程序先调用写入 40 B，再写入 60 B，接收程序可能读取到 100 B，也可能先读 25 B、再读 75 B，还可能分更多次读完。总共 100 B 及其顺序应保持，接收调用的次数与每次长度却没有对应保证。网络分段、到达时机和接收缓冲区都会影响读取结果，不能靠“我发了 2 次”来设计接收循环。

如果应用需要区分 2 条消息，就要定义分帧规则。例如，在每条消息前放 4 B 长度字段：40 B 内容前写入长度 40，60 B 内容前写入长度 60，总字节数为 4＋40＋4＋60＝108 B。接收方先累计读够 4 B，解析长度，再累计读够对应内容。即使第 1 次只读到 2 B，也继续累计长度字段；读到多条消息时则保留剩余字节继续解析。实际协议还应限制允许的长度，避免异常长度消耗资源。

连接建立后，HTTP 服务器仍可能返回 404、500，或者迟迟不给出完整响应。TCP 不理解 URL、登录权限与数据库状态，因此 TCP 成功不能推出 HTTP 200。反过来，读取较慢也未必是链路丢包，可能是应用处理尚未完成。排查时应分开记录连接是否成功、请求是否发送、响应是否完整以及业务结果是否符合预期，才能把修复交给正确的环节。

5 3次握手与连接状态的排查直觉

服务器先创建监听入口，等待客户端发起连接，这叫被动打开；客户端指定服务器地址与端口并主动连接，这叫主动打开。在网页访问例子中，服务器监听 TCP 443，客户端常用系统分配的 53124。客户端也需要本地端口来接收回包，但不必为了这条外连连接再监听 443。两端端口的用途不同，不要把“双方都通信”误读成“双方都监听同个服务端口”。

用 192.0.2.10:53124 到 198.51.100.20:443 观察握手：客户端先发 SYN，表示发起连接，此时本地可能观察到 SYN-SENT。监听中的服务器收到后回复 SYN-ACK；客户端收到响应，再发 ACK。正常情况下客户端进入 ESTABLISHED，服务端收到最后的确认后也进入 ESTABLISHED。服务器等待最后确认期间可能处于 SYN-RECV。状态反映本端已经处理到哪里，双方在同个瞬间看到的标签不必完全相同。

沿动画逐步检查 3 次报文，而不是只背箭头。第 1 步能证明客户端开始尝试；第 2 步说明有响应返回客户端；第 3 步让服务器确认客户端收到了响应。最后的 ACK 也可能携带应用数据，图中将阶段分开是为了观察。SYN 与 SYN-ACK 可以因丢失而重传，所以抓到 4 条相关报文并不表示协议变成了“4 次握手”。

在客户端看到 SYN-SENT 持续存在，应关注握手响应为什么尚未被本端接收，范围包括目标地址、路径、防火墙与服务端状态。它不能单独证明“服务器进程挂了”。在服务器看到 LISTEN，则说明本机存在监听入口，但仍需检查监听地址是否覆盖客户端访问的地址，以及外部路径是否允许进入。看到 ESTABLISHED，说明连接已推进到建立阶段，后续还要检查应用请求与响应。

这些状态是瞬时快照。短连接可能在执行 ss 前就已经结束，未出现在列表不等于从未发生过。若服务端监听 443，已建立连接也使用本地 443，并不代表监听入口被某个客户端独占。排查时要同时保留命令执行的主机、时间和客户端源端口，才能把状态快照与抓包对应起来。这里先掌握 LISTEN、SYN-SENT、ESTABLISHED 的观察意义，不需要背诵完整状态机。

6 看本机：监听、已建立连接与临时端口

在 Linux 上，ss -lntu 用于列出 TCP、UDP 的监听或接收入口，-n 要求保留数字地址与端口，避免名称转换干扰判断。以下输出省略部分列；真实系统的排版和字段可能略有差异：

$ ss -lntu
Netid State  Local Address:Port   Peer Address:Port
udp   UNCONN 0.0.0.0:123          0.0.0.0:*
tcp   LISTEN 127.0.0.1:8080       0.0.0.0:*
tcp   LISTEN 0.0.0.0:443          0.0.0.0:*

先读 Netid，再读 State 和 Local Address:Port。TCP 的 LISTEN 是等待新连接；UDP 的 UNCONN 不能翻译成“服务故障”，因为普通 UDP 接收入口本就没有 TCP 握手状态。127.0.0.1:8080 只绑定本机回环地址，其他主机不能直接通过服务器外部地址访问它。0.0.0.0:443 表示绑定本机所有 IPv4 地址，但仍受路由、防火墙等条件约束。监听表中的 Peer 通配项表示没有指定具体客户端，不能把星号当成实际连接。

ss -nt 则帮助观察当前 TCP 套接字，默认不把普通监听入口作为主要列表。客户端上可能看到：

$ ss -nt
State        Local Address:Port      Peer Address:Port
ESTAB        192.0.2.10:53124         198.51.100.20:443
SYN-SENT     192.0.2.10:53125         198.51.100.20:8443

ss 常把 ESTABLISHED 缩写为 ESTAB。第 1 行表示本端 53124 到对端 443 的连接已经建立，第 2 行表示另条连接还在等待握手响应。若在服务器观察对应的第 1 条连接，Local 会变成 198.51.100.20:443，Peer 则是 192.0.2.10:53124。因此 Local 永远相对于执行命令的主机，不是永远代表客户端。复制输出时写清“客户端执行”或“服务端执行”，比只贴状态名更有用。

假设某系统配置的临时端口范围为 32768–60999，53124 落在其中，但仅凭编号仍不能断定它一定由系统自动分配。应用可以主动绑定本地端口，配置也可以改变。通常重试连接会换用另个临时端口，抓包时只盯住上次的 53124 可能漏掉新尝试。需要定位所属程序时，可在权限允许的环境补充 ss -lntp，查看进程信息；权限不足导致信息缺失，不代表端口没有拥有者。

7 常见坑：把 TCP 当应用成功、把 UDP 当连接、端口与服务混淆

nc -vz 198.51.100.20 443 成功，通常只证明这次 TCP 连接尝试成功。它没有验证 TLS 证书、HTTP 路径、身份认证，也没有检查返回内容。服务端即使接受连接后立即关闭，也可能先让连接探测显示成功。若目标是网页健康，应使用符合应用协议的请求，检查状态码和必要内容；若目标是文件推送，则应核对应用确认与文件校验结果。不同的健康检查应写清自己覆盖的层次。

UDP 程序也可能调用 connect，但这种“连接”主要是本地套接字选择默认对端、限制接收来源以及关联错误信息的便利机制。它没有自动交换 SYN、SYN-ACK、ACK，也不能证明远端已经准备好。因此 nc -u 显示某种成功提示时，不能照搬 TCP 的解释。要验证 UDP 服务，应发送符合该服务协议的请求，并观察预期响应；如果设计上没有响应，就需要对端接收日志或计数等其他证据。

“80 端口空闲”通常只表示当前检查范围内没有相应的端口占用，不能说明 HTTP 健康。服务可能在 8080，也可能根本未启动；即使 80 正在监听，程序也可能配置错误。端口号是约定，不是内容检测器：在 80 上运行其他协议仍然可能绑定成功。应同时核对传输协议、监听地址、配置端口和预期应用协议，尤其不要把本机回环测试成功直接写成外部用户访问成功。

防火墙处理方式也会改变症状。丢弃 SYN 通常使客户端等待并重试，最后超时；主动拒绝若返回 TCP RST，常表现为 Connection refused。某些拒绝方式返回 ICMP 错误，客户端文字可能不同，不能把所有 reject 都强行解释成同种输出。没有监听的 TCP 端口也常由目标系统回复 RST。因此“拒绝”提示有明确负面响应，却还不能单靠客户端文字定位是哪个设备或规则生成。

还有个容易遗漏的条件是观察时间。服务刚重启时，第 1 次探测可能拒绝，第 2 次已经成功；先前捕获的状态也不一定描述当前故障。应把目标地址、端口、协议、探测时间与结果放在同条记录中。如果使用代理或地址转换，还要说明在哪侧观察，否则不同位置看到的五元组可能不同。这样才能比较相同尝试，而不是把互不相干的成功与失败拼成结论。

8 案例：同一功能用 TCP 还是 UDP

设园区要给 20 台设备下发配置，并每秒收集 1 次设备温度。“设备通信”并不能直接决定协议；配置下发和温度采集对结果的要求不同。先给每种消息写明验收条件，再选传输方式，才不会把应用必需的机制遗漏在“以后优化”里。

配置文件大小为 200 KiB，接收方必须完整保存，缺少任意部分都不可启用。用 TCP 传送便于获得有序字节流，应用再添加长度、版本、校验值和提交确认。传输完成但没有收到应用确认时，发送方不能盲目判断已生效；重试还需携带配置版本，避免重复提交带来副作用。文件同步也类似：TCP 负责传输恢复，文件校验与原子替换由应用决定。稳定配置指令即使只有 80 B，也不能仅因消息短就改用无恢复机制的 UDP。

温度消息若每条 32 B，每台每秒 1 条，20 台设备每秒产生 640 B 的应用负载，尚未计入各层首部。假设允许偶尔缺测，且界面只展示最近值，可以采用 UDP 并附加设备标识、序号和采样时间。若 5 秒没收到更新，界面必须显示数据过期，不能把旧温度继续冒充当前值。若业务升级为报警留痕，每条异常都必须确认接收，则需要重新设计确认、补报与存储，或选用适当的可靠传输方案。

UDP 广播发现通常限制在合适的本地广播域，不应期待路由器默认把它转发到所有网段；应限制发送频率与响应规模。TCP 不提供广播式连接，但应用可以通过目录服务发现地址后逐个连接。所谓“NAT 友好”也不是协议的永久标签，实际策略、发起方向和保持时间都要验证。若示例 UDP 映射在空闲 30 秒后失效，40 秒才来的主动回包可能无法按原路径送达；这提醒我们测量环境，而不是套用该数值。选择应说明机制与验收条件，不能只写“实时用 UDP，重要用 TCP”。

9 排查案例：连接被拒绝、超时与重置分别说明什么

症状是客户端访问 https://198.51.100.20:8443/health 失败。先固定目标与测试窗口，并确认此次直连、不经过代理。示例用 --noproxy '*' 排除常见环境代理的影响，--connect-timeout 3 限制连接阶段等待时间，--max-time 5 限制整个请求。以下是不同故障分支的节选，不能当作同次测试的连续输出；RST 标志、源端口和时间必须与当前尝试对应。

路径 A：客户端立刻收到 Connection refused。

$ curl -v --noproxy '*' --connect-timeout 3 --max-time 5 https://198.51.100.20:8443/health
* Trying 198.51.100.20:8443...
* connect to 198.51.100.20 port 8443 failed: Connection refused
curl: (7) Failed to connect to 198.51.100.20 port 8443

在授权的服务器上，同时核对监听项。以下命令只筛选本地 TCP 8443；列标题后没有条目，表示该快照中没有匹配的监听入口：

$ ss -lnt 'sport = :8443'
State Recv-Q Send-Q Local Address:Port Peer Address:Port

客户端抓包可使用 tcpdump -nn 'host 198.51.100.20 and tcp port 8443'，通常需要相应权限。与此次连接对应的代表性响应是：

10:00:00.002 IP 198.51.100.20.8443 > 192.0.2.10.53124: Flags [R.], seq 0, ack 1001, win 0, length 0

RST 响应与空监听快照共同支持“访问的端口没有提供 TCP 监听”的判断。先核对配置是否其实使用 443；若应当使用 8443，则检查服务是否启动、绑定是否正确，再在正确地址上复测。证据边界是：客户端看到的 RST 不能独自排除中间设备主动拒绝；服务器快照也只覆盖该主机、该时刻和该网络环境。若请求实际经过转发或容器端口映射，还需核对对应入口，不能看见空列表就随意重启其他服务。

路径 B：客户端等到连接超时，同样的服务端命令却能看到监听。

$ curl -v --noproxy '*' --connect-timeout 3 --max-time 5 https://198.51.100.20:8443/health
* Trying 198.51.100.20:8443...
* Connection timed out after 3001 milliseconds
curl: (28) Connection timed out after 3001 milliseconds
$ ss -lnt 'sport = :8443'
State  Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0      128    0.0.0.0:8443       0.0.0.0:*

客户端抓包窗口内反复出现 SYN，没有看到匹配的 SYN-ACK 或 RST；其中 1 行为：

10:05:00.000 IP 192.0.2.10.53125 > 198.51.100.20.8443: Flags [S], seq 2000, win 64240, length 0

这条 SYN 只证明抓包点观察到了出站尝试；“没有响应”必须结合覆盖完整等待窗口的记录，不能靠单行输出得出。此时客户端的证据边界是“本端未观察到握手响应”，尚不能认定服务器防火墙丢包。应在服务端同步抓包：若看不到 SYN，沿入口路径检查；若看到 SYN 并发出了 SYN-ACK，则检查返回路径及客户端接收条件；若看到 SYN 却没有响应，再检查服务端过滤规则及相关状态。监听存在也不保证外部报文一定能到达监听入口。

连接重置还要结合发生阶段理解。若先看到连接成功，之后 curl 报 Recv failure: Connection reset by peer，说明读取期间遇到了重置，不能再按“始终没有监听”处理。应用异常退出、主动中止或中间设备策略都可能参与。先确认建立连接的记录，再检查重置前已经发送了什么，例如是否把 HTTPS 请求发到了只接受明文 HTTP 的入口。重置报文说明该连接被中止，不会附带完整的业务原因；进程日志和协议配置才能进一步解释为什么。

放进方案里

把服务端口计划写成另位同事可以执行的记录。每个入口至少包含传输协议、监听地址、端口、发起方、预期应用协议和健康检查方法。例如配置推送填写“TCP；198.51.100.20；8443；管理端主动连接；HTTPS；请求指定健康路径，检查证书、状态码和必要内容”。若只允许本机访问，就明确填写 127.0.0.1；若监听所有 IPv4 地址，就记录暴露范围及访问规则。不能只写“开放 8443”，让实施者猜协议和服务含义。

为每种消息补上交付要求。配置文件注明长度、校验、版本与生效确认，明确重试是否可能重复执行；遥测注明允许缺测比例、序号、过期时间和是否补报。选择 UDP 时，写明数据报大小以及如何发现缺失；选择 TCP 时，写明消息分帧与业务响应，避免把连接建立当成保存成功。涉及跨网段、NAT 或防火墙时，注明观察位置和需要验证的方向，不把局域网测试结果直接推广到生产路径。

排查预案要把症状与首个探针配对。连接被拒绝时，先核对服务端对应协议与地址的监听，并检查是否收到拒绝响应；连接超时时，先保留客户端连接输出与覆盖等待窗口的抓包，再对照服务端是否收到 SYN。建立后重置时，先确认中止阶段，再查应用协议和日志。分别写出超时只说明等待期限内未完成目标动作、拒绝说明出现明确负面响应，防止执行者把所有失败都归入同种修复。

验收时，把方案交给未参与编写的同事，请其针对文件同步和温度遥测各选 TCP 或 UDP，说明选择条件，并说出故障时首先在哪台主机运行哪条命令。再让其区分“端口监听”“连接建立”“应用健康”各需什么证据。若仍须口头补充目标地址、协议或成功标准，就继续完善记录；可交接的方案应让第 1 次探测直接产生可用于缩小范围的证据。

10 小结：走向 DNS（S18）

IP 帮助数据到达主机，传输层结合端口等信息把通信交给端点。UDP 保留数据报边界，恢复与时效策略交给应用；TCP 提供有序字节流，应用仍需定义消息与业务成功。五元组、握手状态和 ss 输出，让这些区别变成可观察的事实。

自检：53124 到 443 的连接中，哪端通常监听？写入 40 B 和 60 B 为什么可能只读取 1 次？只抓到 SYN 时，能否断定服务未启动？能分别解释这些问题，就可以带着端点、消息和证据边界的视角进入 S18 DNS，观察域名查询如何使用 UDP 与 TCP。

下一课转向 S18 DNS：把本章验收过的结论带进后续主题，写成可检查的方案约束。