计算机网络:TCP三次握手可能出现的问题及攻击手段

---

前言

对于TCP三次握手和四次挥手大多数读者想必已经烂熟于心，但是对于TCP三次握手和四次挥手之间可能出现的问题，很多时候我们并没有给予细致的关注，笔者依然如此，因而想借周末的晚上，对相关问题进行一番整理

先放一张TCP三次握手的图

再放一张TCP四次挥手的图

一、握手阶段消息丢失

现象：TCP在握手/挥手阶段发出的消息在数据传播的过程中丢失
解决原则：ACK不会重传，SYN和FIN报文段有最大重传次数。无论是SYN还是FIN，达到最大重传次数后对端若仍无响应则直接进入CLOSED状态。

第一次握手消息丢失（SYN)

正常：当客户端想要与服务器建立TCP连接时，首先要发送第一个SYN报文段，然后将本端的TCP状态置为 SYN_SENT。
异常：客户端没有收到服务端的ACK确认回应，接下来便会进入超时重传阶段

• 超时时间判断： 不同版本的操作系统可能超时时间不同，一般为 1秒 或 3秒，由内核配置，修改需要重新编译内核。

• 重传次数： 由内核参数 tcp_syn_retries 配置，默认值为5，可手动修改。

• 重传周期： 按指数退避计算重传周期，第一次超时重传是 1秒，第二次超时重传是 2秒，第三次超时重传是 4秒，第四次超时重传是 8秒，第五次超时重传是 16秒，以类类推，直到达到最大重传次数后，客户端不再重传SYN报文段，断开TCP连接。 此时 connect会返回 -1，并设置 errno 为 ETIMEOUT。

• 如果达到默认最大重传次数后断开TCP连接，总耗时为：
  1+2+4+8+16+32 = 63秒，大约 1分钟。

关于TCP内核参数的修改：

所有TCP/IP参数（注意是TCP/IP协议族的所有参数，不止TCP参数）都位于 /proc/sys/net目录下，注意此目录下的内容修改都是临时的，任何修改在系统重启后都会丢失。

例如对 tcp_syn_retries 参数的修改：

echo 5 > /proc/sys/net/ipv4/syn_timeout_retries

第二次握手消息丢失（SYN+ACK）

正常：服务端在收到客户端的第一次握手SYN报文段后，将TCP状态置为 SYN_RECV状态，并发送SYN+ACK报文段给客户端。
异常：如果第二次握手的报文段丢失，服务端会发起重传；客户端由于收不到SYN+ACK，无法判断是第一次握手的SYN报文段丢失，还是第二次握手的SYN+ACK报文段丢失，所以客户端也会发起重传。
这一情况可能会导致客户端和服务端一起发生重传，重传过程如第一部分所述，服务端的 SYN+ACK重传次数由参数 tcp_synack_retries 配置。

第三次握手消息丢失（ACK）

正常：客户端在收到服务端的第二次握手SYN+ACK报文段后，将TCP状态置为 ESTABLISH 状态，并发送ACK报文段给服务端。
异常：如果第三次握手的ACK报文段丢失，则服务会重传SYN+ACK报文段，直到收到ACK响应或者达到最大重传次数。
第三次握手的ACK报文段没有重传，当ACK丢失，只能依靠服务端重传SYN+ACK报文段。

如果握手阶段ACK持续丢失，那么对于服务端来说会发生以下情况：

• 超过服务端最大回传次数，放弃此次连接，服务端状态充值

对于客户端来说，会发生以下两种情况

• 未发送数据，等到一定时间后，客户端会检查连接状态，发现检查失败，那状态重置，将连接从半连接状态中移除
• 发送数据，得不到服务端的回应，然后发现连接失败，那状态重置

二、握手阶段队列已满

我们知道，对于客户端和服务端之间的连接，其实存在半连接队列和全连接队列：

• 服务端收到客户端发送的第一次握手syn标志位，该连接进入半连接队列
• 服务端收到客户端发送的第三次握手ack标志位，该连接进入全连接队列

那从半连接到全连接之间的转化，其实并不一定成功，可能存在如下问题

服务端的全连接队列默认设置大小为50，而当client端发送ack，服务端收到时，服务端会如何处置，会根据服务端配置的tcp_abort_on_overflow进行判断，具体会发生如下场景

• 全连接队列未满，当server收到client的ack后会先判断全连接队列accept queue是否已满，如果队列未满则从半连接队列拿出相关信息存放入全连接队列中，之后服务端accept()处理此请求。
• 当全连接已满且tcp_abort_on_overflow = 0，server会扔掉client 发过来的ack。之后隔一段时间server会重发握手第二步的syn+ack包给client，如果客户端连接一直排队不上等待超时则会报超时异常。
• 全连接已满且tcp_abort_on_overflow = 1时，server会发送一个reset包给client，表示废除这个握手过程和这个连接(客户端会报connection reset by peer异常)

三、SYN洪泛攻击

1.洪泛攻击是什么

syn洪泛攻击是Dos攻击的一种，服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击，SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复SYN+ACK确认包，并等待Client确认回复ACK,而这些大量的IP是不存在的，并不会向服务端发送ack确认包，所以会大量的占领半连接队列资源，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。

具体如图

2.解决措施

使用syn cookie解决，服务器在第二次握手时不会为第一次握手的SYN创建半开连接，而是生成一个cookie一起发送给客户端，只有客户端在第三次握手发送ACK报文并且验证cookie成功服务器才会创建TCP连接，分配资源。