企业官网建设流程全解析

最近重新翻开《计算机网络：自顶向下方法》梳理链路层的内容，读到第六章6.6数据中心网络这一节时，我停下来看了很久。教材前面讲以太网、Wi-Fi、地址解析协议，都在解决“一个局域网内部怎么把帧送到对的地方”的问题，而数据中心网络要回答的，是另一个量级的难题：当几百台交换机和几万台服务器挤在同一个机房，它们之间的通信如何做到又快、又稳、又省成本。这一节在教材里篇幅不算长，但信息密度很高，而且和实际工程贴合得极其紧密。不管你是期末复习、准备面试，还是刚接触数据中心相关工作，这篇文章就是我把这一节拆开揉碎之后整理出的笔记和实操心得。

1. 数据中心网络为什么值得单独开一节来讲

1.1 教材里的“隐藏主角”

先说说这一节在整章里的位置。第六章的标题是“链路层和局域网”，前面几节讲的是以太网帧格式、交换机自学习、CSMA/CD这些非常“链路层”的内容。到了6.6，作者突然话锋一转开始讲数据中心网络。我第一次读的时候有点懵：数据中心网络不就是一堆交换机吗？和链路层有什么关系？

后来想明白了。数据中心网络的底层技术确实是链路层那套东西，但它真正研究的是“如何把成千上万个第二层/第三层设备组织成一个稳定、高带宽、可扩展的网络”。换句话说，前面几节教的是“一块砖怎么烧”，6.6教的是“一栋楼怎么盖”。你如果只盯着单台交换机的MAC地址表和帧转发，永远理解不了为什么数据中心网络里会有负载均衡器、为什么核心层要那么多台交换机、为什么要容忍一定的带宽收敛。

这一节在整章里的位置很特殊：它既是链路层的应用场景总结，也是通向三层路由和传输层的桥梁。数据中心网络里的主机之间通信，几乎都会跨越多个网段，需要路由协议的参与；同时数据中心内部的流量控制、拥塞控制又和传输层息息相关。这也是为什么很多老师会建议把6.6放到学完整本教材之后再看，因为它其实是全书知识的集大成场景。

从实际工作角度看，这一节的价值甚至超过了前面任何一节。现在绝大多数互联网应用的后端都是一群服务器组成的集群，理解数据中心网络的拓扑结构和工作原理，能直接帮助你判断：一次用户请求到底经过了哪些设备？为什么某些内部接口的时延有时会突然飙高？为什么扩容时不是随便加一台交换机就能解决？

1.2 南北向与东西向流量：先分清方向再谈设计

学6.6之前，我建议你先建立一个概念：数据中心的流量分为南北向和东西向两类。这个区分不是教材自己发明的，而是整个数据中心设计思路的分水岭。

南北向流量，指的是外部客户端和数据中心服务器之间的流量。用户刷网页、发请求、看视频，这些请求从外界进入数据中心，服务器响应之后再返回外界，方向是“上下”的，所以叫南北向。传统的数据中心设计，尤其是早期以Web服务为主的场景，南北向流量占据绝对主导。外部请求经过核心层、聚合层、接入层，最终到达某一台服务器，响应再原路返回，这个模型很直观。

东西向流量，指的是数据中心内部服务器与服务器之间的流量。比如后端服务要读取数据库、数据分析任务要跨节点交换中间结果、分布式存储要把数据在不同机器之间复制多份，这些流量不会离开数据中心，而是直接从这台服务器跑到那台服务器。方向是“水平”的，所以叫东西向。

为什么要先分清这两个方向？因为网络结构的设计完全是跟着流量特征走的。如果南北向流量占主导，那核心层只需要保证“外部请求能到达任意服务器”，带宽可以适当收敛，过额供给比做高一点问题不大；但如果东西向流量占主导，比如大规模分布式计算场景，任何两台服务器之间可能随时需要高速通信，那网络就不能只围绕“外部入口”优化了。近些年大型数据中心的东西向流量占比越来越高，这也是现代数据中心拓扑从传统三层结构向CLOS结构演进的根本驱动力。后面讲拓扑演进时，你会反复看到这个影子。

2. 经典三层结构：从接入层到核心层的分工

2.1 TOR接入层：机柜顶上的“盘口”

