我在交易所有一个帐户，他们有一个支持ws：// ...和wss：// ...
的websockets API对于未经过身份验证的渠道，例如订单的当前状态，是否可以轻松决定使用ws，主要是为了节省时间（但最少）？显然我想尽可能地提供我的数据。
我只是想检查那里没有其他因素比一些TLS加密CPU周期更重要，并且延迟了ms。
答案 0 :(得分：1)
我完全没有理由不为你的所有连接使用wss，特别是webSocket。正常的webSocket用途是建立连接，然后保持该连接很长时间并使用它。虽然由于加密，每次传输都会产生一些开销，但主要的wss开销是当你第一次建立连接时，每个连接只发生一次。
我只是想检查那里没有其他因素比一些TLS加密CPU周期更重要，并且延迟了ms。
不，没有其他因素。事实上，相反。如今，越来越多的理由使用TLS来保护您的隐私。
对于未经过身份验证的渠道，例如订单的当前状态，是否可以轻松决定使用ws，主要是为了节省时间（但最少）？
为什么呢？如果wss可用，我会将它用于所有事情。如果你真的遇到CPU问题，你可以重新审视使用wss是否与它有关，但这不大可能发生，在我看来，你从wss开始没什么可失去的。虽然人们希望智能地设计代码，但是在您甚至需要担心记录的，测量的性能问题之前，您并不想尝试微观优化与性能相关的事情。
使用TLS的一般原因：
答案 1 :(得分：1)
我只是想检查一下其他因素是否比一些TLS加密CPU周期更重要，并且延迟了ms。
实际上，有。
这也是drib.tech：
在编写本规范时，应该注意端口80和443上的连接具有显着不同的成功率，端口443上的连接更有可能成功，尽管这可能随时间而变化。
某些网络中介（特别是某些移动服务提供商）在ws个连接上失败，但在使用wss时工作正常。
原因似乎是这些中介（代理/路由器）将尝试读取WebSocket消息，就好像它是HTTP并“修复”HTTP错误或解决缓存（实际上会破坏WebSocket数据）。
加密的wss协议将触发直通模式，因为这些中介将无法读取数据或“修复”任何HTTP错误。
Websocket协议使用客户端帧掩码用于相同目的，但有时结果有限。使用wss会增加某些网络的连接性。