HTTPプロトコルの詳しい説明

はじめに

HTTP は、アプリケーション層に属するオブジェクト指向プロトコルであり、そのシンプルかつ高速な方法により、分散ハイパーメディア情報システムに適しています。これは 1990 年に提案され、数年間の使用と開発を経て継続的に改善および拡張されてきました。現在、WWW では HTTP/1.0 の 6 番目のバージョンが使用されており、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 プロトコルを通じて場所を特定することを意味します ネットワーク リソース; ホスト正当なインターネット ホスト ドメイン名または IP アドレスを表します。port はポート番号を指定します。空の場合は、デフォルトのポート 80 が使用されます。abs_path は、要求されたリソースの URI を指定します。URL に abs_path が指定されていない場合は、リクエスト URI として使用される場合、「/」の形式で指定する必要があります。通常、ブラウザーがこのタスクを自動的に完了します。

例:

1. www.guet.edu.cn

と入力します。ブラウザは自動的に次のように変換します: http://www.guet.edu.cn/

2. http:192.168.0.116:8080/index.jsp

2. の詳細説明HTTP プロトコル リクエストの章

http リクエストは、リクエスト行、メッセージ ヘッダー、リクエスト本文

#1 の 3 つの部分で構成されます。リクエスト行は、メソッド シンボル 最初にスペースで区切られ、その後に要求された URI とプロトコル バージョンが続く形式は次のとおりです: Method Request-URI HTTP-Version CRLF

Method は要求メソッドを表し、Request-URI は統一リソースです識別子; HTTP -Version は要求された HTTP プロトコルのバージョンを示します; CRLF はキャリッジ リターンとライン フィードを示します (末尾の CRLF を除き、個別の CR または LF 文字は許可されません)。

リクエストメソッドは多数あります(メソッドはすべて大文字) 各メソッドの説明は以下の通りです:

GET Request-URI#で特定されるリソースの取得リクエスト

## POST Request-URI

HEAD で識別されるリソースの後に新しいデータを追加します。 Request-URI

PUT で識別されるリソースの応答メッセージ ヘッダーの取得を要求します。 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)

...

ホスト:www.guet.edu.cn (CRLF)

コンテンツの長さ:22 (CRLF)

接続:キープアライブ (CRLF)

Cache-Control:no-cache (CRLF)

(CRLF) //この CRLF は、メッセージ ヘッダーが終了し、その前はメッセージ ヘッダーであったことを示します

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 はサーバーから返される応答ステータス コードを表します。 -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 //予期しないエラーが発生しました。 server

503 Server Unavailable //サーバーは現在顧客を処理できません 一定期間が経過すると、正常に戻る可能性があります 応答テキストは、サーバーによって返されたリソースの内容です

4. HTTP プロトコルの詳細説明 - メッセージ ヘッダー

クライアントからサーバーへの HTTP メッセージは、リクエストとサーバーからのレスポンスで構成されます。クライアントに。要求メッセージと応答メッセージはどちらも開始行 (要求メッセージの場合は開始行が要求行、応答メッセージの場合は開始行がステータス行)、メッセージ ヘッダー (オプション)、空行 ( CRLF のみを含む行）、およびメッセージ本文（オプション）の構成。

HTTP メッセージ ヘッダーには、通常のヘッダー、リクエスト ヘッダー、レスポンス ヘッダー、およびエンティティ ヘッダーが含まれます。

各ヘッダー フィールドは、名前「:」スペース値で構成されます。メッセージ ヘッダー フィールドの名前は、大文字と小文字が区別されません。

1. 通常のヘッダー

通常のヘッダーには、すべてのリクエストおよび応答メッセージに使用されるいくつかのヘッダー フィールドがありますが、送信されるエンティティには使用されず、送信されるメッセージにのみ使用されます。 。

例:

Cache-Control は、キャッシュ命令を指定するために使用されます。キャッシュ命令は一方向であり (応答に表示されるキャッシュ命令はリクエストに表示されない場合があります)、独立しています。 (メッセージのキャッシュ ディレクティブは、別のメッセージ処理のキャッシュ メカニズムに影響を与えません。) 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 プログラムを次のように記述できます: response.sehHeader("Cache-Control", "no-cache");

//response .setHeader("Pragma","no-cache");この関数は上記のコードと同等で、通常は両方が // 一緒に使用されます

このコードは共通の送信される応答メッセージのヘッダー フィールド: 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 リクエスト ヘッダー フィールドを含むリクエストを送信して、サーバーに検証を依頼できます。

Host (このヘッダー フィールドはリクエストの送信時に必要です)

Host リクエスト ヘッダー フィールドは主に、リクエストされたリソースのインターネット ホストとポート番号を指定するために使用されます。これらは通常、 HTTP URL が表示されます。例:

ブラウザに次のように入力します: http://www.guet.edu.cn/index.html

ブラウザによって送信されるリクエスト メッセージには、Host が含まれます。リクエスト ヘッダー フィールドは次のようになります:

ホスト: www.guet.edu.cn

ここではデフォルトのポート番号 80 が使用されます。ポート番号を指定すると、ホスト: www になります。 .guet.edu.cn: ポート番号を指定します

User-Agent

オンライン フォーラムにログインすると、オペレーティング システムの名前がリストされたウェルカム メッセージが表示されることがあります。 . とバージョン, あなたが使用しているブラウザの名前とバージョン, これは多くの人に素晴らしいと思わせることがよくあります. 実際、サーバー アプリケーションはこの情報を 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-From:Wed,05 Jan 2007 11:21:25 GMT (CRLF)

一致しない場合:W/"80b1a4c018f3c41:8317" (CRLF)

ユーザー エージェント:Mozilla/4.0(互換;MSIE6.0;Windows NT 5.0) (CRLF)

ホスト:www.guet.edu.cn (CRLF)

Connection:Keep-Alive (CRLF)

(CRLF)

3. 応答ヘッダー

応答ヘッダーを使用すると、サーバーは、ステータス行に配置できない追加の応答情報、サーバーに関する情報、および Request-URI で識別されるリソースへの次のアクセスに関する情報を渡すことができます。

一般的に使用される応答ヘッダー

Location

Location 応答ヘッダー フィールドは、受信者を新しい場所にリダイレクトするために使用されます。 Location 応答ヘッダー フィールドは、ドメイン名を変更するときによく使用されます。

サーバー

サーバー応答ヘッダー フィールドには、サーバーが要求を処理するために使用するソフトウェアに関する情報が含まれています。 User-Agent リクエスト ヘッダー フィールドに対応します。以下は、

サーバー応答ヘッダー フィールドの例です:

Server:Apache-Coyote/1.1

WWW-Authenticate

WWW-Authenticate 応答header フィールド 401 (Unauthorized) 応答メッセージに含める必要があります。クライアントが 401 応答メッセージを受信し、Authorization ヘッダー フィールドを送信してサーバーに検証を要求すると、サーバーの応答ヘッダーにはこのヘッダー フィールドが含まれます。

例: WWW-Authenticate:Basic realm="Basic Auth Test!" //サーバーが要求されたリソースに対して基本認証メカニズムを使用していることがわかります。

4. エンティティ ヘッダー

要求メッセージと応答メッセージの両方でエンティティを送信できます。エンティティは、エンティティ ヘッダー フィールドとエンティティ本文で構成されます。ただし、エンティティ ヘッダー フィールドとエンティティ本文を一緒に送信する必要があるというわけではなく、エンティティ ヘッダー フィールドのみを送信することもできます。エンティティ ヘッダーは、エンティティ本体に関するメタ情報 (例: エンティティ本体の有無) とリクエストによって識別されるリソースを定義します。

一般的に使用されるエンティティ ヘッダー

Content-Encoding

Content-Encoding エンティティ ヘッダー フィールドはメディア タイプ修飾子として使用され、その値はそれが適用されていることを示します。 Content-Type ヘッダー フィールドで参照されるメディア タイプを取得するには、対応するデコード メカニズムを使用する必要があるため、本文内の追加コンテンツのエンコード。 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 を含む) を期限切れとして扱わなければなりません (MUST)。例: ブラウザーがページをキャッシュしないようにするために、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 エコー機能をオンにする

