HTTPの持続的接続
From Wikipedia, the free encyclopedia
| HTTP |
|---|
| 主要項目 |
| リクエストメソッド |
| ヘッダーフィールド |
| ステータスコード |
| 認証方式 |
| セキュリティホール |
HTTPの持続的接続（HTTPのじぞくてきせつぞく、英語: persistent connection）は、単一のTCP接続を維持したまま、複数のHTTPリクエストおよびレスポンスを連続して送受信する接続管理方式である。HTTP/1.1では持続的接続が既定の動作であり、明示的に接続終了が指示されない限り、同一接続を再利用できる。[1]
持続的接続の導入により、各リクエストごとにTCP接続を新設・切断する必要が減るため、接続確立のための往復遅延やTCPのオーバーヘッドを抑えられる。HTTP/1.1仕様では、この方式によりネットワーク混雑の軽減、後続リクエストの遅延削減、ならびに接続上でのHTTPパイプライニングの利用が可能になると説明している。[2]
初期のHTTP実装では、1個の資源を取得するたびにTCP接続を確立し、レスポンス送信後に接続を閉じる動作が一般的であった。HTTP/1.1ではこの方式が改められ、接続は既定で持続的となった。受信者は、もっとも最近受信したメッセージのHTTPバージョンと Connection ヘッダーに基づいて、その接続が持続的かどうかを判断する。[1]
接続を維持したまま複数のリクエストを処理できることは、1つのHTML文書に加えて画像・スタイルシート・スクリプトなど複数の資源を短時間に取得するWeb利用と相性がよい。HTTP/1.1策定時の仕様文書でも、同一サーバに対して短時間に複数の要求が集中する状況を、持続的接続の導入理由として挙げている。[3]
歴史
動作
HTTP/1.1においては、クライアントは Connection: close を送信または受信するまで、同一接続上で追加のリクエストを送信できる。サーバもまた、レスポンス送信後に接続を閉じる意図がある場合には Connection: close を送信する。[1][7]
持続的接続を正しく維持するためには、各メッセージの長さが接続の終了以外の方法で確定できなければならない。RFC 9112は、持続的接続上のすべてのメッセージが自己定義的な長さを持つ必要があるとし、サーバはレスポンス送信後にリクエスト本文をすべて読み切るか接続を閉じなければならず、クライアントも接続を再利用するならレスポンス本文を最後まで読み取らなければならないとしている。[8]
また、HTTP/1.1では、持続的接続上でレスポンスを待たずに複数のリクエストを送るHTTPパイプライニングが関連機能として定義されていた。[2]
利点
持続的接続の主な利点として、HTTP/1.1仕様は次の点を挙げている。[2]
- TCP接続の確立回数が減るため、ネットワーク混雑を抑えられる。
- 後続リクエストでは接続確立のハンドシェイクが不要となるため、遅延が減少する。
- 単一接続を効率よく利用でき、HTTPパイプライニングの基盤となる。