1. 先搞清楚问题1G带宽跑不满到底卡在哪一层很多人第一次碰到“千兆带宽跑不满”的场景第一反应是运营商缩水、网线太差、路由器太老。这些确实可能是原因但如果你手里有一台能跑Wireshark的机器最该做的第一件事不是换硬件而是抓一次包把吞吐量这件事从“感觉”变成“数据”。TCP吞吐量这个词听起来很学术说白了就是单位时间内真正搬过去的有用数据量它和链路带宽不是一回事。链路带宽是马路宽度TCP吞吐量是实际车流量中间隔着红绿灯、收费站、事故现场。这个项目标题里提到的“别再死记公式”指向的正是很多人背过但没真正理解的吞吐量公式吞吐量约等于窗口大小除以往返时延。背下来只要十秒但为什么窗口是64KB的时候千兆链路只能跑出几十兆为什么调大窗口之后还是上不去为什么抓包看到的和公式算出来的对不上这些问题光靠背公式永远解决不了。Wireshark在这里的价值是把公式里的每一个变量变成你能亲眼看到的字段窗口大小在TCP头部里往返时延在时间差里重传和丢包在专家信息里。这篇内容适合三类人看。第一类是刚接触网络排障的运维或开发手里有抓包工具但不知道从哪看起第二类是做性能测试的工程师需要一套可复现的测量方法而不是拍脑袋第三类是对TCP原理有兴趣但被公式劝退的读者想通过真实数据把概念串起来。我会从整体思路讲起然后拆解Wireshark里真正要看的几个字段再给出一套完整的抓包实测流程最后把常见坑和排查表整理出来。全程用一台普通机器加一个模拟环境就能复现不需要特殊设备。需要先说明一点下面涉及的具体参数、窗口数值、时延数据都是基于常见实验环境的合理设定用于说明方法不代表任何特定网络环境的真实测量结果。你自己动手时数值一定和我的不一样但看数据的方法是一样的。2. 整体设计与思路拆解为什么用抓包而不是跑分软件2.1 跑分软件给的是结果抓包给的是原因测带宽最常见的做法是跑一个测速工具看它给出的数字。这个数字有用但它只告诉你“慢”不告诉你“为什么慢”。就像去医院只量了体温知道发烧了但不知道是病毒感染还是细菌感染。抓包不一样它把每一个TCP报文的时间、序号、确认号、窗口、标志位全部摊开你能看到发送方发了多少、接收方确认了多少、中间有没有重传、窗口有没有被压到零。我试过一个很典型的对比同一台机器、同一条链路测速工具显示下行只有三百多兆看起来像是链路问题。抓包之后发现接收窗口在传输过程中反复收缩接收端应用读取速度跟不上数据堆在缓冲区里发送方被迫停下来等。这种情况下换网线、换网卡都没用瓶颈在应用层。如果没有抓包这个结论根本得不出来。所以这个项目的核心思路是用Wireshark做一次端到端的TCP会话捕获把吞吐量的构成要素逐项量化再和理论值对比定位差距来源。整个方案围绕三个问题展开——链路能跑多少、TCP实际跑了多少、差距被谁吃掉了。2.2 为什么选Wireshark而不是其他手段抓包工具不少选Wireshark的理由很实际。第一是字段解析全TCP头部的窗口缩放因子、选择性确认、时间戳选项这些影响吞吐量的细节它都能直接展开看不用自己对着十六进制数位。第二是统计功能够用它的TCP流图形、往返时间统计、专家信息能把海量报文压缩成几条趋势线省去大量手工计算。第三是跨平台且免费实验环境搭起来没有成本门槛。当然它也有局限比如高吞吐场景下抓包本身会丢包这个后面会专门讲。但在千兆以内的实验环境里配合合理的捕获过滤和缓冲区设置它完全够用。这里的关键不是工具多强而是你要知道看哪些字段这正是下一节要拆的内容。2.3 测量方案的整体框架整个实测分四步走。第一步是搭一个可控的传输环境发送端和接收端之间链路明确最好能人为制造时延和丢包方便对照。第二步是在接收端或中间节点抓包捕获过滤只留目标TCP流避免噪声。第三步是把抓到的数据按吞吐量公式拆解逐项核对窗口、时延、重传。第四步是对比理论吞吐量和实测吞吐量差距大的地方就是排查重点。这个框架的好处是可复现。你不需要记住任何结论只要按步骤抓一次包数据会自己说话。下面几节就按这个顺序展开先讲字段再讲操作最后讲排查。3. 核心细节解析吞吐量公式里的每个变量在Wireshark里长什么样3.1 窗口大小不是头部那个16位数字那么简单吞吐量公式里最容易被误解的就是窗口大小。TCP头部里有一个16位的窗口字段最大表示65535字节很多人看到这个数字就以为窗口最大就是64KB然后算出千兆链路在几十毫秒时延下只能跑几兆得出“TCP跑不满千兆是正常的”这种半对半错的结论。问题出在窗口缩放选项上。实际窗口等于头部窗口字段左移缩放因子位缩放因子在三次握手时通过窗口缩放选项协商最大可以到14也就是窗口能放大到约1GB。Wireshark里看这个要展开TCP选项找到“Window Scale”字段然后在后续报文里看“Calculated window size”这个计算值那才是真实窗口。只看“Window size”原始字段会严重低估。这里有个实操细节窗口缩放只在握手阶段协商一次抓包如果从会话中途开始就看不到协商过程Wireshark也就无法正确计算窗口。所以抓包一定要从连接建立开始或者至少确保捕获到了SYN报文。我踩过这个坑中途抓的包窗口显示一直是64KB左右差点误判成接收端没开缩放。3.2 往返时延平均值会骗人要看分布往返时延是公式的分母它的测量方式直接影响结论。Wireshark的TCP流图形里能直接看到往返时间曲线但要注意它统计的是哪些报文。如果会话里有大量重传重传报文的往返时间计算会失真把平均值拉高。更稳妥的做法是看正常数据报文和对应确认之间的时间差或者用Wireshark的“TCP Stream Graphs”里的往返时间图观察分布而不是只看一个平均数。时延对吞吐量的影响是非线性的因为窗口填满链路需要时间。链路带宽时延积这个概念在这里很关键带宽乘以往返时延就是“在途数据量”也就是窗口至少要多大才能把链路喂满。千兆链路、20毫秒往返时延带宽时延积大约是2.5MB窗口小于这个值吞吐量就被窗口卡住和链路带宽无关。这个计算过程建议自己动手算一遍比背公式印象深得多。3.3 重传与丢包吞吐量的隐形杀手丢包对吞吐量的打击远超直觉。一次丢包触发重传重传等待时间至少是一个往返时延期间发送方可能进入拥塞控制窗口减半。如果丢包是随机分布的吞吐量会掉得很厉害。Wireshark的专家信息里会把重传、快速重传、重复确认标出来TCP流图形里也能看到序列号的锯齿。看丢包要注意区分类型。超时重传说明情况比较严重可能是确认丢失或者链路彻底断了快速重传说明接收端通过重复确认发现了空洞发送方及时补发影响相对小。还有一种容易被忽略的是虚假重传发送方误判丢包而重传实际数据已经到了这种会浪费带宽但不一定反映链路问题。抓包时把这几类分开统计才能判断瓶颈性质。3.4 接收窗口与发送窗口两个方向都要看吞吐量受限于发送窗口和接收窗口中的较小者。发送窗口由拥塞窗口和接收窗口共同决定拥塞窗口是发送方自己维护的抓包里看不到直接字段但可以通过在途未确认数据量反推。接收窗口在确认报文里反映接收端缓冲区的剩余空间。实际排障中接收窗口收缩到很小甚至零窗口往往说明接收端应用读取太慢数据在缓冲区堆积。这时候看零窗口探测报文和窗口更新报文的时间间隔能判断应用卡了多久。发送窗口受限则更多和拥塞控制有关表现为在途数据量上不去但接收窗口还有余量。两个方向分开看才能定位是发送端不敢发还是接收端收不下。4. 实操过程从搭环境到算出吞吐量的完整步骤4.1 环境搭建与捕获点选择实验环境可以很简单两台机器直连或者通过一台可管理的交换机相连发送端跑一个能持续发送数据的服务接收端用Wireshark抓包。如果想模拟真实网络可以在中间加一台能配置时延和丢包的设备或者用操作系统自带的流量控制功能在网卡上注入时延。时延设20毫秒、丢包率设百分之零点一就能复现很多真实场景的问题。捕获点的选择有讲究。在接收端抓包看到的是经过链路之后的报文丢包和乱序都能反映出来适合分析传输质量。在发送端抓包看到的是发出去的原始报文适合分析发送行为。两端同时抓再对比能定位丢包发生在哪一段。实验阶段建议先在接收端抓简单直接。捕获过滤要提前设好只抓目标端口或者目标主机的流量避免抓到无关报文把缓冲区撑爆。捕获缓冲区调大一些千兆环境下建议至少几百兆否则高速传输时容易丢包抓到的数据本身就不完整。4.2 关键捕获参数与过滤表达式捕获过滤和显示过滤要分开理解。捕获过滤在抓包开始前生效决定哪些报文进入缓冲区语法用BPF显示过滤在抓包之后生效决定哪些报文显示出来语法是Wireshark自己的。捕获过滤写错了会漏抓显示过滤写错了只是看不到数据还在。一个常用的捕获过滤是只抓某个主机的某个端口比如host 192.0.2.10 and port 5201这里的地址是文档专用地址实际替换成你自己的。显示过滤可以用tcp.analysis.flags快速筛出所有带分析标记的报文重传、重复确认、零窗口都在里面。想看某个方向的流用tcp.stream eq 0锁定一条流避免多条流混在一起。注意捕获过滤里不要用tcp port这种过于宽泛的条件去抓高吞吐流量缓冲区很容易被无关报文占满导致真正想看的报文被丢弃。宁可条件写窄一点多抓几次。4.3 用TCP流图形量化吞吐量抓到包之后第一步不是逐个看报文而是打开统计里的TCP流图形。吞吐量图能直接看到单位时间内的字节数曲线稳定传输阶段曲线的高度就是实测吞吐量。时间序列图能看到序列号随时间的增长斜率斜率就是吞吐量斜率变平的地方就是传输受阻的地方。往返时间图用来核对时延假设如果曲线在某段时间突然抬高对应时间点的吞吐量往往同步下降。窗口图能看到接收窗口和在途数据量的变化窗口收缩和吞吐量下降的时间点对得上基本就能锁定原因。这几张图配合看比逐包分析效率高得多。图形里的数值可以导出导出成文本之后自己做一次积分或者取稳定段平均得到的就是可引用的吞吐量数字。注意要避开慢启动阶段取传输稳定后的区间否则算出来的平均值偏低。4.4 从抓包数据反算理论吞吐量并对比有了实测吞吐量再算理论值做对比。理论吞吐量取窗口大小除以往返时延窗口用抓包里看到的计算窗口时延用稳定段的往返时间。算出来的值和实测值对比差距在百分之十以内基本可以认为窗口和时延是主要限制因素差距很大就要看重传率和零窗口。举个模拟的例子说明计算过程假设抓包显示计算窗口约256KB稳定段往返时延约20毫秒理论吞吐量约等于256KB除以0.02秒约12.8MB每秒换算成比特约102Mbps。如果实测只有80Mbps差距主要来自重传和协议开销如果实测接近100Mbps说明瓶颈就是窗口和时延的组合链路本身没问题。这个反算过程建议每次排障都做一遍能快速判断问题性质。4.5 一次完整的实测记录示例模拟环境里做一次完整测量接收端抓包发送端持续发送六十秒捕获过滤限定目标端口。抓完后先看专家信息重传报文占比不到百分之一没有零窗口。TCP流图形显示吞吐量在前五秒爬升之后稳定在某个水平往返时间曲线平稳。导出稳定段数据计算平均吞吐量再和窗口除以时延的理论值对比差距约百分之八主要来自TCP头部开销和确认报文占用。这个结果说明链路和窗口配置基本匹配没有明显异常。如果实测远低于理论值就按下一节的排查表逐项检查。整个流程走一遍大约十几分钟比反复换硬件试错快得多。5. 常见问题与排查技巧实录5.1 抓包本身丢包导致数据失真高吞吐场景下最容易出的问题是抓包工具自己跟不上。Wireshark在用户态处理报文千兆满速时每秒几十万包普通机器很容易来不及处理内核缓冲区满了就丢包。表现是抓到的报文序号不连续看起来像网络丢包实际是抓包丢了。判断方法看捕获统计里的丢包计数如果这个数字不为零抓包结果就不可信。解决办法是调大捕获缓冲区、缩小捕获过滤范围、把抓包文件写到高速磁盘或者改用命令行工具先抓后分析减少界面开销。实测下来命令行抓包比图形界面稳定得多分析阶段再打开文件。5.2 窗口缩放没协商导致误判前面提过中途开始抓包看不到窗口缩放协商Wireshark算出来的窗口偏小容易误判成接收端窗口不足。排查时先确认抓包是否包含SYN报文如果没有要么重新从连接建立开始抓要么手工在Wireshark里设置窗口缩放值。这个坑很隐蔽因为界面上的窗口数字看起来很正常只是偏小。5.3 把带宽时延积算错方向带宽时延积算的是在途数据量单位是字节不是比特。有人用带宽的比特数直接乘时延算出来的数字大了八倍得出窗口需求被高估的结论。正确做法是先把带宽换算成字节每秒再乘往返时延秒数。千兆链路约125MB每秒乘20毫秒得2.5MB这个数量级要心里有数。5.4 常见问题速查表现象可能原因排查动作实测吞吐量远低于窗口除以时延重传率高或零窗口看专家信息重传占比看窗口图是否触零窗口显示一直很小未抓到握手或缩放未协商确认捕获含SYN检查窗口缩放字段抓包序号不连续抓包工具丢包看捕获统计丢包计数改用命令行抓包吞吐量曲线锯齿明显拥塞控制反复调整看丢包类型区分超时重传和快速重传往返时间曲线突然抬高链路拥塞或队列堆积对照吞吐量下降时间点检查中间设备5.5 几条实操心得第一条抓包前先想清楚要回答什么问题带着问题设过滤比抓一大堆再翻效率高得多。第二条任何结论都要有数据支撑看到吞吐量低不要急着下判断先把窗口、时延、重传三个数拿出来。第三条实验环境和真实环境有差距实验里复现的问题拿到真实环境要重新验证不要直接套结论。第四条Wireshark的专家信息是入口不是终点它标出来的问题要回到具体报文确认有些标记是正常现象被误报。我个人在实际操作中的体会是吞吐量排障最怕的不是工具不会用而是没有形成固定的分析顺序。先看整体吞吐量曲线再看窗口和时延最后看丢包细节这个顺序走下来大部分问题都能定位到具体环节。反过来一上来就逐包翻很容易陷进细节里出不来。另外把每次测量的窗口、时延、吞吐量记在一个小表里时间长了能看出规律比每次从零开始强很多。
