HTTPプロトコルについての深い理解

HTTP プロトコルについての深い理解

1. 基本概念

1.1 はじめに

HTTP は、Hyper Text Transfer Protocol の略です。この開発は、World Wide Web Consortium と Internet Engineering Task Force (IETF) の協力の成果であり、最終的には HTTP/1.0 バージョンを定義する一連の RFC 1945 をリリースしました。これらの中で最も有名なのは RFC 2616 です。 RFC 2616 は、現在一般的に使用されているバージョンである HTTP 1.1 を定義しています。

HTTPプロトコル（HyperText Transfer Protocol、ハイパーテキスト転送プロトコル）は、WWWサーバーからローカルブラウザにハイパーテキストを転送するために使用される転送プロトコルです。これにより、ブラウザの効率が向上し、ネットワーク送信が削減されます。これにより、コンピュータがハイパーテキスト ドキュメントを正確かつ迅速に送信することが保証されるだけでなく、ドキュメントのどの部分が送信されるか、コンテンツのどの部分が最初に表示されるか (グラフィックの前のテキストなど) なども決定されます。

HTTP は、リクエストとレスポンスで構成されるアプリケーション層プロトコルであり、標準的なクライアント/サーバー モデルです。 HTTP はステートレス プロトコルです。

1.2 TCP/IP プロトコル スタックでの位置

HTTP プロトコルは通常、TCP プロトコルの上に置かれ、場合によっては TLS または SSL プロトコル層の上に置かれます。このとき、それは私たちがよく HTTPS と呼ぶものになります。以下の図に示すように:

HTTP のデフォルトのポート番号は 80 で、HTTPS のポート番号は 443 です。

1.3 HTTPリクエストレスポンスモデル

HTTPプロトコルは常にクライアントからリクエストを開始し、サーバーからレスポンスを送り返します。以下の図を参照してください:

これにより、HTTP プロトコルの使用が制限され、クライアントがリクエストを開始しない場合、サーバーはクライアントにメッセージをプッシュすることができなくなります。

HTTP プロトコルはステートレス プロトコルです。このリクエストと同じクライアントの最後のリクエストの間には対応関係がありません。

1.4 ワークフロー

HTTP 操作はトランザクションと呼ばれ、その作業プロセスは 4 つのステップに分割できます:

1) まず、クライアントとサーバーは接続を確立する必要があります。ハイパーリンクをクリックするだけで、HTTP の作業が開始されます。

2) 接続を確立した後、クライアントはサーバーにリクエストを送信します。リクエストの形式は次のとおりです。Uniform Resource Identifier (URL)、プロトコルのバージョン番号、その後にリクエスト修飾子、クライアント情報、および考えられるコンテンツを含む MIME 情報が続きます。 。

3) リクエストを受信した後、サーバーは対応する応答情報を提供します。その形式は、情報のプロトコル バージョン番号、成功コードまたはエラー コードを含むステータス行と、それに続くサーバー情報、エンティティ情報、および MIME 情報です。可能な内容。

4) クライアントはサーバーから返された情報を受信し、ブラウザーを通じてユーザーのディスプレイに表示した後、サーバーから切断します。

上記の処理の特定のステップでエラーが発生した場合、エラーメッセージがクライアントに返され、ディスプレイ画面に出力されます。ユーザーにとって、これらのプロセスは HTTP 自体によって完了し、マウスでクリックして情報が表示されるのを待つだけで済みます。

1.5 Wireshark を使用して TCP および http パケットをキャプチャします

Wireshark を開き、ツールバーで [キャプチャ] -> [オプション] を選択します。インターフェイスの選択は図 1 に示されています:

一般の読者は、上部のドロップダウン ボックスで適切なデバイスを選択し、[キャプチャ フィルター] をクリックします。ここでの選択は [HTTP TCP ポート (80)] です。選択後、上の図の [開始] をクリックしてパケットのキャプチャを開始します。

たとえば、ブラウザで http://image.baidu.com/ を開くと、パケット キャプチャが図 3 に示されています。
http://www.blogjava.NET/images/blogjava_net/amigoxie /40799/ o_http%e5%8d%8f%e8%ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-3.jpg

上の図では、クライアント ブラウザ (IP は 192.168.2.33) とサーバー間の対話プロセスがはっきりとわかります:

1) No1: ブラウザ (192.168.2.33) がサーバーにメッセージを送信します。 (220.181.50.118) ) は接続リクエストを発行します。図からわかるように、これは TCP スリーウェイ ハンドシェイクの最初のステップです。SYN、seq: 要求と要求の確認、この時点では SYN、ACK、この時点では seq: y (y は 0) です。 )、ACK: x+1 (1 です)。これは 3 ウェイ ハンドシェイクの 2 番目のステップです。

3) No3: ブラウザ (192.168.2.33) が確認のためにサーバー (220.181.50.118) に応答し、接続に成功しました。 is: ACK、このとき seq: x+1 (is 1)、ACK: y+1 (is 1)。これは 3 ウェイ ハンドシェイクの 3 番目のステップです。

4) No4: ブラウザ (192.168.2.33) がページ HTTP リクエストを発行します。

5) No5: サーバー (220.181.50.118) が確認します。 No6: サーバー (220.181.50.118) データを送信します。

7) No7: クライアント ブラウザー (192.168.2.33) が確認します。

8) No14: クライアント (192.168.2.33) が画像 HTTP リクエストを発行します。 : サーバー (220.181.50.118) 送信ステータス応答コード 200 OK

......

1.6 ヘッダーフィールド

各ヘッダーフィールドは、ドメイン名、コロン (:)、およびドメイン値で構成されます。ドメイン名では大文字と小文字が区別されません。ヘッダー フィールドは、各行の先頭に少なくとも 1 つのスペースまたはタブを使用して、複数の行に追加できます。

パケット キャプチャの画像で、No14 をクリックすると、図 4 に示す画像が表示されます。

http://www.blogjava.net/images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8% ae %ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-4.jpg

応答メッセージを図 5 に示します。 1.6.1 Host ヘッダー フィールド

Host ヘッダー フィールドは、要求されたリソースのインターネット ホストとポート番号を指定し、要求された URL の元のサーバーまたはゲートウェイの場所を示す必要があります。 HTTP/1.1 リクエストにはホスト ヘッダー フィールドが含まれている必要があります。そうでない場合、システムは 400 ステータス コードを返します。

図 5 のホストの動作:

1.6.2 Referer ヘッダー フィールド

