Webソケットとソケットの違いは何ですか

違い: ソケットは TCP/IP ネットワークの API です。これは、TCP または UDP の使用を容易にするために抽象化された層です。アプリケーション層と伝送制御層の間の一連のインターフェイスです。 WebSocket は、典型的なアプリケーション層プロトコルです。

このチュートリアルの動作環境: Windows 7 システム、Dell G3 コンピューター。

関連する推奨事項: 「プログラミング ビデオ 」

WebSocket の概要と原理

# WebSocket プロトコルは HTML5 の新しいプロトコルです。ブラウザとサーバー間の全二重通信を実装します。最初のハンドシェイクは、HTTP リクエストを使用して完了する必要があります。

——Baidu Encyclopedia

目的: 投票の代替となるインスタント メッセージング

Web ページ上の QQ やチャット システムなど、Web サイトでの即時メッセージングは​​非常に一般的です。待って。以前の技術的能力によれば、この問題を解決するには通常、ポーリングおよび Comet テクノロジーが使用されます。

HTTP プロトコルは、非永続的な一方向のネットワーク プロトコルです。接続が確立された後、サーバーが対応するデータを返す前に、ブラウザーはサーバーにリクエストを行うことのみが許可されます。インスタント メッセージングが必要な場合、ブラウザは特定の時間間隔 (1 秒など) でポーリングを通じてリクエスト リクエストをサーバーに送信し、最新のデータをブラウザに返します。この方法の最も明らかな欠点は、継続的にリクエストを送信する必要があり、通常 HTTP リクエストのヘッダーが非常に長く、少量のデータを送信するには莫大な料金を支払う必要があり、非常に不経済です。そして多くの帯域幅を占有します。

欠点: 不要なリクエストが多すぎて、トラフィックとサーバー リソースが浪費されます。すべてのリクエストと応答が同じヘッダー情報で一定量のトラフィックを無駄にします。

ただし、WebSocket アピアランスはそれを補うことができます。この欠点のために。 WebSocket では、サーバーとブラウザーは HTTP プロトコルを介してハンドシェイク アクションを実行し、データ送信用に別の TCP 通信チャネルを確立するだけで済みます。

原理

WebSocket は HTTP と同様のアプリケーション層プロトコルですが、TCP をベースに構築された双方向通信プロトコルです。

接続プロセス - ハンドシェイク プロセス

• 1. ブラウザとサーバーは、TCP 接続と 3 ウェイ ハンドシェイクを確立します。これは通信の根幹である伝送制御層であり、失敗するとその後実行されなくなります。
• 2. TCP 接続が成功すると、ブラウザは WebSocket がサポートするバージョン番号などの情報を HTTP プロトコル経由でサーバーに送信します。 (開始前の HTTP ハンドシェイク)
• 3. サーバーはクライアントのハンドシェイク要求を受信した後、HTTP プロトコルを使用してデータをフィードバックします。
• 4. 接続成功メッセージを受信した後、通信は TCP チャネルを通じて送信されます。

WebSocket と HTTP の関係

同じ点

• 1. どちらも TCP に基づいており、信頼性が高い. 転送プロトコル。
• 2. これらはすべてアプリケーション層プロトコルです。

相違点

• 1. WebSocket は、Socket プロトコルをシミュレートし、双方向で情報を送受信できる双方向通信プロトコルです。 HTTP は一方向です。
• 2. WebSocket では、接続を確立するためにハンドシェイクが必要です。

連絡先

WebSocket がハンドシェイクを確立すると、データは HTTP 経由で送信されます。ただし、確立後は実際の送信時には HTTP プロトコルは必要ありません。

WebSocket と Socket の関係

Socket は実際にはプロトコルではなく、TCP または UDP を使用する便宜のために抽象化された層であり、アプリケーションにあります。レイヤとトランスポート制御レイヤ間の一連のインターフェイス。

ソケットは、アプリケーション層と TCP/IP プロトコル ファミリ間の通信のための中間ソフトウェア抽象化層であり、一連のインターフェイスです。デザイン モードでは、Socket は実際にはファサード モードであり、複雑な TCP/IP プロトコル ファミリを Socket インターフェイスの背後に隠します。ユーザーにとっては、一連の単純なインターフェイスがすべてであり、Socket が指定された要件を満たすようにデータを編成できるようになります。

