RFC6455-The WebSocket protocol 之一：1. Introduction

1. Introduction

1、介绍

1.1. Background

1.2 背景
_This section is non-normative._

这部分是非正式的。
Historically, creating web applications that need bidirectional
communication between a client and a server (e.g., instant messaging
and gaming applications) has required an abuse of HTTP to poll the
server for updates while sending upstream notifications as distinct
HTTP calls [RFC6202].

以前，客户端和服务端需要进行全双工交互的应用（像即时通讯或游戏程序），已经使HTTP得到了滥用，这种通过轮询机制得到服务端的更新的方式在发送上游通知的时候使用的是不同的http 请求。

This results in a variety of problems:
o The server is forced to use a number of different underlying TCP
connections for each client: one for sending information to the
client and a new one for each incoming message.
o The wire protocol has a high overhead, with each client-to-server
message having an HTTP header.
o The client-side script is forced to maintain a mapping from the
outgoing connections to the incoming connection to track replies.

这产生了许多问题：

o 服务端被迫与每一个客户端建立了许多不同的底层的TCP连接：一些负责向客户端发送消息，另一些负责接收数据。
o 这个网络协议有很高的开销，每一个从客户端到服务端的消息都有一个HTTP header。
o 为了跟踪回复信息，客户端的脚本被迫去维护一个外出连接和进入连接的对应关系。

A simpler solution would be to use a single TCP connection for
traffic in both directions. This is what the WebSocket Protocol
provides. Combined with the WebSocket API [WSAPI], it provides an
alternative to HTTP polling for two-way communication from a web page
to a remote server.

一个简单的解决方式是通过一个TCP连接来进行双向的传输。这就是WebSocket协议提供的。综合WebSocket协议的API，它为网页到远程服务器的双向通讯提供了除HTTP轮询之外的又一种方案。
The same technique can be used for a variety of web applications:
games, stock tickers, multiuser applications with simultaneous
editing, user interfaces exposing server-side services in real time,
etc.

这种技术可以被用在很到网络应用中：游戏、股票、多用户同步编辑程序、服务端即时服务的用户接口。
The WebSocket Protocol is designed to supersede existing
bidirectional communication technologies that use HTTP as a transport
layer to benefit from existing infrastructure (proxies, filtering,
authentication). Such technologies were implemented as trade-offs
between efficiency and reliability because HTTP was not initially
meant to be used for bidirectional communication (see [RFC6202] for
further discussion). The WebSocket Protocol attempts to address the
goals of existing bidirectional HTTP technologies in the context of
the existing HTTP infrastructure; as such, it is designed to work
over HTTP ports 80 and 443 as well as to support HTTP proxies and
intermediaries, even if this implies some complexity specific to the
current environment. However, the design does not limit WebSocket to
HTTP, and future implementations could use a simpler handshake over a

dedicated port without reinventing the entire protocol. This last

point is important because the traffic patterns of interactive
messaging do not closely match standard HTTP traffic and can induce
unusual loads on some components.

WebSocket协议被设计用来替代当前的全双工技术，它们使用HTTP做为传输层，可以从已有的基础设施中获利（代理、过滤器、授权）。这些技术是效率和可靠性间的权衡，因为HTTP最初并不是设计用来进行全双工通讯的。现在存在一些全双工HTTP技术，WebSocket协议尝试基于已存在的HTTP基础设施的上下文来达到共同的目标。因此，它被设计工作在HTTP的80端口和443端口上，并支持HTTP代理和中介，即使这意味着包含当前环境的一些复杂的特性。但是，设计并没有限制WebSocket到HTTP上，将来的实现可能在专用的端口上使用更简单的握手，而不用重构这个协议。最后这一点至关重要，因为交互式消息的传输模式与HTTP的传输模式并不十分吻合，这会在有些组件上引入不寻常的负担。
1.2. Protocol Overview

_This section is non-normative._

1.2协议概述

本节是非正式的。
The protocol has two parts: a handshake and the data transfer.
The handshake from the client looks as follows:

本协议分为两部分：一个握手和数据传输。

来自客户端的握手如下：
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

The handshake from the server looks as follows:

来自服务端的握手如下：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
The leading line from the client follows the Request-Line format.
The leading line from the server follows the Status-Line format. The
Request-Line and Status-Line productions are defined in [RFC2616].
An unordered set of header fields comes after the leading line in
both cases. The meaning of these header fields is specified in
Section 4 of this document. Additional header fields may also be
present, such as cookies [RFC6265]. The format and parsing of
headers is as defined in [RFC2616].

