第三章、WebSocket配置

WebSocket應用程式配置有許多關鍵參數：在容器的URI空間中辨別WebSocket端點的路徑映射，端點支援的子協定，應用程式的擴充需求，此外，在打開握手期間，應用程式可以選擇執行其他配置任務，例如檢查送出請求的用戶端的主機名或處理cookie，本節詳細介紹了容器上支援這些配置任務的要求。

用戶端和服務端點配置都包括應用程式提供的編碼器和解碼器的清單，在WebSocket消息和應用程式定義的消息對象之間轉換的實作和使用這些類。[WSC-3-1]

遵循伺服器特定配置和客戶特定配置選項的定義。

文章目錄

• • 3.1、服務端配置
  • • 3.1.1、URI 映射
    • 3.1.2、子協定協商
    • 3.1.3、擴充修改
    • 3.1.4、來源檢查
    • 3.1.5、握手修改
    • 3.1.6、自定義狀态或處理跨服務端點執行個體
    • 3.1.7、自定義 端點建立
  • 3.2、用戶端配置
  • • 3.2.1、子協定
    • 3.2.2、擴充
    • 3.2.3、用戶端配置修改

3.1、服務端配置

• 為了将程式設計的端點部署到可用于用戶端連接配接的URI空間中，容器需要一個ServerEndpointConfig執行個體。該對象儲存配置資料和實作配置端點所需的預設實作提供的算法。通過提供帶有ServerEndpointConfig的定義ServerEndpoingConfig.Configurator實作，WebSocketAPI允許開放人員覆寫其中的某些配置操作。[WSC-3.1-1]
• 這些操作在下面列出

3.1.1、URI 映射

• 本節介紹伺服器端點的URI映射政策。websocket實作必須将傳入的URI與所有端點路徑的集合進行比較，并确定最佳比對。如果在端點路徑是相對URI的情況下是完全比對。或者傳入URI端點路徑是端點路徑的有效擴充，則打開握手請求中的傳入URI與指定路徑比對 [WSC-3.1.1-1]
• 包含具有相同相對URI的多個端點路徑的應用程式不是有效的應用程式，包含多個等效URI模闆的端點路徑的應用程式不是有效的應用程式。
• 但是從理論上将，打開握手請求中的傳入URI可以比對多個端點路徑，舉個例子，考慮如下場景：
  • 請求URI: “a/b"
  • 端點 A 映射到 “/a/b”
  • 端點 B映射到 “/a/{自定義名}”
• WebSocket實作将嘗試以等同于以下方式的方式将輸入的URI與應用程式中的端點路徑（URI或1級URI模闆）進行比對：[WSC-3.1.1-3]
• 由于端點路徑是相對URI或URI模闆級别1，是以如果路徑的片段不相同，則使用"/" 作為分割符，則路徑不比對，是以容器将從左到右周遊端點路徑中與輸入URI相同數量的段，并将每個段與輸入URI的對應端進行比較，在檢查下一個段之前，實作将在每個段保流哪些完全比對的端點路徑，或如果不存在，則儲存可變段的端點路徑，如果在此過程結束時存在端點路徑，則存在比對項。
• 由于要求不允許使用多個端點路徑和等效的URI模闆，并且每個段都要求完全比對，是以最多隻能有一個路徑，這是最佳比對。
• 例子
  • 假設有端點有路徑為 /a/b, 隻一個請求URI去比對/a/b
  • 假設有端點映射到 /a/{變量}，請求URI如下都可以比對到： /a/b(變量=b) , /a/apple（變量=apple)
    • 如下URI不能比對： /a, /a/b/c (因為空字元串和帶有保留字元"/"的字元串不是有效的URI模闆級别1擴充)
  • 假設有三個端點和URI路徑
    • 端點 A： /a/{變量}/c
    • 端點 B：/a/b/c
    • 端點 C：/a/{變量1}/{變量2}
      • 現在進入一個URI:/a/b/c, 它會比對到端點B， 而不是 A或C，因為B是精确比對
      • 現在進入一個URI：/a/d/c, 它會比對到端點A，相對于C，A是更加精确一些（比對到/c)
      • 現在進入一個URI： /a/x/y 它會比對到端點C， 同時變量1=x，變量2=y
  • 假設現在有兩個端點和URI路徑
    • 端點 A： /{變量1}/d
    • 端點 B： /b/{變量2}
      • 現在進來一個URI: /b/d， 它會比對到B ，變量2=的，而不會比對到A 變量1=b，因為這個比對處理過程是從左到右進行比對的，是以端點B更加精确。
