一、为什么要测实际吞吐量和TCP窗口缩放

很多做网络相关开发的朋友，比如写视频传输工具、做云服务器跨地域同步、甚至是优化游戏联机延迟的，都会遇到一个问题：明明理论上网络带宽足够，实际跑起来却慢得离谱。比如你租了一条100Mbps的专线，测大文件传输却只有20Mbps不到，这时候就得搞清楚到底是哪里拖了后腿。 这俩指标就是找问题的关键：实际吞吐量就是网络真的能跑起来的传输速度，TCP窗口缩放是控制发送端一次能发多少数据的核心逻辑，理论值是理想状态下的数值，实际值是跑出来的真实结果，对比偏差就能快速定位问题。

二、需要用到的工具和环境准备

要做这个测试，咱们只需要两个东西：一个是Wireshark，用来抓包分析；另一个是用来跑传输的测试工具，这里统一用iperf3，因为它简单好用，适合测试TCP传输。

2.1 环境准备要求

得准备两台机器，一台当服务端（接收数据），一台当客户端（发送数据），两台机器的网络得通，比如同机房的两台云服务器，或者家里的两台电脑连同一个路由器。这里咱们先明确两台机器的IP：服务端IP设为192.168.1.100，客户端IP设为192.168.1.101。

2.2 工具安装

先装iperf3，不同系统安装方式不一样，这里以Ubuntu为例，安装命令很简单：

# 更新软件源
apt update
# 安装iperf3
apt install iperf3 -y

Wireshark的安装也很简单，Ubuntu下直接apt install wireshark，Windows和Mac直接去官网下安装包就行，安装的时候记得选允许普通用户抓包的选项，不然后面会有权限问题。

三、测试步骤和抓包分析

整个测试分四步：先开服务端，再开客户端，同时用Wireshark抓包，最后分析抓包结果。

3.1 第一步：启动iperf3服务端

服务端只需要一条命令，指定监听的端口就行，比如用默认的5201端口：

# iperf3服务端，监听5201端口
iperf3 -s -p 5201

这条命令执行后，服务端就会一直等着客户端来连，不用管它，先放着。

3.2 第二步：启动Wireshark抓包

打开Wireshark，找到客户端对应的网卡，比如你是用网线连的，就选有线网卡；用WiFi连的就选WiFi网卡。选好网卡后，点左上角的“开始抓包”按钮，这时候Wireshark就会开始记录所有经过网卡的网络包了。

3.3 第三步：启动iperf3客户端并传输

回到客户端机器，执行iperf3的客户端命令，这里咱们要跑10秒的TCP传输，方便后面分析：

# iperf3客户端，连接服务端192.168.1.100的5201端口，跑10秒
iperf3 -c 192.168.1.100 -p 5201 -t 10

执行后，客户端会开始向服务端传数据，10秒后会自动停止，这时候你会看到iperf3输出的一个大概的速度，比如“[ 5] 0.00-10.00 sec 11.7 MBytes 9.8 Mbits/sec”，这个就是iperf3测出来的大概吞吐量，但咱们要的是更准确的实际吞吐量和TCP窗口缩放的情况，所以得去Wireshark里分析。

3.4 第四步：停止Wireshark抓包并过滤

等iperf3跑完后，立刻停止Wireshark的抓包，不然会抓很多没用的包。然后在Wireshark顶部的过滤框里输入过滤条件，只看这次iperf3传输的包：

tcp.port == 5201

输入后按回车，Wireshark就只会显示这次传输的TCP包了，方便咱们分析。

四、计算实际吞吐量

实际吞吐量的计算逻辑很简单：就是这段时间内，客户端总共发了多少数据，除以传输的时间。这里咱们用Wireshark来统计，步骤如下：

4.1 统计总传输字节数

在Wireshark的顶部菜单里，点“统计”，然后选“协议分层”，会弹出一个窗口，里面有各种协议的统计信息。找到“TCP”这一行，看“字节数”这一列，这个就是这次传输总共发的TCP层的字节数。比如咱们这次测出来是12345678字节。

4.2 计算实际吞吐量

实际吞吐量的单位通常是Mbps（兆比特每秒），所以要把字节转成比特（1字节=8比特），再除以时间（这次测试是10秒）。公式是：实际吞吐量（Mbps）= 总字节数 × 8 ÷ 时间（秒）÷ 1024 ÷ 1024。 比如总字节数是12345678，时间10秒，代入公式：12345678 × 8 ÷ 10 ÷ 1024 ÷ 1024 ≈ 9.4 Mbps，这个就是这次测试的实际吞吐量。

五、分析TCP窗口缩放

TCP窗口是控制发送端一次能发多少数据的机制，窗口越大，能一次发的越多，速度就越快。TCP窗口缩放是因为早期的TCP窗口最大只有65535字节，现在网络带宽大了，不够用，所以加了缩放因子，把窗口放大。

