报文交换 vs 分组交换：串行与并行如何决定传输效率

前阵子帮朋友调一个内网传输的老问题：同样的百兆链路，同时传二十个小文件居然比传一个几百兆的大文件还要快。乍一听不合直觉，小文件多路并发，在网络里是典型的“分组并行”；大文件虽然被TCP拆成了段，但应用层一旦一次性提交太大块，或者中间环节配置不当被强制整包处理，传输节奏就会滑向“串行搬运”的泥潭。报文交换（串行）和分组交换（并行）这对概念，正好把这两种命运解释得清清楚楚。

这篇文章我会从“为什么必须要有交换”讲起，把报文交换为什么串行、分组交换为什么并行、同样数据两种交换到底差多少时间，用算例一笔一笔算给你看；最后聊聊抓包工具里能观察到的分组交换细节。适合正在啃计算机网络教材的学生、做网络开发或者运维的工程师，以及所有被“大文件慢、小文件快”折磨过的人。看完你至少能回答三个问题：中间节点为什么要存储转发、分组头到底值不值得付、为什么今天互联网几乎全是分组交换的天下。

1. 为什么会有交换：从直连到存储转发的必然选择

1.1 N个端点两两直连是场灾难

先往回退一步。如果世界上只有两台设备要通信，拉一根网线就完事。但设备一多，问题立刻来了：三台设备两两直连需要3条线，四台需要6条，五台需要10条。N台设备两两直连需要的线路数量是N(N-1)/2，这个数字增长得极快——100台设备就要4950条线路，1000台就是差不多50万条。

每个设备还得配上对应的接口，线的成本、接口的成本、机房里缠绕成意大利面的物理线路，这些直接让全网状直连的方案彻底破产。所以网络必须引入一个中间角色：交换节点。每个设备只连到最近的交换节点，由节点帮你把数据转交给目标设备。这就好比一个镇上所有人家都把信送到邮局，邮局再按地址分发，而不是每家人都直接修一条路通到别人家门口。

有了交换节点，数据从源设备出发，经过一个个中间节点，最终到达目的设备。这个“经过”的过程就叫转发或者交换。中间节点扮演的角色不同，交换的方式也就有了本质区别。早期电话网用的是电路交换，先拨号建立一条从源到目的地的专用线路，通话期间这条线路被一对用户独占，挂断才释放；后来数据通信发展起来，人们发现数据是突发的，不是像语音那样持续占用，于是报文交换和分组交换相继登场。

1.2 三种交换方式：一次说清电路、报文、分组

先说电路交换，最典型的例子就是老式电话。通话前要“占线”建立连接，建立好之后两个人说话，中间的线路资源就固定分配了，不管你有没有说话，带宽都留着给你。好处是延迟稳定、没有排队，坏处是线路利用率低——你沉默的时候，那段带宽就浪费了。数据通信追求效率，所以后面两种方式都改成了“存储转发”思路：中间节点先把数据收下来，再往下一个节点发，不用提前占路。

报文交换（Message Switching）和分组交换（Packet Switching）都属于存储转发，但关键区别在于：报文交换以“整条报文”为存储转发单位，分组交换先把报文“切片”，以“小分组”为存储转发单位。只看教科书定义容易觉得这两者只是颗粒度不同，但正是这一个颗粒度差异，让它们在延迟、带宽利用率、容错能力上走向了完全不同的方向——也就是标题里说的“串行”和“并行”的分野。

补充一点：报文交换今天在日常网络里已经很少以纯粹形态出现，但在理解分组交换为什么先进时，它是最好的对照组。当年的电报网络、早期的某些消息系统，就是典型的报文交换思路。

2. 报文交换的串行本性：整包占路、后车排队

2.1 收满再走：中间节点是“完整接收”的搬运工

报文交换的工作方式特别像货运列车：一整列火车从始发站出发，到中间站之后，必须等整列车都停稳、货物清点完毕，再整列发往下一站，没有任何一节车厢可以提前走。对应到网络里，就是一个应用要发送一大段数据（可能几兆甚至几十兆），中间节点必须把这整段数据完整接收下来，存到缓冲区里，校验没问题，再整体转发到下一跳。

这里的关键词是“完整接收”。假设链路速率是1Mbps，你要传一个10Mb的报文，那中间节点收完这个报文就需要整整10秒。在这10秒里，这个报文的头还没到下一站呢，它“占据”了从源到当前节点这一段链路。哪怕下一个报文已经等在源节点的发送队列里，也得老老实实等着，因为链路是共享的，现在全被这个巨无霸报文占着。

