WebSocket 协议（RFC6455）中文翻译版（word版）
翻译自： /
Internet Engineering Task Force (IETF) I. Fette
Request for Comments: 6455 Google, Inc.
Category: Standards Track A. Melnikov
ISSN: 2070-1721 Isode Ltd. December 2011
WebSocket 协议
摘要
WebSocket协议使在控制环境下运行不受信任代码的客户端和能够选择与那些代码通信的远程主机之间能够双向通信。用于这个的安全模型是以origin为基础的安全模型，一般被浏览器使用。协议包含打开握手，其次是基本消息框架，在 TCP 之上。这项技术的目的是为基于浏览
器的、需要与服务器双向通信的应用程序提供一种不依赖于打开多个HTTP连接的机制（例如，使用XMLHttpRequest 或 <iframe> 和长轮询）。
本备忘录的状态
这是一个Internet标准跟踪文件。javascript是什么意思中文翻译
这个文档是因特网工程师任务组（IETF）的一个产品。它代表了IETF社区的共识。它已接受公众审查，因特网工程指导组（IESG）证明可出版。关于互联网标准的进一步信息在RFC5741的第2章节。
关于本文档当前状态的信息、勘误表和如何提供反馈，可以在 /info/rfc6455 到。
版权声明
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1 介绍
1.1 背景
这部分是不规范的。
历史上，创建需要在客户端和服务器间双向通信的网络应用程序（如即时消息和游戏程序）要求滥用 HTTP 来轮询服务器来获得更新，通过不同 HTTP 请求来发送上行通知。
这导致各种问题：
•服务器被迫为每个客户端使用一些不同的底层TCP连接：一个用来向客户端发送消息，为每个到来的消息使用一个新的。
•通信（wire）协议具有很高的开销，因为每个客户端到服务器的消息有HTTP头。
•客户端侧的脚本被迫维护输出连接到输入连接的映射来追踪响应。
一个简单的解决方法是为双向传输使用单一的TCP连接。这是WebSocket协议提供的。结合WebSocket API（WSAPI），它为web页面到远程服务器的双向通信提供了HTTP轮询的替代方案。
同样的技术也可用于各种web应用程序：游戏，股票行情，多用户协同编辑的应用程序，用户界面实时展示服务器侧服务等。
WebSocket协议设计用来取代使用HTTP作为传输层的双向通信技术，并从现有的基础设施（代理、过滤、认证）受益。这些技术作为效率与可靠性的平衡而实现，因为HTTP最初并不是用于双向通信的（见RFC6202有多更讨论）。WebSocket尝试解决在现有HTTP基础设施的环境下现有HTTP双向通信技术的目标；像这样，它设计来工作于HTTP 80、443端口上，
并支持HTTP代理和中间设施，即使这意味着增加现有环境的一些复杂性。然而，设计并没有将WebSocket局限于HTTP，未来的实现可以在特定的端口上使用更简单的握手，而不需要重新发明整个协议。最后一点是重要的，因为交互式消息的传输模式并不紧密符合标准的HTTP传输，会在一些部件上引起异常的负载。
1.2 协议概览
这部分是不规范的。
WebSocket 协议有两部分：握手和数据传输。
来自客户端的握手开起来像下面：
来自服务器的握手开起来像下面：
来自客户端的引导行遵从Request-Line格式，来自服务器的引导行遵从Status-Line格式。Request-Line和Status-Line 在RFC2616定义。
在两种情况下，引导行后面跟着一组未排序的头域。这些头域的意义在本文档的第4章指定。
额外的头域也可能出现，如cookie RFC6265。头的格式和解析在RFC2616定义。
一旦客户端和服务器都发送了他们的握手，如果握手成功，传输数据部分开始。这是一个双向传输通道，每个端都能独立、随意发送数据。
在成功握手后，客户端和服务器来回传输数据是以消息message为概念单位的。在传输介质上（on the wire），一个消息由一个或多个帧frame组成。WebSocket消息不需要对应到特定网络层的帧，因为分帧后的消息可能被中间设施合并或拆分。
一帧都有一个关联的类型。属于同一个消息的帧拥有相同的数据类型，广义地说，有文本数据（解释为UTF-8 RFC3629文本）、二进制数据（它的解释留给了应用程序）和控制帧（不打算携带应用数据，携带的是协议层的信号，如连接关闭信号）类型。这个版本的协议定义了6种帧类型，并保留了10种为以后使用。
1.3 打开握手
这部分是不规范的。
打开握手为了兼容基于HTTP的服务器端软件和中间设施，使同一个端口能够接受HTTP客户端和WebSocket客户端，为了这个目的，WebSocket客户端的握手是HTTP请求的升级。
为了兼容RFC2616，客户端握手里的头域可能以任意的顺序发送，因此不同头域接收到的顺序是不重要的。
GET方法(RFC2616)的Request-URI用于识别WebSocket连接的终端，允许一个IP地址服务多个域domain，和允许单个服务器提供多个WebSocket终端。
客户端在握手的Host头域里包含主机名，这样，客户端和服务器能够验证他们同意使用哪个主机。额外的头域用于选择WebSocket协议的选项。此版本中典型的可用选项有子协议选择器Sec-WebSocket-Protocol，Sec-WebSocket-Protocol列出客户端支持的扩展，Origin头域等等。Sec-WebSocket-Protocol请求头域可用来表明客户端可接受的子协议（WebSocket协议之上的应用程序层协议）。服务器选择1个或0个可接受的协议，输出到它的握手，来指明它选择了那个协议。
Sec-WebSocket-Protocol: chat
Origin 头域（RFC6454）用于保护WebSocket服务器不被未授权的运行在浏览器的脚本跨源使用WebSocket API。如果服务器不想接受来自这个源的连接，它可以拒绝连接，并发送一个合适的HTTP错误码。这个头域由浏览器客户端发送；对于非浏览器客户端，这个头域可能发送，如果它在客户端上下文环境中有意义。
最后，服务器得向客户端证明它接收到了客户端的WebSocket握手，为使服务器不接受非WebSocket连接。这防止攻击者通过XMLHttpRequest发送或表单提交精心构造的包来欺骗WebSocket服务器。
为了证明握手被接收，服务器把两块信息合并来形成响应。第一块信息来自客户端握手头域Sec-WebSocket-Key，如 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 对于这个头域，服务器取头的值（由于出现在头域，例如，base64编码[RFC4648]后的版本，消除任何前面后面的空白符），以字符串的形式拼接全局唯一的（GUID，[RFC4122]）标识：258EAFA5-E914-47DA-95CA-C5AB0DC85B11，此值不大可能被不明白WebSocket协议的网络终端使用。然后进行SHA-1 hash（160位）编码，再进行base64编码，将结果作为服务器的握手返回。
具体如下：
请求头：Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
取值，字符串拼接后得到："dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11";
SHA-1后得到：0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea
Base64后得到：s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
最后的结果值作为响应头 Sec-WebSocket-Accept 的值。
来自服务器的握手比客户端的简单很多。首先是HTTP 状态行，状态码是101： HTTP/1.1 101 Switching Protocols 任何非101的状态码表示WebSocket握手还没有完成，HTTP语义仍然生效。
Connection和Upgrade头域完成HTTP升级。Sec-WebSocket-Accept 头表明服务器是否愿意
接受连接。如果有，值必须是前面提到的算法得到的值，否则不能解释为服务器接受连接。
这些字段由WebSocket客户端为脚本页面检测，如果Sec-WebSocket-Accept的值不符合预期的值，如果头缺失， 或HTTP状态码不是101，连接不会建立，WebSocket帧不会发送。
还可以包含一些可选字段。在协议的这个版本里，主要的可选字段是Sec-WebSocket-Protocol，表示服务器选择的子协议。WebSocket客户端验证服务器选择了一个客户端握手中指定的值。支持多个子协议的服务器必须确保它选择了一个基于客户端握手并在它自己的握手里指定了它。
服务器也可以设置cookie有关的可选头。
1.4 关闭握手
这部分是不规范的。
关闭握手远比打开握手简单。
任何一端都可以发送带有指定控制序号的数据的帧来开始关闭握手（详细在5.5.1节）。当接
收到这样的帧时，如果还没有发送，另一端发送一个关闭帧（B）作为响应。当接收到那个（B）帧时，第一个端关闭连接，因为知道没有更多的数据需要传输。
发送表明关闭连接的控制帧后，端不应该再发数据；接收到表示应该关闭连接的控制帧后，端丢弃后面接收的所有数据。
两端都可以安全地同时开始关闭握手。
这个关闭握手想补充TCP的关闭握手（FIN/ACK），依据是，TCP关闭握手不总是端到端可靠的，特别是出现拦截代理和其他的中间设施。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。