[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簡化了顯示