企业官网建设流程全解析

每年开学第三四周，技术交流群里就会集中出现同一类提问：计算机网络第一章的课后习题到底要不要一道一道地做，做完了又该怎么对答案。问的人里，有刚接触这门课的初学者，也有工作几年回头补基础的开发者。这个现象本身就说明了一件事：第一章的习题看起来全是概念，好像背一背就能过，实际上它埋着整门课后面所有计算题的根。我这次就把那本流传最广的国内计算机网络教材第一章的课后习题整体拆一遍，重点讲清楚三件事：哪些题必须动手算、简答题怎么组织语言才拿分、以及那些看似弱智却年年有人栽跟头的单位换算坑。不管你是准备应付期末考核，还是想认真把网络基础补齐，这一章都值得花两三个晚上扎实过一遍。

1. 第一章习题的真实分量：看起来最简单，其实最容易留后患

1.1 为什么这一章的题目"读起来都懂，做起来都不对"

第一章的内容定位是总纲，讲的是互联网的组成、三种交换方式的取舍、性能指标体系、分层体系结构这几块骨架。这些概念单独拎出来，几乎每句话你都能读懂，于是很多人产生了一种错觉，觉得第一章不需要动笔，翻一遍教材直接做后面的题去了。我自己当年就是这么干的，结果在后面的运输层、网络层习题里反复卡在"发送时延和传播时延到底谁大"这种问题上，回头才发现根子在第一章。

这一章的习题有个很典型的特征：题干极短，但每道题背后都对应一个完整的分析框架。比如让你比较电路交换和分组交换，题干可能只有一行字，但要答得完整，你得覆盖建立连接的开销、信道利用率、传输时延构成、突发业务的适应性、差错处理代价这五六个维度。你只写"分组交换更灵活、更高效"，阅卷的人一眼就能看出你只是背了结论，没理解机制。真正的分水岭在于：你能不能从"存储转发"这四个字出发，推导出后面所有结论。

还有一类被严重低估的题是计算题。第一章的计算题数量不多，但每一道都是后面所有时延计算的原型。很多人做第一章计算题时靠"感觉"凑答案，单位一会儿兆一会儿千，算完也不检查量级，最后得出的发送时延比宇宙年龄还长，还觉得是自己公式记错了。这种问题的根源不在公式，在于对"比特""字节""速率"三者的物理关系没有形成直觉。

我的建议很直接：第一章的简答题可以只写提纲，但计算题必须完整写过程，包括单位换算的每一步。第一章的计算题是所有后续章节的模板，在这里偷的懒，后面要连本带利还回来。

1.2 把三十来道题分成三类，复习路线立刻就清晰了

第一章课后习题的数量通常在三十道上下，硬着头皮从头做到尾效率极低。我习惯按"考察意图"把它们切成三类，每类配不同的处理方式。

第一类是对比辨析型，典型代表是三种交换方式的比较、面向连接与无连接的区别、客户-服务器方式与对等通信方式的异同。这类题不需要计算，但需要你把对比维度列全。处理方式是画一张两维表，横轴放对比对象，纵轴放对比维度，填完这张表，这一类题就全解决了。

第二类是计算推导型，核心就是时延、时延带宽积、传输效率这几类。数量大概占三成，但含金量最高。这类题必须动手算，而且要用不同的数量级各算一遍，因为第一章计算题的设计意图就是让你体会"数据量大速率低"和"数据量小速率高"两种极端情况下时延构成的变化。

第三类是名词解释型，比如协议栈、实体、对等层、服务访问点、协议数据单元这一串。这类题的坑在于定义之间高度耦合，你单独背"实体是可发送或接收信息的硬件或软件进程"，考场上换个问法问"对等实体之间通信的实质是什么"，很多人就懵了。正确的处理方式是把这些名词串成一条链：分层产生对等层，对等层上活动的进程叫实体，实体之间交换的数据单位叫协议数据单元，上层通过服务访问点使用下层的服务。

