TCP连接的建立与释放及SYN Flood介绍

绝地灬酷狼 2022-05-14 22:47 248阅读 0赞

# Preface #

总结一下TCP连接的三次握手过程，连接释放的四次挥手过程，以及其原生的缺陷引起的SYN Flood的简单介绍。

--------------------

# 目录 #

*  Preface
 *  目录
    
     *  TCP连接建立——三次握手
        
         *  几个概念
         *  三次握手过程
         *  为什么是三次握手？
     *  缺陷引起的SYN Flood
        
         *  SYN Flood 攻击
         *  SYN Flood 防护措施
     *  TCP连接释放——四次挥手
        
         *  挥手过程
         *  为什么建立连接是三次握手，关闭连接却是四次握手？
         *  为什么TIME\_WAIT状态还需要等2MSL？
         *  关闭TCP连接一定需要4次挥手吗?

--------------------

## TCP连接建立——三次握手 ##

### 几个概念 ###

*  seq：序号，占4个字节，范围\[0,4284967296\],由于TCP是面向字节流的，传送的数据流中的每一个字节都编上一个序号，序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。此外序号是循环使用的
 *  ACK： 仅当ACK=1时确认字段才有效，当ACK=0时确认字段无效，并且TCP规定，在连接建立后所有的传送报文段都必须要把ACK置为1
 *  SYN：同步序列号，用来发起一个连接。当SYN=1而ACK=0时表明这是一个请求报文段；若对方同意连接，则响应报文中SYN=1，ACK=1
 *  FIN ：用来释放一个连接，当FIN=1表示此报文段的发送方已经发送完毕。并要求释放链接

![这里写图片描述][70]

### 三次握手过程 ###

服务端的TCP进程先创建传输控制块TCB，准备接受客户端进程的连接请求，然后服务端进程处于LISTEN状态，等待客户端的连接请求，如有，则作出响应。

*  客户端的TCP进程也首先创建传输控制模块TCB，然后向服务端发出连接请求报文段，该报文段首部中的SYN=1，ACK=0，同时选择一个初始序号 seq=i。**TCP规定，SYN=1的报文段不能携带数据，但要消耗掉一个序号**。这时，TCP客户进程进入SYN—SENT（同步已发送）状态，这是 TCP连接的第一次握手。
 *  服务端收到客户端发来的请求报文后，如果同意建立连接，则向客户端发送确认。确认报文中的SYN=1，ACK=1，确认号ack=i+1，同时为自己选择一个初始序号seq=j。**同样该报文段也是SYN=1的报文段，不能携带数据，但同样要消耗掉一个序号**。这时，TCP服务端进入SYN—RCVD（同步收到）状态，这是TCP连接的第二次握手。
 *  TCP客户端进程收到服务端进程的确认后,还要向服务端给出确认。确认报文段的ACK=1，确认号ack=j+1，而自己的序号为seq=i+1。 **TCP的标准规定，ACK报文段可以携带数据，但如果不携带数据则不消耗序号**，因此，如果不携带数据，则下一个报文段的序号仍为seq=i+1。这时，TCP连接已经建立，客户端进入ESTABLISHED（已建立连接）状态。这是TCP连接的第三次握手，可以看出第三次握手客户端已经可以发送携带数据的报文段了。
 *  当服务端收到确认后，也进入ESTABLISHED（已建立连接)状态。

![这里写图片描述][70 1]

### 为什么是三次握手？ ###

> 前俩比较容易理解，第三次握手看似多余其实不然，这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判。
> 
> 比如：客户端发送了一个连接请求报文段A到服务端，但是在某些网络节点上长时间滞留了，而后客户端又超时重发了一个连接请求报文段B该服务端，而后 正常建立连接，数据传输完毕，并释放了连接。但是请求报文段A延迟了一段时间后，又到了服务端，这本是一个早已失效的报文段，但是服务端收到后会误以为客户端又发出了一次连接请求，于是向客户端发出确认报文段，并同意建立连接。那么问题来了，假如这里没有三次握手，这时服务端只要发送了确认，新的 连接就建立了，但由于客户端没有发出建立连接的请求，因此不会理会服务端的确认，也不会向服务端发送数据，而服务端却认为新的连接已经建立了，并在 一直等待客户端发送数据，这样服务端就会一直等待下去，直到超出保活计数器的设定值，而将客户端判定为出了问题，才会关闭这个连接。这样就浪费了很多服务 器的资源。而如果采用三次握手，客户端就不会向服务端发出确认，服务端由于收不到确认，就知道客户端没有要求建立连接，从而不建立该连接。

