计算机网络 · 从零开始

外观

架构抉择与显微镜：什么时候选 TCP/UDP？怎么用 Wireshark 抓出传输故障？ ​

恭喜你！学到这里，你已经完整掌握了传输层的两大参天巨木——极简高效的 用户数据报协议（UDP），以及精密可靠的 传输控制协议（TCP）。

然而，在真实的企业系统研发与网络运维中，面对形形色色的业务场景，架构师和网络工程师必须回答两个现实问题：

  1. 架构选型：为什么某些即时通信软件、竞技游戏甚至新一代 HTTP/3 协议，宁可不要操作系统内置的 TCP，也要自己在 UDP 之上从零打造可靠机制？
  2. 故障诊断：当用户抱怨“网络卡顿、网页半天打不开”时，网络工程师如何像放射科医生查看 X 光片一样，通过 Wireshark 抓包，精准诊断出连接是卡在三次握手超时、遭遇了连续重传，还是触发了零窗口死锁？

本课将作为阶段 4 的集大成实战课，为你补齐从理论走向实战的最后一块拼图。

学完本课后，你将能够：

  1. 运用 传输层协议选型决策树，为不同业务场景（网页、文件、语音、游戏、监控）快速选出最优传输方案。
  2. 阐述 现代互联网演进中 HTTP/3（QUIC）为什么从 TCP 转向 UDP 的深层原因（彻底终结“队头阻塞”与握手延迟）。
  3. 熟练编写 Wireshark 传输层高频过滤语法，并使用“追踪 TCP 流（Follow TCP Stream）”完整还原会话报文。
  4. 准确诊断 Wireshark 专家分析标记（TCP Dup ACK、Retransmission、ZeroWindow、RST）对应的真实网络故障。

1. TCP vs UDP 全维度深度对照表 ​

在做任何架构决策前，我们必须对两者的性格特质了如指掌：

考察维度TCP（传输控制协议）UDP（用户数据报协议）
连接机制面向连接（必须先通过三次握手建链）无连接（拿起来直接发，不握手）
可靠性保证100% 可靠（通过序号、累计确认、自动重传保证不丢不漏）尽力交付（不确认、不重传，可能丢包）
报文顺序保证按序递交（乱序到达时在缓冲区重排后再提交给应用）不保证顺序（先发的可能后到）
首部开销至少 20 字节，包含扩展选项最高可达 60 字节极简固定 8 字节
流量控制具备（通过接收端通告的滑动窗口 rwnd 控制发送速度）无（发送速度全由应用层支配）
拥塞控制具备（慢启动、拥塞避免、快重传、快恢复动态调速）无（即使网络严重拥堵依然全速倾泻）
通信模式仅支持一对一单播双向通信支持一对一单播、一对多组播、全网广播
数据边界面向字节流（无边界，多消息可能黏在一起）面向报文（保留边界，一发对应一收）

2. 传输层协议选型决策树 ​

在为新系统选择传输层支撑时，可以遵循如下黄金三问：

传输层协议选型决策树

为什么 HTTP/3 最终抛弃了 TCP，投奔 UDP（QUIC）？ ​

这是现代互联网架构中最震撼的技术变革：从 1990 年代起，万维网的 HTTP/1.0、HTTP/1.1、HTTP/2 全部构建在 TCP 之上。但在 2022 年正式标准化的 HTTP/3 却毅然决然地改跑在 UDP 之上的 QUIC 协议 中！

背后的根本痛点正是 TCP 的“队头阻塞（Head-of-Line Blocking）”：

  • 在 HTTP/2 中，一个 TCP 连接可以并发传输几百个网页资源（图片、CSS、JS）。
  • 但在底层的 TCP 看来，这几百个资源只是排成一长串的无差别字节流。
  • 如果其中一张无足轻重的小图标在传输时丢了一个分片，TCP 为了维持严格的按序递交，必须强行把后续已经收到的所有其他资源全部扣留在内核缓冲区中，等待丢掉的小图标重传成功！
  • 这一机制导致整个网页的所有请求瞬间集体冻结。
  • QUIC 解决方案：基于无拘无束的 UDP，在用户空间自行实现轻量级的多流多路复用。每个数据流独立重传，任何一条流丢包绝不波及其他流，同时实现了 0-RTT 极速建链，彻底治愈了队头阻塞！

3. Wireshark 实战：显微镜下的传输层 ​

Wireshark 是网络工程师最强大的利器。它直接挂接在操作系统的数据链路层或网络层驱动上，将网卡收发的每一帧原始报文巨细靡遗地呈现在屏幕上。

