TCP三次握手最后一个ACK报文的seq与ack为何均为1

现象原因说明 #

你观察到的第三次握手ACK报文中seq、ack均为1的情况，是抓包工具（如tcpdump、Wireshark）默认开启的相对序列号/确认号展示模式导致的，并非网络传输时的真实字段值，属于正常现象。

对应抓包数据验证： #

• 第一次握手（SYN包）：客户端发送的真实seq为2029035340，SYN标志位本身会占用1个序列号长度，因此客户端后续报文的起始序列号为2029035340 + 1 = 2029035341
• 第二次握手（SYN+ACK包）：服务端发送的真实seq为1295300764，返回的ack值为2029035341（正好是客户端SYN包的seq+1，符合TCP协议规则），同时服务端的SYN标志位也占用1个序列号，因此服务端后续报文的起始序列号为1295300764 +1 = 1295300765
• 第三次握手（ACK包）：报文传输的真实seq为2029035341、真实ack为1295300765。抓包工具为了降低阅读成本，会针对单条TCP流做序列号转换：将客户端初始SYN的seq作为基准值，转换后相对seq从1开始计数；将服务端初始SYN的seq作为基准值，转换后相对ack从1开始计数，最终就呈现出你看到的seq=1、ack=1的结果。

如果需要查看真实的32位序列号，关闭抓包工具的相对序列号展示开关即可：比如Wireshark可在「编辑-首选项-Protocols-TCP」路径下，取消勾选「Relative sequence numbers」选项。

内容的提问来源于stack exchange，提问作者waka.namake