抓包看TCP序号和确认号变化规则

以浏览器访问网页为例，观察浏览网页过程中建立tcp三次握手，传输数据，最后四次挥手过程中的TCP的序号和确认号的变化规则，从而理解序号和确认号的含义。

抓包工具还是wireshark

首先开始抓包，然后打开浏览器，随便访问一些网页或者打开图片，然后关闭浏览器，之后停止抓包。

过滤tcp流：

这样一个建立会话，传输数据，关闭会话的完整过程就都被抓了下来。

我们清晰的看到前三个数据包是三次握手，后面四个是挥手关闭。中间的是传输数据的过程。

这样看序列号和确认号的变化规律不是很友好，我们可以用wireshark的统计功能查看tcp会话详细过程：

注意选择“限制显示过滤器”和流类型为tcp，结果瞬间就清晰了

下面我们就分析一下序列号和确认号的变化规律。

首先wireshark显示的序列号是一个相对值，理论上这个值是一个四个字节的数据，总共有32位，那就是

0和4,294,967,295之间的任意值。

但是我们是为了分析ack和seq的变化规则，所以用相对值就很方便。

先说结论，a给b发tcp报文，确认号seq代表我发送这个报文的顺序或者位置（之前发送了多少的数据），ack确认号的意思是，我之前收到b给我发送的数据量。

听不懂没关系，我们看一下实际的通信过程。

左边172.16.189.53是客户端，右边221.194.182.35是服务端。首先看三次握手：

第一个SYN：客户端给服务端发第一个包，seq默认是0，0代表是第一个包。

第二个SYN+ACK：服务端给客户端回包seq也是0，是因为这也是服务端给客户端发的第一个包。Ack=1说明，服务端收到了客户端发的第一个包。

第三个ACK：seq=1说明这是客户端给服务端发的第二个包（第一个包seq0+1），ack=1说明收到了服务端给客户端发的包。

接下来就是数据传输了，这时候会传输真实大小的数据，seq和ack变化就会不太一样：

第一个包：大小为517。seq依然为1，是因为之前没有真实的发送过数据。ACK为1因为到目前位置从服务端收到的数据仅仅为之前的SYN+ACK。

也就是说单纯的ack数据包是不会对seq和ack的变化产生影响的。

第二个包：服务端回的ack。Seq=1因为这是服务端发送的第二个有有意义的包（0+1），ack=518（517+1）说明到目前为止收到了客户端发来了518大小的数据。

第三个包：服务端回的ack，长度1412。Seq=1，还是因为这是服务端发的第二个有意义的包，ack=518说明到目前为止收到了客户发来了518大小的数据

第四个包：客户端回ack，长度1412。Seq=1413，为上一个数据包的seq加上上一个数据包的长度（1+1412），ack518说明目前为止收到了客户发来了518大小的数据。

第五个：PSH+ACK，长度1272。Seq=2825.上一个数据包的seq加上一个数据包长度（1413+1412），ack=518说明到目前为止收到了客户发来了518大小的数据。

第六个：客户端发的ack。Seq=518，上一个数据包（也就是图上的第一个包）的seq加上这个包的长度（1+517），ack=4097说明到目前位置收到的数据长度为4097（1+1412+1412+1272）

后面数据交互的序列号和确认号的变化规律也是这么变化的。

下面看四次挥手;

第一个包，客户端发FIN请求关闭会话。Seq=809说明之前发送了809字节数据量。ack说明之前收到了5003字节的数据量。

第二个包，服务端回复ack。seq说明之前发送了5003的数据量，ack=810说明之前收到了810字节的数据（上一个包seq=809+1）

第三个包seq没变还是5003，因为第二个包是个单纯 的ack，不算发送实际意义的数据。

第四个包客户端发ack，seq=810，是在第一个包的seq=809基础上+1，ack=5004是在第三个包seq=5003基础上+1。

总结：

序列号的变化是上一个数据包再加上这个数据包的数据长度；如果上一个数据包不传数据，只是建立连接或者关闭连接，那么序列号seq只是加1；如果数据包只是回复对端的ack，那么序列号不变

确认号是告诉对面到目前本端收到了多少数据量，同样的，单纯的ack不算做数据量