http の長い接続と短い接続の原理の簡単な分析

1. HTTP プロトコルと TCP/IP プロトコルの関係

HTTP の長い接続と短い接続は、本質的には TCP の長い接続と短い接続です。 HTTP はアプリケーション層プロトコルであり、トランスポート層では TCP プロトコル、ネットワーク層では IP プロトコルを使用します。 IP プロトコルは主にネットワークのルーティングとアドレス指定の問題を解決し、TCP プロトコルは主に IP 層の上でデータ パケットを確実に配信する方法を解決します。これにより、ネットワークのもう一方の端は発信者によって送信されたすべてのパケットを受信し、順序が一貫しています。送る順番。 TCP には、信頼性の高い接続指向の特性があります。

2. HTTP プロトコルがステートレスであることを理解する方法

HTTP プロトコルはステートレスです。つまり、プロトコルにはトランザクション処理用のメモリがなく、サーバーはクライアントの状態を知りません。つまり、サーバー上で Web ページを開くことと、以前にこのサーバー上で開いた Web ページとの間には何の関係もありません。 HTTP はステートレス接続指向のプロトコルです。ステートレスであることは、HTTP が TCP 接続を維持できないことを意味するものではなく、HTTP が UDP プロトコルを使用する (接続がない) ことを意味するものでもありません。

3. 長いつながりと短いつながりとは何ですか？

HTTP/1.0では、デフォルトで短い接続が使用されます。つまり、ブラウザとサーバーが HTTP 操作を実行するたびに接続が確立されますが、タスクが完了すると接続は中断されます。クライアント ブラウザによってアクセスされる HTML またはその他の種類の Web ページに、JavaScript ファイル、画像ファイル、CSS ファイルなどの他の Web リソースが含まれている場合、ブラウザはそのような Web リソースに遭遇するたびに HTTP セッションを作成します。

しかし、HTTP/1.1からは、接続特性を維持するためにデフォルトで長い接続が使用されます。長い接続で HTTP プロトコルを使用すると、次のコード行が応答ヘッダーに追加されます:

Connection:keep-alive

長い接続を使用する場合、Web ページが開かれると、クライアントとサーバーが送信に使用されます。 HTTP データの TCP 接続は閉じられず、クライアントがこのサーバー上の Web ページに再度アクセスしても、この確立された接続が引き続き使用されます。キープアライブは接続を永続的に維持するものではなく、さまざまなサーバー ソフトウェア (Apache など) で設定できる保持時間を持ちます。長い接続を実装するには、クライアントとサーバーの両方が長い接続をサポートする必要があります。

HTTPプロトコルのロングコネクションとショートコネクションは、本質的にはTCPプロトコルのロングコネクションとショートコネクションです。

3.1 TCP接続

ネットワーク通信にTCPプロトコルが使用される場合、実際の読み取りおよび書き込み操作の前に、サーバーとクライアントの間で接続を確立する必要があります。読み取りおよび書き込み操作が完了すると、両者は接続を行う必要がなくなります。この接続を解放するには、接続の確立には 3 回のハンドシェイクが必要で、解放には 4 回のハンドシェイクが必要となるため、各接続の確立にはリソースの消費と時間がかかります:

。 古典的な 4 ウェイ ハンドシェイク終了図:

3.2 TCP ショート接続

クライアントがサーバーへの接続リクエストを開始し、サーバーがリクエストを受信し、その後、両者が接続する状況をシミュレートします。接続を確立します。クライアントがサーバーにメッセージを送信し、サーバーがクライアントに応答すると、読み取りと書き込みが完了します。この時点では、どちらの側でもクローズ操作を開始できますが、通常はクライアントが最初にクローズ操作を開始します。なぜですか? 通常、サーバーはクライアントに応答した後すぐに接続を閉じません。もちろん、特殊な状況が発生する可能性は否定できません。上記の説明から、短い接続は通常、クライアント/サーバー間で 1 つの読み取りおよび書き込み操作のみを転送します

短い接続の利点は、管理が比較的簡単であること、既存の接続はすべて有用な接続であること、追加の制御メソッドが必要ないことです

3.3 TCP の長い接続

次に、クライアントがサーバーへの接続を開始し、サーバーがクライアントの接続を受け入れ、両者が接続を確立する状況をシミュレートしてみましょう。クライアントとサーバーが読み取りおよび書き込みを完了した後、それらの間の接続はアクティブに閉じられず、後続の読み取りおよび書き込み操作では引き続きこの接続が使用されます。

