スケーラブルで高性能なWebアプリケーション。 Ch。 1. HTTPプロトコル。 下書き

説明されているトピック：HTTPリクエスト。 HTTP応答 HTTPキープアライブによる最適化。 HTTPパイプラインを使用した最適化。 HTTPキャッシングを使用した最適化：最新のクライアントでのキャッシング、再検証戦略、キャッシングとインタラクティブページの無効化。 圧縮を使用した最適化。 配信されたコンテンツの特定の最適化。 コンテンツを結合します。

コメントを歓迎します。



<div class = "chapter" lang = "ru" xml：lang = "ru">

第1章HTTP

コンテンツ HTTP要求 HTTP応答 HTTPキープアライブ を使用した最適化HTTPパイプライン を使用した最適化HTTPキャッシングを使用した最適化 最新のクライアントでの キャッシング 再検証戦略 キャッシングとインタラクティブページの無効 化圧縮を使用した 最適化特定の最適化
コンテンツコンテンツの 組み合わせクライアント（ブラウザまたはロボット）はWebサーバーと通信します
HTTPプロトコルを使用しています。 HTTPとその動作の細かな詳細
技術の下位層と上位層との相互作用-の1つ
高性能の鍵：HTTPはHyper Text Transport Protocolの略です。
もちろん、サーバーからクライアントへの転送だけでなく使用されます
HTMLファイルだけでなく、その他のオブジェクト：画像、スクリプト、
CSSファイル、データファイル。 また、逆に動作します
サイド-ファイルをサーバーにアップロードし、フォームを送信し、
など。AJAXアプリケーションも、明らかにサーバーと通信します。
HTTP HTTPがより具体的な目的で使用されることもありますが、
たとえば、WebDAVを使用してサーバーコンテンツを管理し、
など。HTTP通信は、一連の断続的な
クライアントとサーバー間のHTTPリクエストとHTTPレスポンス<Div class = "sect1" lang = "ru" xml：lang = "ru">

HTTPリクエスト

HTTP要求は、要求文字列、ヘッダー、および
メッセージ本文。 ファイルを取得するHTTPリクエストの例を次に示します
www.habrahabr.ru/robots.txt ：

  GET /robots.txt HTTP / 1.1
ホスト：www.habrahabr.ru
ユーザーエージェント：Wget 1.8.3

最新のウェブ上のHTTPリクエストの大部分は
これらは、リクエストボディが空（長さ0）のGETリクエストです。
この場合は観察してください。 たとえば、POSTリクエストの場合、本文
ほとんど常に空ではありません。リクエストの例を詳しく調べてみましょう。 リクエストの最初の単語は
GET これはいわゆる「方法」です
HTTPリクエスト。 最も一般的な方法は
GET GETメソッドは、単純に
指定された場所で利用可能なリクエストコンテンツ（ページまたはファイル）
URL。 重要な考慮事項は、GET要求ができることです
キャッシュされた別の一般的なリクエストはPOSTです。
POSTリクエストには、ほとんどの場合、エンコードされたリクエスト本文が含まれます
特別な形式のいずれかで。 通常、POSTリクエストは
ユーザーが[送信]ボタンまたは同様のボタンをクリックした結果として
アクションHEADメソッド（GETメソッドネイバー）も使用されます。
PUTようなよりまれなメソッドのホスト

DELETEと同様に、特定のメソッドの大規模なセット
WebDAVプロトコル。 これらの詳細については、他の章を/robots.txtください。クエリの2番目の単語： /robots.txt
これは、受信したいページまたはファイルのURLで、リクエストの3番目の単語はHTTP/1.1です。 それは
プロトコルの実際の名前とバージョン番号。 HTTP 1.1
ほとんど普遍的に使用されますが、一部の人にとっては十分です
特定の目標がHTTPに格下げされると便利な場合があります
1.0。 HTTP 1.1とHTTP 1.0の主な違いは必須です
仮想ホストのサポート、キャッシュのサポートの改善、
HTTPキープアライブの必須サポート、およびいくつかの重要な
クエリ文字列は、CR-LF（\ r \ n）の文字の組み合わせで終わります。
さらに、互いに分離されたリクエストヘッダーもあります
CR-LFの組み合わせ。 唯一の必須（HTTP 1.1）
ヘッダーは、ドメイン名を含むHostです
どのページまたはファイルがあるか。 HTTP標準は
多くの異なるリクエストヘッダー、その多くは再生
高いパフォーマンスを確保するための重要な役割。 で
例には、別のヘッダーUser-Agentが含まれています。
クライアント識別子行。ヘッダーのリストは、文字の別の組み合わせで終わります
CR-LF（つまり、空の文字列）。 見出しの後に体が来る
リクエスト。 この例では、リクエストの本文は空です（長さゼロ）<Div class = "sect1" lang = "ru" xml：lang = "ru">

