1. 先想清楚TCP 实验为什么必须靠抓包来学标题写着 Wireshark 与 TCP说白了就是一件事把一条 TCP 连接从建立到断开的全过程一个字节一个字节地摊在屏幕上。教科书里的三次握手、四次挥手、滑动窗口、拥塞控制全是状态机图和公式看完合上书脑子里其实还是空的。但只要你在 Wireshark 里亲手点开一个 SYN 包看到Flags: 0x002 (SYN)、Sequence Number: 0、Window Size: 64240、Maximum Segment Size: 1460那些抽象概念立刻就落到了具体字段上。这就是抓包实验不可替代的地方它把协议规范变成了可以点开、可以对照、可以验证的物证。我最早做这类实验的时候最大的困惑其实在于不知道该看什么。抓包一开几十万行报文哗啦啦往下滚80% 是各种后台心跳、系统更新、域名解析真正想看的那条连接藏在里面根本找不到。后来才明白抓包这件事的核心能力在于“裁剪”而非“抓”先把无关流量砍掉再针对剩下的一小撮做逐字段分析。所以这篇内容我会从实验设计讲到环境搭建再讲过滤器体系、握手拆解、序号分析、窗口与吞吐估算最后把翻车实录和交付物整理都过一遍。适合刚接触网络协议分析的同学也适合已经能抓包但总在“抓到了却看不懂”这一步卡住的人。1.1 抽象状态机与真实报文之间的鸿沟TCP 协议规范里状态迁移图有十一个状态CLOSED、LISTEN、SYN_SENT、SYN_RCVD、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、CLOSING、LAST_ACK、TIME_WAIT。只看图你很难理解为什么需要一个 CLOSING 状态也很难体会到 TIME_WAIT 为什么必须存在两倍报文寿命那么久。而在抓包里CLOSING 状态对应的是“双方几乎同时发 FIN”这种极端情况你能看到两个方向的 FIN 交叉出现随后各自回 ACK而不是标准的 FIN-ACK-FIN-ACK 顺序。这种场景在实验环境里需要刻意构造但一旦构造出来那个状态就再也不会忘了。同样的鸿沟还体现在“可靠传输”上。教材说 TCP 用序号和确认号保证有序到达听起来理所当然。但你在抓包里看到[TCP Previous segment not captured]、[TCP Fast Retransmission]、[TCP Retransmission]、[TCP Out-Of-Order]这几种标注时才会真正意识到所谓可靠是靠在不可靠的链路上不断试错换来的而每一种异常标注背后都对应一套不同的判定逻辑。Wireshark 的 TCP 分析器本质上是在帮你做一遍协议推理它标注“快速重传”是因为它看到三个重复 ACK 之后紧跟一个回退序号的段它标注“乱序”是因为它看到序号跳跃但后续又补上了前面的缺口。把这些标注和实际报文对照着看比读十遍 RFC 都管用。1.2 抓包点的三种选法与代价对比实验设计的第一件事是决定在哪里抓。位置选错后面所有分析都白费。常见的三种选法各自的成本和能看到的视野完全不同抓包位置能看到什么代价与局限端点本机抓包完整的双向数据流包含应用层载荷看不到中间设备行为本机回环需要额外适配交换机镜像口多台主机的全部流量适合观察并发连接需要设备权限镜像口容易丢包时钟与主机不同步中间主机代理转发可以人为制造延迟、丢包、乱序引入了额外一跳时序被改写分析结论需谨慎我通常优先选端点抓包。原因很实际实验的目的是理解协议行为不是复现真实生产链路。端点抓包拿到的报文序列号、确认号、窗口值都是最原始的不会被中间设备改写而经过代理或镜像的流量往往会出现时序被压缩、窗口被调整、甚至 MSS 被重写的情况初学者很容易把中间设备的行为误认为协议本身的特性。如果确实要做丢包与重传的实验再考虑引入可控的中间环节并且明确记录“这一段是我们人为加进去的”。提示不要在实验里同时改动多个变量。既换抓包点又加人为延迟最后分析出的异常根本归因不了。2. 环境准备让抓到的每一个字节都可信环境这一步网上教程大多一笔带过但它决定了后面所有分析的可信度。我见过太多人抓着抓到的包来问“为什么校验和全是错的”“为什么时间戳差了 3 秒”“为什么只抓到一半的流量”最后发现全是环境问题。先把工具链理清楚抓包引擎负责从网卡把帧捞上来分析器负责解析和呈现。两个环节都可能出问题。实际动手之前建议做三件事确认网卡型号与驱动是否支持需要的模式确认抓包权限普通用户往往只能看到自己进程的流量确认磁盘空间一个满速千兆链路抓一小时文件能到几十 GB 的量级。这三件事任何一件不到位实验都会在中途崩掉而且崩得很莫名。2.1 安装、权限与驱动那一堆坑抓包工具有两个部件需要分清底层的抓包库和上层的图形界面。抓包库负责和网卡驱动打交道部分平台需要单独安装安装时会顺带装一个虚拟的回环网卡用来抓本机内部进程之间的通信。这里第一个坑就来了如果你的实验是“本机浏览器访问本机上的服务”流量根本不经过物理网卡只走回环而回环网卡的名称往往不叫常见的那个名字你得在接口列表里专门找带 “Loopback” 字样的那一项否则抓半天一个包都没有。第二个坑是权限。在类 Unix 系统上抓包需要对网卡做原始访问普通用户默认没这个权限通常需要把用户加入特定用户组或者用提权方式启动。但提权启动之后配置文件、插件、最近打开的文件列表都跟着变了你会觉得“怎么和我平时用的不一样”。我个人的做法是固定用非提权的图形界面加已配置好的权限组需要提权的批量处理另走命令行工具两边互不干扰。第三个坑是驱动与网卡的卸载计算。现代网卡为了性能会把校验和计算、分段重组这些活交给硬件做。结果就是抓包库在数据离开网卡之前把它截下来了此时校验和字段还是空的或者错的TCP 分段也还没切。于是你在分析器里看到一片“校验和错误”和超大尺寸的 TCP 段吓得以为链路出问题了。这属于典型的抓包位置导致假象处理办法是关闭对应网卡的卸载功能或者在分析器的协议设置里关掉校验和验证。做实验时我倾向于前者因为关掉验证只是不报警报文本身还是错的容易误导后续判断。2.2 时间戳、缓冲与文件格式的取舍时间精度这件事在分析重传和延迟时特别关键。默认情况下抓包库给的时间戳精度是微秒级普通实验足够用了但如果要观察微秒以下级别的间隔比如高速链路下的短突发就需要显式开启纳秒精度而且文件格式必须选支持高精度时间戳的那种。老式的抓包文件格式精度有限转存的时候精度会被截断这个细节经常被忽略导致两组数据对比时“时间对不上”。缓冲策略也得提前想。抓包库默认会攒一批数据再一次性写入磁盘减少 I/O 次数。好处是性能高坏处是一旦程序崩溃或者机器断电缓冲区里那部分就没了。实验时如果只是想抓几十秒的握手过程可以把缓冲关掉或者设得很小保证数据实时落盘如果要做长时间的大流量采集就必须开缓冲并且定期切分文件避免单个文件过大导致后续打开和分析都卡死。切分文件除了控制体积还有一个隐性好处每段时间对应一个明确的实验动作事后定位特别快。文件命名建议带上前缀、时间、场景三个要素。我见过太多“新建文件夹 (3)”里的“capture.pcapng”过两天自己都不知道哪个是握手、哪个是重传。2.3 造流量可控的对端比真实公网更好用实验里最忌讳的就是拿真实公网服务当唯一的流量源。原因很简单你控制不了对端。对端的窗口大小、拥塞算法、是否启用选择性确认、是否中途重置连接全在别人手里你只能被动观察。一旦分析结论和对端行为耦合实验就失去了可重复性。可控的对端有几种做法。第一种是在同一台机器上起一个简单服务用回环地址访问好处是零外部依赖坏处是回环链路的往返时间极短很多和时间相关的特性重传超时、延迟确认根本触发不出来。第二种是在局域网内的另一台机器上起服务这样有真实的链路往返能观察延迟确认和窗口更新。第三种是用脚本精确控制服务端行为比如故意在握手中不接受某个选项、故意只发一半数据就停住、故意不回 ACK用来构造实验需要观察的异常场景。我自己做重传实验时通常用一个很小的自定义服务端配合发送端的分段逻辑人为制造“接收方不回 ACK”的状态然后在发送端抓包等重传超时自己触发。这样抓到的重传包时间间隔接近协议实现里的初始超时值而且不受外界干扰非常适合写进报告。3. 过滤器体系先把 99% 的噪声砍掉过滤器是整个实验里最有性价比的技能。一条连接可能只有几百个包但网卡上同时跑着几百条连接总量几十万包。如果你不知道过滤语法就只能靠肉眼在滚动的列表里找效率低到无法接受。过滤体系分两层抓包时用的底层过滤和抓包后用的显示过滤。前者决定哪些包被写进文件后者决定哪些包被显示出来。这两层的语法完全不同混淆是初学者最常见的错误之一。我的建议是抓包过滤尽量宽松显示过滤尽量精细。理由很充分抓包过滤一旦写错丢掉的包永远找不回来只能重抓显示过滤写错了改一下立刻生效成本几乎为零。所以除非流量量大到磁盘扛不住否则不要在抓包阶段做过度裁剪。3.1 抓包过滤与显示过滤别用反了抓包过滤用的是经典的底层过滤语法关键词是host、port、net、tcp、udp这类运算符是and、or、not取反还可以写成!。它的特点是粒度粗只认地址和端口不认协议字段。比如想只抓某个测试地址的 8080 端口写成host 192.0.2.10 and tcp port 8080这就够了。显示过滤走的是另一套语法能深入到每一个协议字段。同样是端口条件要写成ip.addr 192.0.2.10 tcp.port 8080。运算符用、||、!或者and、or、not都行但字段名必须完全正确写错一个字母就会变红。它最强大的地方是能判断标志位和解析状态比如“只看 SYN 包”、“只看被标注为重传的包”、“只看某一方向的数据段”这些用抓包过滤根本表达不出来。记住一个判断标准语法里出现点号加字段名的是显示过滤语法里只有地址、端口、协议名的是抓包过滤。3.2 常用的 TCP 显示过滤速查下面这张表是我做实验时最常用的一批基本覆盖了从握手到收尾的全部观察需求观察目标显示过滤表达式只看某条连接的握手首包tcp.flags.syn 1 tcp.flags.ack 0只看握手回应包tcp.flags.syn 1 tcp.flags.ack 1只看纯确认包无载荷tcp.flags.ack 1 tcp.len 0 tcp.flags.syn 0 tcp.flags.fin 0只看结束包tcp.flags.fin 1只看重置tcp.flags.reset 1只看所有异常标注tcp.analysis.flags只看重传tcp.analysis.retransmission只看快速重传tcp.analysis.fast_retransmission只看重复 ACKtcp.analysis.duplicate_ack只看零窗口通告tcp.analysis.zero_window只看带载荷的数据段tcp.len 0只看某个端口tcp.port 8080只看某个方向ip.src 192.0.2.10 tcp.dstport 8080表格里最值得单独说的是tcp.analysis.flags。它是个聚合条件只要分析器给这个包打上了任何异常标记它就被选中。做初步筛查时先跑这一条能快速定位到整条连接里所有可疑位置然后再用更精确的条件逐个展开效率高得多。3.3 用 tcp.stream 把一条连接单独拎出来真正好用的是流编号。分析器会自动把属于同一条连接的报文归到一个编号下从 0 开始递增。你只要在任意一个包上右键选“追踪 TCP 流”就能看到这条连接的全部内容按方向分色显示同时过滤栏里会自动填入tcp.stream eq 3这样的表达式。这一步是分水岭从“面对几十万包”变成“面对几百包”后面所有分析都在这几百包里做。流编号还有一个隐藏用途当你需要对比多条连接的行为差异时可以先把候选流号提取出来再用tcp.stream eq 3 || tcp.stream eq 7这样的条件同时显示横向比较两条连接的握手选项、窗口变化、重传次数。做实验报告时这个技巧非常省事能直观看出“同样的服务为什么一条快一条慢”。提示流编号是分析器在本次会话里动态分配的换一个文件重新打开编号可能变化。写报告时如果引用了流号务必同时写下连接的四元组否则将来别人无法复现你的定位。4. 逐字段拆三次握手与四次挥手握手和挥手是实验的必修段但很多人只看了标志位就结束其实信息密度远不止于此。真正有价值的字段藏在选项区最大段长度、窗口缩放因子、选择性确认许可、时间戳。这几个选项决定了整条连接后续的传输性能上限。可以说连接性能的上限在握手那一刻就已经被谈妥了后面所有的窗口调整都是在这个谈判结果里做文章。我的习惯是把握手三个包并排看重点盯三个东西双方各自声明的最大段长度是否一致、是否都带了窗口缩放、时间戳选项是否存在。这三项里任何一项缺失后面的分析都要相应调整预期。4.1 握手三包选项字段才是重点第一个包由客户端发出标志位只有 SYN序号是随机初始值我们记作 x。这个包的选项区一般包含最大段长度、窗口缩放因子、选择性确认许可、时间戳。最大段长度告诉对方“我最多能接收这么大的 TCP 载荷”以太网环境下典型值是 1460 字节算法很简单链路最大传输单元 1500 减去 IP 头 20 字节、再减去 TCP 头 20 字节。如果链路上有额外封装比如隧道这个值会相应变小你在抓包里看到的可能就是 1400 甚至更小。第二个包由服务端回标志位是 SYN 加 ACK序号是服务端自己的随机初始值 y确认号是 x1。注意这个 1SYN 虽然不携带数据但它占用一个序号所以确认号必须加一。这一点在分析挥手时也一样FIN 同样占用一个序号。第二个包的选项区是服务端对自己能力的声明注意它是独立的不用和客户端保持一致。实践中经常出现客户端声明缩放因子 7、服务端只回 5 的情况最终生效的是双方各自收到的那个值且两个方向可以不同。第三个包是客户端回 ACK确认号 y1序号 x1通常不带选项也不带数据。到这一刻连接建立完成。整个握手在抓包里耗时通常只有几毫秒但如果这个时间明显偏大几十毫秒甚至上百毫秒就说明链路往返时间不小这直接决定了后续吞吐上限值得单独记录。4.2 挥手四包与 TIME_WAIT 的观察标准的关闭过程是四个包。主动关闭方先发 FIN 加 ACK此时它进入等待状态还能继续接收数据但不能发送被动关闭方回一个 ACK进入对方的等待状态此时它仍可以继续发送剩余数据等它把数据发完再发自己的 FIN 加 ACK主动方回最后一个 ACK然后进入一个持续两倍报文寿命的等待状态。这个等待状态在抓包里是看不到包的因为它是内核里的一个计时器。但你能通过后续行为间接观察到如果在这个等待期内同一个四元组又被复用发起新连接抓包里会出现异常现象比如新连接的 SYN 收到 RST或者出现序号错乱。做实验时我一般会分别观察两种情况客户端主动关闭等待状态出现在客户端、服务端主动关闭等待状态出现在服务端。两者的差别会直接影响高并发服务的端口耗尽风险这一点在网络编程里是经典的踩坑点。还要注意半关闭的观察。当一方发了 FIN 之后另一方还没有发 FIN 的这段时间里连接处于半关闭状态此时数据只能单向流动。抓包里表现为某一个方向上连续出现带载荷的数据段另一个方向上只有确认直到数据发完才出现 FIN。这个时间段在实验里可以刻意拉长比如让服务端在收到关闭请求后延迟几秒再关闭就能清楚地看到单向传输阶段。4.3 抓不到握手先别怀疑工具很多人第一次做实验抓了半天找不到 SYN 包第一反应是工具坏了。实际上常见原因就那么几个按概率排序一是抓包开始时连接早就建立了你抓到的是连接中段。解决办法是先开抓包再发起访问。二是抓包点选错比如你抓的是无线网卡但流量走的是有线网卡或者你抓的是物理网卡但目标是本机回环。三是中间存在代理客户端连的是代理代理再连目标于是你看到的握手是客户端和代理之间的真正的目标连接在另一台机器上。四是过滤条件写得太窄把握手包本身过滤掉了比如你写了tcp.len 0而握手包载荷长度为零。排查顺序我一般是先清空过滤看全量再确认接口选对最后确认抓包时序。这三步能解决九成以上的“抓不到”。5. 序号、确认号可靠性是怎么被“看出来”的序号和确认号是 TCP 分析的主线。所有的重传、乱序、重复、丢包判断最终都归结为“这个包的序号是不是预期的那个”。但直接看绝对序号很难受因为初始值是随机的大数动辄十亿级别两个包差 1460 你根本看不出来。所以分析器默认开启了相对序号把每条连接的初始序号映射成 0后续按偏移量显示。这个开关在协议设置里实验时建议保持开启除非你要研究初始序号生成策略。开启相对序号之后一切都变得直观握手第一个包的序号是 0第二个包是 0第三个包是 1第一个数据段是 1长度 1460那么下一个期望的序号就是 1461。如果抓到的下一个包序号是 1461正常如果是 2921说明中间有段没抓到如果是 1461 但被标注为乱序说明它晚到了。5.1 相对序号开关与“看起来不合理”的 seq相对序号的映射是按方向独立计算的。也就是说客户端到服务端方向的 0和服务端到客户端方向的 0 是两个不同的基准各自对应各自的初始序号。这一点必须记牢否则看到两个方向的序号都是小数字时会误以为哪里算错了。还有一个容易误导的现象当连接中途开始抓包时分析器拿不到初始握手包就无法建立映射基准它会退而把看到的第一个包当作基准。这时候显示的相对序号虽然也是从 0 或 1 开始但它和真实偏移无关做跨连接的序号比较会出错。判断方法很简单看第一个包有没有 SYN 标志。如果没有就说明这次抓包是不完整的任何基于序号连续性的结论都要打折扣。另外当出现重传时你会看到同一个相对序号出现两次。这不是错误这正是重传的定义。分析器会给后出现的那个打上重传标记并且在备注里说明“这是第几次重传”。三次以上的重传通常意味着链路真的有问题值得进一步查。5.2 重传、快速重传与 SACK 的报文特征普通的超时重传特征是“等”。发送方发出一个段迟迟收不到确认等到计时器到期再发一遍完全相同的段。抓包里表现为两次相同序号的段之间隔了一段明显偏长的时间而且中间没有任何来自接收方的确认。初始超时值通常在几百毫秒到一秒之间重传后如果还失败超时值会翻倍所以你会看到重传间隔一次比一次长。快速重传不需要等计时器。它的触发条件是发送方连续收到三个重复的确认号说明某个段大概率丢了但后续的段都到了。此时发送方立刻重发缺口那个段不用等超时。抓包里的特征是先出现若干个确认号完全相同的 ACK重复确认紧接着一个序号回退的段这个段被标注为快速重传。恢复速度比超时重传快得多通常只损失一个往返时间。选择性确认是配合重传来的。接收方在确认包里带上一个选项告诉发送方“我收到了哪几段”这样发送方就不用把缺口之后的所有段全部重发一遍只补缺口就行。抓包里看到确认包的选项区有“选择性确认”条目说明双方都支持这个能力。启用之后一次丢包往往只需要重传一个段而不是一大片这个差异在长肥管道上非常明显。5.3 乱序、零窗口、保活的识别乱序和丢包在抓包里看起来很像都会导致“序号跳跃”。区别在于乱序的段最终会到达只是顺序颠倒了分析器会把它标注为乱序而不是丢包真正丢了的段永远不会出现只能靠重传来补。判断方法是看后续有没有那个缺失序号的包有就是乱序没有就是丢包。乱序在链路存在多条路径时很常见实验里可以用中间设备人为制造。零窗口是接收方主动喊停。当接收缓冲被填满接收方在确认包里把窗口字段置零发送方看到之后必须停止发送进入持续探测状态定期发一个小包问“现在能收了吗”。抓包里表现为某个确认包的窗口值为 0之后一段时间内出现若干个载荷长度为 1 的探测包直到窗口恢复。这个现象在接收方处理速度跟不上发送方时非常典型做实验时可以故意让服务端读得慢一点来复现。保活报文则完全不同它是空闲连接的定期探测载荷通常为零或一字节序号是发送方已发送的最后一个字节减一。看到这种“不合常理”的序号别慌那是协议设计的刻意为之。6. 从窗口到吞吐量抓包能不能算出真实带宽这条连接最快能跑多少是实验里最有价值的结论之一。而这个结论不需要做压测光靠握手包和几个数据包就能估算出来。核心变量有三个接收窗口大小、往返时间、是否启用窗口缩放。三者组合起来就能算出一个理论上限再和实测吞吐对比差距大就说明有瓶颈。先把概念说清楚。窗口是接收方告诉发送方“我还能接收多少字节”发送方在收到确认之前最多只能发这么多。所以单位时间内能发多少取决于窗口多大除以一次往返需要多久。这个商就是吞吐上限。公式写出来很简单吞吐 窗口 / 往返时间。但实际要用的时候窗口要乘上缩放因子往返时间要从抓包里实测两个细节一错结果能差两个数量级。6.1 窗口缩放因子到底怎么算TCP 头里的窗口字段只有 16 位最大表示 65535 字节。这个值在上世纪八十年代够用放在今天千兆链路上就是瓶颈假设往返时间 40 毫秒65535 字节除以 0.04 秒只有约 13 Mbps链路再快也跑不上去。所以后来加了个选项允许双方在握手时协商一个移位因子实际窗口等于字段值左移这个因子位。这个因子是握手时双方各自在 SYN 和 SYN-ACK 里声明的约定俗成的取值上限是 14。计算方式很直接实际窗口 窗口字段值 × 2^因子。举例来说抓包里看到窗口字段 64240因子是 7那么实际可接收窗口就是 64240 × 128 8,222,720 字节约 7.8 MB。这个量级才能支撑起千兆链路上的长肥管道传输。需要注意的是因子只在握手阶段协商一次之后不变。而窗口字段值在每个确认包里都可能变化所以要算某个时刻的实际窗口必须用当时的字段值乘上握手时定下的因子不能混用。分析器的协议设置里有个选项可以自动做这个换算把缩放后的值直接显示出来省去手工乘法。做实验时建议开启避免算错。6.2 三步估算法与一个完整算例我常用的估算流程分三步。第一步从握手包里取出双方声明的窗口缩放因子确认是否启用。第二步找到连接稳定传输阶段中一个较大的窗口通告值乘以缩放系数得到实际窗口。第三步从抓包里量出往返时间用实际窗口除以往返时间得到吞吐上限。举个具体例子。假设某次实验抓到的握手包里客户端声明因子 7服务端声明因子 7稳定阶段某个确认包的窗口字段是 65535因子 7那么实际窗口是 65535 × 128 8,388,480 字节。再从抓包里量往返时间找到一个数据段和它对应的确认两者时间差 40 毫秒。那么理论上限就是 8,388,480 ÷ 0.04 209,712,000 字节每秒换算成比特要乘 8约 1.68 Gbps。这个数字只是上限实际能不能达到还取决于发送方的拥塞窗口和应用层供给速度。所以做实验时要同时看两个量接收窗口决定“对方能收多快”拥塞窗口决定“发送方敢发多快”两者取小才是实际速率。拥塞窗口在抓包里不直接显示但可以通过“在途字节数”间接观察任一时刻已发送但未确认的字节总量就是当前的发送窗口它不会超过拥塞窗口和接收窗口中的较小者。分析器的 TCP 流图里有一条“在途字节数”曲线看那条曲线在什么水平上稳定就知道实际生效的窗口是多大。另外一个常见算例是反过来的已知链路带宽和往返时间算需要多大窗口才能跑满。带宽 100 Mbps往返 20 毫秒那么管道容量是 100,000,000 ÷ 8 × 0.02 250,000 字节。也就是说窗口至少要 25 万字节才能填满这条管道。如果抓包里看到接收方只通告了 65535 字节那这条连接最多只能跑到约 26 Mbps链路再宽也没用。这类结论在排查“带宽上不去”的问题时特别有说服力。6.3 TCP Stream Graphs 该看哪几张图分析器自带的流图功能能把上面的计算可视化。我常看四张时间-序列号图横轴时间纵轴序号正常情况下是一条条斜向上的平行线斜率就是瞬时速率。出现水平段说明在等确认出现垂直段说明有重传。这张图最能一眼看出“卡在哪”。吞吐量图纵轴是单位时间字节数。看它的稳定平台在哪里和上面算出的理论上限对不对得上差多少。往返时间图每个数据段和它的确认之间的时间差。这条曲线的抖动程度直接反映链路质量突然抬高的位置往往对应队列积压或者路径切换。窗口缩放图把接收窗口和拥塞窗口随时间的变化画出来。看窗口是不是长期贴在小值上如果一直很小说明接收方应用读得慢不是网络问题。这四张图配合着看基本能在几分钟内给一条连接定性。做实验报告时把这几张图截下来比贴一堆报文列表有说服力得多。7. 排错实录实验里最容易翻车的几种情况这一节全是踩过的坑。有些问题看起来像协议故障实际上是工具环境的问题有些看起来像工具问题实际上是自己的过滤条件写错了。区分这两类很重要否则会把大量时间浪费在错误的方向上。7.1 抓不到包 / 只抓到半边只抓到单向流量是极常见的现象尤其在虚拟化环境和无线网络里。表现是你能看到发出的包看不到回来的包或者反过来。原因通常是抓包点的位置不对比如流量实际走了另一块网卡或者无线环境下部分管理帧被驱动过滤掉了。排查方法很朴素先看接口列表里每块网卡的实时流量计数哪个在涨就抓哪个。如果所有网卡都不涨但应用确实在通信那大概率走了回环去抓回环接口。还有一种情况是抓到了包但被显示过滤藏起来了清空过滤栏再确认一次。另一个隐性原因是时间。如果两台机器的时钟不同步你又把两个抓包文件合并分析就会看到确认包早于数据包这种荒谬的时序。做多机实验前务必校时或者至少记录下各机器的时钟偏差。7.2 校验和报错的真相满屏“校验和错误”是新手最容易慌的。前面提过这通常是网卡的卸载计算导致的抓包发生在硬件计算校验和之前所以字段里是错的或者空的。判断方法很直接如果几乎所有包都报同一个错误而且链路工作正常那基本就是卸载问题不是真故障。处理方式有两种。彻底一点的是在系统层面关闭该网卡的校验和卸载功能让软件来计算这样抓到的包校验和就是对的。省事一点的是在分析器的协议设置里关掉校验和验证眼不见为净。我做实验时选前者因为关掉验证之后万一真有校验和错误也发现不了等于自废一项检查能力。顺带说一下 TCP 分段卸载。开启之后抓包库里看到的可能是远大于最大段长度的“巨包”因为分段还没发生。这类包在分析器里会显示为一个超大的 TCP 段序号分析也会跟着乱。同样通过关闭网卡卸载功能解决。7.3 显示与解析层面的假象还有一类问题纯属显示层的误导。比如分析器默认开启 TCP 重组会把多个小段拼成一个完整应用层消息显示这时候你看到的“一个包”其实是多个包拼出来的序号分析要以原始分段为准。排查重传问题时建议临时关掉重组看最原始的段。再比如时间显示格式。默认是相对本次抓包开始的秒数看起来是 0.001、0.002 这种小数字容易误以为是绝对时间。分析长连接时切换到“当天时间”格式更直观定位“几点几分出的问题”更快。最后一类假象来自分析器的启发式标注。它对“乱序”和“丢包”的判断是基于启发式规则的在某些场景下会误判比如超时重传和乱序重传难以区分。遇到标注和实际不符时不要盲信标签回到序号和时间的原始数据自己推一遍。8. 把实验报告写成能交付的东西做完分析不等于完成任务能不能把结论清楚地交付出去才是。我见过太多实验记录通篇是报文字段截图最后一句“分析完毕”看的人完全不知道结论是什么。一份有价值的记录应该让没参与实验的人也能顺着读下来并且能复现你的操作。报告里最关键的不是截图数量而是结论和证据的对应关系。每一条结论后面都要跟一个能定位到具体报文的证据比如“窗口字段长期停留在 65535未启用缩放因此吞吐上限约 26 Mbps”证据是某个流编号下第几个包。这种写法别人能验证也经得起追问。8.1 一份分析记录的骨架我自己的记录固定分五块。第一块是实验目标与假设写清楚这次要看什么现象预期是什么。第二块是环境与抓包点写清楚在哪抓、什么时候开始、用了什么过滤条件这部分决定可复现性。第三块是关键报文摘录只贴和结论相关的包每个包标注它在流中的位置和作用。第四块是量化结论包括往返时间、窗口大小、重传次数、吞吐上限全部给数字。第五块是异常与未解释现象把没搞清楚的也记下来这块往往是最有价值的部分因为它指出了下一步要研究的方向。第三块最容易被写成流水账。控制方法是先想清楚结论再倒推需要哪几个包作为证据只贴这几个。一条连接几百个包真正需要展示的通常不超过十个。8.2 用命令行工具把手工活压到最低图形界面适合探索批量统计适合命令行。比如要统计所有连接里哪些出现了重传用一条命令就能把结果拉出来不用一条条点开看。基本套路是指定读取文件、用显示过滤表达式筛选、只输出需要的字段。tshark -r capture.pcapng \ -Y tcp.analysis.retransmission \ -T fields -e frame.number -e ip.src -e tcp.srcport -e tcp.dstport -e tcp.seq再比如要列出所有连接的首包快速了解这次抓包里到底有多少条独立会话tshark -r capture.pcapng \ -Y tcp.flags.syn 1 tcp.flags.ack 0 \ -T fields -e frame.number -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport需要把大文件按连接拆开时可以先提取流编号再逐条导出。这类批处理的好处是可重复换一份抓包文件命令原样再跑一遍结果格式完全一致方便横向对比。做多组对照实验时我基本都用这个方式生成汇总表最后再把少数几条典型连接拿到图形界面里做详细讲解。提示批处理输出的字段顺序、分隔符尽量固定下来并写进报告附录。别小看这个细节同一个人隔两周回来往往也记不住当时用的是哪套字段。我个人在实际操作中的体会是TCP 抓包实验真正的门槛从来不在语法和字段而在于“先想清楚要验证什么再去抓”。漫无目的地抓一大堆包然后盯着屏幕找异常是最低效的做法。反过来先写下三个具体问题比如“这条连接的窗口缩放谈成了多少”“握手耗时是不是异常”“重传是超时触发还是快速重传触发”带着问题去过滤、去定位通常十几分钟就能出结论。另一个小技巧是给自己建一个过滤器收藏夹把常用表达式按场景归类存好用的时候直接点比每次重新敲快得多也能避免手误打错字段名导致的误判。 
长河君 · 2026/10/27 12:42:20 · 阅读 1.2k Wireshark TCP抓包实战：握手、重传与吞吐量分析
1. 先想清楚TCP 实验为什么必须靠抓包来学标题写着 Wireshark 与 TCP说白了就是一件事把一条 TCP 连接从建立到断开的全过程一个字节一个字节地摊在屏幕上。教科书里的三次握手、四次挥手、滑动窗口、拥塞控制全是状态机图和公式看完合上书脑子里其实还是空的。但只要你在 Wireshark 里亲手点开一个 SYN 包看到Flags: 0x002 (SYN)、Sequence Number: 0、Window Size: 64240、Maximum Segment Size: 1460那些抽象概念立刻就落到了具体字段上。这就是抓包实验不可替代的地方它把协议规范变成了可以点开、可以对照、可以验证的物证。我最早做这类实验的时候最大的困惑其实在于不知道该看什么。抓包一开几十万行报文哗啦啦往下滚80% 是各种后台心跳、系统更新、域名解析真正想看的那条连接藏在里面根本找不到。后来才明白抓包这件事的核心能力在于“裁剪”而非“抓”先把无关流量砍掉再针对剩下的一小撮做逐字段分析。所以这篇内容我会从实验设计讲到环境搭建再讲过滤器体系、握手拆解、序号分析、窗口与吞吐估算最后把翻车实录和交付物整理都过一遍。适合刚接触网络协议分析的同学也适合已经能抓包但总在“抓到了却看不懂”这一步卡住的人。1.1 抽象状态机与真实报文之间的鸿沟TCP 协议规范里状态迁移图有十一个状态CLOSED、LISTEN、SYN_SENT、SYN_RCVD、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、CLOSING、LAST_ACK、TIME_WAIT。只看图你很难理解为什么需要一个 CLOSING 状态也很难体会到 TIME_WAIT 为什么必须存在两倍报文寿命那么久。而在抓包里CLOSING 状态对应的是“双方几乎同时发 FIN”这种极端情况你能看到两个方向的 FIN 交叉出现随后各自回 ACK而不是标准的 FIN-ACK-FIN-ACK 顺序。这种场景在实验环境里需要刻意构造但一旦构造出来那个状态就再也不会忘了。同样的鸿沟还体现在“可靠传输”上。教材说 TCP 用序号和确认号保证有序到达听起来理所当然。但你在抓包里看到[TCP Previous segment not captured]、[TCP Fast Retransmission]、[TCP Retransmission]、[TCP Out-Of-Order]这几种标注时才会真正意识到所谓可靠是靠在不可靠的链路上不断试错换来的而每一种异常标注背后都对应一套不同的判定逻辑。Wireshark 的 TCP 分析器本质上是在帮你做一遍协议推理它标注“快速重传”是因为它看到三个重复 ACK 之后紧跟一个回退序号的段它标注“乱序”是因为它看到序号跳跃但后续又补上了前面的缺口。把这些标注和实际报文对照着看比读十遍 RFC 都管用。1.2 抓包点的三种选法与代价对比实验设计的第一件事是决定在哪里抓。位置选错后面所有分析都白费。常见的三种选法各自的成本和能看到的视野完全不同抓包位置能看到什么代价与局限端点本机抓包完整的双向数据流包含应用层载荷看不到中间设备行为本机回环需要额外适配交换机镜像口多台主机的全部流量适合观察并发连接需要设备权限镜像口容易丢包时钟与主机不同步中间主机代理转发可以人为制造延迟、丢包、乱序引入了额外一跳时序被改写分析结论需谨慎我通常优先选端点抓包。原因很实际实验的目的是理解协议行为不是复现真实生产链路。端点抓包拿到的报文序列号、确认号、窗口值都是最原始的不会被中间设备改写而经过代理或镜像的流量往往会出现时序被压缩、窗口被调整、甚至 MSS 被重写的情况初学者很容易把中间设备的行为误认为协议本身的特性。如果确实要做丢包与重传的实验再考虑引入可控的中间环节并且明确记录“这一段是我们人为加进去的”。提示不要在实验里同时改动多个变量。既换抓包点又加人为延迟最后分析出的异常根本归因不了。2. 环境准备让抓到的每一个字节都可信环境这一步网上教程大多一笔带过但它决定了后面所有分析的可信度。我见过太多人抓着抓到的包来问“为什么校验和全是错的”“为什么时间戳差了 3 秒”“为什么只抓到一半的流量”最后发现全是环境问题。先把工具链理清楚抓包引擎负责从网卡把帧捞上来分析器负责解析和呈现。两个环节都可能出问题。实际动手之前建议做三件事确认网卡型号与驱动是否支持需要的模式确认抓包权限普通用户往往只能看到自己进程的流量确认磁盘空间一个满速千兆链路抓一小时文件能到几十 GB 的量级。这三件事任何一件不到位实验都会在中途崩掉而且崩得很莫名。2.1 安装、权限与驱动那一堆坑抓包工具有两个部件需要分清底层的抓包库和上层的图形界面。抓包库负责和网卡驱动打交道部分平台需要单独安装安装时会顺带装一个虚拟的回环网卡用来抓本机内部进程之间的通信。这里第一个坑就来了如果你的实验是“本机浏览器访问本机上的服务”流量根本不经过物理网卡只走回环而回环网卡的名称往往不叫常见的那个名字你得在接口列表里专门找带 “Loopback” 字样的那一项否则抓半天一个包都没有。第二个坑是权限。在类 Unix 系统上抓包需要对网卡做原始访问普通用户默认没这个权限通常需要把用户加入特定用户组或者用提权方式启动。但提权启动之后配置文件、插件、最近打开的文件列表都跟着变了你会觉得“怎么和我平时用的不一样”。我个人的做法是固定用非提权的图形界面加已配置好的权限组需要提权的批量处理另走命令行工具两边互不干扰。第三个坑是驱动与网卡的卸载计算。现代网卡为了性能会把校验和计算、分段重组这些活交给硬件做。结果就是抓包库在数据离开网卡之前把它截下来了此时校验和字段还是空的或者错的TCP 分段也还没切。于是你在分析器里看到一片“校验和错误”和超大尺寸的 TCP 段吓得以为链路出问题了。这属于典型的抓包位置导致假象处理办法是关闭对应网卡的卸载功能或者在分析器的协议设置里关掉校验和验证。做实验时我倾向于前者因为关掉验证只是不报警报文本身还是错的容易误导后续判断。2.2 时间戳、缓冲与文件格式的取舍时间精度这件事在分析重传和延迟时特别关键。默认情况下抓包库给的时间戳精度是微秒级普通实验足够用了但如果要观察微秒以下级别的间隔比如高速链路下的短突发就需要显式开启纳秒精度而且文件格式必须选支持高精度时间戳的那种。老式的抓包文件格式精度有限转存的时候精度会被截断这个细节经常被忽略导致两组数据对比时“时间对不上”。缓冲策略也得提前想。抓包库默认会攒一批数据再一次性写入磁盘减少 I/O 次数。好处是性能高坏处是一旦程序崩溃或者机器断电缓冲区里那部分就没了。实验时如果只是想抓几十秒的握手过程可以把缓冲关掉或者设得很小保证数据实时落盘如果要做长时间的大流量采集就必须开缓冲并且定期切分文件避免单个文件过大导致后续打开和分析都卡死。切分文件除了控制体积还有一个隐性好处每段时间对应一个明确的实验动作事后定位特别快。文件命名建议带上前缀、时间、场景三个要素。我见过太多“新建文件夹 (3)”里的“capture.pcapng”过两天自己都不知道哪个是握手、哪个是重传。2.3 造流量可控的对端比真实公网更好用实验里最忌讳的就是拿真实公网服务当唯一的流量源。原因很简单你控制不了对端。对端的窗口大小、拥塞算法、是否启用选择性确认、是否中途重置连接全在别人手里你只能被动观察。一旦分析结论和对端行为耦合实验就失去了可重复性。可控的对端有几种做法。第一种是在同一台机器上起一个简单服务用回环地址访问好处是零外部依赖坏处是回环链路的往返时间极短很多和时间相关的特性重传超时、延迟确认根本触发不出来。第二种是在局域网内的另一台机器上起服务这样有真实的链路往返能观察延迟确认和窗口更新。第三种是用脚本精确控制服务端行为比如故意在握手中不接受某个选项、故意只发一半数据就停住、故意不回 ACK用来构造实验需要观察的异常场景。我自己做重传实验时通常用一个很小的自定义服务端配合发送端的分段逻辑人为制造“接收方不回 ACK”的状态然后在发送端抓包等重传超时自己触发。这样抓到的重传包时间间隔接近协议实现里的初始超时值而且不受外界干扰非常适合写进报告。3. 过滤器体系先把 99% 的噪声砍掉过滤器是整个实验里最有性价比的技能。一条连接可能只有几百个包但网卡上同时跑着几百条连接总量几十万包。如果你不知道过滤语法就只能靠肉眼在滚动的列表里找效率低到无法接受。过滤体系分两层抓包时用的底层过滤和抓包后用的显示过滤。前者决定哪些包被写进文件后者决定哪些包被显示出来。这两层的语法完全不同混淆是初学者最常见的错误之一。我的建议是抓包过滤尽量宽松显示过滤尽量精细。理由很充分抓包过滤一旦写错丢掉的包永远找不回来只能重抓显示过滤写错了改一下立刻生效成本几乎为零。所以除非流量量大到磁盘扛不住否则不要在抓包阶段做过度裁剪。3.1 抓包过滤与显示过滤别用反了抓包过滤用的是经典的底层过滤语法关键词是host、port、net、tcp、udp这类运算符是and、or、not取反还可以写成!。它的特点是粒度粗只认地址和端口不认协议字段。比如想只抓某个测试地址的 8080 端口写成host 192.0.2.10 and tcp port 8080这就够了。显示过滤走的是另一套语法能深入到每一个协议字段。同样是端口条件要写成ip.addr 192.0.2.10 tcp.port 8080。运算符用、||、!或者and、or、not都行但字段名必须完全正确写错一个字母就会变红。它最强大的地方是能判断标志位和解析状态比如“只看 SYN 包”、“只看被标注为重传的包”、“只看某一方向的数据段”这些用抓包过滤根本表达不出来。记住一个判断标准语法里出现点号加字段名的是显示过滤语法里只有地址、端口、协议名的是抓包过滤。3.2 常用的 TCP 显示过滤速查下面这张表是我做实验时最常用的一批基本覆盖了从握手到收尾的全部观察需求观察目标显示过滤表达式只看某条连接的握手首包tcp.flags.syn 1 tcp.flags.ack 0只看握手回应包tcp.flags.syn 1 tcp.flags.ack 1只看纯确认包无载荷tcp.flags.ack 1 tcp.len 0 tcp.flags.syn 0 tcp.flags.fin 0只看结束包tcp.flags.fin 1只看重置tcp.flags.reset 1只看所有异常标注tcp.analysis.flags只看重传tcp.analysis.retransmission只看快速重传tcp.analysis.fast_retransmission只看重复 ACKtcp.analysis.duplicate_ack只看零窗口通告tcp.analysis.zero_window只看带载荷的数据段tcp.len 0只看某个端口tcp.port 8080只看某个方向ip.src 192.0.2.10 tcp.dstport 8080表格里最值得单独说的是tcp.analysis.flags。它是个聚合条件只要分析器给这个包打上了任何异常标记它就被选中。做初步筛查时先跑这一条能快速定位到整条连接里所有可疑位置然后再用更精确的条件逐个展开效率高得多。3.3 用 tcp.stream 把一条连接单独拎出来真正好用的是流编号。分析器会自动把属于同一条连接的报文归到一个编号下从 0 开始递增。你只要在任意一个包上右键选“追踪 TCP 流”就能看到这条连接的全部内容按方向分色显示同时过滤栏里会自动填入tcp.stream eq 3这样的表达式。这一步是分水岭从“面对几十万包”变成“面对几百包”后面所有分析都在这几百包里做。流编号还有一个隐藏用途当你需要对比多条连接的行为差异时可以先把候选流号提取出来再用tcp.stream eq 3 || tcp.stream eq 7这样的条件同时显示横向比较两条连接的握手选项、窗口变化、重传次数。做实验报告时这个技巧非常省事能直观看出“同样的服务为什么一条快一条慢”。提示流编号是分析器在本次会话里动态分配的换一个文件重新打开编号可能变化。写报告时如果引用了流号务必同时写下连接的四元组否则将来别人无法复现你的定位。4. 逐字段拆三次握手与四次挥手握手和挥手是实验的必修段但很多人只看了标志位就结束其实信息密度远不止于此。真正有价值的字段藏在选项区最大段长度、窗口缩放因子、选择性确认许可、时间戳。这几个选项决定了整条连接后续的传输性能上限。可以说连接性能的上限在握手那一刻就已经被谈妥了后面所有的窗口调整都是在这个谈判结果里做文章。我的习惯是把握手三个包并排看重点盯三个东西双方各自声明的最大段长度是否一致、是否都带了窗口缩放、时间戳选项是否存在。这三项里任何一项缺失后面的分析都要相应调整预期。4.1 握手三包选项字段才是重点第一个包由客户端发出标志位只有 SYN序号是随机初始值我们记作 x。这个包的选项区一般包含最大段长度、窗口缩放因子、选择性确认许可、时间戳。最大段长度告诉对方“我最多能接收这么大的 TCP 载荷”以太网环境下典型值是 1460 字节算法很简单链路最大传输单元 1500 减去 IP 头 20 字节、再减去 TCP 头 20 字节。如果链路上有额外封装比如隧道这个值会相应变小你在抓包里看到的可能就是 1400 甚至更小。第二个包由服务端回标志位是 SYN 加 ACK序号是服务端自己的随机初始值 y确认号是 x1。注意这个 1SYN 虽然不携带数据但它占用一个序号所以确认号必须加一。这一点在分析挥手时也一样FIN 同样占用一个序号。第二个包的选项区是服务端对自己能力的声明注意它是独立的不用和客户端保持一致。实践中经常出现客户端声明缩放因子 7、服务端只回 5 的情况最终生效的是双方各自收到的那个值且两个方向可以不同。第三个包是客户端回 ACK确认号 y1序号 x1通常不带选项也不带数据。到这一刻连接建立完成。整个握手在抓包里耗时通常只有几毫秒但如果这个时间明显偏大几十毫秒甚至上百毫秒就说明链路往返时间不小这直接决定了后续吞吐上限值得单独记录。4.2 挥手四包与 TIME_WAIT 的观察标准的关闭过程是四个包。主动关闭方先发 FIN 加 ACK此时它进入等待状态还能继续接收数据但不能发送被动关闭方回一个 ACK进入对方的等待状态此时它仍可以继续发送剩余数据等它把数据发完再发自己的 FIN 加 ACK主动方回最后一个 ACK然后进入一个持续两倍报文寿命的等待状态。这个等待状态在抓包里是看不到包的因为它是内核里的一个计时器。但你能通过后续行为间接观察到如果在这个等待期内同一个四元组又被复用发起新连接抓包里会出现异常现象比如新连接的 SYN 收到 RST或者出现序号错乱。做实验时我一般会分别观察两种情况客户端主动关闭等待状态出现在客户端、服务端主动关闭等待状态出现在服务端。两者的差别会直接影响高并发服务的端口耗尽风险这一点在网络编程里是经典的踩坑点。还要注意半关闭的观察。当一方发了 FIN 之后另一方还没有发 FIN 的这段时间里连接处于半关闭状态此时数据只能单向流动。抓包里表现为某一个方向上连续出现带载荷的数据段另一个方向上只有确认直到数据发完才出现 FIN。这个时间段在实验里可以刻意拉长比如让服务端在收到关闭请求后延迟几秒再关闭就能清楚地看到单向传输阶段。4.3 抓不到握手先别怀疑工具很多人第一次做实验抓了半天找不到 SYN 包第一反应是工具坏了。实际上常见原因就那么几个按概率排序一是抓包开始时连接早就建立了你抓到的是连接中段。解决办法是先开抓包再发起访问。二是抓包点选错比如你抓的是无线网卡但流量走的是有线网卡或者你抓的是物理网卡但目标是本机回环。三是中间存在代理客户端连的是代理代理再连目标于是你看到的握手是客户端和代理之间的真正的目标连接在另一台机器上。四是过滤条件写得太窄把握手包本身过滤掉了比如你写了tcp.len 0而握手包载荷长度为零。排查顺序我一般是先清空过滤看全量再确认接口选对最后确认抓包时序。这三步能解决九成以上的“抓不到”。5. 序号、确认号可靠性是怎么被“看出来”的序号和确认号是 TCP 分析的主线。所有的重传、乱序、重复、丢包判断最终都归结为“这个包的序号是不是预期的那个”。但直接看绝对序号很难受因为初始值是随机的大数动辄十亿级别两个包差 1460 你根本看不出来。所以分析器默认开启了相对序号把每条连接的初始序号映射成 0后续按偏移量显示。这个开关在协议设置里实验时建议保持开启除非你要研究初始序号生成策略。开启相对序号之后一切都变得直观握手第一个包的序号是 0第二个包是 0第三个包是 1第一个数据段是 1长度 1460那么下一个期望的序号就是 1461。如果抓到的下一个包序号是 1461正常如果是 2921说明中间有段没抓到如果是 1461 但被标注为乱序说明它晚到了。5.1 相对序号开关与“看起来不合理”的 seq相对序号的映射是按方向独立计算的。也就是说客户端到服务端方向的 0和服务端到客户端方向的 0 是两个不同的基准各自对应各自的初始序号。这一点必须记牢否则看到两个方向的序号都是小数字时会误以为哪里算错了。还有一个容易误导的现象当连接中途开始抓包时分析器拿不到初始握手包就无法建立映射基准它会退而把看到的第一个包当作基准。这时候显示的相对序号虽然也是从 0 或 1 开始但它和真实偏移无关做跨连接的序号比较会出错。判断方法很简单看第一个包有没有 SYN 标志。如果没有就说明这次抓包是不完整的任何基于序号连续性的结论都要打折扣。另外当出现重传时你会看到同一个相对序号出现两次。这不是错误这正是重传的定义。分析器会给后出现的那个打上重传标记并且在备注里说明“这是第几次重传”。三次以上的重传通常意味着链路真的有问题值得进一步查。5.2 重传、快速重传与 SACK 的报文特征普通的超时重传特征是“等”。发送方发出一个段迟迟收不到确认等到计时器到期再发一遍完全相同的段。抓包里表现为两次相同序号的段之间隔了一段明显偏长的时间而且中间没有任何来自接收方的确认。初始超时值通常在几百毫秒到一秒之间重传后如果还失败超时值会翻倍所以你会看到重传间隔一次比一次长。快速重传不需要等计时器。它的触发条件是发送方连续收到三个重复的确认号说明某个段大概率丢了但后续的段都到了。此时发送方立刻重发缺口那个段不用等超时。抓包里的特征是先出现若干个确认号完全相同的 ACK重复确认紧接着一个序号回退的段这个段被标注为快速重传。恢复速度比超时重传快得多通常只损失一个往返时间。选择性确认是配合重传来的。接收方在确认包里带上一个选项告诉发送方“我收到了哪几段”这样发送方就不用把缺口之后的所有段全部重发一遍只补缺口就行。抓包里看到确认包的选项区有“选择性确认”条目说明双方都支持这个能力。启用之后一次丢包往往只需要重传一个段而不是一大片这个差异在长肥管道上非常明显。5.3 乱序、零窗口、保活的识别乱序和丢包在抓包里看起来很像都会导致“序号跳跃”。区别在于乱序的段最终会到达只是顺序颠倒了分析器会把它标注为乱序而不是丢包真正丢了的段永远不会出现只能靠重传来补。判断方法是看后续有没有那个缺失序号的包有就是乱序没有就是丢包。乱序在链路存在多条路径时很常见实验里可以用中间设备人为制造。零窗口是接收方主动喊停。当接收缓冲被填满接收方在确认包里把窗口字段置零发送方看到之后必须停止发送进入持续探测状态定期发一个小包问“现在能收了吗”。抓包里表现为某个确认包的窗口值为 0之后一段时间内出现若干个载荷长度为 1 的探测包直到窗口恢复。这个现象在接收方处理速度跟不上发送方时非常典型做实验时可以故意让服务端读得慢一点来复现。保活报文则完全不同它是空闲连接的定期探测载荷通常为零或一字节序号是发送方已发送的最后一个字节减一。看到这种“不合常理”的序号别慌那是协议设计的刻意为之。6. 从窗口到吞吐量抓包能不能算出真实带宽这条连接最快能跑多少是实验里最有价值的结论之一。而这个结论不需要做压测光靠握手包和几个数据包就能估算出来。核心变量有三个接收窗口大小、往返时间、是否启用窗口缩放。三者组合起来就能算出一个理论上限再和实测吞吐对比差距大就说明有瓶颈。先把概念说清楚。窗口是接收方告诉发送方“我还能接收多少字节”发送方在收到确认之前最多只能发这么多。所以单位时间内能发多少取决于窗口多大除以一次往返需要多久。这个商就是吞吐上限。公式写出来很简单吞吐 窗口 / 往返时间。但实际要用的时候窗口要乘上缩放因子往返时间要从抓包里实测两个细节一错结果能差两个数量级。6.1 窗口缩放因子到底怎么算TCP 头里的窗口字段只有 16 位最大表示 65535 字节。这个值在上世纪八十年代够用放在今天千兆链路上就是瓶颈假设往返时间 40 毫秒65535 字节除以 0.04 秒只有约 13 Mbps链路再快也跑不上去。所以后来加了个选项允许双方在握手时协商一个移位因子实际窗口等于字段值左移这个因子位。这个因子是握手时双方各自在 SYN 和 SYN-ACK 里声明的约定俗成的取值上限是 14。计算方式很直接实际窗口 窗口字段值 × 2^因子。举例来说抓包里看到窗口字段 64240因子是 7那么实际可接收窗口就是 64240 × 128 8,222,720 字节约 7.8 MB。这个量级才能支撑起千兆链路上的长肥管道传输。需要注意的是因子只在握手阶段协商一次之后不变。而窗口字段值在每个确认包里都可能变化所以要算某个时刻的实际窗口必须用当时的字段值乘上握手时定下的因子不能混用。分析器的协议设置里有个选项可以自动做这个换算把缩放后的值直接显示出来省去手工乘法。做实验时建议开启避免算错。6.2 三步估算法与一个完整算例我常用的估算流程分三步。第一步从握手包里取出双方声明的窗口缩放因子确认是否启用。第二步找到连接稳定传输阶段中一个较大的窗口通告值乘以缩放系数得到实际窗口。第三步从抓包里量出往返时间用实际窗口除以往返时间得到吞吐上限。举个具体例子。假设某次实验抓到的握手包里客户端声明因子 7服务端声明因子 7稳定阶段某个确认包的窗口字段是 65535因子 7那么实际窗口是 65535 × 128 8,388,480 字节。再从抓包里量往返时间找到一个数据段和它对应的确认两者时间差 40 毫秒。那么理论上限就是 8,388,480 ÷ 0.04 209,712,000 字节每秒换算成比特要乘 8约 1.68 Gbps。这个数字只是上限实际能不能达到还取决于发送方的拥塞窗口和应用层供给速度。所以做实验时要同时看两个量接收窗口决定“对方能收多快”拥塞窗口决定“发送方敢发多快”两者取小才是实际速率。拥塞窗口在抓包里不直接显示但可以通过“在途字节数”间接观察任一时刻已发送但未确认的字节总量就是当前的发送窗口它不会超过拥塞窗口和接收窗口中的较小者。分析器的 TCP 流图里有一条“在途字节数”曲线看那条曲线在什么水平上稳定就知道实际生效的窗口是多大。另外一个常见算例是反过来的已知链路带宽和往返时间算需要多大窗口才能跑满。带宽 100 Mbps往返 20 毫秒那么管道容量是 100,000,000 ÷ 8 × 0.02 250,000 字节。也就是说窗口至少要 25 万字节才能填满这条管道。如果抓包里看到接收方只通告了 65535 字节那这条连接最多只能跑到约 26 Mbps链路再宽也没用。这类结论在排查“带宽上不去”的问题时特别有说服力。6.3 TCP Stream Graphs 该看哪几张图分析器自带的流图功能能把上面的计算可视化。我常看四张时间-序列号图横轴时间纵轴序号正常情况下是一条条斜向上的平行线斜率就是瞬时速率。出现水平段说明在等确认出现垂直段说明有重传。这张图最能一眼看出“卡在哪”。吞吐量图纵轴是单位时间字节数。看它的稳定平台在哪里和上面算出的理论上限对不对得上差多少。往返时间图每个数据段和它的确认之间的时间差。这条曲线的抖动程度直接反映链路质量突然抬高的位置往往对应队列积压或者路径切换。窗口缩放图把接收窗口和拥塞窗口随时间的变化画出来。看窗口是不是长期贴在小值上如果一直很小说明接收方应用读得慢不是网络问题。这四张图配合着看基本能在几分钟内给一条连接定性。做实验报告时把这几张图截下来比贴一堆报文列表有说服力得多。7. 排错实录实验里最容易翻车的几种情况这一节全是踩过的坑。有些问题看起来像协议故障实际上是工具环境的问题有些看起来像工具问题实际上是自己的过滤条件写错了。区分这两类很重要否则会把大量时间浪费在错误的方向上。7.1 抓不到包 / 只抓到半边只抓到单向流量是极常见的现象尤其在虚拟化环境和无线网络里。表现是你能看到发出的包看不到回来的包或者反过来。原因通常是抓包点的位置不对比如流量实际走了另一块网卡或者无线环境下部分管理帧被驱动过滤掉了。排查方法很朴素先看接口列表里每块网卡的实时流量计数哪个在涨就抓哪个。如果所有网卡都不涨但应用确实在通信那大概率走了回环去抓回环接口。还有一种情况是抓到了包但被显示过滤藏起来了清空过滤栏再确认一次。另一个隐性原因是时间。如果两台机器的时钟不同步你又把两个抓包文件合并分析就会看到确认包早于数据包这种荒谬的时序。做多机实验前务必校时或者至少记录下各机器的时钟偏差。7.2 校验和报错的真相满屏“校验和错误”是新手最容易慌的。前面提过这通常是网卡的卸载计算导致的抓包发生在硬件计算校验和之前所以字段里是错的或者空的。判断方法很直接如果几乎所有包都报同一个错误而且链路工作正常那基本就是卸载问题不是真故障。处理方式有两种。彻底一点的是在系统层面关闭该网卡的校验和卸载功能让软件来计算这样抓到的包校验和就是对的。省事一点的是在分析器的协议设置里关掉校验和验证眼不见为净。我做实验时选前者因为关掉验证之后万一真有校验和错误也发现不了等于自废一项检查能力。顺带说一下 TCP 分段卸载。开启之后抓包库里看到的可能是远大于最大段长度的“巨包”因为分段还没发生。这类包在分析器里会显示为一个超大的 TCP 段序号分析也会跟着乱。同样通过关闭网卡卸载功能解决。7.3 显示与解析层面的假象还有一类问题纯属显示层的误导。比如分析器默认开启 TCP 重组会把多个小段拼成一个完整应用层消息显示这时候你看到的“一个包”其实是多个包拼出来的序号分析要以原始分段为准。排查重传问题时建议临时关掉重组看最原始的段。再比如时间显示格式。默认是相对本次抓包开始的秒数看起来是 0.001、0.002 这种小数字容易误以为是绝对时间。分析长连接时切换到“当天时间”格式更直观定位“几点几分出的问题”更快。最后一类假象来自分析器的启发式标注。它对“乱序”和“丢包”的判断是基于启发式规则的在某些场景下会误判比如超时重传和乱序重传难以区分。遇到标注和实际不符时不要盲信标签回到序号和时间的原始数据自己推一遍。8. 把实验报告写成能交付的东西做完分析不等于完成任务能不能把结论清楚地交付出去才是。我见过太多实验记录通篇是报文字段截图最后一句“分析完毕”看的人完全不知道结论是什么。一份有价值的记录应该让没参与实验的人也能顺着读下来并且能复现你的操作。报告里最关键的不是截图数量而是结论和证据的对应关系。每一条结论后面都要跟一个能定位到具体报文的证据比如“窗口字段长期停留在 65535未启用缩放因此吞吐上限约 26 Mbps”证据是某个流编号下第几个包。这种写法别人能验证也经得起追问。8.1 一份分析记录的骨架我自己的记录固定分五块。第一块是实验目标与假设写清楚这次要看什么现象预期是什么。第二块是环境与抓包点写清楚在哪抓、什么时候开始、用了什么过滤条件这部分决定可复现性。第三块是关键报文摘录只贴和结论相关的包每个包标注它在流中的位置和作用。第四块是量化结论包括往返时间、窗口大小、重传次数、吞吐上限全部给数字。第五块是异常与未解释现象把没搞清楚的也记下来这块往往是最有价值的部分因为它指出了下一步要研究的方向。第三块最容易被写成流水账。控制方法是先想清楚结论再倒推需要哪几个包作为证据只贴这几个。一条连接几百个包真正需要展示的通常不超过十个。8.2 用命令行工具把手工活压到最低图形界面适合探索批量统计适合命令行。比如要统计所有连接里哪些出现了重传用一条命令就能把结果拉出来不用一条条点开看。基本套路是指定读取文件、用显示过滤表达式筛选、只输出需要的字段。tshark -r capture.pcapng \ -Y tcp.analysis.retransmission \ -T fields -e frame.number -e ip.src -e tcp.srcport -e tcp.dstport -e tcp.seq再比如要列出所有连接的首包快速了解这次抓包里到底有多少条独立会话tshark -r capture.pcapng \ -Y tcp.flags.syn 1 tcp.flags.ack 0 \ -T fields -e frame.number -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport需要把大文件按连接拆开时可以先提取流编号再逐条导出。这类批处理的好处是可重复换一份抓包文件命令原样再跑一遍结果格式完全一致方便横向对比。做多组对照实验时我基本都用这个方式生成汇总表最后再把少数几条典型连接拿到图形界面里做详细讲解。提示批处理输出的字段顺序、分隔符尽量固定下来并写进报告附录。别小看这个细节同一个人隔两周回来往往也记不住当时用的是哪套字段。我个人在实际操作中的体会是TCP 抓包实验真正的门槛从来不在语法和字段而在于“先想清楚要验证什么再去抓”。漫无目的地抓一大堆包然后盯着屏幕找异常是最低效的做法。反过来先写下三个具体问题比如“这条连接的窗口缩放谈成了多少”“握手耗时是不是异常”“重传是超时触发还是快速重传触发”带着问题去过滤、去定位通常十几分钟就能出结论。另一个小技巧是给自己建一个过滤器收藏夹把常用表达式按场景归类存好用的时候直接点比每次重新敲快得多也能避免手误打错字段名导致的误判。