TCP的三次握手和四次挥手

Posted 2021-01-13 zzp-biog

TCP(Transmission Control Protocol)　传输控制协议。是一种面向连接的、可靠的、基于字节流的传输层通信协议。

 

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

两个序号和三个标志位：

  （1）序号：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
  （2）确认序号：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。
  （3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：

（A）URG：urgent，紧急指针有效
（B）ACK：acknowledgement，确认序号有效
（C）PSH：push，接收方应该尽快将这个报文交给应用层
（D）RST：reset，重置连接
（E）SYN：synchronous，发起一个新连接
（F）FIN：finish，释放一个连接

（G）sequence number：顺序号码

（H）acknowledge number：确认号码

（I）establish：建立、创建

 需要注意的是：
  （A）不要将确认序号ack与标志位中的ACK搞混了。
  （B）确认方的确认号码等于发起方的顺序号码加上数字1：ack=seq+1，两端配对。

 

第一次握手：A随机选取一个序列号x作为自己的初始序号发送给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并没有要求建立连接。