2 つのホストが通信する場合、Socket を介して接続する必要があり、Socket は TCP/IP プロトコルを使用して TCP 接続を確立します。 TCP 接続は基礎となる IP プロトコルにより多く依存しますが、IP プロトコル接続はリンク層などの下位層に依存します。

WebSocket は、典型的なアプリケーション層プロトコルです。

違い

Socketは伝送制御層プロトコルであり、WebSocketはアプリケーション層プロトコルです。

HTML5 と WebSocket の関係

WebSocket API は HTML5 標準の一部ですが、これは、WebSocket を HTML で使用する必要がある、または WebSocket のみを使用できるという意味ではありません。ブラウザベースで使用され、サーバー アプリケーションで使用されます。

実際、多くの言語、フレームワーク、サーバーが次のような WebSocket サポートを提供しています。

• * C ベースの libwebsocket.org
• * Node.js ベースの Socket.io
• * Python ベースの ws4py
• * C ベースの WebSocket
• * Apache の WebSocket サポート: Apache モジュール mod_proxy_wstunnel
• * Nginx の WebSocket サポート: WebSocket プロキシとしての NGINX、NGINX が WebSocket プロトコル、WebSocket プロキシのサポートを発表
• * lighttpd WebSocket をサポートします: mod_websocket

WebSocket のメカニズム

WebSocket の原理と動作メカニズムを簡単に紹介します。

WebSocket は HTML5 の新しいプロトコルです。ブラウザとサーバー間の全二重通信を実現し、サーバーのリソースと帯域幅を節約し、リアルタイム通信を実現します。TCP 上に構築され、HTTP と同様に TCP を通じてデータを送信します。ただし、HTTP との最大の違いは次のとおりです。

#WebSocket は双方向通信プロトコルです。接続を確立すると、WebSocket サーバーとブラウザ/クライアント エージェントは、Socket と同様に、相互にデータをアクティブに送受信できます。
• WebSocket では、TCP のようなクライアントとサーバーがハンドシェイクを通じて接続する必要があり、接続が成功した場合にのみ相互に通信できます。

非 WebSocket モードでの従来の HTTP クライアントとサーバー間の対話を次の図に示します。

図 1. 従来の HTTP 要求応答のクライアントとサーバーの対話図

WebSocket モードを使用したクライアントとサーバー間の対話は次のとおりです。

##図 2. WebSocket リクエスト応答のクライアントとサーバーの対話図

上図の比較からわかるように、各要求と応答でクライアントがサーバーとの接続を確立する必要がある従来の HTTP モードと比較して、WebSocket は TCP の長時間接続通信です。 WebSocket 接続が確立されると、以降のデータはすべてフレームシーケンスの形式で送信されます。クライアントが WebSocket 接続を切断する前、またはサーバーが接続を切断する前に、クライアントとサーバーが接続要求を再開始する必要はありません。クライアントとサーバー間の大規模な同時実行性と重い対話型負荷トラフィックの場合、ネットワーク帯域幅リソースの消費が大幅に節約され、明らかなパフォーマンス上の利点が得られます。さらに、クライアントは同じ永続接続上でリアルタイムでメッセージを送受信します。 . 性的な利点は明らかです。

クライアントとサーバー間の対話型メッセージを通じて、WebSocket 通信と従来の HTTP の違いを見てみましょう:

クライアントでは、新しい WebSocket が新しい WebSocket クライアント オブジェクトをインスタンス化します。 ws://yourdomain:port/path のようなサーバー WebSocket URL に送信します。WebSocket クライアント オブジェクトは、それを自動的に解析して WebSocket リクエストとして識別し、それによってサーバー ポートに接続し、両者の間でハンドシェイク プロセスを実行します。

リスト 1. WebSocket クライアント接続メッセージ

GET /webfin/websocket/ HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: xqBt3ImNzJbYqRINxEFlkg==
Origin: 
http://localhost
:8080
Sec-WebSocket-Version: 13
http://localhost
:8080
Sec-WebSocket-Version: 13

クライアントによって開始された WebSocket 接続メッセージは、従来の HTTP メッセージと似ていることがわかります。 「Upgrade: websocket」パラメータ値は、これが WebSocket タイプであることを示します。リクエスト、「Sec-WebSocket-Key」は、WebSocket クライアントによって送信される Base64 でエンコードされた暗号文であり、サーバーは対応する暗号化された「Sec-WebSocket」を返す必要があります。 -Accept」応答。そうでない場合、クライアントは「WebSocket ハンドシェイク中のエラー」エラーをスローし、接続を閉じます。

