服务器与客户端握手是双方在建立正式通信前交换确认信息、协商参数并建立信任关系的过程，其核心目的是确保数据能可靠、有序地传输。无论是浏览网页、发送邮件还是调用接口，每一次网络交互都始于这场无声的“对话”，如果把网络通信比作打电话，握手就是拨号后的“喂，能听到吗？”只有确认彼此在线且状态正常，后续的“聊天”才有意义。
服务器与客户端握手的原理
要理解握手，先要分清两种最常见的场景：TCP三次握手和TLS/SSL握手，前者负责建立“传输通道”，后者负责给通道加“加密锁”，两者经常一起出现,但职责完全不同。
TCP三次握手：建立可靠连接的地基
TCP（传输控制协议）的握手过程被形象地称为“三次握手”，行业共识认为这是保证可靠传输的最少交互次数,整个过程像一场严谨的入职面试：
- 第一次握手（SYN）：客户端主动向服务器发送一个带有SYN标志的报文，相当于递上简历，说“我想建立连接，我的初始序列号是X”。
- 第二次握手（SYN+ACK）：服务器收到后，如果同意连接，会回复一个同时携带SYN和ACK标志的报文，意思是“收到你的请求，我确认，我的初始序列号是Y，也请你确认我的身份”。
- 第三次握手（ACK）：客户端再发送一个ACK报文作为最终确认，表示“我知道你同意了，我们开始干活”，此时双方都确认了彼此的收发能力,连接正式建立。
从技术视角看，三次交互的核心价值在于同步双方的初始序列号，没有这个步骤，接收方无法判断报文的先后顺序，也无法有效处理丢包重传，用抓包工具（如Wireshark）观察,你会清晰地看到这三次交互的编号和标志位。
为什么不是两次或四次
两次握手无法解决“失效请求”问题如果客户端发出的连接请求在网络中滞留，超时后重试，而服务器对滞留请求也回复了确认，那么服务器会误以为连接已建立，白白占用资源等待并不存在的客户端。四次握手理论上可行，但三次已经能实现双向确认，多一次只是浪费往返时间，据统计，在数据中心内部网络中，一次往返时间通常在0.5毫秒以内，但公网环境下可能达到几十毫秒,减少一次交互对高并发场景意义重大。
TCP三次握手和四次挥手区别在哪
很多初学者容易混淆“握手”和“挥手”，它们虽然都涉及标志位交换，但目的和流程截然不同。握手是建立连接，挥手是断开连接
，挥手的“四次”是因为TCP连接是全双工的，即数据可以同时双向传输,因此每一方都需要独立关闭自己的发送通道。
四次挥手的完整流程
假设客户端先发起关闭：
- 第一次挥手（FIN）：客户端发送FIN报文，表示“我的数据发完了，准备关闭我的发送端”。
- 第二次挥手（ACK）：服务器回复ACK，表示“收到，但我还有数据没发完，你先等着”。
- 第三次挥手（FIN）：服务器数据传输完毕后，发送FIN报文，表示“我的数据也发完了，可以关闭了”。
- 第四次挥手（ACK）：客户端回复ACK，双方进入等待状态,连接最终关闭。
其中客户端在发送最后一次ACK后会进入TIME_WAIT状态，持续约2分钟（依赖系统设置），这是为了确保服务器能收到最后一个ACK，如果丢失，服务器会重发FIN，客户端需要有时间再次回应,这个机制有效避免了因ACK丢失导致的连接悬挂。
高频场景：服务器与客户端握手延迟高
当用户反馈“网页加载慢”或“接口总是超时”，排查方向往往聚焦在握手阶段。服务器与客户端握手延迟高通常由两种原因导致：
- 网络链路问题：物理距离远、运营商路由绕路、丢包严重，此时用
ping和traceroute命令可以快速定位瓶颈，如果延迟集中在某一跳,多半是运营商网络拥塞。 - 服务器处理能力不足：服务器并发连接数达到上限（如Linux下
net.core.somaxconn默认值128），导致TCP半连接队列溢出，新的握手请求被直接丢弃，此时可以用ss -lnt命令查看当前监听端口的队列情况，如果存在大量SYN_RECV状态的连接，说明队列已满,需要调整内核参数。
HTTPS握手过程详解
如果说TCP握手是“见面打招呼”，HTTPS握手就是“出示身份证并商量暗号”，HTTPS在TCP之上增加了TLS（传输层安全协议）握手，其核心目标是验证服务器身份和协商对称加密密钥。
TLS 1.3握手：更快更安全
近年来，采用TLS 1.3协议的站点占比显著提升，因为它在握手速度和安全性上做了大幅优化，TLS 1.3握手将交互次数从2个往返（2-RTT）压缩到1个往返（1-RTT），甚至支持0-RTT（会话恢复场景）。
具体流程如下：
- 客户端发送ClientHello,包含支持的加密套件列表和一个随机数。
- 服务器回复
ServerHello
，选定加密套件,并附上自己的证书公钥和签名。 - 客户端验证证书是否由受信任的CA（证书颁发机构）签发，同时验证域名和有效期，验证通过后，客户端生成“预主密钥”,用服务器公钥加密后发送给服务器。
- 双方各自计算出相同的会话密钥，握手完成,之后所有数据都用该密钥进行对称加密传输。
常见误区：证书验证不等于握手成功
很多用户遇到“您的连接不是私密连接”的警告，会误以为是握手失败，握手在TCP和TLS层面已经完成，只是证书验证环节未通过，证书过期、域名不匹配、证书链不完整都会触发警告，业内专家指出，超过半数的证书告警源于证书未及时续期,而非加密算法问题。
排查证书问题时,可以执行以下命令检查证书有效期和签发链：
openssl s_client -connect example.com:443 -servername example.com
输出信息中会显示Certificate chain和Verify return code,根据返回码即可判断具体原因。
服务器与客户端握手失败怎么办
实际运维中，握手失败是高频故障，失败位置不同，处理方式也不同,以下按由浅入深的顺序给出排查路径。
端到端排查三步骤
- 第一步：检查网络连通性，使用
ping验证目标IP是否可达，再使用telnet IP 端口（如telnet 10.0.0.1 443）测试指定端口是否开放，如果端口不通，先检查云服务商的安全组规则和本地防火墙（firewalld或iptables）。 - 第二步：检查服务进程状态，确认服务端程序是否正常监听端口，使用
netstat -tlnp | grep 端口号查看监听信息，如果服务未启动或监听地址错误（如绑定在127.0.0.1而非0.0.0.0）,客户端自然无法完成握手。 - 第三步：抓包分析，在客户端执行
tcpdump -i eth0 host 服务器IP and port 443，观察是否有SYN报文发出以及是否有SYN+ACK回复，如果只有SYN发出而一直收不到回复，说明请求被中间网络设备拦截或服务器未响应；如果能收到SYN+ACK但客户端不回复ACK,则需要检查客户端本地的防火墙或内核参数。
高并发场景下的握手优化
对于流量较大的业务系统，握手阶段可能成为性能瓶颈,常规优化手段包括：
- 调整Linux内核TCP参数，增大半连接队列和全连接队列长度，例如修改
net.ipv4.tcp_max_syn_backlog和net.core.somaxconn。 - 启用
TCP Fast Open
（net.ipv4.tcp_fastopen），该机制允许在SYN报文中携带数据,减少一个RTT的往返时间。 - 使用负载均衡器（如Nginx、HAProxy）进行SSL卸载，让负载均衡设备承担TLS握手计算压力，后端服务器只处理明文HTTP流量,从而大幅提升并发处理能力。
实践中，将Nginx配置为反向代理并开启ssl_session_cache，能显著减少重复握手的资源消耗，据统计，对于有大量短连接的业务场景，启用会话缓存后,握手阶段CPU占用率可降低一半以上。
服务器与客户端握手常见问题解答
什么是SYN Flood攻击，和握手有什么关系
SYN Flood是一种典型的分布式拒绝服务（DDoS）攻击方式，攻击者向服务器发送大量伪造源IP的SYN请求，却不完成第三次握手，导致服务器半连接队列被占满，正常用户的握手请求无法进入队列，表现为服务器完全失去响应，防御手段包括启用Linux内核的tcp_syncookies机制，该机制在队列满时不再存储半连接信息，而是通过加密计算向客户端发送Cookie,正常客户端完成ACK后即可建立连接。
TCP握手中的TIME_WAIT状态为什么那么多
TIME_WAIT是主动关闭连接的一方在发送完最后一次ACK后进入的状态，持续时间为2个MSL（最大报文段生存时间），Linux中通常为60秒，在高并发短连接场景（如PHP-FPM、Nginx代理）下，服务器会产生大量TIME_WAIT连接，占用端口资源，优化方向是调整net.ipv4.tcp_tw_reuse参数（允许重用处于TIME_WAIT状态的连接），同时确认对端已开启时间戳选项，但需要注意，系统默认的tcp_tw_recycle参数在公网环境容易引发问题,一般不建议开启。
UDP通信需要握手吗
不需要，UDP是无连接协议，发送方直接将数据包发往目标地址，不进行任何确认，这带来低延迟优势，适合视频直播、DNS查询等容忍少量丢包的应用，但因此也不具备TCP的可靠传输、流量控制和拥塞控制能力，如果业务场景要求传输可靠性，又需要低延迟，可以基于UDP自行实现数据确认逻辑，或者使用QUIC（基于UDP的传输协议），它在应用层实现了类似TCP的可靠传输和TLS加密，且握手更快，目前已在HTTP/3中得到广泛应用。
服务器与客户端握手是网络通信的基石，无论是TCP的可靠校验证、TLS的身份加密，还是挥手的干净收尾，每个步骤都经过精心设计，掌握握手的原理和常见故障排查方法，是每一个网络工程师和运维人员的基本功，下次遇到连接问题时，从握手入手，逐层分析,往往能最快定位根因。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/554361.html