把题目分完类你会发现，真正需要逐字逐句写的没几道，大部分题目共用同一套知识结构。这也是我建议第一章不要"刷题"而要"建框架"的原因。

1.3 一个容易被忽略的细节：题目顺序本身就是知识地图

教材编排课后习题时，顺序基本跟着正文走。前几题集中在互联网的组成与边缘/核心的概念，中间一大段围绕交换方式和性能指标，后半段进入体系结构与协议。这个顺序不是随意的，它对应着一条从"网络长什么样"到"网络怎么衡量"再到"网络怎么描述"的认知路径。

我通常建议按这个顺序做题，但不要按这个顺序复习。做题按顺序走，能保证知识点的连贯；复习的时候反过来，先看体系结构那一组题，因为体系结构是全局视角，理解了分层，前面那些"为什么核心部分要用分组交换"的问题会变得非常自然。你站在物理层到应用层的角度回头看，分组交换的核心地位几乎是必然的——它把复杂问题切成了可以流水处理的片段，这跟分层是同一种思想。

2. 简答题怎么组织语言：三个高频考点的答题骨架

2.1 三种交换方式的对比题，按五个维度铺开就不会漏

三种交换方式的比较几乎是必考题，但绝大多数人的答案都停留在"电路交换独占资源、分组交换共享资源"这个层面，分数自然上不去。我推荐用五个维度来组织答案，每个维度写一两句话，整段下来三百字左右，既完整又不啰嗦。

第一个维度是资源占用方式。电路交换在通信全程独占端到端的物理通路，即使双方都不说话，这条通路也不能给别人用；报文交换和分组交换采用存储转发，链路是共享的，只有在数据真正通过时才占用。

第二个维度是建立连接的开销。电路交换需要先建立连接，这个过程要花时间，短报文传输时这个开销占比会非常高；分组交换通常不需要预先建立通路，可以随时发送，对突发性业务更友好。

第三个维度是传输时延的构成。电路交换的总时延主要是传播时延加建立时间，中途几乎没有排队等待；分组交换则多了每一跳的存储转发时延，并且在网络拥塞时排队时延会急剧变大。注意这里不要写成"分组交换时延更小"，准确的说法是"在轻载和长报文场景下，分组交换的端到端时延可能更小；重载时排队时延会显著上升"。

第四个维度是可靠性与差错处理。电路交换一旦通路建立，中途基本不会出错，但一出错整条通路就废了；分组交换每一段链路都可以独立做差错检测和重传，出错时只需要重传单个分组，代价小得多。

第五个维度是对不同业务的适应性。电路交换适合恒定速率、对时延抖动敏感的实时业务；分组交换适合突发性强、对带宽利用率要求高的数据业务。这个维度往往被漏掉，但它是解释"为什么两种方式长期共存"的关键。

把这五个维度写全，这道题基本就是满分答案的骨架。我自己的习惯是先列维度名，再在每个维度下面补一句机制说明，最后加一句总结性判断，结构一眼可见。

2.2 协议与服务的区别，答不好是因为混用了两个视角

这道题的经典错误答案是"协议是规则，服务是功能"，这种答案等于没说。要答清楚，得抓住一个核心：协议是水平方向的，服务是垂直方向的。

协议是同一层次的对等实体之间通信时遵守的规则，它是"水平"的，控制的是两个对等实体怎么对话。服务是下层向上层提供的功能，它是"垂直"的，上层不需要知道下层怎么实现，只要按接口调用就行。这个水平/垂直的区分一旦建立，后面几个衍生结论就顺理成章了。

第一，协议的实现对上层的服务使用者是透明的。上层看到的是服务原语和服务访问点，看不到下层的协议细节。第二，只有协议是对等的那一层才谈得上，服务则一定是跨层的。第三，协议是"怎么做到"，服务是"做到了什么"，前者关心过程，后者只关心结果。第四，服务通常分面向连接和无连接两类，而这个分类只描述服务的形式，不规定下层用什么协议去实现。

