TCP三次握手的异常情况探究

本文主要探究TCP三次握手出现的握手数据包丢失的情况的探究

首先来看TCP三次握手的正常情况

tcp-1

tcp正常握手的具体过程就不再细说,接下来主要说一下异常情况,分为3种情况

1. 客户端发送的SYN包丢失

对于服务端没有任何处理流程,因为根本不会收到这个SYN包

对于客户端,因为没有收到期望的服务端SYN,ACK包,因此会重传SYN包

2.服务端发送的SYN,ACK包丢失

对于服务端,因为没有收到期望的客户端的ACK包,因此会重传SYN,ACK包

对于客户端,与情况一类似,会重传SYN包

服务端在重传了一定次数的SYN,ACK包后,如果仍未收到客户端的ACK包,会断开此次连接

3.客户端发送的最后一个ACK包丢失

这里需要注意的点是客户端在接受到SYN,ACK包,再发ACK包,会进入连接状态.即客户端认为此次连接已经建立.

而服务端与情况二类似.会重传SYN,ACK包.注意此时的服务端仍然处于SYN-RCVD状态

这里考虑两种情况:

  1. 服务端重传SYN,ACK包后,收到了客户端的ACK包
  2. 服务端重传SYN,ACK包后,收到了客户端的数据包

对于情况一:

很显然连接是可以继续正常建立的.

tcp三次握手丢失测试4

注意图片中的红色部分为服务端的重传包,最后一条是客户端的ACK包,因此tcp可以正常建立

对于情况二:

重点是要需要弄清楚这里的服务端在SYN-RCVD状态收到数据包会如何处理.

tcp第三次握手丢失的测试

注意图片中红色部分为服务端的重传包,在重传后服务端直接收到了客户端发送的PSH,ACK数据包,然后服务端正常响应了ACK包.

这说明服务端在处于SYN-RCVD状态收到客户端发送的数据包也可以进入正常的连接建立状态.

其原因应该是因为服务端发送的SYN,ACK包中有指明自己的序列号为seq=0,然后客户端在发送数据包的时候也带上了确认号ack=1,这与正常tcp连接方式相同.可能因此可以正常建立tcp连接.

下面这张图是正常的tcp三次握手的连接过程,可以看到在第三个包中,有seq=1,ack=1与上面的数据包相似.

tcp第三次握手丢失的测试2

特殊情况4:客户端故意不发送最后的SYN包

在这种情况下,服务端因为没有收到客户端的ACK包,会不断重传自己的SYN,ACK包,直到重传次数达到上限,才会断开连接.但如果服务端在短时间内出现大量这种恶意的连接,服务端将会存在许多的半连接,会十分影响服务端的正常连接.这应该是称为SYN FLOOD攻击