1. 必背常用显示过滤语法（Display Filters） ​

text
# 筛选特定端口的所有流量
tcp.port == 80 || tcp.port == 443

# 捕捉所有发起三次握手的 SYN 报文（SYN 置 1 且 ACK 置 0）
tcp.flags.syn == 1 && tcp.flags.ack == 0

# 捕捉连接断开的挥手 FIN 报文
tcp.flags.fin == 1

# 捕捉所有发生连接复位的异常 RST 报文
tcp.flags.reset == 1

# 专门揪出网络中所有的 TCP 超时重传报文
tcp.analysis.retransmission

# 专门揪出所有的连续重复确认报文（可能触发快速重传）
tcp.analysis.duplicate_ack

# 揪出所有的零窗口通知报文（接收端内存告急）
tcp.analysis.zero_window

2. 神技：追踪 TCP 流（Follow TCP Stream） ​

在茫茫数万条杂乱的数据包中，如果你想看某一个网页请求的完整往返对话：

  • 鼠标右键点击该连接的任意一个 TCP 报文；
  • 选择 Follow → TCP Stream（追踪 TCP 流）；
  • Wireshark 会立即自动根据该连接的 五元组（5-Tuple） 提取出属于这一条会话的所有包，并自动过滤掉底层的 ACK 应答与报文头，将应用层的明文请求与服务器响应以红色（客户端请求）和蓝色（服务端应答）完整拼装展示在弹窗中！

4. Wireshark 专家分析常见异常与排障指南 ​

Wireshark 的 Expert Information（专家信息）会用黑色、红色或黄色高亮标注出网络中的非正常通信状态：

1. TCP Retransmission（超时重传） ​

  • 现象：Wireshark 显示黑色背景，标记 [TCP Retransmission]。
  • 根因：发送端发出的报文在 RTO 超时时间内没有收到 ACK，触发了重新发送。通常表明物理链路存在电磁噪声干扰丢包、接口 CRC 校验错误、或者途中某台路由器队列溢出。

2. TCP Dup ACK（重复确认） ​

  • 现象：显示 [TCP Dup ACK 15#1]、[TCP Dup ACK 15#2]...
  • 根因：接收端收到了不连续的高序号报文（存在空洞），被迫连续回复相同序号的确认。若连续出现 3 个，通常随后就会紧跟着一个带有 [TCP Fast Retransmit] 标签的快速重传包。

3. TCP ZeroWindow（零窗口通知） ​

  • 现象：接收端回复的包被标注为 [TCP ZeroWindow]。
  • 根因：接收端主机的 CPU 负载过高、或者应用程序卡死导致消费速度远低于数据到达速度，接收缓冲区被彻底耗尽。排查重心应放在对端应用程序的代码死锁或高 CPU 占用上，而不是排查网线。

4. TCP RST（连接复位） ​

  • 现象：报文中 RST 标志位置 1，Wireshark 标记 [RST, ACK]。
  • 常见原因：
    1. 客户端访问的目标端口在服务端根本没有进程在监听（操作系统直接回送 RST 拒客）；
    2. 防火墙安全策略检测到非法内容阻断通信，伪造双方身份向两端注入 RST 强行斩断连接；
    3. 对端服务程序突然异常崩溃闪退，操作系统的套接字被异常关闭。

5. 课后核心测验 ​

课后巩固 · 练习 · 单选

某大型多人在线（MMO）射击游戏需要传输玩家每毫秒的瞬时射击坐标与跳跃动作，开发团队最应当优先选择哪种传输层方案？为什么？

课后巩固 · 练习 · 单选

在 Wireshark 抓包工具中排查网络性能劣化时，如果你连续观察到 3 个相同的“TCP Dup ACK”，这通常意味着什么？

6. 阶段小结与下一阶段预告 ​

热烈祝贺你！阶段 4 · 传输层的全部 5 门精要课程已全部圆满结课！

我们从端口号与套接字多路分用出发，对比了无拘无束的极简信使 UDP，深入剖析了 TCP 的三次握手、四次挥手、滑动窗口、超时重传与拥塞控制，并在 Wireshark 中掌握了实战排障神技。

但是，我们上网终究不是为了看纯粹的端口和序号。我们在浏览器里输入 https://www.huawei.com，电脑是怎么找到华为服务器的？网页代码是怎么下载并渲染出精美图片的？传输的数据是如何被 TLS 密码学严密加密的？

下一阶段，我们将正式登上网络世界的最顶层：阶段 5 · 应用层：DNS、HTTP/HTTPS 与端到端交付（第 27 课 ~ 第 31 课）！