WebSocket数据帧和各种操作码
1这个操作码（Opcode）来传输文本的。没错，1这个操作码就是传输文本（UTF-8）的。在分片过程中把操作码设置为0，0也只是分片时用的。操作码是4位的，取值当然不止这两个，除了指定传输数据类型外还有其它用途的操作码。
规范文档中也提供了一个表格
| opcode | Meaning | 描述 | Reference |
| 0XXXXXXX | 数据帧 | 字节的最高位bit为0 | |
| 0 | Continuation Frame | RFC 6455 | |
| 1 | Text Frame | 文本（UTF-8）数据 | RFC 6455 |
| 2 | Binary Frame | 二进制数据 | RFC 6455 |
| 3-7 | 保留 | ||
| 1XXXXXXX | 控制帧 | 字节的最高位bit为1 | |
| 8 | Connection Close Frame | 服务器向客户端请求结束当前连接 | RFC 6455 |
| 9 | Ping Frame | 服务器向客户端发送一个Ping帧 | RFC 6455 |
| 10 | Pong Frame | 客户端返回给服务器端一个Pong帧 | RFC 6455 |
| 11-15 | 保留 |
目前就这么多个操作码被定义，其它都是预留的。0和1这两个之前的例子用过的就不说了。
2这个操作码是告诉服务器不要把数据转换成字符串，直接当做二进制数据来用。这会在传输图片之类的操作中用到，至于传输图片的例子以后再给吧。这篇主要是介绍后三个操作码。
8这个操作码是服务器向客户端请求结束当前连接用的，不要以为这很简单，WebSocket的建立连接需要握手协议，那么关闭也需要双方的协商，还有关闭的代码什么的，总之很麻烦，下回再介绍。
9和10这两个状态码就简单些了，它们是成对的。服务器向客户端发送一个Ping帧时客户端会自动返回一个Pong帧，并且数据部分与发送的完全相同。如果不同或收不到，则说明网络有问题。
