关于TCP协议连接与确认号的疑问（附tcpdump抓包数据）

先看你抓取的前两个握手数据包：

22:29:20.185032 IP 172.10.10.11.43086 > 172.10.10.21.http: Flags [S], seq 2173271328, win 29200, options [mss 1460,sackOK,TS val 3615590 ecr 0,nop,wscale 7], length 0
22:29:20.185090 IP 172.10.10.21.http > 172.10.10.11.43086: Flags [S.], seq 3246536796, ack 2173271329, win 28960, options [mss 1460,sackOK,TS val 3598763 ecr 3615590,nop,wscale 6], length 0

1. 第一次握手（客户端发起SYN请求） #

这是客户端（172.10.10.11:43086）向服务器（172.10.10.21:80）发送的连接请求包：

• Flags [S]：标记这是一个SYN（同步）包，用来发起TCP连接。
• seq 2173271328：这是客户端的初始序列号（ISN），是TCP协议随机生成的数值，目的是避免旧的过期连接数据包干扰当前连接。
• 虽然包的length 0（没有携带应用层数据），但SYN包本身会占用1个序列号的"名额"——这是TCP的规则，你可以把它理解为SYN包自带了一个虚拟字节，需要被确认。

2. 第二次握手（服务器回复SYN+ACK） #

这是服务器收到SYN包后回复的确认+同步包：

• Flags [S.]：S表示服务器也发送自己的SYN包，.代表ACK（确认），所以这是SYN-ACK包。
• seq 3246536796：这是服务器的初始序列号（ISN），同样是随机生成的。
• ack 2173271329：这就是核心的确认号逻辑！TCP的确认号规则是：确认号 = 期望收到的下一个字节的序列号。因为客户端的SYN包占用了1个序列号，所以服务器期望客户端接下来发送的数据包序列号是2173271328 + 1 = 2173271329，这个确认号就是在告诉客户端："我已经收到你到序列号2173271328为止的所有数据，下次请从2173271329开始发"。

补充：第三次握手（客户端发送ACK确认） #

正常情况下，接下来客户端会回复一个纯ACK包（Flags [.]），其中的确认号会是服务器的ISN+1（也就是3246536796 + 1 = 3246536797）。当服务器收到这个ACK包后，TCP三次握手完成，连接正式建立，双方可以开始传输应用层数据了。

如果你的抓包里没有第三个包，大概率是tcpdump的输出截断或者你提前停止了抓包，但从已有的两个包来看，所有序列号和确认号的逻辑都完全符合TCP协议规范。

内容的提问来源于stack exchange，提问作者JoeJoe