客户端的开头行遵循请求行格式；服务端的开头行遵循状态行格式。请求行和状态行的制作在RFC2616中定义。在两种情况下开头行后面都跟着一个无序的头字段列表。这些头字段的含义在第4节中会介绍。额外的头信息也会存在，例如Cookies。头信息的格式和解析在RFC2616中定义。
Once the client and server have both sent their handshakes, and if
the handshake was successful, then the data transfer part starts.
This is a two-way communication channel where each side can,
independently from the other, send data at will.
After a successful handshake, clients and servers transfer data back
and forth in conceptual units referred to in this specification as
"messages". On the wire, a message is composed of one or more

frames. The WebSocket message does not necessarily correspond to a
particular network layer framing, as a fragmented message may be
coalesced or split by an intermediary.

一旦客户端和服务端都发送了他们的握手，假如握手成功，则开始进行数据传输。这是一个双向的通道，独立的双方都可以发送数据。握手成功后，客户端和服务端按照概念上的单位前后传输数据，数据单位在该说明书中称之为“消息“。在网络上，一个消息由一个或多个数据帧组成。WebSocket消息不一定必须与一个特定的网络层架构对应，因为一个分片的消息可能被中介组合或拆分。
A frame has an associated type. Each frame belonging to the same
message contains the same type of data. Broadly speaking, there are
types for textual data (which is interpreted as UTF-8 [RFC3629]
text), binary data (whose interpretation is left up to the
application), and control frames (which are not intended to carry
data for the application but instead for protocol-level signaling,
such as to signal that the connection should be closed). This
version of the protocol defines six frame types and leaves ten
reserved for future use.

每一个帧有一个关联类型。每一个帧都属于包含相同类型数据的消息。一般来说，这里有文本数据（一般按照UTF-8解析）、二进制数据（由应用解析）、控制帧（不用来为应用承载数据而是协议层的信号，例如去通知连接应该被关闭）。这个版本的协议定义了6种帧类型，为将来预留了10种。
1.3. Opening Handshake
_This section is non-normative._

1.3 打开握手

该节为非正式的。
The opening handshake is intended to be compatible with HTTP-based
server-side software and intermediaries, so that a single port can be
used by both HTTP clients talking to that server and WebSocket
clients talking to that server. To this end, the WebSocket client’s
handshake is an HTTP Upgrade request:

打开握手打算与基于HTTP的服务端软件和中介兼容，因此一个端口即可以被HTTP客户端用来与服务端会话，也可以被WebSocket客户端用来与服务端会话。结果，WebSocket客户端的握手就是一个HTTP 更新请求：
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

In compliance with [RFC2616], header fields in the handshake may be

sent by the client in any order, so the order in which different
header fields are received is not significant.
The "Request-URI" of the GET method [RFC2616] is used to identify the
endpoint of the WebSocket connection, both to allow multiple domains
to be served from one IP address and to allow multiple WebSocket
endpoints to be served by a single server.
The client includes the hostname in the |Host| header field of its
handshake as per [RFC2616], so that both the client and the server
can verify that they agree on which host is in use.

与RFC2616一致，握手中的头字段可能被客户端以任何顺序发送，因此不同的头字段被接收的顺序不重要。GET方法中的Request-URI用来标记WebSocket连接的终端，即允许一个IP地址提供多个域服务，也允许一个服务提供多个WebSocket终端。

Additional header fields are used to select options in the WebSocket
Protocol. Typical options available in this version are the
subprotocol selector (|Sec-WebSocket-Protocol|), list of extensions
support by the client (|Sec-WebSocket-Extensions|), |Origin| header
field, etc. The |Sec-WebSocket-Protocol| request-header field can be
used to indicate what subprotocols (application-level protocols
layered over the WebSocket Protocol) are acceptable to the client.
The server selects one or none of the acceptable protocols and echoes
that value in its handshake to indicate that it has selected that
protocol.

额外的头字段被用来在WebSocket协议中选择选项。该版本中经典的选项是子协议选择（|Sec-WebSocket-Protocol|）、客户端支持的扩展（|Sec-WebSocket-Extensions|）， |Origin|头字段等等。|Sec-WebSocket-Protocol|头字段可以用来标记客户端支持的协议（WebSocket协议之上的应用协议）。服务端选择一个或不选择同意的协议，然后在握手中展示出来，标记着它选择了那个协议。
Sec-WebSocket-Protocol: chat
The |Origin| header field [RFC6454] is used to protect against
unauthorized cross-origin use of a WebSocket server by scripts using
the WebSocket API in a web browser. The server is informed of the
script origin generating the WebSocket connection request. If the
server does not wish to accept connections from this origin, it can
choose to reject the connection by sending an appropriate HTTP error
code. This header field is sent by browser clients; for non-browser
clients, this header field may be sent if it makes sense in the
context of those clients.

