捕获！三次握手四次挥手~

想要弄清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次挥手足够切断连结，为节约各种资源，能三次的服务都三次了

等我找着工作了，再来抓你，四次挥手！！！