TCP中三次握手与四次挥手

前言

​ 看了下“三次握手”和“四次挥手”，本以为这就是TCP，但其实TCP远不止这些。面对网络中纷繁复杂的情况，作为承诺传输可靠的TCP协议，需要解决很多问题。例如：

• 怎么保证数据是可靠的？ ---连接确认，关闭确认，收到数据确认，各种确认
• 因为网络或其他原因，对方收不到数据怎么办？ ---超时重试
• 网络情况千变万化，超时时间怎么确认？ --根据RTT动态计算
• 网络拥塞怎么办？ ---慢启动，拥塞避免，快速重传，快速恢复
• 发送速度和接收速度不匹配怎么办？ ---滑动窗口

其中任何一个步骤都蕴含着精妙的算法，我们不需要知道其中算法是如何写的，只需要懂得解决的过程就可。

一.TCP是什么

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

1.1 OSI七层模型

​ 我们需要知道TCP工作在OSI模型中的第四层——Transport层。当发送端发送数据时，从应用层发下来，每一层都会添加头部信息，进行封装，而数据接受端得到数据后也会每一层都会解封装。

​ 在OSI模型中，每一层对应的作用和协议如下：

​ TCP是一个其中传输层的一个协议，那这个协议是如何定义，数据格式又是什么样子的呢？接下来进行进一步的剖析。

1.2 TCP头部

单位为字节（byte）

​ 上面就是TCP协议的头部格式，这张图是非常重要，对于理解TCP协议有很重要的帮助，接下来就详细说明一下各个字段

• 源端口（Source Port）和目的端口（Destination Port）：

  首先来说，如何确认为唯一的标示连接呢？答案TCP四元组——源IP、源端口、目标IP、目标端口。由于IP是在网络层IP协议处理，所以端口号配合IP首部的IP地址就可以确定唯一的TCP连接

• 序列号（Sequence Number）：

  用来标示从TCP发端向TCP收端发送的数据字节流，他表示在这个报文段第一个字节的序列号。序列号长为4个字节，是32位无符号整数，表示范围为0 ～2^32-1，如果到达最大值后就循环到0

  序列号在TCP通信中有两个作用：

  • 在SYN报文中交换彼此的初始化序列号
  • 解决网络乱报序的问题

• 初始序列号（Initial Sequence Number）：

  在三次握手的过程中，双方通过SYN报文来交换彼此的ISN。ISN并不是一个固定的值，而是每4ms加1，溢出则回到0，这个算法使得预测ISN变得很困难。因为IP端口号以及IP是很容易伪造的，当攻击者猜测ISN之后，直接伪造一个RST后，就可以强制连接关闭。

• 确认号（Acknowledgement number）：

  32位确认序列号包含发送确认一端所期望收到的下一个序列号。因此，确认序列号应当是上次收到的数据字节序号加1。不过，只有当标志位ACK标志为1时确认号才能生效。

• TCP标志（TCP Flags）：

  TCP首部有6个标志比特，他们主要的意思如下：

  • SYN：表示同步序号，用来建立连接。SYN标志和ACK标志位搭配使用，当连接请求的时候，SYN为1，ACK为0；当连接被响应的时候 SYN为1，ACK为1
  • ACK：此标志表示应答域有效，1表示有效，0表示无效。
  • FIN：表示发送端已经到了数据末尾，也就说说双发数据传送完成，发送FIN请求断开。
  • RST：表示复位请求，强制断开连接
  • PSH：用于当数据包到达接受端时，立即传送给应用程序，而不在缓冲区排队。
  • URG：TCP的紧急指针域，用来保证TCP连接不被中断，并督促中间层要尽快处理这些数据

• Window：

  窗口大小，也就是有名的滑动窗口，用来进行流量控制。

• 检验和：

  占用两个字节，防止传输过程中数据包有损坏。

• 可选项：

  常见的可选项

  • TimeSTamp：TCP时间戳
  • MSS：指的是TCP容许的从对方接受最大报文段

二. 三次握手（重点）

2.1 TCP三次握手的过程

上图是TCP三次握手的的过程

• 第一次握手：

  最开始双方都处于CLOSED状态，客户端发送请求报文段，服务器端也进入LISTEN状态。客户端将SYN置为1，Sequence Number 为x。然后，客户端进入SYN-SENT状态，等待服务器的确认。

• 第二次握手：

  服务端接收到SYN报文段，并将ACK置为1以及Acknowledgment Number置为x+1（Sequence Number +1）；同时，将SYN置为1以及Sequence Number置为y。服务器将上述所有放到一个报文段发送给客户端。并将自己的状态变为SYN-RCVD状态。