メッセージ受信後にサーバーから返されるデータ形式は次のとおりです。

リスト 2.WebSocket サーバー応答メッセージ

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: K7DJLdLooIwIG/MOpvWFB3y3FE8=

「Sec-WebSocket-Accept」の値サーバーがクライアントと同じキーを使用して計算し、クライアントに返します。「HTTP/1.1 101 スイッチング プロトコル」とは、サーバーが WebSocket プロトコルのクライアント接続を受け入れることを意味します。このような要求と応答の処理の後、クライアント サーバーはWebSocket 接続のハンドシェイクが成功し、その後の TCP 通信が実行できるようになります。

開発の観点から見ると、WebSocket API も非常にシンプルです。WebSocket をインスタンス化して接続を作成するだけで済みます。その後、サーバーとクライアントは相互にメッセージを送信し、応答することができます。WebSocket の実装では、以下のケース分析セクションで、WebSocket API とコードの実装の詳細を確認できます。

WebSocket の実装

前述したように、WebSocket の実装はクライアントとサーバーの 2 つの部分に分かれており、クライアント (通常はブラウザ) は WebSocket 接続要求を発行し、サーバーは実装 TCP ハンドシェイクと同様のアクションにより、ブラウザ クライアントと WebSocket サーバーの間に HTTP 長時間接続の高速チャネルが形成されます。その後、両者の間で直接データが送信されるため、接続を開始して応答する必要がなくなります。

以下は、WebSocket サーバー API とクライアント API の簡単な説明です。

WebSocket サーバー API

WebSocket サーバーは、基本的に、JEE JSR356 標準仕様 API に準拠するさまざまな主流のアプリケーション サーバー メーカーによってサポートされています。以下に、一般的な商用およびオープン ソースのアプリケーション サーバーをいくつか示します。サーバーのサポート:

表 1. WebSocket サーバーのサポート

#メーカーアプリケーション サーバー備考IBMWebSphereWebSphere 8.0 以降がサポートされており、MQTT と組み合わせた 7.X より前のバージョンは同様の HTTP ロング接続をサポートしますOracleWebLogicWebLogic 12c サポート、11g および 10g バージョンは、HTTP PublishMicrosoft## を介した同様の HTTP 長い接続をサポートします。 #IIS 7.0 サポートApacheTomcatTomcat 7.0.5 以降のサポート、カスタム API による 7.0.2X および 7.0.3X のサポートJettyJetty 7.0 以降はサポート

以下我们使用 Tomcat7.0.5 版本的服务端示例代码说明 WebSocket 服务端的实现：

JSR356 的 WebSocket 规范使用 javax.websocket.*的 API，可以将一个普通 Java 对象（POJO）使用 @ServerEndpoint 注释作为 WebSocket 服务器的端点，代码示例如下：

清单 3.WebSocket 服务端 API 示例

 @ServerEndpoint("/echo")
 public class EchoEndpoint {

 @OnOpen
 public void onOpen(Session session) throws IOException {
 //以下代码省略...
 }
 
 @OnMessage
 public String onMessage(String message) {
 //以下代码省略...
 }

 @Message(maxMessageSize=6)
 public void receiveMessage(String s) {
 //以下代码省略...
 } 

 @OnError
 public void onError(Throwable t) {
 //以下代码省略...
 }
 
 @OnClose
 public void onClose(Session session, CloseReason reason) {
 //以下代码省略...
 } 
 
 }

代码解释：

上文的简洁代码即建立了一个 WebSocket 的服务端，@ServerEndpoint("/echo") 的 annotation 注释端点表示将 WebSocket 服务端运行在 ws://[Server 端 IP 或域名]:[Server 端口]/websockets/echo 的访问端点，客户端浏览器已经可以对 WebSocket 客户端 API 发起 HTTP 长连接了。

使用 ServerEndpoint 注释的类必须有一个公共的无参数构造函数，@onMessage 注解的 Java 方法用于接收传入的 WebSocket 信息，这个信息可以是文本格式，也可以是二进制格式。

OnOpen 在这个端点一个新的连接建立时被调用。参数提供了连接的另一端的更多细节。Session 表明两个 WebSocket 端点对话连接的另一端，可以理解为类似 HTTPSession 的概念。

OnClose 在连接被终止时调用。参数 closeReason 可封装更多细节，如为什么一个 WebSocket 连接关闭。

