在完成对三次握手的抓包后，间隔了一段时间，来进行四次挥手的抓包。
知识背景
问题一：为什么要四次挥手呢？
在上一章的三次挥手中，我们说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关闭了这异常的链接……