Wireshark 实战｜TCP 重传、乱序、SACK、BBR 拥塞控制抓包分析

关注

原创 2026-10-10 09:49:38 270 阅读 AI 写同款· GEO 优化 ›

Security ❀ TCP异常报文详解 TCP协议中seq和ack seq的联系：id=4的http请求报文由客户端发向服务器，其TCP协议内seq（由wireshark定义）=1，真实seq=2387613954（十六进制为0x8E501902），ack（由wireshark定义）=1，真实ack=3344080265（十六进制为0xC7529D89），客户端发送的下一个报文的seq=135（len+seq 134+1=135）；阅读详情

Wireshark 实战｜TCP 重传、乱序、SACK、BBR 拥塞控制抓包分析

免责声明：本文所有抓包、实验操作仅用于授权内网、测试环境学习。所有 TCP 原理、网络排障知识，用于运维、网络工程师、安全工程师性能排查。请勿对公共网络、业务生产环境进行未经授权抓包分析。

前言

TCP 是互联网最核心的传输层协议，可靠性、流量控制、拥塞控制是 TCP 三大基石。在日常运维、业务性能排查、压测、网络故障定位中，Wireshark是分析 TCP 行为最强大的工具。很多同学抓包只会看 SYN、ACK，一旦遇到业务卡顿、接口超时、吞吐量上不去，面对满屏 TCP 专家提示：[TCP Retransmission]、[TCP Out-Of-Order]、[TCP Dup ACK]、SACK选项，就会一头雾水。

很多人存在误区：只要抓包看到 TCP 重传，就直接判定网络丢包；看到乱序就认为链路质量差。实际上伪重传、伪乱序在生产环境非常普遍，ECMP 等价路由、负载均衡、网卡 TSO、抓包位置不当，都会造成 Wireshark 误标记。而 SACK 选择性确认、BBR 拥塞控制，是现代 Linux 网络高性能传输的核心，和传统 CUBIC/Reno 基于丢包的拥塞控制完全是两套思路。

本文从 TCP 序列号基础讲起，依次讲解TCP 重传（超时重传、快速重传、虚假重传 Spurious Retransmission）、TCP 乱序（真实乱序、伪乱序）、SACK 与 D-SACK 选择性确认原理 + 抓包解读、BBR 拥塞控制四大阶段（Startup、Drain、ProbeBW、ProbeRTT），配套大量 Wireshark 过滤表达式、实战案例、故障排查思路，同时对比 BBR 和 CUBIC 差异，讲解如何从抓包报文识别 BBR 行为。

全文偏向实战，每一个知识点都附带抓包报文特征、Wireshark 专家信息识别、过滤语法，适合运维、云原生网络、网络安全、CISP 备考、计算机网络学习者。

一、前置基础：TCP 序列号、ACK、Wireshark TCP 专家提示

想要看懂 TCP 重传、乱序、SACK，必须吃透 TCP 序列号与确认号机制，这是所有分析的根基。

1.1 Sequence Number 序列号 & Acknowledgment Number 确认号

TCP 每一个发送报文段，都会携带 Seq 序列号，标记本段数据第一个字节编号。接收方收到连续完整数据，回复 ACK 确认号，告诉发送方：我已经收到 ACK 编号之前全部字节，下一个期望接收字节是 ACK 号。

举个例子：
发送方发送 Seq=100，Len=1000，代表数据字节范围：100 ~ 1099。
接收方正常收到，回复 ACK=1100。含义：1100 之前所有字节全部收到，下一个等待 1100。

关键点：ACK 确认的是连续、无缺口的数据。在没有 SACK 的老式 TCP 中，如果中间某一段报文丢失，后面到达的报文哪怕完整收到，接收方依旧只能回复丢失位置的 ACK，无法告知发送方 “后面部分数据我已经收到了”。这就是 SACK 诞生的背景。

