通常の200ステータスコードの代わりに、WebSocketをサポートするサーバーは、次のような出力を返します。プロトコルスイッチハンドシェイクに成功した後、HTTPアップグレード要求の基になるTCPソケットは、クライアントとサーバーの両方に対して開いたままになり、メッセージの送受信を継続します。WebSocketsの動作方法の完全な紹介は、このドキュメントの範囲外です。6455、HTML5のWebSocketの章、またはWebに関する多くの紹介とチュートリアルのいずれかを参照してください。WebSocketサーバーがWebサーバー(nginxなど)の背後で実行されている場合は、WebSocketアップグレードリクエストをWebSocketサーバーに渡すように構成する必要がある可能性が高いことに注意してください。同様に、アプリケーションがクラウド環境で実行されている場合は、WebSocketサポートに関連するクラウドプロバイダーの指示を確認してください。HTTP対WebSocketWebSocketはHTTP互換であるように設計されており、HTTPリクエストで始まりますが、2つのプロトコルが非常に異なるアーキテクチャとアプリケーションプログラミングモデルにつながることを理解することが重要です。HTTPおよびRESTでは、アプリケーションは多くのURLとしてモデル化されます。アプリケーションと対話するために、クライアントはこれらのURLにアクセスし、リクエスト/レスポンススタイルを使用します。URL、メソッド、およびヘッダーに基づいて要求を適切なハンドラーにルーティングします。対照的に、WebSocketsでは、通常、最初の接続用のURLは1つだけです。その後、すべてのアプリケーションメッセージは同じTCP接続で流れます。これは、まったく異なる非同期のイベント駆動型のメッセージングアーキテクチャを指します。WebSocketは低レベルのトランスポートプロトコルでもあり、HTTPとは異なり、メッセージのコンテンツにセマンティクスを規定していません。クライアントとサーバーがメッセージのセマンティクスに同意しない限り、メッセージをルーティングまたは処理する方法はありません。ヘッダーを介して、より高いレベルのメッセージングプロトコル(たとえば、STOMP)の使用をネゴシエートできます。それがなければ、彼らは彼ら自身のコンベンションを考え出す必要があります。WebSocketsを使用する場合WebSocketsは、Webページを動的かつインタラクティブにすることができます。多くの場合、AjaxとHTTPストリーミングまたはロングポーリングの組み合わせにより、シンプルで効果的なソリューションを提供できます。例:ニュース、メール、ソーシャルフィードは動的に更新する必要がありますが、数分ごとに更新しても問題ありません。コラボレーション、ゲーム、および金融アプリは、リアルタイムにさらに近づける必要があります。遅延だけが決定要因ではありません。メッセージの量が比較的少ない場合(ネットワーク障害の監視など)、HTTPストリーミングまたはポーリングは効果的なソリューションを提供できます。WebSocketの使用に最適なのは、低レイテンシー、高周波数、高ボリュームの組み合わせです。ヘッダーを渡すように構成されていないか、アイドル状態であると思われる長寿命の接続を閉じるため、コントロール外の制限プロキシがWebSocket相互作用を妨げる可能性があることに注意してください。これは、ファイアウォール内の内部アプリケーションにWebSocketを使用することは、一般公開アプリケーションよりも簡単な決定であることを意味します。WebSocketHandlerを作成できます。次の例は、その方法を示しています。WebSocketHandlerAdapterを追加できます。返し、セッションのアプリケーション処理が完了したことを示します。セッションは、受信メッセージ用と送信メッセージ用の2つのストリームを介して処理されます。次の表に、ストリームを処理する2つのメソッドを示します。receive()受信メッセージストリームへのアクセスを提供し、接続が閉じられると完了します。