Referer ヘッダー フィールドを使用すると、クライアントはリクエスト URI のソース リソース アドレスを指定でき、これによりサーバーはフォールバック リストを生成できます。 、ログインとキャッシュ待機の最適化に使用できます。また、メンテナンス目的で放棄された接続や障害のある接続を追跡することもできます。要求された URI に独自の URI アドレスがない場合、Referer を送信できません。部分的な URI アドレスを指定する場合、このアドレスは相対アドレスである必要があります。

図 4 の Referer 行の内容は次のとおりです。

1.6.3 User-Agent ヘッダー フィールド

User-Agent ヘッダー フィールドの内容には、リクエストを行ったユーザー情報が含まれています。

図 4 の User-Agent 行の内容は次のとおりです:

http://www.blogjava.net/images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8%ae%ae%e5 % ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-8.jpg

1.6.4 Cache-Control ヘッダー フィールド

Cache-Control は、リクエストするキャッシュを指定し、反応はメカニズムに従います。要求メッセージまたは応答メッセージで Cache-Control を設定しても、別のメッセージの処理中のキャッシュ プロセスは変更されません。リクエスト中のキャッシュ命令には、no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached が含まれ、応答メッセージ内の命令には、public、private、no-cache、no が含まれます。 -store、no-transform、must-revalidate、proxy-revalidate、max-age。

図 5 のヘッダー フィールドは次のとおりです。

1.6.5 Date ヘッダー フィールド

Date ヘッダー フィールドは、メッセージが送信された時刻を示します。時刻の記述形式は rfc822 で定義されています。たとえば、日付:Mon,31Dec200104:25:57GMT。 Date で記述される時刻は世界標準時を表し、それを現地時間に変換するには、ユーザーのタイムゾーンを知る必要があります。

図 5 では、ヘッダー フィールドは次のようになります:

1.7 HTTP のいくつかの重要な概念

1.7.1 接続:接続

相互に通信する 2 つのアプリケーション間で確立されるトランスポート層の実際の循環。

http1.1 では、リクエスト ヘッダーとレスポンス ヘッダーに接続ヘッダーが表示される場合があります。このヘッダーの意味は、クライアントとサーバーが通信するときに長いリンクを処理する方法です。

http1.1 では、クライアントとサーバーはデフォルトで長いリンクをサポートします。クライアントが http1.1 プロトコルを使用するが、長いリンクを使用したくない場合は、ヘッダーの connection の値を close として指定する必要があります。サーバー側が長いリンクをサポートしたくない場合は、応答で接続の値が近いことを明確に示す必要もあります。要求ヘッダーまたは応答ヘッダーに close という値の接続が含まれているかどうかに関係なく、現在使用中の TCP リンクがその日に要求が処理された後に切断されることを示します。今後、クライアントは新しいリクエストを行うときに新しい tcp リンクを作成する必要があります。

1.7.2 メッセージ: メッセージ

HTTP 通信の基本単位。8 タプルの構造化されたシーケンスが含まれ、接続を通じて送信されます。

1.7.3 リクエスト: Request

クライアントからサーバーへのリクエスト情報には、リソースに適用されるメソッド、リソースの識別子、プロトコルのバージョン番号が含まれます。

1.7.4 レスポンス: レスポンス

サーバーから返されるメッセージには、HTTP プロトコルのバージョン番号、リクエストのステータス (「成功」または「見つからない」など)、およびドキュメントの MIME タイプが含まれます。

1.7.5 リソース: リソース

URI によって識別されるネットワーク データ オブジェクトまたはサービス。

1.7.6 エンティティ: エンティティ

データ リソースの特別な表現、またはサービス リソースからの反映。リクエストまたはレスポンス メッセージに含めることができます。エンティティには、エンティティ ヘッダー情報とエンティティ自体のコンテンツが含まれます。

1.7.7 クライアント: クライアント

リクエストを送信する目的で接続を確立するアプリケーション。

1.7.8 UserAgent: UserAgent

要求元のクライアントを初期化します。これらはブラウザ、エディタ、またはその他のユーザー ツールです。

1.7.9 サーバー: サーバー

接続を受け入れ、リクエストに情報を返すアプリケーション。

1.7.10 オリジンサーバー: Originserver

は、特定のリソースを常駐または作成できるサーバーです。

1.7.11 プロキシ: プロキシ

他のクライアントへのリクエストを確立するためにサーバーまたはクライアントとして機能できる中間プログラム。リクエストは内部的に、または可能な変換を介して他のサーバー経由で渡されます。プロキシは、リクエスト メッセージを送信する前に、リクエスト メッセージを解釈し、可能であれば書き換える必要があります。

プロキシは、ファイアウォールを介してクライアントのポータルとして機能することが多く、ユーザー エージェントによって完了されないプロトコル経由のリクエストを処理するヘルパー アプリケーションとしても機能します。

1.7.12 ゲートウェイ: ゲートウェイ

他のサーバーの仲介として機能するサーバー。プロキシとは異なり、ゲートウェイは、要求されたリソースのオリジン サーバーであるかのように要求を受け入れます。要求元のクライアントは、ゲートウェイを処理していることを認識しません。

ゲートウェイは、ファイアウォールを介してサーバー側のポータルとして機能することが多く、非 HTTP システムに保存されているリソースにアクセスするためのプロトコル トランスレーターとしても機能します。

1.7.13 チャンネル: トンネル

は、2 つの接続間のリレーとして機能する仲介プログラムです。チャネルは、一度アクティブ化されると、HTTP 要求によって開始される可能性がありますが、HTTP 通信に属しているとは見なされません。中継された接続の両端が閉じられると、チャネルは消滅します。チャネルは、ポータルが存在する必要がある場合、または仲介者が中継されたトラフィックを解釈できない場合によく使用されます。

1.7.14 キャッシュ: 応答情報のキャッシュ

ローカルストレージ。

付録: 参考資料

「http_Baidu 百科事典」: http://baike.baidu.com/view/9472.htm

「結果のエンコーディングと http ステータス レスポンス コード」: http://blog.tieniu1980 .cn/ archives/377

「TCP の 3 ウェイ ハンドシェイクの分析」

http://cache.baidu.com/c?m=9f65cb4a8c8507ed4fece763104c8c711923d030678197027fa3c215cc7905141130a8e5747 e 0d548d98297a5ae91e03f7f63772315477e3cacdd94cdbbdc42225d82c36734f 844315c419d891007a9f34d507a9f916a2e1b065d2f48193864353bb15543897 f1fb4d711edd1b86033093b1e94e022e67adec40728e2e605f983431c5508fe4&p=c6769a46c5820efd08e2973b42&user=baidu

「Wireshark を使用して HTTP 接続プロセスを検出する」 ":

http://blog.163.com/wangbo_tester/blog/static/12806792120098174162288/