|Origin|头字段用来避免在浏览器中通过脚本使用WebSocket API 未经授权跨域访问WebSocket服务端。服务端被告知生成WebSocket连接请求的脚本的域。假如服务端不打算接收来自该域的请求，它可以通过发送一个HTTP错误码来拒绝该请求。这个头字段是浏览器发送的，在没有浏览器的客户端中，如果这个字段对于这些客户端有意义，它也可以被发送。
Finally, the server has to prove to the client that it received the
client’s WebSocket handshake, so that the server doesn’t accept
connections that are not WebSocket connections. This prevents an
attacker from tricking a WebSocket server by sending it carefully
crafted packets using XMLHttpRequest [XMLHttpRequest] or a form
submission.

最后，服务端必须证明给客户端它已经接收了客户端的WebSocket握手，以便服务端不接收非WebSocket连接。这避免了通过XMLHttpRequest或表单提交精心制作的数据包的方式欺骗WebSocket服务端的攻击。
To prove that the handshake was received, the server has to take two
pieces of information and combine them to form a response. The first
piece of information comes from the |Sec-WebSocket-Key| header field
in the client handshake:
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
For this header field, the server has to take the value (as present
in the header field, e.g., the base64-encoded [RFC4648] version minus
any leading and trailing whitespace) and concatenate this with the
Globally Unique Identifier (GUID, [RFC4122]) "258EAFA5-E914-47DA-
95CA-C5AB0DC85B11" in string form, which is unlikely to be used by
network endpoints that do not understand the WebSocket Protocol. A
SHA-1 hash (160 bits) [FIPS.180-3], base64-encoded (see Section 4 of
[RFC4648]), of this concatenation is then returned in the server’s
handshake.

服务端为了证实已经接收了握手，它需要把两部分的数据合并成一个响应。一部分信息来自客户端握手的Sec-WebSocket-Keyt头字段：Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==。对于这个字段，服务端必须得到这个值（头字段中经过base64编码的值减去前后的空格）并与GUID"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"组合成一个字符串，这个字符串对于不懂WebSocket协议的网络终端来说是不能使用的。这个组合经过SHA-1掩码，base64编码后在服务端的握手中返回。

Concretely, if as in the example above, the |Sec-WebSocket-Key|
header field had the value "dGhlIHNhbXBsZSBub25jZQ==", the server
would concatenate the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
to form the string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-
C5AB0DC85B11". The server would then take the SHA-1 hash of this,
giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6
0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea. This value is
then base64-encoded (see Section 4 of [RFC4648]), to give the value
"s3pPLMBiTxaQ9kYGzzhZRbK+xOo=". This value would then be echoed in
the |Sec-WebSocket-Accept| header field.

实际的例子：假如按照上面的例子所述，|Sec-WebSocket-Key|头字段的值是 "dGhlIHNhbXBsZSBub25jZQ=="，服务端组合"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"形成"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|头字段中回应。

The handshake from the server is much simpler than the client
handshake. The first line is an HTTP Status-Line, with the status
code 101:
HTTP/1.1 101 Switching Protocols
Any status code other than 101 indicates that the WebSocket handshake
has not completed and that the semantics of HTTP still apply. The
headers follow the status code.

来自于服务端的握手比客户端的握手要简单得多。第一行是一个HTTP状态行，状态码是101：HTTP/1.1 101 Switching Protocols。除101之外的任何状态码表明WebSocket握手还没有结束，HTTP的语义仍然有效。头字段紧跟着状态码。
The |Connection| and |Upgrade| header fields complete the HTTP
Upgrade. The |Sec-WebSocket-Accept| header field indicates whether
the server is willing to accept the connection. If present, this
header field must include a hash of the client’s nonce sent in
|Sec-WebSocket-Key| along with a predefined GUID. Any other value
must not be interpreted as an acceptance of the connection by the
server.
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
These fields are checked by the WebSocket client for scripted pages.
If the |Sec-WebSocket-Accept| value does not match the expected
value, if the header field is missing, or if the HTTP status code is
not 101, the connection will not be established, and WebSocket frames
will not be sent.

 |Connection|和 |Upgrade| 头字段结束HTTP更新。 |Sec-WebSocket-Accept|表明服务端是否打算接受连接。假如存在，这个头字段必须包含客户端发送的|Sec-WebSocket-Key| 头字段的值同预先定义好的GUID的组合的哈希值。任何其它的值都不能被解析为服务端对该连接的接受。

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