再往下追问一层，很多人会被"服务原语"卡住。这里只要记住四个动作就够了：请求、指示、响应、证实。上层发请求，下层收到后向上给指示，上层做响应，下层再回一个证实。这四步串起来就是一次完整的服务交互过程，考试时能写出来这四步，说明你是真的理解了层次间的调用关系，而不是背定义。

2.3 分层体系结构的理由，别只答"降低复杂度"

"为什么要分层"是必考题，标准答案往往写"降低复杂度、便于实现和维护、各层独立演进"。这四条本身没错，但答得太干，缺少因果链条。我更推荐这样组织：先说分层解决的是变化的问题，再说分层带来的两个代价。

从机制上讲，网络通信涉及的问题跨度极大，从电信号在介质中的传播，到应用进程之间的语义交互，中间还夹着寻址、路由、差错控制、流量控制、拥塞控制一大堆子问题。如果不分层，任何一个环节的技术演进都会牵动整体，工程上根本无法维护。分层的本质是把变化隔离在单层内部，只要层间接口不变，某一层的实现随便换。光纤替换铜缆，物理层内部翻天覆地，上面的层完全不需要改一行代码，这就是分层的价值。

但分层不是免费的，它有两个明确代价。一是功能冗余，相邻两层可能都做差错检测，链路层有校验和，运输层也有校验和，这种重复是刻意的，为的是各层独立。二是首部开销，每层封装都要加自己的控制信息，层数越多，有效数据的占比越低。这个代价正好和后面计算传输效率的题目呼应。

接口设计的原则也值得写进去：层间接口要尽量简单，跨越接口的信息量要尽可能少。这条原则解释了为什么网络层对上只提供一个尽力而为的数据报服务，把可靠性交给运输层自己做——如果网络层保证可靠，接口就会变得极其复杂，而且无法适应无线这类天然不可靠的链路。

3. 计算题的通用解法：把时延公式拆到骨头里

3.1 四种时延的物理含义，用生活场景一次讲透

第一章的计算题几乎全部建立在"总时延等于各段时延之和"这个基础上。四种时延分别是发送时延、传播时延、处理时延和排队时延，很多人背得出名字，但一到具体场景就分不清谁是谁。我用一个寄快递的场景类比，基本上一遍就能记住。

发送时延是"把货装箱搬上车的总耗时"，取决于你要寄多少货（数据长度）和装卸速度（发送速率）。公式是数据长度除以发送速率。注意这里的"发送速率"就是网卡把比特推上链路的速度，也就是人们常说的带宽。这个时延和距离完全无关，很多人直觉上认为离得远发送就慢，这是最典型的误解。

传播时延是"车在路上跑的时间"，取决于路程（信道长度）和车速（电磁波在介质中的传播速率）。公式是信道长度除以传播速率，与数据量无关。你在同一条 1000 公里的链路上，发 1 个比特和发 1 亿个比特，传播时延是一模一样的。

处理时延是"到站后分拣、检查、重新贴单"的时间，主机或路由器收到分组后要做首部分析、差错检测、查表转发，这些都要花时间。排队时延是"分拣窗口前排队等待"的时间，取决于链路当时的拥塞程度。这两个时延在教材里通常不做精确计算，因为它们是随机的，做题时如果没有特别说明，一般忽略。

这里有个非常关键的判断，考试里反复出现：高速链路能减小的是发送时延，不能减小传播时延。把带宽从 100 兆提升到 10 吉，接口推送比特的速度快了 100 倍，但光在光纤里跑的速度不会因为你付了更多钱就变快。所以对"长距离、小数据量"的通信，瓶颈往往在传播时延，加带宽没什么用；对"近距离、大数据量"的通信，瓶颈在发送时延，加带宽立竿见影。

3.2 那道经典的双场景时延题，完整算一遍

