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 ProtocolsUpgrade: 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客戶端完全分開處理。向後兼容的版本實現方式是使用同樣的協議字符串，對實際的協議進行仔細設計使其可以支持這種擴展。