这个值被WebSocket客户端的脚本页面进行检查。假如 |Sec-WebSocket-Accept|值与期望的不匹配，假如头字段丢失或HTTP状态码不是101，连接将不能创建，WebSocket帧将不会发送。
Option fields can also be included. In this version of the protocol,
the main option field is |Sec-WebSocket-Protocol|, which indicates
the subprotocol that the server has selected. WebSocket clients
verify that the server included one of the values that was specified
in the WebSocket client’s handshake. A server that speaks multiple
subprotocols has to make sure it selects one based on the client’s
handshake and specifies it in its handshake.

Sec-WebSocket-Protocol: chat
The server can also set cookie-related option fields to _set_
cookies, as described in [RFC6265].

也可以包含可选的字段。在协议的这个版本中，最主要的可选字段是 |Sec-WebSocket-Protocol|，这个标记了服务端选择的子协议。WebSocket客户端需证实服务端选择了WebSocket客户端握手中指定的协议的一种。一个支持多种协议的服务端必须保证从客户端握手中选择一个并且在它的握手中说明。
1.4. Closing Handshake
_This section is non-normative._

1.4 关闭握手

本节是非正式的。
The closing handshake is far simpler than the opening handshake.
Either peer can send a control frame with data containing a specified
control sequence to begin the closing handshake (detailed in
Section 5.5.1). Upon receiving such a frame, the other peer sends a
Close frame in response, if it hasn’t already sent one. Upon
receiving _that_ control frame, the first peer then closes the
connection, safe in the knowledge that no further data is
forthcoming.

关闭握手比打开握手要简单得多。任何一方都可以发送一个包含特定控制序列数据的控制帧去开启关闭握手。一旦接收到这样的帧，如果另一方还没有发送过关闭帧，它需要发送一个关闭帧作为响应。一旦接收到关闭帧，第一方关闭连接，从而保证没有数据过来。
After sending a control frame indicating the connection should be
closed, a peer does not send any further data; after receiving a
control frame indicating the connection should be closed, a peer
discards any further data received.

在发送了一个标记连接应该关闭的控制帧后，一端不会发送进一步的数据；在接收到一个标记连接应该被关闭的控制帧后，一端丢弃所有后续接收到的数据。
It is safe for both peers to initiate this handshake simultaneously.
The closing handshake is intended to complement the TCP closing
handshake (FIN/ACK), on the basis that the TCP closing handshake is
not always reliable end-to-end, especially in the presence of
intercepting proxies and other intermediaries.

双方同时发起关闭握手是安全的。关闭握手的本意是补充TCP关闭握手，源于TCP的端对端的关闭握手不一定是可靠的，尤其是在代理或其它中介拦截的情况下。
By sending a Close frame and waiting for a Close frame in response,
certain cases are avoided where data may be unnecessarily lost. For
instance, on some platforms, if a socket is closed with data in the
receive queue, a RST packet is sent, which will then cause recv() to
fail for the party that received the RST, even if there was data
waiting to be read.

通过发送一个关闭帧和在响应中等待关闭帧，数据不必要丢失的一些场景得到避免。例如，在一些平台上，如果接受序列中的一个带数据的Socket关闭，一个RST包会被发送，这将导致接收到RST的端recv() 方法失败，尽管这里有数据等待去读。
1.5. Design Philosophy
_This section is non-normative._

1.5 设计原理

本节是非正式的。
The WebSocket Protocol is designed on the principle that there should
be minimal framing (the only framing that exists is to make the
protocol frame-based instead of stream-based and to support a
distinction between Unicode text and binary frames). It is expected
that metadata would be layered on top of WebSocket by the application

layer, in the same way that metadata is layered on top of TCP by the
application layer (e.g., HTTP).

WebSocket协议的设计原则是利用最少数据的帧（仅存的帧的目的是使协议基于帧而不是基于流，并支持Unicode文本和二进制帧之间的区别）。建议应用层把数据装载到WebSocket之上，方式同应用层把数据放在TCP之上时一样的。
Conceptually, WebSocket is really just a layer on top of TCP that
does the following:
o adds a web origin-based security model for browsers
o adds an addressing and protocol naming mechanism to support
multiple services on one port and multiple host names on one IP
address
o layers a framing mechanism on top of TCP to get back to the IP
packet mechanism that TCP is built on, but without length limits
o includes an additional closing handshake in-band that is designed
to work in the presence of proxies and other intermediaries.

