TCP为什么是三次握手

前两次比较容易理解，第三次握手看似比较多余，其实不是。第三次握手主要是为了防止已失效的请求报文段又突然传送到了服务端而产生连接的误判。

比如：客户端发送了一个连接请求的报文段A到服务端，但是在某些网络节点上长时间滞留了，而后客户端又超时重发了一个连接请求的报文段B到服务端，而后正常建立连接，数据传送完毕之后释放连接。但是请求报文段A延迟了一段时间之后又发送到了服务端，报文段A原本是一个早已失效的报文段，但是服务端收到之后会误以为客户端又发来了一次连接请求，于是向客户端发出确认报文，并同意建立连接。

那么问题就出现了：假如这里没有第三次握手，这时只要服务端发送了确认，新的连接就建立了，但是由于客户端没有发出建立连接的请求，因此不会理会服务端的确认，也不会向服务端发送数据。而服务端却认为新的连接已经建立了，并一直等待客户端发送数据，直到超出保活计数器的设定值，而将客户端判定为出了问题，才会关闭这个连接。这样就浪费了很多服务器的资源。

如果采用三次握手，客户端就不会向服务端发出确认，服务端由于收不到确认，就知道客户端没有要求建立连接，从而不建立该连接。

TCP三次握手的缺陷(扩充了解)

原文出处：https://blog.csdn.net/xtzmm1215/article/details/47385079

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

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

解决办法：

  • 无效连接监视释放

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

  • 延缓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请求进行验证之后才放行