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数据包将被包含在具有一些有效载荷的其他数据包中。但是为什么ack数据包在第三步中有效载荷为空时不具有序列号三次握手？

我的问题是：为什么ack数据包在三次握手的第三步中没有序号？

Answer 1

从您的数据包捕获中，您似乎很快就会关闭请求 - 甚至在3次握手成功完成之前。

验证您的SYN标志必须为0，并且在第3步中TCP的正确3次握手时ACK标志必须为1. 目前，情况应该不是这样，这就是为什么它失败了。

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.

注意，只需要ITERATE：

在任何阶段，确认号码指出从一个来源到另一个来源的TCP段的下一个序列号应该是另一个来源的确认号。
如果在收到的TCP数据包中设置了SYN，ACK或FIN标志，则确认号码会增加1。如果TCP数据包携带数据，则根据数据包携带的数据大小增加确认号。

为什么ack包装时没有三手鲨鱼的序列号？

1 个答案: