从 ws:// 切换到 wss:// 需要注意啥

Posted 2023-02-16

【中文标题】从 ws:// 切换到 wss:// 需要注意啥

【英文标题】：What do I have to take care of when switching from ws:// to wss://从 ws:// 切换到 wss:// 需要注意什么

【发布时间】：2013-08-08 20:07:21

【问题描述】：

我发现一些移动网络提供商本身并不支持 80 端口，但他们确实支持 443 端口，我觉得这有点奇怪。 无论如何，对于导致我使用wss:// 来支持ws://，从端口80 切换到端口433 的问题，我无能为力。

我想知道使用wss:// 是否有任何负面影响？ 问题是我（尚未）拥有 SSL 证书。

【问题讨论】：

不是运营商不支持 80 端口，而是他们有一个代理，在未加密的情况下会干扰 WebSocket 连接。最有可能发生的是它们干扰了初始 HTTP 握手并注入了 HTTP 标头甚至正文内容。这会导致握手失败，从而导致连接失败。

要测试@leggetter 是否正确，请尝试在6060 之类的端口上运行websocket，并使用ws://mytestmachine.com:6060/endpoint通过移动设备连接到它

【参考方案1】：

唯一真正的“负面”影响可能是对您发送的内容进行加密/解密所需的 CPU 利用率略有增加。其中一些可以通过选择较弱（重新：更快）密码或在极端情况下使用基于 SSL 硬件的卸载来抵消。由于 TLS 密钥交换，在建立连接时也会增加一点延迟（当然类似于使用 HTTPS）。但是因为密钥交换握手只需要在连接上发生一次，所以总体成本并不是很大。

正如您所指出的，您还需要获得适当的 SSL 证书，因此这将是一个额外的管理成本（如果您获得了认可的证书颁发机构的签名，则两者都以 $$ 为单位，并且需要一些时间来加载它到某个密钥库）。

同意上面的 phil (@leggetter)，大多数移动提供商都在使用缓存代理来加快对端口 80 请求的响应（假设它是流过它的 http 内容）并且它经常干扰原始的 http 响应握手WS。当您使用加密时，代理无论如何都无法解析/解密内容，所以他们让它通过。这就是为什么端口 443 经常在端口 80 不能工作的地方工作。您也可以尝试在 80 以外的端口上使用 WS 连接，但前提是您的用户不在防火墙后面。移动网络通常不会缓存/干扰备用端口。

【讨论】：

+1 - 关于提高 CPU 利用率和证书成本的优点。