「http プロトコルのいくつかの重要な概念」: http://nc.mofcom.gov.cn/news/10819972。 html

「http プロトコルにおける接続ヘッダーの役割」:

http://blog.csdn.net/barfoo/archive/2008/06/05/2514667.aspx

2. プロトコルの詳細な説明

2.1 HTTP/1.0 HTTP/1.1 との比較

RFC 1945 は HTTP/1.0 バージョンを定義し、RFC 2616 は HTTP/1.1 バージョンを定義します。

著者は、これら 2 つの RFC の中国語版のダウンロード アドレスをブログで提供しています。

RFC1945 ダウンロード アドレス:

http://www.blogjava.Net/Files/amigoxie/RFC1945 (HTTP) 中国語版.rar

RFC2616 ダウンロード アドレス:

http://www.blogjava.net/Files/ amigoxie/RFC2616 (HTTP) 中国語版.rar

2.1.1 接続確立の側面

HTTP/1.0 各リクエストは新しい TCP 接続を確立する必要があり、接続は再利用できません。 HTTP/1.1 最後のリクエストによって確立された TCP 接続の上に新しいリクエストを送信でき、接続を再利用できます。利点は、繰り返される TCP スリーウェイ ハンドシェイクのオーバーヘッドが軽減され、効率が向上することです。

注: 同じ TCP 接続では、新しいリクエストは送信する前に、最後のリクエストが応答を受信するまで待つ必要があります。

2.1.2 ホスト ドメイン

HTTP1.1 にはリクエスト メッセージ ヘッダーに追加のホスト ドメインがありますが、HTTP1.0 にはこのドメインがありません。

例：

GET /pub/WWW/TheProject.html HTTP/1.1

ホスト: www.w3.org

おそらく HTTP1.0 は、TCP 接続を確立するときに IP アドレスが指定されていると認識します。このアドレスにはホストが 1 つだけあります。

2.1.3 日時スタンプ

(受信方向)

HTTP1.0でもHTTP1.1でも、次の3つの日時スタンプを解析できなければなりません:

Sun, 06 Nov 1994 08 :49:37 GMT ; RFC 822、RFC 1123 によって更新されました

、RFC 1036 によって廃止されました
1994 年 11 月 6 日 08:49:37 ; () format

(送信方向)

HTTP1.0 では、3 番目の asctime 形式の日付/時刻スタンプを生成することはできません。

HTTP1.1 では、RFC 1123 (最初の) 形式の日付/時刻スタンプのみを生成する必要があります。 。

2.1.4 ステータス応答コード

ステータス応答コード 100 (続行) ステータス コードを使用すると、クライアントはリクエスト メッセージ本文を送信する前にリクエスト ヘッダーを使用してサーバーをテストし、サーバーがリクエストを受信したいかどうかを確認できます。ボディを選択し、リクエストボディを送信しないことを決定します。

クライアントはリクエストヘッダーに

Expect: 100-Continue

を含めます。サーバーがそれを確認した後、ステータスコード 100 (Continue) を返した場合、クライアントはリクエストボディの送信を続けます。これはHTTP1.1でのみ利用可能です。

さらに、HTTP/1.1では、101、203、205などのステータス応答コードも追加されました

2.1.5リクエストメソッド

HTTP1.1では、OPTIONS、PUT、DELETE、TRACE、CONNECTなどのリクエストメソッドが追加されました

メソッド = "OPTIONS" ; セクション 9.2

"GET" ;

;セクション9.9

スペース] バージョン番号 [復帰改行]

リクエスト行の例:

Eg1:

GET /index.html HTTP/1.1

Eg2:

POST http://192.168.2.217:8080/index.jsp HTTP/1.1

HTTP リクエストメッセージの例:

GET /h ello .htm HTTP/1.1