教材里描述了一种当时非常典型的数据中心等级体系结构。把整栋数据中心的网络分成三个层次：最下面是接入层，中间是聚合层，最上面是核心层。这个结构你可以把它想象成一家公司的组织架构：接入层的交换机是“基层员工”，直接面对服务器；聚合层是“中层管理”，负责协调一片区域；核心层是“高层决策”，负责全局互通。

接入层交换机在现实中有一个非常形象的叫法：TOR交换机，Top of Rack，字面意思是“机柜顶部”。一个标准机柜里通常塞了20到40台服务器，这个机柜顶部会放一台交换机，机柜里所有服务器的网线都集中连到这台TOR交换机上。这样做的最大好处是布线干净、故障域清晰：一个机柜的服务器都挂在同一台TOR交换机下面，这台交换机挂了，影响的也就是这一个机柜。

接入层交换机选型时，我发现很多人容易忽略端口配比问题。实际项目里，一个机柜的服务器数量、单台服务器的网卡速率、TOR交换机的下行端口数和上行端口数，这四个数字需要一起算。举个例子：一个机柜放了20台服务器，每台服务器配一块10G网卡，那TOR交换机至少需要20个10G下行端口；服务器网卡通常还会做双网卡绑定，这就变成40个下行端口需求。如果买了只有24个万兆口的交换机，还没装就被迫需要两台或用更高密度型号，规划时就得提前算清楚。

TOR交换机的上行方向连接的是聚合层交换机。上行带宽的选择是成本与性能的博弈。常见的做法是给TOR配几个40G或100G的上行口，把机柜内的流量汇聚后送上去。这里就引出了数据中心网络最重要的一个指标：过额供给比。后面我会专门展开计算方式，这里先记住一个直觉：如果上行带宽不足，机柜内服务器再怎么跑，流量也挤不出机柜口。

2.2 聚合层与核心层：各自守好各自的摊子

聚合层在经典三层结构里承上启下。它的主要职责有几个：第一，汇聚来自多个TOR交换机的流量；第二，作为多个机柜或集群之间的通信枢纽；第三，经常是部署安全策略、访问控制列表、负载均衡策略的位置。

教材里的例子还提到一个概念叫“集群”。一组服务器组成一个集群，集群内部通过接入交换机互通，多个集群之间靠聚合层交换机连接。这种划分在早期数据中心很常见：一个集群承担一类业务，比如Web前端一组、应用服务一组、数据库一组，集群之间尽量解耦，减少跨集群流量。聚合层交换机把同一个区域内的集群连在一起，核心层再把所有区域连成一张大网。

核心层是三层结构的顶端，负责连接数据中心与外部网络，也承担所有跨聚合层区域的流量转发。核心层交换机的数量一般不会太多，但每一台都要求很高的转发能力。这一层的带宽规划尤其讲究，因为所有出口流量和跨区域流量都要经过它，一旦核心层成为瓶颈，整个数据中心的性能都会被拖垮。

三层结构里还有个容易被忽略的关键：广播域和三层网关的划分。接入层以下通常是纯二层网络，服务器通过MAC地址通信；到了聚合层或核心层，需要配置三层接口和路由协议，把不同网段路由起来。实际部署中，网关放在聚合层还是核心层是个很经典的设计选择题。放得越靠下，故障域越小，但跨机柜的三层跳数越多；放得越靠上，路由越简单，但核心层的压力越大。

2.3 过额供给比的计算：别把账算错了

过额供给比是这三层结构最核心的算账指标。它的定义很简单：下行带宽总和与上行带宽总和之间的比值。比如一台TOR交换机有48个10G下行口，下行总带宽就是480G；上行接了4个40G口，上行总带宽160G。过额供给比 = 480 / 160 = 3:1。意思是所有下行口同时满速转发时，需要3倍的带宽才能全部送上去，但实际只有1/3，所以必然有收敛。

很多人第一次接触这个指标会觉得“既然有收敛，为什么不把上行带宽做到1:1？”答案很简单：贵。下行端口是接入侧，数量巨大；上行端口是汇聚侧，高密度端口单价高、光模块成本高、消耗的交换容量也大。如果把过额供给比做到1:1，网络成本会成倍上升，而大部分场景根本不会出现所有服务器同时打满带宽的情况，所以做一个合理的超额认购是性价比最高的选择。