更高级的定制如 @Message 注释，MaxMessageSize 属性可以被用来定义消息字节最大限制，在示例程序中，如果超过 6 个字节的信息被接收，就报告错误和连接关闭。

注意：早期不同应用服务器支持的 WebSocket 方式不尽相同，即使同一厂商，不同版本也有细微差别，如 Tomcat 服务器 7.0.5 以上的版本都是标准 JSR356 规范实现，而 7.0.2x/7.0.3X 的版本使用自定义 API （WebSocketServlet 和 StreamInbound， 前者是一个容器，用来初始化 WebSocket 环境；后者是用来具体处理 WebSocket 请求和响应，详见案例分析部分），且 Tomcat7.0.3x 与 7.0.2x 的 createWebSocketInbound 方法的定义不同，增加了一个 HttpServletRequest 参数，使得可以从 request 参数中获取更多 WebSocket 客户端的信息，如下代码所示：

清单 4.Tomcat7.0.3X 版本 WebSocket API

public class EchoServlet extends WebSocketServlet {
@Override
protected StreamInbound createWebSocketInbound(String subProtocol,
HttpServletRequest request) {
 //以下代码省略....
return new MessageInbound() {
 //以下代码省略....
}
protected void onBinaryMessage(ByteBuffer buffer)
throws IOException {
 //以下代码省略...
}
protected void onTextMessage(CharBuffer buffer) throws IOException {
 getWsOutbound().writeTextMessage(buffer);
 //以下代码省略...
}
};
}
}

因此选择 WebSocket 的 Server 端重点需要选择其版本，通常情况下，更新的版本对 WebSocket 的支持是标准 JSR 规范 API，但也要考虑开发易用性及老版本程序移植性等方面的问题，如下文所述的客户案例，就是因为客户要求统一应用服务器版本所以使用的 Tomcat 7.0.3X 版本的 WebSocketServlet 实现，而不是 JSR356 的 @ServerEndpoint 注释端点。

WebSocket 客户端 API

对于 WebSocket 客户端，主流的浏览器（包括 PC 和移动终端）现已都支持标准的 HTML5 的 WebSocket API，这意味着客户端的 WebSocket JavaScirpt 脚本具备良好的一致性和跨平台特性，以下列举了常见的浏览器厂商对 WebSocket 的支持情况：

表 2.WebSocket 客户端支持

	IIS

浏览器	支持情况
Chrome	Chrome version 4+支持
Firefox	Firefox version 5+支持
IE	IE version 10+支持
Safari	IOS 5+支持
Android Brower	Android 4.5+支持

客户端 WebSocket API 基本上已经在各个主流浏览器厂商中实现了统一，因此使用标准 HTML5 定义的 WebSocket 客户端的 JavaScript API 即可，当然也可以使用业界满足 WebSocket 标准规范的开源框架，如 Socket.io。

以下以一段代码示例说明 WebSocket 的客户端实现：

清单 5.WebSocket 客户端 API 示例

var ws = new WebSocket(“ws://echo.websocket.org”); 
 ws.onopen = function(){ws.send(“Test!”); }; 
 ws.onmessage = function(evt){console.log(evt.data);ws.close();}; 
 ws.onclose = function(evt){console.log(“WebSocketClosed!”);}; 
 ws.onerror = function(evt){console.log(“WebSocketError!”);};

第一行代码是在申请一个 WebSocket 对象，参数是需要连接的服务器端的地址，同 HTTP 协议开头一样，WebSocket 协议的 URL 使用 ws://开头，另外安全的 WebSocket 协议使用 wss://开头。

第二行到第五行为 WebSocket 对象注册消息的处理函数，WebSocket 对象一共支持四个消息 onopen, onmessage, onclose 和 onerror，有了这 4 个事件，我们就可以很容易很轻松的驾驭 WebSocket。

当 Browser 和 WebSocketServer 连接成功后，会触发 onopen 消息；如果连接失败，发送、接收数据失败或者处理数据出现错误，browser 会触发 onerror 消息；当 Browser 接收到 WebSocketServer 发送过来的数据时，就会触发 onmessage 消息，参数 evt 中包含 Server 传输过来的数据；当 Browser 接收到 WebSocketServer 端发送的关闭连接请求时，就会触发 onclose 消息。我们可以看出所有的操作都是采用异步回调的方式触发，这样不会阻塞 UI，可以获得更快的响应时间，更好的用户体验。

想要查阅更多相关文章，请访问PHP中文网！！

以上がWebソケットとソケットの違いは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。