HTTP の概要、http はアプリケーション層に属するオブジェクト指向プロトコルです。-PHPチュートリアル-php.cn

regrupting転載時にソースを示してください：HTTPの紹介、HTTPはアプリケーションレイヤーに属するオブジェクト指向のプロトコルです

引用

HTTP は、アプリケーション層に属するオブジェクト指向プロトコルであり、そのシンプルで高速なメソッドのため、分散ハイパーメディア情報システムに適しています。これは 1990 年に提案され、数年間の使用と開発を経て継続的に改善および拡張されてきました。現在、WWW では HTTP/1.0 の 6 番目のバージョンが使用されており、HTTP/1.1 の標準化作業が進行中であり、HTTP-NG (Next Generation of HTTP) 提案が提案されています。 HTTP プロトコルの主な機能は次のように要約できます:
クライアント/サーバーモードをサポートします。
2. シンプルかつ高速: クライアントがサーバーにサービスをリクエストする場合、リクエストのメソッドとパスを送信するだけで済みます。一般的に使用されるリクエストメソッドは、GET、HEAD、および POST です。各メソッドは、クライアントとサーバー間の異なるタイプの接続を指定します。 HTTP プロトコルは単純であるため、HTTP サーバーのプログラムサイズは小さく、通信速度は非常に高速です。
3. 柔軟性: HTTP では、あらゆる種類のデータオブジェクトの送信が可能です。転送されるタイプは Content-Type によってマークされます。
4. 接続なし: 接続なしの意味は、各接続が 1 つのリクエストのみを処理するように制限することです。サーバーはクライアントの要求を処理し、クライアントの応答を受信した後、切断します。この方法により、送信時間が節約されます。
5. ステートレス: HTTP プロトコルはステートレスプロトコルです。ステートレスとは、プロトコルにトランザクション処理のためのメモリ機能がないことを意味します。ステータスがないということは、後続の処理で以前の情報が必要な場合にその情報を再送信する必要があることを意味し、その結果、接続ごとに転送されるデータ量が増加する可能性があります。一方、事前の情報が必要ない場合、サーバーはより速く応答します。

1. HTTPプロトコルの詳細説明 - URL

HTTP (ハイパーテキスト転送プロトコル) は、リクエストとレスポンスのモデルに基づいたステートレスなアプリケーション層プロトコルであり、ほとんどの Web 開発では TCP 接続メソッドが提供されます。 HTTP プロトコルに基づいて構築された Web アプリケーション。

HTTP URL (URL は、リソースを見つけるのに十分な情報を含む特別なタイプの URI) の形式は次のとおりです:
http://www.php.cn/[":"port][ abs_path] http は、HTTP プロトコルを通じてネットワークリソースを見つけることを意味します。 host は、正当なインターネットホストのドメイン名または IP アドレスを意味します。空の場合は、デフォルトのポート 80 が使用されます。 URL に abs_path が指定されていない場合、リクエスト URI として使用する場合は、通常、ブラウザーがこのタスクを自動的に完了します。
例:
1. 入力:
www.guet.edu.cn
ブラウザは自動的に次のように変換します: http://www.php.cn/
2、http:192.168.0.116:8080 /index.jsp

2. HTTPプロトコルの詳細説明 – リクエストセクション

http リクエストは、リクエスト行、メッセージヘッダー、リクエスト本文の 3 つの部分で構成されます

1. リクエスト行はスペースで区切られたメソッド記号で始まり、その後にリクエストされた URI とプロトコルのバージョンが続きます。メソッド Request-URI HTTP-Version CRLF
Method はリクエストメソッドを表します。統合リソース識別子、HTTP-Version は要求された HTTP プロトコルのバージョンを示し、CRLF は復帰と改行を示します (最後の CRLF を除き、個別の CR または LF 文字は許可されません)。

リクエストメソッドは多数あります（メソッドはすべて大文字）各メソッドの説明は次のとおりです:
GET Request-URIで特定されるリソースの取得リクエスト
POST 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)
Accept:image/gif,image/x-xbit,... (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. リクエストボディ（省略）

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 共通ヘッダーフィールドは、メッセージが生成された日時を示します

Connection 共通ヘッダーフィールドを使用すると、接続固有のオプションを送信できます。たとえば、接続が継続的であることを指定するか、「close」オプションを指定して、応答が完了した後に接続を閉じるようにサーバーに通知します

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.php.cn/
ブラウザによって送信されるリクエストメッセージには、次のようなホストリクエストヘッダーフィールドが含まれます:
ホスト: 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)
接続:キープアライブ (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");

5. Telnetを使用してhttpプロトコルの通信プロセスを観察します

実験の目的と原理: MS の Telnet ツールを使用して、http リクエスト情報を手動で入力してサーバーにリクエストを送信します。サーバーがリクエストを受信、解釈し、受け入れると、応答が返され、画面に表示されます。 Telnet ウィンドウを使用して、http プロトコルの通信プロセスを知覚的な観点から理解します。

実験手順:

1. Telnet を開きます1.1 Telnet を開きます
Run-->cmd-->telnet を開きます

1.2 Telnetエコー機能をオンにするlocalechoを設定する

2. サーバーに接続してリクエストを送信
2.1 open www.guet.edu.cn 80 //ポート番号は省略できないことに注意してください

HEAD /index.asp HTTP/1.0
Host:www.guet.edu.cn
/*リクエスト方法を変更して桂林電子ホームページのコンテンツをリクエストすることができます。次のようにメッセージを入力してください*/

www を開きます。 guet.edu. cn 80
GET /index.asp HTTP/1.0 //要求されたリソースのコンテンツ
ホスト:www.guet.edu.cn

2.2 open www.sina.com.cn 80 //コマンドプロンプトで直接telnetと入力します www.sina.com.cn 80 HEAD /index.asp HTTP/1.0
Host:www 。 sina.com.cn

3 実験結果:

3.1 情報 2.1 を要求することで得られる応答は次のとおりです:

HTTP/1.1 200 OK : 木、2007 年 3 月 08 日07:17 :51 GMT接続: キープアライブタイプ: text/html
Expries: Thu,08 Mar 2007 07:16:51 GMT
セット Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH ; パス=/
キャッシュ制御: プライベート

//リソースの内容は省略されました

3.2 情報 2.2 を要求することで得られる応答は次のとおりです:

HTTP/1.0 404 Not Found //リクエストが失敗しましたDate: Thu, 08 Mar 2007 07:50:50 GMTServer: 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
接続: 閉じる

ホストへの接続が失われました

続行するには任意のキーを押してください...

4. 注: 1. 入力エラーがある場合、リクエストは成功しません。
2. ヘッダーフィールドでは大文字と小文字が区別されません。
3. HTTP プロトコルの詳細については、RFC2616 を参照し、http://www.php.cn/ でファイルを見つけてください。
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.php.cn/

4. HTTP プロトコルの特性を利用してサービス拒否攻撃を実行するためのいくつかのアイデア
サーバーは攻撃者によって偽造された TCP 接続リクエストの処理で忙しく、時間がありません。クライアントの通常のリクエストに注意してください (結局のところ、クライアントの通常のリクエストの割合は非常に小さいです)。このとき、通常のクライアントから見ると、サーバーは応答を失います。この状況をサーバーが対象と呼びます。 SYN フラッド攻撃 (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 は、
より効率的な接続を提供するために、セッション制御、リッチコンテンツネゴシエーション、およびその他の方法のサポートを追加しました。