实操中，过额供给比不是一个固定值，要结合业务流量模型来定。早期以南北向流量为主的传统Web业务，20:1甚至40:1都很常见，因为外部请求到达服务器后，响应数据量并不大，大部分时候接入链路根本打不满。但随着分布式计算和存储的业务变多，东西向流量激增，大家被迫把过额供给比越做越低，从20:1降到4:1、3:1，甚至后端存储网络直接做到1:1无收敛。

这里给一个实际经验：不要只看设备标称端口速率，一定要把光模块类型一起算进去。同样标称40G的口，用4条10G独立光模块和用1条40G光模块，链路利用率和故障模式完全不同。很多线上事故就是扩容光模块时没算清端口类型，导致上行链路带宽翻倍但实际并发能力没变。

下面是一个经典三层结构的带宽规划简表，方便你在做方案时快速对号入座：

表格只是参考，具体数值依赖业务模型和预算。但有一条原则永远不会变：离服务器越近，带宽越宽裕，过额供给比越低；离出口越近，越需要考虑成本，过额供给比可以适当放宽。

3. 负载均衡设备：数据中心的“前端守护者”

3.1 负载均衡器的位置与工作原理

教材在讲三层结构之后，紧接着讲了负载均衡。原因很简单：数据中心里有成千上万台服务器，外部请求到达时，必须有一批设备决定“这个请求该交给哪台服务器处理”。这批设备就是负载均衡器。

负载均衡器在物理位置上通常位于接入层和聚合层之间，或者作为独立的设备串在南北向流量的必经路径上。它对外表现为一个虚拟IP，内部维护一份服务器列表，收到请求后通过某种调度算法（轮询、加权轮询、最少连接数、一致性哈希等）把请求分发到具体服务器。

这里有一个非常重要的概念：负载均衡器看到的连接和最终处理的连接不是同一个。客户端和负载均衡器建立一条TCP连接，负载均衡器再和后端服务器建立另一条TCP连接，两边连接完全独立，这叫“代理模式”。在某些高性能场景下也会用NAT直接转发，但理解时你可以先用代理模式来想。这解释了为什么负载均衡器需要维护大量连接状态，也解释了为什么负载均衡器是很容易成为性能瓶颈的地方。

实际操作里，负载均衡器除了分发请求，还要做健康检查。隔几秒探测一次后端服务器是否存活，发现异常就自动把流量切换到其它节点。这里踩过的坑很多：健康检查间隔设得太短，后端服务器因GC或重启出现的毫秒级抖动会被误判为宕机；设得太长，故障响应又不及时。还要注意健康检查的探测来源IP，有些后端防火墙会误拦负载均衡器的探测包，导致明明服务正常却被打上“不健康”标签，流量全被切走。

3.2 ECMP等价多路径：交换机层面的负载均衡

负载均衡器是面向“用户请求”这一层的负载均衡，交换机层面还有另一层负载均衡：ECMP等价多路径。一台接入层交换机上行有多个口，连着多台聚合层交换机，那么去往同一目的地的路由就可以有多条等价路径。交换机把每条流的包按某个哈希算法分到不同的上行口，避免单条链路打满。

ECMP的实现逻辑很简单：交换机提取每条流的五元组（源IP、目的IP、协议、源端口、目的端口），做哈希，哈希结果决定走哪条路径。同一个五元组的包哈希结果相同，所以能保证一条流的所有包从同一个口出去，不会乱序。这里关键点是“按流负载均衡，不按包负载均衡”，如果按包分发，TCP的接收端会因为包乱序而疯狂重传，性能反而更差。

ECMP在数据中心里应用极广，因为拓扑天然是多路径的。但实际使用中有一个著名的坑：哈希冲突导致的大象流堆积。哈希算法是均匀的，但流的大小差别极大。一条流只占几个包，另一条流可能要连续传输几十GB的数据。如果这两个五元组恰好哈希到了同一个上行口，那条大象流就会把链路塞满，而其它上行口却空着，最终表现是整机柜的带宽利用率不佳，单条链路却长期丢包。解决思路有很多，比如用更高质量的哈希算法、对流的大小做动态识别，或者引入集中式控制器来按流调度。后面讲SDN时再展开。

3.3 传统负载均衡的瓶颈与现代思路

硬件负载均衡器能力确实强，动辄几百万并发，但代价是贵、灵活性差、改动调度算法要重启设备。软件负载均衡器便宜、灵活，但性能受制于CPU和网卡中断处理。近些年来的趋势是用更好的网卡驱动和用户态协议栈来提升软件负载均衡的吞吐，有些实现已经能靠普通服务器扛下大批量请求。

