想要弄清TCP三次握手，四次挥手的过程，最好的办法当然是抓包啦~
QQ作为人均必备软件是很好的对象~
值得注意的是，我们的QQ聊天并不是TCP建立点对点连接的，想想好友列表里的在线好友，一人一个TCP端口号，网卡该冒烟了。。。因此从网络资源考虑，想要实现多人在线“交友”(>.<)，只能使用UDP多对多，同时应用层保证可靠传输！！
下面正式开始实验，首先是三次握手，思路步走：
| 步骤 | 任务 |
|---|---|
| 1 | 打开QQ应用程序(当然不能是自动登陆的啦)，还有我们的抓包工具Wireshark |
| 2 | 输入QQ密码，准备发车~ |
| 3 | 选择当前使用的网络(一般是有线以太网或WiFi)，点击Wireshark开始抓包按钮后立刻点击QQ登录… |
| 4 | 登录成功后立刻推退出(就是这么脑残(<.<)) |
| 5 | 点击Wireshark停止抓包，验货，终止交(jian)易(ting) |
就这么简单，附图如下：
这么多包，哪个才是QQTCP建立和断开呢？我们可以使用过滤器哒，输入"tcp.flags.syn == 1 and tcp.flags.ack == 0 and tcp.port == 80"，懂我意思吧(<.<)
点击右边的回车键，我不做人啦！JOJO！
可以看到QQ在登陆时貌似一口气开了三个线程，用了三个端口，建了三个连接
但我们主要关注一个吧，就那个14942的那个，你放学别走！“tcp.port ==14942”
确认过眼神，让我康康！
三次握手
1.连接请求：
客户端
相对序列号=0，跟踪正常
相对确认序列号=0，跟踪正常
SYN=1，ACK=0，向服务端连接请求正常
窗口大小，随意…
最大报文段长度MMS=1460，跟踪正常
窗口扩大因子，随意…
2.连接请求应答：
服务端
相对序列号=0，跟踪正常
相对确认序列号=1，跟踪正常
SYN=1，向客户端请求连接正常
ACK=1，向服务端请求连接应答正常
窗口大小，随意…
最大报文段长度MMS=1460，跟踪正常
窗口扩大因子，随意…
3.第三次握手
服务端
相对序列号=1，跟踪正常
相对确认序列号=1，跟踪正常
ACK=1，向客户端请求连接应答正常
窗口大小，随意…
没有选项…正常？
窗口扩大因子，随意…
四次挥手
你看这个包包，超逊的啦！
1.客户端断开请求FIN
相对序列号=810，FIN一个包，跟踪正常
相对确认序列号=408，跟踪正常
ACK=1，确认服务端最后传来的包
FIN=1，向服务端请求断开
2.客户端断开请求确认FIN_ACK + 服务器断开请求 FIN
相对序列号=408，FIN一个包，跟踪正常
相对确认序列号=810，不再请求新包？
ACK=1，客户端断开请求确认
FIN=1，服务器端断开请求
3服务端断开请求确认 FIN_ACK
相对序列号=811？跟踪正常？
相对确认序列号=409？跟踪正常？
ACK=1，服务端断开请求确认
FIN=0，成功断开
4.？？？
相对序列号=409？
相对确认序列号=811？
ACK=1，FIN=0？
这TM就很尴尬了，和我看到过的四次挥手不一样啊。。。
在@cbdog94的帮助下，了解到，原来还有三次挥手这玩意
虽然和今天提取的4个包挥手原理依旧不一样，但这说明还有其他挥手的可能性~
所以是不是觉得被标题骗了呢？
没事，我们换一个应用，http总可以吧！！！
目标大B站！！！
过程你们也不会看的，我直接放结果了
标准的三次挥手
至于四次挥手嘛，我真的找不到呀…
个人感觉，对客户而言，通过FIN断开请求表达了明确的断开意愿后，服务器端马上就可以做出切断传输的决定，停止文件传输，因此3次挥手足够切断连结，为节约各种资源，能三次的服务都三次了
等我找着工作了，再来抓你，四次挥手！！！