我的一个体会：很多刚从“应用层编程”视角看网络的人，天然以为数据是像水管里的水一样流过去的，源端一边发、目的端一边收。报文交换打破这个直觉——存储转发的本质就是“收一批、走一批”，中间节点像一个检查站，不允许有任何一辆车没到齐就先发车。

2.2 排队等待与链路浪费：串行不是慢一点，而是慢很多

“串行”在这里有两层含义。第一层，在一个节点的输出链路上，报文是一个接一个排队发送的，谁先到谁先走，不存在同时发送的情况，这是最朴素的串行；第二层更关键——因为一个报文在中间节点要整体等待“收满”，它占住链路的时间非常长，其他报文只能串行累积等待。一个10秒的报文堵在前面，后面排100个正常的小报文，每个哪怕只要0.1秒，串行下来也要额外等10秒，这种排队延迟会迅速放大。

链路浪费也是报文交换的一大毛病。报文交换的源端发送是间歇的：中间节点收报文的10秒里，源端发完后其实没事干了，源到节点一的链路空闲；等节点一转发时，源到节点一的链路还是空闲的。你发现了吗，一整条端到端的路径上，同一时刻几乎只有一段链路在干活，其他链路都在等。用经济学的话说，资源利用率极低。

2.3 报文交换的算例：10Mb数据走5跳链路的50秒

做一道很简单的算术题感受一下。假设数据量是10Mb，链路速率是1Mbps，从源到目的地需要经过4个中间节点，也就是总共5段链路（5跳）。报文交换方式下：

• 每一跳的传输时间 = 数据量 / 链路速率 = 10Mb / 1Mbps = 10秒
• 端到端传输时间 = 5跳 × 10秒 = 50秒
• 加上少量传播时延和处理时延，结果还是约50秒

为什么是跳数乘以单跳时间？因为报文交换是“整包收完再发”，第1跳花10秒，第2跳花10秒……每一跳都要完整重传一次整报文。50秒这个数字非常直观：慢不是因为链路速率低，而是同一个10Mb报文被重复发送了5次。中间节点越多，报文越大，这个重复惩罚就越致命。

3. 分组交换的并行基因：切片、交织与独立选路

3.1 切片是并行性的来源：分组头和载荷

分组交换的做法就激进多了：先把大报文切成一堆小分组，每个分组只带一小段有效载荷，然后给每个分组加上一个头部（Header），头部里写着目的地址、源地址、序号这些控制信息，最后这些小分组独立地在网络里穿行。

分组的大小有上限。在今天的以太网环境里，典型的上层分组要适配MTU（最大传输单元）1500字节，也就是说一个分组最大约1.5KB。一个10Mb的报文，切成传统大小的分组，能切出几千个。切完以后，发送端像流水线一样一个接一个地把分组发到链路上：第一个分组还在中间节点转发时，第二个分组已经在第一段链路上跑了，第三个分组已经在源设备网卡里准备发送了。

这里有个特别重要的点：分组交换的“并行”不是说多个分组同时占住同一段链路（物理链路上同一时刻仍然只有一个分组在传输），而是说——整个报文被切片之后，不同分组可以处于整个路径的不同位置、不同链路上，彼此不阻挡地“流水线式”前进。这就像搬家公司把一车货物拆成多个小箱，一辆小货车先出发送第一箱，第二辆紧跟其后送第二箱，车队在路上首尾相接、不停歇地跑，而不是非得等第一辆到了再让第二辆装车出发。

3.2 分组级流水线：节点同时收发，链路不再空等

你可能要问：中间节点不是也要“收满一个分组再转发”吗，怎么就不等了？关键在分组够小。节点转发一个小分组只需要极短时间，比如一个10Kb的分组在1Mbps链路上只花10毫秒。源端持续不断地把分组喂进来，节点一边收一个、一边发前一个，只要输出链路没有被更长的包堵死，它的接收和转发是可以装配线一样重叠进行的。

再算一遍同样的数据量。10Mb数据拆成1000个10Kb分组（忽略头部开销简化），链路依然是1Mbps，单跳传输时间变成10Kb/1Mbps = 10毫秒。第一个分组从源到终点要经过5跳，也就是5×10毫秒=50毫秒；但这期间源端没有闲着，它每10毫秒发出一个新分组。到第9.99秒，最后一个分组才从源端发出，它再经过5跳的50毫秒，大约10.04秒到达终点。

