从握手到长连：HTTPS与WSS的架构协同与本地开发实践

1. 从一次“握手”说起HTTPS与WSS的协同基础想象一下你正在和一个朋友打电话。拨通电话、互相确认身份、然后开始聊天这个过程和我们今天要聊的HTTPS与WSS的“握手”非常像。只不过在互联网世界里这个“握手”过程更加精密和严谨它决定了你的数据是“明信片”还是“加密信件”。HTTPS我们都很熟悉了它就是那个让网站地址栏出现小锁头的协议。简单说它就是HTTP协议加上了TLS/SSL这层“加密外壳”。当你在浏览器里输入一个HTTPS网址你的浏览器和服务器之间会先进行一场复杂的“TLS握手”舞蹈。这场舞蹈的核心目的有三个第一确认服务器就是你想要联系的那个身份认证第二双方协商出一套只有彼此知道的“暗号”密钥协商第三用这套“暗号”给后续所有的通信内容加密。这个过程结束后你和服务器之间就建立起了一条安全的、加密的HTTP通道你提交的密码、银行卡号等信息在这条通道里传输就是安全的。那么WSS又是什么呢你可以把它看作是WebSocket的“安全升级版”。WebSocket本身是一个全双工通信协议它允许服务器和客户端比如你的浏览器建立一条长连接之后双方可以随时、主动地互相发送数据非常适合聊天室、实时游戏、股票行情推送这类场景。而WSS就是在WebSocket协议的基础上也套上了TLS/SSL这层“加密外壳”。更关键的是WSS的建立过程巧妙地“借用”了HTTPS的成果。这里有一个非常重要的概念协议升级。WSS连接并不是凭空建立的。客户端浏览器会先向服务器发起一个看起来像HTTPS的请求但这个请求里携带了特殊的“暗号”——Upgrade: websocket和Connection: Upgrade这两个HTTP头部。这个请求说“嘿我们现有的HTTPS加密通道挺好的能不能把它‘升级’一下变成WebSocket协议”如果服务器同意就会返回一个101 Switching Protocols的响应。从这一刻起之前为HTTPS建立的那条加密通道就无缝切换成了WebSocket长连接并且全程保持加密。这就是“从握手到长连”的精髓一次TLS握手服务两种协议。加密层TLS在底层已经建立好上层的应用协议无论是HTTP还是WebSocket都可以安全地跑在上面。所以在一个典型的现代Web应用中HTTPS负责保护你加载网页、提交表单这些常规请求的安全而当你需要和服务器保持一个长期的、实时的对话通道时比如接收新消息通知WSS就会登场它利用已有的安全通道为你开辟一条专属的“实时加密热线”。两者在架构上协同工作共同构成了一个既安全又能实时交互的Web应用基础。2. 穿越云层一个真实架构中的请求旅程理解了基础原理我们再把镜头拉远看看一个真实的、高可用的云原生应用架构中一个WSS请求是如何穿越层层关卡最终抵达后端的。这个过程就像一场接力赛每个环节都至关重要。我们以一个典型的“客户端 - 阿里云SLB - APISIX网关 - Nginx - 后端WebSocket服务”架构为例来拆解这场接力。2.1 第一棒客户端与负载均衡器的加密握手旅程始于你的浏览器。当你访问一个类似wss://my-app.example.com/chat的地址时故事就开始了。首先浏览器会进行DNS解析将域名my-app.example.com转换成阿里云SLBServer Load Balancer负载均衡器的公网IP地址。接着浏览器会向这个IP的443端口发起TLS握手。这里有个关键点SSL证书终止在SLB。这意味着你浏览器看到的、验证的那个HTTPS证书是配置在阿里云SLB上的。SLB负责完成了与你的整个TLS加密过程。这样做的好处非常明显。第一是性能加解密是CPU密集型操作由SLB统一处理可以解放后端的服务器让它们专注于业务逻辑。第二是灵活性证书的管理、续期、更换都在SLB层面完成无需改动后端任何服务。第三是安全外部网络到SLB的链路是加密的可以有效防止流量在公网被窃听。当TLS握手完成你的浏览器发送那个携带了Upgrade: websocket头部的特殊HTTPS请求时SLB会解密这个请求因为到了它这里TLS层已经结束然后根据预设的监听规则将这个已被解密的普通HTTP请求转发给内网的后端服务器比如我们的APISIX网关集群。从此往后在内网中流转的就是明文的HTTP/WebSocket流量了。这也就是常说的“SSL Termination”SSL终止架构。2.2 第二棒API网关的智能路由与守护请求现在进入了内网来到了APISIX这一站。APISIX是一个动态、实时、高性能的API网关它在这里扮演着“交通警察”和“安全检查站”的角色。它首先会进行路由匹配。网关里配置了多条路由规则比如/api/*转发到REST服务/chat转发到WebSocket服务。我们的wss://my-app.example.com/chat请求其路径/chat正好匹配到专门处理WebSocket的上游Upstream。APISIX的配置通常像这样routes: - uri: /chat upstream: nodes: websocket-backend:8080: 1 plugins: websocket: {} # 明确启用WebSocket支持 cors: {} # 处理跨域 jwt-auth: {} # 进行JWT令牌认证启用websocket插件是关键它告诉APISIX“这条路由上的连接可能需要升级为WebSocket请保持其长连接特性不要擅自断开或缓冲。” 接着jwt-auth插件可能会拦截请求验证你连接中携带的Token是否有效。这就在网关层统一完成了认证鉴权非法请求在进入业务系统前就被拦截了。此外APISIX还能轻松实现限流熔断。比如你可以设置每秒最多1000个新的WebSocket连接防止突发流量打垮后端服务或者当后端服务响应超时比例过高时自动熔断返回友好提示。所有的请求日志、指标都会被APISIX收集方便你进行监控和问题排查。你会发现网关把很多跨切面的关注点安全、流量、观测都从业务代码中剥离了让后端可以更纯粹。2.3 第三棒Nginx的协议升级与精细转发请求通过了网关的检查被转发到了websocket-backend:8080。这个上游地址可能指向一个Nginx反向代理实例。你可能会问都有了APISIX这么强大的网关为什么还需要Nginx这通常源于历史架构或更精细的控制需求。Nginx在这里的核心作用之一是确保协议升级的正确性。虽然APISIX已经支持WebSocket但在一些复杂场景下我们可能仍需要Nginx来处理一些更底层的HTTP细节。针对WebSocketNginx的配置有固定的“公式”location /chat { proxy_pass http://real-websocket-server:6080; # 实际的后端服务地址 proxy_http_version 1.1; # 必须使用HTTP/1.1 proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 86400s; # 设置非常长的读超时维持长连接 proxy_send_timeout 86400s; # 设置非常长的写超时 proxy_buffering off; # 关闭缓冲实现实时通信 }这几行配置是WebSocket反向代理的灵魂。Upgrade和Connection头部被原封不动地传递给后端服务后端服务看到这些头部才会响应101 Switching Protocols。proxy_buffering off至关重要因为Nginx默认会缓冲数据以提高静态文件传输效率但这会破坏WebSocket消息的实时性必须关闭。Nginx的另一个作用是负载均衡与健康检查。如果real-websocket-server背后是一个集群Nginx可以在多个实例间分发连接并踢掉不健康的节点。此外Nginx在处理静态文件、Gzip压缩等方面依然有不可替代的优势在架构中常与API网关互补存在。2.4 最后一棒后端服务的业务处理经过长途跋涉请求终于到达了真正的后端WebSocket服务。这个服务可能用Node.js的ws库、Spring Boot的WebSocket模块或者Go的gorilla/websocket等框架实现。此时它收到的已经是一个标准的HTTP升级请求。服务端代码会检查请求路径和头部确认这是一个WebSocket升级请求。进行业务层面的连接验证比如再次校验用户身份虽然网关验过但这里可以二次校验。发送101 Switching Protocols响应完成协议升级。在内存中维护这个Socket连接并将其与具体的用户会话关联起来。从此一条全双工的、基于WSS的加密长连接就建立起来了。服务器可以随时向这个客户端推送消息客户端也可以随时发送消息给服务器所有数据都通过最初在SLB那里建立的TLS通道进行加密传输安全且实时。3. 为什么必须是域名架构背后的安全逻辑在本地测试时我们经常用localhost或127.0.0.1但一上生产环境WSS地址就必须使用域名比如wss://my-app.example.com直接用IP地址wss://192.168.1.1行不通。这背后有几层深刻的架构和安全原因不仅仅是“规定”那么简单。首先也是最根本的是SSL/TLS证书的约束。CA证书颁发机构签发的SSL证书是绑定到特定域名的比如*.example.com或my-app.example.com。证书里包含了一个“主题备用名称”字段明确列出了它保护哪些域名。当浏览器发起TLS握手时会进行“服务器名称指示”扩展告诉服务器它想访问的域名服务器必须返回一个对该域名有效的证书。如果你用IP地址访问服务器要么没有对应IP的证书几乎不可能有要么返回的证书域名不匹配浏览器就会弹出严重的安全警告阻止连接。这是TLS协议的基础安全机制防止“中间人”攻击。其次现代浏览器的安全策略越来越严格。许多浏览器API和特性如某些严格的CORS策略、Cookie的SameSite属性在非安全上下文非HTTPS或使用IP地址时行为会受到限制甚至被禁用。使用域名并配以有效的证书是告诉浏览器“这是一个受信任的源”的最标准方式。再者从我们前面讲的云架构来看负载均衡器如阿里云SLB的配置也要求使用域名。在SLB控制台添加HTTPS监听器时你必须选择一个已经上传的、匹配访问域名的证书。SLB正是通过请求中的Host头部或TLS握手阶段的SNI信息来识别该将流量转发到哪个后端服务器组。没有域名整个基于虚拟主机Virtual Host的流量分发机制就无法工作。最后从运维和业务角度域名提供了抽象层和灵活性。你的后端IP可能会变服务器可能会扩容缩容但域名可以保持不变。你只需要修改DNS解析记录将域名指向新的IP集群客户端代码完全无需改动。使用域名是互联网服务高可用的基石之一。4. 本地开发的“捷径”用Vite插件快速开启HTTPS/WSS了解了生产环境的复杂架构我们再回到本地开发。作为一名开发者你肯定不想在本地也搭建一套SLBAPISIXNginx的完整链路。我们需要一个轻量、快捷的方式在本地也模拟出HTTPS和WSS的环境以便调试和安全特性相关的代码。这里Vite生态的vitejs/plugin-basic-ssl插件就是你的“神器”。4.1 插件的工作原理一键生成自签名证书这个插件的原理非常直接。当你第一次在Vite项目中配置并启动它时它会自动在本地生成一个自签名SSL证书通常是一个.crt文件和一个.key文件。然后它告诉Vite的开发服务器“别用HTTP了用HTTPS证书和密钥文件在这儿。” Vite服务器就会以HTTPS模式运行。对于WebSocketVite的开发服务器基于原生Node.jshttp(s)模块或connect同样支持协议升级。当你的前端代码尝试连接wss://localhost:5173/ws时Vite服务器会处理这个升级请求就像Nginx或后端服务做的那样将其升级为WebSocket连接。因为底层通信已经是HTTPS所以这个WebSocket连接自然也就成为了WSS。4.2 一步步配置与使用动手试试看整个过程不超过5分钟。首先在你的Vite项目比如Vue或React项目中安装插件# 使用 npm npm install -D vitejs/plugin-basic-ssl # 使用 yarn yarn add -D vitejs/plugin-basic-ssl # 使用 pnpm pnpm add -D vitejs/plugin-basic-ssl然后修改你的vite.config.js或vite.config.ts文件import { defineConfig } from vite import vue from vitejs/plugin-vue // 以Vue为例 import basicSsl from vitejs/plugin-basic-ssl // 导入插件 export default defineConfig({ plugins: [ vue(), basicSsl() // 使用插件 ], server: { host: localhost, // 明确指定主机 https: true // 这个选项现在会被basicSsl插件自动处理写上更清晰 } })保存配置运行npm run dev。你会发现终端输出的本地服务器地址变成了https://localhost:5173。用浏览器打开这个地址你会看到一个醒目的“不安全”警告这是因为浏览器不信任我们刚刚自己生成的证书。别担心这是预期内的。在Chrome中你可以点击“高级” - “继续前往localhost不安全”。在开发阶段接受这个警告是完全安全的。现在你的本地开发环境就运行在HTTPS下了。如果你的代码里有WebSocket连接记得把连接地址从ws://localhost:5173/ws改成wss://localhost:5173/ws然后刷新页面WebSocket连接就会通过WSS协议成功建立。你可以像在生产环境一样调试所有依赖于安全上下文的功能了。4.3 可能遇到的坑与解决方案在实际使用中你可能会踩到一些小坑。第一个常见问题是证书警告。每次换电脑或者长时间不用后重启项目浏览器可能会再次提示不安全这是因为插件可能生成了新的证书。你可以选择接受或者更彻底一点将插件生成的自签名证书通常在项目根目录或系统临时目录手动导入到系统的“受信任的根证书颁发机构”中这样警告就会永久消失。不过对于纯开发来说点一下“继续访问”是最快的。第二个问题是网络请求的代理。如果你的项目配置了代理server.proxy来解决跨域当开启HTTPS后这些代理配置依然有效但需要注意后端服务是否也支持HTTPS。通常代理到本地的后端API比如http://localhost:3000不受影响。第三个需要注意的点是环境区分。一定要记住这个插件仅用于开发环境。它生成的自签名证书绝不能用于生产环境。生产环境必须使用由可信CA如Let‘s Encrypt、各大云服务商签发的正式证书。你可以在Vite配置中通过环境变量来判断是否启用该插件。import basicSsl from vitejs/plugin-basic-ssl export default defineConfig(({ mode }) ({ plugins: [ vue(), mode development ? basicSsl() : null // 仅开发环境启用 ].filter(Boolean), }))本地开启HTTPS/WSS看似是一个小小的配置但它能让你在开发阶段就提前发现和解决很多与安全协议、混合内容、Cookie安全策略相关的问题避免到了部署上线时才手忙脚乱。这就像飞行员在模拟器里训练各种极端情况一样让正式飞行更加安全可靠。