TCP的三次握手过程

• 三次握手

客户端发送连接请求报文，服务端接收后回复ACK报文，并为此次连接分配资源。客服端接收到ACK报文后也向服务器端发送ACK报文，并分配资源，这样连接就建立好了。

AB两端的TCP进程开始时都处于CLOSED关闭状态，A主动打开连接，B被动打开连接。

    状态转化： 

A、B处于打开状态 - > B处于收听状态 - > A处于同步已发送SYN-SENT状态 - > B处于同步接受SYN-RCVD状态 - > A、B处于连接建立ESTAB-LISHED状态 

• 三次握手的具体过程：

1.第一次握手：当客服端A向服务器B发送连接请求前，A、B首先都会各自创建传输控制块TCB（存储每一个连接中的重要信息，如：TCP连接表、到发送和接受缓存的指针、到重传队列的指针、当前的发送和接受序号），同时B服务器也会处于LISTEN状态，等待客户端A的连接请求，当A向B发出连接请求报文段SYN时，首部的同步位SYN=1，初始序号seq=x（需要注意：SYN=1的报文段不能携带数据，但是需要消耗一个序号），而客服端A此时则处于SYN-SENT（同步已发送状态）状态。

2.第二次握手：服务器B收到请求报文后，如果同意连接，则发送确认报文。确认报文中则含有ACK=1，SYN=1,确认序号ack=x+1,同时为自己初始化一个序列号seq=y，此时服务器B进入SYN-RCVD（同步收到）状态。

3.第三次握手：客户端A收到没确认后，还需要向服务器B端给出确认。确认报文的ACK=1，确认序号ack=y+1,自己的序号为seq=x+1（需要注意：ACK报文段可以携带数据，如果不携带数据则不消耗序号），此时连接建立成功，客户端A、B进入ESTAB-LISHD（已建立连接）状态。

• 为什么是三次握手而不是两次？

****三次握手过程中需要能清楚的问题是为什么客户端最后还要发送一次确认呢？

答：使用的是两次握手连接，假设如果在一次TCP连接中，客户端发送了第一次请求只是在网络节点中滞留了较长的时间并没有丢失，客户端在限制时间内没有收到服务器B的确认报文，则认为服务器B没有收到请求，此时便重发这条报文，此后客服端和服务器端经过两次握手建立连接，完成数据的传输后释放连接。此时之前滞留的那一次请求连接网络通达了到达了服务器B，这时的这个报文应该是失效的，但是两次握手的机制会使得客户端与服务器再次建立连接，则会导致不必要的错误和资源的浪费。

如果是三次握手机制，当这条失效的报文传送过来了，服务端接受到后虽然回复了确认报文给客户端，但是客户端查看了确认报文不会再次发送确认，这一次连接不会再进行下去，则不会发生不必要的错误以及资源的浪费。

• SYN攻击

SYN攻击就是客户端在短时间没伪造大量不存在的IP地址，向服务端不断的发送SYN包，服务器收到后则回复确认包，并等待客服端确认，由于源地址并不存在，所以服务器需要不断重发知道超时，而此过程中这些伪造的SYN包长时间的占用未连接队列，导致正常SYN请求因为队满而被丢弃，从而引起网络拥塞甚至系统瘫痪。

SYN攻击是典型的DDOS攻击，当在服务器上看到大量半连接状态时，特别是IP地址是随机的，基本上可以断定这就是SYN攻击，而在Linux下可以可以使用netstat -n -p TCP | grep SYN_REC直接检测是否被SYN攻击。

防范SYN攻击措施:SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短主机的等待时间等