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

HTTP は、リクエストとレスポンスで構成されるアプリケーション層プロトコルであり、標準的なクライアント サービス モデルです。 HTTP は通常、TCP プロトコルで伝送されますが、現在では、TLS または SSL プロトコル層で伝送されることもあります。 HTTP のデフォルトのポート番号は 80 で、HTTPS のポート番号は 443 です。

欠点は、サーバーがクライアントに積極的にプッシュしないことです

SPDY プロトコルのアプリケーションには、クライアント ブラウザーとサーバーの両方からのサポートが必要です。ブラウザとサーバー間の通信を最適化し、ストリーム多重化をサポートし、リクエストの優先順位を付け、リクエストをプロアクティブに開始し、SSL セキュア伝送とその他の高度な機能を強制します

4.1.2 HTTP プロトコルの仕組み

Web の閲覧は HTTP ですメイン アプリケーションこのプロトコルでは、HTTP 操作はトランザクションと呼ばれます

1 クライアントはサーバーとの接続を確立する必要があり、ハイパーリンクをクリックすると、HTTP プロトコルの作業が開始されます。

2 接続を確立した後、クライアントはサーバーにリクエストを送信します。

3 サーバーはリクエストを受信した後、対応する応答情報を提供します

4 クライアントはサーバーから返された情報を受信し、それをユーザーのディスプレイ画面に表示し、その後クライアントはサーバーから切断します

いくつかの主要なHTTP プロトコルの側面 概念

1 リクエスト

HTTP リクエストは 3 つの部分で構成されます: リクエストヘッダー、リクエストヘッダー、リクエストボディ

リクエストライン: メソッド Request-URL HTTP-Version CRLF

メソッド: リクエストメソッド ( GET、POST、HEAD、Put、削除、トレース、接続、オプション)

リクエスト URL: 統合リソースのロゴ

http バージョン: リクエストの http プロトコル バージョン

CRLF: 入力および変更

2応答

HTTP 応答も、ステータス行、メッセージ ヘッダー、応答本文の 3 つの部分で構成されます

ステータス行: HTTP-Version ステータス コード Reason-Phrase CRLF

HTTP バージョン: サーバー HTTP プロトコルのバージョン

ステータス コード: サーバーから返された応答ステータス コード

理由フレーズ: ステータス コードのテキスト説明

' s の off ‐ off ‐ ‐ ‐Code: 返された応答ステータス コードサーバーによる

理由フレーズ: ステータス コードのテキスト説明

2XX: 成功 - リクエストは正常に受信され、理解され、受け入れられました

3XX:リダイレクト - リクエストを完了するにはさらに操作を実行する必要があります 4XX: クライアント エラー - リクエストに構文エラーがあるか、リクエストを実装できません

5XX: サーバー エラー - サーバーが正当なリクエストの実装に失敗しました

一般的なステータス コードおよびステータスの説明 200 OK: クライアント リクエストが成功しました 400 悪いリクエスト: クライアント リクエスト 構文エラーがあるため、サーバーが理解できません

401 Unauthorize: リクエストは承認されていません。このステータス コードは WWW Authenticate ヘッダーと一緒に使用する必要があります403 禁止: サーバーは要求を受信しましたが、サービスの提供を拒否しました。 404 見つかりません: 要求されたリソースが存在しません。たとえば、間違った URL が入力されました。 500 内部サーバー エラー: サーバーで予期しないエラーが発生しました。利用不可: サーバーは現在クライアントのリクエストを処理できず、一定の時間が経過すると通常に戻る可能性があります

3 ヘッダー

HTTP メッセージ ヘッダーには、通常のヘッダー、リクエスト ヘッダー、応答ヘッダー、エンティティ ヘッダーが含まれます

1すべての要求および応答メッセージに使用される通常のヘッダー内のいくつかのヘッダー フィールドですが、送信されるエンティティには使用されず、送信メッセージ (キャッシュ制御、接続制御) にのみ使用されます

2 要求ヘッダーにより、クライアントはサーバーへのリクエストの追加情報とクライアント自身の情報 (UA ヘッダー、Accept)

3 応答ヘッダーを使用すると、サーバーは、ステータス行に配置できない追加の応答情報、およびサーバーに関する情報と、リクエスト URL で識別されるリソースへの次回アクセスのための情報 (場所) を渡すことができます

4エンティティ ヘッダーは、エンティティ テキストの有無など、テキストとリクエストによって識別されるリソースのエンティティ メタ情報を定義します:

またはゲートウェイの場所。 En ユーザー エージェント: 略して、コンテンツにはリクエストを発行するユーザー情報が含まれます。通常、閲覧者の情報、主にブラウザの名前バージョンと使用されているオペレーティング システムが含まれます

受け入れる: どのファイル形式が受け入れられるかをサーバーに指示します。通常、この値はどのブラウザーでも同様です。

Cookie: 2 つのタイプがあります。1 つは Cookie ヘッダーを使用してクライアントからサーバーに送信され、もう 1 つはサーバーからブラウザに送信され、ヘッダーは Set Cookie であり、値は 1 つあります。ドメイン、パスを指定する必要があります

キャッシュ制御: リクエストと応答に続くキャッシュ メカニズムを指定します。要求メッセージまたは応答メッセージでキャッシュ制御を設定しても、別のメッセージのキャッシュ処理プロセスは変更されません。キャッシュ命令には、No Cache、No Store、Max Age、Max State、No Transform、Must Revalidate、Proxy Revalidate、MAX Age が含まれます

リファラー: ヘッド ドメインにより、クライアントはリクエスト URL のソース リソース アドレスを指定できます。サーバーがログインとキャッシュの最適化のためのフォールバック リンク リストを生成できるようにします。 リファラーは通常、訪問者のアドレスを記録するためにトラフィック統計システムによって使用されるパラメーターです。応答の。要求されたリソース範囲は、各要求でマークできます。接続が切断されて再接続されると、クライアントはブレークポイント再開を実装するためにリソース全体を再要求するのではなく、リソースの未ダウンロードの部分のみを要求します。これは Xunlei の原理で、マルチスレッドを使用してインターネット上のバカ女のリソースをセグメントに読み取り、最終的にそれらをマージします。 http1.1 の正式仕様にはヘッダー フィールドが定義されていません。

関連する推奨事項:

php のヘッダーで使用される HTTP プロトコルの使用法の概要

HTTP プロトコルの詳細な分析

HTTP プロトコルの関連紹介と深い理解

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