教材里有一道非常经典的题，题干大意是：收发两端之间的传输距离为 1000 公里，信号在介质上的传播速率为每秒 2×10⁸ 米，分别计算两种情况下的发送时延和传播时延，第一种是数据长度 10⁷ 比特、发送速率 100 千比特每秒，第二种是数据长度 1000 比特、发送速率 1 吉比特每秒。

先把传播时延算出来，两种场景用的是同一条链路，所以这个值是共用的。1000 公里等于 10⁶ 米，除以 2×10⁸ 米每秒，得到 5×10⁻³ 秒，也就是 5 毫秒。这一步建议单独写出来，因为它是后面所有对比的基准。

第一种情况，发送时延等于 10⁷ 比特除以 10⁵ 比特每秒，得到 100 秒。这个数字一出来，对比就非常刺眼了：发送时延 100 秒，传播时延 5 毫秒，前者是后者的两万倍。此时总时延几乎就等于发送时延，链路带宽是绝对的瓶颈。

第二种情况，发送时延等于 10³ 比特除以 10⁹ 比特每秒，得到 10⁻⁶ 秒，也就是 1 微秒。而传播时延还是 5 毫秒，是发送时延的五千倍。此时总时延几乎就等于传播时延，带宽再提升十倍也几乎看不出来。

这道题的结论要写清楚：时延由哪个分量主导，取决于数据量和速率的相对关系，而不是取决于链路长短这一个因素。同样 1000 公里，小包高速率场景下传播时延主导，大包低速率场景下发送时延主导。这个判断在后续章节讨论"为什么小包传输效率低""为什么实时业务怕的是抖动不是带宽"时都会用到。

3.3 单位换算是第一章最大的隐形杀手

我在带人过题时发现，出错率最高的不是公式记错，而是单位。几个高频坑必须一次性说清楚。

第一个坑：速率里的 k 是 1000，存储里的 K 是 1024。教材里讲数据率时，千比特每秒的千就是 10³，兆比特每秒的兆就是 10⁶，吉比特每秒的吉就是 10⁹。但讲文件大小时，1 KB 的 K 是 2¹⁰ 等于 1024。这两套体系混用的时候，误差能到 2.4%，在需要精确对比的题目里足以导致结论相反。做题时最稳妥的做法是：速率一律换算成比特每秒再用 10 的幂表示，文件大小一律先转成字节再乘以 8 转成比特，中间不保留中间结果。

第二个坑：比特和字节差一个 8 倍。数据长度如果给的是字节，而速率给的是比特每秒，必须乘以 8。这个 8 倍在时延计算里是致命的，因为它会直接把答案差出将近一个数量级。我自己的习惯是在草稿纸上先把所有量统一成"比特"和"秒"，后面再也不会错。

第三个坑：毫秒、微秒、纳秒之间的进位。传播时延算出来经常是 10⁻³ 到 10⁻⁶ 秒这个区间，换算成毫秒是乘 1000，换算成微秒是乘 10⁶。很多人算出 5×10⁻³ 秒之后随手写成 5 微秒，量级直接错了三个数量级。我的做法是所有时延先统一用秒表示，保留科学计数法，最后一步才换成便于阅读的单位。

第四个坑：传播速率取值。铜缆和光纤中的传播速率通常取每秒 2×10⁸ 米，也就是真空光速的三分之二左右；无线电在自由空间中接近每秒 3×10⁸ 米。题干如果不给，默认按 2×10⁸ 米每秒处理，但要在答案里写清楚你的假设，这是严谨性的体现。

一个非常实用的自检技巧：算完时延之后，反推一下"这段时间里数据能传多远"。如果传播时延乘以传播速率得到的距离和题目给的链路长度一致，说明你这一步没问题。这个反向验证能挡住绝大多数单位错误。

3.4 时延带宽积：一个被严重低估的概念

时延带宽积等于传播时延乘以带宽，它的物理含义是"链路上正在传输的比特总数"，也就是所谓"以比特为单位的链路长度"。这个概念在第一章只是一笔带过，但它是理解滑动窗口、拥塞控制、管道利用率的基础。