HTTP応答

HTTP要求をサーバーに送信することにより、クライアントは応答を期待します。 HTTP応答
一般的にクエリに似ています：ステータスバー、リスト
ヘッダーと応答本文。

  HTTP / 1.1 200 OK
サーバー：nginx / 0.5.35
日付：2008年4月22日火曜日10:18:08 GMT
コンテンツタイプ：テキスト/プレーン; 文字セット= Windows-1251
接続：閉じる
最終変更日：金、2007年11月30日12:46:53 GMT
 ETag： "27e74f-43-4750063d"
 Accept-Ranges：バイト
コンテンツの長さ：34

ユーザーエージェント：*
不許可：/人

応答の最初の単語はHTTP/1.1バージョンです
プロトコル。 2番目の単語は200です。 これが最も一般的です
要求されたファイルまたはページが検出されたことを示す応答コード
顧客に与えられた。 多くの異なる応答コードがあり、
高い値を確保する上で重要な役割を果たす
パフォーマンス。 行の残りは
人間が読めるレスポンスコードの説明（この場合-
OK ）。ステータス行の後、次を含むヘッダーのリスト
追加の、時には非常に重要なファイル情報または
ページ。 この場合、コンテンツのMIMEタイプが重要です。
ファイルの最終変更日（ Last-Modified ）、その
長さ（ Content-Length ）およびETag （これ
キャッシングに使用される特別なトークン）。 答えにも
サーバー情報（ Serverと

Date ）and Connection 。ヘッダーのリストの後に、別の空の行が表示され、
最後に、応答の実際の内容（この場合、これらは2つです
テキスト行）。HTTPはシンプルで柔軟であると結論付けることができます。
テキスト構文プロトコル。 複数の正確な使用
リクエストおよびレスポンスヘッダーにより、
高性能Webシステムの領域。 詳細分析
関連するテクノロジーについては、次の章で説明します。<div class = "sect1" lang = "ru" xml：lang = "ru">

HTTPキープアライブによる最適化

HTTPはTCP（送信
制御プロトコル）。 TCPは信頼できるプロトコルです
双方向データストリーム送信。 TCPはパケットを転送することで機能します
クライアントからサーバーへ、またはその逆のデータ。 TCPパケットはヘッダーで構成されます
およびデータ。 ヘッダーには、クライアントIPアドレスと
サーバー、クライアントとサーバーで使用されるTCPポート番号、およびダイヤル
フラグ。 サーバーは通常、標準のTCPポートを使用します
80番。クライアントとサーバー間のTCP接続は次の方法で確立されます。
従来のTCP 3ウェイハンドシェイクを使用します。 お客様第一
SYNフラグ付きのパケットをサーバーに送信します。 応答として、サーバーはパケットを送信します
SYN + ACKフラグ。 最後に、クライアントはフラグ付きで別のパケットを送信します
ACKおよび接続は確立されたと見なされ、クライアントは
データ（この場合はHTTPリクエスト）を送信します。プロトコル相互作用のこの部分では、
サーバーからの応答パケットを1回待つ
HTTPリクエストを送信します。 つまり、TCP接続を確立する操作
比較的高価で、一部のチャネルでは
遅延と非常に高価です。 言い換えれば、
HTTP接続1.1では、この最適化はデフォルトで有効になっています。 一回
サーバーに接続すると、クライアントはサーバーとリクエストを交換し、
接続を切断せずに答えます。 これはHTTPと呼ばれます。
キープアライブ：数万のブラウザーがサーバーと共にインストールされている場合
キープアライブ接続を行うと、すぐにリソースを使い果たします。
したがって、すべてのサーバーには、設定可能なタイムアウトがあります。
キープアライブ接続が切断されていない場合は切断されます
アクティビティなし。クライアントは、応答後に接続切断を要求し、
要求ヘッダーConnection: close 同様に
サーバーは、キープアライブをサポートしないことを応答で示す場合があります
まったく同じヘッダーを渡すことによる接続：
Connection: close 。 一般的に、これらのすべて
相互通知の取り消し、厳密に言えば、課さない
義務なし。 サーバーとクライアントの両方を完全に準備する必要があります
接続がイニシアチブでいつでも中断されるという事実に
一方、通知はありません。キープアライブ接続の整合性を維持するために、
サーバーは応答の長さを知っている必要があります。 最も簡単な方法は
Content-Lengthヘッダーで指定します。 長さが
ハンドラーによって応答が示されない場合、サーバーは送信前に強制されます
応答セットヘッダーConnection: close
応答を送信した後、その部分で接続を閉じます。 Webアプリケーションが正しく公開されていることを確認してください
Content-Lengthヘッダー、それ以外の場合はキープアライブ接続
答えのサイズを作成段階で判断するのが難しい場合があります。 で
この場合、キープアライブ接続を犠牲にするか、または
特別なチャンク化された応答エンコーディングを使用します（それは
Transfer-Encoding: chunkedヘッダーを使用）。
詳細はHTTP標準に記載されています<Div class = "sect2" lang = "ru" xml：lang = "ru">

