wireshark分析tcp协议（二）四次挥手（异常情况）【理论 + 实操】

上一章：wireshark分析tcp协议（一）三次握手【理论 + 实操】

在完成对三次握手的抓包后，间隔了一段时间，来进行四次挥手的抓包。

知识背景

问题一：为什么要四次挥手呢？

在上一章的三次挥手中，我们说tcp协议是

• 面向连接
• 可靠的
• 基于字节流的传输层协议

而且在三次握手时有对这些特点进行体现。

在理解过程中，我们可以简单的将

tcp的通信过程，理解为为两个陌生的小朋友的行为

• 三次握手：两个小朋友在相互认识
• 发送数据：两个小朋友在愉快的玩耍，有来有回的
• 而四次挥手则是两个小朋友中有一个小朋友要回家了

小朋友A突然被妈妈叫回家了，于是和小朋友B说我要回家了，但是他没有走，还想听小朋友B说说话。

小朋友B不舍的说知道了，然后再把之前没说完的话继续说完，然后小朋友B也说到，好吧，那你走吧。

小朋友A听完小朋友B的话之后，愉快的分开了，期待下次的相遇~

四次挥手操作步骤

1.建立连接

此步骤为三次握手的全部过程，详情见wireshark分析tcp协议（一）三次握手【理论 + 实操】

2.关闭网站

在建立起连接后，我们关闭网站，等待FIN ACK包的出现

但是我们发现这里只有三次挥手出现，而且等待了很久也没有第四次的出现，为什么呢？

注意：

这里虽然显示的是三次挥手，但是实际上的 步骤没有变

只是将第二次和第三次合并了

为什么第二次会没了呢？

服务器其实在之前就早已经发送完数据了，一直等着你发消息呢！但是你有一直不发，

这时候你说“好了”，服务器收到之后，心里想“好家伙，老子早就不想干了”——客户端的FIN ACK

于是它快速的返回了“我这边也完了，快散伙吧，我还要去找其他人玩呢”——服务端的FIN ACK

客户端接受后，同意了结束请求

为什么服务器在发完数据后不主动结束呢？

因为开启了TCP延迟确认机制（默认开启）

3.第一次挥手——请求中断（FIN,ACK)

在第一次挥手时，我们主动的向服务端发送结束连接请求

我们查看第一条报文

• 源端口：9277，目的端口：80

查看当前的Flags

此时fin和ack都为1，是一个客户端发送连接请求

• 客户端序号seq = 3747946131
• 确认序号 seq = 1890243776

4.第二次挥手——服务器请求中断

• 源端口：80，目的端口：9277
• 服务器序号 = 1890243776
• 服务器确认序号 = （客户端发送序号）+ 1= 3747946131 + 1

与客户端发送完成请求一致，不过为 服务端发送请求

5.第三次挥手——客户端同意结束

• 源端口：9277，目的端口：80
• 客户端序列号 = 3747946131 + 1 = 3747946132
• 客户端确认序号 = 服务器端序号 + 1 = 1890243776

自此，中断连接。

异常情况：RST终止

在研究这四次挥手的时候，我貌似发现了一个不得了的东西

首先，我很正常的等待终止连接

第一个令我疑惑的点出现了：服务器提出终止连接请求

原本，我以为正常情况下，只有客户端才能主动终止请求的

但是了解下来，发现 TCP中断，双方都有权利主动终止请求
因为TCP是全双工通信，两者通信地位相等

在服务器主动发送终止指令后，客户端被动响应终止。

然后客户端主动提出keep-alive不断开连接，服务器响应

再一次客户端提出keep-alive的时候，服务器RST终止了异常的连接。

甚至，我还想到了一个离谱的卑微爱情故事：

服务器首先对客户端提出了分手，客户端通过ack犹豫的答应了，但是客户端发现他还有很多话没有对服务器说，然后就提出了keep-alive承诺，保持一段时间的交流好吗？我还有一些话要对你说。
服务器看到keep-alive承诺的情况下，发送ack不耐烦的答应了他。
但是客户端觉得不放心，又发送了一次，你真的愿意交流一段时间吗？
最后，服务器直接通过RST关闭了这异常的链接……