概述
本文為 WebSocket 協議的第十一章，本文翻譯的主要內容為 WebSocket 的 IANA 相關注意事項。
有興趣瞭解該文件之前幾章內容的同學可以見：
- 【譯】WebSocket 協議——摘要（ Abstract ）
- 【譯】WebSocket 協議第一章——介紹（ Introduction ）
- 【譯】WebSocket 協議第二章——一致性要求（ Conformance Requirements ）
- 【譯】WebSocket 協議第三章——WebSocket網址（ WebSocket URIs ）
- 【譯】WebSocket 協議第四章——連線握手（ Opening Handshake ）
- 【譯】WebSocket 協議第五章——資料幀（Data Framing）
- 【譯】WebSocket 協議第六章——傳送與接收訊息（Sending and Receiving Data）
- 【譯】 WebSocket 協議第七章——關閉連線（Closing the Connection）
- 【譯】 WebSocket 協議第八章——錯誤處理（Error Handling）
- 【譯】 WebSocket 協議第九章——擴充套件（Extension）
- 【譯】 WebSocket 協議第十章——安全性考慮（Security Considerations）
IANA 注意事項（協議正文）
11.1 註冊新 URI 協議
11.1.1 註冊 “ws” 協議
ws URI 定義了 WebSocket 伺服器和資源名稱。
URI 協議名稱
ws
狀態
永久
URI 協議語法
使用 ABNF （RFC5234）語法和來自 URI 規範 RFC3986 的 ABNF 終端：
"ws:" "//" authority path-abempty [ "?" query ]
path-abempty 和 query RFC3986 部分組成了傳送給服務端的資源名稱，來標記需要的服務型別。其他的部分在 RFC3986 中定義了含義。
URI 協議含義
這個方案的唯一操作就是使用 WebSocket 協議開啟一個連線。
編碼注意事項
按照上面定義的語法排除的主機部分中的字元必須按照 RFC3987 中的規定從 Unicode 轉換為 ASCII 或其替換字元。為了實現基於方案的規範化，國際化網域名稱（IDN）主機元件的形式與 punycode 碼之間的相互轉化認為是等價的（見 RFC3987 第 5.3.3 節）。
除了由上面語法排除的字元外，其他元件的字元在第一次轉換為 UTF-8 字元時，必須從 Unicode 碼轉化到 ASCII 碼，然後使用百分比編碼格式替換對應的定義在 URI RFC3896 字元和國際化資源識別符號（IRI） RFC3987 規範。
應用/協議使用這個 URI 協議規範
WebSocket Protocol
互操作性注意事項
使用 WebSocket 時需要使用 1.1 或者更高版本的 HTTP 協議。
安全性注意事項
見”安全性注意事項”一節。
聯絡
HYBI WG <hybi@ietf.org\\\>
作者/更改控制者
IETF <iesg@ietf.org\\\>
關聯
11.1.2 註冊 “wss”協議
一個 wss 的 URI 定義了一個 WebSocket 伺服器和資源名稱，表明通過這個連結的傳輸需要通過 TLS（包含標準的 TLS 能力例如資料保密性和完整性以及終端認證）來進行保護。
URI 協議名稱
wss
狀態
永久
URI 協議語法
使用 ABNF （RFC5234）語法和來自 URI 規範 RFC3986 的 ABNF 終端：
"wss:" "//" authority path-abempty [ "?" query ]
path-abempty 和 query RFC3986 部分組成了傳送給服務端的資源名稱，來標記需要的服務型別。其他的部分在 RFC3986 中定義了含義。
URI 協議含義
這個方案的唯一操作就是使用 WebSocket 協議開啟一個連線，通過 TLS 加密。
編碼注意事項
按照上面定義的語法排除的主機部分中的字元必須按照 RFC3987 中的規定從 Unicode 轉換為 ASCII 或其替換字元。為了實現基於方案的規範化，國際化網域名稱（IDN）主機元件的形式與 punycode 碼之間的相互轉化認為是等價的（見 RFC3987 第 5.3.3 節）。
除了由上面語法排除的字元外，其他元件的字元在第一次轉換為 UTF-8 字元時，必須從 Unicode 碼轉化到 ASCII 碼，然後使用百分比編碼格式替換對應的定義在 URI RFC3896 字元和國際化資源識別符號（IRI） RFC3987 規範。
應用/協議使用這個 URI 協議規範
WebSocket Protocol
互操作性注意事項
使用 WebSocket 時需要使用 1.1 或者更高版本的 HTTP 協議。
安全性注意事項
見”安全性注意事項”一節。
聯絡
HYBI WG <hybi@ietf.org\\\>
作者/更改控制者
IETF <iesg@ietf.org\\\>
關聯
11.2 註冊“WebSocket”協議升級關鍵值
這一節描述一個在 HTTP 升級憑證註冊的關鍵值，在 RFC2817 定義。
憑證名稱
WebSocket
作者/更改控制者
IETF <iesg@ietf.org\\\>
關聯
11.3 註冊新的 HTTP 頭欄位
Sec-WebSocket-Key
這一節描述一個註冊在永久訊息頭欄位名稱中的頭欄位，在 RFC3864 定義。
頭欄位名稱
Sec-WebSocket-Key
應用協議
http
狀態
標準
作者/更改控制者
IETF
說明文件
關聯資訊
這個頭欄位只用於 WebSocket 開始握手。
Sec-WebSocket-Key 頭欄位是用在 WebSocket 開始握手階段。它是通過客戶端傳送給服務端，這部分資訊用於服務端證明收到一個有效的 WebSocket 握手操作的認證。這可以幫助確認服務端不會接收可能被用來向 WebSocket 服務任意傳送資料的非 WebSocket 客戶端的連線（例如 HTTP 客戶端）。
Sec-WebSocket-Key 頭欄位禁止在一個 HTTP 請求中出現多次。
11.3.2 Sec-WebSocket-Extensions
這一節描述一個註冊在永久訊息頭欄位名稱中的頭欄位，在 RFC3864 定義。
頭欄位名稱
Sec-WebSocket-Extensions
應用協議
http
狀態
標準
作者/更改控制者
IETF
說明文件
關聯資訊
這個頭欄位只用於 WebSocket 開始握手。
Sec-WebSocket-Extensions 頭欄位是用於 WebSocket 開始握手階段。它最開始是通過客戶端傳送給服務端，然後通過服務端傳送給客戶端，來對一個在連線中的協議級的擴充套件進行協商。
Sec-WebSocket-Extensions 頭欄位可能會在一個 HTTP 請求中出現多次（這個邏輯是等價於一個單獨的 Sec-WebSocket-Extensions 頭欄位包含所有值）。然而，Sec-WebSocket-Extensions 頭欄位在 HTTP 響應中不能出現超過1次。
11.3.3 Sec-WebSocket-Accept
這一節描述一個註冊在永久訊息頭欄位名稱中的頭欄位，在 RFC3864 定義。
頭欄位名稱
Sec-WebSocket-Accept
應用協議
http
狀態
標準
作者/更改控制者
IETF
說明文件
關聯資訊
這個頭欄位只用於 WebSocket 開始握手。
Sec-WebSocket-Accpet 頭欄位是用於 WebSocket 開始握手階段。它是通過服務端傳送給客戶端，用來確認服務端會初始化一個 WebSocket 連線。
Sec-WebSocket-Accpet 頭在一個 HTTP 響應中不允許出現超過1次。
11.3.4 Sec-WebSocket-Protocol
這一節描述一個註冊在永久訊息頭欄位名稱中的頭欄位，在 RFC3864 定義。
頭欄位名稱
Sec-WebSocket-Protocol
應用協議
http
狀態
標準
作者/更改控制者
IETF
說明文件
關聯資訊
這個頭欄位只用於 WebSocket 開始握手。
Sec-WebSocket-Protocol 頭欄位是用於 WebSocket 開始握手階段。它是從客戶端傳送給服務端，然後從服務端返回給服務端來確認連線的子協議。這個機制能夠讓雙方選擇一個子協議，同時向服務端確認可以支援這個子協議。
Sec-WebSocket-Protocol 頭欄位可以在一個 HTTP 請求中出現多次（這個邏輯是等價於一個單獨的 Sec-WebSocket-Protocol 頭欄位包含所有值）。然而， Sec-WebSocket-Protocol 頭欄位在 HTTP 響應中不能出現超過1次。
11.3.5 Sec-WebSocket-Version
這一節描述一個註冊在永久訊息頭欄位名稱中的頭欄位，在 RFC3864 定義。
頭欄位名稱
Sec-WebSocket-Version
應用協議
http
狀態
標準
作者/更改控制者
IETF
說明文件
關聯資訊
這個頭欄位只用於 WebSocket 開始握手。
Sec-WebSocket-Version 頭欄位是用於 WebSocket 開始握手階段。它是從客戶端傳送給服務端來表示這個連線使用的協議版本。它能夠讓服務端正確的進行開始握手和接下來的資料傳送，以及在服務端不能夠在一個安全方式下正確解析資料時關閉連線。Sec-WebSocket-Version 頭欄位在服務端理解的版本不匹配從客戶端收到的版本導致的 WebSocket 握手失敗時，也從服務端傳送給客戶端。在這種情況下，這個頭欄位包含服務端支援的協議版本。
注意這裡不期望更高的版本號需要向前相容低版本號。
Sec-WebSocket-Version 頭欄位可以在一個 HTTP 響應中出現多次（這個邏輯等價於一個單獨的Sec-WebSocket-Version包含所有的值）。然而，Sec-WebSocket-Version 頭欄位不能在 HTTP 請求中出現超過1次。
11.4 WebSocket 副檔名登錄檔
這個規範根據RFC5526中規定的原則為 WebSocket 協議建立了一個新的 IANA 登錄檔，用於 WebSocket 副檔名稱。
作為此登錄檔的一部分，IANA 包含了一下資訊：
擴充套件定義
這個擴充套件的定義，將在 Sec-WebSocket-Extensions 頭欄位中使用，在此規範的第 11.3.2 節註冊。這個值必須滿足在此規範第 9.1 節中定義的擴充套件憑證要求。
擴充套件通用名
副檔名稱，一般稱為副檔名。
擴充套件定義
對定義與 WebSocket 協議一起使用的擴充套件的文件的引用。
已知不相容擴充套件
已知的不相容的擴充套件定義列表。
WebSocket 副檔名是受到“先到先得” IANA 註冊政策 RFC5226 限制的。
這個登錄檔裡沒有初始值。
11.5 WebSocket 子協議名登錄檔
這個規範根據RFC5526中規定的原則為 WebSocket 協議建立了一個新的 IANA 登錄檔，用於 WebSocket 副檔名稱。
作為此登錄檔的一部分，IANA 包含了一下資訊：
子協議定義
子協議的識別符號將在 Sec-WebSocket-Protocol 頭欄位中使用，在此規範的第 11.3.4 節中註冊。這個之必須符合此規範第 4.1 節中的第 10 項要求—換句話說，這個之必須是 RFC2616 中定義的憑證。
子協議通用名
子協議名稱，通常被稱為子協議。
子協議定義
對定義與 WebSocket 協議一起使用的子協議的文件的引用。
WebSocket 子協議名是受到“先到先得” IANA 註冊政策 RFC5226 限制的。
11.6 WebSocket 版本號登錄檔
該規範根據 RFC5226 中規定的原則為 WebSocket 協議建立了一個新的 IANA 登錄檔，用於 WebSocket 版本號。
作為此登錄檔的一部分，IANA 包含了一下資訊：
版本號
版本號是用於在此規範第 4.1 節中制定的 Sec-WebSocket-Version 欄位。這個值必須是一個範圍在 0 到 255（含）之間的非負整數。
參考
RFC 請求新版本號或者帶有版本號的草稿名稱（見下文）。
狀態
臨時或者標準。見下面描述。
版本號被指定為“臨時”或者“標準”。
“標準”的版本號被記錄在 RFC 文件中，被認為是一個重大、穩定的 WebSocket 協議版本，例如定義在這個 RFC 中的版本。“標準”版本號是受到 “IETF 評論” IANA 註冊政策 RFC5526 限制的。
“臨時”版本是記錄在網路草案和用於幫助實現者識別 WebSocket 協議的已部署版本並與之互操作，例如開發後但是釋出前的 RFC 版本。“臨時”版本號是受到 “專家評論” IANA 註冊政策 RFC5526 、 最初的指定專家如HYBI 工作組主席（或者，如果工作組關閉，那麼是 IETF 應用領域的領域主任）限制的。
IANA 已經向登錄檔中新增了如下的初始值。
| 版本號 | 引用 | 狀態 |
|---|---|---|
| 0 | draft-ietf-hybi-thewebsocketprotocol-00 | 臨時 |
| 1 | draft-ietf-hybi-thewebsocketprotocol-01 | 臨時 |
| 2 | draft-ietf-hybi-thewebsocketprotocol-02 | 臨時 |
| 3 | draft-ietf-hybi-thewebsocketprotocol-03 | 臨時 |
| 4 | draft-ietf-hybi-thewebsocketprotocol-04 | 臨時 |
| 5 | draft-ietf-hybi-thewebsocketprotocol-05 | 臨時 |
| 6 | draft-ietf-hybi-thewebsocketprotocol-06 | 臨時 |
| 7 | draft-ietf-hybi-thewebsocketprotocol-07 | 臨時 |
| 8 | draft-ietf-hybi-thewebsocketprotocol-08 | 臨時 |
| 9 | 保留 | |
| 10 | 保留 | |
| 11 | 保留 | |
| 12 | 保留 | |
| 13 | RFC6455 |
11.7 WebSocket 關閉碼登錄檔
該規範根據 RFC5226 中規定的原則為 WebSocket 協議建立了一個新的 IANA 登錄檔，用於 WebSocket 關閉碼。
作為此登錄檔的一部分，IANA 包含了一下資訊：
狀態碼
狀態碼錶示定義在此文件第 7.4 節中 WebSocket 連線關閉的原因。這個狀態碼是一個在 1000 到 4999（含）之間的整數。
含義
狀態碼含義。每一個狀態碼有一個特定的含義。
聯絡
保留狀態程式碼的實體的聯絡人。
關聯
請求狀態碼的固定文件和含義定義。對於 1000-2999 的狀態碼來說是必須的，推薦使用 3000-3999 範圍的狀態碼。
WebSocket 關閉狀態碼根據它的範圍有不同的註冊要求。使用在這個協議和它的後續的版本或者擴充套件的請求版本號是受到“標準行為”、“規範要求”（這意味著“指定專家”）或者“IESG 評論” IANA登錄檔政策限制的，應該在 1000-2999 範圍內授權。被類庫、框架和應用使用的狀態碼是受限制於“先到先得”IANA 登錄檔政策，應該在 3000-3999 範圍內授權。4000-4999 範圍的狀態碼是私用的。請求應指明它們是否正在通過擴充套件、類庫、框架或者應用使用請求WebSocket協議的狀態程式碼（或者將來的協議的版本）。
IANA已經向登錄檔中新增了如下初始值。
| 狀態碼 | 含義 | 聯絡人 | 關聯 |
|---|---|---|---|
| 1000 | 正常關閉 | hybi@ietf.org | RFC6455 |
| 1001 | 離開 | hybi@ietf.org | RFC6455 |
| 1002 | 協議錯誤 | hybi@ietf.org | RFC6455 |
| 1003 | 不支援的資料型別 | hybi@ietf.org | RFC6455 |
| 1004 | 保留 | hybi@ietf.org | RFC6455 |
| 1005 | 沒有收到狀態碼 | hybi@ietf.org | RFC6455 |
| 1006 | 異常關閉 | hybi@ietf.org | RFC6455 |
| 1007 | 無效的幀資料 | hybi@ietf.org | RFC6455 |
| 1008 | 違反政策 | hybi@ietf.org | RFC6455 |
| 1009 | 訊息太大 | hybi@ietf.org | RFC6455 |
| 1010 | 強制擴充套件 | hybi@ietf.org | RFC6455 |
| 1011 | 內部伺服器錯誤 | hybi@ietf.org | RFC6455 |
| 1015 | TLS握手 | hybi@ietf.org | RFC6455 |
11.8 WebSocket 操作碼登錄檔
該規範根據 RFC5226 中規定的原則為 WebSocket 協議建立了一個新的 IANA 登錄檔，用於 WebSocket 操作碼。
作為此登錄檔的一部分，IANA 包含了一下資訊：
操作碼
操作碼錶示定義在第 5.2 節中的 WebSocket 幀的幀型別。操作碼是一個範圍在 0 到 15（含）的數字。
含義
操作碼的含義。
關聯
請求操作碼的規範。
WebSocket 操作碼是受到“標準行為”IANA 登錄檔政策 RFC5266 限制的。
IANA 已經向登錄檔中註冊了一下初始值。
| 操作碼 | 含義 | 關聯 |
|---|---|---|
| 0 | 連續幀 | RFC6455 |
| 1 | 文字幀 | RFC6455 |
| 2 | 二進位制幀 | RFC6455 |
| 8 | 連線關閉幀 | RFC6455 |
| 9 | 心跳 Ping 幀 | RFC6455 |
| 10 | 心跳 Pong 幀 | RFC6455 |
11.9 WebSocket 幀頭 bit 欄位登錄檔
該規範根據 RFC5226 中規定的原則為 WebSocket 協議建立了一個新的 IANA 登錄檔，用於 WebSocket 幀頭 bit 欄位。這個登錄檔控制分配的 bit 位為第 5.2 節中的 RSV1、RSV2 和 RSV3。
這些 bit 位是保留給將來的版本或者文件中的擴充套件。
WebSocket 幀頭 bit 欄位是受到“標準行為”IANA 登錄檔政策 RFC5266 限制的。