HTTPプロトコル（HTTPプロトコル）とは、一般的にHTTPのことを指します。
ハイパー テキスト転送プロトコル ( HTTP ) は、通常はTCP上で実行される単純な要求/応答プロトコルです。クライアントがサーバーに送信できるメッセージの種類と、クライアントが取得する応答の種類を指定します。リクエストおよびレスポンスメッセージのヘッダーはASCII形式で与えられますが、[9] メッセージの内容はMIMEのような形式です。この単純なモデルは、開発と展開を非常に簡単にしたため、Web の初期の成功に貢献しました。
| 中国語の名前 | ハイパーテキスト転送プロトコル |
ベース | TCP上のアーキテクチャ |
| 外国人の名前 | HTTP |
対応ブラウザ | Firefox、Google Chrome等 |
| 作業層 | アプリケーション層 | 関数 | WWWサーバーとブラウザ間の情報転送の仕様を定めたもので、双方が遵守する協定です。 |
導入
World Wide Web (WWW) は、ヨーロッパのジュネーブにある量子物理学研究所CERNに由来しており、WWW テクノロジーの出現により、インターネットは想像を絶する速度で発展することができました。このTCP/IPベースのテクノロジーは、何十年にもわたって開発されてきたインターネット上で最大の情報システムを、わずか 10 年で急速に成長させました。その成功の要因は、そのシンプルさと実用性にあります。WWW の背後には、このような壮大な作業の達成をサポートする一連のプロトコルと標準があり、これが HTTP ハイパーテキスト転送プロトコルを含む Web プロトコル スイートです。
1990 年に、HTTP は WWW のサポート プロトコルになりました。WWW の父である創始者ティムバーナーズリーによって提案され、その後 HTTP をさらに改良しリリースするために WWW コンソーシアムが設立され、IETF (Internet Engineering Task Force) グループが組織されました。
HTTP はアプリケーション層プロトコルであり、他のアプリケーション層プロトコルと同様、ある種の特定のアプリケーションを実装するためのプロトコルであり、その機能はユーザー空間で動作するアプリケーションによって実現されます。HTTP はプロトコルの仕様であり、文書に記録された仕様であり、実際に HTTP を介して通信を行う HTTP の実装プログラムです。
HTTPはB/Sアーキテクチャに基づいて通信し、 HTTPのサーバー側実装プログラムにはhttpd、nginxなどが含まれ、クライアント側実装プログラムは主にFirefox 、 Internet Explorer、Google Chrome、Safari、Operaなどに加えて、クライアントのコマンド ライン ツールには elink、curlなども含まれます。Web サービスはTCP に基づいているため、クライアントの要求にいつでも応答できるように、Web サーバーはポート 80/TCP をリッスンする必要があります。このようにして、クライアント ブラウザと Web サーバーは HTTP 経由で通信できます。
開発段階
0.9
0.9 プロトコルは、さまざまなデータ情報に適したシンプルで高速なプロトコルですが、ますます開発が進むさまざまなアプリケーションのニーズを満たすには程遠いです。0.9 プロトコルは、テキストに限定された情報交換のための順序付けされていないプロトコルです。内容については交渉できないため、双方の握手や合意によって双方の内容が規定されることはなく、写真を表示したり加工したりすることはできない。
1.0
1.0 プロトコルの段階、つまり 1982 年に、Tim Berners-Lee が HTTP/1.0 を提案しました。その後の強化と開発において、HTTP/1.0 は最も重要なトランザクション指向のアプリケーション層プロトコルになりました。このプロトコルは、要求/応答ごとに接続を確立および切断します。シンプルで管理しやすいのが特徴で、あらゆるニーズに応え、広く使われています。
1.1
1.0 プロトコルでは、双方が接続方法と接続タイプを規定し、HTTP の分野を大きく拡大しましたが、インターネットの最も重要な速度と効率についてはあまり考慮されていません。結局のところ、プロトコルの作成者として、彼は当時 HTTP がこれほど普及するとは予想していませんでした。
HTTP1.1プロトコルの具体的な内容については、 RFC 2616を参照してください 。
2.0
HTTP2.0 の前身は HTTP1.0 と HTTP1.1 です。以前は 2 つのバージョンしかありませんでしたが、これら 2 つのバージョンに含まれるプロトコル仕様は、経験豊富なエンジニアであれば頭痛の種になるほど膨大です。ネットワーク プロトコルの新しいバージョンは、古いバージョンをすぐに置き換えるものではありません。実際、1.0 と 1.1 は長い間共存していましたが、これはネットワーク インフラストラクチャの更新が遅かったためです。
HTTP2.0 プロトコルの具体的な内容については、RFC 7540 を参照してください。
アプリケーションシナリオ
HTTP が誕生した当初は、主に WEB 側のコンテンツを取得するために使用されていましたが、当時はコンテンツが今ほど豊富ではなく、レイアウトも精緻ではなく、ユーザーとの対話シーンもほとんどありませんでした。Web コンテンツを取得するこの単純なシナリオでは、HTTP は適切にパフォーマンスを発揮します。しかし、インターネットの発展と WEB2.0 の誕生により、より多くのコンテンツが表示され (画像ファイルが増え)、レイアウトがより美しくなり (CSS が増え)、より複雑なインタラクションが導入されました (JS が増えました)。ユーザーがWeb サイトのトップページを開いたときに読み込まれるデータの総量とリクエストの数も増加しています。
現在、ほとんどのポータル Web サイトのホームページ サイズは 200 万を超え、リクエスト数は 100 に達する場合があります。もう 1 つの広く普及しているアプリケーションは、モバイル インターネットクライアント アプリケーションであり、さまざまな性質のアプリケーションによる HTTP の使用は大きく異なります。e コマース アプリの場合、ホームページを読み込むリクエストが 10 件を超える場合があります。WeChatなどの IMの場合、 HTTP リクエストは音声ファイルと画像ファイルのダウンロードに限定される場合があり、リクエストの頻度は高くありません。
動作原理
HTTP はクライアント/サーバーモデルに基づいており、接続指向です。一般的な HTTPトランザクション処理には次のプロセスがあります。
(1) クライアントはサーバーとの接続を確立します。
(2) クライアントはサーバーにリクエストを送信します。
(3) サーバーはリクエストを受け取り、リクエストに応じて対応するファイルを応答として返します。
(4) クライアントとサーバーは接続を閉じます。
クライアントとサーバー間の HTTP 接続は 1 回限りの接続であり、各接続が 1 つのリクエストのみを処理するように制限されています。サーバーがこのリクエストに対する応答を返すと、すぐに接続が閉じられ、次のリクエストのために接続が再確立されます。リクエスト。この 1 回限りの接続は、WWW サーバーがインターネット上で何千ものユーザーに直面しており、限られた数の接続しか提供できないことを主に考慮しています。そのため、サーバーは接続を待機状態のままにすることはありません。サーバーのパフォーマンスと有効性が大幅に向上します。
HTTP はステートレス プロトコルです。つまり、サーバーはクライアントとのトランザクションの状態を保持しません。これにより、サーバーのメモリ負荷が大幅に軽減され、より高速な応答速度が維持されます。HTTP はオブジェクト指向のプロトコルです。あらゆるタイプのデータ オブジェクトの転送を許可します。データの種類と長さによって送信データの内容とサイズを識別し、データの圧縮送信を可能にします。ユーザーがHTMLドキュメント内でハイパーテキストリンクを定義すると、ブラウザはTCP/IP プロトコルを通じて指定されたサーバーとの接続を確立します 。
HTTP は永続的な接続をサポートしており、HTTP/0.9 および 1.0 では、単一の要求/応答ペアの後に接続が閉じられます。HTTP/1.1 では、複数のリクエストに対して接続を再利用できるキープアライブ メカニズムが導入されました。このような永続的な接続により、クライアントは最初のリクエストを送信した後にTCP 3-Way ハンドシェイク接続を再ネゴシエートする必要がないため、リクエストの遅延を大幅に短縮できます 。もう 1 つのプラスの副作用は、通常、TCP のスロー スタート メカニズムにより、時間の経過とともに接続が高速になることです。
このプロトコルのバージョン 1.1 では、HTTP/1.0 に比べて帯域幅の最適化が強化されています。たとえば、HTTP/1.1 ではチャンク転送エンコーディングが導入され、永続的な接続でコンテンツをバッファリングするのではなくストリーミングできるようになりました。HTTP パイプラインによりレイテンシがさらに短縮され、クライアントは各応答を待つ前に複数のリクエストを送信できるようになります。プロトコルのもう 1 つの追加機能は、サーバーがクライアントが明示的に要求したリソースの部分のみを送信するバイト サービングです。
技術的に言えば、クライアントは特定のTCP ポート(通常、ポート番号は 80)でソケットを開きます。サーバーがこの既知のポートで接続をリッスンしている場合、接続は確立されます。次に、クライアントは接続経由でリクエスト メソッドを含むリクエスト ブロックを送信します。
HTTP 仕様では 9 つのリクエスト メソッドが定義されています。各リクエスト メソッドは、クライアントとサーバー間の異なる情報交換メソッドを指定します。一般的に使用されるリクエスト メソッドは GET と POST です。サーバーはクライアントのリクエストに従って対応する操作を完了し、それを応答ブロックの形式でクライアントに返し、最後に接続を閉じます。
動作モード
WWW では、「クライアント」と「サーバー」は、特定の接続中にのみ存在する相対的な概念です。つまり、ある接続内のクライアントが別の接続内のサーバーとして機能する場合があります。HTTPクライアント/サーバーモデルに基づく情報交換処理は、コネクションの確立、リクエスト情報の送信、レスポンス情報の送信、コネクションの切断の4つの処理に分かれます。
図 3 http の動作方法の 1 つ
HTTP はリクエスト/レスポンスのパラダイムに基づいています。クライアントはサーバーとの接続を確立した後、サーバーにリクエストを送信します。リクエストの形式は、統一リソース識別子、プロトコルのバージョン番号、その後にリクエスト修飾子を含む MIME 情報、クライアント情報、および考えられるコンテンツが続きます。リクエストを受信した後、サーバーは対応する応答情報を返します。その形式は、情報のプロトコル バージョン番号、成功コードまたはエラー コードを含むステータス行に、サーバー情報、エンティティ情報、および考えられるコンテンツを含む MIME 情報が続きます。実際、簡単に言うと、どのサーバーにもHTML ファイルに加えて、ユーザーのリクエストに応答するための HTTP常駐プログラムもあります。ブラウザは HTTP クライアントであり、サーバーにリクエストを送信します。ブラウザに開始ファイルが入力されるか、ハイパーリンクがクリックされると、ブラウザは HTTP リクエストをサーバーに送信します。このリクエストは、IPで指定されたアドレスに送信されます。アドレスのURLです。常駐プログラムはリクエストを受け取り、必要な操作を実行して、リクエストされたファイルを送り返します。このプロセスでは、ネットワーク上で送受信されるデータが 1 つ以上のデータ パケット(パケット) に分割され、各データ パケットには、送信されるデータと、データ パケットの処理方法をネットワークに指示する制御情報が含まれます。TCP/IP は各データ パケットの形式を決定します。事前に説明されていなかったら、情報は送信のために多くの小さな塊に分割され、その後再びまとめられることを知らないかもしれません。
多くの HTTP 通信はユーザー エージェントによって開始され、オリジン サーバー上のリソースのリクエストが含まれます。最も単純なケースは、おそらくユーザー エージェント (UA) とオリジン サーバー (O) 間の単一の接続を介して実行されます。
リクエスト/レスポンス チェーンに 1 つ以上の仲介者が存在する場合、状況は少し複雑になります。仲介者には、プロキシ、ゲートウェイ、トンネルの 3 つのタイプがあります。プロキシは、URIの絶対形式に基づいてリクエストを受け入れ、メッセージのすべてまたは一部を書き換えて、URI 識別子を使用してフォーマットされたリクエストをサーバーに送信します。ゲートウェイは、他のサーバーの上の層として機能する受信プロキシであり、必要に応じてリクエストを基礎となるサーバー プロトコルに変換できます。チャネルは、メッセージを変更しない 2 つの接続間の中継ポイントとして機能します。チャネルは、通信が仲介者 (ファイアウォールなど) を通過する必要がある場合、または仲介者がメッセージの内容を識別できない場合によく使用されます。
メッセージフォーマット
HTTP メッセージは、クライアントからサーバーへのリクエストと、サーバーからクライアントへの応答で構成されます。リクエストメッセージのフォーマットは以下の通りです: [6]
リクエストライン - 一般情報ヘッダ - リクエストヘッダ - エンティティヘッダ - メッセージボディ
リクエスト行はメソッド フィールドで始まり、URL フィールドと HTTP プロトコル バージョン フィールドが続き、CR LFで終わります。SP は区切り文字です。最終的な CRLF シーケンスで CF と LF が必須であることを除いて、その他はすべてオプションです。一般情報ヘッダー、リクエストヘッダー、エンティティヘッダーの詳細については、関連ドキュメントを参照してください。
応答メッセージのフォーマットは以下のとおりです。
ステータス行 - 一般情報ヘッダー - 応答ヘッダー - エンティティヘッダー - メッセージ本文
ステータスコード要素は3 桁で構成され、リクエストが理解されたか満たされたかを示します。原因分析は原文のステータスコードを簡単に説明したもので、ステータスコードは自動運用をサポートするために使用され、原因分析はユーザーのために使用されます。構文のチェックや表示にクライアントを使用する必要はありません。一般情報ヘッダー、応答ヘッダー、エンティティヘッダーの詳細については、関連ドキュメントを参照してください。
ステータスメッセージ
| 情報 |
説明する |
|---|---|
| 100 継続 |
サーバーはリクエストの一部のみを受信しますが、サーバーがリクエストを拒否しなくなったら、クライアントはリクエストの残りの送信を続行する必要があります。 |
| 101 スイッチングプロトコル |
サーバー変換プロトコル: サーバーはクライアントの要求に従い、別のプロトコルに変換します。 |
| 情報 |
説明する |
|---|---|
| 200 OK |
リクエストは成功しました (その後に GET および POST リクエストに対する応答ドキュメントが続きます)。 |
| 201 件が作成されました |
リクエストが作成され、新しいリソースが作成されます。 |
| 202 承認済み |
処理要求は受け付けられましたが、処理が完了していません。 |
| 203 権限のない情報 |
ドキュメントは正常に返されましたが、ドキュメントのコピーが使用されたため、一部の応答ヘッダーが正しくない可能性があります。 |
| 204 コンテンツがありません |
新しい書類はありません。ブラウザは元のドキュメントを表示し続ける必要があります。このステータス コードは、ユーザーがページを定期的に更新し、サーブレットがユーザーのドキュメントが十分に最新であると判断できる場合に役立ちます。 |
| 205 リセット内容 |
新しい書類はありません。ただし、ブラウザは表示内容をリセットする必要があります。ブラウザにフォーム入力コンテンツを強制的にクリアさせるために使用されます。 |
| 206 部分的なコンテンツ |
クライアントは Range ヘッダーを含む GET リクエストを送信し、サーバーがそれを完了します。 |
| 情報 |
説明する |
|---|---|
| 300 の複数の選択肢 |
複数の選択肢。リンクされたリスト。ユーザーはリンクを選択して目的地に到達できます。最大 5 つのアドレスが許可されます。 |
| 301 永久に移動しました |
リクエストされたページは新しい URL に移動されました。 |
| 302 件見つかりました |
リクエストされたページは、新しい URL に一時的に移動されました。 |
| 303 その他を見る |
要求されたページは別の URL で見つかります。 |
| 304 未変更 |
ドキュメントは期待どおりに変更されませんでした。クライアントはバッファリングされたドキュメントを持ち、条件付きリクエストを行います (通常は、クライアントが指定された日付より新しいドキュメントのみを必要とすることを示す If-Modified-Since ヘッダーを提供します)。サーバーは、バッファされた元のドキュメントが引き続き使用できることをクライアントに伝えます。 |
| 305 プロキシを使用する |
クライアントによって要求されたドキュメントは、Location ヘッダーで指定されたプロキシ サーバーを通じて取得される必要があります。 |
| 306 未使用 |
このコードは以前のバージョンで使用されていました。現在は使用されていませんが、コードはまだ保持されています。 |
| 307 一時リダイレクト |
リクエストされたページは一時的に新しい URL に移動されました。 |
| 情報 |
説明する |
|---|---|
| 400不正な要求 |
サーバーはリクエストを理解できませんでした。 |
| 401 不正 |
要求されたページにはユーザー名とパスワードが必要です。 |
| 401.1 |
ログインに失敗しました。 |
| 401.2 |
サーバーの設定によりログインが失敗します。 |
| 401.3 |
リソースに対する ACL 制限により、許可が取得できません。 |
| 401.4 |
フィルターの承認に失敗しました。 |
| 401.5 |
ISAPI/CGI アプリケーションの認証に失敗しました。 |
| 401.7 |
アクセスは、Web サーバー上の URL 承認ポリシーによって拒否されます。このエラー コードは IIS 6.0 に固有です。 |
| 402 支払いが必要です |
このコードはまだ利用できません。 |
| 403禁止します |
要求されたページへのアクセスは禁止されています。 |
| 403.1 |
実行アクセスは禁止されています。 |
| 403.2 |
読み取りアクセスは禁止されています。 |
| 403.3 |
書き込みアクセスは禁止されています。 |
| 403.4 |
SSLが必要です。 |
| 403.5 |
SSL128が必要です。 |
| 403.6 |
IPアドレスが拒否されました。 |
| 403.7 |
クライアント証明書が必要です。 |
| 403.8 |
サイトへのアクセスが拒否されました。 |
| 403.9 |
ユーザーが多すぎます。 |
| 403.10 |
無効な構成です。 |
| 403.11 |
パスワードの変更。 |
| 403.12 |
マッピングテーブルへのアクセスが拒否されました。 |
| 403.13 |
クライアント証明書が取り消されました。 |
| 403.14 |
ディレクトリのリストを拒否します。 |
| 403.15 |
クライアントのアクセス許可を超えました。 |
| 403.16 |
クライアント証明書が信頼できないか無効です。 |
| 403.17 |
クライアント証明書の有効期限が切れているか、まだ有効ではありません。 |
| 403.18 |
要求された URL は現在のアプリケーション プールでは実行できません。このエラー コードは IIS 6.0 に固有です。 |
| 403.19 |
このアプリケーション プール内のクライアントに対して CGI を実行することはできません。このエラー コードは IIS 6.0 に固有です。 |
| 403.20 |
パスポートのログインに失敗しました。このエラー コードは IIS 6.0 に固有です。 |
| 404お探しのページが見つかりませんでした |
サーバーは要求されたページを見つけることができません。 |
| 404.0 |
(なし) – ファイルまたはディレクトリが見つかりません。 |
| 404.1 |
要求されたポートでは Web サイトにアクセスできません。 |
| 404.2 |
Web サービス拡張機能のロック ポリシーは、このリクエストをブロックします。 |
| 404.3 |
MIME マッピング ポリシーがこのリクエストをブロックします。 |
| 405 メソッドは許可されていません |
リクエストで指定されたメソッドは許可されていません。 |
| 406 受け入れられません |
サーバーが生成した応答はクライアントにとって受け入れられませんでした。 |
| 407 プロキシ認証が必要です |
用户必须首先使用代理服务器进行验证，这样请求才会被处理。 |
| 408 Request Timeout |
请求超出了服务器的等待时间。 |
| 409 Conflict |
由于冲突，请求无法被完成。 |
| 410 Gone |
被请求的页面不可用。 |
| 411 Length Required |
"Content-Length"未被定义。如果无此内容，服务器不会接受请求。 |
| 412 Precondition Failed |
请求中的前提条件被服务器评估为失败。 |
| 413 Request Entity Too Large |
由于所请求的实体的太大，服务器不会接受请求。 |
| 414 Request-url Too Long |
由于url太长，服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时，就会发生这种情况。 |
| 415 Unsupported Media Type |
由于媒介类型不被支持，服务器不会接受请求。 |
| 416 Requested Range Not Satisfiable |
服务器不能满足客户在请求中指定的Range头。 |
| 417 Expectation Failed |
执行失败。 |
| 423 |
锁定的错误。 |
| 消息 |
描述 |
|---|---|
| 500 Internal Server Error |
请求未完成。服务器遇到不可预知的情况。 |
| 500.12 |
应用程序正忙于在Web服务器上重新启动。 |
| 500.13 |
Web服务器太忙。 |
| 500.15 |
不允许直接请求Global.asa。 |
| 500.16 |
UNC授权凭据不正确。这个错误代码为IIS 6.0所专用。 |
| 500.18 |
URL授权存储不能打开。这个错误代码为IIS 6.0所专用。 |
| 500.100 |
内部ASP错误。 |
| 501 Not Implemented |
请求未完成。服务器不支持所请求的功能。 |
| 502 Bad Gateway |
请求未完成。服务器从上游服务器收到一个无效的响应。 |
| 502.1 |
CGI应用程序超时。 |
| 502.2 |
CGI应用程序出错。 |
| 503 Service Unavailable |
请求未完成。服务器临时过载或宕机。 |
| 504ゲートウェイのタイムアウト |
ゲートウェイのタイムアウト。 |
| 505 HTTP バージョンはサポートされていません |
サーバーは、リクエストで指定された HTTP バージョンをサポートしていません。 |
バージョンナンバー
HTTP 要求および応答メッセージには HTTPバージョン番号が含まれており、HTTP バージョン番号の正しい使用と解釈、およびさまざまなプロトコル変換の HTTP 実装の相互運用性に関して混乱が生じています。HTTP バージョン番号の使用と解釈については、RFC 2145 に記載されています。