详解三次握手

简述三次握手的过程

应用场景：当客户端向服务器端发送数据之前，需要建立一个TCP连接

第一次握手：客户端向服务器端发送一个SYN请求包（序列号syn为x）,并进入SYN_SENT状态，等待服务器的确认

第二次握手：服务器端收到客户端发的包，并向服务器端发送确认请求包（syn序列号为y,ack确认号为x+1,SYN,ACK标志位为1），并进入SYN_RECV状态

第三次握手：客户端收到服务器端的包，并向服务器端发送ACK确认包（syn序列号为x+1,ack确认号为y+1）

此时客户端与服务器端都进入ESTABLISH状态，三次握手完成，然后就可以进行数据传输了

SYN洪泛攻击

服务器端收到客户端发送SYN请求包，而没有收到ACK确认包时，成为半连接状态，服务器维护一个半连接队列，需要为其开设一个条目，占用服务器的CPU，内存资源。
当服务器端没有收到客户端的ACK确认包时，会进行重传，当重传的次数超过系统规定的最大次数时，才会将该连接删除，并回收相应的资源
SYN洪泛攻击经常会和ip欺骗联合使用，客户端会在短时间内伪造大量的ip地址，向服务器不断发送SYN包，服务器回复确认包，等待客户端确认，由于源地址是不存在的，不可能得到回应，服务器就只能不断的超时重传，直至达到系统的规定的最大次数，这些伪造的SYN包将长时间占用半连接队列，正常的SYN请求被丢弃，目标系统就会运行缓慢，甚至引起网络堵塞，系统瘫痪。

为什么是三次握手，为什么不能两次？

对于应对SYN洪泛攻击来说，第三次握手肯定是必须的

如果客户端想建立连接，给服务端发了一个连接请求（SYN），但是由于网络中种种情况，导致没有及时到达服务端，这就导致客户端在很长一段时间中没有收到回复消息（ACK），这时客户端又给服务端发送一个SYN，这次的发送和接收的很顺利，很快就收到了ACK，但是这时之前的SYN终于到了服务端，服务端规规矩矩的为这个SYN申请资源，然后返回ACK。由于之前的SYN已经失效了，所以客户端也不会去理会这个ACK，但是傻乎乎的服务端并不知道这个SYN已经失效了，一直为他委会着资源，这就造成了资源的浪费。

或者这样理解:
如果是两次握手就成功建立连接的话，会出现这种情况：
客户端向服务器端发送SYN请求包，服务器端收到后，回复客户端ACK确认包，此时服务器端会认为已成功建立连接，开始向客户端发送数据包，但是可能由于网络或其他原因，客户端并没有收到服务器端回复的ACK确认包，所以会忽略服务器端发送的所有数据包，一直等待服务器端的ACK确认包，直到超时会再次向服务器端发送SYN请求包，而服务器端发送的数据包一直没有收到客户端的响应，会再次发送同样的数据包给客户端，等待客户端的响应。双方都在等待，就造成了死锁。

什么是死锁？

死锁就是指两个或两个以上的进程在执行过程中，因为争夺资源而造成的一种相互等待的现象。
死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。
对应的解决死锁问题的关键就是：让不同的session加锁有次序