HTTPパイプライン化による最適化

1つの中で一連の要求と応答を行うとき
キープアライブ接続、時間はパフォーマンスに重要な役割を果たします
要求と応答の間の遅延。 遅延は
高いチャネル遅延と長時間の両方が原因
サーバーでリクエストを処理します。 別のリクエストを送信する前に、
次の処理が完了するまで待つ必要があります。 対処する
この問題は、技術を使用することができます
HTTPパイプライン処理：HTTPパイプライン処理の意味は、単にクライアントが
いくつかのリクエストを連続して送信し、徐々に開始します
入ってくる回答をすくい上げます。 一般的なサーバーサポート
良いが、残念ながら、現在サポートしているクライアント
HTTPパイプライン、市場のごく一部を占める<Div class = "sect1" lang = "ru" xml：lang = "ru">

HTTPキャッシングによる最適化

オーバーHTTPキャッシングは長年にわたって蓄積されてきました
神話と偏見。 第13章RFC2616（HTTPでのキャッシュ）
かなり紛らわしい。 これの主な理由は、著者が
すべての人に一度にすべてを説明しようとした：サーバー開発者、および
クライアント開発者、およびキャッシュプロキシ開発者。 を除く
さらに、混乱は時代遅れの議論を追加します
（HTTP 1.0）クライアント、サーバー、プロキシによる。この章では、ストーリー全体を正確に伝えることを試みます。
現代の開発者の視点（すなわち、サポート
HTTP 1.1）サーバー。 最初に、最も単純な状況について説明します。
最新のクライアントで動作します（途中でプロキシをキャッシュしません）。
その後-1つまたは
いくつかの最新のキャッシュプロキシ。 最後に、
さらに、どの（廃止された）ヘッダーを応答に追加する必要があるか、
古い顧客や時代遅れの顧客から受け入れられる結果を達成するため
道路沿いのプロキシ（ただし、これら2つの種の存在は
動物を証明するのは非常に難しいです。）<div class = "sect2" lang = "ru" xml：lang = "ru">

現代のクライアントでのキャッシュ

一般に、キャッシュプロセスは2つの部分で構成されます。
コンテンツの有効期限と再検証手順。コンテンツの有効期限を切れるには、
Cache-Control: max-age=300応答ヘッダーCache-Control: max-age=300 ここに

300は、コンテンツの有効期限（秒単位）です。
（つまり、5分）。 これは、5分以内にクライアントが
まったくリクエストせずに、受信したオブジェクトを自由に使用できます
re-server。オブジェクトが有効期限後に必要な場合、
再検証する必要があります。 再検証は単純に
同じオブジェクトを再要求しますが、追加で
見出し。 再検証により、いずれかの再送信が発生する場合があります
オブジェクト、または特別な応答コードを送信する
304 Not Modified 。 明らかに、2番目のオプション
望ましい。 再検証には主に3つの方法があります。

• 最終変更時
  （ Last-Modified ）;
• オブジェクト識別子（ ETag ）;
• 無条件（オブジェクトの内容を与えるだけ）;

