1.4 关闭握手关闭握手的操作也很简单。
任意一端都可以选择关闭握手过程。需要关闭握手的一方通过发送一个特定的控制序列（第 5 节会描述）去开始一个关闭握手的过程。一端一旦接受到了来自另一端的请求关闭控制帧后，接收到关闭请求的一端如果还没有返回一个作为响应的关闭帧的话，那么它需要先发送一个关闭帧。在接受到了对方响应的关闭帧之后，发起关闭请求的那一端就可以关闭连接了。
在发送了请求关闭控制序列之后，发送请求的一端将不可以再发送其他的数据内容；同样的，一但接收到了一端的请求关闭控制序列之后，来自那一端的其他数据内容将被忽略。注意这里的说的是数据内容，控制帧还是可以响应的。否则就下面一句就没有意义了。
两边同时发起关闭请求也是可以的。
之所以需要这样做，是因为客户端和服务器之间可能还存在其他的中间件。一段关闭之后，也需要通知另一端也和中间件断开连接。
1.5 设计理念WebSocket 协议的设计理念就是提供极小的帧结构（帧结构存在的目的就是使得协议是基于帧的，而不是基于流的，同时帧可以区分 Unicode 文本和二进制的数据）。它期望可以在应用层中使得元数据可以被放置到 WebSocket 层上，也就是说，给应用层提供一个将数据直接放在 TCP 层上的机会，再简单的说就可以给浏览器脚本提供一个使用受限的 Raw TCP 的机会。
从概念上来说，WebSocket 只是一个建立于 TCP 之上的层，它提供了下面的功能：
- 给浏览器提供了一个基于源的安全模型（origin-based security model）
- 给协议提供了一个选址的机制，使得在同一个端口上可以创立多个服务，并且将多个域名关联到同一个 IP
- 在 TCP 层之上提供了一个类似 TCP 中的帧的机制，但是没有长度的限制
- 提供了关闭握手的方式，以适应存在中间件的情况
从概念上将，就只有上述的几个用处。不过 WebSocket 可以很好的和 HTTP 协议一同协作，并且可以充分的利用现有的 web 基础设施，比如代理。WebSocket 的目的就是让简单的事情变得更加的简单。
协议被设计成可扩展的，将来的版本中将很可能会添加关于多路复用的概念。
1.6 安全模型WebSocket 协议使用源模型（origin model），这样浏览器中的一个页面中的脚本需要访问其他源的资源时将会有所限制。如果是在一个 WebSocket 客户端中直接使用了 WebSocet（而不是在浏览器中），源模型就没有什么作用，因为客户端可以设置其为任意的值。
并且协议的设计目的也是不希望干扰到其他协议的工作，因为只有通过特定的握手步骤才能建立 WebSocket 连接。另外由于握手的步骤，其他已经存在的协议也不会干扰到 WebSocket 协议的工作。比如在一个 HTTP 表单中，如果表单的地址是一个 WebSocket 服务的话，将不会建立连接，因为到目前本文成文为止，在浏览器中是不可以通过 HTML 和 Javascript APIs 去设置 Sec- 头的。
1.7 和 TCP 以及 HTTP 之间的关系WebSocket 是一个独立的基于 TCP 的协议，它与 HTTP 之间的唯一关系就是它的握手请求可以作为一个升级请求（Upgrade request）经由 HTTP 服务器解释（也就是可以使用 Nginx 反向代理一个 WebSocket）。
默认情况下，WebSocket 协议使用 80 端口作为一般请求的端口，端口 443 作为基于传输加密层连（TLS） 接的端口
1.8 建立一个连接因为 WebSocket 服务通常使用 80 和 443 端口，而 HTTP 服务通常也是这两个端口，那么为了将 WebSocket 服务和 HTTP 服务部署到同一个 IP 上，可以限定流量从同一个入口处进入，然后在入口处对流量进行管理，概况的说就是使用反向代理或者是负载均衡。
1.9 WebSocket 协议的子协议在使用 WebSocket 协议连接到一个 WebSocket 服务器时，客户端可以指定其 Sec-WebSocket-Protocol 为其所期望采用的子协议集合，而服务端则可以在此集合中选取一个并返回给客户端。
这个子协议的名称应该遵循第 11 节中的内容。为了防止潜在的冲突问题，应该在域名的基础上加上服务组织者的名称（或者服务名称）以及协议的版本。比如 v2.bookings.example.net 对应的就是 版本号-服务组织（或服务名）-域名 |
