想要弄清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次挥手足够切断连结,为节约各种资源,能三次的服务都三次了
等我找着工作了,再来抓你,四次挥手!!!