面试官问我为啥TCP需要三次握手及四次挥手

TCP协议特点

TCP是传输层协议，具有以下特点：

• 基于链接：在传输数据之前需要建立连接，然后再进行传输。
• 双向通信：一旦建立连接，双方可以进行双向通信。
• 字节流传输：TCP以字节流为单位进行传输，将数据按字节大小进行编号，接收端通过 ACK 来确认收到的数据编号，通过这种机制，TCP 协议能够保证接收数据的有序性和完整性，因此 TCP 能够提供可靠性传输。
• 流量控制：使用滑动窗口机制控制数据发送速率。滑动窗口的本质是动态缓冲区，接收端根据自己的处理能力，在 TCP 的 Header 中动态调整窗口大小，通过 ACK 应答包通知给发送端，发送端根据窗口大小调整发送的的速度。
• 拥塞控制：通过慢启动、拥塞避免、拥塞发生和快速恢复等算法处理网络拥塞。

三次握手与四次挥手

三次握手建连

TCP 是基于链接的，所以在传输数据前需要先建立链接，TCP 在传输上是双工传输，不区分 Client 端与 Server 端，为了便于理解，我们把主动发起建连请求的一端称作 Client 端，把被动建立链接的一端称作 Server 端。

如下图，建连的时序是从上到下，左右两边的绿色字分别代表 Client 端与 Server 端当时的链接状态。

首先建立链接前需要 Server 端先监听端口，因此 Server 端建立链接前的初始状态就是 LISTEN 状态，这时 Client 端准备建立链接，先发送一个 SYN 同步包，发送完同步包后，Client 端的链接状态变成了 SYN_SENT 状态。Server 端收到 SYN 后，同意建立链接，会向 Client 端回复一个 ACK。

由于 TCP 是双工传输，Server 端也会同时向 Client 端发送一个 SYN，申请Server 向 Client 方向建立链接。发送完 ACK 和 SYN 后，Server 端的链接状态就变成了 SYN_RCVD。

Client 收到 Server 的 ACK 后，Client 端的链接状态就变成了 ESTABLISHED 状态，同时，Client 向 Server 端发送 ACK，回复 Server 端的 SYN 请求。

Server 端收到 Client 端的 ACK 后，Server 端的链接状态也就变成了的 ESTABLISHED 状态，此时建连完成，双方随时可以进行数据传输。

SYN 洪水攻击发生的原因，是 Server 端收到 Client 端的 SYN 请求后，发送了 ACK 和 SYN，但是 Client 端不进行回复，导致 Server 端大量的链接处在 SYN_RCVD 状态，进而影响其他正常请求的建连。可以设置 tcp_synack_retries = 0 加快半链接的回收速度，或者调大 tcp_max_syn_backlog 来应对少量的 SYN 洪水攻击。

四次挥手断连

TCP 链接的关闭，通信双方都可以先发起，我们暂且把先发起的一方看作 Client，从图中看出，通信中Client和Server 两端的链接都是 ESTABLISHED 状态，然后 Client 先主动发起了关闭链接请求，Client向Server 发送了一个FIN包，表示 Client 端已经没有数据要发送了，然后 Client 进入了 FIN_WAIT_1 状态。

Server 端收到 FIN 后，返回 ACK，然后进入 CLOSE_WAIT 状态。此时 Server 属于半关闭状态，因为此时Client向Server方向已经不会发送数据了，可是 Server 向 Client 端可能还有数据要发送。

当 Server 端数据发送完毕后，Server 端会向 Client 端发送 FIN，表示 Server 端也没有数据要发送了，此时Server进入 LAST_ACK 状态，就等待 Client 的应答就可以关闭链接了。

Client端收到 Server端的 FIN 后，回复 ACK，然后进入 TIME_WAIT 状态。TIME_WAIT 状态下需要等待 2 倍的最大报文段生存时间，来保证链接的可靠关闭，之后才会进入 CLOSED 关闭状态。而 Server 端收到 ACK 后直接就进入 CLOSED 状态。

为什么需要等待 2 倍最大报文段生存时间之后再关闭链接，原因有两个：

• 保证 TCP 协议的全双工连接能够可靠关闭；

• 保证这次连接的重复数据段从网络中消失，防止端口被重用时可能产生数据混淆。

从这个交互流程可以看出，无论是建连还是断链，都是需要在两个方向上进行，只不过建连时，Server 端的 SYN 和 ACK 合并为一次发送，而断链时，两个方向上数据发送停止的时间可能不同，所以不能合并发送 FIN 和 ACK。这就是建连三次握手而断链需要四次的原因。

实际应用中有可能遇到大量 Socket 处在 TIME_WAIT 或者 CLOSE_WAIT 状态的问题。一般开启 tcp_tw_reuse 和 tcp_tw_recycle 能够加快 TIME-WAIT 的 Sockets 回收；而大量 CLOSE_WAIT 可能是被动关闭的一方存在代码 bug，没有正确关闭链接导致的。