Wireshark 默认会对序列号做相对化处理，把连接初始 ISN（初始序列号）转为 0，方便阅读。你可以在 编辑 → 首选项 → 协议 → TCP，取消勾选相对序列号，查看原始真实序列号。

1.2 Wireshark TCP 专家信息（Expert Info）

Wireshark 内置 TCP 解析引擎，自动分析报文时序，生成专家标记，也就是 Info 列里中括号里的提示，这是我们分析 TCP 异常的核心入口。

标记	含义	过滤表达式
`[TCP Retransmission]`	超时重传	`tcp.analysis.retransmission`
`[TCP Fast Retransmission]`	快速重传	`tcp.analysis.fast_retransmission`
`[TCP Spurious Retransmission]`	虚假重传（伪重传）	`tcp.analysis.spurious_retransmission`
`[TCP Out-Of-Order]`	报文乱序到达	`tcp.analysis.out_of_order`
`[TCP Dup ACK]`	重复 ACK	`tcp.analysis.duplicate_ack`
`[TCP SACK]`	选择性确认	`tcp.options.sack`
`[TCP D-SACK]`	重复 SACK	`tcp.options.dsack`

重要提醒：Wireshark 的专家分析是基于抓包文件的推测，不是绝对事实。抓包位置会严重影响分析结果。比如在发送端抓包，不会看到报文在传输途中丢失；在接收端抓包，才能看到报文抵达情况。如果在中间交换机镜像抓包，会出现大量伪乱序。

1.3 TCP RTO 重传超时时间

RTO（Retransmission Timeout），发送方维护的超时计时器。发送报文后启动 RTO 定时器，如果定时器到期，还没有收到对应 ACK，发送方认为报文丢失，触发超时重传。
RTO 不是固定值，根据 RTT 往返时延动态计算，RTO = RTT_Smooth + 4*RTT_Dev。RTO 会指数退避，第一次超时 RTO=1s，第二次 3s，第三次 7s，以此类推。超时重传代价很大，一旦触发超时重传，传统拥塞算法会把拥塞窗口 cwnd 直接降到 1，重新慢启动，吞吐量暴跌。

二、TCP 重传完整分类：超时重传、快速重传、虚假重传抓包实战

TCP 重传，是 TCP 可靠性的核心机制：发送方没有收到 ACK，重新发送报文。很多运维只知道重传 = 丢包，但是重传分三类，每一类的成因、抓包特征、故障定位方向完全不同。

2.1 超时重传 [TCP Retransmission]

原理

发送方发送报文，启动 RTO 计时器；RTO 时间耗尽，依旧没有收到 ACK。发送方判定报文丢失，执行重传。超时重传由时间驱动。
触发超时重传的原因有三类：

数据包在网络链路丢失；
数据包到达接收端，但是接收端回复的 ACK 报文丢在回程链路；
接收端收到数据包，但是应用层迟迟不读取 Socket 缓冲区，TCP 接收窗口耗尽，无法回复新 ACK。

Wireshark 抓包特征

Info 列标记 [TCP Retransmission]；
原始报文和重传报文之间时间间隔≈RTO；
重传报文 Seq、载荷内容和原始报文完全一致，IP ID 不同；
传统 CUBIC 协议触发超时重传，cwnd 会直接收缩，进入慢启动。

过滤表达式：

tcp.analysis.retransmission

实战案例：跨机房访问超时重传

场景：A 机房客户端访问 B 机房服务端，中间专线链路偶尔丢包。客户端发送 Seq=100 报文，RTO 超时，没有收到 ACK，客户端重传该报文。
抓包现象：原始报文发出之后，间隔约 1 秒，出现[TCP Retransmission]报文。后续收到 ACK，业务恢复。

排查思路：超时重传代表链路存在真实丢包，需要排查链路、交换机、防火墙、运营商链路质量。

2.2 快速重传 [TCP Fast Retransmission]

