12.1HTTPプロトコルの概要

HTTP（HyperText Transfer Protocol）プロトコル、つまりHyperTextTransferProtocol。いわゆるプロトコルとは、コンピュータネットワークでのデータ交換のために確立されたルール、標準、または制約の集まりを指します。簡単に言うと、プロトコルは2台のコンピュータ間の通信ルールを定義し、プロトコルを通じて相互通信の目的を達成することができます。ワールドワイドウェブ上で最も広く使用されているプロトコルとして、HTTPプロトコルの開発は、ワールドワイドウェブコンソーシアムとインターネット技術特別調査委員会（IETF）の間の協力の結果です。

HTTPの12.1.1開発の歴史¹

1. HTTP / 0.9バージョン：最初に完成したHTTPプロトコルで、このバージョンの内容は非常に単純です。

コマンドGETは1つだけです。
HEADERなどのデータを説明する情報はありません。
サーバーはコンテンツの送信を終了すると、TCP接続を閉じます。

2. HTTP / 1.0バージョン：このバージョンは、HTTP / 0.9バージョンに基づく改良版であり、現在一般的に使用されているHTTP /1.1に類似しています。

多くのコマンドが追加されました。例：POST、PUT、HEADERこれらのコマンド。
ステータスコードとヘッダーに関連するコンテンツを追加しました。ステータスコードは、特定のリクエストを処理した後のサーバーのステータスを説明するために使用されます。
マルチ文字セットのサポート、マルチパート送信、権限、キャッシュ、およびその他の関連コンテンツが追加されました。

3. HTTP / 1.1バージョン：このバージョンは、HTTP /1.0に基づいてネットワーク接続のプロセスを最適化するためのいくつかの機能を追加します。

このバージョンでは、持続的接続がサポートされています。TCP接続が確立された後、それは閉じられず、新しいhttp要求は常にこの接続で送信できます。
パイプラインを追加しました。同じTCP接続で複数のhttpリクエストを送信できます。ただし、サーバーは着信要求のためにデータを返す必要があります。
HTTPヘッダーホストとその他のコマンドを追加しました。ホストを使用すると、同じサーバー（物理サーバー）で複数のWebサービスを同時に実行できます。

4. HTTP / 2バージョン：

すべてのデータはバイナリで送信されます。HTTP / 1.1では、ほとんどのデータ送信が文字列を介して行われるため、データの断片化方法が異なります。HTTP / 2のすべてのデータはフレームで送信されます。
同じ接続でリクエストを並行して処理します。同じ接続で複数のリクエストが送信された場合、サーバーは処理されたデータを順番に返す必要がなくなります。
伝送効率を向上させるために、新しいヘッダー情報の圧縮およびプッシュ機能が追加されました。

12.1.2HTTPプロトコルの主な機能

シンプル：クライアントがサーバーにサービスを要求するとき、要求メソッドとパスを送信するだけで済みます。
柔軟性：HTTPを使用すると、あらゆるタイプのデータオブジェクトを送信できます。送信されるタイプは、Content-Typeによってマークされます。
ステートレス：HTTPプロトコルはステートレスプロトコルです。ステートレスとは、WebブラウザとWebサーバーの間に永続的な接続を確立する必要がないことを意味します。つまり、クライアントがサーバーに要求を送信し、Webサーバーが応答を返すと、接続が閉じられます。接続は保持されません。

12.2HTTPのしくみ

12.2.1 TCP / IPプロトコルスイートにおけるHTTPプロトコルの位置

インターネットでの送信はすべてTCP / IPを介して行われ、TCP / IPモデルのアプリケーション層プロトコルとしてのHTTPプロトコルも例外ではなく、通常はTCPプロトコルで実行され、TLSまたはSSLでも実行される場合があります。プロトコル層。、現時点では、HTTPSと呼ばれるものになっています。ネットワーク内のHTTPの階層を次の図に示します。

アプリケーション層（HTTP / HTTPS）
トランスポート層（TCP）
ネットワーク層（IP）
データリンク層

通常、HTTPの予約ポートは80で、HTTPSのポート番号は443です。

12.2.2HTTPのしくみ