再検証が最後の時間に機能するために
変更、応答ヘッダーの間に特別なヘッダーがあるはずです
当然のことながら、最後の時刻を含むLast-Modified
オブジェクトの変更。 再検証中に、この値はクライアントによって送信されます
特別なリクエストヘッダー： If-Modified-Since
要求ハンドラは、オブジェクトが変更されたかどうか、および
no-空のボディと応答コードで応答を返します

304 Not Modified 。 コンテンツ自体は
送信され、クライアントはコンテンツを使用します
キャッシュに保存されます。最後の変更時までに再検証を使用する方が簡単です
静的ファイル、およびデフォルトですべてのサーバーの合計
この機能を含めます。 動的に生成されたページの場合
適切なリクエスト処理アーキテクチャを選択すること、そして一般的には
そのような再検証の可能性と便宜が議論されています
オブジェクト識別子による再検証が機能するためには、
応答ヘッダーには特別な見出しが必要です
ETag 。 指定されていないものを返します
オブジェクトバージョン識別子（例：Apache静的ファイル用）
デフォルトでは、ファイルが最後に変更された日付の組み合わせを使用し、
ファイルシステムのサイズとiノード番号）。 再検証時
クライアントはリクエストで特別なヘッダーを送信します
同じ識別子を含むIf-None-Match 。
サーバーは、バージョン識別子の現在の値を比較します。
一致し、空の本文と応答コードを含む応答を返します
304 Not Modified最後の変更の時刻の再検証と同様に、
この再検証は、静的ファイルに使用するのが最も簡単です。 のために
動的に生成されたページの場合正しい選択の問題
コンテンツアーキテクチャについては以下で説明します。 両方の再検証メソッドは
神話上のブラウザやプロキシとの互換性のため、
HTTP 1.1をサポートするため、応答にはヘッダーを含める必要があります
Expires 。廃止の必要なポイントを示します
ファイルまたはページ。 このヘッダーの値の形式は次のとおりです。
Tue, 15 Nov 1994 08:12:31 GMT <div class = "sect2" lang = "ru" xml：lang = "ru">

再検証戦略

既に述べたように、キャッシングは最も簡単で最も理解しやすいものです
デザイン写真、javascriptファイルなどの静的ファイル、
CSSファイル。 静的ファイルの場合、生成が非常に簡単で、
両方の条件の意味を確認します： Last-Modifiedと
およびETag 。おそらく静的の場合にETag難しい質問
ファイル-適切な有効期限を選択します。 開発者
Yahoo.comは単純な戦略を推奨します。a）静的に公開する
1年のファイルの有効期限（読み取り：「永久」）およびb）
プロジェクトの新しいバージョンを投稿するときにURLを変更するシステムを導入する
実稼働サーバー上。たとえば、Ruby on Railsでは、URLが
CSSファイルは次のようになります。

/stylesheets/main.css?31415ここで
31415は、システム内の最新リビジョンの番号です
バージョン管理。 同様のメカニズムを簡単に実装できるはずです
他の保守的な戦略は、キャッシュすることです
約30分、短時間の静的ファイル。 だから
したがって、一般的なユーザーセッションを高速化します。 彼はいつ来ますか
次回サイトへ、初めてそれが起こったとき
すべての統計の一括再検証。 この戦略は必要ありません
量産コード除去システム（原則としてこれを変更する
この戦略の欠点と見なすことができます-多くの場合
そのようなシステムがまったく存在しないことを意味するかもしれません。）一般的に、いくつかの大幅な増加を達成するために、
パフォーマンスを向上させるには、条件を適切に組み合わせる必要があります。
まず、ページについては、比較的簡単に計算できるはずです
バリデーター（最終変更時刻またはETag）。 第二に
ページの情報デザインにより、クライアントは十分な負荷をかけることができます
時代遅れのコピー。 経験から、非常にまれなページクラス
測定可能な効果は言うまでもなく、この組み合わせを提供する
再検証の導入から。 現代の可能性があります
インタラクティブなプロジェクトは一般にそれについて考えるのは意味がありません
方向、および非常に高速な生成に集中
これらの同じページ。ただし、上記の静的キャッシュは
ファイルは、各特定のユーザーエクスペリエンスで重要な役割を果たします
ユーザー、およびそのようなキャッシュに注意を払う必要があります（良い
これは難しいことではありません。）この問題のもう1つの側面は、検索エンジン
システムは、おおよそ正しい時間を設定することを強くお勧めします
すべてのページでLast-Modified 、
検索ロボットにフィードします。 可能性があります
このトピックのエンジンを修正するプロセスは、
戦略自体を実装することも困難です
キャッシング<div class = "sect2" lang = "ru" xml：lang = "ru">

