WebSockets に渡すパスは、ファイルシステム内の実際のパスとは関係ありません。
WebSocket がサーバーに接続するとき、実際のアドレス「localhost」とポート「33」のみを使用します。次に、ハンドシェイクの HTTP リクエストで、「/sockets/server.php」である「パス」の詳細を取得し、それらをハンドシェイクに入れるため、ハンドシェイクの最初の行は次のようになります。
GET /sockets/server.php HTTP/1.1
そのため、アプリケーションがそれをどうするかを決定するために使用されます。実際のファイルに関連したように見せたり、独自の方法で使用したい場合。
WebSockets URI に関する RFC 6455 からの情報を次に示します。
同様に、ポート 33 は使用しないでください。dsp サービスによって使用される可能性があります。ここでポートマップを確認してください。
サーバー側の WebSocket をポート 33 にバインドすると、接続が続行されます。
TCP 層の接続が確立された後、Handshake である HTTP Request を介して続行する必要があります。
その後、成功しました。クライアント側の JavaScript は onopen コールバックをスローします。何か問題が発生した場合、onerror および onclose イベントがスローされます。
接続が正常に確立され、WebSocket がハンドシェークを通過した後、メッセージングを行うことができます。クライアントは生の文字列をメッセージまたはバイナリとして受け取ります (サーバーがバイナリ データを送信する場合は、特定のオペコードを含むメッセージ)。ただし、サーバーはフレーミングとヘッダーを含むデータを受け取ります。ブラウザはデフレーミングを自動的に適用するため、クライアント側ではそれについて心配する必要はありません。ただし、サーバー側では、それを自分で行うか、既存のライブラリを使用して処理する必要があります。
WebSockets プロトコルの公式ドキュメントは次のとおりです: RFC 6455。WebSockets プロトコルのすべての側面を知るために必要なすべての情報が含まれています。
それまでの間、準備ができているソリューションを調べることに興味があるかもしれません。そして、彼らの例を見てみましょう。