HTTP、Websocketの関係、およびクライアントとサーバーの相互作用

websocket

Websocketは、http、ftpなどがすべてネットワーク通信プロトコルであるように、単なるネットワーク通信プロトコルです
。HTTPなどの非永続プロトコルと比較すると、Websocketは永続ネットワーク通信プロトコルです。

WebSocketとHTTPの関係

交差点はありますが、すべてではありません。
Websocketは、HTTPプロトコルの一部を借用して、ハンドシェイクを完了します。（HTTPスリーウェイハンドシェイク、ここで1回だけ完了）

Httpプロトコル

最初のハンドシェイク：ホストAはsyn = 1のビットコードを送信し、seq番号= 1234567のデータパケットをサーバーにランダムに生成します。ホストBはSYN = 1を認識し、Aは接続の確立を要求します。

2番目のハンドシェイク：ホストBは、要求を受信した後に接続情報を確認し、ack number =（ホストAのseq + 1）、syn = 1、ack = 1を送信して、seq = 7654321のパケットをランダムに生成する必要があります。

3番目のハンドシェイク：ホストAは、受信後にack番号が正しいかどうか、つまり、seq番号+1が初めて送信されたかどうかを確認し、ビットコードackが1であるかどうかを確認します。正しい場合、ホストAはackを送信します。 number =（ホストBのseq + 1）、ack = 1、ホストBはseq値を確認し、受信後ack = 1とすると、接続は正常に確立されます。

スリーウェイハンドシェイクが完了すると、ホストAとホストBがデータの送信を開始します。

ロングポーリングとAjaxポーリングおよびWebSocketの原理

1. Ajaxのポーリングの原則。

シナリオは次のとおりです。

クライアント：ラララ、新しい情報はありますか（リクエスト）
サーバー：いいえ（応答）
クライアント：ラララ、新しい情報はありますか（リクエスト）
サーバー：いいえ。。（応答）
クライアント：ラララ、新しい情報はありますか（リクエスト）
サーバー：あなたはとても迷惑です、いいえ。。（応答）
クライアント：ラララ、新しいメッセージはありますか（リクエスト）
サーバー：OK、OK、私はあなたのためにそれを持っています。（応答）
クライアント：ラララ、新しいメッセージがありますか（要求）
サーバー：。。。。。番号。。。。番号。。。いいえ（応答）----ループ

コード：

var polling = function(url, type, data){
    var xhr = new XMLHttpRequest(), 
        type = type || "GET",
        data = data || null;

    xhr.onreadystatechange = function(){
        if(xhr.readyState == 4) {
            receive(xhr.responseText);
            xhr.onreadystatechange = null;
        }
    };

    xhr.open(type, url, true);
    //IE的ActiveXObject("Microsoft.XMLHTTP")支持GET方法发送数据，
    //其它浏览器不支持，已测试验证
    xhr.send(type == "GET" ? null : data);
};

var timer = setInterval(function(){
    polling();
}, 1000);

2.ロングポーリングの原則。

実際、ロングポーリングの原則は、ajaxポーリングの原則と似ています。どちらもポーリング方式を使用しますが、ブロッキングモデルを採用しています（常に呼び出し、受信しない場合は電話を切らないでください）。いう、

クライアントが接続を開始した後、メッセージがない場合、クライアントに応答を返すことはありません。メッセージが表示されるまで戻りません。戻った後、クライアントは再び接続を確立し、サイクルが続行されます。

シナリオは次のとおりです。

クライアント：ラララ、新しい情報がある場合は、それが私に返されるのを待つだけです（リクエスト）
サーバー：ええと。。（ニュースがあるまで待ちます）。。あなたに来てください（応答）
クライアント：la la la、新しい情報はありますか、そうでない場合は、それが私に返されるのを待ってください（リクエスト）

クライアント：ラララララ、新しい情報はありますか？

サーバー：月次回線が混雑しています。しばらくしてからもう一度お試しください（503サーバーは利用できません）

クライアント：。。。。さて、ラララ、何か新しい情報はありますか？
サーバー：月次回線が混雑しています。しばらくしてからもう一度お試しください（503サーバーは利用できません）クライアント：

コード：

var longPoll = function(type, url){
    var xhr = new XMLHttpRequest();

    xhr.onreadystatechange = function(){
        // 状态为 4，数据传输完毕，重新连接
        if(xhr.readyState == 4) {
            receive(xhr.responseText);
            xhr.onreadystatechange = null;

            longPoll(type, url);
        }
    };

    xhr.open(type, url, true);
    xhr.send();
}

それからサーバーは傍観者でとても忙しかった：冷蔵庫、もっと冷蔵庫が欲しい！もっと。。もっと。。

上記から、実際には、これら2つの方法は常にHTTP接続を確立し、サーバーが処理するのを待機していることがわかります。これは、HTTPプロトコルのもう1つの特性であるパッシブ性を反映している可能性があります。

パッシブとは何ですか？実際、サーバーはクライアントにアクティブに接続できず、クライアントのみがクライアントに接続できます。

欠陥：

上記から、いずれにせよ、上記の2つは非常に多くのリソースを消費することが容易にわかります。
Ajaxポーリングには、サーバー上での高速な処理速度とリソースが必要です。（速度）
長いポーリングには、高い同時実行性、つまり同時に顧客を受け入れる能力が必要です。（会場の大きさ）
そのため、ajaxポーリングとlongポーリングの両方が発生する可能性があります。

3.WebSocketの原則。

この時、Websocketが登場しました。
彼はHTTPのこれらの問題を解決しました。
まず、パッシブです。サーバーがプロトコルのアップグレードを完了すると（HTTP-> Websocket）、サーバーはクライアントに情報をアクティブにプッシュできます。
したがって、上記のシナリオは次のように変更できます。
クライアント：La la la、Websocketプロトコルを確立したい、必要なサービス：チャット、Websocketプロトコルバージョン：17（HTTPリクエスト）
サーバー：わかりました、確認済み、Websocketプロトコルにアップグレードされました（HTTPプロトコルが切り替えられました）
クライアント：プッシュの問題情報があるときは私。。
サーバー：わかりました、時々私はあなたに話します。
サーバー：balabalabalabala
サーバー：balabalabalabala
サーバー：Ha ha ha ha ha ha ha ha ha ha ah
サービス側：killing me ha ha ha ha ha ha ha

ただし、Websocketに必要なHTTPハンドシェイクは1つだけなので、通信プロセス全体が1つの接続/状態で確立され、HTTPの非状態の性質が回避されます。サーバーは、リクエストを閉じるまで常に情報を認識し、解決されます。オペレーターHTTPプロトコルを繰り返し分析し、ID情報情報を確認する必要があります。

同時に、顧客は積極的に質問し、サーバーに変換（プッシュ）し、情報がある場合は送信します（もちろん、クライアントはイニシアチブが情報を送信するのを待ちます）。情報がない場合は、遅いカスタマーサービス（ハンドラー）を自分の速度で占有することなく、オペレーター（Nginx）に引き渡されました。