TCP 序列号和确认号是如何变化的？( 三 ) _生活百科

文章插图
在这里插入图片描述
客户端发送的第一次挥手的序列号和确认号分别设置为：

序列号设置为 client_isn + 11 。客户端上一次发送的报文是 [PSH, ACK]，该报文的 seq = client_isn + 1, len = 10，根据公式 1（_序列号 = 上一次发送的序列号 + len_），可以得出当前的序列号为 client_isn + 11 。
确认号设置为 server_isn + 1 。客户端上一次收到的报文是服务端发来的 ACK 报文，该报文的 seq = server_isn + 1，是单纯的 ACK 报文，不携带用户数据，所以 len 为 0 。那么根据公式 2（确认号 = 上一次收到的序列号 + len），可以得出当前的确认号为 server_isn + 1 + 0 （len = 0），也就是 server_isn + 1 。

服务端发送的第二次挥手的序列号和确认号分别设置为：

序列号设置为 server_isn + 1 。服务端上一次发送的报文是 ACK 报文，该报文的 seq = server_isn + 1，而该报文是单纯的 ACK 报文，不携带用户数据，所以 len 为 0，根据公式 1（_序列号 = 上一次发送的序列号 + len_），可以得出当前的序列号为 server_isn + 1 + 0 （len = 0），也就是 server_isn + 1 。
确认号设置为 client_isn + 12 。服务端上一次收到的报文是客户端发来的 FIN 报文，该报文的 seq = client_isn + 11，根据公式 2（_确认号= _上一次_收到的序列号 + len，特殊情况，如果收到报文是 SYN 报文或者 FIN 报文，则改为 + 1_），可以得出当前的确认号为 client_isn + 11 + 1，也就是 client_isn + 12 。

服务端发送的第三次挥手的序列号和确认号还是和第二次挥手中的序列号和确认号一样。

客户端发送的四次挥手的序列号和确认号分别设置为：

序列号设置为 client_isn + 12 。客户端上一次发送的报文是 FIN 报文，该报文的 seq = client_isn + 11，根据公式 1（_序列号 = 上一次发送的序列号 + len 。特殊情况，如果收到报文是 SYN 报文或者 FIN 报文，则改为 + 1_），可以得出当前的序列号为 client_isn + 11 + 1，也就是 client_isn + 12 。
确认号设置为 server_isn + 2 。客户端上一次收到的报文是服务端发来的 FIN 报文，该报文的 seq = server_isn + 1，根据公式 2（_确认号 = _上一次_收到的序列号 + len，特殊情况，如果收到报文是 SYN 报文或者 FIN 报文，则改为 + 1_），可以得出当前的确认号为 server_isn + 1 + 1，也就是 server_isn + 2 。

实际抓包图在这里贴一个，实际过程中的抓包图。

文章插图
在这里插入图片描述
套入我的万能公式，发送的 TCP 报文：

公式一：序列号 = 上一次发送的序列号 + len（数据长度）。特殊情况，如果上一次发送的报文是 SYN 报文或者 FIN 报文，则改为上一次发送的序列号 + 1 。
公式二：确认号 = 上一次收到的报文中的序列号 + len（数据长度）。特殊情况，如果收到的是 SYN 报文或者 FIN 报文，则改为上一次收到的报文中的序列号 + 1 。

懂了这套公式之后，相信你在看这类的抓包图中序列号和确认号的变化的时候，就不会没有逻辑了。
怎么样，学废了吗，溜啦溜啦！
更多网络文章网络基础篇