《WebSocket 协议中文翻译版》由会员分享，可在线阅读，更多相关《WebSocket 协议中文翻译版（28页珍藏版）》请在金锄头文库上搜索。
1、WebSocket协议（RFC6455）中文翻译版（word版）翻译自： http:/tools.ietf.org/rfc/rfc6455.txtInternetEngineeringTaskForce(IETF)I.FetteRequestforComments:6455Google,Inc.Category:StandardsTrackA.MelnikovISSN:2070-1721IsodeLtd.December2011WebSocket 协议摘要WebSocket 协议使在控制环境下运行不受信任代码的客户端和能够选择与那些代 码通信的远程主机之间能够双向通信。用于这个的安全模型是以
2、origin 为基础的 安全模型，一般被浏览器使用。协议包含打开握手，其次是基本消息框架，在TCP 之上。这项技术的目的是为基于浏览器的、需要与服务器双向通信的应用程序提供 一种不依赖于打开多个HTTP连接的机制(例如，使用XMLHttpRequest或 和长轮询)。本备忘录的状态这是一个 Internet 标准跟踪文件。这个文档是因特网工程师任务组(IETF)的一个产品。它代表了 IETF社区的共 识。它已接受公众审查，因特网工程指导组(IESG)证明可出版。关于互联网标 准的进一步信息在RFC5741的第2章节。关于本文档当前状态的信息、勘误表和如何提供反馈，可以在http:/www.rf
3、c- editor.org/info/rfc6455 找到。版权声明Copyright(c)2011IETFTrustandthepersonsidentifiedasthedocumentauthors. Allrightsreserved.ThisdocumentissubjecttoBCP78andtheIETFTrustsLegalProvisionsRelatingtoIETFDocuments( http:/trustee.ietf.org/license-info)ineffectonthedateof publicationofthisdocument.Pleasereview
4、thesedocumentscarefully,asthey describeyourrightsandrestrictionswithrespecttothisdocument.Code ComponentsextractedfromthisdocumentmustincludeSimplifiedBSDLicensetext asdescribedinSection4.eoftheTrustLegalProvisionsandareprovidedwithout warrantyasdescribedintheSimplifiedBSDLicense.1介绍1.1背景这部分是不规范的。历史
5、上，创建需要在客户端和服务器间双向通信的网络应用程序（如即时消息和游 戏程序）要求滥用HTTP来轮询服务器来获得更新，通过不同HTTP请求来发送上 行通知。这导致各种问题： 服务器被迫为每个客户端使用一些不同的底层TCP连接：一个用来向客户端 发送消息，为每个到来的消息使用一个新的。 通信（wire）协议具有很高的开销，因为每个客户端到服务器的消息有HTTP 头。 客户端侧的脚本被迫维护输出连接到输入连接的映射来追踪响应。一个简单的解决方法是为双向传输使用单一的TCP连接。这是WebSocket协议提 供的。结合WebSocketAPI（WSAPI），它为web页面到远程服务器的双向通信 提供
6、了 HTTP轮询的替代方案。同样的技术也可用于各种web应用程序：游戏，股票行情，多用户协同编辑的应 用程序，用户界面实时展示服务器侧服务等。WebSocket 协议设计用来取代使用 HTTP 作为传输层的双向通信技术，并从现有 的基础设施（代理、过滤、认证）受益。这些技术作为效率与可靠性的平衡而实 现，因为HTTP最初并不是用于双向通信的（见RFC6202有多更讨论）。WebSocket 尝试解决在现有 HTTP 基础设施的环境下现有 HTTP 双向通信技术的 目标；像这样，它设计来工作于HTTP 80、443端口上，并支持HTTP代理和中间 设施，即使这意味着增加现有环境的一些复杂性。然而
7、，设计并没有将WebSocket局限于HTTP，未来的实现可以在特定的端口上使用更简单的握手，而 不需要重新发明整个协议。最后一点是重要的，因为交互式消息的传输模式并不紧 密符合标准的 HTTP 传输，会在一些部件上引起异常的负载。1.2协议概览这部分是不规范的。WebSocket 协议有两部分：握手和数据传输。来自客户端的握手开起来像下面：来自服务器的握手开起来像下面：来自客户端的引导行遵从 Request-Line 格式，来自服务器的引导行遵从 StatusLine 格式。Request-Line 和 Status-Line 在 RFC2616 定义。在两种情况下，引导行后面跟着一组未排序
8、的头域。这些头域的意义在本文档的第4章指定。额外的头域也可能出现，如cookie RFC6265。头的格式和解析在 RFC2616 定义。一旦客户端和服务器都发送了他们的握手，如果握手成功，传输数据部分开始。这 是一个双向传输通道，每个端都能独立、随意发送数据。在成功握手后，客户端和服务器来回传输数据是以消息message为概念单位的。 在传输介质上（onthewire ），个消息由一个或多个帧frame组成。WebSocket 消息不需要对应到特定网络层的帧，因为分帧后的消息可能被中间设施合并或拆 分。一帧都有一个关联的类型。属于同一个消息的帧拥有相同的数据类型，广义地说， 有文本数据（解释
9、为 UTF-8 RFC3629 文本）、二进制数据（它的解释留给了应用 程序）和控制帧（不打算携带应用数据，携带的是协议层的信号，如连接关闭信 号）类型。这个版本的协议定义了6 种帧类型，并保留了10种为以后使用。1.3打开握手这部分是不规范的。打开握手为了兼容基于HTTP的服务器端软件和中间设施，使同一个端口能够接受 HTTP 客户端和 WebSocket 客户端，为了这个目的， WebSocket 客户端的握手是 HTTP 请求的升级。为了兼容RFC2616,客户端握手里的头域可能以任意的顺序发送，因此不同头域接 收到的顺序是不重要的。GET方法（RFC2616）的Request-URI用
10、于识别WebSocket连接的终端，允许一个IP 地址服务多个域domain，和允许单个服务器提供多个WebSocket终端。客户端在握手的 Host 头域里包含主机名，这样，客户端和服务器能够验证他们同 意使用哪个主机。额外的头域用于选择WebSocket协议的选项。此版本中典型的 可用选项有子协议选择器 Sec-WebSocket-Protocol， Sec-WebSocket-Protocol 列 出客户端支持的扩展，Origin头域等等。Sec-WebSocket-Protocol请求头域可用 来表明客户端可接受的子协议（WebSocket协议之上的应用程序层协议）。服务 器选择 1
11、个或 0个可接受的协议，输出到它的握手，来指明它选择了那个协议。 Sec-WebSocket-Protocol: chatOrigin头域（RFC6454）用于保护WebSocket服务器不被未授权的运行在浏览器 的脚本跨源使用 WebSocketAPI 。如果服务器不想接受来自这个源的连接，它可以 拒绝连接，并发送一个合适的 HTTP 错误码。这个头域由浏览器客户端发送；对于 非浏览器客户端，这个头域可能发送，如果它在客户端上下文环境中有意义。最后，服务器得向客户端证明它接收到了客户端的WebSocket握手，为使服务器 不接受非 WebSocket 连接。这防止攻击者通过 XMLHttpR
12、equest 发送或表单提交精 心构造的包来欺骗 WebSocket 服务器。为了证明握手被接收，服务器把两块信息合并来形成响应。第一块信息来自客户端握手头域 Sec-WebSocket-Key，如 Sec-WebSocket-Key:dGhlIHNhbXBsZSBub25jZQ= 对于这个头域，服务器取头的值（由于出现在头域， 例如，base64编码RFC4648后的版本，消除任何前面后面的空白符），以字符串 的形式拼接全局唯一的（GUID，RFC4122）标识：258EAFA5-E914-47DA-95CA- C5AB0DC85B11，此值不大可能被不明白WebSocket协议的网络终端使
13、用。然后进 行SHA-1hash （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 0xeaBase64 后得到
14、： s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 最后的结果值作为响应头 Sec-WebSocket-Accept 的值。来自服务器的握手比客户端的简单很多。首先是HTTP状态行，状态码是101：HTTP/1.1 101 Switching Protocols 任何非 101 的状态码表示 WebSocket 握手还 没有完成， HTTP 语义仍然生效。Connection 和 Upgrade 头域完成 HTTP 升级。Sec-WebSocket-Accept 头表明服务 器是否愿意接受连接。如果有，值必须是前面提到的算法得到的值，否则不能解释 为服务器接受连接。这些字段由WebS
15、ocket客户端为脚本页面检测，如果Sec-WebSocket-Accept的值 不符合预期的值，如果头缺失，或HTTP状态码不是101，连接不会建立， WebSocket 帧不会发送。还可以包含一些可选字段。在协议的这个版本里，主要的可选字段是 Sec-WebSocket-Protocol，表示服务器选择的子协议。WebSocket客户端验证服务器 选择了一个客户端握手中指定的值。支持多个子协议的服务器必须确保它选择了一 个基于客户端握手并在它自己的握手里指定了它。服务器也可以设置cookie有关的可选头。1.4关闭握手关闭握手远比打开握手简单。任何一端都可以发送带有指定控制序号的数据的帧来
16、开始关闭握手（详细在 5.5.1 节）。当接收到这样的帧时，如果还没有发送，另一端发送一个关闭帧（B）作为 响应。当接收到那个（B）帧时，第一个端关闭连接，因为知道没有更多的数据需 要传输。发送表明关闭连接的控制帧后，端不应该再发数据；接收到表示应该关闭连接的控 制帧后，端丢弃后面接收的所有数据。两端都可以安全地同时开始关闭握手。这个关闭握手想补充TCP的关闭握手（FIN/ACK），依据是，TCP关闭握手不总是 端到端可靠的，特别是出现拦截代理和其他的中间设施。通过发送一个关闭帧并等待返回关闭帧响应，可以避免一些数据丢失的特殊情况。 例如，在一些平台上，如果一个套接字关闭时有数据在接收队列， RST 包发送后， 将导致recv（）失败，因为接收到RST，即使
