ホームページ >バックエンド開発 >PHPチュートリアル >Http プロトコルと TCP プロトコルの違いは何ですか?
Http プロトコルと TCP プロトコルの違いは何ですか?
- 一个新手オリジナル
- 2017-09-11 11:09:215785ブラウズ
TCP プロトコルはトランスポート層に相当し、HTTP プロトコルはアプリケーション層に相当します。本質的に、この 2 つは比較できません。 Http プロトコルは TCP プロトコルに基づいています。ブラウザはサーバーから Web ページ データを取得する必要がある場合、Http リクエストを発行します。 Http は、TCP 経由でサーバーへの接続チャネルを確立します。このリクエストに必要なデータが完了すると、HTTP はすぐに TCP 接続を切断します。このプロセスは非常に短いです。したがって、HTTP 接続は短い接続であり、ステートレス接続です。いわゆるステートレスとは、ブラウザがサーバーへのリクエストを開始するたびに、接続を経由せず、毎回新しい接続を確立することを意味します。接続の場合、サーバー プロセスは接続を維持し、何らかの情報ステータスをメモリに記憶できます。各リクエストが終了すると接続が閉じられ、関連するコンテンツが解放されるため、状態は記憶されず、ステートレス接続になります。
時間の経過とともに、HTML ページはより複雑になり、多くの画像が埋め込まれている場合があります。このとき、画像にアクセスするたびに TCP 接続を確立するのは非効率です。そこで、効率が悪いという問題を解決するためにキープアライブが提案されました。 HTTP/1.1 以降、接続機能を維持するためにキープアライブがデフォルトで有効になり、Web ページが開かれた場合、クライアントとサーバー間の HTTP データの送信に使用される TCP 接続は閉じられません。クライアント このサーバー上の Web ページに再度アクセスすると、この確立された接続が継続して使用されます。キープアライブには保持時間があり、別のサーバー ソフトウェア (Apache など) で設定できます。ここでTCPコネクションは一定期間維持されますが、この時間は限られており、その時点ではまだクローズされるため、各コネクションが完了するたびにクローズするものともみなします。その後、セッションを通じて、
Cookie およびその他の関連テクノロジーによって、一部のユーザーのステータスが維持される場合もあります。ただし、依然として毎回 1 つの接続が使用され、ステートレス接続のままです。
かつて私には、混乱することが許せない概念がありました。 Http がステートレスな短い接続であり、TCP がステートフルな長い接続であるのはそのためですか? HTTP は TCP に基づいているのではないのですか? Http は各リクエストが完了した後に TCP 接続を閉じるため、接続が短いことがわかりました。ソケット プログラミングを通じて TCP プロトコルを直接使用する場合、コード領域を通じて接続のオープンとクローズのタイミングを制御できるため、コードを通じて接続を閉じない限り、接続はクライアントのプロセス内にあり、サーバーは常に存在し、関連するステータス データは常に保存されます。
C# にはソケットがあります。実際、ソケットは TCP/IP プロトコルをカプセル化したものです。ソケット自体はプロトコルではなく、呼び出しインターフェイス (API) です。 Socket の出現により、プログラマーは TCP/IP プロトコル スタックを簡単に使用できるようになりました。これは TCP/IP プロトコルの抽象化であり、作成、リッスン、接続、など、私たちが知っている最も基本的な機能インターフェイスの一部を形成します。受け入れ、送信、読み取り、書き込みなど。
より鮮明な説明: HTTP はデータのカプセル化または表示の特定の形式を提供する自動車であり、ソケットはネットワーク通信機能を提供するエンジンです。 C# プログラミングの観点から見ると、便宜上、サーバーと対話するためにすでに製造された自動車の Http を直接選択できます。ただし、環境要因やその他のカスタマイズされた要求により TCP プロトコルを使用する必要がある場合は、ソケット プログラミングを使用して、取得したデータを自分で処理する必要があります。既存のエンジンを使用してトラックを構築し、サーバーと対話するようなものです。
HTTP/1.0 と HTTP/1.1 は両方とも、基礎となるトランスポート プロトコルとして TCP を使用します。 HTTP クライアントは、まずサーバーとの TCP 接続の確立を開始します。接続が確立されると、ブラウザ プロセスとサーバー プロセスはそれぞれのソケットを通じて TCP にアクセスできるようになります。前述したように、クライアント ソケットはクライアント プロセスと TCP 接続の間の「ドア」であり、サーバー側ソケットはサーバー プロセスと同じ TCP 接続の間の「ドア」です。クライアントは、HTTP 要求メッセージを自身のソケットに送信し、HTTP 応答メッセージを自身のソケットから受信します。同様に、サーバーは独自のソケットから HTTP 要求メッセージを受信し、独自のソケットに HTTP 応答メッセージを送信します。クライアントまたはサーバーがそれぞれのソケットにメッセージを送信すると、メッセージは完全に TCP の制御下に入ります。 TCP は、HTTP に対して信頼性の高いデータ送信サービスを提供します。これは、クライアントから送信されたすべての HTTP 要求メッセージが最終的に損失なくサーバーに到達し、サーバーから送信されたすべての HTTP 応答メッセージが最終的に損失なくクライアントに到達することを意味します。
C# コードは、TCP プロトコルを使用してリモート データベースに接続します。新しい接続が作成されるたびに、connection.open が TCP 接続を開きます。 connection.Close が呼び出されると、接続は閉じられます。 FTP の最下層も TCP ですが、これは長期間の接続です。大きなファイルの転送が高速になります。 それは特定のシナリオによって異なります。サーバー側では、プログラムが長時間接続方式を採用している場合、サーバーへの同時接続数を制御して、同時に複数の接続が行われないようにすることができます。ただし、短い接続方法を採用すると、サーバーに同時に接続する接続数を制御できないため、同時に大量の接続要求を処理できるという利点もあります。ただし、接続リクエストの数が多すぎると、サーバーが動作しなくなる可能性があります。
WebService は接続を必要とせず、1 秒間に少なくとも数万/数十万のリクエストをサポートでき、各リクエストは解放され、空きメモリの消費はありません。通常、同時接続数に制限がないことが利点です。 Message Queue は接続を確立する必要がありますが、数千の接続をサポートすることは非常に困難です。データを要求していない場合でも、各接続はメモリ内の一定量のスペースを占有するためです。 SQL Server データベース サーバーの同時接続数は通常最大 16 であるなど、制限があります。
Httpプロトコルは指定されたポート80を通過する必要があるため、このポートは一般のコンピュータでは制限されていないため、Httpプロトコルはすべてのマシンのファイアウォールを正常に通過できます。ソケット プログラミングを使用する場合は、特定のポートを自分で指定する必要があります。そうすると、特定の環境ではこのポートが無効になる可能性が高く、ファイアウォールを通過できなくなります。 IIS はポート 80 を使用します。これは、このプログラムがこのポートをリッスンしていることを意味します。誰かがこのポートへの接続を確立しようとしていることが分かると、その人は応答して接続を確立します。ここで挙げた接続はすべて短い接続です。したがって、サーバー上の URL に対するリクエストは、ポート 80 を介して Web サイト プログラムに送信されます。クライアントのブラウザは、このポートを介してそれを送信します。
HTTP は、アプリケーション層に属するオブジェクト指向プロトコルであり、そのシンプルかつ高速な方法により、分散ハイパーメディア情報システムに適しています。これは 1990 年に提案され、数年間の使用と開発を経て継続的に改善および拡張されてきました。 HTTP/1.0 の 6 番目のバージョンが現在 WWW で使用されています。HTTP/1.1 の標準化作業が進行中であり、HTTP-NG (次へ)
HTTP の生成) に関する提案が行われています。
HTTP プロトコルの主な機能は次のように要約できます:
1. クライアント/サーバー モードをサポートします。
2. シンプルかつ高速: クライアントがサーバーにサービスをリクエストする場合、リクエストのメソッドとパスを送信するだけで済みます。一般的に使用されるリクエスト メソッドは、GET、HEAD、および POST です。各メソッドは、クライアントとサーバー間の異なるタイプの接続を指定します。 HTTP プロトコルは単純であるため、HTTP サーバーのプログラム サイズは小さく、通信速度は非常に高速です。
3. 柔軟性: HTTP では、あらゆる種類のデータ オブジェクトの送信が可能です。転送されるタイプは Content-Type によってマークされます。
4. 接続なし: 接続なしの意味は、各接続が 1 つのリクエストのみを処理するように制限することです。サーバーはクライアントの要求を処理し、クライアントの応答を受信した後、切断します。この方法により、送信時間が節約されます。
5. ステートレス: HTTP プロトコルはステートレス プロトコルです。ステートレスとは、プロトコルにトランザクション処理のためのメモリ機能がないことを意味します。ステータスがないということは、後続の処理で以前の情報が必要な場合にその情報を再送信する必要があることを意味し、その結果、接続ごとに転送されるデータ量が増加する可能性があります。一方、事前の情報が必要ない場合、サーバーはより速く応答します。
1. HTTP プロトコルの詳細な説明 - URL
HTTP (ハイパーテキスト転送プロトコル) は、要求および応答モードに基づいたステートレスなアプリケーション層プロトコルであり、多くの場合 TCP に基づいています 接続方法: HTTP 1.1 バージョンでは、継続的な接続メカニズムが提供されます。ほとんどの Web 開発は、HTTP プロトコルに基づいて構築されています。
HTTP URL (URL は、リソースを見つけるのに十分な情報を含む特別なタイプの URI) の形式は次のとおりです:
http://host[":"port][abs_path]
http は、ネットワーク リソースがHTTP プロトコルを通じて検索されます。 host は、正当なインターネット ホストのドメイン名または IP アドレスを示します。 空の場合は、デフォルトのポート 80 が使用されます。 URL abs_path に指定されていない場合、リクエスト URI として使用する場合は、「/」の形式で指定する必要があります。通常、ブラウザがこの作業を自動的に完了します。
例:
1. 入力: www.guet.edu.cn
ブラウザは自動的に次のように変換します: http://www.guet.edu.cn/
2。 /index.jsp
2. HTTP プロトコルの詳細な説明を求めるリクエスト
http リクエストは、リクエストライン、メッセージヘッダー、リクエストボディの 3 つの部分で構成されます
1. Request 行はスペースで区切られたメソッド記号で始まり、その後にリクエストされた URI とプロトコルのバージョンが続きます。 形式は次のとおりです。 Method 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 ブラウザ (クライアント) にキャッシュしないように指示する場合page のサーバー側 JSP プログラムは次のように記述できます。この関数は上記のコードと同等です。通常、 // は両方とも一緒に使用されます
このコードは、送信される応答メッセージの通常のヘッダー フィールドを設定します: Cache-Control: no-cache
通常の接続 ヘッダー フィールドを使用して、接続固有のオプションを送信できます。たとえば、接続が継続的であることを指定するか、「close」オプションを指定して、応答が完了した後に接続を閉じるようにサーバーに通知します
2. リクエスト ヘッダー 一般的に使用される応答ヘッダーLocation 5. Telnet を使用する http プロトコルの通信プロセスを観察します MS の Telnet ツールを使用して、http リクエスト情報を手動で入力してサーバーにリクエストを送信します。サーバーはリクエストを受信、解釈、受け入れ、応答を返します。応答は Telnet ウィンドウに表示されます。これにより、http プロトコルの通信プロセスの知覚的な理解が深まります。 1. telnet を開く 1.1 telnet を開くRun-->cmd-->telnet www.guet.edu.cn /*桂林電子ホームページのコンテンツをリクエストするリクエスト方法を変更できます。次のようにメッセージを入力してください*/ 80 //コマンドプロンプトに直接 Telnet を入力します www.sina.com.cn 80 HEAD /index.asp HTTP/1.0 ホスト:www.sina.com.cn HTTP/1.1 200 OK 3.2 情報 2.2 を要求することで得られる応答は次のとおりです: HTTP/1.0 4 04 見つかりません // リクエスト失敗しました サーバー: Apache/2.0.54
6. HTTP プロトコル関連の技術補足事項 1. 基本:
リクエスト ヘッダーを使用すると、クライアントはリクエストの追加情報とクライアント自身の情報をサーバーに渡すことができます。
一般的に使用されるリクエスト ヘッダー
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
ブラウザによって送信されるリクエスト メッセージには、次のような Host リクエスト ヘッダー フィールドが含まれます:
Host: www.guet.edu.
ここではデフォルトのポート番号 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)
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;
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");
1.2 Telnet エコー機能をオンにする
2.サーバーに接続してリクエストを送信
80 //ポート番号は省略できないので注意 HEAD /index.asp HTTP/1.0
open
www.guet.edu.cn
80 GET /index. asp HTTP/1.0 //リソースのコンテンツをリクエストします Host:www.guet.edu.cn
2.2 open
3 実験結果:
3.1 情報 2.1 を要求することによって得られる応答は次のとおりです。
日付: 木、2007 年 3 月 8 日07:17: 51 GMT
接続: キープアライブ --タイプ: text/html
Expries: Thu,08 Mar 2007 07:16:51 GMT
Set-Cookie : ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/
Cache-control: private
//リソースの内容は省略されました
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-Cache: zjm152-78 からのミス。 sina.com.cn
Via: 1.0 zjm152-78.sina.com.cn:80
事項: 1. 入力エラーがある場合、リクエストは成功しません。
2. ヘッダーフィールドでは大文字と小文字が区別されません。
3. HTTP プロトコルの詳細については、RFC2616 を参照し、
http://www.letf.org/rfc
高レベルのプロトコルには、ファイル転送プロトコル 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 は、
より効率的な接続を提供するために、セッション制御、リッチ コンテンツ ネゴシエーション、およびその他の方法のサポートを追加しました。
以上がHttp プロトコルと TCP プロトコルの違いは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。