tcpdump使用時tcp三次握手抓包，ack置1的一些說明

在使用tcpdump抓包的時候，發現tcp的三次握手，第三次的時候竟然將ack置1了，百思不得其解，難道是現在tcp的協議變了嗎，讓我困惑不已，直接上結果

[root@www test_cpp]# tcpdump -i any port 53 -nn -v

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:09:32.524005 IP (tos 0x0, ttl 64, id 30266, offset 0, flags [DF], proto TCP (6), length 60)
    127.0.0.1.46894 > 127.0.0.1.53: Flags [S], cksum 0x3e3d (correct), seq 3479715283, win 65495, options [mss 65495,sackOK,TS val 20728809 ecr 0,nop,wscale 7], length 0
17:09:32.524066 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    127.0.0.1.53 > 127.0.0.1.46894: Flags [S.], cksum 0x74c2 (correct), seq 729305304, ack 3479715284, win 65483, options [mss 65495,sackOK,TS val 20728809 ecr 20728809,nop,wscale 7], length 0
17:09:32.524100 IP (tos 0x0, ttl 64, id 30267, offset 0, flags [DF], proto TCP (6), length 52)
    127.0.0.1.46894 > 127.0.0.1.53: Flags [.], cksum 0x9b7e (correct), ack 1, win 512, options [nop,nop,TS val 20728809 ecr 20728809], length 0

首先握手先在本地啓了一個dns server，用tcpdump抓53端口的包，然後使用dig 命令+tcp進行查詢，然後就出現了上面的結果，當然，通過Telnet,也可以重現這個現象。

現象就是三次握手的最後一次，ack 1？？？？

第一次客戶端127.0.0.1.46894 發送seq 3479715283，隨機生成的

第二次服務器 127.0.0.1.53 發送seq 729305304, ack 3479715284 ，，ack是前一次的seq+1

第三次客戶端127.0.0.1.46894發送ack 1，這不科學，按理來說應該是第二次的seq+1。

重複了幾次，都是這樣的，通過telnet也是一樣的，自己開個網頁，去訪問抓包也是這樣的，這怎麼辦！！

然後將抓包的報文保存下來-w ，在wireshark上打開，是這樣的：

只看前三條，是三次握手的過程在這裏：

第一次客戶端127.0.0.1.46894 發送seq 0，隨機生成的

第二次服務器 127.0.0.1.53 發送seq 0, ack 1 ，，ack是前一次的seq+1

第三次客戶端127.0.0.1.46894發送seq 1,ack 1， ack是第二次的seq+1。

再看下面的詳細解釋：

第一條：

看第二條的解釋：

第三條：

原來seq,ack,還是用的原來的tcp協議，沒有改變，只不過在wireshark中使用了相對量來顯示，

第一次seq:30 aa 5d 22 

第二次seq: 8a 5d 87 9b  ack:30 aa 5d 23     ack恰好是上一次的seq➕1

第三次seq：30 aa 5d 23  ack: 8a 5d 87 9b ack恰好是上一次的seq➕1。

那麼現在可以知道了，抓包本身確實是沒有問題的，那問題就只能是tcpdump自己顯示的功能有問題了，

應該是tcpdump，前兩次都是用的絕對量，第三次然後使用了個相對量，ack 1，這邏輯也是沒誰了！！！！無力吐槽，還以爲是tcp協議改了呢。