HTTPプロトコル例の詳しい説明-PHPチュートリアル-php.cn

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

小云云

リリース： 2023-03-21 09:04:01

オリジナル

2835 人が閲覧しました

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 の正式仕様にはヘッダーフィールドが定義されていません。