TCP三次握手详解和SYN攻击

有很多三次握手的文章，我觉得讲的都比较不容易懂，有点冗杂，下面我来总结一下。

 

三次握手的过程：

说到三次握手，大家肯定都会用这张图，我这里也用这张图了，下面来看看这个过程：

第一次握手：client首先发送SYN（Synchronization）报文给server，此时，client进入SYN_SENT状态，等待server端确认；注：SYN报文的特点：SYN标识位置1，随机产生一个值seq=X，占用一个序列号。

第二次握手：server收到client发过来的SYN包后知道client请求建立连接，将产生一个SYN+ACK包发送给client以确认连接请求，此时server进入SYN_RCVD状态；注：SYN+ACK包的特点：SYN和ACK标识位都为1，ack=X+1,随机产生的seq=Y。

第三次握手：client收到server的SYN+ACK包，向server发送确认包ACK(ack=Y+1），此包发送完毕，client和server进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

完成三次握手，客户端与服务器开始传送数据，其实在第三次握手的同时，client就可以向sever发送数据了。

 

这样应该说的很明白了。

 

为什么是三次握手呢？

关于三次握手的目的，谢希仁的《计算机网络》中这么说“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。

“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。

假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

如果上面的解释太学术化了，还是有点蒙，没关系，看点生动形象点的东西吧（来自知乎网友的一个回答）。

三次握手

A：“喂，你听得到吗？”

B：“我听得到呀，你听得到我吗？”

A：“我能听到你”，今天blabla.....

三次握手正常建立连接

 

两次握手

A:“喂，你听得到吗？”

B:“我听得到呀”         

A:“喂，你听得到吗？” ----问题：A有可能没听到B的回答

B:“草，我听得到呀！！！！”

A:“你TM能不能听到我讲话啊！！喂！”

两次握手不能保证成功率

 

四次握手

A：“喂，你听得到吗？”

B：“我听得到呀，你听得到我吗？”

A：“我能听到你

B：你能听到我吗？     ----问题：这次完全是没必要的

A：“……不想跟傻逼说话”    

四次握手纯粹是浪费资源

 

弄懂了上面的过程，我们来看看什么是SYN攻击：

在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。

SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列（内核会为每个这样的连接分配资源的），导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了