zoukankan      html  css  js  c++  java
  • 利用tcpdump抓包工具监控TCP连接的三次握手和断开连接的四次挥手

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

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

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

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

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

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

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

    5.ACK:确认序号有效;

    6.FIN:断开连接。

    三次握手

    三次握手的过程如下:

    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环境下,开启三个终端,在第一个终端输入命令

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

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

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

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

    四次挥手

    连接双方在完成数据传输之后就需要断开连接。由于TCP连接是属于全双工的,即连接双方可以在一条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

  • 相关阅读:
    Data Base mysql备份与恢复
    java 乱码问题解决方案
    【知识强化】第二章 物理层 2.1 通信基础
    【知识强化】第二章 进程管理 2.2 处理机调度
    【知识强化】第二章 进程管理 2.1 进程与线程
    【知识强化】第一章 操作系统概述 1.3 操作系统的运行环境
    【知识强化】第一章 网络体系结构 1.1 数据结构的基本概念
    【知识强化】第一章 网络体系结构 1.2 计算机网络体系结构与参考模型
    【知识强化】第一章 网络体系结构 1.1 计算机网络概述
    【知识强化】第一章 操作系统概述 1.1 操作系统的基本概念
  • 原文地址:https://www.cnblogs.com/findumars/p/7701617.html
Copyright © 2011-2022 走看看