TCP的三次握手和四次挥手

传输控制协议TCP简介

• 面向连接的、可靠的、基于字节流的传输层通信协议
• 将应用层的数据流分割成报文段并发送给目标节点的TCP层
• 数据包都有序号，对方收到则发送ACK确认，未收到则重传
• 使用校验和来校验数据在传输过程中是否有误

TCP报文头

其中：
seq是32位序号，ack是32位确认序号

TCP Flags
URG：紧急指针标志
ACK：确认序号标志
PSH：push标志
RST：重置连接标志
SYN：同步序号，用于建立连接过程
FIN：finsh标志，用于释放连接

TCP的三次握手

“握手”是为了建立连接，TCP三次握手的流程图如下：

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

• 第一次握手：建立连接时，客户端发送SYN包（seq = x）到服务器，并进入SYN_SEND状态，等待服务器确认；
• 第二次握手：服务器收到SYN包，必须确认客户的SYN（ack = x+1），同时自己也发送一个SYN包（seq = y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
• 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认表ACK（ack = y+1），此包发送完毕，客户端和服务端进入ESTABLISHED状态，完成三次握手。

为什么需要三次握手才能建立起连接？
为了初始化Sequence Number的初始值，通信的双方要互相通知对方自己的初始化Sequence Numbe，作为以后的数据通信序号，以保证应用层接收到的数据不会因为网络上的传输问题而乱序，即TCP会用这个序号来拼接数据。

首次握手的隐患——SYN超时
问题起因分析：

• Server收到Client的SYN，回复SYN-ACK的时候未收到ACK确认
• Server不断重试直至超时，Linux默认等待63秒才断开连接

产生的问题：SYN超时可能使服务器遭到会带来恶意程序攻击的危险。
针对SYN Flood的防护措施：

• SYN队列满后，通过tcp_syncookies参数回发SYN Cookie
• 若为正常连接则Client会回发SYN Cookie，直接建立连接

建立连接后，Client出现故障怎么办？
保活机制：

• 向对方发送保活探测报文，如果未收到响应则继续发送
• 尝试次数达到保活探测次数仍未收到响应则中断连接

TCP的四次挥手

“挥手”是为了终止连接，TCP四次挥手的流程图如下：

TCP采用四次挥手来释放连接

• 第一次挥手： Client 发送一个 FIN ，用来关闭 Client 到 Server 的数据传送，之后 Client 进入 FIN_WAIT_1 状态；
• 第二次挥手： Server 接收到 FIN 后，发送一个 ACK 给 Client ，确认序号为收到序号 +1 （与 SYN 相同，一个 FIN 占用一个序号）， Server 进入到 CLOSED_WAIT 状态， Client 进入到 FIN_WAIT_2 状态；
• 第三次挥手： Server 发送一个 FIN ，用来关闭 Server 到 Client 的数据传送， Server 进入 LAST_ACK 状态；
• 第四次挥手： Client 收到 FIN 后， Client 进入 TIME_WAIT 状态，接着发送一个 ACK 给 Server ，确认序号为收到序号 +1 。紧接着 Server 进入 CLOSED 状态，完成四次挥手。

为什么会有 TIME_WAIT 状态？
原因：

• 确保有足够的时间让对方收到ACK包
• 避免新旧连接混淆

为什么需要四次挥手才能断开连接？
因为全双工，发送方和接收方都需要 FIN 报文和 ACK 报文，即发送方和接收方各只需两次挥手即可，只不过有一方是被动的，所以看上去就成了所谓的四次挥手。

服务器出现大量 CLOSE_WAIT 状态的原因
对方关闭 socket 连接，我方忙于读或写，没有及时关闭连接
措施：

• 检查代码，特别是释放资源的代码
• 检查配置，特别是处理请求的线程配置