webscoket 协议中有一个非常有意思的设计，在opcode内，对帧类型进行了区分：文本和二进制流。但这个区分并没有规定文本类型有类似于http协议中空行表示结束的说法，而且长度也是由帧头记录，也就是说，单纯从协议格式上来讲，这个区分，没有任何实际的含义。RFC6455只是规定了如果采用文本帧，就必须用UTF8来编码，如果采用数据帧，则完全由应用程序来解释。这也许是为了给未知来源的文本帧提供了某种解读方式。
这种最大程度的向下兼容性在我看来，有点过于啰嗦，帧类型其实与子协议强相关。怎么解读帧都是应用层的事情，用什么格式来理解帧的内容，不就是subprotocol干的事情吗？不知道如何解析或如何使用的文本帧，除了浪费服务器的带宽之外，没有任何作用。而且在设计中，这个文本或则二进制帧的opcode也成了一个比较麻烦的障碍，应用层发送数据难道还需要根据websocket的实现所规定的帧类型进行编码？这儿应该有更方便，或则说更直接的方式来处理，理清楚思路之后，我决定将opcode交给应用层来处理，应用层必须注册 subprotocol，提供具体的帧解析的接口，握手的时候，如果没有指定subprotocol，那就采用一个通用的dummy来处理帧。而发送数据时，必须由subprotocol来决定使用文本还是二进制帧操作码，当接收到数据时，也必须将操作码和数据一起交给subprotocol来处理。websocket的实现本身对此不作任何干预。