Question

暴露WebSocket碎片会在客户端API中有任何价值吗？

阅读RFC 6455后，我确信一个非延续框架并不保证你的语义方面的任何东西。一个人不应该依赖于框架边界。这太危险了。规范明确地解决了这个问题：

private func translateY(y: CGFloat) -> CGFloat {
    if barsAreReversed {
        return round(graphingArea.minY + graphingArea.height * (y - graphingWindow.startValue) / (graphingWindow.length))
    } else {
        return round(graphingArea.maxY - graphingArea.height * (y - graphingWindow.startValue) / (graphingWindow.length))
    }
}

因此，接收二进制或文本类型的非连续帧并不意味着它是从通道的另一侧发送的原子和有意义的东西。类似地，一系列连续帧并不意味着合并它们将产生有意义的消息。更令人沮丧的是，单个非连续类型帧可能是合并许多其他帧的结果。

总而言之，由于字节顺序相同（当然在没有扩展名的情况下），因此可以通过WebSocket发送的字节组几乎以任何方式重新接收。

如果是这样，那么引入这个概念是否有用？也许最好将其隐藏为实施的细节？我想知道WebSocket用户是否发现它在Netty，Jetty，Grizzly等产品中很有用。谢谢。

Answer 1

碎片不是任何东西的边界。

这只是实现基于内存，websocket扩展，性能等处理自身的一种方式。

典型情况是客户端端点发送文本，该文本通过permessage-deflate扩展，它将根据其deflate算法内存配置压缩和生成片段，将这些片段写入远程端点，因为它具有缓冲区要写入的压缩数据（某些实现仅在缓冲区已满或消息已收到其最终字节时才会写入）

虽然暴露了对API中片段的访问（Jetty有2个核心websocket API，两者都支持片段访问），但它实际上只对那些想要对流应用程序进行较低级别控制的人有用。（想想视频/ voip你要通过质量调整来传输，如果需要就丢弃数据，不要写得太快等等......）

Answer 2

关于未分段消息的RFC似乎存在一些歧义，它们可以任意拆分或组合。但是，在故意将消息作为多个片段（总共X个字节）发送的情况下，中介是否允许以一种在序列中返回不同数量（大于X）字节的方式分割其中一些帧？我不认为这是允许的，碎片在这方面有一些价值。这只是阅读RFC，而不是查看实际的实现。

一条消息的片段绝不能交错除非有扩展名，否则是另一条消息的片段谈判可以解释交错。

在我的阅读中，这意味着除非已经协商了一些允许它的扩展，否则来自不同消息的片段不能交错，这意味着虽然可以改变片段的数量，但确切的字节数（以及字节本身）不可能。

Answer 3

应该有控制碎片的支持；我们有一个 C# 程序，它有意将大型 WebSocket 消息拆分为小片段，以便接收数据的小型嵌入式处理器可以一次处理小块。相反，它完全合并成一个大块，消耗了大部分可用内存。我们不确定合并发生在哪里。也许是 C# 库。

API中的WebSocket框架碎片

3 个答案: