11

HTMLファイル仕様のWebSocketsインターフェースについて、ここの関連する質問から聞いた。
それは非常に有望に聞こえます！
それがどのように機能するのかわかりませんが、それでもHTTPプロトコルを使用して機能しますか？それを回避しますか、それともTCPソケットのように機能しますか？

4

4 に答える 4

23

ある意味では、これは HTTP リクエストであり、通常の TCP ソケットでもあります。

Websocket 接続は、TCP を介した通常の HTTP 要求を使用して要求されます。要求されているのは Websocket であり、通常のページではないことを Web サーバーに示すヘッダーがいくつか送信されますが、基本的には単なる HTTP 要求です。

サーバーから応答が送信された後、接続がアップグレードされます。つまり、HTTP に使用されていた TCP 接続がハイジャックされ、より高度な呼び出し (双方向のリアルタイム データ転送) が行われます。

双方向かつ効率的に通信できるようになると (comet に対する大きな利点です)、開発者の視野が大幅に広がります。突然、MMO ゲームやリアルタイム コラボレーションなど、Web テクノロジーだけでは不可能だったことが可能になります。

于 2011-06-25T20:38:14.583 に答える
7

HTTP ではなく、プレーンな TCP ソケットでもありません。これは、通常のソケット接続のオーバーヘッドを低く抑えるように設計されています (AJAX/COMET はオーバーヘッドが非常に高い) が、過去数年にわたって開発されてきたブラウザーのセキュリティ原則の一部を犠牲にすることはありません。

最初の WebSockets ハンドシェイクは、HTTP によく似ています。これにより、既存の HTTP プロキシと Web サーバーが着信 WebSocket 接続をサポートし、正しいことを行う (つまり、実際のハンドラーに転送する) ことが容易になります。ただし、ハンドシェークが成功した後 (送信元情報の交換と検証を含む)、接続は開いたままになり、双方向になります。

データの各パケット (サーバーから送信されたものでもクライアントから送信されたものでも) は '\x00' (ゼロ バイト) で始まり、UTF-8 でエンコードされたデータが続き、'\xff' (すべて 1 バイト) で終わります。

現在のドラフト標準はこちら: https://datatracker.ietf.org/doc/html/draft-hixie-thewebsocketprotocol-76

また、noVNC に含まれている wsproxy も参考になるかもしれません。wsproxy は、TCP ソケット プロキシに対する一般的な WebSocket です。noVNC には wsproxy の C バージョンと Python バージョンの両方が含まれています。

http://github.com/kanaka/noVNC/tree/master/utils/

于 2010-10-14T05:04:33.100 に答える
2

Web ソケット プロトコルは TCP ベースのプロトコルですが、HTTP にダウングレードするように設計されています。サーバーに Web ソケット プロトコルへのアップグレードを要求する HTTP ハンドシェイクもあります。したがって、サーバーがそれをサポートしている場合は、二重化された TCP 接続が使用されます。それ以外の場合は、HTTP とそのための Comet ハックに頼ります。

于 2009-09-20T02:56:39.890 に答える
0

このような状況では、サーバーの役割は次の場合に発生します。

HTML 5 では、WebSocket は携帯電話ではなく、fone (双方向通信) のようなものです。HTTP プロトコルが WebSocket プロトコルにアップグレードされました。(wss:// from ws://)サーバーは二重チャネルを開くことができる必要があるため、二重通信に同意します。このリンクも参照してください: http://www.html5rocks.com/en/tutorials/websockets/basics/

ありがとう。

于 2014-02-10T12:17:52.143 に答える