别再死记公式：用Wireshark抓包实测TCP吞吐量，定位千兆带宽瓶颈

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 常见问题速查表

5.5 几条实操心得

第一条，抓包前先想清楚要回答什么问题，带着问题设过滤，比抓一大堆再翻效率高得多。第二条，任何结论都要有数据支撑，看到吞吐量低不要急着下判断，先把窗口、时延、重传三个数拿出来。第三条，实验环境和真实环境有差距，实验里复现的问题拿到真实环境要重新验证，不要直接套结论。第四条，Wireshark的专家信息是入口不是终点，它标出来的问题要回到具体报文确认，有些标记是正常现象被误报。

我个人在实际操作中的体会是，吞吐量排障最怕的不是工具不会用，而是没有形成固定的分析顺序。先看整体吞吐量曲线，再看窗口和时延，最后看丢包细节，这个顺序走下来，大部分问题都能定位到具体环节。反过来，一上来就逐包翻，很容易陷进细节里出不来。另外，把每次测量的窗口、时延、吞吐量记在一个小表里，时间长了能看出规律，比每次从零开始强很多。