三只手鲨鱼为什么没有序列号？

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数据包携带数据，则确认号将根据数据包携带的数据大小而增加。