HTTPプロトコルの詳細な説明（本当に古典的）
- 高洛峰オリジナル
- 2016-12-12 11:08:071061ブラウズ
はじめに
HTTP は、アプリケーション層に属するオブジェクト指向プロトコルであり、そのシンプルかつ高速なメソッドにより、分散ハイパーメディア情報システムに適しています。 1990 年に提案され、数年間の使用と開発を経て継続的に改良と拡張が行われてきました。現在、WWW では 6 番目のバージョンの HTTP/1.0 が使用されており、HTTP/1.1 の標準化作業が進行中であり、HTTP-NG (Next Generation of HTTP) 提案が提案されています。
HTTP プロトコルの主な機能は次のように要約できます:
1. クライアント/サーバー モードをサポートします。
2. シンプルかつ高速: クライアントがサーバーにサービスをリクエストする場合、リクエストのメソッドとパスを送信するだけで済みます。一般的に使用されるリクエスト メソッドは、GET、HEAD、および POST です。各メソッドは、クライアントとサーバー間の異なるタイプの接続を指定します。 HTTP プロトコルは単純であるため、HTTP サーバーのプログラム サイズは小さく、通信速度は非常に高速です。
3. 柔軟性: HTTP では、あらゆる種類のデータ オブジェクトの送信が可能です。転送されるタイプは Content-Type によってマークされます。
4. 接続なし: 接続なしの意味は、各接続が 1 つのリクエストのみを処理するように制限することです。サーバーはクライアントの要求を処理し、クライアントの応答を受信した後、切断します。この方法により、送信時間が節約されます。
5. ステートレス: HTTP プロトコルはステートレス プロトコルです。ステートレスとは、プロトコルにトランザクション処理のためのメモリ機能がないことを意味します。ステータスがないということは、後続の処理で以前の情報が必要な場合にその情報を再送信する必要があることを意味し、その結果、接続ごとに転送されるデータ量が増加する可能性があります。一方、事前の情報が必要ない場合、サーバーはより速く応答します。
1. URL 章 HTTP プロトコルの詳細な説明
HTTP (Hypertext Transfer Protocol) は、要求および応答モードに基づくステートレスなアプリケーション層プロトコルであり、多くの場合、TCP 接続方法、HTTP バージョン 1.1 に基づいています。継続的な接続メカニズムは次のとおりです。ほとんどの Web 開発は、HTTP プロトコルに基づいて構築された Web アプリケーションです。
HTTP URL (URL は、リソースを見つけるのに十分な情報を含む特別なタイプの URI) の形式は次のとおりです:
http://host[":"port][abs_path]
http は、ネットワーク リソースを検索することを意味します。 HTTP プロトコル。host は、正当なインターネット ホストのドメイン名または IP アドレスを表します。port は、URL に abs_path が指定されていない場合、デフォルトのポート 80 を指定します。リクエスト URI として使用する場合は、「/」の形式で指定する必要があります。通常、これはブラウザーが自動的に行います。
例:
1. www.guet.edu.cn と入力します。ブラウザは自動的に http://www.guet.edu.cn/
2 http:192.168.0.116:8080/index.jsp に変換します。
Method はリクエスト メソッドを表し、HTTP-Version はリクエストされた HTTP プロトコル バージョンを表します。および改行 (末尾の CRLF を除き、単一の CR または LF 文字は許可されません)。
リクエストメソッドは多数あります(メソッドはすべて大文字) それぞれのメソッドの説明は次のとおりです:
GET Request-URIで特定されるリソースの取得リクエスト
HEAD リクエスト Request-URI で識別されるリソースの応答メッセージ ヘッダーを取得します
PUT リソースを保存し、その識別子として Request-URI を使用するようにサーバーにリクエストします
DELETE サーバーに Request-URI で識別されるリソースを削除するようにリクエストします
TRACE リクエスト受信したリクエスト情報を送り返すサーバー。主にテストまたは診断に使用されます
CONNECT 将来の使用のために予約されています
OPTIONS サーバーのパフォーマンスをクエリする、またはリソースに関連するオプションと要件をクエリするリクエスト
アプリケーション例:
GET メソッド:ブラウザのアドレス バーに URL を入力して、Web ページにアクセスします。 ブラウザが GET メソッドを使用してサーバーからリソースを取得する場合、例: GET /form.html HTTP/1.1 (CRLF)
POST メソッドには、要求されたサーバーが必要ですリクエストに添付されたデータを受け入れるためのもので、フォームの送信によく使用されます。
例：POST /reg.jsp HTTP/ (CRLF)
...
HOST:www.guet.edu.cn (CRLF)
Content-Length:22 (CRLF)
Connection:Keep-Alive (CRLF)
Cache-Control:no-cache (CRLF)
(CRLF) //この CRLF は、メッセージ ヘッダーが終了する前にメッセージが終了したことを示しますheader
user =jeffrey&pwd=1234 //次の行は送信されたデータです
HEAD メソッドは GET メソッドとほぼ同じです。HEAD リクエストの応答部分については、HTTP ヘッダーに含まれる情報は同じです。 GET リクエストで取得したメッセージと同じです。この方法を使用すると、リソースの内容全体を送信することなく、Request-URI で識別されるリソースに関する情報を取得できます。この方法は、ハイパーリンクの有効性、アクセス可能かどうか、最近更新されたかどうかをテストするためによく使用されます。
2. リクエストヘッダーの説明は後ほど
3. HTTPプロトコルの詳細な説明付き
リクエスト メッセージを受信して解釈した後、サーバーは HTTP レスポンス メッセージを返します。
HTTP 応答も、ステータス行、メッセージ ヘッダー、応答本文の 3 つの部分で構成されます
1。ステータス行の形式は次のとおりです:
HTTP-Version Status-Code Reason-Phrase CRLF
そのうち、HTTP-Versionサーバー HTTP を表します。プロトコルのバージョンを表します。Status-Code は、サーバーから返された応答ステータス コードを表します。Reason-Phrase は、ステータス コードのテキストの説明を表します。
ステータス コードは 3 桁で構成され、最初の数字は応答のカテゴリを定義し、可能な値は 5 つあります。
1xx: 指示情報 -- リクエストが受信され、処理が継続されていることを示します。
2xx: 成功 -- を示します。リクエストが処理されたこと 正常に受信、理解、受け入れられたこと
3xx: リダイレクト -- リクエストを完了するにはさらに操作を実行する必要があります
4xx: クライアント側エラー -- リクエストに構文エラーがあるか、リクエストを実行できません
5xx : サーバー側エラー - サーバーはリクエストを実行できませんでした 正当なリクエスト
共通のステータス コード、ステータスの説明、説明:
200 OK //クライアント リクエストは成功しました
400 Bad Request //クライアント リクエストには構文エラーがあるため、リクエストを実行できませんサーバーによって理解される
401 Unauthorized //リクエストは承認されていません。このステータスコードはWWW-Authenticateヘッダーフィールドと一緒に使用する必要があります
403 Forbidden //サーバーはリクエストを受信しましたが、サービスの提供を拒否しました
404 Not Found //要求されたリソースが存在しません。例: 間違った URL が入力されました
500 Internal Server Error / /サーバーで予期しないエラーが発生しました
503 Server Unavailable //サーバーは現在クライアントのリクエストを処理できず、返される可能性があります一定の時間が経過すると通常に戻ります
例: HTTP/1.1 200 OK (CRLF)
2. 応答ヘッダーについては後述します
3. 応答本文はサーバーから返されるリソースの内容です
4. . HTTPプロトコルの詳しい説明 - メッセージヘッダー
HTTPメッセージは、クライアントからサーバーへのリクエストと、サーバーからクライアントへのレスポンスで構成されます。要求メッセージと応答メッセージはどちらも開始行 (要求メッセージの場合は開始行が要求行、応答メッセージの場合は開始行がステータス行)、メッセージ ヘッダー (オプション)、空行 (CRLF のみ) で構成されます。行）、メッセージ本文（オプション）の構成。
HTTP メッセージ ヘッダーには、通常のヘッダー、リクエスト ヘッダー、レスポンス ヘッダー、エンティティ ヘッダーが含まれます。
各ヘッダー フィールドは、名前 + ":" + スペース + 値で構成されます。メッセージ ヘッダー フィールドの名前は、大文字と小文字が区別されません。
1. 通常のヘッダー
例:
Cache-Control は、キャッシュ命令を指定するために使用されます。キャッシュ命令は一方向であり (応答に表示されるキャッシュ命令はリクエストに表示されない場合があります)、独立しています (1 つのメッセージのキャッシュ命令は影響しません)。別のメッセージ) 処理のためのキャッシュ メカニズム)、HTTP 1.0 で使用される同様のヘッダー フィールドは Pragma です。
リクエスト時のキャッシュ ディレクティブには、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、s-maxage
例: IE ブラウザ (クライアント) にキャッシュしないように指示する場合ページのサーバー側 JSP プログラムは次のように記述できます。この関数は上記のコードと同等です。通常は // 両方が一緒に使用されます
このコードは、送信される応答メッセージの共通ヘッダー フィールドを設定します: Cache-Control: no-cache
Date 共通ヘッダー フィールドは日付と時刻を示しますメッセージが生成されるとき
2. リクエスト ヘッダー
リクエスト ヘッダーを使用すると、クライアントはリクエストの追加情報とクライアント自身の情報をサーバーに渡すことができます。
一般的に使用されるリクエスト ヘッダー
Accept
Accept リクエスト ヘッダー フィールドは、クライアントが受け入れる情報の種類を指定するために使用されます。例: Accept: image/gif、クライアントが GIF 画像形式のリソースを受け入れたいことを示します。Accept: text/html、クライアントが HTML テキストを受け入れたいことを示します。
Accept-Charset
Accept-Charset リクエスト ヘッダー フィールドは、クライアントが受け入れる文字セットを指定するために使用されます。例: Accept-Charset:iso-8859-1、gb2312 このフィールドが要求メッセージに設定されていない場合、デフォルトでは任意の文字セットが受け入れられます。
Accept-Encoding
Accept-Encoding リクエスト ヘッダー フィールドは Accept と似ていますが、許容可能なコンテンツ エンコーディングを指定するために使用されます。例: Accept-Encoding:gzip.deflate このドメインがリクエスト メッセージに設定されていない場合、サーバーはクライアントがさまざまなコンテンツ エンコーディングを受け入れることができると想定します。
Accept-Language
Accept-Language リクエスト ヘッダー フィールドは Accept と似ていますが、自然言語を指定するために使用されます。例: Accept-Language:zh-cn このヘッダー フィールドがリクエスト メッセージに設定されていない場合、サーバーはクライアントがさまざまな言語を受け入れることができると想定します。
Authorization
Authorization リクエスト ヘッダー フィールドは主に、クライアントが特定のリソースを表示する権利を持っていることを証明するために使用されます。ブラウザがページにアクセスし、サーバーから応答コード 401 (Unauthorized) を受信すると、Authorization リクエスト ヘッダー フィールドを含むリクエストを送信して、サーバーに検証を依頼できます。
ホスト (このヘッダー フィールドはリクエストを送信するときに必要です)
ホスト リクエスト ヘッダー フィールドは主に、リクエストされたリソースのインターネット ホストとポート番号を指定するために使用されます。通常、HTTP URL から抽出されます。例:
ブラウザを使用します。次のように入力します: http://www.guet.edu.cn/index.html
ブラウザによって送信されるリクエスト メッセージには、次のようなホスト リクエスト ヘッダー フィールドが含まれます:
ホスト: www.guet.edu.cn
ここでは、デフォルトのポート番号は 80 です。ポート番号を指定すると、次のようになります。 ホスト: www.guet.edu.cn: ポート番号を指定します
ユーザー エージェント
オンライン フォーラムにログインすると、いくつかのウェルカム メッセージが表示されることがよくあります。これには、使用しているオペレーティング システムの名前とバージョン、および使用しているブラウザの名前とバージョンがリストされます。実際、サーバー アプリケーションはこの情報を User-Agent リクエスト ヘッダー フィールドから取得します。 。 User-Agent リクエスト ヘッダー フィールドを使用すると、クライアントはサーバーにオペレーティング システム、ブラウザ、およびその他の属性を伝えることができます。ただし、ブラウザを自分で作成し、User-Agent リクエスト ヘッダー フィールドを使用しない場合、このヘッダー フィールドは必要ありません。サーバーはその情報を知ることができません。
リクエストヘッダーの例:
GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel, application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 2007 年 1 月 11:21:25 GMT (CRLF)
If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)
ユーザー エージェント:Mozilla/4.0(互換性;MSIE6.0;Windows NT 5.0) (CRLF)
ホスト:www.guet.edu.cn (CRLF)
接続:Keep-Alive (CRLF)
(CRLF)
3. 応答ヘッダー
応答ヘッダーを使用すると、サーバーは、ステータス行、およびサーバーに関する情報と、Request-URI によって識別されるリソースへのさらなるアクセスに関する情報。
一般的に使用される応答ヘッダー
Location
Location 応答ヘッダー フィールドは、受信者を新しい場所にリダイレクトするために使用されます。 Location 応答ヘッダー フィールドは、ドメイン名を変更するときによく使用されます。
サーバー
サーバー応答ヘッダー フィールドには、サーバーがリクエストを処理するために使用するソフトウェアに関する情報が含まれています。 User-Agent リクエスト ヘッダー フィールドに対応します。以下は、
Server 応答ヘッダー フィールドの例です。
Server: Apache-Coyote/1.1
WWW-Authenticate
WWW-Authenticate 応答ヘッダー フィールドは 401 (Unauthorized) 応答メッセージに含める必要があり、クライアントは 401 応答を受信しますメッセージを送信し、Authorization ヘッダー フィールドを送信してサーバーに検証を要求すると、サーバーの応答ヘッダーにはこのヘッダー フィールドが含まれます。
例: WWW-Authenticate:Basic realm="Basic Auth Test!" //サーバーがリソースの要求に基本的な検証メカニズムを使用していることがわかります。
4. エンティティ ヘッダー
リクエスト メッセージとレスポンス メッセージの両方でエンティティを送信できます。エンティティはエンティティ ヘッダー フィールドとエンティティ本文で構成されますが、エンティティ ヘッダー フィールドとエンティティ本文を一緒に送信する必要があるという意味ではありません。エンティティ ヘッダーは、エンティティ本体に関するメタ情報 (例: エンティティ本体の有無) とリクエストによって識別されるリソースを定義します。
一般的に使用されるエンティティ ヘッダー
Content-Encoding
Content-Encoding エンティティ ヘッダー フィールドは、メディア タイプの修飾子として使用され、その値はエンティティ本体に適用された追加コンテンツのエンコーディングを示します。で参照されるメディア タイプは、対応するデコード メカニズムを使用する必要があります。 Content-Encoding は、ドキュメントの圧縮方法を記録するために使用されます。例: Content-Encoding: gzip
Content-Language
Content-Language エンティティ ヘッダー フィールドは、リソースで使用される自然言語を記述します。このフィールドが設定されていない場合、エンティティ コンテンツはすべての言語の読者に利用可能であると想定されます。例: Content-Language:da
Content-Length
Content-Length エンティティ ヘッダー フィールドは、エンティティ本体の長さを示すために使用され、バイト単位で格納された 10 進数として表されます。
Content-Type
Content-Type エンティティ ヘッダー フィールドの用語は、受信者に送信されるエンティティ本文のメディア タイプを示します。例:
Content-Type: text/html; charset=ISO-8859-1
Content-Type: text/html; charset=GB2312
Last-Modified
Last-Modified エンティティ ヘッダー フィールドは、エンティティの最終変更日を示すために使用されます。リソースと時間。
Expires
Expires エンティティ ヘッダー フィールドは、応答の有効期限が切れる日時を示します。プロキシ サーバーまたはブラウザが一定期間後にキャッシュ内のページを更新できるようにするには (以前にアクセスしたページに再度アクセスするときは、そのページをキャッシュから直接ロードして、応答時間を短縮し、サーバーの負荷を軽減します)、次のことができます。 Expires エンティティ ヘッダー フィールドを使用して、ページの有効期限を指定します。例: Expires: Thu, 15 Sep 2006 16:23:12 GMT
HTTP 1.1 のクライアントとキャッシュは、他の不正な日付形式 (0 を含む) を期限切れとして扱う必要があります。例: ブラウザーがページをキャッシュしないようにするには、Expires エンティティ ヘッダー フィールドを使用して、それを 0 に設定することもできます。JSP のプログラムは次のとおりです: response.setDateHeader("Expires","0");
MS の Telnet ツールを使用して、http リクエスト情報を手動で入力してサーバーにリクエストを送信します。サーバーはリクエストを受信し、解釈して受け入れます。応答が返され、Telnet ウィンドウに表示されます。これにより、http プロトコルの通信プロセスを知覚的な観点から理解できます。
1.1 telnet を開く
-->cmd-->telnet を開く
localecho を設定する
2.1 open www.guet.edu.cn 80 //ポート番号は省略できないので注意
Host:www.guet.edu.cn
/*リクエストは変更可能メソッドを使用して桂林電子ホームページのコンテンツを要求し、次のようにメッセージを入力します*/
open www.guet.edu.cn 80
GET /index.asp HTTP/1.0 //要求されたリソースのコンテンツ
Host:www. guet.edu.cn
HEAD /index.asp HTTP/1.0
ホスト:www.sina. com.cn
Date: 2008 年 木2007 年 3 月07:17:51 GMT
接続: 維持- Live JKLKKAJEOIMMH; path=/
Cache-control: private
/ /リソースの内容は省略されました
3.2 情報 2.2 を要求することで得られる応答は次のとおりです:
HTTP/1.0 404 Not Found //リクエストが失敗しました
Date: Thu, 08 Mar 2007 07:50:50 GMT
Server: Apache/2.0.54
Last-Modified: Thu, 30 Nov 2006 11:35 :41 GMT
ETag: "6277a-415-e7c76980"
Accept-Range: bytes
X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix
Vary: Accept-Encoding
Content-Type: text/html
X-キャッシュ: zjm152-78.sina.com.cn からのミス
経由: 1.0 zjm152-78.sina.com.cn:80
X-キャッシュ: th-143 からのミス。 sina.com.cn
Connection: close
ホストとの接続が失われました
Press any key to continue...
4. 注: 1. 入力エラーがある場合、リクエストは成功しません。
2. ヘッダーフィールドでは大文字と小文字が区別されません。
3. HTTP プロトコルの詳細については、RFC2616 を参照し、http://www.letf.org/rfc でドキュメントを見つけてください。
4. バックグラウンドプログラムを開発するには、http プロトコルをマスターする必要があります
6. HTTP プロトコルに関連する技術補足
1. 基本:
高レベルのプロトコルには、ファイル転送プロトコル FTP、電子メール転送プロトコル SMTP、ドメイン ネーム システム サービス DNS、ネットワーク ニュース転送プロトコル NNTP および HTTP プロトコルなどが含まれます。
仲介者には 3 種類あります: プロキシとゲートウェイチャネル (トンネル) では、プロキシが URI の絶対形式に基づいてリクエストを受け入れ、メッセージのすべてまたは一部を書き換え、フォーマットされたリクエストを URI 識別子を通じてサーバーに送信します。ゲートウェイは、他のサーバーの上の層として機能する受信プロキシであり、必要に応じてリクエストを基礎となるサーバー プロトコルに変換できます。チャネルは、メッセージを変更しない 2 つの接続間の中継ポイントとして機能します。チャネルは、通信が仲介者 (ファイアウォールなど) を通過する必要がある場合、または仲介者がメッセージの内容を識別できない場合によく使用されます。
プロキシ: 他のクライアントへのリクエストを確立するためにサーバーまたはクライアントとして機能できる中間プログラム。リクエストは内部的に、または可能な変換を介して他のサーバー経由で渡されます。プロキシは、リクエスト メッセージを送信する前に、リクエスト メッセージを解釈し、可能であれば書き換える必要があります。プロキシは、多くの場合、ファイアウォールを介してクライアントのポータルとして機能し、ユーザー エージェントによって完了されないプロトコル経由のリクエストを処理するヘルパー アプリケーションとしても機能します。
ゲートウェイ: 他のサーバーの仲介として機能するサーバー。プロキシとは異なり、ゲートウェイは、要求されたリソースのオリジン サーバーであるかのように要求を受け入れます。要求元のクライアントは、ゲートウェイを処理していることを認識しません。
ゲートウェイは、ファイアウォールを介してサーバー側のポータルとして機能することが多く、非 HTTP システムに保存されているリソースにアクセスするためのプロトコル トランスレーターとしても機能します。
チャネル (トンネル): 2 つの接続間のリレーとして機能する中間プログラムです。チャネルは、一度アクティブ化されると、HTTP 要求によって開始される可能性がありますが、HTTP 通信に属しているとは見なされません。中継された接続の両端が閉じられると、チャネルは消滅します。チャネルは、ポータルが存在する必要がある場合、または仲介者が中継されたトラフィックを解釈できない場合によく使用されます。
2. プロトコル分析の利点 - HTTP アナライザーがネットワーク攻撃を検出します
モジュール形式で高レベルのプロトコルを分析および処理することが、将来の侵入検出の方向性となります。
HTTP の一般的に使用されるポート 80、3128、8080 とそのプロキシは、ネットワーク セクションのポート タグで指定されます
3. HTTP プロトコルのコンテンツの長さ制限の脆弱性により、サービス拒否攻撃が引き起こされます
POST メソッドを使用する場合、次のように設定できますContentLenth は送信する必要があるコンテンツのデータ長を定義します (ContentLenth:999999999 など)。攻撃者はこの欠陥を利用して、送信が完了するまでガベージ データを WEB サーバーに送信し続けることができます。 WEBサーバーのメモリが不足しています。この攻撃方法は基本的に痕跡を残しません。
http://www.cnpaf.net/Class/HTTP/0532918532667330.html
4. HTTP プロトコルの特性を利用してサービス拒否攻撃を実行するいくつかのアイデア
サーバーは、によって偽造された TCP 接続リクエストの処理でビジーです。攻撃者は、通常のリクエストのクライアントに注意を払う時間がありません (結局、クライアントの通常のリクエストの割合は非常に小さいため)。このとき、通常のクライアントの観点からは、サーバーは応答を失います。 : サーバーは SYNFlood 攻撃 (SYN フラッド攻撃) の対象になっています。
Smurf、TearDrop などは、ICMP メッセージを使用してフラッド攻撃や IP フラグメンテーション攻撃を実行します。この記事では、「通常の接続」方法を使用してサービス拒否攻撃を生成します。
ポート 19 は、初期の Chargen 攻撃、つまり Chargen_Denial_of_Service に使用されていましたが、!彼らが使用する方法は、2 つの Chargen サーバー間に UDP 接続を生成することで、サーバーが大量の情報を処理してダウンすることを可能にします。その場合、WEB サーバーを停止するには 2 つの条件が必要です。1. Chargen サービスがある。2. Chargen サービスがある。 HTTP サービス
メソッド: 攻撃者はソース IP を偽造し、N Chargen に接続リクエスト (Connect) を送信します。接続を受信した後、Chargen は 1 秒あたり 72 バイトの文字ストリームを返します (実際、この速度は、実際のネットワーク状況)。
5. HTTP フィンガープリント技術
HTTP フィンガープリントの原理は基本的に同じです。異なるサーバーによる HTTP プロトコルの実行のわずかな違いを記録することは、TCP/IP スタック フィンガープリントよりもはるかに複雑です。カスタマイズされた HTTP サーバー構成ファイルでは、プラグインやコンポーネントを追加すると、HTTP 応答情報を簡単に変更できるため、識別が困難になりますが、TCP/IP スタックの動作のカスタマイズにはコア層の変更が必要となるため、簡単に変更できます。
Apache などのオープンソースの HTTP サーバーの場合、ユーザーはソース コード内のバナー情報を変更し、HTTP サービスを再起動して有効にすることができます。 Microsoft の IIS や Netscape などの HTTP サーバーは、バナー情報を格納する DLL ファイルで変更できます。これについては関連記事で説明しているため、ここでは詳しく説明しません。バナー情報をぼかす別の方法は、プラグインを使用することです。
一般的に使用されるテストリクエスト:
1: HEAD/Http/1.0 は基本的な HTTP リクエストを送信します
2: DELETE/Http/1.0 は削除リクエストなどの許可されていないリクエストを送信します
3: GET/Http/3.0 は、不正なバージョンの HTTP プロトコル リクエストを送信します
4: GET/JUNK/1.0 は、誤った仕様の HTTP プロトコル リクエストを送信します
HTTP 指紋識別ツール Httprint は、統計原理を使用してファジィ ロジックを組み合わせますHTTP サーバーのタイプを効果的に判断し、さまざまな HTTP サーバーによって生成された署名を収集および分析するために使用できます。
6. その他: ブラウザー使用時のユーザーのパフォーマンスを向上させるために、最新のブラウザーは、Web ページを閲覧するときに複数の接続を同時に確立し、Web ページ上の複数のアイコンを迅速に取得します。これは、Web ページ全体の転送をすばやく完了するのに便利です。
HTTP1.1 は、この継続的な接続方法と、次世代の HTTP プロトコルを提供します。HTTP-NG は、
より効率的な接続を提供するために、セッション制御、リッチ コンテンツ ネゴシエーション、およびその他の方法のサポートを追加しました。