三隻手鯊魚爲什麼沒有序列號？

Question

我使用tcpdump觀看三次握手。 的客戶端口是51484和服務器端口是9501

//connect to server 
//three-way handshake 
51484 > 9501 : Flags [S], seq 2969626801 
9501 > 51484: Flags [S.], seq 587835665, ack 2969626802, 
51484 > 9501 : Flags [.], ack 587835666  // <- why the ack don't 
              // have sequence number ? 

//close the connect 
51484 > 9501 : Flags [F.], seq 2969626802, ack 587835666 
9501 > 51484: Flags [F.], seq 587835666, ack 2969626803 
51484 > 9501 : Flags [.], ack 587835667 

我知道：只要條件允許，ACK包將包含在其他的包一些payload.But爲什麼ACK包唐」在三次握手的第三步中有效載荷爲空時，是否有序列號？

我的問題是：爲什麼ack數據包在三次握手的第三步中沒有序號？

Answer 1

從您的數據包捕獲中，您似乎很快關閉了請求 - 即使在3次握手成功完成之前。

驗證您的SYN標誌必須爲0，並且ACK標誌必須爲1，以便在第3步中在TCP中進行正確的3路握手。目前，它不應該是這樣，這就是爲什麼它失敗。

Step 1 : SYN Flag = 1, ACK Flag = 0 
Step 2 : SYN Flag = 1, ACK Flag = 1 
Step 3 : SYN Flag = 0, ACK Flag = 1 

建立使用三次握手一個TCP可靠連接的最後一步是將TCP ACK數據包發送回服務器，在最後一步收到的SYN-ACK信息包 。

9501 > 51484: Flags [S.], seq 587835665, ack 2969626802, 
51484 > 9501 : Flags [.], ack 587835666 
// shows that the previous data was successfully received 

51484 > 9501 : Flags [F.], seq 2969626802, ack 587835666 
// next, here the client machine soon sends the close request. 

---

注意，JUST迭代：

1. 在任何階段，確認號指出的是，TCP段的下一個序列號從一個源到另一個源應成爲對方的確認號碼。

2. 如果在接收到的TCP數據包中設置了SYN，ACK或FIN標誌，則確認號增加1。如果TCP數據包攜帶數據，則確認號將根據數據包攜帶的數據大小而增加。