WebSocket 协议(RFC6455)中文翻译版(word版).docxVIP

WebSocket 协议(RFC6455)中文翻译版(word版) WebSocket 协议〔RFC6455〕中文翻译版〔word版〕翻译自：http://.doczj/doc/6046de15b42acfc789eb172ded630b1c59ee9bc6.html /rfc/rfc6455.txtInternet Engineering Task Force (IETF) I. FetteRequest for Comments: 6455 Google, Inc.Category: Standards Track A. MelnikovISSN: 2070-1721 Isode Ltd. December 2011WebSocket 协议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-WebSoc