Keep-Alive

2971 ワード
プログラミング サーバ HttpWebRequest
HTTPは、要求<->応答モードの典型的な例であり、クライアントがサーバに要求情報を送信し、サーバがこの情報に応答する。古いHTTPバージョンでは、各要求は、新しいクライアントサーバの接続を作成し、この接続上で要求を送信し、要求を受信する。このようなモードには大きな利点があります。簡単で、理解しやすく、プログラミングしやすいです。また、効率が低いという大きな欠点がありますので、Keep-Aliveは効率の低い問題を解決するために提案されています。
Keep-Alive機能は、クライアントからサーバー側への接続を継続的に有効にし、サーバの後継要求がある場合、Keep-Alive機能は接続の確立または再確立を回避します。市場上のほとんどのWebサーバーは、iPlanet、IIS、Apacheを含め、HTTP Keep-Aliveをサポートしています。静的なコンテンツを提供するウェブサイトにとって、この機能は一般的に有用である。しかし、負担が重いサイトにはもう一つの問題があります。お客様のために開いた接続を保留することは一定の利点がありますが、それは同様に性能に影響を与えています。処理が一時停止されている間、本来釈放できる資源は依然として占有されています。Webサーバとアプリケーションサーバが同じマシンで動作する場合、Keep-Alive機能は特にリソース利用に影響を与えます。この機能はHTTP 1.1のプロビジョニング機能で、HTTP 1.0にKeep-Aliveheaderを加えてHTTPの持続作用機能を提供することができます。
Keep-Alive: timeout=5, max=100
timeout：有効期限が5秒（httpd.com nfに対応するパラメータは、KeepAlive Timeout）で、maxは最大100回の要求で、強制的に接続を切断すると、timeout時間内にまた新しい接続ができ、同時にmaxは自動的に1を減らして、0になるまで、強制的に断絶します。下の四つの図を見て、Dateの値（前後の時間差は全部5秒以内）を見てください。
  • HTTP/1.0はHTTP/1.0バージョンにおいて、Keep-Aliveがどのように動作するかを公式の基準で規定していませんので、実際にはHTTP/1.0プロトコルに添付されています。クライアントブラウザがKeep-LIVEをサポートすると、HTTPリクエストヘッダにフィールドConnection:Keep-Aliveを追加します。また、応答ヘッダに同じフィールドを追加して、Keep-Aliveを使用します。このように、クライアントとサーバとの間のHTTP接続は維持され、切断されない（Keep-Alive所定の時間を超えて、予期せぬ停電などの場合を除く）。クライアントが他の要求を送信する場合は、この確立された接続
    • を使用する。
  • HTTP/1.1はHTTP/1.1バージョンにおいて、公式に規定されているKeep-Aliveの使用基準とHTTP/1.0バージョンでは若干異なりますが、デフォルトではHTTP 1.1にあるすべての接続が維持されています。要求側または応答先でクローズすると指定されていない限り、Connection:Close、これはなぜConnection:Keep-LIVEフィールドが意味がないのですか？また、新しいフィールドKeep-Aliveも追加されました。このフィールドは何をするために詳細に説明されていないので、Not reliable（信頼できない）
    • を無視できます。
    HTTPは無状態プロトコルであり、これは各要求が独立していることを意味し、Keep-Aliveはこの結果を変えられなかった。また、Keep-Aliveもクライアントとサーバー間の接続が活発であることは保証できません。HTTP 1.1バージョンでもそうです。唯一保証できるのは、接続がクローズされた時に通知がもらえます。だから、プログラムをKeep-Aliveの接続特性に依存させてはいけません。そうしないと、思いがけない結果になります。
  • Keep-AliveとPOST
    • HTTP 1.1細則では、一つのPOSTメッセージ体の後ろに文字がないように規定されています。また、ある特定のブラウザについては、この基準（例えば、POSTメッセージ体の後ろにCRLF符を置く）に従わないかもしれないと指摘しています。私が知っている限りでは、ほとんどのブラウザはPOSTメッセージの後に自動的にCRLFの文字と再送信します。どうやってこの問題を解決しますか？上記の説明によりますと、POSTリクエストヘッドでKeep-Aliveの使用を禁止したり、サーバによって自動的にこのCRLFを無視したりすると、ほとんどのサーバーは自動的に無視されますが、テストを受ける前にサーバーがこのようにするかどうかは分かりません。
    Keep-AliveはJavaで実現されます。クライアントでJavaはKeep-Aliveを抽象化しました。プログラマとシェアして出発しました。HttpURLConnection類は自動的にKeep-LIVEを実現しました。もしプログラマがKeep-Aliveを操作しなかったら、Keep-LIVEはクライアント内部のHttpURLConnect類のインスタンスオブジェクトを通じて自動的に実現されます。つまり、javaではkeep-aliveはJavaクラスライブラリによって実現されるが、他のクラスのライブラリでは必ずしも利用できるとは限らない。
    Keep-AliveはJavaで実現します。サーバー側はサーバー側にあります。Javaは依然としてKeep-Aliveを抽象的に出しています。HttpServlet、HttpServletRequest、およびHttpServletResonse類は自動的にKeep-LIVEを実現しました。この場合、いくつかのサードパーティによる操作が可能であり、例えばKeepAlive Servletで言及されているJava WebServerのように、Keep-Aliveが有効かどうかは、2つの要素によって決定され、コンテンツの長さと出力の大きさは、コンテンツの長さが応答の一部である場合には、Keep-Aliveが有効となる。（もちろんクライアントサポートが必要な場合）、コンテンツ長が設定されていない場合、Servletは応答バッファ長を計算してコンテンツ長を決定してみます。Javasoft実装では、4 KBのバッファを使用します。つまり、コンテンツ長が設定されておらず、リターンデータが4 KBを超えている場合、応答長の一部ではなくコンテンツ長が応答長よりも大きいということです。Keep-Aliveは有効にされません。
    Key-Value Pair並べ替え——すべてのタイプに対応しています。
    set&&Mapデータ構造