TCP三次握手及其背后的缺陷
概述
总结一下TCP中3次握手过程，以及其原生的缺陷 引起的SYN Flood的介绍
【1】TCP三次握手
【2】SYN Flood
1、TCP连接建立——三次握手
几个概念：
【1】seq：序号。占4个字节，范围[0,4284967296],因为TCP是面向字节流的。在一个1个TCP连接中传送字节流中国的每个字节都依照顺序编号。此外序号是循环使用的
【2】ACK： 仅当ACK=1时确认字段才有效，当ACK=0时确认字段无效，而且TCP规定，在连接建立后全部的传送报文段都必需要把ACK置为1
【3】SYN：同步序列号，用来发起一个连接。
当SYN=1而ACK=0时表明这是一个请求报文段；若对方允许连接，则响应报文中SYN=1，ACK=1
【4】FIN ：用来释放一个连接，当FIN=1表示此报文段的发送方已经发送完成。
并要求释放链接
1.1、3次握手过程
服务端的TCP进程先创建传输控制块TCB。准备接受client进程的连接请求，然后服务端进程处于LISTEN状态，等待client的连接请求，如有，则作出响应。
1、client的TCP进程也首先创建传输控制模块TCB，然后向服务端发出连接请求报文段，该报文段首部中的SYN=1，ACK=0。同一时候选择一个初始序号 seq=i。TCP规定。SYN=1的报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN—SENT（同步已发送）状态。这是 TCP连接的第一次握手。
2、服务端收到client发来的请求报文后，假设允许建立连接，则向client发送确认。确认报文中的SYN=1。ACK=1，确认号ack=i+1。同一时候为自己 选择一个初始序号seq=j。相同该报文段也是SYN=1的报文段，不能携带数据，但相同要消耗掉一个序号。
这时，TCP服务端进入SYN—RCVD（同 步收到）状态。这是TCP连接的第二次握手。
3、TCPclient进程收到服务端进程的确认后，还要向服务端给出确认。确认报文段的ACK=1。确认号ack=j+1，而自己的序号为seq=i+1。 TCP的标准规定，ACK报文段能够携带数据，但假设不携带数据则不消耗序号。因此。假设不携带数据。则下一个报文段的序号仍为seq=i+1。这 时。TCP连接已经建立。client进入ESTABLISHED（已建立连接）状态。这是TCP连接的第三次握手，能够看出第三次握手client已经能够发送携带
数据的报文段了。
当服务端收到确认后。也进入ESTABLISHED（已建立连接）状态。
1.2、关于第三次握手的解释
前俩比較easy理解。第三次握手看似多余事实上不然。这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判
比 如：client发送了一个连接请求报文段A到服务端，可是在某些网络节点上长时间滞留了，而后client又超时重发了一个连接请求报文段B该服务端，而后 正常建立连接。传输数据完成，并释放了连接。
可是请求报文段A延迟了一段时间后。又到了服务端，这本是一个早已失效的报文段，可是服务端收到后会误以为客 户端又发出了一次连接请求。于是向client发出确认报文段，并允许建立连接。那么问题来了。假如这里没有三次握手，这时服务端仅仅要发送了确认，新的
连接就建立了，但因为client没有发出建立连接的请求，因此不会理会服务端的确认，也不会向服务端发送数据，而服务端却觉得新的连接已经建立了。并在 一直等待client发送数据，这样服务端就会一直等待下去，直到超出保活计数器的设定值，而将client判定为出了问题，才会关闭这个连接。这样就浪费了非常多服务 器的资源。而假设採用三次握手，client就不会向服务端发出确认。服务端因为收不到确认，就知道client没有要求建立连接，从而不建立该连接。
2、 缺陷引起的SYN Flood
2.1、SYN Flood 攻击
SYN- Flood攻击是当前网络上最为常见的DDoS攻击。也是最为经典的拒绝服务攻击。它就是利用了TCP协议实现上的一个缺陷，通过向网络服务所在port发送 大量 的伪造源地址的攻击报文。就可能造成目标server中的半开连接队列被占满，从而阻止其它合法用户进行訪问。
这样的攻击早在1996年就被发现，但至今仍然显示 出强大的生命力。非常多操作系统，甚至防火墙、路由器都无法有效地防御这样的攻击。并且因为它能够方便地伪造源地址。追查起来非常困难。它的数据包特征通常 是。源发送了大量的SYN包。而且缺少三次握手的最后一步握手ACK回复。
原理：攻击者首先伪造地址对 server发起SYN请求。server回应(SYN+ACK)包，而真实的IP会觉得，我没有发送请求，不作回应。服务 器没有收到回应，这种话，server不知 道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这种话。对于server的内存，带宽都有非常大的消耗。攻击者 假设处于公网。能够伪造IP的话，对于server就非常难依据IP来推断攻击者，给防护带来非常大的困难。
2.2、SYN Flood 防护措施
主要通过下面3种方式
1． 无效连接监视释放
这样的方法不停的监视系统中半开连接和不活动连接。当达到一定阈值时拆除这些连接，释放系统资源。这样的绝对公平的方法往往也会将正常的连接的请求也会被释放掉，”伤敌一千，自损八百“
2． 延缓TCB分配方法
SYN Flood关键是利用了，SYN数据报文一到。系统马上分配TCB资源，从而占用了系统资源，因此有俩种技术来解决这一问题
Syn Cache技术
这样的技术在收到SYN时不急着去分配TCB。而是先回应一个ACK报文，并在一个专用的HASH表中（Cache）中保存这样的半开连接，直到收到正确的ACK报文再去分配TCB
Syn Cookie技术
Syn Cookie技术则全然不使用不论什么存储资源，它使用一种特殊的算法生成Sequence Number，这样的算法考虑到了对方的IP、port、己方IP、port的固定信息，以及对方无法知道而己方比較固定的一些信息，如MSS、时间等。在收到对方 的ACK报文后，又一次计算一遍，看其是否与对方回应报文中的（Sequence Number-1）同样，从而决定是否分配TCB资源
