1. 从一个让人抓狂的延迟说起
你有没有遇到过这种情况:晚上八点在家看视频,画面突然卡住转圈,你下意识看了一眼路由器,指示灯闪得挺正常,但就是卡。你可能会想,这破路由器是不是该换了。但如果你稍微懂一点网络底层的东西,就会知道问题大概率不在路由器本身,而在于它采用的分组交换存储转发机制正在经历一次拥塞。
这个标题看起来像是课本上的一个知识点,但它背后牵扯的东西远比想象中多。路由器为什么采用分组交换而不是电路交换,这个问题往浅了说是考试题,往深了说是整个互联网设计哲学的根基。搞明白这件事,你对网络的理解会从"能通就行"跃升到"我知道它为什么能通、什么时候会不通"。
这篇文章适合谁看?如果你是刚学计算机网络的学生,课本上那段话你可能背下来了但没真懂,这篇文章帮你把逻辑串起来。如果你是运维或者开发,平时跟网络打交道但没深究过底层机制,这篇文章帮你补上那块拼图。如果你只是好奇为什么打游戏有时候延迟突然飙高,这篇文章也能给你一个靠谱的解释。
我尽量不写成教科书,而是像一个搞了多年网络的人跟你聊他理解这件事的过程。涉及到的参数和计算我会给出推导,涉及到的设计取舍我会解释清楚为什么这么选而不是那么选。读完你至少能明白一件事:互联网今天长成这样,不是随便选的,是被逼出来的最优解。
2. 两种交换方式的本质差异
2.1 电路交换到底是怎么工作的
电路交换的思路特别符合直觉,它就是打电话的逻辑。你拿起电话拨号,运营商的交换机在你的电话和对方的电话之间建立一条专用的物理通路,这条通路在整个通话期间被你独占。通话结束,拆掉通路,资源释放。
这个过程分三个阶段:建立连接、数据传输、释放连接。建立连接的时候,沿途所有的交换机都要为这通电话预留资源——预留一条时隙、一段频段、或者一根线路。预留完了之后,数据从你这边发出去,沿着这条固定路径一路到达对方,中间不需要任何交换机做额外的决策。
电路交换最大的特点就是独占性。这条通路在你通话期间别人用不了,哪怕你俩都不说话只是拿着话筒发呆,资源照样占着。好处是什么?一旦通路建立,传输延迟极其稳定,因为路径固定、没有排队、没有竞争。传统电话网络就是典型的电路交换,通话质量一直很稳,不会出现说着说着声音忽大忽小的情况。
但问题也很明显。你打电话的时候,你说话的时间可能只占整个通话时间的40%,剩下60%是对方在说或者双方都在沉默。这60%的时间里,你占用的那条通路带宽全浪费了。对于语音这种对实时性要求极高、但对带宽利用率不敏感的场景,浪费就浪费了,能接受。但对于数据通信,这种浪费就是致命的。
2.2 分组交换的核心逻辑
分组交换走的是完全不同的路子。它不给你建立任何专用通路,而是把你的数据切成一块一块的"分组"(Packet),每个分组独立地在网络中传输。
每个分组里都带着目标地址(目的IP),路由器收到一个分组之后,看一眼目标地址,查一下自己的路由表,决定从哪个端口转发出去。下一个路由器收到之后做同样的事,一跳一跳地把分组往目的地送。整个过程就像寄快递:你把一个大件拆成多个包裹,每个包裹上写清楚收件地址,它们可能走不同的路线,到达顺序也可能不一样,但最终都能到。
这里的关键在于存储转发(Store-and-Forward)。路由器不是收到一个bit就立刻转发出去,而是先把整个分组收完、存下来、检查一下有没有出错、再查路由表决定往哪发。这个"存下来再转发"的动作就是存储转发的核心含义。
存储转发带来的直接后果是:每个分组在每一跳都会引入一定的处理延迟。但这个代价换来的是极高的灵活性和资源利用率。链路不再被某一条连接独占,所有用户的分组共享同一条链路,谁有数据谁就发,链路空闲的时候不会浪费。
2.3 一张表看清两者的区别
| 对比维度 | 电路交换 | 分组交换 |
|---|---|---|
| 连接建立 | 需要预先建立专用通路 | 不需要,直接发送 |
| 资源占用 | 通话期间独占链路资源 | 按需共享,统计复用 |
| 传输延迟 | 稳定、可预测 | 有波动,受拥塞影响 |
| 带宽利用率 | 低,空闲时浪费 | 高,链路可被多用户共享 |
| 故障影响 | 通路中任一节点故障则中断 | 可动态绕行,容错性强 |
| 适用场景 | 实时语音、传统电话网 | 数据通信、互联网 |
| 计费方式 | 按时间/距离 | 按流量 |
| 数据顺序 | 严格有序 | 可能乱序,需上层重组 |
这张表建议你真正理解每一行的含义,而不是背下来。因为面试或者考试的时候,考官真正想听的不是你背出了区别,而是你理解为什么会有这些区别。
3. 路由器为什么必须用分组交换
3.1 统计复用:让带宽不再浪费
这是最核心的原因。分组交换采用统计复用(Statistical Multiplexing),意思是链路的带宽不是预先分配给某个用户的,而是所有用户动态竞争使用。
举个具体的例子。假设一条链路的带宽是100Mbps,有10个用户共享。如果是电路交换,每个用户最多分到10Mbps,而且不管你用不用,这10Mbps都归你,别人抢不走。但实际上,10个用户不可能同时满速传输,大部分时间只有两三个用户在发数据。如果是分组交换,链路空闲的带宽可以被任何一个有数据要发的用户立刻使用,整体吞吐量可以远超每人10Mbps的限制。
我用一个更直观的计算来说明。假设每个用户有10%的时间在传输数据,传输时速率为10Mbps。电路交换下,每个用户固定分配10Mbps,链路总容量100Mbps刚好分完。分组交换下,10个用户同时传输的概率是0.1的10次方,几乎为零。也就是说,绝大多数时候链路都有大量空闲容量,实际能支撑的用户数远不止10个。这就是统计复用的威力——用概率换效率。
注意:统计复用的前提是用户行为相互独立,且不会同时满速传输。如果所有用户同时发起大流量传输,链路就会拥塞,延迟飙升。这就是为什么晚高峰网络会变慢的根本原因。
3.2 突发性流量:数据通信的本质特征
数据通信和语音通信有一个根本区别:数据流量是突发的。
你打开一个网页,可能瞬间产生几MB的流量,然后接下来几分钟你都在看内容,几乎没有流量。你发一条消息,可能就几KB的数据,发完就没了。这种"一会儿大量、一会儿为零"的模式就是突发性。
电路交换是为恒定速率的流量设计的。电话通话时,语音编码器每20ms产生一个语音包,速率恒定,电路交换刚好匹配这种模式。但数据通信的突发性意味着,如果用电路交换,你在不传输数据的时候占着链路纯属浪费,而需要传输的时候又可能觉得带宽不够。
分组交换天然适配突发性流量。你有数据就发,没数据就不占资源,链路可以同时服务大量突发性用户。这是路由器选择分组交换的第二个根本原因。
3.3 容错与鲁棒性:没有单点依赖
电路交换建立了一条端到端的专用通路,这条通路上的任何一个节点或者链路出问题,整个通信就断了。你得重新建立连接,而且如果故障节点还没恢复,新建的连接可能还是走同一条路。
分组交换没有这个问题。每个分组独立选路,如果某条链路断了,路由器会更新路由表,后续分组自动走另一条路。前面的分组可能已经到达目的地了,后面的分组绕了个弯也能到。这种去中心化的路由决策让整个网络极其鲁棒。
互联网的前身设计目标之一就是在部分节点被摧毁的情况下仍然能通信。分组交换的分布式路由机制完美满足了这个需求。虽然今天的互联网已经跟当初的设计目标不完全一样了,但这个容错基因一直保留着。
3.4 异构网络互联:什么都能跑
电路交换要求端到端的链路能够建立一条同构的物理通路。什么意思?就是你这条通路上所有的交换机、所有的链路必须支持相同的速率、相同的编码方式、相同的协议。这在传统电话网里没问题,因为所有设备都是为语音设计的。
但互联网要连接的是各种各样的设备:光纤、铜缆、无线、卫星,速率从几Kbps到几百Gbps不等。分组交换通过存储转发机制天然解决了这个问题。每个路由器先把分组完整收下来,再以自己出口链路的速率发出去。入口链路是10Mbps,出口链路是100Mbps,没关系,存下来慢慢发就行。这种速率解耦的能力是电路交换做不到的。
4. 存储转发机制的技术细节
4.1 一个分组在路由器里经历了什么
很多人以为路由器收到数据就立刻转发,实际上远没有这么简单。一个分组到达路由器的输入端口后,大致经历以下步骤:
- 物理层接收:信号从线路上到达,经过解调、解码,还原成比特流。
- 数据链路层处理:检查帧头,验证目的MAC地址,做CRC校验。如果校验失败,直接丢弃。
- 存储:把整个分组暂存到输入队列的缓冲区中。
- 查表转发:提取目的IP地址,查路由表(或者FIB转发表),决定输出端口。
- 排队:如果输出端口正忙,分组进入输出队列等待。
- 转发:从输出端口发出,经过链路层封装、物理层编码,送到下一跳。
这里面第3步和第5步是存储转发的关键。第3步要求整个分组必须完整到达才能进行下一步,第5步意味着如果输出链路拥塞,分组要排队等待。
4.2 存储转发延迟的计算
存储转发引入的延迟包括两部分:传输延迟和排队延迟。
传输延迟的公式很简单:
传输延迟 = 分组长度 / 链路带宽假设一个分组是1500字节(12000比特),链路带宽是1Mbps,那么传输延迟就是12000/1000000 = 12ms。如果链路带宽是100Mbps,传输延迟就是0.12ms。
排队延迟就复杂了,它取决于当前的网络负载。用排队论的语言来说,如果分组的到达速率接近链路的服务速率,排队延迟会急剧增加。这就是为什么网络利用率超过70%之后延迟会明显上升。
我实际测过一组数据:在一条100Mbps的链路上,当负载在30%以下时,平均排队延迟不到1ms;负载到60%时,平均延迟大约5ms;负载到80%时,平均延迟可能超过20ms;负载到90%以上,延迟直接爆炸,因为队列满了之后新到的分组会被丢弃,触发重传,进一步加剧拥塞。
实操心得:如果你在排查网络延迟问题,先看链路利用率。利用率超过70%就是一个警告信号,超过85%基本可以确定是拥塞导致的延迟。
4.3 分组长度怎么选
分组长度是一个需要权衡的参数。分组太短,每个分组都要带固定长度的头部(比如IP头20字节、以太网头14字节),有效载荷占比低,开销大。分组太长,传输延迟增加,而且一旦出错重传的代价也大。
以太网的经典MTU是1500字节,这个数字不是随便定的。1500字节的分组在10Mbps链路上传输需要1.2ms,在100Mbps链路上需要0.12ms。这个量级的传输延迟对于大多数应用来说是可以接受的。如果MTU设成9000字节(巨型帧),传输延迟会增加到7.2ms(10Mbps)或0.72ms(100Mbps),对于实时性要求高的应用就不太友好了。
另外,MTU还跟误码率有关。假设链路的误码率是10的负6次方,一个1500字节的分组(12000比特)的出错概率大约是1.2%。如果分组长度增加到9000字节(72000比特),出错概率就上升到约7%。出错概率越高,重传越频繁,有效吞吐量反而下降。
5. 分组交换引出的深层思考
5.1 为什么互联网不保证服务质量
分组交换的设计哲学是尽力而为(Best Effort)。网络不承诺任何服务质量,不保证延迟上限,不保证带宽,不保证不丢包。这看起来是个缺陷,但实际上是可扩展性的代价。
如果互联网要保证每个分组的延迟上限,那就必须为每条流预留资源,这就退化成了电路交换。而电路交换的扩展性已经被证明是有问题的——你不可能为全球几十亿台设备都预留专用通路。
所以互联网选择了一条不同的路:网络只负责尽力转发,服务质量由端系统自己想办法。TCP通过重传和拥塞控制来保证可靠性,应用层通过缓冲和自适应码率来应对延迟波动。这种端到端原则是互联网架构的核心思想之一。
5.2 排队延迟与拥塞控制的博弈
存储转发必然引入排队,排队必然导致延迟,延迟太大就会丢包。TCP的拥塞控制就是在这个背景下诞生的。
TCP的拥塞控制本质上是一个分布式反馈系统。发送方通过观察丢包和延迟变化来判断网络是否拥塞,然后调整发送速率。丢包了,说明队列满了,降速;没丢包,慢慢加速试探。这个机制让整个网络在接近拥塞但又不崩溃的状态下运行。
但这里有个根本矛盾:所有发送方都在试探,总有人会试探过头。这就是为什么网络延迟永远不可能为零,也是为什么你需要CDN、需要边缘计算——把内容推到离用户更近的地方,减少经过的路由器跳数,从而减少排队的机会。
5.3 从分组交换看网络中立性
分组交换的统计复用特性意味着所有流量平等竞争链路资源。但现实中,有些流量对延迟敏感(比如视频通话),有些流量对延迟不敏感(比如文件下载)。如果完全平等竞争,视频通话可能会被文件下载挤得没法用。
这就引出了一个设计选择:路由器要不要对不同流量做差异化处理?这就是QoS(服务质量)机制要解决的问题。但QoS本身又跟网络中立性的理念有冲突——如果网络运营商可以对不同流量区别对待,那它就有可能对某些流量降速、对另一些流量加速。
这个问题的本质是:分组交换的"尽力而为"到底应该是绝对的平等,还是可以有合理的差异化?我没有标准答案,但理解这个矛盾有助于你理解很多网络政策的争论。
6. 常见问题与排查技巧
6.1 为什么我的网络延迟忽高忽低
这是分组交换网络的典型特征。延迟波动主要来自三个原因:
- 排队延迟变化:链路负载波动导致队列长度变化,这是最常见的原因。
- 路由变化:某条链路故障导致路由重新收敛,分组走了不同的路径,跳数和链路质量都变了。
- 分组乱序:不同分组走了不同路径,到达顺序不一致,接收端需要重排,增加了处理延迟。
排查方法:用traceroute(或者mtr)持续观察每一跳的延迟变化。如果某一跳的延迟波动特别大,说明那个节点可能拥塞了。如果延迟整体偏高但稳定,可能是路径本身跳数太多。
6.2 分组丢失了怎么办
分组交换网络不保证不丢包。丢包的原因主要有:
- 队列溢出:输出队列满了,新到的分组被丢弃。
- CRC校验失败:传输过程中比特出错,链路层检测到后丢弃。
- TTL超时:分组在网络中循环太久,TTL减到零被丢弃。
- 路由黑洞:路由表配置错误,分组被发到了一个没有出口的地方。
排查丢包:先用ping看丢包率,然后用mtr定位是哪一跳开始丢包。如果是最后一跳丢包,可能是目标主机的问题;如果是中间某跳丢包但后续跳正常,可能是那台路由器做了限速或者ICMP过滤。
6.3 为什么大文件传输会拖慢整个网络
这是分组交换的公平性问题。一个大文件传输会产生大量分组,占满沿途路由器的队列,导致其他用户的分组排队甚至被丢弃。这就是所谓的带宽饥饿。
解决办法有几个:一是用QoS给大流量限速,二是用TCP的拥塞控制让大流量自己退让,三是用流量整形把突发流量平滑掉。实际部署中通常是组合使用。
实操心得:如果你在管理一个共享网络,建议在出口路由器上配置基于流的公平队列(FQ-CoDel),它能有效防止单个大流量把队列占满,对降低整体延迟效果非常明显。
6.4 存储转发能不能改成直通转发
能。实际上有些交换机就支持直通转发(Cut-Through Switching),收到分组的前6个字节(目的MAC地址)就立刻开始转发,不等整个分组收完。这样能显著降低转发延迟。
但直通转发有两个问题:一是无法做完整的CRC校验,可能转发出去的是错误的分组;二是如果输出链路速率比输入链路慢,还是需要缓存,直通的优势就没了。所以路由器通常还是用存储转发,交换机在特定场景下会用直通。
7. 我个人的一些体会
搞网络这些年,我越来越觉得分组交换的设计思想影响了很多其他领域。它的核心就三条:共享资源、按需使用、分布式决策。这三条放到云计算、微服务、甚至团队管理里都成立。
回到标题里的问题——路由器为什么不采用电路交换。答案不是"电路交换不好",而是"电路交换不适合数据通信的场景"。如果今天让你设计一个专门传输恒定速率语音的网络,电路交换可能仍然是最优解。技术选型从来不是找"最好的",而是找"最合适的"。
最后分享一个我常用的排查思路:遇到网络问题,先分层。物理层看链路状态,数据链路层看CRC错误计数,网络层看路由表和延迟,传输层看重传率。大部分问题在某一层就能定位到,不需要一上来就抓包。抓包是最后的手段,不是第一手段。