教材里有一道配套题，大意是信号传播速率取每秒 2.3×10⁸ 米，介质长度分别为 10 厘米、100 米、100 公里、5000 公里，数据率分别取 1 兆比特每秒和 10 吉比特每秒，求各情况下链路中正在传播的比特数。

计算过程其实很机械，先算传播时延，再乘数据率。10 厘米的情况，传播时延约 4.35×10⁻¹⁰ 秒，在 1 兆比特每秒下链路中只有约 4.35×10⁻⁴ 个比特，连一个比特都装不满；在 10 吉比特每秒下是 4.35 个比特。这个结果非常反直觉，但它说明了一个真实事实：网卡内部的短链路上，发送和接收几乎是同步发生的，谈不上"管道"。

5000 公里的情况就完全反过来了，传播时延约 2.17×10⁻² 秒，在 1 兆比特每秒下有约 21700 个比特在途，在 10 吉比特每秒下有约 2.17×10⁸ 个比特在途。后一个数字意味着，如果发送方要等接收方的确认才能继续发，那它每一轮都得等这么久才能推进，链路的实际利用率会低得可怕。这就是为什么长距离高带宽链路必须用大窗口，窗口小于时延带宽积，管道就永远灌不满。

这道题还有一个常见的延伸问法：提高了带宽，时延带宽积会怎么变。答案很明确，带宽提升，时延带宽积同步提升，也就是说管道变粗了，但管道的长度没变。变粗的管道如果没有足够的"在途数据"去填充，多出来的容量就是浪费的。这个结论在后面的拥塞控制章节会反复出现。

3.5 封装开销与传输效率：从首部字节数直接算

第一章还有一类计算题，给应用层数据长度，逐层加上首部和尾部，问传输效率。这类题的计算极其简单，但很多人答不到点子上，因为它考的不是除法，是"你对分层代价的量化理解"。

以一道典型题为例：应用层数据 100 字节，交给运输层加 20 字节首部，网络层再加 20 字节首部，链路层再加 18 字节首部和尾部。总长度是 158 字节，传输效率等于有效数据除以总长度，约 63.3%。如果应用层数据换成 1000 字节，总长度 1058 字节，传输效率约 94.5%。

这组数字值得反复看。同样一套协议栈，数据量从 100 字节涨到 1000 字节，效率从 63% 跳到 94%。这说明固定开销对小包的惩罚是极其严重的，而这就是很多实时语音、游戏心跳包明明数据量很小却依然占用可观带宽的原因。你发一个 10 字节的心跳，经过三层封装可能变成 68 字节，其中八成都是控制信息。

延伸一下，如果题目问"要提高传输效率有哪些办法"，可以从三个方向答：增加有效载荷长度（但受最大传输单元限制）、压缩首部（比如首部压缩技术）、减少封装层数（比如应用层直接跑在特定传输之上）。这三个方向在后面的章节里都有对应的具体技术，第一章把这个账算明白，后面理解这些技术为什么存在就毫不费力。

4. 名词解释与易混概念：把散点串成链路

4.1 实体、对等层、服务访问点、协议数据单元，其实是一条链

这一组名词单独背非常容易混，因为它们的定义互相引用。正确的记忆方式是把它们放进一次完整的通信过程里，让它们各自有位置。

从最上层往下看：两台主机要通信，它们是对等的，也就是说双方的应用层对应用层、运输层对运输层。这种"不同机器上同一层次"的对应关系就叫对等层。在对等层上真正干活的东西不是"层"本身，而是层里活动的进程，这个进程就叫实体。实体之间交换的数据单位叫协议数据单元，不同层的协议数据单元有不同的名字：应用层叫报文，运输层叫报文段，网络层叫分组或者数据报，链路层叫帧，物理层就是比特流。