Accept: */*

Accept-Language: zh-cn

Accept-Encoding: gzip, deflate

If-Modified-Since : Wed, 17 Oct 2007 02:15:55 GMT

一致しない場合: W/"158-1192587355000"

ユーザー エージェント: Mozilla/4.0 (互換性、MSIE 6.0、Windows NT 5.1、SV1)

ホスト: 192.168 .2.162:8080

接続: Keep-Alive

2.2. 2 つのリクエスト メソッド

HTTP リクエスト メソッドには次のものが含まれます:

q GET

q POST

q HEAD

q PUT

q 削除

q OPTIONS

q TRACE

q CONNECT

2.3 HTTP 応答メッセージ

2.3.1 応答メッセージの形式

HTTP 応答メッセージの形式は次のとおりです。 | エンティティヘッダー

CRLF

エンティティコンテンツ

ここで: ステータス行 = バージョン番号 [スペース] ステータスコード [スペース] 理由 [入力と改行]

ステータス行の例:

Eg1:

HTTP/1.0 200 OK

例 2:

HTTP/1.1 400 Bad Request

HTTP 応答メッセージ 例は次のとおりです:

HTTP/1.1 200 OK

ETag: W/"158-1192590101000"

Last-Modified: Wed, 17 Oct 2007 03:01:41 GMT

Content-Type: text/html

Content-Length : 158

Date: Wed, 17 Oct 2007 03:01:59 GMT

Server: Apache-Coyote/1.1

2.3.2 http ステータス応答コード

2.3.2.1 1**: リクエストを受信しました。処理を続行します

100——クライアントはリクエストを続行する必要があります

101——クライアントはサーバに対し、リクエストに従ってHTTPプロトコルのバージョンを変換するよう要求します

2.3.2.2 2**: 操作は正常に受信、分析され、受け入れられました

200 — トランザクションは成功しました

201— — 新しいファイルの URL を知るように要求されます

202 — 受け入れられ、処理されましたが、処理はは完了していませんでした

203 — 返される情報が不確実であるか不完全です

204 — リクエストは受信されましたが、返される情報は空でした

205 — —サーバーはリクエストを完了しており、ユーザーエージェントは現在閲覧している情報をリセットする必要がありますfiles

206 —サーバーはユーザーの GET リクエストの一部を完了しました

2.3.2.3 3**: このリクエストは完了し、さらに処理する必要があります

300 - リクエストされたリソースは複数の場所で利用可能です

301 - リクエスト データを削除します

302 - リクエスト データが他のアドレスで見つかりました

303 - 顧客に他の URL またはアクセス方法にアクセスするよう提案します

304 - クライアントGET を実行しましたが、ファイルは変更されていません

305 - 要求されたリソースは、サーバーによって指定されたアドレスから取得する必要があります

306 - 以前のバージョンの HTTP で使用されていたコードは、現在のバージョンでは使用されなくなりました

307 - —リクエストされたリソースが一時的に削除されるという宣言

2.3.2.4 4**: リクエストに不正な構文が含まれているか、完了できません

400 - 構文エラーなどの不正なリクエスト

401 - 未承認

HTTP 401.1 - 未承認: ログインに失敗しました

HTTP 401.2 - 未承認: サーバー構成の問題によりログインが失敗しました

HTTP 401.3 - ACL によりリソースへのアクセスが禁止されました

HTTP 401.4 - 未承認: フィルターによって承認が拒否されました

HTTP 401.5 - 未承認: ISAPIまたはCGI認証失敗アクセスは禁止されています 書き込みアクセス

HTTP 403.4 - 禁止: SSL が必要

HTTP 403.5 - 禁止: SSL 128 が必要

HTTP 403.6 - 禁止: IP アドレスが拒否されました

HTTP 403.7 - 禁止: クライアント証明書が必要

HTTP 403.8 - 禁止: サイトへのアクセスは禁止されています

HTTP 403.9 - 禁止: 接続ユーザーが多すぎます

HTTP 403.10 - 禁止: 無効な構成

HTTP 403.11 - 禁止: パスワード変更

HTTP 403.12 - 禁止: マッパーアクセスが拒否されました

HTTP 403.13 - 禁止: クライアント証明書が取り消されました

HTTP 403.15 - 禁止: クライアントのアクセス権限が多すぎます

HTTP 403.16 - 禁止: クライアント証明書が信頼できないか無効です

HTTP 403.17 - 禁止: クライアント証明書の有効期限が切れているか、期限切れではありませんまだ有効です

404 - ファイル、クエリ、または URL が見つかりません

405 - Request-Line フィールドでユーザーが定義したメソッドは許可されていません

406 - ユーザーが送信した Accept に基づいてリソースをリクエストしますアクセスできません

407 - 401 と同様に、ユーザーは最初にプロキシ サーバーで承認される必要があります

408 - クライアントはユーザーが指定した時間内にリクエストを完了しませんでした

409 - 現在のリソース ステータスではリクエストを完了できません

410 - このリソースはサーバー上にもう存在せず、これ以上の参照アドレスはありません

411 - サーバーはユーザー定義の Content-Length 属性リクエストを拒否しました

412 - 現在のリクエスト内の 1 つ以上のリクエスト ヘッダー フィールドが正しくありません

413 - 要求されたリソースはサーバーで許可されているサイズより大きいです

414 - 要求されたリソース URL はサーバーで許可されている長さより長いです

415 - 要求されたリソースは要求された項目形式をサポートしていません

416 - リクエストRange リクエスト ヘッダー フィールドが含まれており、現在のリクエスト リソース範囲内に範囲指示値がなく、リクエストに If-Range リクエスト ヘッダー フィールドが含まれていません

417 - サーバーはリクエストの Expect ヘッダーで指定された期待を満たしていませんプロキシ サーバーの場合、次のレベルのサーバーは長い間リクエストを実行できない可能性があります。 52.3.2.5 5 **: サーバーは完全に有効なリクエストを実行しますが失敗します

HTTP 500-内部サーバーエラー

HTTP 500.100-内部サーバーエラー-ASP エラー

HTTP 500-11 サーバーを閉じる

HTTP 500-12 アプリケーションプログラム再起動

HTTP 500-13 - サーバーが忙しすぎます

HTTP 500-14 - アプリケーションが無効です

HTTP 500-15 - global.asa リクエストは許可されていません

エラー 501 - 実装されていません

HTTP 502 - ゲートウェイエラー

2.4 http テストには Telnet を使用します

Windows では、コマンド ウィンドウを使用して簡単な http テストを実行できます。

「cmd」と入力してコマンド ウィンドウに入り、コマンド ラインに次のコマンドを入力して Enter キーを押します:

ウィンドウで「Ctrl+]」を押してから を押すと、返された結果をエコー表示できます。入力 。

その後、リクエスト メッセージの送信を開始します。たとえば、Baidu のホームページ メッセージをリクエストするには、次のリクエスト メッセージを送信します。使用される HTTP プロトコルは HTTP/1.1 です:

GET /index.html HTTP/1.1

注: 上記のメッセージをコピーした後。コマンド ウィンドウへ 応答メッセージを取得するには、2 つのキャリッジ リターンとライン フィードを押す必要があります。最初のキャリッジ リターンとライン フィードは、HTTP プロトコルで必須です。 2 つ目は、入力を確認してリクエストを送信することです。

以下の図に示すように、200 OK メッセージが返されることがわかります。

HTTP/1.1 が使用されている場合、リクエストが完了しても接続が切断されていないことがわかります。 HTTP1.0 を使用する場合は、コマンド ウィンドウに次のように入力します:

GET /index.html HTTP/1.0

この時点で、リクエストは終了直後に切断されていることがわかります。

読者は、次の情報を入力するなど、GET または POST を使用するときにヘッダー情報を取得することもできます:

GET /index.html HTTP/1.1
connection: close
Host: www.baidu.com

2.5 一般的に使用されるリクエストメソッド

一般的に使用されるリクエストメソッドは GET と POST です。

l GET メソッド: リクエスト URI が単なるデータ生成の場合、そのリクエスト URI で指定されたリソースの情報を取得します。処理を実行すると、応答エンティティは最終的に次のようになります。返されるのは、処理の説明ではなく、処理の結果によって示されるリソースです。

l POST メソッド: 宛先サーバーにリクエストを発行するために使用され、リクエストに添付されたエンティティを受け入れ、それをリクエスト Post キュー内のリクエスト URI で指定されたリソースの追加の新しいサブアイテムとして扱うように要求します。このメソッドは次の機能を実装するように設計されています:

1: 既存のリソースの解釈;

2: 電子掲示板、ニュース グループ、メーリング リスト、または同様のディスカッション グループにメッセージを送信します。 ;

4: 追加の操作でデータベースを拡張します。

上記の説明から分かるように、Get はサーバーへのデータのリクエストであり、Post はサーバーへのデータの送信リクエストです。送信されるデータは、情報ヘッダーの後ろのエンティティにあります。

GET メソッドと POST メソッドには次の違いがあります:

(1) クライアント側では、Get メソッドは URL を介してデータを送信し、データは POST メソッドで確認できます。送信用の HTML ヘッダー。

(2) GET メソッドで送信できるデータは最大 1024 バイトまでですが、POST にはこの制限がありません。

(3) セキュリティの問題。 (1)で述べたように、Getを使用するとアドレスバーにパラメータが表示されますが、Postでは表示されません。したがって、データが中国語のデータで機密データではない場合は get を使用し、ユーザーが入力したデータが漢字ではなく機密データが含まれている場合は post を使用することをお勧めします。

(4) 安全で冪等。安全とは、操作が情報を変更するのではなく取得するために使用されることを意味します。冪等とは、同じ URL に対する複数のリクエストが同じ結果を返す必要があることを意味します。完全な定義は、思っているほど厳密ではありません。言い換えれば、GET リクエストには通常、副作用があってはなりません。基本的に、目標は、ユーザーがリンクを開いたときに、そのリソースが自分の観点から変更されていないことを確信できるようにすることです。たとえば、ニュース サイトのトップ ページは常に更新されます。 2 番目のリクエストは別のニュースのバッチを返しますが、常に最新のニュースを返すため、この操作は安全で冪等であると考えられます。逆に。 POST リクエストはそれほど簡単ではありません。 POST は、サーバー上のリソースを変更する可能性のあるリクエストを表します。引き続きニュース サイトを例にとると、記事に対する読者の注釈は POST リクエストを通じて実装する必要があります。これは、注釈が送信された後はサイトが異なるためです (たとえば、記事の下に注釈が表示されます)。

2.6 リクエスト ヘッダー

最も一般的な HTTP リクエスト ヘッダーは次のとおりです:

l Accept: ブラウザーが受け入れる MIME タイプ;

l Accept-Charset: ブラウザーが受け入れる文字セット。 : gzip など、ブラウザがデコードできるデータ エンコード方式。サーブレットは、gzip でエンコードされた HTML ページを gzip をサポートするブラウザに返すことができます。多くの場合、これによりダウンロード時間が 5 ～ 10 分の 1 に短縮されます。

l Accept-Language: ブラウザーが希望する言語タイプ。サーバーが複数の言語バージョンを提供できる場合に使用されます。

l Authorization: 認証情報。サーバーによって送信された WWW-Authenticate ヘッダーへの応答に表示されます。

l Connection: 永続的な接続が必要かどうかを示します。サーブレットがここの値を「Keep-Alive」と認識した場合、またはリクエストが HTTP 1.1 を使用していることを認識した場合 (HTTP 1.1 はデフォルトで永続的な接続を作成します)、ページに複数の要素 (アプレット、画像)、ダウンロードに必要な時間を大幅に短縮します。これを実現するには、サーブレットは応答で Content-Length ヘッダーを送信する必要があります。最も簡単な実装方法は、まずコンテンツを ByteArrayOutputStream に書き込み、次にコンテンツを正式に書き込む前にそのサイズを計算することです。リクエストメッセージ本文の長さ;

l Cookie: これは最も重要なリクエストヘッダー情報の 1 つです。

l From: リクエスト送信者の電子メール アドレス。一部の特別な Web クライアント プログラムによって使用されます。ブラウザで見てください;

l ホスト: 初期 URL のホストとポート。

l If-Modified-Since: 要求されたコンテンツが指定された日付以降に変更された場合にのみ返し、それ以外の場合は 304 "Not Modified" 応答を返します。プラグマ: "no-cache" 値を指定すると、サーバーがプロキシ サーバーであり、ページのローカル コピーがすでにある場合でも、更新されたドキュメントを返す必要があることを示します。

l リファラー: ユーザーが開始する URL が含まれます。現在リクエストされているページにアクセスします。

l ユーザーエージェント: ブラウザーのタイプ、この値は、サーブレットによって返されるコンテンツがブラウザーのタイプに関連している場合に非常に役立ちます。

l UA-ピクセル、UA-カラー、UA-OS、UA-CPU: いくつかのバージョン IE ブラウザによって送信される、画面サイズ、色深度、オペレーティング システム、CPU タイプを示す非標準のリクエスト ヘッダー。

2.7 応答ヘッダー

HTTP の最も一般的な応答ヘッダーは次のとおりです。

l 許可: サーバーによってサポートされているリクエスト メソッド (GET、POST など)

l コンテンツ エンコーディング:ドキュメントのエンコード（Encode）メソッド。 Content-Type ヘッダーで指定されたコンテンツ タイプは、デコード後にのみ取得できます。 gzip を使用してドキュメントを圧縮すると、HTML ドキュメントのダウンロード時間を大幅に短縮できます。 Java の GZIPOutputStream は gzip 圧縮を簡単に実行できますが、これをサポートしているのは Unix 上の Netscape と Windows 上の IE 4 および IE 5 だけです。したがって、サーブレットは、Accept-Encoding ヘッダー (つまり request.getHeader("Accept-Encoding")) を見てブラウザが gzip をサポートしているかどうかを確認し、gzip をサポートしているブラウザに対しては gzip 圧縮された HTML ページを返し、通常の HTML ページを返す必要があります。他のブラウザの HTML ページ。

l Content-Length: コンテンツの長さを示します。このデータは、ブラウザが永続的な HTTP 接続を使用する場合にのみ必要です。永続的な接続を利用したい場合は、出力ドキュメントを ByteArrayOutputStream に書き込み、完了時にそのサイズを確認し、その値を Content-Length ヘッダーに入れて、最後に byteArrayStream.writeTo(response.getOutputStream(() );

l Content-Type: 次のドキュメントがどの MIME タイプに属するかを示します。サーブレットのデフォルトは text/plain ですが、通常は Content-Type が明示的に指定される必要があるため、HttpServletResponse は専用のメソッド setContentTyep。 拡張子と MIME タイプの対応を Web で設定できます。 ドキュメントが期限切れになった場合、クライアントは If- 経由で日付を指定できます。 Modified-Since リクエスト ヘッダーは GET 条件とみなされ、変更時間が指定された時間より後のドキュメントのみが返されます。それ以外の場合は、Last-Modified ステータスを設定することもできます。 setDateHeader メソッド;

l Location: 顧客がドキュメントを取得するためにどこに行くべきかを示します。通常は、HttpServletResponse の sendRedirect メソッドを通じて設定されます。これにより、ステータス コードも 302 に設定されます。現在のドキュメントを更新することに加えて、ブラウザがドキュメントを更新する時間を秒単位で指定します。 setHeader("Refresh", "5; URL=http://host/path") を使用してブラウザに指定されたページを読み取らせることもできます。 ) この機能は通常、HTML ページの HEAD 領域に -EQUIV="Refresh" CONTENT="5;URL=http://host/path" を使用しているかどうかに関係なく、ブラウザーが更新を継続できなくなる可能性があります。 Refresh ヘッダーは公式の HTTP 1.1 仕様の一部ではなく拡張機能ですが、Netscape と IE の両方がサポートしていることに注意してください。

2.8 エンティティ ヘッダー

エンティティ ヘッダーは、エンティティ コンテンツのメタ情報を使用して、エンティティ情報の種類、長さ、圧縮方法、最終変更時刻、データの有効性など、エンティティ コンテンツの属性を記述します。

l 許可: GET、POST

l Content-Encoding: ドキュメントのエンコード (Encode) 方法、例: gzip、「2.5 応答ヘッダー」を参照

l Content-Language: コンテンツの言語タイプ、例: zh-cn ;

l Content-Length: コンテンツの長さを示します。例: 80。「2.5 応答ヘッダー」を参照してください。

l Content-Location: 顧客がドキュメントを取得するためにどこに行くべきかを示します。例: http://www.dfdf.org/dfdf.html、「2.5 応答ヘッダー」を参照してください。

l Content-MD5: チェックサムとして使用される MD5 エンティティの MD5 ダイジェスト。送信者と受信者の両方が MD5 ダイジェストを計算し、受信者はその計算値とこのヘッダーで渡された値を比較します。例1: コンテンツ-MD5: 。例 2: dfdfdfdfdfdfdff==;

l Content-Range: いくつかのエンティティと一緒に送信され、挿入されたバイトの下位バイト オフセットと上位バイト オフセットを示し、このエンティティの合計長も示します。例1: Content-Range: 1001-2000/5000、例2: バイト2543-4532/7898

l Content-Type: 送受信されるエンティティのMIMEタイプを示します。例: text/html; charset=GB2312 メインタイプ/サブタイプ;

l Expires: 0 はキャッシュがないことを証明します。

l Last-Modified: WEB サーバーは、オブジェクトの最終変更時刻を考慮します。ファイル、動的 ページが最後に生成された時刻など。例: Last-Modified: Tue, 06 May 2008 02:42:43 GMT.

2.8 拡張ヘッダー

HTTP メッセージでは、HTTP1.1 公式仕様で定義されていない一部のヘッダー フィールドも使用できます。ヘッダー フィールド カスタム HTTP ヘッダーまたは拡張ヘッダーと総称され、通常はエンティティ ヘッダーの一種として扱われます。

現在、一般的なブラウザは、Cookie、Set-Cookie、Refresh、Content-Disposition など、一般的に使用されるいくつかの拡張ヘッダー フィールドを実際にサポートしています。

l Refresh: 1; url=http://www.dfdf.org // 1 秒後に指定された場所にジャンプします。

l Content-Disposition: ヘッダー フィールド、「2.5 応答ヘッダー」を参照してください。 l Content-Type: WEB サーバーはブラウザに応答するオブジェクトのタイプを伝えます。

eg1: コンテンツタイプ: application/xml;

eg2: アプリケーション/octet-stream;

Content-Disposition: ファイル名 = aaa.zip。

付録:参考資料

「HTTP1.1とHTTP1.0の違い」:

http://blog.csdn.net/yanghehong/archive/2009/05/28/4222594.aspx

「HTTPリクエスト」 ( GET と POST の違い) とレスポンス》：

http://www.blogjava.net/honeybee/articles/164008.html

《HTTP リクエスト ヘッダーの概要_Baidu Knows》：

http://zhidao. baidu .com/question/32517427.html

「エンティティ ヘッダーと拡張ヘッダー」:

http://www.cnblogs.com/tongzhiyong/archive/2008/03/16/1108776.html

3.深さの理解

3.1 Cookie と Session

Cookie と Session はどちらも状態情報を保存するために使用され、どちらも HTTP のステートレス問題を解決するための仕組みです。

セッションは、Cookie または URL ライトバック メカニズムを使用して実装できます。 Cookie を使用して実装されたセッションは、Cookie のより高度なアプリケーションと考えることができます。

3.1.1 2 つの比較

Cookie とセッションには次の明らかな違いがあります:

1) Cookie はクライアント側で状態を保存し、セッションはサーバー側で状態を保存します

2) Cookie は保存されます。サーバーのローカル マシン上 サーバーに保存され、リクエストごとに同じサーバーに送信される小さなテキスト。 Cookie は RFC2109 で最初に実装され、その後 RFC2965 で拡張されました。 Web サーバーは、HTTP ヘッダーを使用してクライアントに Cookie を送信し、ブラウザはこれらの Cookie を解析し、同じサーバーへのリクエストに自動的に添付します。セッションは HTTP プロトコルで定義されません。

3) 変数の値はサーバーに保存され、どのユーザーのセッション変数であるかを識別します。クライアントが Cookie を無効にすると、この値がサーバーに返されるように設定されます。

4) セキュリティの観点から: セッションを使用するサイトにアクセスすると、 Cookie を作成するには、クライアントによって保存された情報を勝手に読み取らないようにするため、サーバー側の SESSION メカニズムをより安全にすることをお勧めします。

3.1.2 セッションメカニズム

セッションメカニズムは、サーバー側のメカニズムであり、ハッシュテーブルに似た構造を使用して情報を保存します。

プログラムがクライアントのリクエストに対してセッションを作成する必要がある場合、サーバーはまずクライアントのリクエストにセッション ID と呼ばれるセッション識別子が既に含まれているかどうかを確認します。セッション ID が既に含まれている場合は、このクライアントが以前に作成されたことを意味します。クライアントがセッションを作成している場合、サーバーはセッション ID に従ってセッションを取得し、それを使用します (取得できない場合は、クライアントのリクエストにセッション ID が含まれていない場合は、新しいセッションを作成する可能性があります)。セッションに関連付けられたセッション ID の値は、反復的でなく、偽造するパターンが容易ではない文字列である必要があります。このセッション ID はクライアントに返されます。この応答に保存されます。

3.1.6 セッションの実装方法

3.1.6.1 Cookieを使用して実装します

サーバーは各セッションに一意のJSESSIONIDを割り当て、Cookieを通じてクライアントに送信します。

クライアントが新しいリクエストを開始すると、この JSESSIONID が Cookie ヘッダーに含まれます。このようにして、サーバーはクライアントに対応するセッションを見つけることができます。

そのプロセスを以下の図に示します:

3.1.6.2 URL エコーを使用して実現します

URL ライトバックとは、サーバーがブラウザ ページに送信されるすべてのリンクに JSESSIONID パラメータを保持することを意味し、クライアントがクリックすることを意味します。どのリンクでも JSESSIONID がサーバーに送信されます。

サーバーリソースのURLをブラウザに直接入力してリソースをリクエストした場合、セッションは照合されません。

Tomcat の Session 実装は、最初に Cookie と URL ライトバック メカニズムの両方を使用します。クライアントが Cookie をサポートしていることが判明した場合、引き続き Cookie を使用し、URL ライトバックの使用を停止します。 Cookie が無効になっている場合は、必ず URL ライトバックを使用してください。 JSP 開発でセッションを処理するときは、ページ内のリンクに必ず response.encodeURL() を使用してください。

3.1.3 J2EE プロジェクトにおけるセッション障害のいくつかの状況

1) セッションタイムアウト: セッションは指定された時間内に期限切れになります (例: 30 分)。Web などで 30 分以内に操作がない場合、セッションは期限切れになります。次の設定は XML で行われます:

()セッションを明示的に削除します。

3.1.4 Cookie に関連する HTTP 拡張ヘッダー

1) Cookie: クライアントはサーバーによって設定された Cookie をサーバーに返します。

2) Set-Cookie: サーバーはクライアントに Cookie を設定します。 ) Cookie2 (RFC2965)): クライアントはサーバーに Cookie のバージョンをサポートするように指示します。

4) Set-Cookie2 (RFC2965): サーバーは Cookie をクライアントに設定します。

3.1.5 Cookie プロセス

サーバーは応答メッセージの Set-Cookie ヘッダーを使用して Cookie コンテンツをクライアントに送り返し、クライアントは同じコンテンツを Cookie ヘッダーに含めてサーバーに送信します。新しいリクエスト。これにより、セッションを維持できるようになります。

プロセスは以下の図に示されています:

3.2 キャッシュの実装原理

3.2.1 Webキャッシュとは

WEBキャッシュ(キャッシュ)はWebサーバーとクライアントの間に位置します。

キャッシュは、HTML ページ、画像、ファイルなどの出力コンテンツのコピーをリクエストに保存します。次のリクエストが来たとき、同じ URL の場合、キャッシュはそのコピーを直接使用して応答します。リクエストをソースサーバーに再度送信する代わりに、アクセスリクエストを送信します。

HTTP プロトコルは、WEB キャッシュが可能な限り適切に機能するように、関連するメッセージ ヘッダーを定義します。

3.2.2 キャッシュの利点

q 応答遅延の短縮: リクエストはオリジンサーバーではなくキャッシュサーバー (クライアントに近い) から応答されるため、このプロセスにかかる時間が短縮され、Web サーバーの応答が速くなったように見えます。

q ネットワーク帯域幅消費の削減: レプリカが再利用されると、クライアントの帯域幅消費量が削減され、顧客は帯域幅コストを節約し、帯域幅要件の増加を制御し、管理が容易になります。

3.2.3 キャッシュに関連するHTTP拡張メッセージヘッダー

q Expires: 応答コンテンツの有効期限を示します(グリニッジ標準時GMT)

q Cache-Control: キャッシュされたコンテンツをより詳細に制御します

q Last-Modified :応答内のリソースが最後に変更された時刻

q ETag: 応答内のリソースのチェック値。サーバー上で一定期間内に一意に識別されます。

q 日付: サーバー時刻

q If-Modified-Since: クライアントがアクセスしたリソースが最後に変更された時刻 (Last-Modified と同じ)。

q If-None-Match: クライアントがアクセスしたリソースのチェック値。ETag と同じです。

3.2.4 クライアントキャッシュを有効にするための共通プロセス

サーバーがリクエストを受信すると、200OK でリソースの Last-Modified ヘッダーと ETag ヘッダーを送り返します。クライアントはリソースをキャッシュに保存し、記録します。これら 2 つの属性です。クライアントが同じリクエストを送信する必要がある場合、リクエスト内に If-Modified-Since と If-None-Match という 2 つのヘッダーが含まれます。 2 つのヘッダーの値は、応答の Last-Modified ヘッダーと ETag ヘッダーの値です。サーバーは、これら 2 つのヘッダーによってローカル リソースが変更されていないと判断し、クライアントはそれを再度ダウンロードする必要がなく、304 応答を返します。共通のプロセスを以下の図に示します。

3.2.5 Web キャッシュのメカニズム

HTTP/1.1 でのキャッシュの目的は、多くの場合、リクエストの送信を減らすことであり、多くの場合、リクエストを送信する必要はありません。完全な応答。前者はネットワーク ループの数を減らします。HTTP はこの目的で「有効期限」メカニズムを利用します。後者はネットワーク アプリケーションの帯域幅を削減します。HTTP はこの目的で「検証」メカニズムを使用します。

HTTP は 3 つのキャッシュ メカニズムを定義します:

1) 鮮度: 応答メッセージをソース サーバーで再チェックできるようにし、サーバーとクライアントによって制御できます。たとえば、Expires 応答ヘッダーは、ドキュメントが利用できなかった時間を示します。 Cache-Control の max-age フラグは、最大キャッシュ時間を示します。

2) 検証: キャッシュされた応答がまだ利用可能かどうかを確認するために使用されます。たとえば、応答に Last-Modified 応答ヘッダーがある場合、キャッシュは If-Modified-Since を使用して変更されたかどうかを判断し、状況に応じてリクエストを送信するかどうかを決定できます。3) 無効化:別のリクエストがキャッシュを通過すると、多くの場合、副作用が発生します。たとえば、URL がキャッシュされた応答に関連付けられているが、その後に POST、PUT、および DELETE リクエストが続く場合、キャッシュは期限切れになります。

3.3 ブレークポイント再開とマルチスレッドダウンロードの実装原理

q HTTP プロトコルの GET メソッドは、リソースの特定の部分のみのリクエストをサポートします

q 206 Partial Content 部分コンテンツ応答

q リクエストされたリソースの範囲。範囲;

q Content-Range 応答のリソース範囲;

q 接続が切断されて再接続されると、クライアントはブレークポイント再開を達成するためにリソース全体を再要求するのではなく、リソースの未ダウンロードの部分のみを要求します。

ブロックされたリクエストリソースの例:

Eg1: Range: bytes=306302-: 306302 bytesからこのリソースの末尾までの部分をリクエストします。

Eg2: Content-Range: bytes 306302-604047/604048: 応答に示されます。これはリソースの 306302 ～ 604047 バイトを伝送し、リソースには合計 604048 バイトがあります。クライアントは、同じリソースの異なるフラグメントを同時に要求することで、特定のリソースの同時ブロック ダウンロードを実現します。高速ダウンロードの目的を達成するため。現在普及している FlashGet と Thunder は基本的にこの原理を使用しています。

マルチスレッド ダウンロードの原理:

q ダウンロード ツールは、HTTP リクエストを発行する複数のスレッドを開きます。

q 各 http リクエストは、リソース ファイルの一部のみをリクエストします。 Content-Range: バイト 20000-40000/47000。

q 各スレッドでダウンロードしたファイルを結合します。

3.4 https通信プロセス

3.4.1 https

とは HTTPS (正式名: Hypertext Transfer Protocol over Secure Socket Layer) は、簡単に言えば、セキュリティを目的とした HTTP チャネルです。つまり、HTTP に SSL 層が追加されています。HTTPS のセキュリティ基盤は SSL です。暗号化の詳細については、「SSL」を参照してください。

下の図を参照してください:

httpsで使用されるポート番号は443です。

3.4.2 https

の実装原理 暗号化および復号化アルゴリズムには 2 つの基本的なタイプがあります:

1) 対称暗号化: キーは 1 つだけあり、暗号化と復号化は同じパスワードであり、暗号化と復号化の速度は異なります。高速であり、一般的な対称暗号化アルゴリズムには DES、AES などが含まれます

2) 非対称暗号化: 鍵はペアで表示されます (秘密鍵は公開鍵に基づいて推測できず、公開鍵は公開鍵に基づいて推測できません)。秘密鍵）、暗号化と復号化に異なる鍵が使用されます（公開鍵暗号化には秘密鍵復号化が必要であり、秘密鍵暗号化には公開鍵復号化が必要です）。一般的な非対称暗号化アルゴリズムには、RSA、DSA などが含まれます。

https の通信プロセスを見てみましょう:

https 通信の利点:

1) クライアントによって生成されたキーはクライアントとサーバーのみが取得できます

2) 暗号化されたキーデータはクライアントとサーバーのみが取得できます。 サーバー側のみがクリア テキストを取得できます

3) クライアントからサーバーへの通信は安全です。

3.5 http プロキシ

3.5.1 http プロキシ サーバー

プロキシ サーバーの英語の正式名は Proxy Server で、その機能はネットワーク ユーザーがネットワーク情報を取得するためのプロキシとして機能することです。比喩的に言えば、ネットワーク情報の転送ステーションです。

プロキシサーバーは、ブラウザとWebサーバーの間にあるサーバーであり、ブラウザはWebページを取得するためにWebサーバーに直接アクセスするのではなく、リクエスト信号をプロキシサーバーに送信します。最初にプロキシサーバーを使用すると、プロキシサーバーはブラウザーに必要な情報を取得してブラウザーに送信します。

さらに、ほとんどのプロキシ サーバーには、大きなキャッシュと同様のバッファリング機能があり、ブラウザが要求したデータはローカル メモリにすでに存在しており、そのデータは自身のメモリに継続的に保存されます。最新の場合は、Web サーバーからデータを再取得せず、メモリ内のデータをユーザーのブラウザに直接送信するため、閲覧速度と効率が大幅に向上します。

さらに重要なこと: プロキシ サーバー (プロキシ サーバー) は、インターネット リンク レベルのゲートウェイによって提供される重要なセキュリティ機能であり、主にオープン システム相互接続 (OSI) モデルの会話層で機能します。

3.5.2 http プロキシサーバーの主な機能

主な機能は次のとおりです:

1) 独自の IP アクセス制限を突破して、海外サイトにアクセスします。例: Education Network や 169 Network などのインターネット ユーザーは、プロキシ経由で外国の Web サイトにアクセスできます

2) 大学の FTP など、一部のユニットまたはグループの内部リソースにアクセスします (プロキシ アドレスが許可されたアクセス範囲内にある場合)。リソースの)、教育ネットワークのアドレス セグメントで無料のプロキシ サーバーを使用すると、教育ネットワークにオープンなさまざまな FTP ダウンロードとアップロード、およびさまざまなデータ クエリと共有サービスに使用できます

3) ブレークChina Telecom の IP ブロックによる: China Telecom には多くのユーザーがいます。Web サイトへのアクセスは制限されており、この制限はサーバーによってアドレスのブロック方法が異なります。したがって、アクセスできない場合は、外部プロキシ サーバーを試してください。

4) アクセス速度の向上: 通常、プロキシ サーバーは、外部情報が通過するときに、より大きなハードディスク バッファを設定します。 、他のユーザーが同じ情報に再びアクセスすると、アクセス速度を向上させるために情報がバッファから直接取り出され、ユーザーに渡されます

5) 本当の IP を隠す: インターネット ユーザーは、この方法の IP を使用して自分自身を隠すこともできます。 、攻撃から保護されます。

3.5.3 http プロキシ アイコン

http プロキシ アイコンを以下に示します:

クライアントブラウザの場合、httpプロキシサーバーはサーバーに相当します。

Web サーバーの場合、http プロキシ サーバーがクライアントの役割を果たします。

3.6 仮想ホストの実装

3.6.1 仮想ホストとは

仮想ホスト: ユーザーがサイトやアプリケーションコンポーネントなどを配置できるようにネットワークサーバー上の一定のディスクスペースを分割し、必要なサイト機能とデータ転送機能。

いわゆる仮想ホストは、「ウェブサイト空間」とも呼ばれ、インターネット上で実行されているサーバーを複数の「仮想」サーバーに分割するもので、各仮想ホストは独立したドメイン名と完全なインターネット サーバー (WWW、FTP をサポート) を持ちます。 、電子メールなど）機能を備えています。サーバー上のさまざまな仮想ホストは独立しており、ユーザーによって管理されます。ただし、サーバー ホストがサポートできる仮想ホストの数は、この数を超えると急激に低下します。

3.6.2 バーチャルホストの実装原理

バーチャルホストとは、同一のWEBサーバーを利用して、異なるドメイン名のWebサイトにサービスを提供する技術です。 ApacheやTomcatなどは設定によりこの機能を実現できます。

関連する HTTP メッセージ ヘッダー: ホスト。

例: Host: www.baidu.com

クライアントが HTTP リクエストを送信すると、Host ヘッダーにはクライアントが入力したドメイン名が記録されます。このようにして、サーバーは、クライアントがどのドメイン名にアクセスしたいのかを Host ヘッダーに基づいて確認できます。

付録: 参考文献

「Cookie とセッションのメカニズムについて」:

http://sumongh.javaeye.com/blog/82498

「HTTP プロトコルの簡単な分析」:

http://203.208.39.132 / search?q=cache:CdXly_88gjIJ:www.cnblogs.com/gpcuster/archive/2009/05/25/1488749.html+http%E5%8D%8F%E8%AE%AE+web%E7%BC%93 % E5%AD%98&cd=27&hl=zh-CN&ct=clnk&gl=cn&st_usg=ALhdy2-vzOcP8XTG1h7lcRr2GJrkTbH2Cg

"http proxy_Baidu 百科事典":

http://baike.baidu.com/view/1159398.htm

"仮想ホスト_Baidu百科事典》：

http://baike.baidu.com/view/7383.htm

《https_百度百科事典》：