三次握手,四次挥手速记版
本文同步发表于微信公众号，微信搜索程语新视界即可关注，每个工作日都有文章更新
三次握手和四次挥手是 TCP 协议中建立与关闭连接的关键机制，常因流程抽象而难以记忆。结合权威资料和通俗类比，以下是清晰、易记的要点：
三次握手（建立连接）
目的：确认双方收发能力正常，并协商初始序列号（ISN）。
过程：
- 客户端 → 服务端：发送
SYN=1, seq=x（请求连接）。 - 服务端 → 客户端：回复
SYN=1, ACK=1, ack=x+1, seq=y（确认 + 请求连接）。 - 客户端 → 服务端：发送
ACK=1, ack=y+1（确认连接）。
- 客户端 → 服务端：发送
为什么不能是两次？
两次无法确认客户端的接收能力。若第二次握手后服务端认为连接已建立，但客户端未收到响应，会导致服务端浪费资源等待。
四次挥手（关闭连接）
目的：安全关闭双向连接，确保数据全部传输完毕。
过程（假设客户端主动关闭）：
- 客户端 → 服务端：发送
FIN=1（不再发送数据）。 - 服务端 → 客户端：回复
ACK（确认收到关闭请求）。 - 服务端 → 客户端：发送
FIN=1（自己也准备关闭）。 - 客户端 → 服务端：回复
ACK，进入TIME_WAIT（等待 2MSL 后关闭）。
- 客户端 → 服务端：发送
为什么是四次而非三次？
TCP 是全双工协议，双方需独立关闭数据流。服务端收到客户端的FIN后，可能仍有数据未发送完，因此ACK和FIN不能合并。
关键状态与细节
三次握手状态：
- 客户端：
CLOSED → SYN_SENT → ESTABLISHED - 服务端：
LISTEN → SYN_RCVD → ESTABLISHED
- 客户端：
四次挥手状态：
- 客户端：
ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED - 服务端：
ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED
- 客户端：
TIME_WAIT 作用：
确保最后ACK被服务端收到。若丢失，服务端会重传FIN；同时防止旧连接报文干扰新连接。
如果还是记不住，可以按照实际生活例子来记
- 比喻：
- 三次握手 = 电话确认：“喂？（你听得到吗？）” → “听得到！”（你听得到我吗？） → “听得到！”
- 四次挥手 = 道别：“我先挂了哈” → “好” → “我也挂了” → “嗯”。
TCP三次握手和四次挥手是TCP协议建立和断开连接的核心过程，其本质可理解为通信双方在开始对话前和结束对话后，为确保沟通顺畅而进行的“打招呼”与“告别”。
三次握手（建立连接）
这个过程好比两个人通过电话确认通信线路畅通。
- 第一次握手（询问）：客户端主动联系服务器，发送一个带有“SYN”标志的报文。这好比打电话时，客户端说：“你好，我是A，能听到吗？我想和你通话。”
- 第二次握手（确认与回应）：服务器收到后，回复一个同时带有“SYN”和“ACK”标志的报文。这相当于服务器回答：“你好A，我能听到。我是B，我也准备好了。”
- 第三次握手（最终确认）：客户端收到服务器的回复后，再发送一个“ACK”报文。这就像客户端最后说：“好的B，我确认我们连接上了，可以开始通话了。”
至此，连接建立。之所以需要三次而非两次，是为了防止因网络延迟导致失效的连接请求占用服务器资源，确保连接的可靠性。
四次挥手（断开连接）
这个过程好比两个人结束通话时的礼貌告别。由于TCP连接是全双工的（双方可同时收发数据），断开需要两个方向分别关闭。
- 第一次挥手（单方面结束发送）：主动关闭方（例如客户端）发送一个“FIN”报文。这表示：“我要说的话都说完了，不会再发送新数据了。”
- 第二次挥手（确认收到结束请求）：被动关闭方（例如服务器）收到“FIN”后，立即回复一个“ACK”报文。这表示：“好的，我知道你不再发送了。”但此时服务器可能还有数据需要发送给客户端。
- 第三次挥手（另一方结束发送）：当服务器也完成数据发送后，它发送自己的“FIN”报文给客户端。这表示：“我这边也说完了，也不再发送数据了。”
- 第四次挥手（最终确认）：客户端收到服务器的“FIN”后，回复一个“ACK”报文。这表示：“明白，我们正式结束通话。”
之后，服务器会立即关闭连接。客户端则会等待一个短暂的时间（TIME_WAIT状态），以确保服务器收到了最后的确认报文，然后才完全关闭连接。
之所以是四次挥手，是因为服务器在收到客户端的结束请求后，通常需要时间处理完剩余数据，其确认（ACK）和自身的结束请求（FIN）无法像握手时那样合并发送，因此比三次握手多了一次交互。