TCP三握四挥TLS握手
在现代互联网通信中，传输控制协议（Transmission Control Protocol）和传输层安全协议（Transport Layer Security）是构建可靠、安全连接的基石。TCP负责数据的可靠传输，而TLS则在此基础上提供了加密和身份验证。理解它们各自的握手（Handshake）过程，是掌握网络通信精髓的关键。本文将介绍TCP的“三次握手”与“四次挥手”的机制，并进一步探讨TLS 1.2和TLS 1.3的握手全过程。
一、TCP的握手与挥手
TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。它通过复杂的机制确保数据能够无差错、按顺序地到达目的地。
1. TCP三次握手：连接的建立与同步
TCP连接的建立过程被称为“三次握手”（Three-Way Handshake），其核心目标是同步双方的序列号（Sequence Number），并确认双方的发送和接收能力均正常。
过程详解
最终，双方都进入 ESTABLISHED 状态，可以开始数据传输。
为什么必须是三次握手？（Why Three?）
这是TCP设计中最常被问到的问题，其根本原因在于防止“已失效的连接请求报文段”突然出现，并确保双方都具备可靠的发送和接收能力。
防止历史连接的干扰（核心原因）：
假设客户端发送了一个连接请求（
SYN1），但该请求在网络中滞留。客户端超时后会重发新的SYN2。如果采用二次握手，服务器收到滞留的
SYN1后会立即建立连接。当客户端收到服务器的确认后，它会忽略这个过期的连接，但服务器却认为连接已建立，并持续等待数据。这会导致服务器资源的浪费。采用三次握手，服务器收到滞留的
SYN1并发送SYN+ACK后，客户端会因为这不是它当前期望的连接而发送一个RST报文（或直接忽略），服务器就不会错误地建立连接。
同步双方的初始序列号（ISN）：
TCP是全双工的，双方都需要发送和接收数据。序列号是保证数据有序性的关键。
第一次握手：客户端 -> 服务器（证明了：客户端具有发送能力 客户端序列号：seq：x ）
第二次握手：服务器 -> 客户端（证明了：服务器具有接收和发送能力 服务器序列号：seq：y ）
第三次握手：客户端 -> 服务器（证明了：客户端具有接收能力）
只有三次握手，才能确保双方都知晓并确认了对方的初始序列号，并确认了自己发送和接收路径的畅通。
为什么不能是二次握手？
如上所述，二次握手无法有效防止“已失效的连接请求报文段”导致的资源浪费，也无法确保客户端的接收能力。
为什么不能是四次握手？
四次握手在理论上是可行的，但它增加了不必要的延迟和开销。三次握手已经足够完成序列号的同步和连接的确认，多一次握手没有带来额外的可靠性或功能提升。TCP的设计原则是在保证可靠性的前提下，追求效率最大化。
2. TCP四次挥手：连接的优雅关闭
TCP连接是全双工的，这意味着数据流是双向的。当一方完成数据发送任务后，可以发送一个 FIN 报文来终止这一方向的数据流，但另一方向的数据流可以继续。因此，关闭一个TCP连接需要四个步骤，被称为“四次挥手”（Four-Way Wavehand）。
过程详解
假设客户端主动发起关闭：
客户端在发送完第四次挥手后，会进入 TIME-WAIT 状态，等待 2MSL（Maximum Segment Lifetime，最大报文段生存时间）后才进入 CLOSED 状态。
为什么必须是四次挥手？（Why Four?）
四次挥手的根本原因在于TCP的半关闭（Half-Close）特性和全双工（Full-Duplex）连接。
第一次挥手：客户端发送
FIN，表示它不再发送数据，但仍可接收数据。第二次挥手：服务器发送
ACK确认收到FIN。此时，服务器可能还有数据要发送给客户端。服务器的延迟关闭：服务器在收到
FIN后，进入CLOSE-WAIT状态。它会检查自己的发送缓冲区，如果还有数据未发送完毕，它会继续发送。只有当所有数据都发送完毕后，服务器才会发送自己的FIN报文。第三次挥手：服务器发送自己的
FIN，表示它也不再发送数据。第四次挥手：客户端发送
ACK确认。
由于服务器的 ACK（第二次挥手）和 FIN（第三次挥手）是两个独立的动作，它们之间可能存在任意长的时间间隔（取决于服务器是否还有数据要发送），因此不能合并，必须分开发送，从而形成了四次挥手。
为什么不能是三次挥手？
在挥手过程中，服务器不能像三次握手那样将 ACK 和 FIN 合并发送。
在握手时，服务器在收到客户端的
SYN后，可以立即发送SYN+ACK，因为服务器的连接请求（SYN）和对客户端请求的确认（ACK）是同时发生的。在挥手时，服务器收到客户端的
FIN后，它立即发送ACK是为了告诉客户端：“我收到了你的关闭请求，但我可能还有数据要发。” 只有当服务器也完成了所有数据发送后，它才能发送FIN。如果强制合并为三次挥手，服务器在收到
FIN后必须立即发送ACK+FIN。这意味着服务器必须立即停止向客户端发送数据，这违背了TCP的半关闭特性，即允许一端关闭发送，而另一端仍可继续发送数据直到完成。
二、TLS握手
传输层安全协议（TLS），是SSL（Secure Sockets Layer）的继任者，它位于TCP之上，为应用层协议（如HTTP）提供数据加密、身份验证和数据完整性保护。
为什么需要TLS握手？
TCP握手解决了可靠性问题，但它传输的数据是明文的，存在被窃听和篡改的风险。TLS握手的核心目的在于：
身份验证（Authentication）：通过数字证书验证服务器（通常也包括客户端）的身份，防止中间人攻击。
密钥协商（Key Exchange）：安全地协商出一个会话密钥（Session Key），用于后续的数据加密。
安全参数协商（Parameter Negotiation）：确定双方都支持的TLS版本、加密套件（Cipher Suite）等安全参数。
（1）TLS 1.2 握手全过程（经典四次往返）
至此，TLS 1.2握手完成，双方开始使用协商好的会话密钥进行加密通信。
（2）TLS 1.3 握手全过程（高效的一次往返）
TLS 1.3在TLS 1.2的基础上进行了重大改进，核心目标是提高性能和增强安全性。它将握手过程简化为一次往返（1-RTT），甚至在客户端已经访问过服务器的情况下可以实现零次往返（0-RTT）。
核心改进
移除不安全特性：废弃了RSA密钥交换、SHA-1等不安全的加密套件。
强制使用前向保密（Forward Secrecy）：强制使用基于Diffie-Hellman（DH）的密钥交换算法，如ECDHE，确保即使私钥泄露，历史会话数据也不会被解密。
1-RTT 握手：通过在
Client Hello中携带密钥交换所需的公钥参数，实现了握手流程的精简。
过程详解（1-RTT）
在TLS 1.3中，服务器在发送 Server Hello 后，立即就可以根据客户端提供的密钥共享计算出主密钥，并使用该密钥加密后续的证书和 Finished 报文。客户端收到 Server Hello 后，也计算出主密钥，并能立即解密后续报文，从而将握手过程从TLS 1.2的两次往返（2-RTT，未优化前）或三次往返（3-RTT，包含TCP握手）优化为一次往返（1-RTT，包含TCP握手）。
尾
在网络协议的精密逻辑中，我们窥见了超越技术的存在智慧。TCP的三次握手恰如文明进程中信任的建立——不是莽撞的一见如故，而是经由试探、回应、确认的仪式感，在不确定的数字旷野中开辟出确定的通途。这三次往复，是对现代社会中廉价连接的优雅反抗。
TLS在可靠连接之上构筑的安全通道，展现了更为深刻的生命哲学。证书验证如同灵魂的相互审视，非对称加密恰似谨慎的自我披露，而前向保密特性，则隐喻着高级的情感智慧——即便关系终结，曾经的亲密仍应保持其神圣不可侵犯。从1.2到1.3的演进，是人类在效率与安全间的永恒求索，也是成熟心智的写照：学会在保持边界的同时，不牺牲连接的深度。
四次挥手的告别艺术，揭示了圆满的退场比热烈的开场更需要智慧。TIME-WAIT状态的设置，是协议设计中最富诗意的留白——它承认信息可能迷失，理解需要时间抵达，给所有未完成的对话以温柔的余韵。这种克制的等待，是对速食时代最优雅的悖离。
在万物互联的喧嚣中，这些底层协议依然保持着古典的节奏。它们不因光速传输而省略必要的确认，不因效率至上而牺牲安全的底线。每一次连接都重新开始，每一次加密都独一无二。这种在即时满足时代的“延迟美学”，正是我们在迷失中急需找回的生活韵律。
或许，我们应当在这些沉默的协议中寻找答案：像TCP般珍视连接的完整，如TLS般懂得边界的艺术，若挥手告别时保有优雅的余韵。在代码的深处，我们意外邂逅了生活的真谛——所有珍贵都需要时间的沉淀，所有信任都需要耐心的构建，所有结束都值得温柔的对待。
这就是协议教给我们的终极智慧：在确定与不确定性的永恒张力中，既保持连接又守护独立的节点，于混沌中建立秩序，在秩序中保留温度。