另一个趋势是把负载均衡和网络本身结合起来。传统负载均衡器是一个“独立设备”，请求必须先经过它；现代数据中心里，负载均衡功能可以分散到交换机上做，或者在协议层面用“一致性哈希”配合分布式代理来实现，避免所有流量都集中在固定的几个点上。这种分散式架构的典型场景就是大型云厂商的网关集群，外面看起来还是一个虚拟IP，但背后很可能是几十台甚至上百台服务器同时在做网关转发。

学习教材6.6时，要注意它的写法是“负载均衡器存在于网络边缘，负责分发请求”，这是对现实的一种简化。现实中不存在一个能承担全网所有请求的负载均衡器，而是一组负载均衡集群，中间还要靠ECMP或集中控制器把流量先均匀分到每一台负载均衡实例上，负载均衡实例再做应用层的请求分发。

4. 现代数据中心拓扑演进：CLOS与Fat-tree

4.1 为什么传统三层结构撑不住了

传统三层结构在服务器数量和带宽需求达到一定规模后，会遇到好几个绕不开的问题。第一个是核心层的带宽和容量瓶颈。所有跨区域流量都要经过核心层，核心交换机的转发容量有限，能插的端口也有限，等核心层被打满，唯一办法是换更高端的设备，代价极高。

第二个问题是东西向流量的增长。前面说了，分布式计算、海量存储这些场景需要任意两台服务器之间都能高速互通。传统三层结构里，两台在不同区域、不同聚合层的服务器通信，路径要跨越接入层、聚合层、核心层好几个层级，经过的设备和跳数都多。跳数多意味着延迟高、故障点多、带宽被层层收敛压制。

第三个问题是扩展粒度不灵活。三层结构里某一片区域不够用，想加新的接入交换机，只能整片往聚合层上接，而聚合层的上行端口是有限的，接到一定程度就满了。想扩展就得动整个聚合层甚至核心层，这种“牵一发动全身”的扩展方式，在追求快速扩容的数据中心里很致命。

还有一层现实原因是成本和可维护性。传统三层结构里核心层通常要用能力最强的设备，这类设备单价极高，而且越强越贵；但现代数据中心推崇的是规模化部署同一款设备，用数量堆出性能，能用便宜设备解决的问题绝不用贵的。这个思路的转变和后来的CLOS拓扑有很大的关系。

4.2 CLOS网络：把“胖树”搬进数据中心

CLOS这个名字源自通信领域的多级交换网络，后来被数据中心网络借鉴，成为一种解决扩展性和带宽收敛问题的经典拓扑。它的核心思想很直接：不再依赖少数几台高端核心交换机，而是用大量中低端交换机组成多层的、路径对称的拓扑，让任意两点之间都有多条完全等长的路径可选。

教材里特别提到了一种常见的CLOS变体：胖树。胖树的特点是“越靠近根部，链路越粗”，但具体实现上更常见的表述是“所有层级的链路带宽相同，只是链路数量不同”。胖树拓扑抽象出来是一个多叉树结构，每一层的交换机数量有严格的数学关系。以常用的k叉胖树为例，最底层有k台交换机组成一个“元组”，每个元组向上连接k台上层交换机，逐层扩展。这种结构下，任意接入层交换机之间都有多条等长路径，理论上可以实现无收敛的满带宽转发。

为什么胖树这么受欢迎？第一个原因是它允许用统一规格的交换机搭建整个网络。接入层、聚合层、核心层可以用同一款设备，采购成本大幅下降，备件也方便。第二个原因是路径丰富，一台接入交换机的流量可以均匀散到很多条上行链路上，不会出现传统结构里单点拥塞。第三个原因是扩展性好。往胖树里加新的机柜，只要在对应的层次补设备，不用动整张网络。这也是很多早期CLOS方案能在数据中心落地生根的根本原因。

实际工程里落地CLOS时，我碰到的第一个问题是路由协议的选择。CLOS拓扑的路径数量多，天然适合用多路径路由。传统OSPF虽然也能算多条等价路径，但收敛慢、支持的等价路径数量有限；很多实际部署会在核心层用BGP。别觉得奇怪，BGP并不只是互联网上用的，数据中心内部也大量使用，把聚合层和核心层的互联关系做成BGP会话，配合ECMP，就能充分利用CLOS的多路径优势。

