的WebSocket交通編碼（GZip壓縮）

StackOverflow的使用上的所有他們的頁面的gzip編碼;它們的websocket流量似乎也是如此，因爲它似乎完全混淆了。的WebSocket交通編碼（GZip壓縮）

enter image description here

如何/什麼，他們會用它來實現這一點;而是我需要做什麼來實現相同，因爲我的websocket服務器託管在它自己的獨立服務器上沒有IIS等？

值得注意過了http compression沒有設置自己的WebSocket連接請求，無論是。

完整的日誌截圖：http://i44.tinypic.com/19s4yr.jpg

來源

2012-04-08 f0x

出於興趣，怎麼都你嗅探websocket的流量？此外，值得注意的是，上述消息的純文本部分長度爲19個字節，因此實際上可能不會被混淆。 – simonc 2012-04-08 10:45:51

@simonc我其實只是偶然看到它爲什麼瀏覽日誌;不適當的更新了這個帖子，並在屏幕上顯示了它在fiddler上的樣子。那麼怎麼會呢，因爲我的websocket流量是明文。 – f0x 2012-04-08 10:53:53

根據RFC6455，從客戶端到服務器的WebSocket負載必須被掩蓋，服務器向客戶端必須不被掩蓋。屏蔽是通過XORring有效載荷與32位掩碼完成的..您在日誌中看到的值。

有位於提供基於幀的壓縮（放氣）的烹飪一個WS擴展。這與掩蔽無關。使用每幀壓縮有效負載壓縮有效負載，然後屏蔽有效負載（客戶端到服務器）。

來源

2012-04-08 12:15:57 oberstet

謝謝，隊友！你是否也許可以在.net框架中向我指出這種屏蔽實現的方向？由於在我上面的屏幕截圖中，該值被屏蔽到客戶端，所以根據規範，SO實現是否是錯誤的？ – f0x 2012-04-08 15:44:58

屏幕截圖顯示：「從瀏覽器接收的68個字節..消息掩碼爲真」。所以，如果這是瀏覽器到服務器屏蔽的有效載荷，那麼沒關係。如果它實際上是服務器到客戶端，那麼它違反了規範。規範很明確：不可以。 – oberstet 2012-04-08 22:01:05

掩碼算法很簡單：payload [i]^= mask [i％4]，其中有效載荷和掩碼是字節數組，並且我索引幀有效載荷。 – oberstet 2012-04-08 22:02:46

我不認爲有任何這裏使用gzip壓縮。它看起來像小提琴手已經開始增加對websockets的支持，但它仍然是一個正在進行的工作。

日誌示出了連接
...然後12個字節（461287-收件箱中。最初的字節81 8C示出了新的完整的，文本用4字節掩碼和12個字節的數據幀的第一消息。提琴手正確地解碼這個）
...然後的19個字節（字節81個93的第二消息。 - 19字節到流 - 展現出新的，完整的，文本與4字節的蔭罩框架和19個字節的數據）
。 ..then的19個字節的第三消息（後面字節81 93 - 約44個字節到流 - 展現出新的，完整的，文本與4字節的蔭罩框架和19個字節的數據）

來源

2012-04-08 13:37:45 simonc

謝謝，夥計。我可以向您展示我的websocket實現的日誌，其中可以看到全文。 – f0x 2012-04-08 15:45:36

當然啊，我看到掩蔽確實是'假'，所以確實只是有效載荷的混淆。 http://i43.tinypic.com/2n8tug1.png哦和+1哈哈:) – f0x 2012-04-08 15:48:32

的WebSocket交通編碼（GZip壓縮）

回答

相關問題