为了规避超时重传巨大延迟，TCP 设计快速重传，由 ACK 事件驱动，不需要等待 RTO 超时。
原理：接收方收到报文缺口（某一段报文丢失，后续报文提前到达），接收方持续回复同一个 ACK（重复 ACK Dup ACK）。当发送方收到3 个重复 ACK，直接判定报文丢失，立刻重传丢失报文，不需要等待 RTO 超时。收到 3 个 Dup ACK，进入快速恢复阶段。

经典阈值：3 个重复 ACK，也就是 RFC 规定的阈值。为什么是 3 个？网络存在正常报文乱序，少量重复 ACK 可能只是报文到达顺序错乱，不是真丢包，3 次作为阈值，区分真实丢包和正常乱序。

Wireshark 抓包特征

前面连续出现 3 条 [TCP Dup ACK]；
紧随其后报文标记 [TCP Fast Retransmission]；
重传动作几乎无等待，没有 RTO 长时间延迟；
快速重传后，传统 Reno/CUBIC 会减半拥塞窗口，而 BBR 不会因为丢包直接砍半窗口。

过滤表达式：

tcp.analysis.fast_retransmission

快速重传与超时重传对比

快速重传：收到 3 个 Dup ACK 触发，响应快，延迟低；
超时重传：RTO 计时器到期触发，延迟巨大，对业务伤害更大。

2.3 虚假重传 Spurious Retransmission [TCP Spurious Retransmission]

这是最容易踩坑的知识点。很多运维看到重传告警就判定链路丢包，结果排查半天链路无丢包，其实是虚假重传。
原理：发送方 RTO 超时，重传报文。但是实际上原始报文已经成功到达接收端，ACK 也已经在路上，只是 ACK 延迟到达。发送方误以为丢包而重传，属于不必要的重传。接收端收到重复报文，会直接丢弃，回复 ACK。Wireshark 识别这种场景，标记[TCP Spurious Retransmission]。

常见诱因：

RTO 计算偏小，RTT 抖动大，误判超时；
回程 ACK 延迟；
中间设备延迟转发报文。

重点：虚假重传不是网络丢包，链路本身没问题，只是 TCP 计时器误判。如果大量虚假重传，会浪费带宽，但是不会像真实丢包那样严重影响业务。

过滤表达式：

tcp.analysis.spurious_retransmission

2.4 重传率计算与业务评估

重传率 = 重传报文数量 / 总 TCP 报文数量。
行业经验参考：

重传率 <1%：正常，互联网链路少量随机丢包属于常态；
1%~3%：业务开始感知卡顿，视频、大文件下载出现抖动；

3%：严重问题，业务超时、接口失败，必须排查链路。

注意：区分是快速重传为主，还是超时重传为主。超时重传占比高，业务影响远大于快速重传。

三、TCP 乱序 Out-Of-Order：真实乱序、伪乱序，抓包识别与故障定位

3.1 TCP 乱序原理

TCP 发送报文顺序是 1、2、3、4。但是报文经过网络不同路径，到达接收端顺序变成 2、3、1，这种先发后到、后发先至，就是 TCP 乱序。Wireshark 检测到当前报文 Seq 号小于之前收到报文 Seq+Len，标记[TCP Out-Of-Order]。

现代网络乱序非常普遍，最常见原因：

ECMP 等价路由，多路径负载分担，不同报文走不同路由，到达时间不一致（云环境、数据中心交换机高频出现）；
链路层重传，WiFi、4G 无线链路；
负载均衡、中间设备转发延迟波动；
网卡 TSO/GSO 分段，在发送端网卡拆分报文，抓包看到乱序。

乱序的负面影响：
乱序会让接收方产生 Dup ACK。如果乱序幅度大，触发 3 个 Dup ACK，发送方误判报文丢失，触发不必要的快速重传，降低吞吐。轻微乱序（1~2 个报文错位）几乎无影响；大幅度乱序才会引发性能问题。

3.2 伪乱序（Wireshark 误报乱序）