--------------------

## 缺陷引起的SYN Flood ##

### SYN Flood 攻击 ###

SYN- Flood攻击是当前网络上最为常见的DDoS攻击，也是最为经典的拒绝服务攻击，它就是利用了TCP协议实现上的一个缺陷，通过向网络服务所在端口发送大量 的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现，但至今仍然显示出强大的生命力。很多操作系统，甚至防火墙、路由器都无法有效地防御这种攻击，而且由于它可以方便地伪造源地址，追查起来非常困难。它的数据包特征通常是，源发送了大量的SYN包，并且缺少三次握手的最后一步握手ACK回复。

原理：攻击者首先伪造地址对服务器发起SYN请求，服务器回应(SYN+ACK)包，而真实的IP会认为，我没有发送请求，不作回应。服务器没有收到回应，这样的话，服务器不知道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp\_syn\_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者如果处于公网，可以伪造IP的话，对于服务器就很难根据IP来判断攻击者，给防护带来很大的困难。

### SYN Flood 防护措施 ###

主要通过以下3种方式:

*  无效连接监视释放

> 这种方法不停的监视系统中半开连接和不活动连接，当达到一定阈值时拆除这些连接，释放系统资源。这种绝对公平的方法往往也会将正常的连接的请求也会被释放掉，”伤敌一千，自损八百“

*  延缓TCB分配方法

SYN Flood关键是利用了，SYN数据报文一到，系统立即分配TCB资源，从而占用了系统资源，因此有俩种技术来解决这一问题

Syn Cache技术

> 这种技术在收到SYN时不急着去分配TCB，而是先回应一个ACK报文，并在一个专用的HASH表中（Cache）中保存这种半开连接，直到收到正确的ACK报文再去分配TCB

Syn Cookie技术

> Syn Cookie技术则完全不使用任何存储资源，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方 的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源

*  使用SYN Proxy防火墙  
    原理：对试图穿越的SYN请求进行验证之后才放行。

--------------------

## TCP连接释放——四次挥手 ##

### 挥手过程 ###

![这里写图片描述][70 2]

> 数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。

*  客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 **TCP规定，FIN报文段即使不携带数据，也要消耗一个序号**。
 *  服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
 *  客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
 *  服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，**由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w**，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
 *  客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
 *  服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

![这里写图片描述][70 3]

### 为什么建立连接是三次握手，关闭连接却是四次握手？ ###

> 这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

PS：实际用抓包工具抓包分析时，有时候会发现TCP的释放只有三次的挥手，那是因为客户端发送请求断开连接后，服务器没有数据要再发给客户端了，所以把第二次的ACK和第三次的FIN两次的TCP报文段合成了一次ACK+FIN发送。

### 为什么TIME\_WAIT状态还需要等2MSL？ ###

> MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。  
> 第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。  
> 第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

### 关闭TCP连接一定需要4次挥手吗? ###

> 不一定，4次挥手关闭TCP连接是最安全的做法。但在有些时候，我们不喜欢TIME\_WAIT 状态(如当MSL数值设置过大导致服务器端有太多TIME\_WAIT状态的TCP连接，减少这些条目数可以更快地关闭连接，为新连接释放更多资源)，这时我们可以通过设置SOCKET变量的SO\_LINGER标志来避免SOCKET在close()之后进入TIME\_WAIT状态，这时将通过发送RST强制终止TCP连接(取代正常的TCP四次握手的终止方式)。但这并不是一个很好的主意，TIME\_WAIT 对于我们来说往往是有利的。

[70]: /images/20220515/c361802090044d37a9df00315f57b648.png
[70 1]: /images/20220515/38271552838d47d7be92895f55dc39dd.png
[70 2]: /images/20220515/82eab25bb972466ca2e5497853d1d429.png
[70 3]: /images/20220515/c598fa4773704658afe8539a6f1d45e6.png