十一月的机房，冷气开得很足，我盯着手里的测速报告，有点哭笑不得——千兆专线，文件传输顶死活只有 350Mbps。这是典型的 TCP 性能上不去，不是带宽不够。做这一行久了你会发现，网络不通只是低级故障，网络"不流畅"才是真正让人头秃的难题。今天想把我在 TCP 性能测试与问题分析上的一些进阶经验和心得梳理出来。无论你是运维、网络工程师还是刚接触性能调优的开发者，搞清楚这一整套流程，绝对能少走不少弯路。
这篇文章不谈基础概念，直接从"怎么测、测什么、结果怎么分析、问题怎么定位"展开，适合有一定 TCP 基础、正在被性能问题折磨的同行。我把过去几年在实测中踩过的坑、验证过的方法都放进来了，尽量说人话，尽量给可以直接落地的方案。
1. TCP性能测试的整体思路与设计拆解
1.1 先搞清楚你到底要验证什么
TCP 性能测试如果上来就 iPerf，那就是耍流氓。见过太多人直接把吞吐量数字拉出来交差，一问场景就傻眼。事实上，TCP 性能测试要回答的问题通常分为三类：
第一类是链路能力验证。比如你新拉了一条专线，或者更换了核心交换机，需要确认物理链路和中间设备到底能不能跑满理论带宽。这种测试最看重极限吞吐量和多流并发下的稳定性，因为单流 TCP 很容易受限于单核 CPU 或单队列网卡，多流才能压出设备的真实水平。
第二类是应用层性能评估。比如某个业务系统总是传输大文件很慢、视频流卡顿，这时候你要验证的是特定传输模式下的有效速率，包括网络吞吐、延迟、重传率、连接建立耗时等综合指标。这类场景不能只看带宽，必须结合业务特征去模拟流量，否则测出来的数据没有任何参考价值。
第三类是调优效果验证。比如修改了内核缓冲区参数，或者换了一种拥塞控制算法，你需要用同一个基线流程去对比前后差异。这种测试最关键的就是控制变量，任何外部环境的波动都会让对比结果失真。
明确目标之后，才能决定用什么工具、压多长时间、采集哪些数据。测试不是目的，定位问题和验证结论才是。
1.2 测试拓扑与方案选型的核心考量
有了目标，下一步是设计测试拓扑。这里有一个很容易踩的坑：直接把客户端和服务端放到业务网段里测，结果被防火墙策略、负载均衡设备等环节干扰，数据完全不可信。经验上讲，理想状态下的性能基线测试应该尽量绕开中间安全设备，用一对直连的测试服务器，或者至少在相同的网段内先做一轮基线。
初测拓扑建议越简单越好，直连交换机，关闭中间链路的不必要功能（比如限速策略、QoS队列），两边都使用高性能服务器。等确认了链路本身没有瓶颈，再逐步加入防火墙、负载均衡等设备，对比同一套测试脚本下数据的衰减程度，这样就能精准定位是哪一层设备拖慢了性能。
方案选型还要考虑传输方向。TCP 是双向的，但很多业务场景读多写少或者反之，你需要分别做上行、下行、双向三种模式的测试。iPerf 的默认模式是单向，双向测试需要加 -d 或 --bidir 参数，这在验证交互类业务时很重要——有些设备的瓶颈只有在双向流量同时跑的时候才会暴露。
工具选型方面，长连接大流量场景首选 iPerf3，短连接高并发场景推荐用 hping3 或自研的并发连接脚本，抓包用 tcpdump 配合 Wireshark 分析。不要指望一个工具解决所有问题，不同测试形态对应不同的工具组合，这是进阶和初级之间一个明显的分水岭。
2. 核心参数与原理：TCP性能是由什么决定的
2.1 带宽延迟积：看懂 TCP 窗口的极限
要理解 TCP 为什么跑不满带宽，就必须先理解带宽延迟积（BDP）。这个概念用一句大白话讲：TCP 是确认制协议，发出去的包必须等收到 ACK 才能继续发下一个，如果你在等待 ACK 的这段往返时间里，还没把管道填满，带宽就浪费了。
BDP 的计算公式很简单：带宽（bit/s）× RTT（秒）= 需要填充的字节数。举个例子，千兆网络（1Gbps）下，RTT 是 10ms，那么 BDP = 1Gbps × 0.01s = 10Mbit ≈ 1.25MB。也就是说，TCP 的发送窗口至少要达到 1.25MB，才能让链路在每一个 RTT 内都保持满载。
如果窗口设置为默认的 64KB，那么单流的理论最大吞吐就只有 64KB / 10ms ≈ 51.2Mbps。现实中很多人遇到单流传输跑不满带宽，第一反应是怀疑线路质量，但实际上只要算一下 BDP，就发现是窗口根本不够大。
这里有个容易忽略的细节：窗口大小是接收端通告的，发送端受限于 min(自身拥塞窗口，接收端通告窗口)。所以测速的时候两端都得检查，尤其是接收端的 rmem 和 tcp_adv_win_scale 等参数。我曾经只调了发送端的缓冲区，测出来一点变化都没有，调了半天才发现瓶颈在接收端，白白折腾了几个晚上。
2.2 拥塞控制算法：同一根线，不同算法的差异
拥塞控制算法决定了 TCP 在遇到丢包和延迟时的行为方式。传统上 Linux 默认是 Cubic，它在高带宽长距离链路上表现不错，但对轻微丢包非常敏感，一丢包就大幅降窗，恢复速度又慢。后来 Google 提出的 BBR 算法改变了思路，不再以丢包为抓手，而是靠实时测量带宽和延迟来主动控制发送速率，在高丢包高延迟链路上往往能带来好几倍的提升。
实测对比过一条跨国链路，RTT 稳定在 80ms 上下，丢包率约 0.5%。Cubic 单流跑出来只有 25Mbps，换成 BBR 之后直接干到了 220Mbps，差距是数量级的。但是 BBR 也不是银弹，它在深缓冲区网络里可能挤占传统算法的带宽，聚合场景下对公平性不好，所以生产环境用不用 BBR 要谨慎评估，不能只看单流测试数据。
查看和切换拥塞控制算法用这个命令：
# 查看当前算法 sysctl net.ipv4.tcp_congestion_control # 查看可用的算法列表 sysctl net.ipv4.tcp_available_congestion_control # 切换到 BBR（内核 4.9+ 支持） sysctl -w net.ipv4.tcp_congestion_control=bbr调测时建议在发送端和接收端都确认使用的算法一致，有的中间设备会改写 TCP 选项，导致实际生效的算法和预期不同。
2.3 内核缓冲区与队列参数，这些默认值往往是最佳起点
前面说 BDP 决定窗口容量，内核缓冲区的设置则是窗口的物理上限。Linux 下与 TCP 缓冲区直接相关的参数有 net.ipv4.tcp_rmem 和 net.ipv4.tcp_wmem，它们都是三个值：最小值、默认值、最大值，单位是字节。
# 查看当前缓冲区设置 sysctl net.ipv4.tcp_rmem sysctl net.ipv4.tcp_wmem # 调整接收缓冲区上限，单位：字节 sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216' sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216'这里不建议直接把最小值也调大，因为每个连接都会占用至少最小值的物理内存，高并发场景下内存配额会迅速被吃光。实际操作中我的习惯是：保持最小值不变，只调大最大值，让 TCP 窗口在实际传输时根据 BDP 动态增长。如果是短连接频繁的业务，还要注意 net.core.netdev_max_backlog 和 net.core.somaxconn，这两个参数影响的是接收队列和连接队列的长度，队列溢出会直接表现为丢包和连接失败，测性能时同样不能忽略。
2.4 硬件与中断绑定，压测时 CPU 成了隐藏瓶颈
TCP 性能测试遇到瓶颈，很多人第一反应查网络、查丢包，却忽略了服务器 CPU。现代网卡大多支持多队列（RSS），但默认情况下中断可能都打在同一颗 CPU 上，导致单核跑满、其余核心闲置，整体吞吐上不去。这是我在测试中踩过最典型的坑之一：网卡明明是 25G，单流压测只能跑 4Gbps，一看 CPU 占用，软中断那一栏已经 100% 卡死。
排查和解决办法分两步：
先用mpstat -P ALL 1看每个核心的中断和软中断占比，确认是否单核集中。如果是，再查网卡的队列总数和 RSS 配置：
# 查看网卡队列数 ethtool -l eth0 # 查看 RSS 哈希配置 ethtool -x eth0 # 设置多队列 ethtool -L eth0 combined 8做完这个操作之后，最直接的办法是用irqbalance自动平衡中断，或者手动把多队列的中断绑定到不同 CPU 核上。实测在双路服务器上，把 8 个队列绑到 8 颗不同的物理核上，单流吞吐直接翻倍，多流场景的提升更明显。所以测 TCP 性能的时候，一定不要把眼光局限在网络层——整个数据链路涉及的所有环节，都可能成为瓶颈。
3. 实操：一整套完整的 TCP 性能测试流程
3.1 测试环境的准备清单
这一步决定测试的可靠性，我说几个必须反复确认的点：
第一，时间同步。测 TCP 性能必须要分析抓包结果，两端时钟不同步，RTT 计算完全是错的。测试前先ntpdate或者chronyc makestep强制同步一次，误差控制在毫秒级以内。
第二，防火墙和中间设备。测试端口要在两端防火墙放通，最好也确认中间链路的 MTU 一致。有一次测试发现 MSS 异常小，排查半天发现是中间某台设备的 MTU 设置错误，导致所有大包被分片，性能受到严重影响。
第三，工具版本统一。iPerf3 的版本差异会导致参数行为不一样，两端版本不一致时，结果可靠性难以保证。我自己习惯固定用同一个版本（比如 3.9 或 3.12），避免因应用层处理差异影响最终数据。
第四，启动顺序。先启动服务端，再启动客户端，这个顺序看似无关紧要，但某些工具在客户端连不上时的报错会误导判断方向。另外，如果服务端是通过nohup后台跑的，一定要确认日志里没有报"bind failed"之类的错误，别让一个小疏漏浪费整个测试周期。
3.2 分场景的测试命令与参数解读
场景一：纯链路吞吐验证，这是最常用的裸测场景。先用 iPerf3 跑单流基线：
# 服务端 iperf3 -s -i 1 -p 5201 # 客户端，测试 60 秒，每 1 秒输出一次间隔数据 iperf3 -c 192.168.10.20 -p 5201 -t 60 -i 1单流结果代表"在没有多流叠加情况下单条 TCP 连接能跑多快"，这是很多应用的实际情况。但如果你想验证链路本身的能力上限，就得开多流：
# 8 条并发流，压满 60 秒 iperf3 -c 192.168.10.20 -p 5201 -t 60 -i 1 -P 8注意一点，-P 8 的并发流会让 iPerf3 输出一个汇总结果和一个每条流的细分列表。真正的链路承载能力看汇总值，而单流均匀程度则能反映负载均衡策略是否生效。如果某一条流明显比其它流慢，就要怀疑交换机哈希不均或者服务器网卡队列绑定不平衡了。
场景二：应用模拟测试，这在业务性能评估中更贴近真实情况。比如你的业务是传输 10MB 左右的文件块，中途有断点续传逻辑，那单纯 iPerf 大流量灌就不够。可以用scp传输一个实际大小的文件，同时用sar -n DEV实时观察流量曲线，配合 tcpdump 抓包看应用层的连接复用情况。
还有一种常用手段是设置固定窗口来限制发送速率，模拟特定网络条件。比如用 iPerf3 的 -w 参数指定窗口：
iperf3 -c 192.168.10.20 -p 5201 -t 60 -i 1 -w 512K通过这个对比就能直观看到窗口变小后吞吐量怎么变化，这个数据和 BDP 计算值对应上了，说明问题定位就八九不离十了。
3.3 结果解读的正确姿势
iPerf3 的输出结果看起来简单，其实每个数字都值得琢磨。我举一个典型的实测例子：
[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 1.08 GBytes 155 Mbits/sec 184 sender [ 5] 0.00-60.00 sec 1.08 GBytes 154 Mbits/sec 0 receiver很多人只看了 Bitrate 是 155Mbps，就开始抱怨线路问题了。但注意这里的Retr（重传）列有 184 次，这是一个非常重要的信号——如果有大量重传，说明链路上存在拥塞或丢包，这个 155Mbps 已经是在不断恢复中的结果，而链路的真实能力可能远高于这个数。
正确解读分三步走：
第一步，先看重传率。重传次数除以总发包数（统计工具里可以看到），超过 0.1% 就要警惕。第二步，看单流和多流的差异。如果单流 155Mbps、多流 800Mbps，说明单流受到了窗口或 CPU 限制；如果多流照样上不去，链路本身可能就有硬瓶颈。第三步，结合中间设备的 CPU 和接口错误计数判断——交换机端口有没有 CRC 错误、光模块光功率是否在正常范围，这些物理层的检查往往能提供最直接的答案。
另外，iPerf3 的-O参数可以跳过前几秒的数据，这个参数对于需要规避慢启动阶段干扰的场景很有用：
iperf3 -c 192.168.10.20 -p 5201 -t 60 -i 1 -O 3意思是跳过前 3 秒的输出，从第 4 秒开始统计，这样每个 RTT 窗口的比例更真实，慢启动毛刺不会影响最终平均值。
3.4 抓包分析，把数字落到证据上
性能测试只是第一步，真正定位问题要靠抓包。tcpdump 是我每天都要用的工具：
# 抓取指定端口的 TCP 流量，并写入文件供 Wireshark 分析 tcpdump -i eth0 -nn -s 100 -w /tmp/tcp_test.pcap 'tcp port 5201'抓包文件出来之后，用 Wireshark 打开，我会重点关注这几个地方：
第一次握手。看 SYN 包的 Window 字段，这代表了接收端初始通告窗口大小。如果这里显示只有 29200 之类的默认小值，说明接收端没有开启窗口缩放（Window Scaling），或者内核参数没有调大，后面就算发送端有再大的窗口也白搭。
重传轨迹。在 Wireshark 里用 分析->专家信息 看 TCP 重传和 DUP ACK。如果重传分布均匀，往往是拥塞造成；如果集中在某个时间点，可能是中间设备发生了路由切换，或者对端应用发生了卡顿。用tcp.analysis.retransmission过滤能快速定位。
RTT 变化。在 Wireshark 的 IO 图表里，以时间轴显示 RTT。如果 RTT 是锯齿状波动，说明缓冲队列在反复堆积和释放，这种场景下调整接收端缓冲区意义不大，需要从拥塞控制和丢包方向入手。
抓包分析做多了，你会形成一种直觉：看三次握手的窗口和选项，就知道这个系统有没有调过；看重传分布，就能猜出大概率的瓶颈层在哪。这种直觉没法从文档里学到，只能靠一次一次抓包喂出来。
4. 常见问题与排查技巧实录
4.1 吞吐量上不去，如何逐层定位
这是被问得最多的问题，没有之一。通常我的排查顺序是固定的，每一步都有对应的验证数据，不凭感觉：
第一层，确认时钟和接口。检查两端的网络接口速率和双工模式，ethtool eth0看 Speed 和 Duplex 是否正常协商到千兆或万兆。我曾经碰到过一个光模块接触不良导致接口自动降到百兆的情况，这类低级错误在网络性能问题中的占比远比想象中高。
第二层，做链路层打流验证。用 iPerf3 UDP 模式或者专门的打流工具（如iperf -u）测试原始链路能力，UDP 没有拥塞控制，如果 UDP 能跑满带宽而 TCP 不行，说明链路本身是好的，问题出在 TCP 协议栈或应用层。反过来如果 UDP 也跑不满，那就是物理链路或设备转发的硬瓶颈。
# UDP 模式测试，带宽 1000Mbps，持续 30 秒 iperf3 -c 192.168.10.20 -u -b 1000M -t 30第三层，检查 TCP 协议栈状态。用ss -s查看当前系统的 TCP 连接统计，注意重传和丢包计数。再用netstat -s | grep -i retrans查看累计重传。抖动发生在哪一跳，可以通过mtr逐跳观察：
mtr -rw 192.168.10.20看每一跳的丢包率和延迟，如果某个中间节点的丢包率持续高于前后节点，瓶颈基本锁定在这一跳。
第四层，排除应用层因素。如果 iPerf 跑得好而业务流量跑不满，问题极大概率出在业务代码或中间件上，比如某些框架默认限制连接数、应用层数据处理速度慢、磁盘写性能跟不上等。拿top看 CPU、iostat看磁盘、pidstat看具体进程，确定瓶颈不在 I/O 和 CPU 之后再回来看网络。
4.2 重传率居高不下的排查方向
重传率高不等于线路差，这一点新手最容易误判。我见过一个案例，某应用跨机房同步数据，重传率高达 3%，大家一开始怀疑链路。后来排查发现是交换机上配置了流量限速策略，突发流量全被标记为丢弃，TCP 被迫不断重传，应用吞吐极低。去掉限速策略后，重传率立刻掉到 0.1% 以下，链路本身完全没毛病。
重传问题排查的核心思路是找出丢包发生的具体位置，推荐按这个顺序走：
先看接收端的丢包。运行netstat -s | grep -i 'drop\|overflow'看 receive buffer errors 和 packet receive errors。如果 kernel drop 比例高，需要调大tcp_rmem或net.core.rmem_max，同时确认应用读取数据的速度是否足够快，否则缓冲区再大也只是延迟了丢包的时间。
再看中间设备的丢包。登录交换机查端口 counters，确认 Input Errors、Output Errors、Discards 等计数是否持续增长。很多设备丢包不是因为链路质量，而是因为 buffer 不足或 QoS 队列配置不合理。
最后看发送端是否过度发送。用抓包观察，如果发送端持续以超过链路容量的速率发送，必然导致中间节点队列溢出，这时候要调拥塞控制算法，或在应用层做流量整形。
4.3 高延迟与抖动问题的不同处理思路
延迟和抖动，经常被混为一谈，但处理思路完全不同。
延迟高（RTT 大）通常意味着物理距离远或路径绕路。BDP 变大之后需要更大的窗口和合适的拥塞算法。我之前处理过一个跨海链路的案例，RTT 稳定在 150ms，原始性能只有 9Mbps，合理调大窗口后直接跳到 200Mbps 以上。这类问题核心是算好 BDP，设置合理的缓冲区，必要时启用 BBR。
抖动大（RTT 忽高忽低）则更多指向队列拥塞或链路干扰。典型的特征是 Wireshark 里 RTT 呈周期性波动，伴随重传集中出现。遇到这种情况，先检查是否有突发流量占满带宽，用iftop实时观察各连接的速率；再检查交换机端口的 discard 计数，确认缓冲是否经常溢出。如果是链路干扰造成的抖动，通常伴随 CRC 错误或光模块告警，那就要联系链路供应商处理物理线路。
实测中有个技巧：用 ping 的间隔和包大小模拟 TCP 的行为。比如ping -s 1400 -i 0.01发 100 个包，看延迟分布和丢包率，如果延迟抖动大，那么 TCP 传输一定会受影响；如果 ping 一切正常但 TCP 抖动厉害，重点就要放在系统层或协议栈内部。
4.4 常见问题速查表
| 现象 | 直接原因 | 排查命令/手段 | 处理方向 |
|---|---|---|---|
| 单流吞吐极低，多流正常 | 窗口太小或单核 CPU 瓶颈 | 计算 BDP；mpstat -P ALL 1 | 调大tcp_rmem/wmem；网卡多队列绑核 |
| 单流、多流都跑不满 | 物理链路或中间设备瓶颈 | UDP 模式打流；交换机端口计数 | 检查光模块、光纤、限速策略 |
| 重传率持续超高 | 中间节点丢包或缓冲不足 | tcpdump 抓包定位丢包位置 | 调整 QoS、加大中间设备 buffer |
| RTT 正常但吞吐上不去 | 应用层读写速度慢 | iostat、top、pidstat | 优化应用 IO 或并发模型 |
| 高延迟链路性能差 | BDP 大但窗口未调 | 计算 BDP，对比当前窗口 | 调大缓冲区或启用 BBR |
| RTT 锯齿状波动 | 缓冲队列反复堆积 | Wireshark IO 图表看 RTT | 调整拥塞控制或流量整形 |
| CPU 软中断 100% 但吞吐低 | 网卡中断集中在一核 | mpstat、ethtool -l | 开多队列、中断绑核 |
| 抓包看到大量 DUP ACK | 乱序或中间设备缓存问题 | Wireshark 过滤tcp.analysis.duplicate_ac | 检查交换机哈希策略和链路负载 |
这个速查表是我自己整理的，不一定覆盖所有场景，但覆盖了八成以上的常规问题，遇到类似情况可以按图索骥，高效不少。
4.5 一个容易忽略的细节：iperf 版本的坑
iPerf3 服务端和客户端的收发方向在输出里是相反的，很多人第一次看结果会搞混。iPerf3 3.1 版本之后-R参数可以反转方向测试，但要注意，反转测试的服务端报告和客户端的实际体验不一定一致，需要同时看两端输出。
另外，iPerf3 单线程测试的时候，务必确认两边机器 CPU 是性能模式而不是省电模式。有次在一台笔记本上做测试，功率限制导致 CPU 自动降频，单流带宽直接打了五折，怎么调参数都没用，最后发现是电源策略问题。
我在测试机上统一都用
cpupower frequency-set -g performance把 CPU 锁在性能模式，避免这类硬件层面的干扰。这个细节虽然简单，但能节省大量排查时间。
5. 几个可以抄作业的调优组合
5.1 常规高带宽长延迟链路的参数建议
针对 RTT 在 20~100ms 的链路，我常用的参数组合如下（以 Linux 为例）：
# TCP 缓冲区 sysctl -w net.ipv4.tcp_rmem='4096 87380 33554432' sysctl -w net.ipv4.tcp_wmem='4096 65536 33554432' sysctl -w net.core.rmem_max=33554432 sysctl -w net.core.wmem_max=33554432 # 启用窗口缩放和选择性确认 sysctl -w net.ipv4.tcp_window_scaling=1 sysctl -w net.ipv4.tcp_sack=1 # 提高队列长度 sysctl -w net.core.netdev_max_backlog=50000 sysctl -w net.core.somaxconn=4096注意，双端都要设置，窗口缩放是接收端通告的，发送端光调没用。
5.2 BBR 启用与回退的注意事项
BBR 在某些场景下效果拔群，但在生产环境切换之前一定要做灰度验证。操作上最好先在一台服务器上开启，观察一段时间（至少一个业务周期），对比同一时段的吞吐、重传率、应用响应时间三个指标。
回退也很简单：
sysctl -w net.ipv4.tcp_congestion_control=cubic如果切换 BBR 后发现传统 Cubic 流量被压制（比如同链路其它业务变慢），说明公平性存在问题，不建议全局启用，可以只针对特定目标 IP 或端口使用ip route的congctl属性做精细化路由策略。这个操作比较进阶，但实测里最实用：
# 只对特定目标走 BBR ip route add 10.10.20.0/24 via 192.168.10.1 congctl bbr不过注意，这个命令需要内核和 iproute2 支持，具体版本要求可以查一下各自环境的文档。
5.3 硬件卸载功能与测试结果的干扰
现代网卡有各种硬件卸载功能（TSO、GSO、GRO、LRO），它们的作用是把 TCP 分段和重组工作交给网卡处理，显著降低 CPU 负载。但硬件卸载在测试和排障时也会带来干扰：tcpdump 抓包时看到的大包其实是网卡卸载前的聚合效果，不代表线上的真实报文大小，会造成分析误判。
所以抓包的时候，我通常会先关掉卸载功能再抓，这样拿到的是真实线缆上传输的包：
# 关闭 TSO/GRO/GSO（以 eth0 为例） ethtool -K eth0 tso off gro off gso off抓完包再重新打开，避免影响线上性能。做了这么多次调试之后我的体会是：硬件卸载功能是默认优先级很高的"嫌疑对象"，但实际导致的性能问题并不太多，最大的影响在于它会让你的抓包数据失真，进而误导你判断问题的方向。这个坑特别隐蔽，建议每个做 TCP 性能分析的同行都注意一下。
写在最后
TCP 性能测试和问题分析这事，做久了你会越来越觉得，最大的难点不是工具不够多、参数不够玄，而是如何把现象、数据和协议行为串成一条线。带宽上不去，到底是链路问题还是软件配置问题？重传高，到底是中间丢包还是发送过快？这些结论不能靠猜，只能靠一套可靠复现的测试流程和层层递进的排查方法来验证。
我自己在实际操作中最深的体会是：一次测试只能反映一个瞬间的状态，不要指望单次数据就能下结论。多跑几轮，反复抓包，对比不同参数下的变化趋势，才能真正理解这条链路的脾性。每一次排查都是在积累经验，踩过的坑多了，后面就越来越得心应手。
希望这篇内容能给你一些参考。如果你在测试中遇到什么有意思的现象，也欢迎拿出来一起讨论——毕竟 TCP 这个老家伙，水深得很，谁都不敢说自己完全摸透了。
