★ FEATURED ARTICLE 学计算机网络的几乎没谁没被“快”这个字坑过。我有次给学生讲期末题讲到“发送速率100Mbps、传播速率2×10^8m/s”时底下有人问了一句这俩不都是每秒能跑多远吗为啥是俩数这个问题问到了根子上。很多人对高速网络的“快”只有一种模糊直觉——反正就是快。但一旦面对一道期末计算题要算一个数据包从A到B到底花多少时间就会发懵到底该用“带宽”去除数据大小还是该用“线缆速度”去除距离一旦弄混计算结果能差出好几个数量级。这篇内容适合谁准备考研、期末考的计算机/通信学生正在搞项目性能调优的开发人员以及任何想真正搞懂网络延迟本质的从业者。不绕弯子直接把发送速率和传播速率掰开揉碎讲明白。1. 先说清楚一道题里藏着的四个时间1.1 数据从一端到另一端凭什么要花时间把一个数据包从主机A送到主机B不是一瞬间的事。很多人简化成“发出去就收到了”那是理解网络延迟最大的误区。实际上数据包从源头到目的地要经历四种时间这四种时间对应四个不同的物理过程发送传输延迟发送端把数据比特依次“推”上线路的时间。只要数据没发完线路口就还在忙。传播延迟已经上线路的比特以电磁波的速度在介质里跑到对端的时间。这是“已经在路上跑”的时间。处理延迟路由器/交换机检查头部、查路由表、决定转发端口的时间。排队延迟数据在路由器的缓冲区里排队等待被处理/发出的时间。期末考基本围绕前两个因为前两个是常量和基础认知后两个在理论题里通常假设为0或给具体数值。这道经典的传输题主线就是计算“发送延迟 传播延迟”——前者数学上叫发送时间 数据大小 ÷ 发送速率后者叫传播时间 链路长度 ÷ 传播速度。1.2 为什么“发送”和“传播”不是一回事打个比方。高速公路上有一队卡车每辆卡车运着集装箱货物从北京跑上海。发送速率 收费站每分钟能放行多少辆车。车越多、收费站放行速度越快全队车“全离开收费站”所需的时间就越短。传播速率 卡车上高速后的行驶速度。路况好、车速快第一辆车就能更快到上海。收费站一分钟放行5辆这叫“发送速率”。车在高速上跑120km/h这叫“传播速率”。二者一个管“上车前”一个管“上路后”。如果你拿“行驶速度”去算“全队车离开收费站的时间”算出个不三不四的数拿“放行速度”去算“从北京到上海的到货时间”同样错得离谱。数据包进链路和“车队离开收费站”本质是同一件事。链路带宽就是“收费站吞吐”或“发送时间模型”的表现电磁波速度才是“路段通行能力”。2. 发送速率和传播速率到底差在哪2.1 用公式说话两个最小单位为秒的距离变量先看两个标准公式发送延迟传输延迟Transmission Delay [ T_{trans} \frac{L}{R} ] 其中L是数据量比特R是链路带宽bps。单位是秒。传播延迟Propagation Delay [ T_{prop} \frac{D}{V} ] 其中D是链路长度米V是信号在介质中的传播速度m/s。单位也是秒。这俩公式长得就不像。一个除以带宽一个除以速度。一个跟“数据包的大小”挂钩一个跟“物理距离”挂钩。哪怕同一根1米长的网线只要线上有不同的信号传播速度传播延迟就会变但只要带宽不变发送延迟就只由数据大小决定。很多新手把“发送速率”记成网速、下载速率——比如100Mbps宽带。这个概念本身不叫错100Mbps确实说的是链路带宽下载文件的速度也确实取决于带宽。但传播速率这个概念完全不在用户感官层出现。光纤里的信号传播速度大约 2×10^8 m/s是真空中光速的2/3这个数跟“你的宽带是100M还是1000M”没有半毛钱关系。2.2 一个常被忽略的物理事实线缆里的光速并不快光速 c ≈ 3×10^8 m/s但光在光纤里不是沿直线飞而是全反射路线前进实际路径更长。工程上一般取光纤传播速度约 2×10^8 m/s铜缆双绞线里的电信号速度约为 2.3×10^8 m/s。有个让人直观感受“传播速率其实没那么快”的例子数据沿光纤从北京到上海直线约1000公里链路距离算上盘绕和冗余实际可能到1200公里以上。按 2×10^8 m/s 算完单程传播延迟至少5~6毫秒。你再快的光模块光速也跑不满物理极限。这就是为什么物理链路一长延迟下限就定死了。而发送延迟则完全由“技术参数”决定。同样是传1MB数据100Mbps链路需要约83.9ms1Gbps链路需要约8.39ms带宽越高发送越快。注意如果数据包特别小比如一个TCP的SYN包只有几十字节带宽再高每秒能“拍”出的比特数有限它很快就能发完但还是要花一个完整传播延迟跑完整根链路。这个“极小包也没法超光速”的直觉后面做题特别重要。2.3 数据包像火车链路像铁轨再换一个更准确的生活类比发送速率 火车站把一列列火车从站台催发出去的速度列/小时。决定这个速度的是站台设施、调度系统。 传播速率 火车在铁轨上的运行速度km/h。决定这个速度的是铁轨质量和列车动力。一列火车全程耗时 所有列车全部离站的时间 最后一列车奔跑到终点的时间。两列火车一个接一个发出第一列已经在铁轨上跑了后面还在站台排队这两段时间显然是重叠但独立的。很多人把网络里的比特想象成“已经在线上跑的东西”这是对的但“把比特推上线”这个动作本身需要时间这件事没做过网线的人很难建立物理直觉。3. 真题拆解经典题是怎么考这两个参数的3.1 原题长什么样这题在很多版本的计算机网络教材和期末卷里都出现过大致形式如下某主机向另一台主机发送一个 1KB 的数据分组。链路长度为 100km链路带宽为 1Mbps信号传播速度为 2×10^8 m/s。假设无处理延迟与排队延迟忽略确认帧求 1该分组的发送延迟 2该分组的传播延迟 3该分组从开始发送到最后一个比特到达接收端的总时间。一般还会给个类似“求带宽延迟积”或“若长度变为1000km总时间怎么变”的变体。3.2 逐步算给你看换算一律走标准单位别在十进制和二进制之间习惯性滑走1KB 选哪个进制这题里一般按 8×1024 bit 算也就是 8192 bit。如果题目明确写 1000 字节那就用8000 bit。别小看这种约定期末考每次都有人因为这里用错了基数后面全崩。发送速率1Mbps 10^6 bps网络领域Mbps基本是百万位每秒不是2^20。第一步发送延迟 [ T_{trans} \frac{8192}{10^6} 8.192 \text{ ms} ]第二步传播延迟 [ T_{prop} \frac{100 \times 10^3}{2 \times 10^8} 5 \times 10^{-4} \text{ s} 0.5 \text{ ms} ]第三步总时间 注意“从开始发送到最后一个比特到达”不是把两个时间相加就完事但在这个单分组、无管道化复杂处理的模型下它确实是 [ T_{total} T_{trans} T_{prop} 8.192 0.5 8.692 \text{ ms} ]那么问题来了为什么直接相加因为发送过程持续8.192ms在这个过程期间最早发出的比特已经在链路上向前挪了。发送停止的那一刻最后一个比特刚进入链路它离接收端还有100km要跑而跑完这100km还需要0.5ms。所以总时间纯粹是“发送完所需时间最后一个比特独自跑完剩余链路所需时间”。如果链路长度极端比如变成10000km差不多跨洲际光缆的长度那 [ T_{prop} \frac{10^7}{2\times10^8} 0.05 \text{ s} 50\text{ ms} ] 传播延迟就会反超发送延迟总时间变成 58.192 ms。这个时候你再追带宽收益就很有限了——因为大头在物理距离上。3.3 最经典的“反直觉”变形考法很多老师会加一问连续发送三个分组求第二分组的端到端总时间。这里就有两个细节第一个分组发送需要8.192ms第一个分组发完第二个分组立刻开始发。第二分组的发送结束时间 8.192×2。第二分组到达接收端时间 第二分组发送结束 最后一位比特跑完链路0.5ms 16.884ms。如果题目要求“第三个分组的第一个比特到达接收端的时间”那又不一样——第三分组的第一个比特在第三分组发送的最初瞬间就进入链路了它在链路上跑0.5ms。关键是我见过不少学生在“这是第几个分组的第几个比特”上转不过弯直接把整个分组的发送时间都加上去白丢分。遇到这种什么“分组1的最后一个bit”还是“分组3的第一个bit”先画个时间轴。这题考的不是计算能力而是你脑子里有没有“流水线作业”的图景。4. 进入真实世界为什么“快”明明有两种大家却只关注一种4.1 长短链路下主导因素完全反过来理论题把参数摆在那里什么100km、1000km你都觉得是抽象数字。实际网络里这两种延迟主导的场景截然不同短距离场景比如机房内服务器到交换机机房里一个ToR交换机连着几十台服务器线缆长度通常就几米到几十米。在10米铜缆上传播延迟大约 [ \frac{10}{2.3 \times 10^8} ≈ 43.5 \text{ ns} ] 这也就是一个CPU时钟周期级别。而这个场景下如果你想传一个大文件在一个10Gbps链路上发10MB数据发送延迟约8.39ms比传播延迟高了好几个数量级。这时候你体验到的“快”或“慢”几乎完全由发送速率带宽决定。长距离场景比如跨城、跨境链路从北京机房到上海机房物理距离走地下光缆可能有1500km。单程传播延迟 [ \frac{1.5\times10^6}{2\times10^8} 7.5\text{ ms} ] 这就是你从上海访问北京某接口PING显示15ms左右往返而绝对下不来的原因。你在北京拉一个上海服务器上的1KB网页发送延迟小到忽略不计大头基本是7.5ms传播延迟。这时候就算你家带宽从100M升到1000MPING值也不会有任何变化——因为“重”根本不在带宽上。这是一个真实项目的排查记忆当时某服务的接口偶发性高延迟业务团队一开始疯狂调服务器参数、调并发全没用。后来抓包看时间戳发现是用户在北京、业务在上海单程传播延迟就是8ms左右。后来把部分服务迁到更近的边缘节点延迟直接从40ms降到10ms以下。换带宽解决不了物理距离问题。4.2 带宽延迟积一个连接里能“塞进管道”的数据量学习考试总爱考一个概念叫“带宽延迟积”。它其实非常直观[ BDP R \times T_{prop} ]单位是比特。它表示的物理意义是在这条链路上从第一个比特开始传播那一刻起到最后一个比特能够以最大速率离开发送端的那一刻止通常就是传播延迟那段时间里“已经在线路上但还没到对端”的数据总量。打个比方一条高速公路全程畅通无阻收费站每个小时放行100辆车。第一辆车从收费站跑到出口全程需要2小时。那这条路上最多同时容纳多少辆车200辆。这200辆不是拥堵是“正常占用的管道容量”。在TCP调优里BDP决定了你的发送窗口至少应该多大。如果你带宽是10Gbps往返延迟RTT就是两倍的传播延迟加传输处理时间是20ms那BDP就是 [ 10\times10^9 \times 0.02 2\times10^{8}\text{ bit} 25\text{ MB} ] 你的接收窗口如果小于25MB那TCP就永远跑不满带宽。程序员的代码写得再正确也没用——这是传输层机制决定的。很多人做网络性能优化查了半天最后发现自己只是没调大buffer。这道期末题背后的深刻之处在于带宽决定“吞吐上限”传播延迟决定“等待下限”。BDP把它们焊在了一起让你理解高带宽和低延迟究竟分别能买来什么、买不来什么。5. 容易掉进去的坑和几个刷题笔记5.1 高频易错点为什么你总把两个公式混用我见到的错法集中在以下几条把发送延迟算成“数据大小 ÷ 传播速度”。连单位都不对。数据是bit速度是m/s两者正交。会出现这种错法一般是看到“速率”两个字就下意识用。把传播延迟算成“距离 ÷ 带宽”。更离谱但理论上真有人统计过能把距离m直接除带宽bps的确实有因为脑子记岔了公式。单位不换链路长度用km传播速度用m/s结果忘了乘1000。送上门的5分就这么丢了。把“最后一个比特到达时间”算成“第一个比特到达时间”。第一个比特到尾只需要 (T_{prop})最后一个比特到尾需要 (T_{trans}T_{prop}) 或更长。题目问的是“分组完全接收”就是最后一个比特别搞混。连续分组时把每个分组的传播延迟都加一遍。正确的模型是后续分组不需要重新跑“从头到尾”的传播——因为它们的第一个比特在发送的最初瞬间就已经进链路了。只要不产生排队每个分组追加的总时间就是发送时间一次传播时间。我自己有个做题习惯拿到题先画一条时间轴竖线标“开始发送”横着标出发送持续区间然后在末端画一条长箭头表示传播。画出来以后公式只是记录不再需要背。5.2 区分“第一比特”和“最后一比特”是理解全题的关键经典题最容易让人绕晕的不是计算而是对“分组到达”的定义。分组第一个比特到达接收端发生在它刚离开发送端、在链路上跑了D/V时间之后。分组最后一个比特到达接收端发生在整个分组被发送端“推”上线之后最后一个比特再独自跑完D/V时间。再直接一点如果一个分组总长很大你甚至可以近似认为“第一个比特已经到对端了最后一个比特还没出门”。这不是什么特例是管道传输里的常态。我在真实网络抓包时也见过这种现象——一个大TCP窗口的数据包链表上同时存在十几个包首尾相距很远。理解了这个就理解了为什么TCP的滑动窗口要设计那么大为什么一个小带宽高延迟的链路不如高带宽低延迟的链路为什么RTT比带宽更容易影响单笔交互。5.3 做题时间管理三道变形题帮你彻底焊牢这里给你留三道变体可以做着玩带宽1Gbps距离100km传播速度2×10^8m/s数据包4096bit。求总时间。同一个链路连续发送两个包求第二个包整体到达的时间。把距离换成卫星链路地球同步轨道卫星单跳大约35786km传播速度按3×10^8m/s再求一个1KB分组在64kbps链路上的总时间。这个算出来你会对“PING卫星链路为什么慢”有直观感受。第三题很有信息量典型同步卫星高度约3.6万公里单程传播延迟约119ms但64kbps链路发送1KB需要128ms总时间就超过247ms。你看在这个场景里发送延迟和传播延迟都大两头堵。以前我刚工作时听老工程师说“网络调优先看RTT再看带宽”当时不以为然觉得带宽才是硬道理。后来做跨机房同步的时候把一堆小文件推到远端瓶颈全在RTT上才明白那句话说得多实在。6. 从这道题往外走两个参数怎么决定架构选型6.1 为什么CDN、边缘计算和“快”直接相关所有云厂商都在搞边缘节点搞CDN本质都是在缩短物理链路长度。因为传播延迟 距离 ÷ 速度那你没法超过光速就只能缩短距离。把这个逻辑想透了就明白为什么“内容离用户越近体验越好”不是一个销售话术而是物理定律逼出来的结论。现在你在手机上看视频视频源如果在北京你在广州访问即便骨干网速度极好也躲不开约30~40ms的传播延迟。但内容分发到广州边缘节点后距离一缩短到几十公里传播延迟就降到1ms以内。用户体验的提升大多数来自传播延迟的减少而不是带宽的增加——因为视频码率再高10Gbps也轻松扛得住真正影响首帧体验的是“最开头那一点数据什么时候到”。这道期末题在真实业务里的投影就是“PING值高”和“下载慢”这两个完全不同的病。PING高大概率是传播距离远或排队严重下载慢大概率是带宽不够或掌握窗口没调够。很多人一张嘴就说“网速慢”我从这道题开始就意识到“网速慢”至少有四种截然不同的病因。6.2 为什么“超低延迟”是个很难做的指标游戏行业的“帧同步”、“云游戏”、“远程手术”都特别强调端到端延迟要低到几十毫秒甚至几毫秒。但物理定律就在那光在光纤里2×10^8m/s在空气里约3×10^8m/s。上海到深圳直线距离1200km哪怕全程光纤最理想路径单程传播延迟也要6ms加上往返就是12ms再算上路由跳数、服务器处理、终端显示和刷新体感延迟轻轻松松就上50ms。所以当你看到“超低延迟网络”这类宣传时第一反应应该是它到底从哪一段缩短了延迟是压缩了传播路径还是提高了处理速度还是降低了排队概率这些是不同维度的优化对应着完全不同的技术方案。这些认知并不只在考试卷上有用。做网络优化的工程师如果对“发送速率”和“传播速率”没有刻在骨子里的区分遇到线上问题就会乱调参数白白耗掉大量时间。我不是没见过有人把“跨地域接口慢”误判成“平均负载太高”给服务疯狂扩容——结果PING值纹丝不动。这就是没分清延迟跟负载的直接后果。6.3 一句话总结咱从这道题里真正带走什么“快”不是一个单维度的概念。判断一次网络传输的快慢要同时盯住发送速率和传播速率这两个坐标轴发送速率决定了一条链路单位时间能“灌”多少数据进去是吞吐的关键。传播速率决定了一个比特在既定物理距离上跑多少时间是延迟的下限。BDP把这两个参数乘起来告诉你“在途数据”的规模又把吞吐和延迟连接成了同一条管道里的两个侧面。你做网络、做系统、做应用最终都在跟这两个数打交道。我个人在实际项目里的习惯是凡是拿到一个新网络拓扑先问两个数——链路带宽多少、物理距离多远然后秒算BDP和单程传播延迟。这两个数一出来很多性能问题的方向就定了。这道期末题看似简单但它背后压着的是整个网络性能世界的内功心法。多说一句实战经验在项目里估算跨地域接口性能时不要平均而谈也不要用那种“大概几十毫秒”的模糊说法。老老实实写个函数先查从本节点到对端节点的光纤公里数除以2×10^8得到单程下界再根据包大小和可用带宽算发送延迟两个数相加再乘以一个1.5到3的经验系数覆盖跳数、排队、处理等就是你能拿到的合理性能预测区间。我自己用这套粗估法和线上实测PING值经常能对到个位数毫秒。每次都感慨考试题当初觉得抽象后来发现现实世界比题里的模型还要线性。这题目你现在看着是期末必考后面工作了再看就是打开网络黑盒的一把钥匙。
阅读完成 · 觉得有帮助？