以上のことから、HTTPはトランスポート層に基づくTCPプロトコルであり、TCPはエンドツーエンドのコネクション型プロトコルであることがわかります。いわゆるエンドツーエンドは、プロセス間通信として理解できます。したがって、HTTP送信を開始する前に、最初にTCP接続を確立する必要があり、TCP接続プロセスにはいわゆる「スリーウェイハンドシェイク」が必要です。TCPスリーウェイハンドシェイクの後、TCP接続が確立され、この時点でHTTPを送信できます。
例を使用して、HTTPプロトコルの通信プロセスを簡単に理解しましょう。Wiresharkツールを使用してhttp://www.cr173.comページにアクセスし、一度キャプチャすると、次の図に示すように、Webページアクセスのプロセス全体を明確に確認できます（クライアントのIPは10.134.51.2、サーバーのIPは10.134.51.2です）。 IPは49.7.21.45）です。
ここに画像の説明を挿入
クライアントブラウザはサーバーへのTCP接続要求を開始し、ステータスはSYNです。
次に、サーバーはクライアントブラウザに応答し、確認を求めます。Seq= 0、Ack =1。
クライアントブラウザが情報を受信した後、同じように応答します。この時点で、Seq = 1、Ack = 1、TCPスリーウェイハンドシェイクは成功しています。
クライアントブラウザはページHTTPリクエストを
サーバーに送信し、サーバーはデータとステータス応答コード200をクライアントブラウザに送信します。

12.3HTTPリクエスト

ブラウザとサーバーが接続を確立する方法を理解した後、次のステップは、HTTPプロトコルがコンテンツを送信する方法を理解することです。HTTPリクエストメッセージでは、主に次の3つの部分で構成されています。

リクエストライン（リクエストメソッド+リクエストURL +プロトコルバージョン）
リクエストヘッダー
リクエスト本文

説明のために例を見てみましょう。
ここに画像の説明を挿入
上記は典型的なHTTP要求メッセージであり、最初の行は要求行です。

要求行は固定された方法で記述され、3つの部分で構成されています。最初の部分はリクエストメソッド、2番目の部分はリクエストURL、3番目の部分はHTTPプロトコルバージョンです。「GET」はリクエストメソッドを意味します。HTTP/ 1.1プロトコルには、GET、POST、HEAD、OPTIONS、PUT、DELETE、TRACEの7つのメソッドがあります。最も一般的に使用されるのはGETとPOSTです。「/」はアクセスURLのルートディレクトリを意味し、ホストが配置されているURLの下の他の相対パスにすることもできます。「HTTP / 1.1」はプロトコルと対応するバージョンを意味し、現在主流は1.1です。
2行目の最初から最後までは、通常ヘッダーフィールドとも呼ばれるリクエストヘッダーです。各ヘッダーフィールドは、ドメイン名、コロン（:)、およびドメイン値で構成されます。ドメイン名では大文字と小文字が区別されず、ドメイン値の前に任意の数のスペースを追加できます。一般的に使用されるヘッダーフィールドを次に示します。
ここに画像の説明を挿入
HOSTヘッダーフィールドは、要求されたリソースのインターネットホストとポート番号を指定し、要求されたURLの元のサーバーまたはゲートウェイの場所を示す必要があります。HTTP / 1.1リクエストには、ホストヘッダーフィールドが含まれている必要があります。含まれていない場合、システムは400ステータスコードを返します。
ここに画像の説明を挿入

User-Agentは、ブラウザのタイプとバージョン、オペレーティングシステムなど、リクエスターの情報を識別します。この例の内容から、お客様はWindows 1064ビットオペレーティングシステムに基づくChrome / 87.0.4280.88バージョンのブラウザーを使用していることがわかります。ここに記載されている情報は通常、データ収集に使用され、ユーザーが当社のサービスにアクセスするために使用するブラウザーを分析できます。
ここに画像の説明を挿入
Acceptは、クライアントが受信する応答コンテンツのタイプを指定するために使用されます。また、クライアントのブラウザーで直接開くことができる形式でもあります。

Accept-Language：クライアントのオペレーティングシステム言語、私たちが通常使用する中国語のオペレーティングシステム、この属性値は通常zh-cnです。
ここに画像の説明を挿入
接続：クライアントとサーバーが通信するときに長い接続を処理する方法を示します。HTTP/ 1.1では、クライアントとサーバーの両方がデフォルトで長い接続をサポートします。クライアントがHTTP / 1.1プロトコルを使用しているが、長い接続を使用したくない場合、ヘッダーで接続の値をcloseとして指定する必要があります。サーバーが長い接続をサポートしたくない場合は、応答で接続の値もcloseとして指定する必要があります。要求ヘッダーまたは応答ヘッダーにcloseの接続値が含まれているかどうかに関係なく、現在使用中のTCP接続は、現在の要求が処理された後に切断されることを示します。後で、クライアントが新しい要求を行うとき、クライアントは新しいTCP接続を作成する必要があります。
Date、Proxy、Cache-Control、Cookiesなどの一般的なヘッダーフィールドもあります。
上記の例はGETリクエストであるため、通常はリクエスト本文はありません。POSTリクエスト（直接投稿された本の元の画像）を介してリクエスト本文を見てみましょう。
ここに画像の説明を挿入
上記の例のボックス部分はリクエスト本文であり、通常、対応するのはPOSTによって送信されたコンテンツ情報です。

12.4HTTP応答

