muxing 多路复用协议

可以在TCP, KCP, Websocket二进制流上构建出多路复用

帧处理

在底层使用流式连接，但在其上增加了消息帧处理，从而可在多逻辑流之间共享连接。每个帧包含如下头部：

• 版本 (8 位)
• 标志 (8 位)
• 保留字段 (16 位)
• 流ID (32 位)
• 长度 (32 位)

这意味着每个头部有 12 字节的开销。
所有字段均采用网络字节序（大端序）编码。
以下是各字段的详细描述：

版本字段

版本字段用于未来的向后兼容。目前，该字段始终设置为 0x1，

标志字段

标志字段用于提供与消息类型相关的额外信息。支持以下标志：

• 0x1 FIN - 发据是否发送完成，首次到收到FIN应执行半关闭，不能再送数据
• 0x8 RST - 立即重置流。

流ID字段

流ID字段用于标识帧所针对的逻辑流。客户端应使用奇数 ID，而服务器则使用偶数 ID，以避免冲突。另外，流ID 0 被保留用于表示整个会话。

长度字段

长度字段的含义取决于消息的类型：

• 数据 - 指示紧随头部后的字节数
• 最大的数据长度需随服务端与服务端约定，默认256KB。

消息流程

没有明确的连接建立过程；它依赖底层传输机制。然而，会话中存在客户端与服务器的区别。

打开流

要打开一个流，首先发送带有新流ID的数据， 可以是一个空包

由于依赖于底层的可靠传输，发送方可以随首帧同步发送数据。这在需要立即发送请求而不等待 RTT 的 RPC 系统中尤其适用。

这也意味着在数据发送后，连接可能会被拒绝。这与 TCP 略有不同，因为在 TCP 中连接一旦建立就不会被拒绝。客户端应准备好处理接收到的 RST 错误。

关闭流

要关闭一个流，任一方发送带有 FIN 标志的帧，表示对流进行半关闭，即发送方不再传输数据。

当发送都收到两端的FIN时，则表示流结束了。

当双方都完成关闭操作后，该流即被关闭。

或者，在发生错误时，可使用 RST 标志立即强行关闭流。

流量控制

每个帧都有最大的数据长度限制默认为256KB

会话终止

当会话即将终止时，从底层连接（如:Websocket的Close帧）进行关闭，分流协议不提供优雅关闭，很多底程协议都以实现，没必要增加