很多时候，网络本身没有乱序，仅仅是抓包位置问题，Wireshark 错误标记 Out-Of-Order，也就是伪乱序。
常见场景：

在发送端主机抓包，网卡 TSO/GSO 大段卸载，操作系统把大块数据交给网卡，网卡硬件拆分成 TCP 分段。内核发出顺序报文，网卡硬件分段顺序发生变化，抓包看到乱序，但是报文发到网络上是有序的。
交换机端口镜像抓包，镜像报文本身存在转发延迟，镜像流的报文到达抓包机器顺序错乱，真实业务报文到达服务端是有序的。
抓包工具缓冲区不足，报文捕获顺序错乱。

排查乱序黄金法则：两端同时抓包。客户端抓包 + 服务端抓包。如果服务端抓包没有 Out-Of-Order，只有交换机镜像抓包看到乱序，那就是伪乱序，网络本身没问题。

过滤表达式：

tcp.analysis.out_of_order

3.3 乱序报文的 TCP 行为

接收方收到乱序报文，会把报文存入接收缓冲区，不会向上交给应用层。同时回复 Dup ACK，告知发送方当前期望的 Seq。

小幅度乱序：短暂 Dup ACK，报文补齐后，ACK 正常推进；
大幅度乱序：连续多个 Dup ACK，触发快速重传，发送方错误重传报文，带宽浪费。

云环境 ECMP 是乱序重灾区，很多云主机之间通信，大量 Out-Of-Order，但业务感知正常，就是典型的 ECMP 多路径乱序。

四、SACK 选择性确认与 D-SACK，抓包报文深度解析

4.1 SACK 诞生背景

传统 TCP（Reno）只确认连续数据。举例：发送 1、2、3、4 四个报文，报文 2 丢失，报文 1、3、4 成功到达接收端。
老式 TCP 接收方只能回复 ACK=2，告诉发送方期望 2 号报文。发送方只知道 2 号丢了，不知道 3、4 已经收到。重传只能重传 2 号，但是如果连续多个报文丢失，发送方不知道哪些收到哪些丢失，只能盲目重传大量报文，带宽浪费严重。

SACK（Selective Acknowledgment，选择性确认，RFC2018）解决这个痛点。SACK 允许接收方，在 TCP 头部选项字段，额外上报已经收到的非连续数据块。发送方可以精准定位丢失报文，只重传真正丢失的报文，不会重传已经收到的报文。

4.2 SACK 选项格式

SACK 分为两个选项：

SACK-Permitted：在 SYN 握手阶段协商。SYN/SYN+ACK 报文携带 SACK-Permitted 选项，表示双方支持 SACK。三次握手协商成功，连接全程启用 SACK。
SACK Block：ACK 报文携带 SACK 块。每一个 SACK 块占用 8 字节，包含左右边界：Left Edge、Right Edge，代表收到的数据块 Seq 区间。

示例：SACK 3000-5000，含义：Seq 从 3000 到 5000 这段数据，接收方已经收到，但是中间存在缺口。

Wireshark 报文详情面板，TCP Options 区域直接展示 SACK 块信息。过滤表达式：

tcp.options.sack

4.3 D-SACK（Duplicate SACK，重复 SACK RFC2883）

D-SACK 是 SACK 的扩展。接收方收到重复报文，使用 D-SACK 告诉发送方：这个报文我已经收到了，现在收到重复副本。
D-SACK 的核心价值：帮助发送方识别虚假重传。发送方收到 D-SACK，就知道刚才重传的报文是不必要的，属于 Spurious Retransmission，调整 RTO 计时器，避免后续继续误判超时。

Wireshark 识别 D-SACK，在 TCP 选项标注 D-SACK。过滤表达式：

tcp.options.dsack

4.4 SACK 抓包实战案例