• 第三次握手：

  客户端接接收到SYN+ACK报文段，将Acknowledgment Number设置为y+1，Sequence Number置为y+1。向服务器发送ACK报文段，报文发送完后，自身进入ESTABLISHED，服务器端收到后也进入ESTABLISHED状态。

  完成三次握手后，客户端和服务器端开始传送数据。以上就是TCP三次握手的总体介绍。

2.2 TCP为什么是三次握手

为什么三次握手有不同的解释，这里引用几个解释：

1. TCP是一个可靠字节流传输连接，我们需要在不可靠信道中传输，为了使得其可靠，三次通信是理论的最小值

在Google Groups的TopLanguage中看到一帖讨论TCP“三次握手”觉得很有意思。贴主提出“TCP建立连接为什么是三次握手？”的问题，在众多回复中，有一条回复写道：“这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.”。这可视为对“三次握手”目的的另一种解答思路。

2. 在谢希仁的《计算机网络》中“为了防止已失效的连接请求报文段又重新传送到服务器端，因而产生错误”，主要是为了防止服务器一直等待而浪费资源

“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

三. 四次挥手

3.1 四次挥手的过程

• 第一次分手：

  主机1（可以是客户端，也可以是服务端），设置Sequence Number和ACknowledgment Number，并且发送Fin报文段，此时发送方进入FIN-WAIT-1状态，表示已经没有数据要发送给接收方，并且要断开连接了。

• 第二次分手：

  当主机2方发送的FIN 报文，就会向主机1发送ACK报文，以表示接收方同意断开连接的请求。并进入CLOSED-WAIT状态，当发送方收到时，主机1进入FIN-WAIT2状态。

• 第三次分手：

  随后，主机2向发送方发送FIN报文段，请求关闭连接，同时主机2进入LAST-ACK状态

• 第四次分手：

  主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL（Maximum Segment Lifetime 最大报文生存时间）后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。

至此，TCP四次分手正式分手成功。

3.2 为什么要等待2MSL

• 一个MSL确保四次挥手主动关闭方最后的ACK报文最终能到达对方
• 一个MSL确保对端没有收到ACK重传的FIN报文可以达到

3.3 为什么是四次挥手而不是三次挥手

​ 因为在服务端在接收到FIN，往往不会立即返回FIN，必须等到服务端所有的报文都发送完毕，才能发送FIN。因此先发一个ACK表示已经收到了客户端的FIN，延迟一段时间才发FIN。这就造成了四次挥手。

如果是三次挥手会怎么养？

​ 也就是说服务端将ACK和FIN发送合并为一次挥手，这个时候如果服务器端有很多数据正在发送，就会造成延迟很长时间才能发送FIN导致客户端以为自己发的FIN没有到达客户端，从而让客户端不断重发FIN

四. 半连接队列、全连接队列和SYN Flood攻击的关系

三次握手之前，服务端的状态从CLOSED变为LISTEN，同时在内部创建了两个队列：半连接队列 和全连接队列。也就是SYN队列和ACCEPT队列

4.1 半连接队列

第一次握手时，客户端发送SYN到服务器，服务器收到回复ACK和SYN，状态由LISTEN变为SYN_RCVD，此时这个连接就被推入了SYN队列，也就是半连接队列

4.2 全连接队列

当客户端返回ACK，服务端接收时，三次握手完成。这个时候连接等待着被应用取走，在被取走之前，他会被推入TCP维护的队列:全连接队列

4.3 SYN Flood攻击

SYN Flood 属于典型的DoS/DDoS攻击，攻击原理就是客户端短时间大量伪造不存在的IP地址，并且发送SYN。此时服务端会产生两个后果：

• 处理大量的SYN并返回ACK，大量的连接会处在SYN_RCVD状态，从而占满整个连接队列，无法处理正常的请求。
• 由于不存在的IP，服务端长期收不到回应，会不断的重发数据，耗尽服务端的资源。

4.4 如何应对SYN Flood攻击

• 增加半连接的容量
• 减少SYN+ACK的重试次数，避免大量的超时重发
• 利用SYN Cookie技术，在服务端收到SYN后不立即分配连接资源，而是根据这个SYN计算出一个Cookie，连同第二次握手回复给客户端，在客户端回复ACK时候带上这个Cookie值，服务端验证Cookie合法后才分配连接资源

搬运文章

通俗大白话来理解TCP协议的三次握手和四次分手

TCP协议灵魂之问，巩固你的网路底层基础

TCP协议详解