TCP三次握手和四次挥手

---

一、三次握手和四次挥手

1、三次握手

第一次握手：客户端向服务端发送包含自身初始序号x的同步报文，进入SYN-SENT状态。

第二次握手：服务端收到连接请求报文段后，会将连接放入半连接队列中，并向客户端发送包含自身初始序号y的同步确认报文，进入SYN-RECEIVED状态。

第三次握手：客户端收到应答，向服务端发送确认报文，进入ESTABLISHED状态，此时成功建立长连接。

2、四次挥手

第一次挥手：客户端数据发送完毕，向服务端发送终止报文请求释放连接。

第二次挥手：服务器收到连接释放请求，告诉应用层释放TCP连接。然后发送确认报文，进入CLOSE-WAIT状态，此时表明客户端到服务端的连接已经释放，不再接受客户端的数据。但因为TCP是全双工的，所以服务器仍可以发送数据。

第三次挥手：当服务端数据发送完毕，向客户端发送终止报文，发送连接释放请求，进入LAST-ACK状态。

第四次挥手：客户端收到连接释放请求，向服务器端发送确认报文，此时客户端进入TIME-WAIT状态，会等待2MSL（最长报文段寿命），若期间没有收到服务器端的数据报文，进入CLOSED状态。服务器端在收到确认应答后也进入CLOSED状态。

---

二、为什么是三次握手而不是两次或者四次

两次不安全，四次没必要。

TCP通信需要确保双方都具有数据收发的能力。

• 第一次带有SYN的ACK向客户端表明了服务端的收发能力，同时也验证了客户端自己的收发能力。
• 第二次的ACK则向服务端表明了客户端的收发能力，同时也验证了服务端自己的收发能力。

---

三、三次握手哪次可以携带数据

第一次和第二次不能携带数据，第三次可以携带数据。

• 如果第一条同步报文可以携带数据，当有人恶意攻击服务器时，就可以在第一次握手中携带大量额外数据来攻击服务器缓存。
• 第二次握手由服务器发起，服务器 作为被动连接方，没有必要携带数据。

---

四、三次握手失败服务器会如何处理

握手失败有两种原因：

• 一种是服务端没有收到SYN，此时不会做任何响应。
• 另一种情况是服务端在回复了SYN+ACK报文后长时间没有收到ACK响应，此时服务端会在超时之后发送RST报文重置连接，释放资源。

---

五、ISN

ISN全称是Initial Sequence Number，是TCP发送方数据编号的起点。

TCP每次建立连接时，初始化序列号都不一样。如果ISN是固定的，一方面攻击者很容易猜出后序的确认号，从而发送伪造的TCP报文，另一方面在网络拥塞等情况下很有可能导致历史报文被下一个相同的四元组（源目套接字）接收。因此ISN一般都基于随机算法生成，同时还会整合时间戳等信息以避免序号回绕。

---

六、半连接队列和全连接队列

服务器第一次收到客户端的SYN之后会处于SYN_RCVD状态，此时双方还没有完全建立连接，服务器会把这种状态下的连接放在**半连接队列（syn队列）中，半连接队列可以在一定程度上抵御syn泛洪攻击。而全连接队列（accept队列）**则保存着已经完成三次握手，已经建立起来的连接。

半连接队列和全连接队列都有最大长度限制，超出限制时内核会直接丢弃收到的报文或返回一个RST包，其中直接丢弃可以更好地应对突发流量。

---

七、为什么握手三次，而挥手需要四次

TCP握手时服务端将SYN和ACK合并在一个包中发送，因此减少了一次握手。

对于四次挥手，由于TCP是全双工通信，客户端（或者说主动关闭方）发送FIN请求只能表示客户端不再发送数据了，不代表完全断开连接，服务端（或者说被动关闭方）可能还要发送数据。所以不能将服务端的FIN包和对客户端的ACK包合并发送，只能先确认主动关闭方的FIN，等服务端数据发送完毕时再发送FIN包，故挥手需要四次。

---

八、TIME_WAIT状态有什么作用，主动关闭方为什么不直接进入CLOSED状态释放资源

假设主动关闭方最后发送的ACK在网络中丢失，由于TCP协议的重传机制，被动关闭方将会重发其FIN，在该FIN到达主动关闭方之前，主动关闭方必须维护该连接（即该TCP连接所对应的套接字等资源不能被释放或重新分配）。直到客户端收到服务器重发的FIN之后重发ACK，再经过2MSL（客户端ACK到达+服务器FIN到达）没有再收到新的FIN之后，该TCP连接才能恢复CLOSED状态。

如果主动关闭方不维护这样一个TIME_WAIT状态，那么当被动关闭方重发的FIN到达时，主动关闭方会用RST包响应对方，使得正常的关闭连接过程变为异常。