场景：发送方发送 4 段报文，报文 2 丢失，报文 1、3、4 到达接收端。
接收方回复 ACK=2，同时携带 SACK 块：SACK 3000~5000。
发送方收到 ACK+SACK，明确知道：1 收到，2 丢失，3、4 已经收到。只重传报文 2，不需要重传 3、4。

结论：SACK 在丢包场景极大提升传输效率，现代 Linux、Windows 服务器默认开启 SACK。关闭 SACK，高带宽长 RTT 链路一旦丢包，吞吐量会断崖下跌。

4.5 查看 Linux 系统 SACK 开关

# 查看是否开启SACK
sysctl net.ipv4.tcp_sack
# 开启SACK
sysctl net.ipv4.tcp_sack=1
# 关闭SACK
sysctl net.ipv4.tcp_sack=0

生产环境强烈建议开启 SACK，只有老旧特殊设备兼容性场景才关闭。

五、BBR 拥塞控制原理，四大阶段与 Wireshark 抓包识别

传统 CUBIC、Reno 属于基于丢包的拥塞控制：把报文丢失当成拥塞信号，一旦检测丢包，直接大幅削减拥塞窗口 cwnd。这种机制在有随机非拥塞丢包的链路（无线、跨公网）存在巨大缺陷：链路只是随机丢包，不是队列拥塞，CUBIC 依然降低窗口，带宽利用率上不去。

BBR 全称 Bottleneck Bandwidth and Round-trip propagation time，瓶颈带宽与往返时延算法，Google 开发，属于基于模型的拥塞控制。BBR 不把丢包作为拥塞判断依据，持续测量链路的最大带宽 BtlBw和最小 RTT BtlRTT，计算 BDP 带宽时延积，以此控制发送速率和 in-flight 在途数据量。

BDP = 带宽 × 最小 RTT。BDP 代表链路管道最多容纳的数据量。BBR 目标是控制在途数据接近 BDP，填满链路管道，但是不把瓶颈队列塞满，兼顾低延迟和高带宽。

5.1 BBR 四大运行阶段

阶段 1：Startup 启动阶段

类似慢启动，快速探测瓶颈带宽。每一轮 RTT，pacing gain（发送速率增益）为 2，指数提升发送速率，持续探测带宽。当连续 RTT 测量带宽不再增长，BBR 认为到达瓶颈带宽，进入 Drain 排空阶段。
Startup 阶段特征：报文爆发式发送，cwnd 快速上涨。

阶段 2：Drain 排空阶段

Startup 阶段快速发包，已经在瓶颈设备缓存队列堆积数据包，队列变长，RTT 升高。Drain 阶段降低发送速率，排空瓶颈队列，把队列中的数据全部送走，重新测量最小 RTT。队列排空完成，进入稳态 ProbeBW。

阶段 3：ProbeBW 探测带宽（稳态，连接大部分时间处于这个阶段）

稳态循环，周期性探测链路剩余带宽，8 个 RTT 为一个周期，轮流切换增益系数：

2 个 RTT，增益 1.25：略微提速探测，看是否还有空闲带宽；
1 个 RTT，增益 0.75：降速排空新增队列；
其余 5 个 RTT，增益 1：稳定速率传输。

ProbeBW 阶段，BBR 持续维持发送速率接近瓶颈带宽，少量随机丢包不会降低 cwnd。这是 BBR 对比 CUBIC 最大优势，公网、无线链路性能远优于 CUBIC。

阶段 4：ProbeRTT 探测最小 RTT

每过 10 个 RTT，BBR 进入 ProbeRTT。把 in-flight 数据限制到 4 个 MSS，清空队列，重新采样最小 RTT。这个阶段发送速率会短暂降低，拿到新的 BtlRTT，回到 ProbeBW。

ProbeRTT 阶段抓包会看到短暂发包变少，属于 BBR 正常行为，不是故障。

5.2 BBR 和 CUBIC 核心差异

