Board logo

标题: WebSocket 协议(10) [打印本页]

作者: look_w    时间: 2019-1-15 19:49     标题: WebSocket 协议(10)

5.3 客户端到服务端掩码一个被掩码的帧需要将掩码标识位(第 5.2 节定义)设置为 1。
掩码钥匙 masking key 整个都在帧中,就像第 5.2 节定义的。它用于对 “有效负荷数据” 进行掩码操作,包括 “扩展数据” 和 “应用数据”。
掩码钥匙由客户端随机选取一个 32 位的值。在每次准备对帧进行掩码操作时,客户端必须选择在可选的 32 位数值集合中选取一个新的掩码钥匙。掩码钥匙的值需要是不可被预测的;因此,掩码钥匙必须来源于一个具有很强保密性质的生成器,并且 服务器/代理 不能够轻易的预测到一连串的帧中使用的掩码钥匙。不可预测的掩码钥匙可以防止恶意程序在帧的传输过程中探测到掩码钥匙的内容。  具体讨论了为什么对于一个安全性比较敏感的应用程序需要使用一个很强保密性质的生成器。
掩码不会影响 “有效负载数据” 的长度。为了将掩码后的数据进行反掩码,或者倒过来,可以使用下面的算法。同样的算法适用于不同方向发来的帧,比如,对于掩码和反掩码使用相同的步骤。
传输数据中的每 8 个数位的字节 i (transformed-octet-i),生成方式是通过原数据中的每 8 个数位的字节 i (original-octet-i)与以 i 与 4 取模后的数位为索引的掩码钥匙中的 8 为字节 j(masking-key-octet-j) 进行异或(XOR)操作:
j = i MOD 4transformed-octet-i = original-octet-i XOR masking-key-octet-j负载的长度不包括掩码钥匙的长度,它是 “有效负载数据 Payload data” 的长度,比如,位于掩码钥匙后的字节的长度。
5.4 消息碎片化消息碎片化的目的就是允许发送那些在发送时不知道其缓冲的长度的消息。如果消息不能被碎片化,那么一端就必须将消息整个地载入内存缓冲,这样在发送消息前才可以计算出消息的字节长度。有了碎片化的机制,服务端或者中间件就可以选取其适用的内存缓冲长度,然后当缓冲满了之后就发送一个消息碎片。
碎片机制带来的另一个好处就是可以方便实现多路复用。没有多路复用的话,就需要将一整个大的消息放在一个逻辑通道中发送,这样会占用整个输出通道。多路复用需要可以将消息分割成小的碎片,使这些小的碎片可以共享输出通道。(注意多路复用的扩展在这片文档中并没有进行描述)
除非运用了特定的扩展,否则帧是没有特定的语义的。在客户端和服务端协商了某个扩展,或者客户端和服务端没有协商扩展的情况下,中间件都有可能将帧进行 合并/分隔。也就是说,在客户端和服务端没有协商某个扩展时,双方都不应该猜测帧与帧之间的边界。注:这里的某个扩展的意思就是赋予了帧特定的语义的扩展,比如多路复用扩展。
下面的规则解释了如何进行碎片化:
注意:如果控制帧不能夹杂在消息帧的话,那么将导致 ping 的结果产生延迟,比如在处理了一个非常长的消息后才响应 ping 控制帧时。因此,要求在处理消息帧的期间可以响应控制帧。
重点注意:在没有扩展的情况下,接收端为了处理消息不是非得缓冲所有的帧。比如如果使用了 流API (streaming API),数据帧可以直接传递给应用层。不过这样假设并不一定在所有的扩展中都适用。




欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/) Powered by Discuz! 7.0.0