Google chrome 在wss安全模式下运行时，chrome中的websocket性能明显较差

我似乎遇到了一些问题，表明wss安全WebSocket在Chrome上比IE和Firefox慢得多。我环顾四周，但找不到任何真实的信息来证实其他人看到了这种行为

总之： 我使用一个LoalHub C++ WebSoSver服务器来将各个二进制图像PNG帧发送到同一台机器上打开的网页。这必须是WebSocket的安全wss版本

我不能真正地流式传输视频并使用视频标签，因为延迟/延迟必须是最小的

潜在的限制因素之一是websocket连接将提供多少数据吞吐量。目前只是为了原型化，我使用mongoose作为服务器。服务器似乎不是限制因素，它似乎是Chrome wss websocket处理

在我的高规格开发机器上的测试只是通过websocket发送数据。目前，我不想对传递的实际数据做任何事情。 客户端发送一个wss客户端->服务器字符串，表示“pull”。 服务器使用wss服务器客户端1兆字节二进制blob进行响应。 客户端使用wss客户端服务器字符串回答“pull”。 服务器使用wss服务器客户端1兆字节二进制blob进行响应。 ……等等

以下是我每秒获得的安全和非安全WebSocket的二进制帧数：

IE（v10）无线传感器网络：120无线传感器网络：221

Firefox（v28）wss:65 ws:170

铬合金（v35）wss:17 ws:93

您可以看到，与其他浏览器相比，chrome wss的性能似乎非常差。我在三台电脑上试过，结果都差不多。我尝试了0.1 MB到100 MB的不同blob大小，这对实际数据速率吞吐量没有实际影响。我试过禁用Nagle的算法

有人对我可能遗漏的东西有什么想法吗？ 有人能确认chrome wss的性能可能很差吗

谢谢

马特

---

更多信息：

在评论之后：我启用了“#启用websocket实验实现”，但似乎没有什么区别。我还尝试了最新的chrome canary版本，但这似乎也没什么不同

更多信息：

在带有64位调试服务器的开发人员计算机上的开发人员计算机上的更多结果（每秒周期数）。发送“拉”到服务器，用任意二进制1000000字节缓冲区进行应答。 已尝试为每个客户端使用2个套接字，每个套接字位于不同的子协议上

IE（v10）：wss:120 ws:221 wss[2个WebSocket]：176

Firefox（v28）：wss:65 ws:170 wss[2个websockets]：59

Chrome（v35）wss:17 ws:93 wss[2个WebSocket]：18

IE使用2个WebSocket似乎可以显著加快速度。Firefox和Chrome没有

---

---

根据chromium Discussion的反馈，许多速度差异似乎是由于客户端和服务器之间协商的密码造成的

为了证实这一点，我尝试将服务器密码编码为SSL_CTX_set_cipher_list（CTX，“AES128-SHA”）；然后，帧速率如下所示：

Chrome版本35.0.1916.153 m:49.75 Chrome版本38.0.2068.0金丝雀（64位）：53.15 Firefox版本30.0:61.8 IE 30.0:68.21

---

尽管存在一些差异，但所有浏览器的速度现在都处于相同的水平。在这种情况下，我将控制服务器，并能够决定一个合适的密码列表。

我没有直接提示您的观察结果，但您可能会研究浏览器和TLS/非TLS之间的线路级开销/差异。另外：Chrome最近切换到了一个新的WS-UndertheHood实现（忘记了是哪个版本），这带来了一些影响：另一个想法是：尝试不同的密码。例如，从服务器端强制执行“空密码”。不确定浏览器是否接受空密码，但如果接受空密码，这可能有助于了解发生了什么。谢谢您的评论。我将查看这些链接，同时等待其他人是否看到类似的性能问题。我已经在chromium上提出了这个问题-discuss@chromium.org如果出现任何重大问题，我会在这里发布反馈。希望是我做错了什么。。。