理论上讲，WebSocket实际也是TCP之上的一层，它执行以下步骤：

o 为浏览器增加一个基于域的网络安全模型。
o 增加了一个寻址和协议命名机制去支持在一个端口上支持多个服务以及在一个IP地址上支持多个主机名。
o 在TCP之上构建了一个框架，回归到TCP创建的IP包机制上，但是取消了长度限制。
o 定义了一个额外的关闭握手，设计用在代理或其它中介存在时。

Other than that, WebSocket adds nothing. Basically it is intended to
be as close to just exposing raw TCP to script as possible given the
constraints of the Web. It’s also designed in such a way that its
servers can share a port with HTTP servers, by having its handshake
be a valid HTTP Upgrade request. One could conceptually use other
protocols to establish client-server messaging, but the intent of
WebSockets is to provide a relatively simple protocol that can
coexist with HTTP and deployed HTTP infrastructure (such as proxies)
and that is as close to TCP as is safe for use with such
infrastructure given security considerations, with targeted additions
to simplify usage and keep simple things simple (such as the addition
of message semantics).
The protocol is intended to be extensible; future versions will
likely introduce additional concepts such as multiplexing.

除此之外，WebSocket没有增加任何内容。考虑到网络的限制，从根本上说它意在尽可能地把原始的TCP暴露给脚本。它还被设计成这种方式：通过把它的握手设计成一个标准的HTTP更新请求，它的服务可以与HTTP服务共享端口。从理论上讲，WebSocket可以使用其它协议进行客户端-服务端的消息传输，但是WebSocket协议的意图是创建一个相对简单的协议，这个协议可以与HTTP和部署好的HTTP基础设施共存，而且它尽可能的贴近TCP以及尽可能的在给过安全建议的基础设施上安全使用，通过有意图的补充使使用过程简化，简单的事情保持简单。

协议被设计成可扩展的，将来的版本可能会引入额外的概念例如多路技术。
1.6. Security Model
_This section is non-normative._

1.6 安全模型

该节是非正式的。
The WebSocket Protocol uses the origin model used by web browsers to
restrict which web pages can contact a WebSocket server when the
WebSocket Protocol is used from a web page. Naturally, when the
WebSocket Protocol is used by a dedicated client directly (i.e., not
from a web page through a web browser), the origin model is not
useful, as the client can provide any arbitrary origin string.
This protocol is intended to fail to establish a connection with
servers of pre-existing protocols like SMTP [RFC5321] and HTTP, while
allowing HTTP servers to opt-in to supporting this protocol if

desired. This is achieved by having a strict and elaborate handshake
and by limiting the data that can be inserted into the connection
before the handshake is finished (thus limiting how much the server
can be influenced).

当网页中使用WebSocket协议的时候，WebSocket协议通过域模型（浏览器使用过的）去限制哪些网页可以与WebSocket服务接触。一般当WebSocket协议被客户端直接使用时（没有通过浏览器建立网页），域模型没有用，客户端可以提供任何域字符串。这个协议与基于以前存在的协议（SMTP、HTTP）的服务无法建立连接，当允许HTTP服务选择性的支持这个协议时。这个是通过一个严格的精心制作的握手以及在握手结束前限制可发送到连接的数据而达成的。
It is similarly intended to fail to establish a connection when data
from other protocols, especially HTTP, is sent to a WebSocket server,
for example, as might happen if an HTML "form" were submitted to a
WebSocket server. This is primarily achieved by requiring that the
server prove that it read the handshake, which it can only do if the
handshake contains the appropriate parts, which can only be sent by a
WebSocket client. In particular, at the time of writing of this
specification, fields starting with |Sec-| cannot be set by an
attacker from a web browser using only HTML and JavaScript APIs such
as XMLHttpRequest [XMLHttpRequest].

当其它协议的数据（例如HTTP）发送到WebSocket服务端的时候，连接会建立失败，比如一个HTML的表单被提交到一个WebSocket服务端。这个主要是通过要求服务端证实它能读握手信息（它只能读包含特定部分的握手，这些只能由WebSocket客户端发送过来）实现的。特别的是，在编写这个说明书的时候，以 |Sec-| 开头的字段不能被攻击者（来自于浏览器，仅使用HTML和javaScript api，例如XMLHttpRequest）设置值。
1.7. Relationship to TCP and HTTP
_This section is non-normative._

