web-dev-qa-db-ja.com

WebSocketとプレーンソケット通信の違いは何ですか？

Wikipedia によると、HTTPとWebSocketの間の唯一の関係は、Upgrade HTTP requestの形式の追加のハンドシェイクです。そしてその後、ブラウザーとHTTPサーバーは単純なソケットを介して古いC/Sパラダイムで通信するようになります。

だから私の質問は：

  • WebSocketは単なるソケット通信ですか？
  • 通信はサーバーの80ポートを対象としているため、WebSocketと呼ばれますか？つまり、port 80はwebと同義です。
  • 80ポートはサーバー側にありますが、クライアントではどのポートが使用されますか？
  • それがブラウザとサーバー間の単純なソケット通信のようである場合、なぜWebSocketが最近までブラウザに実装されていないのですか？これは、B/Sパラダイムに対する少しのC/S拡張にすぎません。

追加1（2017年5月23日午前9時46分）

今日、私は@ jfriend00の素晴らしい答えを再訪しました。私の理解を要約しましょう。

  • ソケットは、エンドツーエンド通信channelにすぎません。使用できる通信プロトコルに制限はありません。
  • hTTPと同様に、webSocketは単なる別のスタンドアロン通信プロトコルです。名前の単語socketは最初は混乱しましたが。
  • webSocketはHTTPと同じポート番号を利用するため、HTTPを介して通信できる場合、webSocket通信を確実に実行できます。チャネルが通過したので、チャネルに沿って話すのに最も適切な方法を選択できます。
socketswebwebsocket
27
smwikipedia

webSocketsと通常のソケットは同じものではありません。 webSocketは通常のソケットで動作しますが、通常のソケットの上で独自の接続スキーム、セキュリティスキーム、およびフレーミングプロトコルを実行します。接続を確立するには、両方のエンドポイントがこれらの追加手順に従う必要があります。ここでwebSocketプロトコルを確認できます。 http://tools.ietf.org/html/rfc6455

すぐに最大の違いは、すべてのwebSocket接続がクライアントからサーバーへのHTTPリクエストで始まることです。クライアントは、通常のWeb通信用に開いているまったく同じサーバーとポートにHTTPリクエストを送信します（デフォルトはポート80ですが、Webサーバーが別のポートで実行されている場合、webSocket通信はその別のポートで実行されます）。 。クライアントはいくつかのカスタムヘッダーを設定します。その中で最も重要なのは、クライアントがwebSocketプロトコルに「アップグレード」したいことを示すヘッダーです。さらに、両側でいくつかのセキュリティキーを交換します。サーバーが「アップグレード」に同意すると、クライアントとサーバーの両方が、元のソケットを介して話されるプロトコルをHTTPからwebSocketに切り替え、現在はwebSocketフレーミングプロトコルが使用されます。

さらに、最初のHTTPリクエストには、webSocketリクエストの「サブ宛先」を示すリクエストパスを含めることができます。これにより、すべての種類の異なるwebSocketリクエストをすべて同じサーバーとポートで開始できます。

Sec-WebSocket-Protocolヘッダー付きのオプションのサブプロトコル指定子もあり、サブプロトコル（一般的なものは「チャット」である場合があります）をさらに要求して、両側が特定のメッセージ識別子のセットとそのプロトコルに同意できるようにします使用される可能性のある対応する意味。

WebSocket接続がHTTP接続で始まるという事実は非常に重要です。通常のWeb通信のためにWebサーバーに到達できれば、クライアントとサーバー間のネットワークインフラストラクチャに新しい穴を開けなくても、WebSocketリクエストに到達できるためです。ファイアウォールで、または新しいポートなどを開きます。

ここで、webSocket接続がどのように開始されるかについての優れた要約を見ることができます： https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_servers 。

WebSocketプロトコルは、アイドル状態のwebSocketがまだ接続されているかどうかを両側が知るのに役立つpingおよびpongパケットも定義します。

WebSocketをすべての一般的なブラウザーに取り込むのにしばらく時間がかかった理由は、多くの便利な機能がしばらくかかったのと同じ理由であると考えることができます。最初にやる気のある人々のグループがニーズを特定して同意する必要があり、次にそのグループが問題を解決するためのアプローチを開発する際に主導権を握る必要がありますそのような問題を解決する別の方法であり、それが実際に標準になる可能性があるものになるのに十分な勢いがあるように見える場合、誰かがブラウザでテスト/トライアル実装を行い、サーバーの実装を一致させることを決定します）。その後、勢いがまだあり、標準化の軌道に乗っているように見える場合は、他のブラウザーメーカーがアイデアを取り上げ、実装を開始します。すべてのブラウザメーカーがきちんと機能する実装になったら（通常、さまざまな実装が仕様に穴を見つけたり、初期の開発者が問題を見つけたり、機能の欠落やセキュリティの問題が発生したりするため、標準が何度も改善されます）。次に、少なくとも2つの主要なブラウザーが最新リリースで機能を備え、標準は比較的堅固であると見なされ、消費者はそれらのブラウザーを採用し始め、一部のサイトは新しい機能を使用してユーザーエクスペリエンスを改善し始めます。その時点で、後続のブラウザはそれを実装するようにプレッシャーを感じ始めます。次に、場合によっては数年後、すべての主要なブラウザーに機能があり、それらのブラウザーは、Webサイトがその機能に依存できる十分な全体的なユーザー採用を持っています（ブラウザーが機能をサポートしていない場合に機能する主要な2番目のフォールバック設計がなくても） 。このプロセス全体には何年もかかります。

これは、webSocket接続を開始するための初期HTTPリクエストの例です。

GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

そして、サーバーの応答：

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

そして、データフレームの例：

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+
44
jfriend00

いいえ、WebSocketは単なるソケットではありません。ハンドシェイクを必要とするフレーミングプロトコルを使用し、XORでマスクされたメッセージを32ビットの乱数で交換します。詳細については、 それらを標準化するRFCをお読みください 。

この追加のエンコードレイヤーの理由は、Webブラウザーが任意のソケット接続を作成できるようにすると、さまざまなセキュリティ問題が発生するためです。たとえば、Webサイトの訪問者にSMTPを介して任意のメールサーバーに接続させ、ユーザーが気付かないうちにスパムを送信させることができます。そのため、プロトコルは、サーバー側のアプリケーションがWebブラウザから使用する前に意図的に実装する必要があるように設計されています。

ポートについて：デフォルトでは、WebSocketはポート80に接続しますが、APIは任意のポートを受信できます。ほとんどのTCP/IPベースのプロトコルと同様に、クライアント側のポートはランダム化されています。

なぜそれは以前に実装されなかったのですか？最近まで、WhatWGとW3Cは、新しい標準を導入するために必要な権限を取得するために、すべての主要なブラウザー開発者による統一されたサポートを持っていませんでした。そのため、最近、HTML5というラベルの下に、このような新しいブラウザ機能が殺到しています。

7
Philipp