5.1 找TCP窗口的初始值和缩放因子

咱们先看抓包里的握手包，TCP的三次握手里，前两个包会带窗口信息。在Wireshark的包列表里，找到第一次发的TCP包（就是SYN包），点进去看“TCP”部分，会看到“Window size value”（窗口值）和“Window scale”（缩放因子）。 比如咱们测的SYN包里，Window size value是65535，Window scale是7，那初始的窗口就是65535 × 2^7 = 65535 × 128 = 8388480字节，也就是大概8MB。

5.2 看传输过程中的实际窗口

在传输过程中，接收端会告诉发送端自己的接收窗口有多大，发送端不能超过这个窗口发数据。在Wireshark里，随便找一个接收端发的ACK包（就是服务端发给客户端的包），看“TCP”部分的“Window size value”，再乘以缩放因子，就是当前的实际窗口。 比如传输过程中，接收端的Window size value是16384，缩放因子还是7，那实际窗口就是16384 × 128 = 2097152字节，也就是2MB。

5.3 计算理论吞吐量

TCP的理论吞吐量有个公式，叫带宽延迟乘积（BDP），公式是：BDP（字节）= 带宽（bps）× 延迟（秒）÷ 8。 比如咱们的网络带宽是100Mbps（100×1024×1024 bps），延迟是10毫秒（0.01秒），那BDP就是（100×1024×1024）× 0.01 ÷ 8 = 131072字节，也就是128KB。 理论上，只要窗口大于等于BDP，就能跑满带宽。但如果实际窗口远小于BDP，那速度就上不去。比如咱们测的实际窗口是2MB，远大于BDP的128KB，那速度上不去就不是窗口的问题，可能是别的原因，比如丢包、路由瓶颈。

六、对比偏差和定位问题

把实际吞吐量和理论吞吐量对比，就能找到问题所在。比如理论吞吐量是100Mbps，实际只有9.4Mbps，偏差很大，那就要分情况分析：

  1. 如果实际窗口远小于BDP：那就是接收端的窗口太小，比如接收端的内存不够，或者系统设置的窗口上限太低。
  2. 如果实际窗口大于等于BDP：那就是网络有丢包，或者路由有瓶颈，或者服务端的处理速度不够。 比如咱们测的实际窗口是2MB，BDP是128KB，窗口足够，那速度上不去的原因可能是中间的路由器处理能力不够，或者有丢包。这时候可以在Wireshark里看有没有重传的包，过滤条件是“tcp.analysis.retransmission”，如果有很多重传，那就是丢包导致的。

七、应用场景、优缺点和注意事项

7.1 应用场景

这个测试方法适合很多场景：比如云服务商给客户做专线验收，要证明实际速度和标称速度一致；比如开发视频传输系统，要优化传输速度，找到瓶颈；比如排查企业内部网络慢的问题，定位是客户端、服务端还是中间网络的问题；比如测试新的路由设备的性能，看能不能达到标称的吞吐量。

7.2 技术优缺点

优点很明显：首先是工具都是免费的，不用花钱买专业设备；其次是分析过程很透明，能看到每一个包的细节，定位问题很准确；第三是操作简单，只要会用Wireshark和iperf3，就能完成测试。 缺点也有：首先是测试过程会占用网络带宽，不能在业务高峰期测，不然会影响正常业务；其次是分析过程需要一定的网络知识，虽然咱们尽量讲得通俗，但还是得理解TCP的基本逻辑；第三是测试结果受很多因素影响，比如测试时的网络负载、机器的CPU占用，所以得多次测试取平均值。

7.3 注意事项

第一，测试的时候要保证两台机器的CPU、内存都足够，不能跑满，不然会影响测试结果；第二，测试时间不能太短，比如只测1秒，结果会很不准，最好测10-30秒；第三，要多次测试，比如测3次，取平均的吞吐量，排除偶然因素；第四，测试的时候要关闭两台机器上的其他网络程序，比如浏览器、视频软件，不然会占用带宽；第五，Wireshark抓包的时候，要确保网卡的抓包性能足够，不会丢包，不然统计的字节数会不准。

八、文章总结

这次咱们讲了怎么用Wireshark和iperf3来测实际吞吐量和TCP窗口缩放，对比理论值和实际值的偏差，定位网络问题。整个过程从环境准备到测试步骤，再到分析计算，都是很实用的方法，不管是刚入门的网络开发新手，还是有经验的工程师，都能用来排查问题。 其实网络优化的核心就是找到瓶颈，而实际吞吐量和TCP窗口缩放就是两个最核心的指标，只要掌握了这个方法，就能快速定位大部分网络慢的问题，不用再盲目排查，节省很多时间。