首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

WebSocket 协议(4)

WebSocket 协议(4)

2 一致性的要求见原文  

3 WebSocket URIs在这份技术说明中,定义了两种 URI 方案,使用 ABNF 语法  ,以及 URI 技术说明   中的生产式。
ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]host = <host, defined in [RFC3986], Section 3.2.2>port = <port, defined in [RFC3986], Section 3.2.3>path = <path-abempty, defined in [RFC3986], Section 3.3>query = <query, defined in [RFC3986], Section 3.4>端口部分是可选的;“ws” 默认使用的端口是 80,“wss” 默认使用的端口是 443。
如果资源标识符(URI)的方案(scheme)部分使用的是大小写不敏感的 “wss” 的话,那么就说这个 URI 是 “可靠的 secure”,并且说明 “可靠标记(secure flag)已经被设置”。
“资源名称 resource-name” 也就是 4.1 节中的 /resource name/,可以按下面的部分(顺序)连接:
  • 如果不用路径不为空,加上 “/”
  • 紧接着就是路径部分
  • 如果查询组件不为空 ,加上 “?“
  • 紧接着就是查询部分
片段标识符(fragment identifier) “#” 在 WebSocket URIs 的上下文是没有意义的,不能出现在 URIs 中。在 WebSocket 的 URI 中,如果出现了字符 “#” 需要使用 %23 进行转义。
4.1 客户端要求为了建立一个 WebSocket 连接,由客户端打开一个连接然后发送这一节中定义的握手信息。连接初始的初始状态被定义为 “连接中 CONNECTING”。客户端需要提供 /host/,/port/,/resource name/ 和 /secure/ 标记,这些都是上一节中的 WebSocket URI 中的组件,如果有的话,还需要加上使用的 /protocols/ 和 /extensions/。另外,如果客户端是浏览器,它还需要提供 /origin/。
连接开始前需要的设定信息为(/host/, /port/, /resource name/ 和 /secure/)以及需要使用的 /protocols/ 和 /extensions/,如果在浏览器下还有 /origin/。这些设定信息选定好了之后,就必须打开一个网络连接,发送握手信息,然后读取服务端返回的握手信息。具体的网络连接应该如何被打开,如何发送握手信息,如何解释服务端的握手响应,这些将在接下来的部分讨论。我们接下来的文字中,将使用第 3 节中定义的项目名称,比如 “/host/” 和 “/secure/”。
  • 在解析 WebSocket URI 的时候,需要使用第 3 节中提到的技术说明去验证其中的组件。如果包含了任何无效的 URI 组件,客户端必须将连接操作标记为失败,并停止接下来的步骤
  • 可以通过 /host/ 和 /port/ 这一对 URI 组件去标识一个 WebSocket 连接。这一部分的意思就是,如果可以确定服务端的 IP,那么就使用 “服务端 IP + port” 去标识一个连接。这样的话,如果已经存在一个连接是 “连接中 CONNECTING” 的状态,那么其他具有相同标识的连接必须等待那个正在连接中的连接完成握手后,或是握手失败后关闭了连接后,才可以尝试和服务器建立连接。任何时候只能有一个具有相同的标识的连接是 “正在连接中” 的状态。
    但是如果客户端无法知道服务器的IP(比如,所有的连接都是通过代理服务器完成的,而 DNS 解析部分是交由代理服务器去完成),那么客户端就必须假设每一个主机名称对应到了一个独立服务器,并且客户端必须对同时等待连接的的连接数进行控制(比如,在无法获知服务器 IP 的情况下,可以认为 a.example.com 和 b.example.com 是两台不同的服务器,但是如果每台服务器都有三十个需要同时发生的连接的话,可能就应该不被允许)
    注意:这就使得脚本想要执行 “拒绝服务攻击 denial-of-service attack” 变得困难,不然的话脚本只需要简单的对一个 WebSocket 服务器打开很多的连接就可以了。服务端也可以进一步的有一个队列的概念,这样将暂时无法处理的连接放到队列中暂停,而不是将它们立刻关闭,这样就可以减少客户端重连的比率。
    注意:对于客户端和服务器之间的连接数是没有限制的。在一个客户端请数目(根据 IP)达到了服务端的限定值或者服务端资源紧缺的时候,服务端可以拒绝或者关闭客户端连接。
  • 使用代理:如果客户端希望在使用 WebSocket 的时候使用代理的话,客户端需要连接到代理服务器并要求代理服务器根据其指定的 /host/,/port/ 对远程服务器打开一个 TCP 连接,有兴趣的可以看  。
    如果可能的话,客户端可以首选适用于 HTTPS 的代理设置。
    如果希望使用   脚本的话,WebSocket URIs 必须根据第 3 节说的规则。
    注意:在使用 PAC 的时候,WebSocket 协议是可以特别标注出来的,使用 “ws” 和 “wss”。
  • 如果网络连接无法打开,无论是因为代理的原因还是直连的网络问题,客户端必须将连接动作标记为失败,并终止接下来的行为。
  • 如果设置了 /secure/,那么客户端在和服务端建立了连接之后,必须要先进行 TLS 握手,TLS 握手成功后,才可以进行 WebSocket 握手。如果 TLS 握手失败(比如服务端证书不能通过验证),那么客户端必须关闭连接,终止其后的 WebSocket 握手。在 TLS 握手成功后,所有和服务的数据交换(包括 WebSocket 握手),都必须建立在 TLS 的加密隧道上。
    客户端在使用 TLS 时必须使用 “服务器名称标记扩展 Server Name Indication extension”  

返回列表