看出来差别了吗？报文交换是50秒，分组交换是10.04秒，将近5倍的差距。本质原因是：报文交换里这10Mb数据每次都是从起点完整重发到终点，重复搬运5次；分组交换里只有第一个分组真正经历了“逐跳完整传输”的起步延迟，后续分组全靠流水线跟上来，整个10Mb数据的“传输时间”基本就是发送时间本身，和跳数无关了。

3.3 独立选路：真正意义上的多路并行

分组交换还有一层更强的并行：每个分组头部都带着完整的目的地址，可以独立选择路径。这意味着同一批分组不一定走相同的路由——某个分组走A路线，另一个分组走B路线，它们在物理上是真正并行的，共享网络的总带宽，而不是都挤在同一条链路上排队。

独立选路的直接好处是容错和负载均衡。某条链路断了或者堵了，后续分组可以自动绕道；多条路径同时传数据，整体吞吐能被拉高。代价是分组会乱序到达：先发的分组绕了远路，后发的分组抄了近路，到达顺序就不一定是发送顺序了。这件事恰恰解释了为什么互联网的传输层需要TCP：TCP用序号把这些乱序的分组重新排好，应用层看到的数据才是有序的。

所以“分组交换的并行”可以概括为三层：一是分组级流水线，让同一报文的不同分组在不同链路上串行接力却不互相等待；二是源端连续注入，让链路利用率最大化；三是独立选路，让大批分组在网络里多路径并发。而报文交换只有一条路走到黑，每个节点都必须等整包收完，这就是串行与并行最本质的分野。

4. 同样一段数据，两种交换差出几倍？算给你看

4.1 分组交换的端到端延迟推导

把上面的例子写成通用公式，方便你以后遇到自己的场景直接套用。设报文大小为M（bit），分组大小为P（bit），链路速率为R（bit/s），端到端经过H跳，忽略传播时延和处理时延。

报文交换端到端延迟：T_message = H × (M / R)

分组交换端到端延迟：分组个数 n = M / P，单跳传输一个分组的时间 t = P / R；T_packet ≈ (n + H - 1) × t

用之前的数字验证：M=10Mb，P=10Kb，R=1Mbps，H=5；T_message=5×10s=50s；n=1000，t=10ms，T_packet=(1000+5-1)×10ms=10.04s。两个公式都能对上。注意分组交换公式里“+H-1”的含义：第一个分组要多走H跳的流水线建立时间，剩下的分组基本就是排队跟着走，所以跳数的影响只被算了一次，而不是每一跳都重复整个数据量。

这套公式在真实网络调优里非常有用。比如你看视频卡顿，如果抓包发现是带宽低，加带宽立竿见影；但如果是RTT（往返时间）大、又有大量小分组要传，那瓶颈其实是“起步延迟”被反复计算，加再多带宽也没有用。这两种情况对应公式里的哪一项，一眼就能判断。

4.2 报文与分组的全面对比表

把两种方式从几个关键维度拉出来对比：

结论很清楚：分组交换几乎在所有衡量指标上都赢，唯一输的就是头部开销。但互联网选择它，正因为那点头部开销换来了延迟、利用率、容错三方面的巨大收益。

4.3 为什么“分组头开销”是值得付的保费

每个分组头部占用一些字节，以太网常见的开销是20字节左右的IP头加上20字节左右的TCP头。一个1500字节的帧里，头部占了40字节，大约2.7%的额外开销。有人会觉得这是浪费，但换个角度想：这相当于每个包裹都贴了张写着地址和序号的快递单。没有这张单子，包裹就不能独立运输、不能走不同路线、不能在中间节点掉头重发。网络里没有集中式的中央调度，分组头就是让每个分组“自动驾驶”的地图和导航。

而且头部开销在实际网络里几乎可以忽略——传输的数据量一旦变大，固定开销就被摊薄了；链路一旦到千兆万兆，2.7%的开销远小于串行等待带来的几十倍延迟放大。这是一笔非常划算的“保险费”。

5. 在真实网络里看分组交换：抓包与分片现场

5.1 MTU与分片：以太网帧1500字节的切片

