很多学网络的朋友拿到TCP报文段首部格式第一反应是找一张字段表开始背源端口16位、序号32位、确认号32位……背完合上书又问抓包为什么还是看不懂我自己的经验是不要背字段把TCP报文段的首部当成一张按位布局的二进制地图。你只要知道每个字段占几位、为什么占这么多位看到一串十六进制也能当场推出来这是握手包还是数据包窗口多大协商的MSS是多少。这篇就按我实际抓包分析时的思路把TCP首部格式从头到尾拆一遍。适合刚学计算机网络基础的学生也适合日常跟网络抓包打交道的运维和开发。读完你会得到两个东西一个可以对照Wireshark逐字段核对的阅读方法一套遇到异常连接时快速看首部字段定位问题的习惯。1. 先建立整体认知为什么TCP首部从20字节起步1.1 最小20字节是怎么凑出来的TCP首部不是拍脑袋定的长度。TCP要独立于IP工作它必须自己携带足够信息来描述通信双方、字节流位置、控制标志和流量控制窗口。把这些信息排下来最低限度就是端口4字节、序号4字节、确认号4字节、数据偏移和标志位2字节、窗口2字节、校验和2字节、紧急指针2字节。加起来正好20字节也就是十六进制的0x14。这是所有TCP报文段的基准长度任何TCP包都不会小于这个值。为什么这些字段一个都不能少你可以把TCP首部想象成快递面单上的必填项源端口和目的端口是发件人和收件人电话序号和确认号是包裹编号和签收备注窗口是仓库容量寄存说明校验和是货品总价核验标志位是这票货是正常送达还是退回重发。少了任何一项快递都送不到手上TCP的可靠性、连接管理或流量控制机制就缺了一条腿。UDP不用这么复杂所以它的首部只有8字节但UDP也因此不负责可靠传输、不管理连接、不做流量控制——你拿8字节和20字节对比着看就能理解TCP牺牲带宽和头部开销换来的是什么能力。这里有个很实际的问题既然TCP首部可长可短协议栈怎么知道当前这个包的首部到底占多长靠的是第13字节的高4位也就是“数据偏移”字段。数据偏移的单位是4字节如果值是5就表示首部5×420字节如果值是15就表示首部15×460字节这是上限。后面我会专门展开这个字段先记住结论TCP首部长度介于20到60字节之间变化来自选项字段。1.2 头部长度为什么要用“数据偏移”表达“数据偏移”这个叫法容易让人困惑因为它其实是在说“首部长度”TCP首部后面紧跟数据这个字段告诉协议栈数据从哪里开始。为什么不直接叫“长度”因为TCP头长度不固定IP头长度也不固定IP首部里同样有一个IHL字段。协议设计者把“数据从第几个字开始”和“首部占几个字”看成同一个信息用偏移量来表达长度这样接收方解析时逻辑最简单先跳过IP头再跳过TCP头剩下的全是应用数据。关键的槽点是数据偏移只占4位最大是15但TCP最小首部是20字节。如果单位是1字节4位最多表示15字节根本不够用。所以设计单位必须放大最终选择了4字节。为什么是4字节而不是2字节或8字节因为整个TCP/IP协议栈从设计之初就强调32位对齐。IP头、TCP头都希望落在4字节边界上CPU读写内存时按32位访问最舒服协议栈在做内存拷贝和字段解析时也能省不少指令。4字节为单位还有一个好处20到60字节的长度区间用4位二进制就能完整表达不浪费位宽。从抓包的角度看数据偏移字段是解析TCP头时第一个要看的。Wireshark里显示为“Header Length: 32 bytes”其实就是把数据偏移值乘了4。我在实际排障中见过有人把20字节的普通ACK包读成32字节原因就是没注意数据偏移字段的值不是字节数而是“4字节块数”。20字节时值是532字节时值是8这两个数字很容易混淆后面常见误区里我会再提一次。2. 逐位拆开固定字段端口、序号与确认号2.1 端口字段16位容量与连接标识TCP首部最前面两个字段是源端口和目的端口各占16位。端口号范围0到65535这个上限完全由二进制位数决定2的16次方。设计者选16位在协议诞生年代是一个很自然的选择一个整数刚好两个字节不占空间而且几万个端口在当时的网络规模下完全够用。0到1023是知名端口比如80、443、22通常需要特权才能监听1024到49151是注册端口49152到65535是动态/临时端口客户端发起连接时一般从这里选一个源端口。端口字段和IP地址一起构成了连接标识的关键部分。一个TCP连接通常用四元组描述源IP、源端口、目的IP、目的端口严谨一点再加上协议编号就是五元组。这里有个非常常见的误解以为服务器监听80端口就只能处理一个连接。不对。服务器的监听端口80是固定的但每个连接还有客户端那一侧的源IP和源端口参与区分。所以一台服务器同时挂几万、几十万个80端口连接是完全正常的。反过来客户端机器做压力测试时经常遇到“端口不够用”的问题。一个客户端对外访问源IP是固定的可用的临时端口区间有限比如Linux默认的net.ipv4.ip_local_port_range通常是32768到60999也就两万多个端口。如果发起大量短连接并且不处理TIME_WAIT状态端口可能被迅速占满表现就是“Cannot assign requested address”。这不是TCP首部字段不够而是连接四元组的组合空间被临时端口区间限制住了。理解了端口16位和四元组的关系这类问题一眼就能定位。2.2 序号与确认号字节流协议的两根坐标轴TCP最核心的设计是把应用层数据看成一条连续的字节流而不是一堆独立的报文。这个视角直接决定了序号字段的语义。序号占32位表示“本报文段第一个数据字节在发送字节流中的编号”。初始序号不是0也不是1而是一个随机值叫ISN。为什么随机如果不随机攻击者可以通过预测序号来伪造TCP包、往连接里注入数据。现代操作系统生成ISN时会结合时间和加密算法让外界无法猜测。序号有一个特别容易忽略的规则SYN和FIN各消耗一个序号。这个规则从抓包里看最明显。客户端发SYN包假设seq1000这个包没有携带任何应用数据但服务器返回的ACK包的确认号必须是1001而不是1000。因为SYN本身占了一个字节的“逻辑位置”服务器期望客户端下一个发送的字节编号是1001。FIN包同理。很多人第一次抓包时看到带FIN的包比不带数据的包还多占一个序号会一脸疑惑其实这是TCP专门设计的目的就是让连接建立和释放过程也能参与可靠确认。确认号字段也是32位它的语义是“期望收到对端下一个字节的序号”。注意不是“最后收到的字节序号”。如果B返回ack2000意思是我已经收到1999以及之前所有字节现在请你从2000开始发。这种机制叫累计确认接收方不需要给每个包单独发确认只要把期望的下一字节序号报出来发送方就知道之前的数据全部到达了。一旦某一个包丢了接收方收到后面的乱序包时确认号会一直停在缺失位置发送方靠超时重传或者收到多个重复ACK来感知丢包触发快速重传。给一个具体的例子A发送seq2000payload是10字节B收到后返回ack2010。如果B把ack写成2000或者2009发送方就没法判断正确边界。所以抓包时看TCP信息栏里的Seq和Ack一定要结合相对序号理解Wireshark为了照顾人眼通常显示“relative sequence number”把ISN归零这样第一个SYN包显示Seq0后续包显示Seq1、11之类的相对值。实际线上排查跨设备抓包时一定要关掉相对序号看绝对序号否则两边各算各的根本对不上。2.3 数据偏移字段4位如何表达20到60字节数据偏移字段排在第13字节的高4位它的值是首部长度除以4。最小值是5对应20字节最大值是15对应60字节。前面说过为什么不是以字节为单位因为位数不够且要考虑32位对齐。这里再补充一个实用角度协议栈解析时看到数据偏移值是5就知道后面没有选项直接进入数据看到值是6或7就知道有4到8字节的选项需要解析。选项字段最多40字节加上固定20字节刚好60字节封顶这个设计把整个首部长度压进了一个4位字段里非常精巧。抓包验证也很直观。一个普通的TCP ACK包通常没有选项或者只有时间戳选项Header Length显示“20 bytes”或“32 bytes”。而SYN包因为要协商MSS、窗口缩放、SACK、时间戳Header Length经常是“44 bytes”或“60 bytes”。数据偏移字段的值和首部字节数之间的关系我是这样记的看到Wireshark里Header Length是44字节就立刻除以4得到11数据偏移字段的二进制就是1011。自己写协议解析器时从原始字节流里读这个值再乘4拿到真实长度千万别直接拿这个值当字节数用。3. 连接的控制中枢标志位、窗口与校验和3.1 标志位从6位经典标记到9位扩展标志位是TCP首部里最“热闹”的地方。经典教材会告诉你保留6位、标志位6位URG、ACK、PSH、RST、SYN、FIN。但你在Wireshark里看到的实际报文标志位往往不止6个还会有NS、CWR、ECE。这是后来RFC扩展的结果原本的保留位被拿出来一部分用于显式拥塞通知。所以严格来说现在的TCP头标志区是NS、CWR、ECE、URG、ACK、PSH、RST、SYN、FIN共9位保留位只剩3位。读老代码或者老文档看到“保留6位”不要奇怪那是当时的历史版本。这些标志位各自管什么我直接列一张表标志位置位含义URG紧急指针字段有效表示有紧急数据需要优先处理ACK确认号字段有效除SYN外几乎所有包都要置位PSH接收方应尽快把数据交给应用层不要等在缓冲区里RST异常重置连接常见于端口未监听、协议异常SYN同步序号用于建立连接FIN发送方数据发送完毕请求释放连接CWR发送端已降低发送速率回应ECE通知ECE接收端反馈网络出现拥塞通知对端降速NSECN机制里的随机数校验位普通排障很少关心三次握手在标志位上的表现是客户端发SYN服务器回SYNACK客户端再回ACK。四次挥手则是A发FINB回ACKB再发FINA回ACK。RST最特殊它不是正常流程而是随时可能出现的“中断开关”你访问一个没人监听的端口对方内核直接回RST中间设备发现连接非法也可能注入RST。抓包时看到RST不要慌先看带没带ACK再看序号对不对这是后面排障一节的重点。PSH标志值得一提因为它经常被误解。老教材说“PSH表示立即上送应用层”实际现代协议栈几乎不依赖PSH来决定交付时机因为TCP默认就会按序把数据交给应用。PSH更多是发送端提示“这段数据请别攒着”常见于交互式协议里比如SSH。你抓SSH流量会看到大量PSHACK包但HTTP大文件下载里PSH很少。这个标志对普通应用的影响没有教科书渲染的那么大。3.2 窗口字段16位上限与窗口缩放窗口字段占16位最大65535含义是“接收方当前还能接收的字节数”即通告窗口。它属于流量控制接收方根据自己缓冲区剩余空间告诉发送方“你最多再发这么多多了装不下”。发送方收到这个值后把当前未确认的数据量控制在窗口范围内就不会把接收方缓冲区撑爆。很多人在这一步犯迷糊窗口字段和拥塞控制有什么关系其实TCP首部里根本没有拥塞窗口字段拥塞窗口是发送方自己维护的状态变量不随报文传输。通告窗口是接收方告诉发送方“别超过我的容量”解决的是两端处理速度不匹配拥塞窗口是发送方探测网络能承载多少数据解决的是链路中间节点的承载能力。两个窗口取较小值才决定实际发送速度。问题来了65535字节的窗口上限在1981年很够用但在今天的网络环境下远远不够。拿10Gbps链路举例RTT如果是20毫秒带宽时延积大约是10Gbps×0.02s25MB。窗口只有64KB时即使链路再宽发送方也只能每200毫秒发64KB数据吞吐被死死摁在不到3Mbps。所以TCP后来增加了窗口缩放选项用一个shift count0到14把16位窗口值左移实际窗口窗口字段值×2^shift。比如窗口字段是64240缩放因子是7实际通告窗口就是64240×128≈8.22MB。Wireshark显示的“Calculated window size”就是做了这个换算之后的值。抓包时一定要关注窗口缩放。两端在握手SYN包中互相通告自己的缩放因子如果有一方不支持另一方就默认不用缩放窗口就退回64KB上限。我曾经在某个跨平台系统的对接里遇过吞吐上不去的问题两边带宽都很足抓包一看一端SYN包里没有窗口缩放选项而另一端通告的窗口高达数MB协商失败后实际窗口按64KB处理吞吐自然起不来。这类问题只看Window字段不看缩放因子是永远找不到原因的。3.3 校验和别忽略那个“伪首部”校验和字段16位作用是检测TCP首部和数据在传输过程中有没有损坏。但TCP校验和覆盖的范围比你想的大得多它不只是计算TCP首部而是计算三块内容12字节的伪首部、TCP首部、TCP数据。伪首部由源IP、目的IP、保留0字节、协议编号IPv4下是6、TCP报文段总长度组成最关键的是伪首部只参与计算不会真的随包发送。为什么要把IP层的信息拉进来算校验和因为TCP校验和不仅要保护自己这段内容还要防止IP层把包投错地方。如果源IP、目的IP或者协议号在传输中被改错了接收方的TCP校验和就会对不上从而丢弃这个包。这相当于让TCP给IP层也做了一层完整性兜底。IPv6下的伪首部更长包含更多地址位和下一个头字段原理完全一样。Linux内核里计算校验和时会通过一个辅助函数把伪首部拼接进来从协议栈实现角度这个设计增加了代码复杂度但换来了跨层的完整性保护。计算过程很简单发送方先把校验和字段置0然后把整个覆盖范围按16位一组划分不足16位的尾部补0对每一组做反码求和最后把和取反写入校验和字段。接收方收到后对同样的范围再做一次同样计算结果应该是全10xFFFF否则说明包在传输中损坏直接丢弃。这个算法在CPU上做起来极快现代网卡还支持硬件计算卸载。我在看协议栈代码时最喜欢提醒别人计算范围里那个伪首部是TCP校验和容易写错的地方自己手写解析器只按TCP段算校验和算出来永远是错。4. 选项字段可变部分才是现代TCP真正厉害的地方4.1 常见选项速览MSS、窗口缩放、SACK与时间戳固定20字节只能保证TCP“能工作”要跑出高性能全靠选项字段。选项位于固定首部之后、数据之前总长最多40字节每个选项由“类型长度值”组成某些填充选项只有一个字节。我把抓包时最常见的几个选项整理成一张表选项类型名称长度作用1NOP1字节空填充用于32位对齐2MSS4字节协商最大报文段长度3Window Scale3字节通告窗口缩放因子范围0到144SACK-Permitted2字节表示本端支持选择性确认5SACK可变88n字节报告收到的不连续数据段8Timestamp10字节测量RTT并防止序号回绕NOP是最不起眼却最常用的选项它的作用纯粹是占位。因为TCP要求选项整体按4字节边界对齐如果前面几个选项加起来的长度不是4的倍数就用NOP把尾巴补齐。比如MSS选项4字节、SACK-Permitted选项2字节这俩加起来6字节后面通常就跟一个NOP再加时间戳10字节凑成16字节。Wireshark里显示为一串“NOP, NOP”的包就是对齐用的不用在意。MSS选项每次握手都会出现它表示本端能接受的最大TCP数据段长度。标准以太网环境下MSS通常协商为1460这个数字怎么来的以太网MTU是1500字节减去IPv4首部20字节再减TCP首部20字节剩余数据最多就是1460。如果中间链路MTU是1400MSS就会变成相应较小的值。SYN包里的MSS是“提议值”接收方会在自己的MSS和对方的MSS里取较小者作为这条连接的实际发送上限。所以抓包看到两端MSS不一致很正常实际生效的是小值。4.2 选项协商如何影响大流量传输窗口缩放、SACK和时间戳这三个选项直接决定了一条TCP连接能不能在长肥网络高带宽、高延迟上跑出吞吐。先看时间戳它有两个值TSval和TSecr发送方在包里放当前时间接收方原样回显发送方就能算出精确的RTT。同时时间戳还能防止序号回绕带来的歧义——32位序号在高速链路上很快绕一圈比如10Gbps下大约每3.4秒就回绕一次如果没有时间戳接收方很难区分旧包和新包。SACK的作用是解决“一个包丢了一堆后续包跟着遭殃”的问题。传统累计确认下如果接收方收到100到199和300到399的数据但丢了200到299这一段它只能反复确认“下一个期望是200”发送方要等到超时才知道到底该重传哪些。开启了SACK之后接收方可以明确告诉发送方“我收到了100-199和300-399缺口在200-299”发送方只重传缺口部分效率提升非常明显。所以在抓包时看到一个SYN包里带SACK-Permitted基本可以判断这条连接对丢包有不错的恢复能力。窗口缩放和这三个选项必须都在三次握手阶段协商完成这解释了为什么抓包时SYN包总是带着一堆选项。如果任一方没有在SYN包里通告某个能力后续就不允许再使用。这也是TCP“端到端协商”思想的一个体现双方能力不同、路径条件不同必须在连接建立时就把约束谈好之后数据传得再快也不能突破协商结果。我建议每个做网络性能排查的人都养成一个习惯先看握手阶段的SYN包选项就能提前判断这条连接的上限。如果SYN里MSS是1460、窗口缩放是7、SACK和时间戳齐全这条连接的底子就是好的如果某个选项缺失后面出现吞吐异常、乱序重传高企就有了解释方向。5. 实操验证用抓包把首部格式“解剖”一遍5.1 抓包准备与过滤表达式纸上谈兵讲再多不如自己抓一个包看一眼。准备一台能联网的机器安装Wireshark或者用命令行工具tcpdump也可以。抓本机回环流量最简单因为不需要过滤网卡混杂模式权限也容易满足。先开着终端抓包再在浏览器里访问一个普通网站就能看到完整的TCP三次握手。最常用的tcpdump命令是这样sudo tcpdump -i eth0 -nn tcp port 443 -c 10如果想把原始报文保存下来放到Wireshark里慢慢看加一个-w参数sudo tcpdump -i eth0 -nn -w /tmp/tcp.pcap tcp port 443在Wireshark里打开文件后过滤表达式按需求写。只想看TCP包就输入tcp想只看SYN包输入tcp.flags.syn 1只看出站方向的SYN包再叠加一个条件tcp.flags.syn 1 tcp.flags.ack 0。这个组合过滤很关键因为SYNACK包同时满足syn1和ack1如果你只看syn1会把服务端的响应也混进来。正确的是用“syn1且ack0”表达“主动发起连接的包”用“syn1且ack1”表达“被动确认并同步的包”。抓包时要注意一个细节在Wireshark里看到的TCP信息栏是一行摘要默认显示相对序号、相对确认号还会自动算出窗口大小。这些信息非常方便但如果你想练解读首部的硬功夫建议右键选择“Protocol Preferences”里关掉相对序号或者直接看原始字节流。Wireshark底下有Hex pane把光标点到TCP头部就能逐字节看到十六进制和对应的字段高亮。这一块的联动是搞懂首部格式的最佳练习场。5.2 一个SYN包的逐字段对照我拿一个典型的出站SYN包作为例子把它展开成一张表格。为了描述方便我们假设客户端用端口52000访问服务器的443端口源IP和目的IP用文档专用的保留地址段不影响理解。字段抓包显示值解读Source Port52000客户端临时分配的源端口Destination Port443HTTPS服务端口Sequence Number相对值0一个随机ISN的起始位置Header Length44 bytes数据偏移字段值是11Flags0x002只有SYN置位没有ACKWindow64240接收缓冲区通告值Checksum0x8f5e发送方计算后的校验值[MSS]1460本端建议的最大段长度[Window Scale]7实际窗口左移7位[SACK Permitted]True支持选择性确认[Timestamp]TSval..., TSecr0首次握手没有回显值为什么Header Length是44字节固定首部20字节加上MSS选项4字节、Window Scale选项3字节、SACK-Permitted选项2字节、时间戳选项10字节几个数字加起来4321019字节不是4的倍数于是中间插入若干NOP填充凑成20字节的选项区最后固定202044字节。你从原始十六进制里看数据偏移字段的值应该是11也就是二进制1011。再看Flags的值0x002是怎么来的。TCP标志字段按位展开从高位到低位依次是NS、CWR、ECE、URG、ACK、PSH、RST、SYN、FIN。SYN位处在倒数第二位对应的二进制权值是0x02ACK位权值是0x10。所以一个纯SYN包的flags显示为0x002一个SYNACK包显示为0x012一个纯ACK包显示为0x010。记住这个位权表你在十六进制里看到一个0x012立刻能反应出这是握手的第二个包不需要把鼠标悬停在Wireshark的Flags字段上。5.3 从首部字段快速定位握手异常实际排障中抓包不是看热闹而是要在几秒内判断连接卡在哪一步。我总结了一套看首部的顺序先看Flags确认这是哪个阶段的包再看Seq和Ack确认双方序号是否对得上然后看窗口和选项判断性能上限最后才看IP层有没有丢包。最常见的场景是“只看到出站SYN没看到SYNACK”。这有两种可能要么SYN包根本没到对方要么对方回了但回包被防火墙丢掉。这时候看SYN包的重传情况TCP会重传SYN第一次约1秒后重试指数退避。如果多次重传都石沉大海多半是路径上有设备静默丢包或者目的端口根本没监听。可以用tcpdump在服务器侧同时抓包一眼就能判断是入向丢还是出向丢。这个“两端同时抓包对照”的操作比在客户端单侧猜半天高效得多。再一种场景是握手完成了但连接立刻被RST干掉。这时要看RST包的序号和确认号。如果RST.ACK1并且确认号是对方期望的正确值说明是服务器主动拒绝——端口未监听、应用层拒绝或安全策略未通过如果RST包的ACK标志为0且序号很诡异很可能是中间设备伪造注入的reset用来干扰连接。这两种情况处理思路完全不同前者查应用和防火墙策略后者要排查链路设备是否有流清洗策略。判断依据都在首部那几位标志里熟悉了就不用瞎猜。6. 常见问题与排障经验实录6.1 首部字段速查表把TCP首部所有字段汇总成一张速查表排查时可以直接对照。注意这里列出的字节位置是从TCP头起始处计算的不是从IP头起始处。字节范围字段位数作用与常见值0-1源端口16客户端临时端口常见32768-609992-3目的端口16服务监听端口如80、4434-7序号32第一个数据字节的流位置SYN/FIN各占一个序号8-11确认号32期望收到的下一个字节序号累计确认12数据偏移4首部长度/4最小5最大1512保留位3目前保留未用通常为012-13标志位9NS、CWR、ECE、URG、ACK、PSH、RST、SYN、FIN14-15窗口16接收方通告窗口实际值需结合缩放因子16-17校验和16覆盖伪首部TCP首部数据18-19紧急指针16URG1时指向紧急数据末尾20-59选项0-40常见MSS、窗口缩放、SACK、时间戳等这张表建议打印出来放在手边比任何时候去翻RFC都快。我自己早年做协议接入时用的就是一张类似的纸质表每看一个十六进制字节就按表查一次半个月后所有字段位置就烂熟于心了。初学者不用追求一次背下来先能看懂Wireshark里的字段和这张表的对应关系就已经赢了一半。6.2 最容易踩的5个误区误区一确认号表示“已经收到的最后一个字节号”。错确认号是“期望收到的下一个字节号”。如果我收到0到199字节确认为200而不是199。这个区别在抓包时非常明显尤其是配合SYN占一个序号来看很多人第一次看到SYN包后回应的ack是x1会以为服务器多确认了一个字节其实那就是规则本身。误区二数据偏移字段的值就是首部字节数。错它是4字节块数。值5对应20字节值11对应44字节。因为20字节的首部恰好对应值5导致不少人误以为这个字段就是字节数直到遇到带选项的包才露出马脚。自己解析包时一定先用data_offset*4得到真实长度再看数据从哪开始。误区三TCP校验和只算TCP首部。错它要算伪首部、TCP首部和数据三部分。伪首部里的源IP和目的IP来自IP层协议号固定为6。这也是为什么你不能把TCP段单独拎出来就算校验和必须结合IP头信息。自己做抓包工具时最容易踩的就是这个坑。误区四窗口字段就是实际接收能力。错还要看窗口缩放因子。窗口缩放协商在握手阶段完成如果对端没有通告缩放因子窗口上限就是65535字节即使本地缓冲区再大也没用。抓包看到的“Calculated window size”才是协商后的真实值。误区五只有数据包才消耗序号。错SYN包和FIN包各占一个序号。很多初学者看三次握手的第二个包不理解为什么ack是seq1而不是seq就是因为没把SYN看成“占了一个字节”的逻辑实体。四次挥手时FIN同理最后一个ACK的确认号也要在FIN序号上加1。6.3 实际排障中的一条经验线排障经验这东西讲一堆不如给一条可复用的操作线。我自己处理TCP连接问题时的习惯是抓包后先不看IP直接看TCP首部。第一眼看Flags判断当前抓到的包是握手的第几个、挥手状态、还是异常RST第二眼看相对序号和确认号把双向的序号线画出来确认没有序号跳变第三眼看MSS和窗口缩放选项评估这条连接的性能上限最后才结合IP层确认丢包和RTT。举个例子我曾经调一个跨平台系统的对接问题现象是文件传输总是中断从应用层日志看不出原因。抓包一看三次握手正常数据发送阶段接收窗口一路上涨然后突然变成0窗口字段更新为0发送方就停下来了。再往后接收方重新发了窗口更新包但发送方没反应最终超时重传。这一串现象问题其实不在TCP首部本身而是接收方的应用层没有及时消费数据缓冲区满了触发了TCP的流量控制。但如果不是先看懂窗口字段和标志位我根本没法把“窗口变成0”和“应用层读太慢”这件事关联起来。还有一次是服务器回包一切正常但客户端始终报连接超时。两端同时抓包后发现服务器发出的SYNACK包在某个中间节点被改了MSS值这属于中间设备篡改TCP选项的典型案例。如果只看客户端侧抓包只会看到“发了很多SYN一直没响应”永远找不到根因。后来我们在服务器侧也抓了一份一对标志位和序号很快锁定了路径上的设备。所以我想强调的排障经验就是TCP首部格式不是考试用的背诵题而是一套现场勘查工具。遇到网络问题先把首部字段按顺序读一遍大多数问题的方向就清楚了。最后再分享一个小技巧抓包时保留完整报文长度不要用-s 0截断看首部格式一定要开“Relative sequence numbers”之外的绝对序号视角分析结束后记得保存为pcapng格式并附上过滤条件。把读首部变成习惯你再看网络问题就不再是玄学而是一行行可以验证的二进制事实。 
长河君 · 2026/10/20 4:37:13 · 阅读 1.2k TCP首部格式详解：从抓包到排障的完整拆解
很多学网络的朋友拿到TCP报文段首部格式第一反应是找一张字段表开始背源端口16位、序号32位、确认号32位……背完合上书又问抓包为什么还是看不懂我自己的经验是不要背字段把TCP报文段的首部当成一张按位布局的二进制地图。你只要知道每个字段占几位、为什么占这么多位看到一串十六进制也能当场推出来这是握手包还是数据包窗口多大协商的MSS是多少。这篇就按我实际抓包分析时的思路把TCP首部格式从头到尾拆一遍。适合刚学计算机网络基础的学生也适合日常跟网络抓包打交道的运维和开发。读完你会得到两个东西一个可以对照Wireshark逐字段核对的阅读方法一套遇到异常连接时快速看首部字段定位问题的习惯。1. 先建立整体认知为什么TCP首部从20字节起步1.1 最小20字节是怎么凑出来的TCP首部不是拍脑袋定的长度。TCP要独立于IP工作它必须自己携带足够信息来描述通信双方、字节流位置、控制标志和流量控制窗口。把这些信息排下来最低限度就是端口4字节、序号4字节、确认号4字节、数据偏移和标志位2字节、窗口2字节、校验和2字节、紧急指针2字节。加起来正好20字节也就是十六进制的0x14。这是所有TCP报文段的基准长度任何TCP包都不会小于这个值。为什么这些字段一个都不能少你可以把TCP首部想象成快递面单上的必填项源端口和目的端口是发件人和收件人电话序号和确认号是包裹编号和签收备注窗口是仓库容量寄存说明校验和是货品总价核验标志位是这票货是正常送达还是退回重发。少了任何一项快递都送不到手上TCP的可靠性、连接管理或流量控制机制就缺了一条腿。UDP不用这么复杂所以它的首部只有8字节但UDP也因此不负责可靠传输、不管理连接、不做流量控制——你拿8字节和20字节对比着看就能理解TCP牺牲带宽和头部开销换来的是什么能力。这里有个很实际的问题既然TCP首部可长可短协议栈怎么知道当前这个包的首部到底占多长靠的是第13字节的高4位也就是“数据偏移”字段。数据偏移的单位是4字节如果值是5就表示首部5×420字节如果值是15就表示首部15×460字节这是上限。后面我会专门展开这个字段先记住结论TCP首部长度介于20到60字节之间变化来自选项字段。1.2 头部长度为什么要用“数据偏移”表达“数据偏移”这个叫法容易让人困惑因为它其实是在说“首部长度”TCP首部后面紧跟数据这个字段告诉协议栈数据从哪里开始。为什么不直接叫“长度”因为TCP头长度不固定IP头长度也不固定IP首部里同样有一个IHL字段。协议设计者把“数据从第几个字开始”和“首部占几个字”看成同一个信息用偏移量来表达长度这样接收方解析时逻辑最简单先跳过IP头再跳过TCP头剩下的全是应用数据。关键的槽点是数据偏移只占4位最大是15但TCP最小首部是20字节。如果单位是1字节4位最多表示15字节根本不够用。所以设计单位必须放大最终选择了4字节。为什么是4字节而不是2字节或8字节因为整个TCP/IP协议栈从设计之初就强调32位对齐。IP头、TCP头都希望落在4字节边界上CPU读写内存时按32位访问最舒服协议栈在做内存拷贝和字段解析时也能省不少指令。4字节为单位还有一个好处20到60字节的长度区间用4位二进制就能完整表达不浪费位宽。从抓包的角度看数据偏移字段是解析TCP头时第一个要看的。Wireshark里显示为“Header Length: 32 bytes”其实就是把数据偏移值乘了4。我在实际排障中见过有人把20字节的普通ACK包读成32字节原因就是没注意数据偏移字段的值不是字节数而是“4字节块数”。20字节时值是532字节时值是8这两个数字很容易混淆后面常见误区里我会再提一次。2. 逐位拆开固定字段端口、序号与确认号2.1 端口字段16位容量与连接标识TCP首部最前面两个字段是源端口和目的端口各占16位。端口号范围0到65535这个上限完全由二进制位数决定2的16次方。设计者选16位在协议诞生年代是一个很自然的选择一个整数刚好两个字节不占空间而且几万个端口在当时的网络规模下完全够用。0到1023是知名端口比如80、443、22通常需要特权才能监听1024到49151是注册端口49152到65535是动态/临时端口客户端发起连接时一般从这里选一个源端口。端口字段和IP地址一起构成了连接标识的关键部分。一个TCP连接通常用四元组描述源IP、源端口、目的IP、目的端口严谨一点再加上协议编号就是五元组。这里有个非常常见的误解以为服务器监听80端口就只能处理一个连接。不对。服务器的监听端口80是固定的但每个连接还有客户端那一侧的源IP和源端口参与区分。所以一台服务器同时挂几万、几十万个80端口连接是完全正常的。反过来客户端机器做压力测试时经常遇到“端口不够用”的问题。一个客户端对外访问源IP是固定的可用的临时端口区间有限比如Linux默认的net.ipv4.ip_local_port_range通常是32768到60999也就两万多个端口。如果发起大量短连接并且不处理TIME_WAIT状态端口可能被迅速占满表现就是“Cannot assign requested address”。这不是TCP首部字段不够而是连接四元组的组合空间被临时端口区间限制住了。理解了端口16位和四元组的关系这类问题一眼就能定位。2.2 序号与确认号字节流协议的两根坐标轴TCP最核心的设计是把应用层数据看成一条连续的字节流而不是一堆独立的报文。这个视角直接决定了序号字段的语义。序号占32位表示“本报文段第一个数据字节在发送字节流中的编号”。初始序号不是0也不是1而是一个随机值叫ISN。为什么随机如果不随机攻击者可以通过预测序号来伪造TCP包、往连接里注入数据。现代操作系统生成ISN时会结合时间和加密算法让外界无法猜测。序号有一个特别容易忽略的规则SYN和FIN各消耗一个序号。这个规则从抓包里看最明显。客户端发SYN包假设seq1000这个包没有携带任何应用数据但服务器返回的ACK包的确认号必须是1001而不是1000。因为SYN本身占了一个字节的“逻辑位置”服务器期望客户端下一个发送的字节编号是1001。FIN包同理。很多人第一次抓包时看到带FIN的包比不带数据的包还多占一个序号会一脸疑惑其实这是TCP专门设计的目的就是让连接建立和释放过程也能参与可靠确认。确认号字段也是32位它的语义是“期望收到对端下一个字节的序号”。注意不是“最后收到的字节序号”。如果B返回ack2000意思是我已经收到1999以及之前所有字节现在请你从2000开始发。这种机制叫累计确认接收方不需要给每个包单独发确认只要把期望的下一字节序号报出来发送方就知道之前的数据全部到达了。一旦某一个包丢了接收方收到后面的乱序包时确认号会一直停在缺失位置发送方靠超时重传或者收到多个重复ACK来感知丢包触发快速重传。给一个具体的例子A发送seq2000payload是10字节B收到后返回ack2010。如果B把ack写成2000或者2009发送方就没法判断正确边界。所以抓包时看TCP信息栏里的Seq和Ack一定要结合相对序号理解Wireshark为了照顾人眼通常显示“relative sequence number”把ISN归零这样第一个SYN包显示Seq0后续包显示Seq1、11之类的相对值。实际线上排查跨设备抓包时一定要关掉相对序号看绝对序号否则两边各算各的根本对不上。2.3 数据偏移字段4位如何表达20到60字节数据偏移字段排在第13字节的高4位它的值是首部长度除以4。最小值是5对应20字节最大值是15对应60字节。前面说过为什么不是以字节为单位因为位数不够且要考虑32位对齐。这里再补充一个实用角度协议栈解析时看到数据偏移值是5就知道后面没有选项直接进入数据看到值是6或7就知道有4到8字节的选项需要解析。选项字段最多40字节加上固定20字节刚好60字节封顶这个设计把整个首部长度压进了一个4位字段里非常精巧。抓包验证也很直观。一个普通的TCP ACK包通常没有选项或者只有时间戳选项Header Length显示“20 bytes”或“32 bytes”。而SYN包因为要协商MSS、窗口缩放、SACK、时间戳Header Length经常是“44 bytes”或“60 bytes”。数据偏移字段的值和首部字节数之间的关系我是这样记的看到Wireshark里Header Length是44字节就立刻除以4得到11数据偏移字段的二进制就是1011。自己写协议解析器时从原始字节流里读这个值再乘4拿到真实长度千万别直接拿这个值当字节数用。3. 连接的控制中枢标志位、窗口与校验和3.1 标志位从6位经典标记到9位扩展标志位是TCP首部里最“热闹”的地方。经典教材会告诉你保留6位、标志位6位URG、ACK、PSH、RST、SYN、FIN。但你在Wireshark里看到的实际报文标志位往往不止6个还会有NS、CWR、ECE。这是后来RFC扩展的结果原本的保留位被拿出来一部分用于显式拥塞通知。所以严格来说现在的TCP头标志区是NS、CWR、ECE、URG、ACK、PSH、RST、SYN、FIN共9位保留位只剩3位。读老代码或者老文档看到“保留6位”不要奇怪那是当时的历史版本。这些标志位各自管什么我直接列一张表标志位置位含义URG紧急指针字段有效表示有紧急数据需要优先处理ACK确认号字段有效除SYN外几乎所有包都要置位PSH接收方应尽快把数据交给应用层不要等在缓冲区里RST异常重置连接常见于端口未监听、协议异常SYN同步序号用于建立连接FIN发送方数据发送完毕请求释放连接CWR发送端已降低发送速率回应ECE通知ECE接收端反馈网络出现拥塞通知对端降速NSECN机制里的随机数校验位普通排障很少关心三次握手在标志位上的表现是客户端发SYN服务器回SYNACK客户端再回ACK。四次挥手则是A发FINB回ACKB再发FINA回ACK。RST最特殊它不是正常流程而是随时可能出现的“中断开关”你访问一个没人监听的端口对方内核直接回RST中间设备发现连接非法也可能注入RST。抓包时看到RST不要慌先看带没带ACK再看序号对不对这是后面排障一节的重点。PSH标志值得一提因为它经常被误解。老教材说“PSH表示立即上送应用层”实际现代协议栈几乎不依赖PSH来决定交付时机因为TCP默认就会按序把数据交给应用。PSH更多是发送端提示“这段数据请别攒着”常见于交互式协议里比如SSH。你抓SSH流量会看到大量PSHACK包但HTTP大文件下载里PSH很少。这个标志对普通应用的影响没有教科书渲染的那么大。3.2 窗口字段16位上限与窗口缩放窗口字段占16位最大65535含义是“接收方当前还能接收的字节数”即通告窗口。它属于流量控制接收方根据自己缓冲区剩余空间告诉发送方“你最多再发这么多多了装不下”。发送方收到这个值后把当前未确认的数据量控制在窗口范围内就不会把接收方缓冲区撑爆。很多人在这一步犯迷糊窗口字段和拥塞控制有什么关系其实TCP首部里根本没有拥塞窗口字段拥塞窗口是发送方自己维护的状态变量不随报文传输。通告窗口是接收方告诉发送方“别超过我的容量”解决的是两端处理速度不匹配拥塞窗口是发送方探测网络能承载多少数据解决的是链路中间节点的承载能力。两个窗口取较小值才决定实际发送速度。问题来了65535字节的窗口上限在1981年很够用但在今天的网络环境下远远不够。拿10Gbps链路举例RTT如果是20毫秒带宽时延积大约是10Gbps×0.02s25MB。窗口只有64KB时即使链路再宽发送方也只能每200毫秒发64KB数据吞吐被死死摁在不到3Mbps。所以TCP后来增加了窗口缩放选项用一个shift count0到14把16位窗口值左移实际窗口窗口字段值×2^shift。比如窗口字段是64240缩放因子是7实际通告窗口就是64240×128≈8.22MB。Wireshark显示的“Calculated window size”就是做了这个换算之后的值。抓包时一定要关注窗口缩放。两端在握手SYN包中互相通告自己的缩放因子如果有一方不支持另一方就默认不用缩放窗口就退回64KB上限。我曾经在某个跨平台系统的对接里遇过吞吐上不去的问题两边带宽都很足抓包一看一端SYN包里没有窗口缩放选项而另一端通告的窗口高达数MB协商失败后实际窗口按64KB处理吞吐自然起不来。这类问题只看Window字段不看缩放因子是永远找不到原因的。3.3 校验和别忽略那个“伪首部”校验和字段16位作用是检测TCP首部和数据在传输过程中有没有损坏。但TCP校验和覆盖的范围比你想的大得多它不只是计算TCP首部而是计算三块内容12字节的伪首部、TCP首部、TCP数据。伪首部由源IP、目的IP、保留0字节、协议编号IPv4下是6、TCP报文段总长度组成最关键的是伪首部只参与计算不会真的随包发送。为什么要把IP层的信息拉进来算校验和因为TCP校验和不仅要保护自己这段内容还要防止IP层把包投错地方。如果源IP、目的IP或者协议号在传输中被改错了接收方的TCP校验和就会对不上从而丢弃这个包。这相当于让TCP给IP层也做了一层完整性兜底。IPv6下的伪首部更长包含更多地址位和下一个头字段原理完全一样。Linux内核里计算校验和时会通过一个辅助函数把伪首部拼接进来从协议栈实现角度这个设计增加了代码复杂度但换来了跨层的完整性保护。计算过程很简单发送方先把校验和字段置0然后把整个覆盖范围按16位一组划分不足16位的尾部补0对每一组做反码求和最后把和取反写入校验和字段。接收方收到后对同样的范围再做一次同样计算结果应该是全10xFFFF否则说明包在传输中损坏直接丢弃。这个算法在CPU上做起来极快现代网卡还支持硬件计算卸载。我在看协议栈代码时最喜欢提醒别人计算范围里那个伪首部是TCP校验和容易写错的地方自己手写解析器只按TCP段算校验和算出来永远是错。4. 选项字段可变部分才是现代TCP真正厉害的地方4.1 常见选项速览MSS、窗口缩放、SACK与时间戳固定20字节只能保证TCP“能工作”要跑出高性能全靠选项字段。选项位于固定首部之后、数据之前总长最多40字节每个选项由“类型长度值”组成某些填充选项只有一个字节。我把抓包时最常见的几个选项整理成一张表选项类型名称长度作用1NOP1字节空填充用于32位对齐2MSS4字节协商最大报文段长度3Window Scale3字节通告窗口缩放因子范围0到144SACK-Permitted2字节表示本端支持选择性确认5SACK可变88n字节报告收到的不连续数据段8Timestamp10字节测量RTT并防止序号回绕NOP是最不起眼却最常用的选项它的作用纯粹是占位。因为TCP要求选项整体按4字节边界对齐如果前面几个选项加起来的长度不是4的倍数就用NOP把尾巴补齐。比如MSS选项4字节、SACK-Permitted选项2字节这俩加起来6字节后面通常就跟一个NOP再加时间戳10字节凑成16字节。Wireshark里显示为一串“NOP, NOP”的包就是对齐用的不用在意。MSS选项每次握手都会出现它表示本端能接受的最大TCP数据段长度。标准以太网环境下MSS通常协商为1460这个数字怎么来的以太网MTU是1500字节减去IPv4首部20字节再减TCP首部20字节剩余数据最多就是1460。如果中间链路MTU是1400MSS就会变成相应较小的值。SYN包里的MSS是“提议值”接收方会在自己的MSS和对方的MSS里取较小者作为这条连接的实际发送上限。所以抓包看到两端MSS不一致很正常实际生效的是小值。4.2 选项协商如何影响大流量传输窗口缩放、SACK和时间戳这三个选项直接决定了一条TCP连接能不能在长肥网络高带宽、高延迟上跑出吞吐。先看时间戳它有两个值TSval和TSecr发送方在包里放当前时间接收方原样回显发送方就能算出精确的RTT。同时时间戳还能防止序号回绕带来的歧义——32位序号在高速链路上很快绕一圈比如10Gbps下大约每3.4秒就回绕一次如果没有时间戳接收方很难区分旧包和新包。SACK的作用是解决“一个包丢了一堆后续包跟着遭殃”的问题。传统累计确认下如果接收方收到100到199和300到399的数据但丢了200到299这一段它只能反复确认“下一个期望是200”发送方要等到超时才知道到底该重传哪些。开启了SACK之后接收方可以明确告诉发送方“我收到了100-199和300-399缺口在200-299”发送方只重传缺口部分效率提升非常明显。所以在抓包时看到一个SYN包里带SACK-Permitted基本可以判断这条连接对丢包有不错的恢复能力。窗口缩放和这三个选项必须都在三次握手阶段协商完成这解释了为什么抓包时SYN包总是带着一堆选项。如果任一方没有在SYN包里通告某个能力后续就不允许再使用。这也是TCP“端到端协商”思想的一个体现双方能力不同、路径条件不同必须在连接建立时就把约束谈好之后数据传得再快也不能突破协商结果。我建议每个做网络性能排查的人都养成一个习惯先看握手阶段的SYN包选项就能提前判断这条连接的上限。如果SYN里MSS是1460、窗口缩放是7、SACK和时间戳齐全这条连接的底子就是好的如果某个选项缺失后面出现吞吐异常、乱序重传高企就有了解释方向。5. 实操验证用抓包把首部格式“解剖”一遍5.1 抓包准备与过滤表达式纸上谈兵讲再多不如自己抓一个包看一眼。准备一台能联网的机器安装Wireshark或者用命令行工具tcpdump也可以。抓本机回环流量最简单因为不需要过滤网卡混杂模式权限也容易满足。先开着终端抓包再在浏览器里访问一个普通网站就能看到完整的TCP三次握手。最常用的tcpdump命令是这样sudo tcpdump -i eth0 -nn tcp port 443 -c 10如果想把原始报文保存下来放到Wireshark里慢慢看加一个-w参数sudo tcpdump -i eth0 -nn -w /tmp/tcp.pcap tcp port 443在Wireshark里打开文件后过滤表达式按需求写。只想看TCP包就输入tcp想只看SYN包输入tcp.flags.syn 1只看出站方向的SYN包再叠加一个条件tcp.flags.syn 1 tcp.flags.ack 0。这个组合过滤很关键因为SYNACK包同时满足syn1和ack1如果你只看syn1会把服务端的响应也混进来。正确的是用“syn1且ack0”表达“主动发起连接的包”用“syn1且ack1”表达“被动确认并同步的包”。抓包时要注意一个细节在Wireshark里看到的TCP信息栏是一行摘要默认显示相对序号、相对确认号还会自动算出窗口大小。这些信息非常方便但如果你想练解读首部的硬功夫建议右键选择“Protocol Preferences”里关掉相对序号或者直接看原始字节流。Wireshark底下有Hex pane把光标点到TCP头部就能逐字节看到十六进制和对应的字段高亮。这一块的联动是搞懂首部格式的最佳练习场。5.2 一个SYN包的逐字段对照我拿一个典型的出站SYN包作为例子把它展开成一张表格。为了描述方便我们假设客户端用端口52000访问服务器的443端口源IP和目的IP用文档专用的保留地址段不影响理解。字段抓包显示值解读Source Port52000客户端临时分配的源端口Destination Port443HTTPS服务端口Sequence Number相对值0一个随机ISN的起始位置Header Length44 bytes数据偏移字段值是11Flags0x002只有SYN置位没有ACKWindow64240接收缓冲区通告值Checksum0x8f5e发送方计算后的校验值[MSS]1460本端建议的最大段长度[Window Scale]7实际窗口左移7位[SACK Permitted]True支持选择性确认[Timestamp]TSval..., TSecr0首次握手没有回显值为什么Header Length是44字节固定首部20字节加上MSS选项4字节、Window Scale选项3字节、SACK-Permitted选项2字节、时间戳选项10字节几个数字加起来4321019字节不是4的倍数于是中间插入若干NOP填充凑成20字节的选项区最后固定202044字节。你从原始十六进制里看数据偏移字段的值应该是11也就是二进制1011。再看Flags的值0x002是怎么来的。TCP标志字段按位展开从高位到低位依次是NS、CWR、ECE、URG、ACK、PSH、RST、SYN、FIN。SYN位处在倒数第二位对应的二进制权值是0x02ACK位权值是0x10。所以一个纯SYN包的flags显示为0x002一个SYNACK包显示为0x012一个纯ACK包显示为0x010。记住这个位权表你在十六进制里看到一个0x012立刻能反应出这是握手的第二个包不需要把鼠标悬停在Wireshark的Flags字段上。5.3 从首部字段快速定位握手异常实际排障中抓包不是看热闹而是要在几秒内判断连接卡在哪一步。我总结了一套看首部的顺序先看Flags确认这是哪个阶段的包再看Seq和Ack确认双方序号是否对得上然后看窗口和选项判断性能上限最后才看IP层有没有丢包。最常见的场景是“只看到出站SYN没看到SYNACK”。这有两种可能要么SYN包根本没到对方要么对方回了但回包被防火墙丢掉。这时候看SYN包的重传情况TCP会重传SYN第一次约1秒后重试指数退避。如果多次重传都石沉大海多半是路径上有设备静默丢包或者目的端口根本没监听。可以用tcpdump在服务器侧同时抓包一眼就能判断是入向丢还是出向丢。这个“两端同时抓包对照”的操作比在客户端单侧猜半天高效得多。再一种场景是握手完成了但连接立刻被RST干掉。这时要看RST包的序号和确认号。如果RST.ACK1并且确认号是对方期望的正确值说明是服务器主动拒绝——端口未监听、应用层拒绝或安全策略未通过如果RST包的ACK标志为0且序号很诡异很可能是中间设备伪造注入的reset用来干扰连接。这两种情况处理思路完全不同前者查应用和防火墙策略后者要排查链路设备是否有流清洗策略。判断依据都在首部那几位标志里熟悉了就不用瞎猜。6. 常见问题与排障经验实录6.1 首部字段速查表把TCP首部所有字段汇总成一张速查表排查时可以直接对照。注意这里列出的字节位置是从TCP头起始处计算的不是从IP头起始处。字节范围字段位数作用与常见值0-1源端口16客户端临时端口常见32768-609992-3目的端口16服务监听端口如80、4434-7序号32第一个数据字节的流位置SYN/FIN各占一个序号8-11确认号32期望收到的下一个字节序号累计确认12数据偏移4首部长度/4最小5最大1512保留位3目前保留未用通常为012-13标志位9NS、CWR、ECE、URG、ACK、PSH、RST、SYN、FIN14-15窗口16接收方通告窗口实际值需结合缩放因子16-17校验和16覆盖伪首部TCP首部数据18-19紧急指针16URG1时指向紧急数据末尾20-59选项0-40常见MSS、窗口缩放、SACK、时间戳等这张表建议打印出来放在手边比任何时候去翻RFC都快。我自己早年做协议接入时用的就是一张类似的纸质表每看一个十六进制字节就按表查一次半个月后所有字段位置就烂熟于心了。初学者不用追求一次背下来先能看懂Wireshark里的字段和这张表的对应关系就已经赢了一半。6.2 最容易踩的5个误区误区一确认号表示“已经收到的最后一个字节号”。错确认号是“期望收到的下一个字节号”。如果我收到0到199字节确认为200而不是199。这个区别在抓包时非常明显尤其是配合SYN占一个序号来看很多人第一次看到SYN包后回应的ack是x1会以为服务器多确认了一个字节其实那就是规则本身。误区二数据偏移字段的值就是首部字节数。错它是4字节块数。值5对应20字节值11对应44字节。因为20字节的首部恰好对应值5导致不少人误以为这个字段就是字节数直到遇到带选项的包才露出马脚。自己解析包时一定先用data_offset*4得到真实长度再看数据从哪开始。误区三TCP校验和只算TCP首部。错它要算伪首部、TCP首部和数据三部分。伪首部里的源IP和目的IP来自IP层协议号固定为6。这也是为什么你不能把TCP段单独拎出来就算校验和必须结合IP头信息。自己做抓包工具时最容易踩的就是这个坑。误区四窗口字段就是实际接收能力。错还要看窗口缩放因子。窗口缩放协商在握手阶段完成如果对端没有通告缩放因子窗口上限就是65535字节即使本地缓冲区再大也没用。抓包看到的“Calculated window size”才是协商后的真实值。误区五只有数据包才消耗序号。错SYN包和FIN包各占一个序号。很多初学者看三次握手的第二个包不理解为什么ack是seq1而不是seq就是因为没把SYN看成“占了一个字节”的逻辑实体。四次挥手时FIN同理最后一个ACK的确认号也要在FIN序号上加1。6.3 实际排障中的一条经验线排障经验这东西讲一堆不如给一条可复用的操作线。我自己处理TCP连接问题时的习惯是抓包后先不看IP直接看TCP首部。第一眼看Flags判断当前抓到的包是握手的第几个、挥手状态、还是异常RST第二眼看相对序号和确认号把双向的序号线画出来确认没有序号跳变第三眼看MSS和窗口缩放选项评估这条连接的性能上限最后才结合IP层确认丢包和RTT。举个例子我曾经调一个跨平台系统的对接问题现象是文件传输总是中断从应用层日志看不出原因。抓包一看三次握手正常数据发送阶段接收窗口一路上涨然后突然变成0窗口字段更新为0发送方就停下来了。再往后接收方重新发了窗口更新包但发送方没反应最终超时重传。这一串现象问题其实不在TCP首部本身而是接收方的应用层没有及时消费数据缓冲区满了触发了TCP的流量控制。但如果不是先看懂窗口字段和标志位我根本没法把“窗口变成0”和“应用层读太慢”这件事关联起来。还有一次是服务器回包一切正常但客户端始终报连接超时。两端同时抓包后发现服务器发出的SYNACK包在某个中间节点被改了MSS值这属于中间设备篡改TCP选项的典型案例。如果只看客户端侧抓包只会看到“发了很多SYN一直没响应”永远找不到根因。后来我们在服务器侧也抓了一份一对标志位和序号很快锁定了路径上的设备。所以我想强调的排障经验就是TCP首部格式不是考试用的背诵题而是一套现场勘查工具。遇到网络问题先把首部字段按顺序读一遍大多数问题的方向就清楚了。最后再分享一个小技巧抓包时保留完整报文长度不要用-s 0截断看首部格式一定要开“Relative sequence numbers”之外的绝对序号视角分析结束后记得保存为pcapng格式并附上过滤条件。把读首部变成习惯你再看网络问题就不再是玄学而是一行行可以验证的二进制事实。