抓包分析TCP的三次握手和四次握手

空扰寡人 提交于 2019-12-01 19:22:44

问题描述:

       在上一篇《如何对Android设备进行抓包》中提到了,服务器的开发人员需要我bug重现然后提供抓包给他们分析,所以抓好包自己也试着分析了一下。发现里面全是一些TCP协议和HTTP协议。所以要想进行抓包分析,必须先了解TCP的原理。这里介绍了TCP的建立连接的三次握手和断开连接的四次握手。


问题分析:


1、TCP建立连接的三次握手


1、1前言:介绍三次握手之前,先介绍TCP层的几个FLAGS字段,这个字段有如下的几种标示

SYN表示建立连接,

FIN表示关闭连接,

ACK表示响应,

PSH表示有 DATA数据传输,

RST表示连接重置。


1、2 三次握手的步骤

第一次握手:主机A发送位码为syn=1,随机产生seq number=1234567的数据包到服务器,主机B由SYN=1知道,A要求建立联机;

 第二次握手:主机B收到请求后要确认联机信息,向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包;

 第三次握手:主机A收到后检查ack number是否正确,即第一次发送的seq number+1,以及位码ack是否为1,若正确,主机A会再发送ack number=(主机B的seq+1),ack=1,主机B收到后确认seq值与ack=1则连接建立成功。

 完成三次握手,主机A与主机B开始传送数据。

从抓包分析中可以很清晰的看到TCP三次握手,下图就是完整的三次握手,客户端41826端口和服务器的80端口建立了连接



2、tcp断开连接的四次握手

tcp断开连接有两种方式,第一种是正常的四次握手断开的,第二种是RST异常断开的


2、1 正常断开的四次握手:

下图来自网络


假设Client端发起中断连接请求,也就是发送FIN报文。Server端接到FIN报文后,意思是说"我Client端没有数据要发给你了",但是如果你还有数据没有发送完成,则不必急着关闭Socket,可以继续发送数据。所以你先发送ACK,"告诉Client端,你的请求我收到了,但是我还没准备好,请继续你等我的消息"。这个时候Client端就进入FIN_WAIT状态,继续等待Server端的FIN报文。当Server端确定数据已发送完成,则向Client端发送FIN报文,"告诉Client端,好了,我这边数据发完了,准备好关闭连接了"。Client端收到FIN报文后,"就知道可以关闭连接了,但是他还是不相信网络,怕Server端不知道要关闭,所以发送ACK后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传。“,Server端收到ACK后,"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,我Client端也可以关闭连接了。Ok,TCP连接就这样关闭了!


2、2 用抓包来看断开连接的四次握手

下图中的四个箭头就是标准的四次握手了。

首先服务器80端口想41826端口发出FIN的断开连接请求

然后第二个箭头41826收到请求之后想服务器80端口回复了一个ACK

接着第三个箭头41826向服务器80端口发送断开请求FIN

最后第四个箭头,服务器80向客户端发送断开的回复ACK

这样四次握手之后,服务器和客户端都确认了断开连接,可以看到断开连接是双向的。


2、3 RST异常关闭连接

有时候也会出现异常断开连接的情况,也就是RST,比如说下图,服务器80向客户端32875发送断开请求FIN,客户端也通过这条链路回复了ACK,但是此时还有数据需要发送,所以没有急着回复FIN,而是先将get请求发送出去,发送了get请求之后再发送的断开请求FIN,但是此时服务器不知道什么原因在没有确认客户端的确认前就断开了,所以在接到get请求之后,返回了一个RST,异常断开了这条链路。


结论:

TCP的三次握手和四次握手平时看书本看起来很生涩难懂,但是通过一次http的抓包分析之后,对于tcp的七次握手有了新的了解和认识。

这些理论知识我还是了解的不够深入,只是学以致用,用来分析网络抓包。不过要想做好网络应用,还是很有必要对tcp,http做深入一点的了解

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!