キャッシュとインタラクティブページを無効にする

多くの場合、逆問題も解決する必要があります。
サイトの特定のページがそれぞれサイトからリロードされるように
ユーザーが訪問する時間。 あります
HTTPのキャッシングに関連する一般的な神話から。 彼は縛られている
3つの魔法の魔法の呪文の儀式の繰り返しで
ヘッダー：

キャッシュ制御：キャッシュなし
プラグマ：no-cache
有効期限：今

エラーの詳細な分析については説明しませんが、
これら3行で収集されます。 最初の行は
この目的を完全に意図したものではなく、2行目は決して
意味がありませんでした、そして3番目は壊滅的に時代遅れです（それはしますが
タスク）。正しい現代的な方法は
Cache-Control: max-age=0ヘッダーCache-Control: max-age=0 。 彼は意味する
ページのコンテンツが受信後すぐに期限切れになること、および
ブラウザはそれを再検証する必要があります。 リクエストを受信するサーバー
再検証、単にユーザーに新しいバージョンを返す
ページ。ブラウザの神話上の古いバージョンとの互換性および
HTTP 1.1をサポートしないプロキシ、応答も
ヘッダーExpires: now追加しExpires: now 。 彼は同じです
Cache-Control: max-age=0ような意味です。<div class = "sect1" lang = "ru" xml：lang = "ru">

圧縮の最適化

トラフィックを大幅に削減し、応答を高速化する素晴らしい方法
サーバーは、指定されたファイルとページの圧縮です。 ほぼ
最新のすべてのWebサーバーが何らかの形でこれをサポート
機能。 圧縮率は
特定の各ページで、10のオーダーの値に到達できます。
Webアプリケーション開発者の圧縮は完全に透過的であり、必要ありません
圧縮されたコンテンツクライアントを受け入れる機能
ヘッダーを使用してサーバーに通知します

Accept-Encoding: gzip 。 サーバーが
関連コンテンツの圧縮、それからタイトルを追加できます
Content-Encoding: gzip応答（混同しないでください）
Transfer-Encoding ）および圧縮されたクライアントに送信
コンテンツ。歴史的に異なるブラウザには多くの異なるエラーがありました
圧縮コンテンツの処理。 現在（2008年半ば）、
エラーのある実際に使用された顧客の割合が低下したようです
無視できる。 通常、サーバーのドキュメントでは、
コンテンツのタイプとブラウザの組み合わせのおよそのセット
古いクライアントのエラーを回避するための推奨事項と同様に機能します。
<div class = "sect2" lang = "ru" xml：lang = "ru">

特定の最適化
内容

簡単に言えば、これは余分なスペースと改行を削除します
HTMLファイルとCSSファイルから、JavaScriptの縮小、および
画像ファイルサイズの最適化。 サイズへの影響に加えて
送信データ、この最適化も増加する可能性があります
クライアント側のパフォーマンス：ブラウザのパフォーマンスは低下します
処理されたページのページソースおよびDOMノードの解析および占有メモリの削減
。JavaScriptのミニファイは、
難読化（コードの意味を暗くする）と同時に実行することもできます。これは
、知的財産保護ポリシーの観点からある程度の意味を持つ場合があります。
prototype.jsなどの汎用ライブラリには、
縮小化の組み込みサポートと、
プロジェクトで使用されていないコンポーネントのサブセットを削除する機能が含まれています<Div class = "sect2" lang = "ru" xml：lang = "ru">

コンテンツの組み合わせ

HTTPリクエストの数を減らすために、
複数のファイルを1つにまとめることができます。多くの場合、
結合に加えて、結果のファイルを縮小することもできますCSSファイルは単純に1つに連結できます。JavaScriptファイルに
はこの点に注意が必要ですが、一般的に
、JavaScriptが連結されない場合
、JSコードのアーキテクチャに問題があると想定できます。アイコン、ナビゲーショングラフィックなどは、
t n CSSスプリット
このテーマに関する多数のガイドをオンラインで参照してください。