项目	CUBIC	BBR
拥塞判断依据	报文丢失作为拥塞信号	测量带宽、RTT，建立链路模型
丢包处理	一旦丢包，cwnd 减半	随机非拥塞丢包，不降低 cwnd
目标	尽量填满队列，榨取带宽	填满链路管道，避免队列堆积，压低延迟
适用场景	数据中心低丢包内网	公网、跨地域、无线，存在随机丢包场景

5.3 Linux 查看、切换拥塞控制算法

# 查看当前系统支持拥塞算法
sysctl net.ipv4.tcp_available_congestion_control

# 查看当前默认拥塞算法
sysctl net.ipv4.tcp_congestion_control

# 临时切换为BBR
sysctl net.ipv4.tcp_congestion_control=bbr

# 永久开启BBR（内核4.9+支持）
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

5.4 如何在 Wireshark 抓包里识别 BBR 连接？

Wireshark 本身不会直接标记 BBR，不能直接看报文头部识别 BBR，需要通过报文时序特征间接判断：

稳态阶段发包速率平滑，不像 CUBIC 锯齿状爆发；
出现少量丢包、快速重传，但是拥塞窗口不会断崖式下降；
周期性出现短暂发包降低（ProbeRTT 阶段）；
结合内核配置，确认服务端 / 客户端启用 BBR。

注意：BBR 无法从 TCP 报文头直接识别，必须结合主机内核配置 + 报文时序综合判断。很多新手误以为 TCP 头部有 BBR 标记，这是误区。

5.5 BBR 的局限性

BBR 对 Bufferbloat（设备缓存过大）场景，会持续填满缓存，导致延迟升高；
在极小带宽链路，BBR 性能不一定优于 CUBIC；
中间防火墙、QoS 限速设备，会干扰 BBR 的带宽测量，造成性能抖动；
BBR v1 存在一些固有缺陷，BBR v2 做了改进，内核版本需要较高。

六、综合实战案例：Wireshark 完整 TCP 链路排障

场景描述

业务：跨公网 HTTP 接口，客户端访问服务器，接口偶尔超时，吞吐量上不去。抓包发现大量[TCP Out-Of-Order]、少量[TCP Fast Retransmission]，开启 SACK，服务器内核启用 BBR。
排障完整步骤：

过滤 TCP 流，选择一条业务流，右键追踪 TCP 流 tcp.stream eq 0；
统计重传：tcp.analysis.retransmission，统计重传报文数量，计算重传率；
区分重传类型：快速重传为主，少量虚假重传，几乎没有超时重传；
分析乱序：大量 Out-Of-Order，两端抓包对比，确认是公网多路径 ECMP 带来真实乱序，不是伪乱序；
查看 TCP 选项：SYN 报文协商 SACK，ACK 报文携带 SACK/D-SACK 块，SACK 正常生效；
分析拥塞控制：服务器开启 BBR，少量丢包没有造成窗口暴跌，带宽维持稳定；
结论：公网链路存在随机丢包 + 多路径乱序，BBR 相比 CUBIC 已经优化了吞吐。优化方向：调整应用超时，或者专线替代公网链路。

常用 Wireshark 过滤汇总（收藏）

# 所有TCP重传
tcp.analysis.retransmission
# 快速重传
tcp.analysis.fast_retransmission
# 虚假重传
tcp.analysis.spurious_retransmission
# TCP乱序
tcp.analysis.out_of_order
# 重复ACK
tcp.analysis.duplicate_ack
# SACK选项
tcp.options.sack
# D-SACK
tcp.options.dsack
# 追踪指定TCP流
tcp.stream eq 0
# 过滤特定IP之间TCP流量
ip.src==192.168.1.100 and ip.dst==192.168.1.200 and tcp

七、常见故障排查清单

7.1 大量超时重传

排查方向：

链路物理层故障，光模块、网线、WiFi 信号差；
防火墙、安全设备丢包，会话老化；
中间链路 MTU 不匹配，大报文分片丢包；
接收端应用读取缓慢，接收窗口耗尽，零窗口。

