StackOverflow在所有页面上使用GZip编码；对于他们的websocket流量似乎也是如此，因为它似乎完全被混淆了。
还值得注意的是，他们的 WebSocket 连接请求中也没有设置 HTTP 压缩。
WebSocket 流量编码（GZip）
6
还值得注意的是，他们的 WebSocket 连接请求中也没有设置 HTTP 压缩。
- cillierscharl
2
你好，想问一下你是如何嗅探WebSocket流量的？另外值得注意的是，上述消息的纯文本部分长度为19字节，因此实际上可能并没有被混淆。 - simonc
@simonc 我其实是在浏览日志的时候偶然发现的；我会更新帖子，附上 Fiddler 中它的截图。既然我的 WebSocket 流量都是明文的，那它可能是什么呢？ - cillierscharl
2个回答
6
根据 RFC6455 规范，WebSocket 客户端发送到服务器的有效负载必须进行屏蔽处理，从服务器发送到客户端的有效负载则不得进行屏蔽处理。使用32位掩码对有效负载进行 XOR 运算来进行屏蔽处理，您可以在日志中看到该值。
有一个 WebSocket 扩展名为 cooking，该扩展提供了基于帧的压缩（deflate）。这与屏蔽处理无关。启用每帧压缩的有效负载会进行压缩，然后对有效负载进行屏蔽处理（客户端发送到服务器）。
有一个 WebSocket 扩展名为 cooking，该扩展提供了基于帧的压缩（deflate）。这与屏蔽处理无关。启用每帧压缩的有效负载会进行压缩，然后对有效负载进行屏蔽处理（客户端发送到服务器）。
- oberstet
5
谢谢，伙计！你能否指导我如何实现这样的掩码功能，也许在 .net 框架上？由于我的屏幕截图中值是入站到客户端进行掩码处理的，那么根据规范，SO 的实现是否有误？ - cillierscharl
截图显示：“从浏览器接收到68字节..消息掩码为真”。所以，如果这是浏览器到服务器的掩码有效载荷，那就没问题。如果实际上是服务器到客户端，那么它就违反了规范。规范对此非常明确：必须不这样做。 - oberstet
掩码算法很简单：payload[i] ^= mask[i % 4]，其中payload和mask是字节数组，i索引帧负载。 - oberstet
因为字符串“reputation”是可见的，所以它显然没有显示XOR字节。我假设发生的情况是有效负载被序列化为客户端/服务器理解的格式，例如bson。 - statenjason
也许对一些人有所帮助：http://www.altdevblogaday.com/2012/01/23/writing-your-own-websocket-server/ - Beachhouse
1
我认为这里没有使用gzip。看起来Fiddler已经开始支持WebSockets，但仍在进行中。
日志显示了一个连接
...然后是第一条12字节的消息（461287-inbox）。初始字节81 8C显示了一个新的、完整的文本帧，带有4字节掩码和12字节数据。Fiddler正确地解码了这个。
...然后是第二条19字节的消息（字节81 93 - 在流中的第19字节处 - 显示了一个新的、完整的文本帧，带有4字节掩码和19字节数据）
...然后是第三条19字节的消息（后面的字节81 93 - 大约在流的第44字节处 - 显示了一个新的、完整的文本帧，带有4字节掩码和19字节数据）
- simonc
2
谢谢，伙计。我可以向您展示我的WebSocket实现日志，其中可以看到完整的文本。 - cillierscharl
啊，当然，我看到掩码确实是“false”，所以确实只是有效载荷的混淆。http://i43.tinypic.com/2n8tug1.png 哦，还有+1哈哈 :) - cillierscharl
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接