利用tcpdump抓包工具监控TCP连接的三次握手和断开连接的四次挥手

TCP传输控制协议是面向连接的可靠的传输层协议,在进行数据传输之前,需要在传输数据的两端(客户端和服务器端)创建一个连接,这个连接由一对插口地址唯一标识,即是在IP报文首部的源IP地址、目的IP地址,以及TCP数据报首部的源端口地址和目的端口地址。TCP首部结构如下:

利用tcpdump抓包工具监控TCP连接的三次握手和断开连接的四次挥手

其中在TCP连接和断开连接过程中的关键部分如下:

1.源端口号:即发送方的端口号,在TCP连接过程中,对于客户端,端口号往往由内核分配,无需进程指定;

2.目的端口号:即发送目的的端口号;

3.序号:即为发送的数据段首个字节的序号;

3.确认序号:在收到对方发来的数据报,发送确认时期待对方下一次发送的数据序号;

4.SYN:用于发送连接请求;

5.ACK:确认序号有效;

6.FIN:断开连接。

三次握手

三次握手的过程如下:

利用tcpdump抓包工具监控TCP连接的三次握手和断开连接的四次挥手

step1.  由客户端向服务器端发起连接请求。发送请求标识位SYN置为1,发送序号为一个随机数,这里假设为X;

step2.  服务器端接收到连接请求,将标识位ACK置为1,并将确认序号置为X+1,然后生成一个随机数Y作为发送序号(因为所确认的数据报的确认序号未初始化);

step3:  客户端对接收到的确认进行确认,将确认序号置为Y+1,然后将发送序号置为X+1(即为接收到的数据报的确认序号);

这里有几点需要说明一下:

1.为什么是三次握手而不是两次。对于step3的作用,假设一种情况,客户端A想服务器B发送一个连接请求数据报,然后这个数据报在网络中滞留导致其迟到了,虽然迟到了,但是服务器仍然会接收并发回一个确认数据报。但是A却因为久久收不到B的确认而将发送的请求连接失效,等到一段时间后,接到B发送过来的确认,A认为自己现在没有发送连接,而B却一直以为连接成功了,于是一直在等待A的动作,而A将不会有任何的动作了。这会导致服务器资源白白浪费掉了,因此,两次握手是不行的,因此需要再加上一次,对B发过来的确认再进行一次确认,即确认这次连接是有效的,从而建立连接。

2.对于双方,发送序号的初始化为何值。有的系统中是显式的初始化序号是0,但是这种已知的初始化值是非常危险的,因为这会使得一些黑客钻漏洞,发送一些数据报来破坏连接。因此,初始化序号因为取随机数会更好一些,并且是越随机越安全。

下面是一个简单的客户端/服务器端连接程序,在Linux环境下,开启三个终端,在第一个终端输入命令

利用tcpdump抓包工具监控TCP连接的三次握手和断开连接的四次挥手

然后在第二个终端运行服务器端程序:

利用tcpdump抓包工具监控TCP连接的三次握手和断开连接的四次挥手

最后在第三个终端运行客户端程序:

利用tcpdump抓包工具监控TCP连接的三次握手和断开连接的四次挥手

完了之后,我们可以在第一个终端看到抓包的结果,如下:

利用tcpdump抓包工具监控TCP连接的三次握手和断开连接的四次挥手

利用tcpdump抓包工具监控TCP连接的三次握手和断开连接的四次挥手

前三个数据包就是三次握手的三个数据报了。我们逐个分析一下,第一个数据报是由客户端发送到服务器端,随机产生一个序号seq = 830831828。然后第二个数据报是由服务器端发回的确认,随机产生一个序号seq = 2690963443,然后根据接收到的请求数据报将确认序号设置为830831829。然后第三个数据报是有客户端对服务器端确认数据报的确认,可以看出确认序号为2690963444

四次挥手

连接双方在完成数据传输之后就需要断开连接。由于TCP连接是属于全双工的,即连接双方可以在一条TCP连接上互相传输数据,因此在断开时存在一个半关闭状态,即有有一方失去发送数据的能力,却还能接收数据。因此,断开连接需要分为四次。主要过程如下:

利用tcpdump抓包工具监控TCP连接的三次握手和断开连接的四次挥手

主要过程如下:

step1.  主机A向主机B发起断开连接请求,之后主机A进入FIN-WAIT-1状态;

step2.  主机B收到主机A的请求后,向主机A发回确认,然后进入CLOSE-WAIT状态;

step3.  主机A收到B的确认之后,进入FIN-WAIT-2状态,此时便是半关闭状态,即主机A失去发送能力,但是主机B却还能向A发送数据,并且A可以接收数据。此时主机B占主导位置了,如果需要继续关闭则需要主机B来操作了;

step4.  主机B向A发出断开连接请求,然后进入LAST-ACK状态;

step5.  主机A接收到请求后发送确认,进入TIME-WAIT状态,等待2MSL之后进入CLOSED状态,而主机B则在接受到确认后进入CLOSED状态;

这里有几点需要说明:

1.  为何主机A在发送了最后的确认后没有进入CLOSED状态,反而进入了一个2MSL的TIME-WAIT。主要作用有两个:第一,确保主机A最后发送的确认能够到达主机B。如果处于LAST-ACK状态的主机B一直收不到来自主机A的确认,它会重传断开连接请求,然后主机A就可以有足够的时间去再次发送确认。但是这也只能尽最大力量来确保能够正常断开,如果主机A的确认总是在网络中滞留失效,从而超过了2MSL,最后也无法正常断开;第二,如果主机A在发送了确认之后立即进入CLOSED状态。假设之后主机A再次向主机B发送一条连接请求,而这条连接请求比之前的确认报文更早地到达主机B,则会使得主机B以为这条连接请求是在旧的连接中A发出的报文,并不看成是一条新的连接请求了,即使得这个连接请求失效了,增加2MSL的时间可以使得这个失效的连接请求报文作废,这样才不影响下次新的连接请求中出现失效的连接请求。

2.  在下面的抓包实验中,为什么断开连接请求报文只有三个,而不是四个。因为在TCP连接过程中,确认的发送有一个延时(即经受延时的确认),一端在发送确认的时候将等待一段时间,如果自己在这段事件内也有数据要发送,就跟确认一起发送,如果没有,则确认单独发送。而我们的抓包实验中,由服务器端先断开连接,之后客户端在确认的延迟时间内,也有请求断开连接需要发送,于是就与上次确认一起发送,因此就只有三个数据报了。

http://blog.csdn.net/hulifangjiayou/article/details/47283387

上一篇:【循序渐进学Python】8.面向对象的核心——类型(下)


下一篇:JS获取标签方法及兼容处理