転送：https://blog.csdn.net/gueter/article/details/1524447
入門
HTTPは、分散ハイパーメディア情報システムのための簡単、迅速な方法によるオブジェクト指向のアプリケーション層に属するプロトコルです。それが1990年に提案され、使用および開発の数年後、継続的に改善され、拡張されました。現在WWWで使用されるHTTP / 1.1で標準化作業が進行中、HTTP / 1.0の第六のバージョンで、HTTP-NG（HTTPの次世代 ） 推奨事項が提案されています。
次のようにHTTPプロトコルの主な特徴はまとめることができます：
1.は、クライアント/サーバモデルをサポートしています。
2.シンプルかつ高速：サーバーへの顧客サービス要求、代わりにリクエストメソッドとパスを送ります。リクエスト方法は、一般的にGET、HEAD、POSTを使用していました。各メソッドは、クライアントはサーバーの異なる種類を提供します。簡単なHTTPプロトコルに、HTTPサーバは、プログラム小規模になり、その通信は非常に高速です。
3.フレキシブル：HTTPデータ・オブジェクトの任意のタイプの送信を可能にします。コンテンツタイプでマークされている伝送のタイプです。
4.接続なし：なし制限を意味しないが、接続ごとに1つだけの要求を取り付けていません。サーバがクライアントの要求を処理し、顧客の応答を受信した後、すなわち、切断。このようにして、送信時間を節約することができます。
5.ステートレス：HTTPプロトコルはステートレスなプロトコルです。いかなる状態は、トランザクション処理とメモリのためのプロトコルではありません。状態の欠如は、その後の処理は、情報の前に必要なことを意味する場合は、各接続増加するために送信されるデータの量をもたらす可能性が、再送されなければなりません。一方、それはより速く、サーバーに応じて、以前の情報を必要としません。
、HTTPプロトコルは、記事のURLを詳細に説明しました
HTTP（ハイパーテキスト転送プロトコル）要求応答モードに基づいており、多くの場合、TCP接続に基づくステートレス、アプリケーション層プロトコルは、HTTP1.1解放機構は、連続的に接続与えられ、最もWeb開発、Webアプリケーションは、HTTPプロトコルの上に構築されています。
次の形式のHTTP URL（URLはURIの特別なタイプである、リソースを見つけるための十分な情報が含まれています）：
HTTP：//ホスト[「：」ポート] [腹筋_経路 ]
HTTP：HTTPプロトコルを介して表現ネットワークリソースを検索します。
ホスト：法的インターネットホストのドメイン名またはIPアドレスを定義します。
ポート：ポート番号を指定し、デフォルトは空のポート80です。
腹筋_経路：要求されたリソースのURIを指定します。
URLは腹筋_経路を与えられていない場合、リクエストURIとして、「/」の形、通常はジョブブラウザをするために与えられなければならないときに自動的に完了するために、私たちを助けます。
1は、入力：www.guet.edu.cn 自動的に変換します。http：//www.guet.edu.cn/
2は、http：192.168.0.116：8080 / index.jspを
二、リクエストのHTTPプロトコルの詳細記事
要求ライン、ヘッダーメッセージ、リクエストボディ：httpリクエストは、3つの部分、すなわち、から成り
図1は、本方法は、スペース、URIによって分離され、リクエストラインシンボルで始まり、要求されたバージョンは、次の形式に続くプロトコル：方法のRequest-URI HTTP-版 CRLF
メソッド要求メソッドを表す;のRequest-URIはユニフォームリソース識別子であります; HTTPバージョンは、HTTPプロトコルのバージョン要求を表し、CRLFはキャリッジリターンおよび改行を表し（添加の終了としてCRLFを、別個の文字CRまたはLFを許可しません）。
リクエストメソッド（すべてのメソッドすべて大文字）各の解釈の様々な方法があり、以下：
GET要求は、Request-URIによって識別されるリソース取得するため
のRequest-URIので識別される新しいリソースの追加後にPOSTデータ
のRequest-URIによって取得HEADリクエストを応答メッセージが最初で識別されるリソースの報告
としてPUT要求リソースを格納するサーバ、および要求URIとそのIDを
削除リクエストサーバは、リクエストURI識別されたリソースを削除
TRACE要求サーバは、主に、テストまたは診断のために、要求情報を受信し返し
CONNECTを将来の使用のために予約
、サーバーのパフォーマンスを照会するためのオプションの要求、または他の関連リソースのニーズやオプションの
応用例：
メソッドを取得する：あなたはページがブラウザのURLアドレスバーに入力してアクセスしたときに、ブラウザがサーバーにリソースを取得する方法を取得し使用しています、例えば：GET /form.html HTTP / 1.1（ CRLF）
POSTメソッドを使用してフォームを送信するために、バックリクエストに添付要求されたデータを受け入れるようにサーバーを必要とします。
EG：POSTは、HTTP /（CRLF）/reg.jsp
画像/ GIF、画像/ X-Xbit、...（CRLF）：受け入れを
...
HOSTを：www.guet.edu.cn（CRLF）
のContent-Length：22であります（CRLF）
接続：キープアライブ（CRLF）
のCache-Control：キャッシュなし（CRLF）
（CRLF）は、メッセージヘッダの前にCRLFは、オーバーメッセージヘッダーを表す//
ユーザは=ジェフリー＆PWD = 1234 //以下を訪問します提出されたデータ
HEADメソッドとGETメソッドは、ほとんど応答部HEAD要求に対して同じである、得られたGET要求情報に含まれる、そのHTTPヘッダ情報は同じです。この方法では、リソース・コンテンツを転送することなく、リソース情報は、Request-URIによって識別され得ることができます。ハイパーリンクの有効性をテストするために使用される方法は、あなたがアクセスし、最新の更新するかどうかことができます。
図2に示すように、後に前記要求ヘッダー
3、リクエストボディ（省略）
三、記事へのHTTPプロトコルの詳細レスポンス
要求メッセージを受信し、解釈した後、サーバは、HTTPレスポンスメッセージを返します。
ステータスライン、メッセージヘッダ、応答体：HTTPレスポンスは、3つの部分、すなわち、で構成されている
：1、次の形式でステータス行
HTTP-版ステータスコード理由フレーズCRLF
HTTP-版サーバHTTPプロトコルのバージョンを示し、;ステータス理由-フレーズステータスコードのテキスト記述を表し; -code応答状態コードを返送するサーバを表します。
ステータスコードが定義されたカテゴリに応じて3つの数字、最初の数字があり、5つの可能な値がある：
1XX：指示情報は- 、要求が受信されたことを示す処理が続行
の2xxを：成功は、 -要求が正常に受信されたことを示し、理解し、受け入れる
の3xxを： -リダイレクト要求を満たすためには、さらに一歩行かなければならない
の4xx：クライアントエラー-リクエストに構文エラーがありますか、要求を達成することができない
の5xxを：サーバー側のエラー-サーバーは、正当な要求を達成するために失敗した
一般的なステータスコードを、状態の説明は、説明：
200 OK //クライアントの要求が成功した
400不正な要求//クライアントが構文エラーを要求し、サーバーが理解することはできません
401不正//要求が許可されていない、ステータスコードは、WWW-Authenticateヘッダフィールドなければなりません使用
403禁止//サーバがリクエストを受信しますが、サービスを提供することを拒否した
の間違ったURLを入力します。404見つかりません//要求されたリソースが、例えば存在しない
500内部サーバーエラー//サーバが予期しないエラーになる
503サーバー利用できない//サーバーを現在、クライアントの要求を処理できない、一定期間後に正常に戻してもよいです
例：HTTP / 1.1 200 OK（CRLF）
前記ヘッダに応答して2、
3、レスポンスボディは、サーバリソースの内容によって返されます
フォー詳細、HTTPプロトコルメッセージは、紙をヘッダ
サーバーへのクライアントと組成に応じて、サーバーからクライアントへのHTTPリクエストメッセージ。要求および応答メッセージは、スタートラインであり、メッセージヘッダ（オプション）、空行（CRLFラインのみ）、メッセージ本体（要求メッセージ、要求ラインは、スタートライン、応答メッセージ、ステータス行は、開始行です） （任意）コンポーネント。
HTTPメッセージヘッダは、共通ヘッダ、要求ヘッダ、応答ヘッダ、ヘッダ・エンティティを含みます。
「：」各ヘッダフィールドは名前+である+スペース+値の組成、メッセージヘッダフィールド名は大文字小文字を区別しています。
図1に示すように、一般的なヘッダ
すべての要求メッセージと応答メッセージの数が少ないため、だけでなく、メッセージの送信のために送信されるエンティティの通常のヘッダ内のヘッダフィールド。
EG：
キャッシュ制御コマンドはキャッシュを指定するために使用され、命令キャッシュが単方向である（バッファコマンド応答は、必ずしも要求に表示されません）、および独立した命令キャッシュ（別のメッセージ処理へのメッセージに影響を与えませんプラグマのヘッダフィールドHTTP1.0の使用と同様キャッシュ機構）。
ノーキャッシュを（要求または応答メッセージを示すことができないキャッシュ）、無店舗、MAX-：キャッシュ命令要求が含まれていない分、新鮮MAX-失効年齢、、、キャッシュのみ-IF-、
キャッシュ命令応答含みます：パブリック、プライベート、キャッシュ-NO、NO-ストア、変換-NO、MUST-再検証、プロキシ再検証、MAXAGE、S-MAXAGE
EGは：IEブラウザ（クライアント）を示すことがないキャッシュページ、サーバー側を行います次のようにJSPプログラムを書くことができる。response.sehHeader（「キャッシュ・コントロール」、「キャッシュ-NO」）;
//response.setHeader("Pragma","no-cache「）;アクションは上記のコードに対応する、通常の両方/の/組合せ
のCache-Control：キャッシュなし、このコードは、送信された応答メッセージに共通のヘッダーフィールドで提供されます
日付共通ヘッダフィールドは、メッセージの生成日時を示します
接続通常のヘッダ・フィールドは、送信オプションが接続を指定可能にします。例えば、連続接続が指定した、または指定された「クローズ」オプションは、通知サーバは、応答が完了すると、接続を閉じます
図2は、ヘッダ要求
自体に関する要求された情報の付加情報とクライアントとサーバにクライアントを許可するように要求ヘッダーを。
一般的なリクエストヘッダは
受け入れ
受け入れリクエストヘッダフィールドは、クライアントが受け入れられた情報の種類を指定するために使用されます。例えば：受け入れ：画像/ gif形式を、クライアントはリソースのGIF画像フォーマットを受信したいことを示し、受け入れ：text / htmlのを、クライアントはHTMLテキストを受け入れることを望んでいることを示しています。
文字セットは、受け入れ
文字セットリクエストヘッダフィールドは、クライアントによって受け入れられた文字セットを指定するために使用されて受け入れます。例えば：イソ:.-文字セットを受け入れ -8859-1、2312 このフィールドは要求メッセージに設定されていない場合は、デフォルトの文字セットは、任意の許容することができます。
受け入れ-encoding
受け入れエンコードリクエストヘッダフィールドは受け入れに似ているが、それはコンテンツのエンコードを指定するための許容されます。例：要求がメッセージサーバにこのフィールドを設定されていない場合にAccept-エンコーディング:. gzip.deflateを様々なコンテンツをエンコードするため、クライアントが許容されていることを前提としています。
言語受け入れる
受け入れに似たAccept-Languageリクエストヘッダフィールドは、自然言語を指定するために使用されます。例えば：:.言語を受け入れZH -cn 要求はメッセージヘッダフィールドに設定されていない場合、サーバーは、クライアントがさまざまな言語を受け入れることができていることを前提としています。
認証
Authorizationリクエストヘッダフィールドは、主にクライアントがリソースを表示する権限を持っていることを証明するために使用されます。サーバ401（不正）の応答コードを受信した場合、ブラウザは、ページにアクセスするときに、それを検証するためにサーバを必要とする、要求承認リクエストヘッダフィールドに含ま送信することができます。
ホスト（送信要求、ヘッダフィールドは要求されます）
ホストリクエストヘッダフィールドは主に例えば、通常のHTTP URLから抽出された要求されたリソースのインターネットホストとポート番号を指定するために使用されます。
我々は、ブラウザで次のコマンドを入力します。http://www.guet.edu.cn/index .htmlの
ブラウザによって送信された要求メッセージ、次のように、ホスト要求ヘッダーフィールドが含まれます：
ホスト：www.guet.edu.cn
ポート番号が指定されている場合、本明細書にデフォルトのポート番号80を使用するが、その後、次のようになる。ホスト：www.guet.edu.cn：ポート番号の指定
のUser-Agentを
、我々はインターネットフォーラムを上陸させ、あなたは多くの場合、オペレーティングシステムの名前とバージョンを示していますいくつかのウェルカムメッセージ、あなたが使用しているブラウザの名前が表示されます多くの場合、多くの人々は非常に不思議な感じさせるのバージョンでは、実際には、要求情報にUser-Agentヘッダフィールドからサーバーアプリケーションを取得することです。User-Agentリクエストヘッダフィールドは、そのオペレーティングシステム、ブラウザにクライアントを可能にし、他の属性は、サーバーに指示します。しかし、ヘッダフィールドが必要とされていない、あなたはブラウザ自分自身を書いた場合、サーバは、私たちのメッセージを知ることができません、User-Agentリクエストヘッダフィールドを使用しないでください。
例としては、ヘッダを要求：
GETをHTTP / 1.1（CRLF）/form.html
受け入れ：画像/ GIF、画像/ X-xbitmap、画像/ JPEG、ファイルアプリケーション/ X-ショックウェーブ-フラッシュ、ファイルアプリケーション/ vnd.ms-エクセル、ファイルアプリケーション/ VND Powerpoint-.ms、アプリケーション/ mswordは、* / *（CRLF）
のAccept-言語：ZH-CN（CRLF）
受け入れエンコード：gzipで、（CRLF）を収縮させる
変更した場合--ので：水曜日、2007年1月5日午前11時21分25秒GMT（CRLF）
の場合-なし-マッチ：W / "80b1a4c018f3c41：8317"（CRLF）
のUser-Agent： Mozillaの/ 4.0（互換; MSIE6.0;のWindows NT 5.0）（CRLF）
ホスト：www.guet.edu.cn（CRLF）
接続：キープアライブ（CRLF）
（CRLF）
図3は、レスポンスヘッダ
レスポンスヘッダは、サーバがステータスラインに応じて、追加情報を渡すことができ、次のステップにアクセスするためにRequest-URIによって識別されるリソースに、サーバーの詳細情報とすることができません。
一般的な応答は、ヘッダ
場所に
新しい場所にリダイレクトするためのロケーション応答ヘッダーフィールド受信機。場所レスポンスヘッダフィールドは、時間にドメイン名を置き換えるために使用されます。
サーバー
サーバーのレスポンスヘッダフィールドは、情報要求を処理するサーバソフトウェアが含まれています。ヘッダフィールドは、User-Agentリクエストが対応しています。以下の通りである
：例サーバ応答ヘッダフィールド
サーバー：Apacheの-コヨーテ/ 1.1
WWW認証
WWW認証応答ヘッダフィールドは401（不正な）応答メッセージに含まれなければならないが、クライアント401は、応答メッセージの時刻を受信し、そしてAuthorizationヘッダフィールドサーバが検証するための要求を送信するとき、サーバの応答ヘッダは、ヘッダフィールドを含んでいます。
例えば：WWW認証：基本レルム 「！ベーシック認証テスト」= // サーバは要求されたリソース上で見ることができ、基本的な認証メカニズムを使用しています。
4、のエンティティヘッダ
要求および応答メッセージは、エンティティを送信することができます。エンティティヘッダフィールドによってエンティティ、およびエンティティ体組成が、一緒にするために、テキストを送信するために、エンティティヘッダフィールドとエンティティということを意味するものではありません、あなただけのエンティティヘッダフィールドを送ることができます。特定されたメタ情報リソース（例えばエンティティボディかどうか）と、要求：エンティティボディに定義されたエンティティヘッダ。
共通のエンティティヘッダ
のコンテンツをコードする
コンテンツ符号化エンティティヘッダフィールドはメディアタイプの修飾子として使用され、コードを表す値が参照Content-Typeヘッダフィールドを得ることが、追加コンテンツのエンティティボディに適用されていますメディアタイプは、対応する復号化機構を使用しなければなりません。このような文書を記録するためのコンテンツの符号化圧縮方法は、EGは：コンテンツ・エンコード：gzipの
コンテンツ言語
コンテンツ言語エンティティヘッダフィールドが使用自然言語リソースを記述する。設定されていないこのフィールドは、エンティティの内容が読み込まれたすべての言語に利用できるようになります考えられている
ことで。EG：コンテンツ言語：DA
コンテンツ長
進数のエンティティボディの長さを示すLengthヘッダフィールドを表すためにバイト単位で格納されているコンテンツ・エンティティ。
タイプコンテンツ
コンテンツ用語Typeヘッダフィールドはメディアタイプの受信側エンティティ本体にエンティティを示しています。EG：
コンテンツタイプ：テキスト/ HTML;のcharset = ISO-8859-1
のContent-Type：テキスト/ HTML;のcharset = GB2312
のLast-Modified
のLast-Modifiedエンティティヘッダフィールドリソースの最終更新日時表示のために。
有効期限
エンティティヘッダフィールドはレスポンスの期限が切れた日付と時間を与える有効期限。ページのプロキシサーバーまたはブラウザは、一定期間後にキャッシュを更新するために順序（アクセスしたときにページが、再び訪れキャッシュから直接ロード、応答時間の短縮やサーバーの負荷を軽減して）で、我々は、使用することができますページ指定されたエンティティヘッダフィールドを有効期限時間が期限切れ。EGは：有効期限：木、2006年9月15日午後4時23分12秒GMT
HTTP1.1クライアントとキャッシュの有効期限が切れていると考えられ（ゼロを含む）その他の違法な日付形式でなければなりませんが。例えば次のようにブラウザがページをキャッシュしないために、我々はまた、使用することができるためには、0に設定されたエンティティヘッダフィールド、JSPプログラムを有効期限：response.setDateHeaderを（「「有効期限」 0」）;
第五に、通信処理httpプロトコルを観察するためにTelnetを使用
実験目的および原理：
使用してMSのテルネット設備、手動入力モードHTTPリクエスト情報により、サーバへの要求、サーバは、受信し解釈し、要求を受信した後、それによって、Telnetウィンドウに表示される応答を返しますhttpプロトコルの感性から通信プロセスの理解を深め。
実験手順：
1. Telnetは
1.1オープンのTelnet
の実行- > CMD - >のtelnet
エコー1.2オープンのtelnet
セットLOCALECHOを
図2に示すように、接続サーバは、要求を送信し、
2.1オープン www.guet.edu.cn ポート番号を省略することができない80 //注
HEAD / 1.0 /index.asp HTTP
ホスト：www.guet.edu.cnは
/ *我々は、入力メッセージとして、リクエストメソッド、リクエスト桂林家電の内容を変換することができます* /
オープン www.guet.edu.cn 80
GETの/index.asp HTTP / 1.0 //要求コンテンツリソースの
ホスト：www.guet.edu.cn
オープン2.2 www.sina.com.cn コマンドプロンプトのTelnetで直接80 //入力 www.sina.com.cn 80
HTTP / 1.0 /index.asp HEAD
www.sina.com.cn：ホスト
3つの結果：
3.1 2.1要求応答情報が得られます。
HTTP / 1.1 200 OK //请求成功
サーバー：マイクロソフト-IIS / 5.0 //ウェブ服务器
日：木、3月8日200707は、17：51 GMTの
接続：キープアライブ
のContent-Length：23330
のContent-Type：text / htmlの
Expries ：木、2007年3月8日午前七時16分51秒GMT
のSet-Cookie：ASPSESSIONIDQAQBQQQB = BEJCDGKADEDJKLKKAJEOIMMH。パス= /
キャッシュ制御：プライベート
//リソースの内容は省略します
3.2 2.2要求応答情報が得られます。
HTTP / 1.0 404見つかりませんでした//请求失败
日：木、2007年3月8日午前七時50分50秒GMTの
サーバー：Apacheの/ 2.0.54 <Unixの>
のLast-Modified：木、2006年11月30日11時35分41秒GMTの
ETagを： "6277a-415-e7c76980は"
受け入れ-範囲を：バイト
X-パワード・バイを：mod_xlayout_jh / 0.0.1vhs.markII.remix
ヴァリ：受け入れ-encodingを
コンテンツタイプ：text / htmlでの
X-キャッシュ：zjm152-78.sinaからMISSを.com.cn
経由：1.0 zjm152-78.sina.com.cn:80 <イカ/ 2.6.STABLES-20061207>
X-キャッシュ：MISS th-143.sina.com.cnからの
接続：近いです
注4：1、入力エラーを、要求は成功しません。
図2に示すように、ヘッダフィールドは、大文字と小文字が区別されません。
3、HTTPプロトコルのより深い理解は、あなたがして、RFC2616を参照することができhttp://www.letf.org/rfc上のファイルを見つけます。
4、開発者はデーモンhttpプロトコルを習得する必要があります
1は、ベース：
高レベルのプロトコルが含まれます：ファイル転送プロトコルFTP、電子メール転送プロトコルSMTP、DNSサービス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接続要求を偽造するために、サーバーが攻撃を処理して忙しくされ（結局、クライアントの通常の要求率が非常に小さい）、ビューの通常の顧客の視点から、この時間は、サーバーが停止したときは、私たちはこのような状況を呼び出す：サーバが攻撃（SYNフラッド攻撃を）SYNFLOODされています。
スマーフ、ティアドロップなどはIP洪水や破片攻撃に対してICMPパケットを使用することです。このホワイトペーパーでは、サービスの攻撃方法「通常接続」の拒否を作成します。
初期の19ポートではすでにChargen_Denial_of_ServiceそのCHARGEN攻撃を行うために使用されるが、されています！1. 2. HTTPサービスがCHARGENを持っている：彼らが使用方法は、サーバーが2つの条件を持っている必要がありますWEBサーバを殺す、DOWNアウトあまりにも多くの情報を処理させる、2つのCHARGENサーバーのUDP接続の間に生成されますサービス
この方法は：送信元IP N CHARGEN局を偽造する攻撃者は、接続要求（接続）を送信し、CHARGENは、毎秒72のバイトがサーバに（実際には、実際のネットワーク状況に応じて、この高速）接続文字列を返す受信します。
図5は、HTTPの指紋認識技術
のHttp .Httpは、TCP / IPスタックよりも多くの複雑な根拠をフィンガープリンティングプロトコル実行マイナーな違い指紋識別そのカスタムHTTP Serverの別のサーバーを記録する：のHttp指紋認識原理は一般的に同じですプロファイルは、識別困難な変更を行う応答情報が非常に容易になるのHttp変更のためのプラグインまたはコンポーネントを追加する;識別が容易であるのでしかし、カスタムTCP / IPスタックの動作は、コア層を変更する必要がある。
サーバーが異なる返すため情報のバナーセットは、ApacheのオープンソースのHTTPサーバとして、非常に単純で、ユーザーは、ソースコード情報バナーを変更することができ、その後、再起動のHttpサービスが有効になります。HTTP ServerはMicrosoftなど、ソースを開いていないためIISやNetscape、あなたがバナーDllファイルの文書保存されている情報を変更することができ、関連記事を議論してきた、ここではそれらを繰り返さない、もちろん、効果のような変更が良いです。もう一つのファジーバナー情報は、プラグインを使用することです。
共通テスト要求：
1：HEAD / HTTP / 1.0 HTTPリクエストが基本的な送信
2：DELETE / HTTP / 1.0リクエストを送信し、そのような削除要求として、許可されていない
プロトコル要求のHTTP違法バージョン送信するGET / HTTP / 3.0：3
4 ：GET / JUNK / 1.0仕様では、HTTP、誤ったプロトコル要求送信
統計理論を使用して、ファジーロジック技術の組み合わせは、それが使用可能なサーバーの種類のHttpを決定する上で非常に有効であることができるのHttp Httprint指紋ツールを、。サーバによって生成されたHTTP異なる署名の収集と分析。
6、その他：これは、より迅速に完了することができ、すぐにWebページ上の複数のアイコンを取得するために、複数の同時接続を参照するとき、Webページを、ユーザーがブラウザを使用する場合、最新のブラウザはまた、同時アクセス方法をサポート、パフォーマンスを向上させる確立するためにページ全体を転送します。
HTTP1.1継続的に接続されている、このように設けられており、HTTPプロトコルの次世代：HTTP-NGを提供し、セッション制御、リッチコンテンツとの協議の他の形態のためのサポートについて追加
の接続がより効率的に。