HTTP応答メッセージは要求メッセージに似ており、次の3つの部分で構成されています。

応答ライン
応答ヘッダー
レスポンスボディ

上記のリクエストのレスポンスメッセージを使用して説明します。
ここに画像の説明を挿入

レスポンスラインはHTTPリクエストラインに似ており、通信プロトコルがHTTP / 1.1バージョンであることを意味し、「200」はサーバーがによって送信されたリクエストを正常に処理したことを意味します。クライアント。以下は、一般的なHTTP要求応答の戻りコードのリストです。

200	OK	リクエストは成功しました。通常、GETおよびPOSTリクエストに使用されます
300	複数の選択肢	複数の選択肢。要求されたリソースには複数の場所を含めることができ、応答では、ユーザー端末（ブラウザーなど）を選択するためのリソース特性とアドレスのリストを返すことができます。
301	恒久的に移動	永久に移動します。要求されたリソースは永続的に新しいURIに移動され、返される情報には新しいURIが含まれ、ブラウザーは自動的に新しいURIに移動します。今後の新しいリクエストでは、代わりに新しいURIを使用する必要があります
302	見つかりました	一時的に移動します。301と同様ですが、リソースは一時的に移動されるだけなので、クライアントは引き続き元のURIを使用する必要があります
400	要求の形式が正しくありません	クライアント要求の構文が正しくなく、サーバーがそれを理解できません
401	許可されていない	リクエストにはユーザー認証が必要です
402	支払いが必要	将来の使用のために予約済み
403	禁止	サーバーは要求元のクライアントの要求を理解しますが、要求の実行を拒否します
404	見つかりません	サーバーは、クライアントの要求に従ってリソース（Webページ）を見つけることができません。このコードを使用して、Webサイトの設計者は、「要求したリソースが見つかりません」というパーソナライズされたページを設定できます。
405	許可されていない方法	クライアントリクエストのメソッドは禁止されています
500	内部サーバーエラー	内部サーバーエラーにより、リクエストを完了できませんでした
501	実装されていません	サーバーは要求された機能をサポートしておらず、要求を完了できません
502	悪いゲートウェイ	ゲートウェイまたはプロキシとして機能するサーバーが、リモートサーバーから無効な要求を受信しました
503	サービスは利用できません	まず、過負荷またはシステムメンテナンスのため、サーバーは一時的にクライアント要求を処理できません。遅延の長さは、サーバーのRetry-Afterヘッダー情報に含めることができます。
504	ゲートウェイのタイムアウト	ゲートウェイまたはプロキシとして機能するサーバーは、リモートサーバーからの要求を時間内に取得しません
505	HTTPバージョンはサポートされていません	サーバーは要求されたHTTPプロトコルバージョンをサポートしておらず、処理できません

応答ヘッダーの内容は、要求ヘッダーの内容と似ています。注意が必要ないくつかのヘッダーフィールドは次のとおり
ここに画像の説明を挿入
です。返されるコンテンツがHTML形式に基づくページ情報であることを示します。

ページで送信されたコンテンツが正しいことを確認するために返される本文の長さを示します。
ページにアクセスすると、HTTPリクエストを送信するだけではありません。通常の状況では、表示される完全なWebインターフェイスは複数のHTTPリクエストによって完成します。通常の状況では、ブラウザによるHTML解析の過程で、取得する必要のあるコンテンツ（CSS、GIF、PNGなど）が見つかると、サーバーに対してHTTPリクエストを再度開始して取得します。、ただし、TCP接続は1つだけで十分です。これは、いわゆる持続的接続です。

12.5HTTPキャプチャ

現在、ネットワーク上で送信されるHTTPプロトコルコンテンツをキャプチャするための主流のツールは次のとおりです
。Wireshark：Windowsで最も一般的に使用されているネットワークパケットキャプチャツール。シンプルで使いやすい。このツールは上記の例で使用されています。ただし、このツールによってキャプチャされるパケットは通常16進数であるため、後のパフォーマンステスト中にHTTPプロトコルの送信コンテンツに対して2次処理を実行するのは不便です。
FirefoxでのFirebug：各ページから送信されるコンテンツ、ページ構成を明確に確認でき、使用方法は比較的簡単です。Firebugコンポーネントを検索して、Firefox（新しいバージョンのブラウザ）のツールアクセサリコンポーネントにインストールするだけです。インストールされている追加のコンポーネントはサポートしていません。自分でダウンロードしてインストールできます）。
Chromeは直接プレスはCtrl + Shift + Iまたは右のチェック、すべてのコンポーネントをインストールする必要はありません、あなたはHTTPプロトコルの要求コンテンツを視聴するには、関連するツールを呼び出すことができ、効果は次の図に示します。
ここに画像の説明を挿入
もありますIEでのツールHttpWatch。次の章では、このツールに焦点を当て、このツールを使用して、簡単なページのフロントエンドパフォーマンス分析を実行します。