那上层怎么使用下层的服务？通过服务访问点。服务访问点可以理解成层与层之间的"插座"，上层把数据从这个插座递下去，下层把结果从这个插座递上来。网络层的服务访问点就是 IP 地址，运输层的服务访问点就是端口号。这个对应关系一旦记住，你就能明白为什么说"IP 地址标识主机，端口标识进程"——它们本来就是不同层上的插座。

把这四个概念串成一句话：对等层上的实体，通过服务访问点使用下层服务，并按照本层协议与对等实体交换协议数据单元。能默写出这句话，这一组名词就再也不会混。

4.2 客户-服务器方式与对等通信，相同点比不同点更容易被漏掉

这道题的常规答法是列不同点：客户-服务器方式中，客户是服务请求方，服务器是服务提供方，角色固定，服务器需要一直运行并拥有固定地址；对等通信方式中，每个节点既是客户又是服务器，角色对等，可以动态加入退出。这些都没错，但题目往往还会追问一句"有没有相同的地方"，这一问才是拉开差距的地方。

相同点至少有两条。第一，两种方式都是端系统之间的通信方式，都不涉及路由器等核心设备的行为，核心部分对它们是中立的。第二，两种方式在底层都依赖同样的传输服务，无论是集中式的服务请求还是节点间的直接交互，最终都要落到分组交换网络上的进程间通信，都需要寻址、都需要处理可靠性问题。

还有一个更本质的相同点：两种方式解决的都是"资源在哪里、谁去取"的问题。客户-服务器方式把资源集中管理，代价是服务器成为瓶颈和单点；对等通信把资源分散到各节点，代价是寻址和维护变得复杂，一致性难以保证。理解到这一层，你在讨论分布式系统架构时就有了一个稳定的分析框架。

4.3 那两个关于 IP 的表述，考的是对"承载关系"的理解

"everything over IP"和"IP over everything"这两个说法经常被放在一起考，很多人只能背中文翻译，说不清含义。它们的核心都在"over"这个介词上，指的是承载关系。

everything over IP说的是：所有的应用和业务，不管原来是语音、视频还是数据，最终都可以承载在 IP 之上。这解释了为什么IP 能成为事实上的统一网络层——它提供了一个足够简单的公共底座，各种业务自己在上层解决自己的特殊需求。

IP over everything说的是：IP 本身可以运行在各种各样的底层网络技术之上，不管底层是以太网、光纤、无线还是别的什么链路，只要它能提供基本的帧传输能力，IP 就能跑在上面。这解释了为什么 IP 具有极强的适应性和生命力，新的链路技术出现时，不需要重新设计整个协议栈，只要实现底层驱动就行。

这两句话合起来，描述的是一个双向的解耦：上层业务与 IP 解耦，IP 与底层链路解耦。这个设计思想是整本书里最值得反复体会的一点，它的精髓和分层是同一个道理——把变化挡在接口之外。

5. 错题复盘：那些年年重复的错误和一套可复用的自测流程

5.1 高频错误速查表

下面这张表是我从实际带人过题的经验里整理出来的，每一条都至少见过三次以上。做题时对着表扫一遍，比重新看一遍教材的效率高得多。

这张表里最值得警惕的是第一行。带宽和时延的关系是整门课里被误解最多的一个点，很多工作多年的人在讨论网络性能时依然会说"带宽不够所以延迟高"，这是把吞吐量和时延两个完全不同的指标混在一起了。带宽决定的是单位时间能送多少数据，时延决定的是数据从 A 到 B 要多久，两者可以完全独立。

5.2 一套二十分钟能跑完的自测流程

我给自己设计过一个简短的检查流程，用来判断第一章到底掌握到什么程度。整个过程二十分钟左右，不翻书，做完再对照。

第一步，五分钟，默写三种交换方式的对比表。五个维度，每个维度两句话，写不满说明对比框架没建立起来。

第二步，五分钟，做一道双场景时延计算题。自己改数字，比如把距离改成 2000 公里，数据长度改成 10⁴ 比特，速率改成 10 兆比特每秒，看看能不能在半分钟内把发送时延、传播时延、时延带宽积全算出来且量级正确。

