websocket协议

最新推荐文章于 2024-04-12 18:00:34 发布

xiaoming_zhong

最新推荐文章于 2024-04-12 18:00:34 发布

阅读量422

点赞数

文章标签： websocket

本文链接：https://blog.csdn.net/xiaoming_zhong/article/details/52369148

版权

URI方案:

ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]

本协议有两部分：握手和数据传输。

来自客户端的握手看起来像如下形式：

    GET /chat HTTP/1.1
    Host: server.example.com
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
    Origin: http://example.com
    Sec-WebSocket-Protocol: chat, superchat
    Sec-WebSocket-Version: 13

来自服务器的握手看起来像如下形式：

  HTTP/1.1 101 Switching Protocols 
  Upgrade: websocket 
  Connection: Upgrade 
  Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 
  Sec-WebSocket-Protocol: chat

来自客户端的首行遵照Request-Line格式。来自服务器的首行遵照Status-Line格式。详情见(https://tools.ietf.org/html/rfc2616)

打开阶段握手:

打开阶段握手目的是兼容基于HTTP的服务器软件和中间件，以便单个端口可以用于与服务器交流的HTTP客户端和与服务器交流的WebSocket客户端。
最后，WebSocket客户端的握手是一个HTTP Upgrade请求：

    GET /chat HTTP/1.1
    Host: server.example.com
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
    Origin: http://example.com
    Sec-WebSocket-Protocol: chat, superchat
    Sec-WebSocket-Version: 13

握手中的头字段可能由客户端按照任意顺序发送，因此在接收的不同头字段中的顺序是不重要的。

来自服务器的握手比客户端握手更简单。首行是一个HTTP Status-Line，具有状态码101：

  HTTP/1.1 101 Switching Protocols 
  Upgrade: websocket 
  Connection: Upgrade 
  Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 
  Sec-WebSocket-Protocol: chat

关闭阶段握手:

关闭阶段握手比打开阶段握手简单得多。两个节点中的任一个都能发送一个控制帧与包含一个指定控制序列的数据来开始关闭阶段握手。在收到这样一个帧时，另一个节点在响应中发送一个Close帧，如果还没有发送一个。在收到那个控制帧时，第一个节点接着关闭连接，安全地知道没有更多的数据到来。

----------------------------------------------------------------------------------------------------

客户端请求字段：

一旦一个到服务器的连接连接（包括通过代理或在TLS加密隧道之上的连接），客户端必须发送一个打开阶段握手到服务器。该握手包括一个HTTP Upgrade请求，连同一个必需的和可选的头字段列表。该握手的要求如下所示:

1.握手必须是有效的HTTP请求。

2.请求方法必须是GET、且HTTP版本必须是至少1.1。
例如，如果WebSocket URI是“ws://example.com/chat”，发送的第一行应该是“GET /chat HTTP/1.1”。

3.请求的“Request-URI”部分必须匹配定义在第三章的（一个相对URI）/resource name/或是一个绝对的http/https URI，当解析时，有一个/resource name/、/host/、和/port/匹配相应的ws/wss URI。

4.请求必须包含一个|Host|头字段，其值包含/host/加上可选的“:”后跟/port/（当没用默认端口时）。

5.请求必须包含一个|Upgrade|头字段，其值必须包含“websocket”关键字。

6.请求必须包含一个|Connection|头字段，其值必须包含“Upgrade”标记。

7.请求必须包含一个名字为| Sec-WebSocket-Key |的头字段，这个头字段的值必须是临时（nonce）组成的一个随机选择的已经base64编码的（参见[RFC4648]第4章）16位的值。临时必须是为每个连接随机选择的。

8.如果请求来自一个浏览器客户端，请求必须包含一个名字为|Origin|[RFC6454]的头字段。如果连接是来自非浏览器客户端，如果该客户端的语义匹配描述在这的用于浏览器的使用情况时，请求可以包含这个字段。该头字段的值是在建立正运行的连接代码中的环境的origin 的ASCII序列化。参考[RFC6454]获取如果构造该头字段的值的详细信息。

9.请求必须包含一个名字为|Sec-WebSocket-Version|的头字段。该头字段的值必须是13。

10.请求可以包含一个名字为|Sec-WebSocket-Protocol|的头字段。如果存在，该值表示一个或多个逗号分割的客户端想要表达的子协议，按优先顺序排列。包含该值的元素必须是非空字符串，且字符在U+0021到U+007E范围内但不包含定义在[RFC2616]中的分割字符且必须所有是唯一的字符串。用于该头字段值的ABNF是1#token，其构造和规则定义在[RFC2616]给出。

11.请求可以包含一个名字为|Sec-WebSocket-Extensions|的头字段。如果存在，该值表示客户端想要表达的协议级的扩展。

12.请求可以包含任意其他头字段，例如，cookie[RFC6265]和/或验证相关的头字段例如|Authorization|头字段[RFC2616]，其根据定义它们的文档处理。

客户端验证字段：

一旦客户端的打开阶段握手已经发送，客户端在发送任何进一步数据之前必须等待自服务器的一个响应。客户端必须验证服务器的响应，如下所示：

1.如果收到的服务器的状态码不是101，客户端处理每个HTTP[RFC2616]程序的响应。尤其是，如果收到一个401状态码客户端可能执行身份验证；服务器可能使用一个3xx状态码重定向客户端（但客户端不需要跟随他们），等等。否则，按以下步骤处理。

2.如果响应缺少一个|Upgrade|头字段或|Upgrade|头字段包含的值不是一个不区分大小写的ASCII匹配值“websocket”，客户端必须_失败WebSocket连接_。

3.如果响应缺少一个|Connection|头字段或|Connection|头字段不包含一个不区分大小的ASCII匹配值“Upgrade”符号，客户端必须_失败WebSocket连接_。

5.如果响应包含一个|Sec-WebSocket-Extensions|头字段且此头字段表示使用一个扩展但没有出现在客户端握手中（服务器表示的一个扩展，不是客户端请求的），
客户端必须_失败WebSocket连接_。

6.如果响应包含一个|Sec-WebSocket-Protocol|头字段且该头字段表示使用一个子协议但没出现在客户端握手中（服务器表示的一个子协议，不是客户端请求的），客户端必须_失败WebSocket连接_。

服务器端验证字段：

当客户端开始一个WebSocket连接，它发送它的打开阶段握手部分。服务器必须至少解析这个握手为了获取必要的信息来生成服务器握手部分。

1.一个HTTP/1.1或更高版本的GET请求，包括一个“Request-URI” [RFC2616]应该被解释为定义在第3章的/resource name/（或一个包含/resource name/的绝对HTTP/HTTPS URI）。