• 除非存在比對項，否則實作不得建立連接配接。[WSC-3.1.1-4]

3.1.2、子協定協商

• 必須在建立時以預設順序為預設伺服器配置提供受支援協定的清單。在子協定協商期間，此配置将檢查用戶端提供的子協定清單，并從用戶端提供的清單中選擇它支援的清單中的第一個子協定，如果不比對，則不選擇。[WSC-3.1.2-1]

3.1.3、擴充修改

• 在打開握手中， 用戶端提供了要使用的擴充清單。預設伺服器配置從這些擴充中選擇它支援的擴充，并且按照用戶端要求的順序放置它們.[WSC-3.1.3-1]

3.1.4、來源檢查

• 預設伺服器配置檢查Origin請求頭提供的主機名，如果無法驗證主機名，則握手失敗[WSC-3.1.4-1]

3.1.5、握手修改

• 預設伺服器配置除了上述内容外，不對打開握手過程進行任何修改:[WSC-3.1.5-1]
• 開發人員可能希望自定義上面列出的配置和握手協定政策，為此，他們可以提供自己的ServerEndpointConfig.Configurator實作
• 例如，開發人員可能希望在握手過程中進行更多幹預，他們可能希望使用Http cookie來跟蹤用戶端，或在握手響應中插入應用程式特定的響應頭，為此，他們可以在ServerEndpointConfig.Configurator上實作ModifyHandshake() 方法，其中他們可以完全通路握手的HandshakeRequest和HandshakeResponse.

3.1.6、自定義狀态或處理跨服務端點執行個體

• 開發人員還可以實作ServerEndpointConfig.Configurator,以保留自定義應用程式狀态或其他類型的特定于應用程式的處理方法，這些方法可以通過EndpointConfig對象從同一邏輯端點的所有Endpoint執行個體通路。

3.1.7、自定義 端點建立

• 開發者可以通過提供覆寫getEndpointInstance()調用的ServerEndpointConfig.Configurator對象來控制中節點執行個體的建立。實作每次必須調用此方法新的康雙人連接配接到邏輯端點。[WSC-3.1.7-1]該方法的平台預設實作是每次調用時都傳回端點類的新執行個體。[WSC-3.1.7-2]
• 通過這種方式，開發人員可以以這樣的方式部署端點：對于與邏輯端點的所有用戶端連接配接，僅執行個體化端點類的一個執行個體。在這種情況下，請開發人員注意，例如，如果兩個不同的用戶端同時發送消息，則此類端點類的單例執行個體必須在程式設計時考慮并發調用線程。

3.2、用戶端配置

• 為了将websocket用戶端端點連接配接到其相應的websocket伺服器端點，該實作需要配置資訊，除了編碼器和解碼器的清單之外，Java websocket API 還需要以下屬性：

3.2.1、子協定

• 預設的用戶端配置使用開發人員提供的子協定清單，以優先順序發送要在其指定的握手過程使用的子協定名稱。[WSC-3.2.1-1]

3.2.2、擴充

• 預設的用戶端配置必須使用開發人員提供的擴充清單，以便按照優先順序發送要在其制定的握手過程中使用的擴充（包含參數）。[WSC-3.2.2-1]

3.2.3、用戶端配置修改

• 一些用戶端可以希望适用用戶端和伺服器之間進行開放式握手互動的方式，開發人員可以提供自己的ClientEndpointConfig.Configuartor實作，這些實作将覆寫基礎實作的預設行為，以便對其進行自定義以适應特定的應用程式的需求。