zoukankan      html  css  js  c++  java
  • TCP基础知识(二)三次握手与四次挥手

    TCP详解(2):三次握手与四次挥手

    TCP(Transmission Control Protocol,传输控制协议)是基于连接的协议,也就是说,在正式收发数据前,必须和对方建立可靠的连接,就好像你给别人打电话,必须等线路接通了、对方拿起话筒建立了连接才能相互通话。 

    TCP三次握手的过程为:

    • 第一次握手:建立连接。客户端发送连接请求报文段,将SYN位置为1,Sequence Number为x;然后,客户端进入SYN_SEND状态,等待服务器的确认;

    • 第二次握手:服务器收到客户端的SYN报文段,需要对这个SYN报文段进行确认,设置Acknowledgment Number为x+1(Sequence Number+1);同时,自己自己还要发送SYN请求信息,将SYN位置为1,Sequence Number为y;服务器端将上述所有信息放到一个报文段(即SYN+ACK报文段)中,一并发送给客户端,此时服务器进入SYN_RECV状态;

    • 第三次握手:客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1,向服务器发送ACK报文段,这个报文段发送完毕以后,客户端和服务器端都进入ESTABLISHED状态,完成TCP三次握手。

    TCP用三次握手(three-way handshake)过程创建一个连接。在连接创建过程中,很多参数要被初始化,例如序号被初始化以保证按序传输和连接的强壮性。 
      一对终端同时初始化一个它们之间的连接是可能的。但通常是由一端打开一个套接字(socket)然后监听来自另一方的连接,这就是通常所指的被动打开(passive open)。服务器端被被动打开以后,用户端就能开始创建主动打开(active open)。 
      1)客户端通过向服务器端发送一个SYN来创建一个主动打开,作为三路握手的一部分。客户端把这段连接的序号设定为随机数 A。 
      2)服务器端应当为一个合法的SYN回送一个SYN/ACK。ACK 的确认码应为 A+1,SYN/ACK 包本身又有一个随机序号 B。 
      3)最后,客户端再发送一个ACK。当服务端受到这个ACK的时候,就完成了三路握手,并进入了连接创建状态。此时包序号被设定为收到的确认号 A+1,而响应则为 B+1。 

    为什么需要三次握手? 
      简单地说,就是要保证在一段有效时间内,双方收到对方的有效信息。 
      一个简单例子,A发给B,B回复A,如果A不再回复B,B如何知道A收到了自己的信息? 
      谢希仁版《计算机网络》中的例子是这样的,“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”。 
      不管哪个例子,都是为了满足”在不可靠信道上可靠地传输信息”这一需求。请注意这里的本质需求,信道不可靠,数据传输要可靠。还是那句话,就是要保证在一段有效时间内,双方收到对方的有效信息。

    Socket状态对应 
      Socket API 和 TCP 协议中各个状态是如何对应的呢?我们可以通过下图来看:

      

    2. 断开连接四次挥手 
      由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。比如服务器收到一个FIN只意味着客户端不再发送数据,但它还可以向客户端发送数据,当服务器不再发数据了,他也要向客户端发送FIN。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。 

    当客户端和服务器通过三次握手建立了TCP连接以后,当数据传送完毕,断开连接就需要进行TCP四次分手:

      • 第一次分手:主机1(可以使客户端,也可以是服务器端),设置Sequence Number和Acknowledgment 
        Number,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1状态;这表示主机1没有数据要发送给主机2了;

      • 第二次分手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment Number为Sequence

      • 第三次分手:主机2向主机1发送FIN报文段,请求关闭连接,同时主机2进入LAST_ACK状态;

      • 第四次分手:主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后,就关闭连接;此时,主机1等待2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,主机1也可以关闭连接了。

           FIN_WAIT_1: 当SOCKET在ESTABLISHED状态,主动关闭连接时,向对方发送FIN报文,此时该SOCKET进入到FIN_WAIT_1状态。当对方回应ACK报文后,则进入到FIN_WAIT_2状态。(主动方) 
      FIN_WAIT_2:处于FIN_WAIT_2状态下的SOCKET为半连接状态,等待对方发起断开要求,(注意对方可以在断开时捎带信息)稍后再关闭连接。(主动方) 
      TIME_WAIT: 收到了对方FIN报文,并发送出了ACK报文,等待2MSL后即可回到CLOSED状态了。 
      注意:在FIN_WAIT_1状态下,如果收到了对方同时带FIN和ACK标志的报文(复用一个报文)时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2状态。(主动方) 
      CLOSING(比较少见): 如果双方几乎同时试图断开一个SOCKET的话,那么就出现了双方同时发送FIN报文的情况,即会出现CLOSING状态,表示双方都试图关闭SOCKET连接。 
      CLOSE_WAIT: 等待关闭连接,当对方发送FIN报文,回应ACK报文给对方后,则进入到CLOSE_WAIT状态。如果此时没有数据发送给对方,就可以关闭这个SOCKET,发送FIN报文给对方,即关闭连接。(被动方) 
      LAST_ACK: 被动关闭方在发送FIN报文后,最后等待对方的ACK报文。当收到ACK报文后,进入到CLOSED状态。(被动方) 
      CLOSED: 连接中断。

  • 相关阅读:
    Centos8安装MySQL8(社区版)
    DateTime.Now 在.netcore下的格式问题
    HP Socket FAQ
    docker基本操作
    Win10-Docker和VMware运行环境冲突解决办法
    Centos8安装docker-compose
    .net5 RSA
    密码规则之数字、小写、大写、特殊字符,至少满足3个
    .net5 应用程序启动和停止事件
    MySQL中国省市区数据表
  • 原文地址:https://www.cnblogs.com/qlky/p/7344928.html
Copyright © 2011-2022 走看看