1.7 与TCP和HTTP的关系

本节是非正式的。
The WebSocket Protocol is an independent TCP-based protocol. Its
only relationship to HTTP is that its handshake is interpreted by
HTTP servers as an Upgrade request.
By default, the WebSocket Protocol uses port 80 for regular WebSocket
connections and port 443 for WebSocket connections tunneled over
Transport Layer Security (TLS) [RFC2818].

WebSocket协议是一个独立的基于TCP的协议。它与HTTP的唯一的关系是它的握手可以被HTTP服务端当作更新请求解析。

默认情况下，WebSocket协议使用80端口进行常规连接，通过443端口进行TLS连接。
1.8. Establishing a Connection
_This section is non-normative._

1.8 建立一个连接

给节是非正式的。
When a connection is to be made to a port that is shared by an HTTP
server (a situation that is quite likely to occur with traffic to
ports 80 and 443), the connection will appear to the HTTP server to
be a regular GET request with an Upgrade offer. In relatively simple
setups with just one IP address and a single server for all traffic
to a single hostname, this might allow a practical way for systems
based on the WebSocket Protocol to be deployed. In more elaborate
setups (e.g., with load balancers and multiple servers), a dedicated
set of hosts for WebSocket connections separate from the HTTP servers
is probably easier to manage. At the time of writing of this
specification, it should be noted that connections on ports 80 and
443 have significantly different success rates, with connections on
port 443 being significantly more likely to succeed, though this may
change with time.

当连接建立在HTTP服务共享的端口上（这种情况在与80和443端口传输的时候很容易发生），对于HTTP服务器来说连接看起来像是一个通常的带更新要求的GET请求。在相对简单的部署：仅有一个IP地址、一个服务传输到一个主机名，这可能会允许基于WebSocket协议的系统采用一个切实可行的方式部署。在更复杂的部署中，从HTTP服务中为WebSocket连接区分出一系列主机可能更容易管理。在写本书的时候，需要注意到端口80和443的连接拥有不同的成功率，基于443端口的连接成功率更高，尽管会随着时间变更。

1.9. Subprotocols Using the WebSocket Protocol
_This section is non-normative._

1.9 使用WebSocket协议的子协议

该节是非正式的。
The client can request that the server use a specific subprotocol by
including the |Sec-WebSocket-Protocol| field in its handshake. If it
is specified, the server needs to include the same field and one of
the selected subprotocol values in its response for the connection to
be established.

客户端可以要求服务端使用握手中|Sec-WebSocket-Protocol| 字段包含的子协议。假如指定了，为了建立连接，服务端在响应中也需要引入同样的字段和选中的子协议值的一个。
These subprotocol names should be registered as per Section 11.5. To
avoid potential collisions, it is recommended to use names that
contain the ASCII version of the domain name of the subprotocol’s
originator. For example, if Example Corporation were to create a
Chat subprotocol to be implemented by many servers around the Web,
they could name it "chat.example.com". If the Example Organization
called their competing subprotocol "chat.example.org", then the two
subprotocols could be implemented by servers simultaneously, with the
server dynamically selecting which subprotocol to use based on the
value sent by the client.

这些协议的名称需要按照11.5节定义的进行注册。为了避免潜在的冲突，强烈推荐使用协议的发起人的域名称的ASCII版本。举例，假如一个Example公司计划创建一个网络上很多服务器都会使用的Chat子协议，他们可以把它命名为"chat.example.com"。假如Example公司把它的竞争子协议命名为“chat.example.org”，这时两个协议可以被服务器同时使用，服务器会根据客户端发送的值动态选择要使用的协议。
Subprotocols can be versioned in backward-incompatible ways by
changing the subprotocol name, e.g., going from
"bookings.example.net" to "v2.bookings.example.net". These
subprotocols would be considered completely separate by WebSocket
clients. Backward-compatible versioning can be implemented by
reusing the same subprotocol string but carefully designing the
actual subprotocol to support this kind of extensibility.

子协议可以通过修改协议名称的方式拥有向后不兼容的版本，例如，从"bookings.example.net" 到 "v2.bookings.example.net"。这些协议会被WebSocket客户端完全分开处理。向后兼容的版本实现方式是使用同样的协议字符串，对实际的协议进行仔细设计使其可以支持这种扩展。