在wss安全模式下運行時Chrome中顯然很差的websocket性能

我似乎遇到了一些問題，表明wss安全websocket在Chrome瀏覽器上比IE和Firefox慢得多。我環顧四周，但找不到任何真實的信息以確認其他人看到此行爲。在wss安全模式下運行時Chrome中顯然很差的websocket性能

總結：我正在使用localhost C++ websocket服務器原型開發單個二進制圖像PNG幀到在同一臺機器上打開的網頁。這必須是websockets的安全wss版本。

我無法真正流式傳輸視頻並使用視頻標籤，因爲延遲/延遲必須最小化。

其中一個潛在的限制因素是websocket連接將提供多少數據吞吐量。目前僅用於原型設計，我使用貓鼬作爲服務器。服務器似乎不是限制因素，它似乎是Chrome瀏覽器的WebSocket處理。

我的high'ish spec dev機器上的測試只是通過websocket發送數據。目前我不想對傳遞的實際數據做任何事情。客戶端發送一個wss客戶機 - >服務器字符串，說「拉」。服務器回覆wss服務器客戶端1兆二進制blob。客戶端回覆wss客戶端服務器字符串說「拉」。服務器回覆wss服務器客戶端1兆二進制blob。 ..和等等...

這裏是每秒我得到安全和非安全的WebSockets二進制幀數：

IE（V10）WSS：120個WS：221

火狐（ V28）WSS：65個WS：170

鉻（V35）WSS：17個WS：93

你可以看到，鉻WSS性能相比於其它看起來很可憐。我已經在3臺電腦上嘗試了這一結果。我已經嘗試了0.1兆字節到100兆字節的不同BLOB大小，這對實際數據速率吞吐量沒有實際影響。我試過禁用Nagle的算法。

有沒有人有任何想法，我可能會失蹤？任何人都可以確認，鉻wss性能可能很差？

感謝

馬特

更多信息：

的意見後：我啓用了 '＃使-WebSocket的實驗性的實現'，但它似乎沒有什麼區別。我也嘗試了最新的鉻金絲雀建造，但這似乎也沒有什麼區別。

更多信息：我開發機器上

更多結果我開發機（每秒的週期數）在具有64位的調試服務器。發送「拉」到服務器，回覆任意二進制1000000字節緩衝區。嘗試每個客戶端使用2個套接字，每個使用不同的子協議。

IE（V10）：WSS：120個WS：221個WSS [2周的WebSockets]：176

火狐（V28）：WSS：65個WS：170個WSS [2周的WebSockets]：59

鉻（ v35）wss：17 ws：93 wss [2 websockets]：18

IE似乎使用2個websockets顯着加速。 Firefox和Chrome不支持。

來源

2014-06-23 user2968363

我沒有直接提示rgd你的觀察，但你可以看看http://tavendo.com/blog/post/dissecting-websocket-overhead/，它分析了瀏覽器和TLS/non- TLS。另外：Chrome最近在引擎蓋下改用了一個新的WS實現（忘記了哪個版本），並且有漣漪：http://www.ietf.org/mail-archive/web/hybi/current/msg10506.html – oberstet

另一個想法：嘗試不同的密碼。例如。從服務器端強制執行「空密碼」。不確定瀏覽器是否接受空密碼，但如果是這樣，它可能有助於找出發生了什麼事情。 – oberstet

感謝您的意見。我會看看這些鏈接，同時等待看看是否有其他人看到類似的性能問題。 – user2968363

經過鉻討論的反饋，很多速度差異似乎是由於客戶端和服務器之間協商的密碼造成的。爲了證實這一點，我嘗試將服務器密碼硬編碼爲SSL_CTX_set_cipher_list（ctx，「AES128-SHA」）;然後，幀速率如下：

鉻版35.0.1916.153米：49.75 鉻版38.0.2068.0金絲雀（64位）：53.15 火狐版30.0：61.8 IE 30.0：68.21

儘管有些區別，所有瀏覽器的速度現在都在同一個球場。在這種情況下，我在控制服務器，並能夠決定一個合適的密碼列表。

來源

2014-06-25 23:27:08 user2968363

在wss安全模式下運行時Chrome中顯然很差的websocket性能

回答

相關問題