[tcp] tcpdump抓包第三次握手ack数值为1

在用tcpdump抓包时，发现前面两次握手的seq和ack能对应起来，可是第三次由客户端发起的确认ack值为1，熟悉tcp三次握手的都知道，ack的值是对方的seq+1，第三次握手的ack值不该该是1，测试抓了各类端口的tcp包发现都是这样，难道是由于tcp协议改动了？

tcpdump抓包复现

直接tcpdump命令便可，若是更详细点的信息，可加-v不过跟当前复现内容没有太多关系

14:29:06.049398 IP 100.116.251.137.53686 > 10.0.0.15.81: Flags [S], seq 413886776, win 29130, options [mss 1942,sackOK,TS val 2047175890 ecr 0,nop,wscale 9], length 0
14:29:06.049406 IP 10.0.0.15.81 > 100.116.251.137.53686: Flags [S.], seq 1511062036, ack 413886777, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:29:06.049711 IP 100.116.251.137.53686 > 10.0.0.15.81: Flags [.], ack 1, win 57, length 0
14:29:06.050075 IP 100.116.251.137.53686 > 10.0.0.15.81: Flags [P.], seq 1:20, ack 1, win 57, length 19
14:29:06.050087 IP 10.0.0.15.81 > 100.116.251.137.53686: Flags [.], ack 20, win 115, length 0
14:29:06.050107 IP 10.0.0.15.81 > 100.116.251.137.53686: Flags [P.], seq 1:184, ack 20, win 115, length 183
14:29:06.050118 IP 10.0.0.15.81 > 100.116.251.137.53686: Flags [F.], seq 184, ack 20, win 115, length 0

第一行100.116.251.137端口53686向10.0.0.15端口81发起了SYN主动链接的请求，seq为413886776

第二行10.0.0.15.81端口81向100.116.251.137端口53686发起了SYN请求，seq为1511062036，注意ack是413886776+1=413886777
那么以上两次都没什么问题，正常的握手

问题出在第三行，原本按照三次握手，最后确认，ack应该是第二次握手的seq+1，也就是1511062036+1=1511062037，这才是正确的ack，但tcpdump抓包的显示是1

利用wireshark分析

因而将tcp包抓到本地，利用wireshark来分析下看看可否找到答案

抓包命令
tcpdump -w test.cap

上面这张图就是三次握手的包在wireshark，前三行封包就是三次握手，发如今wireshark里面seq从0开始，其实seq也不是0，能够看下面的具体值。不过第三次握手依然显示ack=1

经过wireshark逐行分析
第一行

seq:82 dc ee f2
ack:0

第二行
seq

ack

seq:7c d5 55 21
ack:82 dc ee f3
ack的值恰好是第一行的seq+1

第三行

ack:7c d5 55 22

结语看到这里就明白了，第三次握手的ack虽然在tcpdump显示为1，可是值是第二行的seq+1所以不是tcp三次握手协议变了，应该是tcpdump简化了显示