7.2 大量快速重传，几乎无超时重传

排查方向：

链路随机丢包；
ECMP 多路径乱序，触发 Dup ACK 引发快速重传；
中间设备 QoS 队列丢包。

7.3 大量 Out-Of-Order 乱序提示，业务无明显卡顿

排查方向：

ECMP 等价路由多路径转发；
确认是伪乱序还是真实乱序，两端抓包验证；
轻微乱序无需处理；大幅度乱序，调整路由策略，关闭 ECMP。

7.4 大量虚假重传 Spurious Retransmission

排查方向：

RTO 计算过小，RTT 抖动；
回程 ACK 延迟；
可以调整 tcp_rto_min 内核参数优化。

7.5 SACK 不生效

排查方向：

SYN 握手没有协商 SACK；
内核关闭 tcp_sack；
中间防火墙拦截 TCP 选项，删除 SACK 选项。

八、面试 & 运维高频问题总结

超时重传和快速重传的区别？
答：超时重传是 RTO 计时器到期触发，代价大；快速重传收到 3 个重复 ACK 触发，无需等待超时，响应更快。
什么是虚假重传？
答：发送方超时重传，但原始报文已经到达接收端，只是 ACK 延迟抵达。报文并没有丢失，属于不必要重传，Wireshark 标记 Spurious Retransmission。
TCP 乱序一定会造成业务故障吗？
答：不一定。轻微乱序是现代网络常态，只有大幅度乱序，触发大量 Dup ACK 和快速重传，才会影响性能。同时区分真实乱序和抓包导致的伪乱序。
SACK 作用是什么？D-SACK 是什么？
答：SACK 选择性确认，告诉发送方哪些非连续数据块已经收到，发送方只重传丢失报文。D-SACK 用来通知发送方收到重复报文，识别虚假重传。
BBR 和 CUBIC 核心区别？
答：CUBIC 是基于丢包的拥塞控制，丢包直接降低拥塞窗口；BBR 基于带宽、RTT 建立链路模型，随机丢包不会削减窗口，公网、无线链路性能更好。BBR 分为 Startup、Drain、ProbeBW、ProbeRTT 四个阶段。
Wireshark 看到 Out-Of-Order，如何确认是真实乱序还是伪乱序？
答：两端抓包，客户端和服务端同时抓包。如果服务端抓包没有乱序，仅镜像抓包看到乱序，属于伪乱序。
BBR 能不能直接从 TCP 报文头部识别？
答：不能。TCP 头部没有 BBR 标记，需要结合报文时序特征，并且确认主机内核拥塞控制配置综合判断。

九、总结

TCP 重传、乱序、SACK、BBR 是网络性能分析的核心组合。很多工程师踩坑根源：看到 Wireshark 红色重传标记就直接判定链路丢包，看到乱序就认为网络故障，忽略伪重传、伪乱序的场景。

重传分为超时重传、快速重传、虚假重传，三者故障含义完全不同；超时重传对业务伤害最大；
TCP 乱序在云 ECMP、公网链路属于常态，区分真实乱序和抓包带来的伪乱序，两端抓包是验证金标准；
SACK 选择性确认，解决丢包场景下重复重传问题，提升长链路传输性能，生产环境建议开启；D-SACK 用于识别虚假重传；
BBR 是基于带宽时延模型的拥塞控制，不再以丢包作为拥塞信号，在公网、跨地域传输场景相比传统 CUBIC 有巨大优势，BBR 四个阶段的发包特征可以通过 Wireshark 报文时序观察。

Wireshark TCP 分析不能只依赖专家提示，必须结合抓包位置、两端报文、内核参数、网络架构综合判断。建议在 Linux 靶场搭建 BBR 环境，构造丢包、乱序场景，亲自抓包，对比 CUBIC 和 BBR 抓包差异，加深理解。在云原生、跨公网业务排查、压测性能分析场景，这套分析思路可以快速定位网络瓶颈。