為什麼使用tcpdump觀察三次握手的過程，最後一次握手後，ack變為1而不是y+1？

在學習tcp三次握手的時候，書上最後一次握手是ack=y+1

但是我在ubuntu上使用tcpdump抓包的時候，前兩次的seq值比較大，而最後一次握手時，ack的值並不是y+1，而是變成了1，這是為什麼呢？

網路協議解析軟體，有一個宗旨，就是將枯燥乏味的0、1二進位流解析成用戶友好的顯示，讓協議分析盡量簡單、直白。

TCPDUMP第三個ACK顯示的偏移值（Offeset），即相對於初始序列號(原點）的偏移值，但需要明確的是，TCPDUMP捕獲的原始報文里是絕對值（應該是長長的一串數字），只是顯示成一個偏移量。

有一種防火牆，每當TCP同步握手時，會將雙方的初始序列號替換成一個32位的隨機數，這樣雙方看到對方的序列號都是替換後的序列號，這樣的好處是，避免用戶有規律的序列號被第三方猜測到，而注入非法流量。通過隨機化，可以讓這個猜測過程難以湊效。

這是中間人技術的一種，隨著學習的深入，多注意中間人對IP協議欄位、TCP協議欄位的改寫、替換。

TCP connection 開始之後，tcpdump 默認開始顯示 relative sequence number。沒記錯的話是三次握手的最後一個包開始。

加 -S 可以恢復。

PS. 去官方文檔確認了一下，有明確的解釋說明

IP rtsg.1023 &> csam.login: Flags [S], seq 768512:768512, win 4096, opts [mss 1024]
IP csam.login &> rtsg.1023: Flags [S.], seq, 947648:947648, ack 768513, win 4096, opts [mss 1024]
IP rtsg.1023 &> csam.login: Flags [.], ack 1, win 4096


Note that the ack sequence number is a small integer (1). The first time tcpdump sees a TCP `conversation", it prints the sequence number from the packet. On subsequent packets of the conversation, the difference between the current packet"s sequence number and this initial sequence number is printed. This means that sequence numbers after the first can be interpreted as relative byte positions in the conversation"s data stream (with the first data byte each direction being `1"). `-S" will override this feature, causing the original sequence numbers to be output.

Manpage of TCPDUMP