まず、TCP/IP の詳細説明で述べた TCP キープアライブ機能について説明します。キープアライブ機能は主にサーバー アプリケーション向けに提供されており、クライアントのホストがクラッシュしたかどうかを知りたいと考えています。クライアントに代わってリソースを使用できます。クライアントが消滅し、サーバー上にセミオープン接続が残され、サーバーがクライアントからのデータを待機している場合、サーバーは、キープアライブ機能によって、このセミオープン接続の検出が試行されます。サーバー側で接続します。

2 時間以内に特定の接続に対してアクションがなかった場合、サーバーはクライアント ホストにプローブ セグメントを送信します。クライアント ホストは次の 4 つの状態のいずれかである必要があります。

クライアント ホストはまだ正常に実行されており、サーバーに到達可能な状態から動作を継続します。クライアントの TCP 応答は正常であり、サーバーも相手が正常であることを認識しており、2 時間後にキープアライブ タイマーをリセットします。

クライアントホストがクラッシュし、シャットダウンまたは再起動中です。どちらの場合も、クライアントの TCP からの応答はありません。サーバーはプローブへの応答を受信せず、75 秒後にタイムアウトします。サーバーは、このようなプローブを 75 秒間隔で合計 10 回送信します。サーバーが応答を受信しない場合、クライアント ホストが閉じられたものとみなし、接続を終了します。

クライアントホストがクラッシュし、再起動されました。サーバーはキープアライブ プローブに対する応答を受信します。これはリセットであり、サーバーは接続を終了します。

クライアントは正常に実行されていますが、サーバーに到達できません。この状況は 2 と似ています。TCP が検出できるのは、プローブ応答が受信されていないことです。

3.4 ロング接続とショート接続の操作手順

ショート接続の操作手順は次のとおりです:

接続の確立-データ送信-接続を閉じる...接続の確立-データ送信-接続を閉じる

ロング接続の操作手順それは、

接続の確立 - データ転送...(接続を維持)...データ転送 - 接続を閉じる

4. 長い接続と短い接続の長所と短所

上記からわかるように、長い接続 TCP の確立と終了操作をより多く節約し、無駄を減らし、時間を節約できます。リソースを頻繁に要求する顧客には、長い接続の方が適しています。ただし、ここで問題が発生します。生存機能の検出期間は長すぎ、TCP 接続の生存を検出するだけです。悪意のある接続に遭遇した場合、キープアライブ機能は十分ではありません。 。接続が長いアプリケーション シナリオでは、通常、クライアントはクライアントとサーバー間の接続を積極的に閉じません。クライアント接続の数が増えると、サーバーに問題が発生します。以降、サーバーは耐えられなくなることがあります。このとき、サーバーは、長期間読み取りまたは書き込みイベントが発生していない接続を閉じるなど、いくつかの戦略を採用する必要があります。これにより、一部の悪意のある攻撃を回避できます。クライアント マシンは細分化されており、各クライアントの長時間接続の最大数が制限されているため、問題のあるクライアントがバックエンド サービスに影響を与えることを完全に防ぐことができます。

サーバーにとって短い接続は管理が比較的簡単で、既存の接続はすべて有用な接続であり、追加の制御方法は必要ありません。ただし、クライアントが頻繁に要求すると、TCP の確立とシャットダウンの操作に時間と帯域幅が無駄になります。

長い接続と短い接続の出現は、クライアントとサーバーが採用する終了戦略にあります。完璧な選択肢はなく、適切な選択肢があるだけです。

5. 長い接続と短い接続をいつ使用するか?

長い接続は主に頻繁な操作やポイントツーポイント通信に使用され、接続数が多すぎることはできません。各 TCP 接続には 3 段階のハンドシェイクが必要であり、各操作が最初に接続されてから操作されると、処理速度が大幅に低下するため、各操作後に切断されず、データ パケットが直接送信されます。最初の処理は TCP 接続を確立する必要はありません。たとえば、データベース接続に長い接続が使用されると、短い接続で頻繁に通信が行われ、ソケット エラーが発生します。また、頻繁にソケットを作成するとリソースが無駄になります。

WEB ウェブサイトのような HTTP サービスは、一般に短いリンクを使用します。これは、長い接続はサーバーに一定量のリソースを消費するためです。また、数千、さらには数億のクライアント接続が頻繁に行われる WEB ウェブサイトと同様に、短いリンクを使用すると、長時間の接続を使用し、同時に数千のユーザーがいる場合、各ユーザーが接続を占有することが考えられます。したがって、同時実行量は多くなりますが、頻繁な操作が必要ない場合、各ユーザーは短い接続を使用する必要があります。