12.6Httpウォッチ

Http Watchは、Internet Explorerツールバーに統合された強力なWebデータ分析ツールであり、HTTPプロトコルの相互作用に関する詳細な情報を収集して表示できます。対応するWebサイトを選択するだけで、WebサイトとIE要求応答間の通信を分析し、対応するログレコードを同じインターフェイスに表示できます。各HTTPレコードは、Cookie、メッセージヘッダー、文字クエリ、およびその他の情報を詳細に分析できます。HTTPSおよび分析レポートの出力をXML、CSV、およびその他の形式でサポートします。
Http Watchのインストールが完了したら（win10にはバージョンの互換性の問題があり、バージョン7.0.23をダウンロードする必要があります。7.0.23中国語バージョンをダウンロードしました）、Webサイトにアクセスするか、IEのツールオプションをクリックするか、右クリックして検索します。「HttpWatchPro」（ここではダウンロードしたプロバージョンです）オプションをクリックしてクリックすると、次の図に示すように、HttpWatchのメインインターフェイスがブラウザの下部に表示されます。
ここに画像の説明を挿入

12.6.1Httpウォッチの記録

次の図に示すように、[記録]ボタンをクリックし、URLにアクセスします。ページが完全に表示され
ここに画像の説明を挿入
たら、[停止]ボタンをクリックしてHTTPインタラクションの結果を生成します。HttpWatchパネル全体が3つの領域に分かれています。メニューエリア、データエリア、データ詳細エリア。メニュー領域には、主に、記録、停止、クリア、クエリ、フィルターなど、一般的に使用されるいくつかの機能ボタンが含まれています。データ領域には、アクセスしたURLと関連リソース（画像、CSSなど）が格納されます。データ詳細領域は、特定のURLの詳細な分析用です。

12.6.2 HttpWatchデータ分析

データ領域
データ領域では、インターフェースが複数のURL要求で構成されていることがわかります。以下は、この領域の各列の簡単な分析です。

開始：ここでの時間は、最初のリクエストからの他のリクエストの時間オフセットを指します。
時間のかかるグラフ：各リクエストに費やされた時間の特定の分布。
時間：各URLリクエストに費やされた特定の時間（秒単位）。
送信済み：HTTPリクエストヘッダーとデータのサイズを含む、各リクエストによって送信されたデータのサイズ（バイト単位）。
受信：サーバーから返されたデータの合計量（バイト単位）。
メソッド：HTTPリクエストメソッド。一般的なメソッドはGETとPOSTです。
戻り値：HTTP要求応答の戻りコード。要求がキャッシュを介して表示される場合、ここでは（キャッシュ）として表示されます。
タイプ：URLリクエストのタイプ、主に次のタイプを説明します：html、css、javascript、image、redirect。
URL：特定のURLリクエストアドレス。
データ領域の下部には、統計情報の行があります。ここが最も注意が必要な場所です。

次のデータに注意する必要があります。時間は、インターフェイス全体がロードされた時間を反映します。これは、通常の状況でのユーザーの応答時間です。この応答時間が長すぎると、ユーザーエクスペリエンスに深刻な影響を及ぼします。送受信の合計は、1人のユーザーがアクセスしたネットワークトラフィックを反映しています。この値が比較的大きい場合、マルチユーザーで使用する場合、ネットワーク帯域幅がボトルネックになります。メソッド列の下部で、リクエストの数がカウントされます。リクエストが多すぎる場合は、サーバーリソースのオーバーヘッドを削減するために、CSSとイメージをマージする必要があるかどうかを検討する必要があります。
データ詳細領域
URLまたはリソースを選択すると、データ詳細領域に特定の情報が表示され、複数のタブページに分割され、さまざまなコンテンツを表示できます。

概要：URLの概要情報。返されるアドレス、時刻、接続されているIP、およびステータス情報が表示されます。

時間のかかるグラフ：接続の確立から完全な表示まで、URLにアクセスするために費やされるすべての時間は、さまざまな色で区別されます。

ヘッダー情報：送信された要求と受信された応答を含む、HTTPプロトコルのヘッダー情報を表示します。
Cookie、キャッシュ：ページ関連のキャッシュ情報を保存します。キャッシュが更新されているか、期限切れになっているか、キャッシュコンテンツが正しく保存されているかどうかをテストする必要がある場合は、このタブから表示できます。
POSTデータ：POSTリクエストにリクエスト本文を保存します。
コンテンツ：接続にアクセスしたときにサーバーから返されるコンテンツ。
データフロー：リクエストプロセス全体のデータを表示します。
警告：HttpWatchには、セキュリティチェック、文法チェックなどがいくつか付属しているため、あまり注意を払う必要はありません。