set localecho

2. サーバーに接続してリクエストを送信します

2.1 open www.guet.edu.cn 80 //メモポート番号は省略できません。

HEAD /index.asp HTTP/1.0

Host:www.guet.edu.cn

/*リクエスト方法を変更できます。桂林電子ホームページのコンテンツをリクエストするには、次のメッセージを入力してください */

open www.guet.edu.cn 80

GET /index.asp HTTP/1.0 //リソースのリクエスト Content

ホスト: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 IS：

HTTP/1.1 200 OK // Webサーバー

日付：Thu、08 2007 年 3 月 07:17:51 GMT

Connection: Keep-Alive

Content-Length: 23330

Content-Type: text/html

#Expries: Thu,08 Mar 2007 07:16:51 GMT

Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/

##キャッシュ制御: private

/ /リソース コンテンツ省略

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

HTTP/1.0 404 Not Found //要求は失敗しました

Date: Thu, 08 Mar 2007 07:50 :50 GMT

サーバー: Apache/2.0.54

最終更新日: 木、2006 年 11 月 30 日 11:35:41 GMT

ETag: " 6277a-415-e7c76980"

受け入れ範囲: バイト

X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix

Vary: Accept-Encoding

Content-Type: text/html

#XX-Cache: MISS from zjm152-78.sina.com.cn

Via: 1.0 zjm152-78.sina.com 。 cn:80d5f86657af72c1913e9b8af081e6b15f

XX-キャッシュ: th-143.sina.com.cn

接続からのミス: 閉じる

失われたホストとの接続が確立されました

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 プロトコルの実行のわずかな違いを記録して識別します。HTTP フィンガープリンティングは TCP よりも優れています。 /IP スタックのフィンガープリンティングは非常に複雑です。その理由は、HTTP サーバーの構成ファイルをカスタマイズしたり、プラグインやコンポーネントを追加したりすることで、HTTP 応答情報を簡単に変更できるため、識別が困難になるためです。 TCP/IP スタックでは、コア層の変更が必要です。変更なので、識別が簡単です。

さまざまなバナー情報を返すようにサーバーをセットアップするのは非常に簡単です。Apache などのオープン ソースの Http サーバーの場合、ユーザーはソース コード内のバナー情報を変更できます。その後、HTTP サービスを再起動すると有効になります。Microsoft の IIS や Netscape など、オープン ソース コードを持たない HTTP サーバーの場合は、バナーを保存する DLL ファイルで変更できます。情報。関連記事で説明されているため、ここでは詳しく説明しません。もちろん、これは事実です。修正の効果は依然として良好です。バナー情報をぼかすもう 1 つの方法は、プラグインを使用することです。

一般的に使用されるテスト リクエスト:

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 ページ全体の送信をより迅速に完了できます。

HTTP1.1 は、この継続的な接続方法と次世代の HTTP プロトコルを提供します。HTTP-NG は、セッション制御、リッチ コンテンツ ネゴシエーション、その他の方法のサポートを追加して、

より効率的な接続を提供します。 。

以上がHTTPプロトコルの詳しい説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。