很多人学完分组交换还是觉得它很抽象，其实打开抓包工具看一次就懂了。你发一个普通网页请求，抓包工具里能看到一条条TCP流被切成了无数个分组（数据包），每个分组在网络层都有一个IP头，里面带着源地址、目的地址、标识符、分片偏移量和DF标志。以太网链路的MTU是1500字节，大于这个数值的上层大包会被IP协议切分成多个分片，每个分片都保持独立的IP头，到目的地后再按“分片偏移”重组。

把这个现象对应到原理上：IP分片就是分组交换“切片”概念的最直接体现。大块数据无法塞进一个帧，就拆成多个分组分别传输；每个分片都是独立路由的，可能在网络里走不同路径到达。以前我调试一个跨网传输问题，抓包看到一批分片包的序号是交错的，目的端要等凑齐了才重组——那一刻我才真正理解“分片是分组交换的常态”，而不是异常。

注意：具体网络里追求性能时，大多数场景会尽量避免IP层分片。TCP会通过MSS协商把段大小控制在有效载荷1460字节左右，正好适配1500字节的MTU。这就是为什么TCP建立连接时要协商MSS——它本质上是一次“预切片”，避免真实数据在IP层再被二次分片。二次分片浪费带宽且一旦丢一个分片就得重传整组，性能很吃亏。

5.2 乱序、重复ACK与重组：独立选路的代价被TCP接住

抓包时另一个常见现象就是乱序和重复确认（Dup ACK）。一个TCP连接在传输大量数据时，如果你看到目标主机的接收端回复的ACK序号没有按顺序增长，比如收到了seq=1000的段之后，没有马上收到seq=2000，而是先收到seq=1800，就说明这两个分组走了不同的路径或者经历了不同的排队时延，先发的不一定先到——这就是分组独立选路的直接证据。

分组丢失了怎么办？接收端会连续发送重复的ACK，告诉发送端“我还在等某个序号”，发送端连续收到三个重复ACK就快速重传，不需要傻等超时。这套机制和分组交换“不保证有序、不保证不丢”的底层特性是对应着的：网络层本身就是“尽力而为”，靠TCP的序号、ACK、重传、重组把上层的数据重新变成可靠有序的字节流。

我特别推荐做一次完整的抓包实验：用浏览器下载一个大文件，同时抓包，你能看到成千上万个分组以近乎均匀的时间间隔被确认，偶尔出现一两个乱序包，TCP层波澜不惊地把它重排回去。这比背十遍“分组交换是存储转发的”都管用。

6. 实操中的几条体会

聊完原理，说点这几年实际调网络攒下的体会。

第一，中间节点的缓冲区根本不是越大越好。分组交换依赖节点缓存来处理“收组转发”的瞬时冲突，但缓冲区太大反而坏事：TCP的拥塞控制是靠丢包和延迟信号的，路由器缓冲区把临时拥塞全“吞”了，发送端感知不到拥塞，继续猛发，结果就是缓冲区排队的延迟越来越大，这就是很多人讲过的“缓冲区膨胀”。报文交换时代那种“整包排队”的原始问题，在分组交换里换了一种形态继续存在，只不过颗粒度变小了。调试延迟敏感应用时，看一眼路由器队列深度，经常能发现真相。

第二，应用层并行下载、多连接传输能提速，底层逻辑就是制造更多分组流。多个TCP连接同时下载，等于让网络里同时存在多个分组的“流水线”，每个连接独立滑动窗口，链路利用率就被拉高了。单连接传大文件时，如果RTT大、丢包率高，滑动窗口经常被打满，链路利用率上不去，整体速度就慢。这不一定是带宽不够，而是“并发流水线”没有被充分建立起来。

第三，给正在学网络的朋友一个建议：不要停留在“记住报文交换慢、分组交换快”这个结论上。把那张传递函数公式写在纸上，把10Mb/1Mbps/5跳的例子亲自算一遍，再用抓包工具看一次真实的分组流，这套概念就再也忘不掉了。很多时候你觉得网络知识虚，不是知识假，而是没有把抽象的数字和现实中那个一闪一闪的网卡指示灯连起来。

报文交换和分组交换的对比，表面上是一个教科书考点，实质上它是整个互联网设计哲学的一个缩影：整包串行是简单但低效，切片并行是复杂但高效。复杂度并没有消失，它从网络层转移到了传输层（TCP负责排序、重传、去重），用一点协议开销换来了整个网络的效率和韧性，这笔买卖做得值。