请解释TCP三次握手和四次挥手的过程，为什么TCP连接断开需要四次挥手而不是两次？在Web服务端开发中，如何利用TCP连接复用来减少连接建立的开销？
答案
1) 【一句话结论】TCP三次握手通过三次消息交换建立可靠连接，四次挥手因TCP全双工特性需四次消息确保双方数据传输完成，避免资源残留；Web服务端可通过HTTP keep-alive或长连接复用TCP连接减少连接建立开销。
2) 【原理/概念讲解】TCP三次握手是建立连接的核心过程，步骤为：客户端发送SYN（同步序列号）报文（初始序列号seq=100），服务端收到后回复SYN+ACK（同步序列号+确认，seq=200, ack=101），客户端收到后发送ACK（确认，ack=201），完成连接建立。核心是同步双方初始序列号，避免重复连接。
TCP四次挥手是断开连接的过程，因TCP全双工（双方可同时发送数据），一方先关闭自己的发送端（半关闭），发送FIN（关闭发送）报文（seq=204, ack=301），服务端收到后回复ACK（确认，ack=205），然后服务端关闭自己的发送端，发送FIN（被动关闭，seq=302, ack=206），客户端收到后回复ACK（确认，ack=307），完成断开。核心是确保双方数据传输完成，避免缓冲区资源残留。
3) 【对比与适用场景】
| 特性 | 三次握手 | 四次挥手 |
|---|---|---|
| 目的 | 建立可靠连接 | 断开连接 |
| 步骤 | SYN → SYN+ACK → ACK | FIN → ACK → FIN → ACK |
| 关键报文 | SYN（同步）、ACK（确认） | FIN（关闭发送）、ACK（确认） |
| 使用场景 | 客户端首次连接服务端 | 连接使用完毕后释放资源 |
4) 【示例】
HTTP请求流程：
- 客户端发送SYN（seq=100）→ 服务端回复SYN+ACK（seq=200, ack=101）→ 客户端发送ACK（ack=201）→ 连接建立。
- 客户端发送GET请求（seq=202）→ 服务端返回响应（seq=300, ack=203）→ 客户端发送FIN（seq=204, ack=301）→ 服务端回复ACK（ack=205）→ 服务端发送FIN（seq=302, ack=206）→ 客户端回复ACK（ack=307）→ 连接断开。
5) 【面试口播版答案】
“TCP三次握手是建立连接的过程，步骤是客户端发送SYN，服务端回复SYN+ACK，客户端再回复ACK，确保双方初始序列号同步。而四次挥手是断开连接，因为TCP是全双工，双方都有数据传输，所以一方先关闭自己的发送端（半关闭），发送FIN，服务端确认后关闭自己的发送端，再发送FIN，客户端确认后完成断开，共四次。在Web服务端开发中，可通过HTTP keep-alive或长连接复用同一个TCP连接处理多个请求，减少每次请求建立连接的开销。”
6) 【追问清单】
- 问题：为什么TCP是全双工？
回答要点：全双工意味着双方可同时发送数据，因此关闭连接时需确保双方数据传输完成，避免资源残留。 - 问题：三次握手为什么需要三次？
回答要点：第一次交换SYN同步序列号，第二次交换SYN+ACK确认序列号并同步自身序列号，第三次交换ACK确认双方序列号，确保连接可靠。 - 问题：四次挥手中的FIN和ACK顺序是否可以颠倒？
回答要点：不可以，FIN是关闭发送端，ACK是确认FIN，顺序颠倒会导致数据传输未完成就关闭连接，造成资源残留。 - 问题：连接复用的具体实现方式？
回答要点：通过HTTP keep-alive（短连接复用）或长连接（如WebSocket）复用TCP连接，减少连接建立开销。 - 问题：如果服务端先关闭连接，客户端如何处理？
回答要点：客户端收到服务端的FIN后，发送ACK确认，然后关闭自己的连接，等待服务端确认后完成断开。
7) 【常见坑/雷区】
- 误认为四次挥手是两次（忽略FIN的确认步骤）；
- 忽略TCP全双工特性，解释四次挥手时说成两次；
- 三次握手顺序错误（如SYN+ACK先于SYN）；
- 连接复用实现混淆（如将HTTP keep-alive与长连接混淆）；
- 四次挥手中的FIN和ACK顺序颠倒（如服务端先发送ACK再发送FIN）。