zoukankan      html  css  js  c++  java
  • TCP三次握手详解及释放连接过程

    TCP在传输之前会进行三次沟通,一般称为“三次握手”,传完数据断开的时候要进行四次沟通,一般称为“四次挥手”。

    两个序号和三个标志位:

      (1)序号:seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。
      (2)确认序号:ack序号,占32位,只有ACK标志位为1时,确认序号字段才有效,ack=seq+1。
      (3)标志位:共6个,即URG、ACK、PSH、RST、SYN、FIN等,具体含义如下:
      (A)URG:紧急指针(urgent pointer)有效。
      (B)ACK:确认序号有效。
      (C)PSH:接收方应该尽快将这个报文交给应用层。
      (D)RST:重置连接。
      (E)SYN:发起一个新连接。
      (F)FIN:释放一个连接。

     需要注意的是:
      (A)不要将确认序号ack与标志位中的ACK搞混了。
      (B)确认方ack=发起方req+1,两端配对。

    在第一次消息发送中,A随机选取一个序列号作为自己的初始序号发送给B;

    第二次消息B使用ack对A的数据包进行确认,因为已经收到了序列号为x的数据包,准备接收序列号为x+1的包,所以ack=x+1,同时B告诉A自己的初始序列号,就是seq=y;

    第三条消息A告诉B收到了B的确认消息并准备建立连接,A自己此条消息的序列号是x+1,所以seq=x+1,而ack=y+1是表示A正准备接收B序列号为y+1的数据包。

    三次握手
    为什么A还要再发送一次确认呢?这主要是为了防止已失效的连接请求报文又传送到了B,因而产生错误
    所谓“已失效的连接请求报文段”是这样产生的,考虑一种正常情况,A发出连接请求,但因连接请求报文丢失而未收到确认,于是A再重传一次连接请求。后来收到了确认,建立了连接。数据传输完毕后,就释放了连接。A共发送了俩个连接请求报文段,其中第一个丢失,第二个到达了B。没有“已失效的连接请求报文段”
    现假定出现一种异常情况,即A发出的第一个连接请求报文段并没有丢失,而是在某些网络节点长时间滞留了,以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后,就误以为是A又发出一次新的连接请求。于是就向A发出确认报文段,同意建立连接。假定不采用三次握手,那么只要B发出确认,新的连接就建立了
    由于现在A并没有发出建立连接的请求,因此不会理睬B的确认,也不会向B发送数据。但B却以为新的运输连接已经建立了,并一直等待A发来数据。B的许多资源就这样白白浪费了。
    采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下,A不会向B的确认发出确认。B由于收不到确认,就知道A并没有要求建立连接

    四次挥手:
    由于TCP连接时全双工的,因此,每个方向都必须要单独进行关闭,这一原则是当一方完成数据发送任务后,发送一个FIN来终止这一方向的连接,
    收到一个FIN只是意味着这一方向上没有数据流动了,即不会再收到数据了,但是在这个TCP连接上仍然能够发送数据,直到这一方向也发送了FIN。
    首先进行关闭的一方将执行主动关闭,而另一方则执行被动关闭,上图描述的即是如此。
    (1)第一次挥手:client发送一个FIN,用来关闭client到server的数据传送,client进入FIN_WAIT_1状态
    (2)第二次挥手:server收到FIN后,发送一个ACK给client,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),server进入CLOSE_WAIT状态
    (3)第三次挥手:server发送一个FIN,用来关闭server到client的数据发送,server进入LAST_ACK状态
    (4)第四次挥手:client收到FIN后,client进入TIME_WAIT状态,接着发送一个ACK给server,确认序号为收到序号+1,server进入CLOSED状态,完成四次挥手

    (1)三次握手是什么或者流程?四次握手呢?答案前面分析就是
    (2)为什么建立连接是三次握手,而关闭连接却是四次挥手呢?
      这是因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。而关闭连接时,收到对方的FIN报文时,

    仅仅表示对方不再发送数据了但是还能接收数据,己方也未必全部数据都发送给对方了,所以己方可以立即close,也可以发送一些数据给对方后,

    再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送。

    为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

    不应该是为了防止B发送的FIN=1的包的丢失,因为如果A没有收到来自B的释放连接请求,是不会进入TIME-WAIT状态的。

    所以正确的解释是:A发送的确认释放连接信息B没有收到,这时候B会再次发送一个FIN=1的释放连接请求,而这个时候A还处于TIME-WAIT,所以可以再次发送确认信息




    知识点:

    1、ACK (Acknowledgement)即是确认字符,在数据通信中,接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。

    TCP/IP协议中,如果接收方成功的接收到数据,那么会回复一个ACK数据。通常ACK信号有自己固定的格式,长度大小,由接收方回复给发送方。
    2、全双工(Full Duplex)是通讯传输的一个术语。通信允许数据在两个方向上同时传输,它在能力上相当于两个单工通信方式的结合。全双工指可以同时(瞬时)进行信号的双向传输(A→B且B→A)。指A→B的同时B→A,是瞬时同步的。

    除全双工外,还有两种数据传输方式:

      半双工,指可以分时进行信号的双向传输(A→B或B→A)。指A→B时,不能B→A;B→A时,不能A→B。即数据发送和数据接受是分时进行的。(汽车的单边放行。)
      单工,只允许A→B传送信息,而不能B→A传送 。(汽车的单行道。)
  • 相关阅读:
    UVM系统验证基础知识0(Questasim搭建第一个UVM环境)
    DDR3详解(以Micron MT41J128M8 1Gb DDR3 SDRAM为例)
    正则表达式的基本用法
    Veloce2 Emulator
    Perl入门
    哪一种验证方法最好?形式验证、硬件加速还是动态仿真?
    什么是形式验证?
    穆里尼奥之皮洛斯式胜利
    穆帅:孟菲斯是计划中重要的一部分
    CentOS Netstat命令
  • 原文地址:https://www.cnblogs.com/fmgao-technology/p/9189366.html
Copyright © 2011-2022 走看看