4.3 集中式控制与SDN：数据中心为何成了试验田

CLOS拓扑解决了物理结构的问题，但多路径也带来一个麻烦：如何让流量在各条路径之间高效、均衡地分配？靠交换机本地ECMP哈希，前面说了会有哈希冲突和大象流问题；靠手工调整路由权重，又跟不上业务的变化。这时候集中式控制的思想就派上了用场。

教材在讲现代数据中心网络时，提到了集中式控制器和它在大型数据中心里的部署思路。集中式控制的逻辑和传统路由协议完全不同：传统方式是每台交换机自己运行协议、自己算路由、自己决定转发；集中式方式是控制器收集全网状态，算好流表，再下发到每台交换机，交换机本质上是执行控制器决定的转发设备。

数据中心为什么成了集中式网络控制最合适的试验田？因为数据中心太适合了：网络所有者和管理者是同一批人，业务完全可控；拓扑相对规则，路径多且对称；业务需求变化快，需要快速调整网络策略；设备规模大，手工配置根本管不过来。反过来，广域网或园区网没有这些条件，这也是为什么集中式控制普及度最高的地方始终是数据中心。

集中式控制带来的直接收益是把“流级调度”变成可能。控制器能看到全局流的状态，识别出大象流和老鼠流，然后按需把大象流挪到空闲链路上，把多条老鼠流聚合共享链路，整网利用率可以大幅提升。当然它也带来单点故障风险，所以控制器本身要做集群化部署，交换机与控制器失联时要有降级方案，这些工程细节都是实际落地时绕不开的坑。

我见过不少团队刚开始做集中式控制时，把所有流表都依赖控制器下发，控制器一次故障，全网转发几乎瘫痪。正确的做法是：静态路由或基础路由仍然由交换机本地协议保证，控制器只负责动态优化和策略下发。这样控制器挂了，网络还能保持基础连通，只是失去最优调度能力。这个“控制器只做优化、不做唯一路径来源”的原则，是实践中比较稳妥的设计。

5. 容错、带宽与运维：数据中心网络里的现实问题

5.1 冗余设计：别让网络因为一根光纤而瘫掉

教材那一节里专门提到，数据中心网络必须考虑可靠性和扩展性，这两个词翻译成工程语言就是：冗余和增量扩容。先讲冗余。

交换机设备本身要做冗余。经典的部署方式是主备两台核心交换机，一台坏了另外一台顶上。现代CLOS拓扑里，冗余已经内化在结构里了：路径多，一台交换机挂了，流量自动改走其它路径，不需要主备切换，天然高可用。但要注意ECMP的收敛过程也很重要，链路切换时如果收敛太慢，仍然可能出现大量丢包。

链路层面是故障重灾区。光模块、光纤、网线、网卡，任何一环出问题都会导致链路中断。实际现场里最闹心的是“间歇性故障”：光模块光功率漂移、光纤弯曲过大、网卡固件Bug，这类问题在监控图上表现为周期性丢包，最常见的解决办法是建立完整的光模块光功率监控和链路质量测试机制。我处理过最典型的案例是某台服务器网络时断时续，折腾了几天，最后发现是网线水晶头压线不规范，只有一对线接触不良。这种问题在数据中心里并不少见，排查时要先看物理层，别一上来就怀疑路由配置。

还有个容易忽略的点是电源和风扇。交换机电源要接双路，风扇故障会导致温度升高进而引发丢包和重启。这些看起来不是“网络”问题，但在运维实践里，很多网络故障的根因都是非网络因素。

5.2 延迟优化：数据中心里“快”字是怎么做到的

教材里的网络设计追求的是带宽利用率和吞吐，但工程上对延迟也有很高的要求。数据中心内部的往返时延通常在几十到几百微秒量级，这个数字比家庭宽带、园区网要小几个数量级。

影响延迟的因素很多：路径跳数、队列排队、链路拥塞、交换机转发时延、网卡处理时延等。减少路径跳数靠拓扑设计实现，CLOS天然让任意两点间的跳数更少；减少队列排队靠拥塞控制实现，比如网络层做显式拥塞通知、传输层做更激进的拥塞控制算法；减少网卡处理时延要靠更好的网卡驱动和用户态网络技术。