第三步，三分钟，把五个层次的协议数据单元名字写出来，再写出每一层的一个典型协议和一个典型设备。写不出来说明体系结构还是散的。

第四步，三分钟，用自己的话解释"为什么分组交换成为主流"，不许用"灵活""高效"这种词，必须落到存储转发、流水线并行、出错重传代价这三个机制上。

第五步，四分钟，回顾错题。把上面那张速查表看一遍，回想自己最近一次做错的题属于哪一类。

这套流程的价值在于它逼你用"输出"来检验，而不是用"眼熟"来安慰自己。第一章的知识点太少太集中，看第二遍的时候几乎每句话都眼熟，但眼熟和能写出来之间差着一条鸿沟。

5.3 一段可以直接跑的小脚本，专治单位换算

单位换算这种事，靠人脑检查总会有漏网之鱼。我后来干脆写了一个几行的小脚本，把所有中间量都打印出来，量级不对一眼就能看出来。这比反复手算靠谱得多，尤其是在连续做十几道计算题的时候。

def delay_report(data_bits, rate_bps, distance_m, v_mps=2.0e8): tx = data_bits / rate_bps prop = distance_m / v_mps bdp = prop * rate_bps total = tx + prop print(f"发送时延: {tx:.3e} s ({tx*1e3:.3f} ms)") print(f"传播时延: {prop:.3e} s ({prop*1e3:.3f} ms)") print(f"时延带宽积: {bdp:.3e} bit ({bdp:.1f} bit)") print(f"总时延(忽略处理与排队): {total:.3e} s") print(f"主导分量: {'发送' if tx > prop else '传播'}") print("-" * 40) # 场景一：大数据量、低速率 delay_report(data_bits=10**7, rate_bps=100e3, distance_m=1000e3) # 场景二：小数据量、高速率 delay_report(data_bits=10**3, rate_bps=1e9, distance_m=1000e3) # 场景三：中等距离、中等速率，自行改参数对比 delay_report(data_bits=8000, rate_bps=10e6, distance_m=200e3)

跑出来的结果和手算能对上，就说明公式和单位都对了。脚本里我把"主导分量"也打印出来，这是为了强制自己每次做题都做一次判断，而不是算完数字就完事。考试时虽然不能带脚本，但这种"算完必须判断谁主导"的习惯是可以带进考场的。

顺带说一个使用心得：改参数的时候，每次只改一个量，观察输出怎么变。一次性改三个参数，你根本不知道哪个因素在起作用。这也是我自己摸索出来的学习方法——单变量对比比一次性看结论有效得多。

6. 我在反复过这一章时形成的几点判断

第一章的习题做三遍以上，会有一个很有意思的转变。第一遍是"对着题目找知识点"，第二遍是"看到题目就知道它在考哪个维度"，第三遍你会发现很多题其实是同一道题的变体——时延那道题和时延带宽积那道题，考的都是"哪个分量主导"；协议与服务那道题和分层理由那道题，考的都是"水平与垂直的分工"。

我个人最深的体会是，这一章真正需要背的东西极少，需要建立的直觉极多。比如"带宽不等于时延"这个直觉，光靠背是建立不起来的，必须自己动手算过至少两组数量级差距极大的数据，看着发送时延从 100 秒变成 1 微秒而传播时延纹丝不动，那种冲击感才会留在脑子里。再比如"固定开销对小包惩罚严重"这个直觉，只有亲自把 100 字节和 1000 字节的传输效率都算一遍，看到 63% 和 94% 这个对比，才会真正理解为什么协议设计里到处都在想办法减少往返次数。

如果只允许我给一条建议，那就是把第一章所有计算题的数字都改一遍再做一次。改数字这个动作看起来笨，但它能让你从"记住答案"切换到"掌握关系"，而后者才是后面所有章节真正依赖的东西。