TCP的三次握手，四次挥手

TCP建立连接的三次握手：

客户端在此过程中的工作流程如下：

1.先调用socket创建套接字
2.调用connect发起连接请求，在这个过程中就会出现三次握手的情况：

• 客户端先向服务器发送一个带有SYN(同步序列号）连接请求，发送完之后客户端处于SYN_SENT状态（此为第一次握手）
• 服务器收到连接请求后，对客户端发一个SYN+ACK（确认应答），表示同意连接请求，服务端从listen状态变为SYN_RVCD状态（此为第二次握手）
• 当客户端收到服务器的SYN+ACK报文段后，也会向服务器发送ACK应答此时客户端处于ESTABUSHED状态，当服务器收到SYN确认应答后也会处于ESTABUSHED状态，到此，连接建立成功。（此为第三次握手）

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攻击了

3.建立连接后开始收发数据（先发后收）

TCP的四次挥手（断开连接）：

• 主动想断开连接一方（假设是客户端）会向另一方发送一个FIN包，进入FIN_WAIT_1状态（此为第一次）
• 服务器收到请求后，向客户端发送一个ACK应答，表示我收到了，然后服务器进入CLOSE_WAIT状态（此为第二次）
• 客户端收到应答后进入FIN_WAIT_2状态，等待服务器调用close发起关闭请求
• 服务器调用close向客户端发送一个FIN包，进入LAST_ACK状态（此为第三次）
• 客户端收到后也向服务器发送一个ACK应答，然后客户端进入TIME_WAIT状态（此状态只有主动关闭的一方才会有），服务端收到后就进入CLOSED状态（此为第四次）

上述为三次握手和四次挥手的过程
面试中还会问道这样的问题：
**

1.为什么建立连接需要三次握手而不是两次？

**

• 主要是为了防止已失效的连接请求重新到达服务器。假设客户端给服务器第一次发送连接请求后，由于网络原因导致请求被滞留，当超过一定的时间后，客户端没有收到服务器的应答，就认为可能发生了丢包，就会重新发送请求连接，如果是两次握手连接，服务器收到请求后向客户端作出回应，连接成功，收发完数据，关闭连接。在网络畅通后，之前被滞留的请求到达服务器后，会重新建立连接，造成不必要的资源浪费。如果是三次握手连接，即使那条失效的请求重新到达服务器后，服务器作出了应答，但是因为客户端不会再向服务器作出确认应答，所以服务器就不会认为这是客户端的请求连接

2.为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

• 因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

2.为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

• 保证在两个传输方向上的尚未被接受到或迟到的报文段都已经消失（否则服务器立即重启可能收到来自上一个进程迟到的数据，这种数据很可能是错误的）
• 同时也是在保证最后一条报文可靠到达（假设一个ACK丢失，服务器就会重新向客户端发送一个FIN，此时虽然客户端的进程不在了，但是TCP连接还在，仍然可以重新发LAST_ACK）