这里我要提一个很多新手会碰到的现象：TCP Incast。在分布式存储和并行计算这类场景里，一个父任务会同时向大量子任务请求数据，子任务同时把数据返送给父节点，瞬时拥塞导致父节点网卡缓冲爆掉，大量数据包被丢弃，TCP重传又进一步恶化时延。这类问题不是靠拓扑能解决的，要做流控参数调优、应用层做限流和背压设计。所以说数据中心网络的优化，从来都不是单独靠网络工程师在交换机上敲配置就能完成的，需要上层应用协同。

5.3 能耗与成本：不只是省电，还是密度问题

数据中心网络还有个不太起眼但实际影响巨大的指标：能耗。交换机每加一个端口、每提升1Gbps速率，功耗都会上升。几千台交换机堆在一起，一年的电费是非常可观的数字。

选型时除了看性能和端口密度，还要算单位带宽功耗。同样提供100G转发能力，A设备功耗200瓦，B设备功耗300瓦，看似只差100瓦，乘以几千台设备就不是小数目。更关键的是散热压力，功耗升高之后空调系统甚至液冷系统都要跟着升级，这就牵涉到机柜的功率密度和机房基础设施改造了。

节能方面还有一个思路是“按需工作”。传统网络里所有设备、所有链路都保持全速运行，即使利用率只有几个百分点。现代数据中心里会把利用率很低的服务器和交换机做节能调度，把业务合并到一部分设备上，另一部分设备可以休眠或降频。这个逻辑和虚拟化的热迁移是配套的，但在网络层面实施起来要小心，切流量时要保证业务平滑过渡，不能为了省电把正在跑的在线服务搞断了。

6. 学完6.6之后的几点延伸思考

6.1 教材简化模型和实际部署的差异

说实话，教材里的三层结构在现代大型数据中心已经不那么流行了，更常见的是“叶脊”拓扑或各种CLOS变体。但教材为什么要先讲传统三层再讲现代趋势？我理解是为了给读者一个递进感：先理解等级结构为什么存在，再理解它为什么被替代。

另外一个教材没有展开、但非常重要的现实话题是Overlay网络。现代数据中心虚拟机、容器数量远超物理机，想在底层物理网络上动态建立海量隔离网络，不能只靠VLAN这种二层隔离手段，因为VLAN数量有限、配置繁琐。所以实际系统普遍会在现有物理网络上叠加一层隧道封装，把二层帧封装进三层包里传输。这层叠加网络对底层网络的需求，恰恰是“底层只要提供大带宽和丰富的路径即可”，这也是为什么现代底层网络普遍采用CLOS的原因之一。你可以理解为把“复杂网络策略”上升到了软件层实现，底层物理网络则被简化成了“一个巨大的、没有收敛的交换机”。

6.2 面试与复试视角：6.6常考的几个点

如果你是为了应付考试或面试，我帮你把6.6的核心考点做个整理。

首先，南北向和东西向流量的区别，以及它如何影响拓扑设计，这是基础题里最高频的切入点。其次，经典三层结构的层次名称、TOR交换机的含义、过额供给比的计算方法，经常以选择题或简答题形式出现。再次，负载均衡器为什么需要、放置在什么位置、有什么局限，这是中等难度的考点。最后，CLOS和胖树为什么能解决传统结构的扩展问题，以及集中式控制的价值，这是难度较高的分析题。

我特别建议你把“ECMP”和“过额供给比”这两个关键词放在一起复习。它们一个解决“多条路径怎么选”，一个衡量“带宽到底够不够”，本质上都是数据中心网络里“算资源账”的问题。把这层意思想通，这一节就不再是一堆名词的堆砌了。

关于复习方法，我自己的体会是：不要只背结论，要能用一两句话说清每个设计的出发点。比如问“为什么数据中心网络要有负载均衡器”，标准回答是“为了让请求均匀分配到多台服务器”，但更好的回答会补充一句“因为服务器数量远超过任何一个外部入口能直接面对的实例数，而且服务器节点可能随时故障，需要一个中间层把故障屏蔽掉”。

最后说一点我个人的复习体验：6.6这一节虽然列在链路层章里，但它读到最后你会发现，它其实是一个横跨链路层、网络层和传输层的综合体。建议你学完整本教材之后再回来重读一遍这一节，第一遍读是认识名词，第二遍读才能看懂设计背后的取舍。每次重读，我都能从同一个拓扑图里看出新的东西——这大概就是经典教材里“应用场景”章节的魅力。