http

インターネットについて学ぶ上で、その歴史を理解することは、なぜインターネットが今日のように発展したのかを理解するのに役立ち、インターネットの探求に興味を持ち続けることができます。次の図は、インターネットの誕生から現在までの歴史を示しています。

httpとは何ですか？

HyperTextTransferProtocolは 直訳すると「ハイパーテキスト転送プロトコル」です。

1. ハイパーテキスト：テキスト、イメージ、動画、音声などを混ぜ合わせたもの。
2. 伝送：httpは「双方向プロトコル」であり、要求側と応答側の役割を限定することなく、要求側と応答側の間でデータを伝送するもので、伝送プロセスにはどのような「仲介者」が存在してもかまいません。
3. プロトコル：プロトコルは、2つ以上の参加者間の交換であり、プロトコルは、参加者間の合意と仕様です。したがって、httpプロトコルは、コンピュータの役割として理解することができ、コンピュータの使用は、コンピュータの交換や通信だけでなく、関連する様々な制御やエラー処理間の通信の規範を確立するための言語を理解することができます。

httpは、テキスト、イメージ、音声、動画などのハイパーテキスト・データを、コンピュータ世界の2点間で転送するための規約であり、仕様です。

httpに関連するいくつかの概念

ブラウザ: ブラウザは基本的にHTTPのリクエスト側であり、HTTPプロトコルを使用してネットワーク上の様々なリソースを取得します。HTTPプロトコルでは、ブラウザの役割は「ユーザーエージェント」と呼ばれ、HTTPリクエストを開始する訪問者の「代理人」として機能することを意味します。以下は、主要なブラウザとそのカーネルの一部です。サーバ： ハードウェアとは、物理的な形態のマシン、または「クラウド」の形態のマシンを意味します。ソフトウェア的な意味でのウェブサーバーは、ウェブサービスを提供するアプリケーションであり、通常はハードウェア的な意味でのサーバー上で動作します。ハードウェアの能力を利用して、多数のクライアントからのHTTPリクエストに応答し、動的な情報を返します。一般的なウェブサーバーにはApacheやNginxがあります。

CDN： CDNは、長距離ネットワークへのアクセスが遅いという問題を解決するために生まれたネットワークアプリケーションサービスで、「コンテンツデリバリーネットワーク」と呼ばれています。CDNの核心原理は「ローカルアクセス」で、HTTPプロトコルのプロキシとキャッシュ技術を使用します。CDNの核心原理は "近接アクセス "であり、HTTPプロトコルのプロキシとキャッシング技術を利用し、アクセスプロセスの時間コストを節約することで、ユーザーはインターネットサーフィンの際に元のウェブサイトに直接アクセスするのではなく、最も近いCDNノードにアクセスします。

Crawler（クローラー）:「ボット」の形をしたユーザーエージェントで、ウェブリソースに自動的にアクセスするアプリケーション。

web Service： W3Cによって定義されたアプリケーションサービス開発仕様で、クライアント・サーバー・マスター・スレーブ・アーキテクチャを使用。Webベースのサービスアーキテクチャ技術。

TCP/IP： 一連のネットワーク通信プロトコルの総称で、その中核となるのがTCPとIPプロトコル。TCPはIPプロトコルの上に位置し、「伝送制御プロトコル」を意味し、信頼性の高いバイトストリーム形式の通信を提供するためにIPプロトコルをベースにしています、TCPプロトコルは、「伝送制御プロトコル」を意味するIPプロトコルの上に位置し、IPプロトコルに基づいた信頼性の高いバイトストリーム形式の通信を提供します。インターネット上のHTTPプロトコルはTCP/IPの上で動作するため、HTTPはより正確に「HTTP over TCP/IP」と呼ぶことができます。

DNS：Domain Name System（ドメイン・ネーム・システム）の略。DNSでは、「ドメイン名」は「ホスト名」とも呼ばれます。ドメイン名は". "で区切られます。ドメイン名は". "で区切られた複数の単語に分かれており、左から右にレベルが上がっていき、一番右が「トップレベルドメイン」と呼ばれます。しかし、TCP/IPプロトコルを使って通信するためには、やはりIPアドレスが必要なので、ドメイン名を変換して実際のIPに「マッピング」する必要があり、これを「ドメイン名解決」と呼びます。

URIには主に3つの基本構成要素があります：

• プロトコル名：すなわち、リソースへのアクセスに使用されるべきプロトコル
• Hostname［ホスト名］：インターネット上のホストの識別子で、ドメイン名またはIPアドレス。
• パス: ホスト上のリソースの場所。複数のディレクトリを区切るには "/" を使用します。

HTTPS： 正式名称は "HTTP over SSL/TLS "です。つまり、SSL/TLSプロトコル上で動作するHTTPのことで、TCP/IPの上に構築された暗号化通信を担うセキュリティプロトコルです。"http+ssl/tls+tcp/ip "に相当します。

Proxy (プロキシ): HTTPプロトコルで、リクエスト側とレスポンス側をつなぐもので、クライアントのリクエストとサーバーのレスポンスの両方を転送する "リレー "の役割を果たします。

一般的なエージェントの種類はたくさんあります：

• 匿名プロキシ: プロキシされているマシンを完全に「隠し」、外部に見えるのはプロキシサーバだけです；
• 透明なプロキシ：その名が示すように、送信プロセスにおいて「透明でオープン」であり、外部はプロキシとクライアントの両方を知っています；
• フォワードプロキシ：クライアントに近く、クライアントに代わってサーバにリクエストを送信します；
• リバースプロキシ：サーバーサイドに近く、サーバーに代わってクライアントのリクエストに応答します；

ネットワークのレイヤーモデル

ネットワーク・レイヤリング・モデルのレイヤは下から数えますが、一般的によく使われるのはTCP/IPの4レイヤ・モデルで、これも初期のレイヤリング・モデルです。

• 第1層はリンク層で、IPプロトコルが配置されています。IPプロトコルは「IPアドレス」という概念を定義しているため、「リンク層」に基づいてMACアドレスをIPアドレスに置き換え、IPアドレスをMACアドレスに変換することでこのネットワーク内のデバイスを見つけることができます。これはISOモデルの「ネットワーク層」に相当します。
• 第3層は、"トランスポート層 "と呼ばれるので、次の3つの層は非常によく基礎を築くために、この層では "花 "に、特定のアプリケーション指向のプロトコルの様々なされています。例えば、Telnet、SSH、FTP、SMTPなど、そしてもちろんHTTP。 セッション層"、"表現層"、"アプリケーション層 "のISOモデルに対応します。

TCP/IPファミリーのプロトコルを使用したネットワーク通信は、階層的に通信を行います。

ドメイン名

ドメイン名は階層構造になっており、". "で区切られた単語の文字列です。一番右が「トップレベルドメイン」、その次が「セカンドレベルドメイン」と呼ばれ、左へ行くほど階層が低くなっていきます。一番左はホスト名で、通常、WWWサービスなら "www"、メールサービスなら "mail "など、ホストの目的を示すために使われますが、これは絶対的なものではありません。

プロトコル・ホスト・ドメイン名の間の階層は、次の例で理解できます。ドメイン名は人の名前のようなもので、名前の鍵は覚えやすくすることです。IDを識別するだけでなく、ドメイン名はIPアドレスの代わりにもなります。

DNS

多くの場合、ウェブサイトにアクセスするためにドメイン名を使用しますが、実際にはネットワーク内のプロジェクトを見つけるために、リソースを見つけるためにIPを使用することです、ドメイン名は、正しいリソースを取得するためにIPアドレスに解決する必要があります。

DNSのコアシステムは、基本的にドメイン名の構造に対応する3層のツリー状の分散サービスです：

DNSは素晴らしい能力を持つグローバルサービスですが、世界中のインターネットユーザーがこのサービスを利用しているという事実は、サーバーに大きな負担をかけています。コアDNSシステム以外では、ドメイン名解決への圧力を軽減し、より速く結果を得るための2つの方法があり、基本的な考え方は「キャッシュ」です。

DNSの解決結果は、会社独自のDNSサーバー、またはオペレーティングシステムのキャッシュ、hostsファイルに保存することができますドメイン名の解決作業の多くは、直接ローカルまたはローカルでルートDNSサーバーを要求する必要はありません解決することができますだけでなく、ユーザーの利便性だけでなく、DNSサーバーのすべてのレベルの圧力を軽減し、効率が大幅に改善されます。

ドメイン名とDNSサーバーに基づいて、リダイレクトが可能です。ドメイン名はIPアドレスに置き換わるため、外部ドメイン名は変更せずに、ホストIPを自由に変更することができます。ホストがオフラインになったり、移行しなければならない状況になった場合、ドメイン名が別のマシンを指すようにDNSレコードを変更することができます。

DNSはドメイン名解決の段階でロードバランシングを実行することができます。

• 最初の方法では、ドメイン名解決は複数のIPアドレスを返すことができるため、ドメイン名は複数のホストに対応することができ、クライアントは複数のIPアドレスを受け取った後、負荷分散を達成するために、ポーリングアルゴリズムを使ってサーバへのリクエストを開始することができます。
• 2つ目の方法として、ドメイン名解決は、クライアントに最も近いホスト、または現在のサービス品質が最も良いホストを返すように内部ポリシーで構成することができます。

HTTP/1.

先に述べたように、HTTPとはハイパーテキスト転送プロトコルのことで、テキスト、イメージ、音声、動画などのハイパーテキスト・データをコンピュータ世界の2点間で転送するための規約であり仕様です。ネットワークの階層モデルについて学んだ後、HTTPがアプリケーション層のプロトコルであることを学びました。このセッションでは、HTTPの世界への正式な飛び込みが始まります。

HTTP

HTTPプロトコルのリクエスト・メッセージとレスポンス・メッセージは、基本的に同じ構造を持ち、3つの主要な部分で構成されています：

• 開始行( )：リクエストまたはレスポンスの基本情報を記述します；
• ヘッダ・フィールド・セット( )：キー・バリュー形式のメッセージのより詳細な説明；
• メッセージ本文（）：実際に送信されるデータ。プレーンテキストである必要はなく、イメージや動画などのバイナリデータでもかまいません。

リクエストライン

リクエスト行は一般的に、クライアントがサーバのリソースをどのように 操作したいかを記述するために使われ、通常3つの部分で構成されます。通常は空白で区切られ、CRLF改行で終わります。

ステータス行

ステータス行は一般的に、クライアントのリクエストに対するサーバーの応答のステータスを記述するために使用され、また、一般的に3つの部分で構成されます。

ヘッダーフィールド

リクエスト行またはステータス行とヘッダーフィールドのセットは、HTTP メッセージの完全なリクエストヘッダまたはレスポンスヘッダを構成します。HTTP ヘッダフィールドは非常に柔軟で、標準の Host や Connection などの既存のヘッダを使うだけでなく、カスタムヘッダを追加することもできます。しかし、ヘッダーフィールドの使用には以下の点に注意する必要があります：

• フィールド名は大文字と小文字を区別しません。例えば、"Host "は "host "と書くこともできますが、読みやすくするために頭文字を大文字にした方がよいでしょう；
• ハイフン"-"は使用できますが、アンダースコア"_"は使用できません。たとえば、"test-name "は正当なフィールド名ですが、"test name "や "test_name "は正しくないフィールド名です；
• フィールド名の直後にはスペースを入れずに": "を続けなければなりません。": "の後のフィールド値には複数のスペースを入れることができます；
• フィールドの順番に意味はなく、セマンティクスに影響を与えることなく任意に並べることができます；
• Set-Cookieのように、フィールド自体のセマンティクスがそれを許さない限り、原則的にフィールドを複製することはできません。

HTTPリクエストメソッド

現在HTTP/1.1では、単語が大文字でなければならない以下の8つのメソッドが指定されています。

• GET：リソースの取得。データの読み取りやダウンロードと理解できます；
• HEAD: リソースのメタ情報を取得します；
• POST：リソースにデータを送信します。これはデータの書き込みやアップロードに相当します；
• PUT：POSTに似ています；
• DELETE：リソースを削除します；
• CONNECT：特別な接続トンネルを作成します；
• OPTIONS: リソースに適用できるメソッドをリストします；
• TRACE: リクエストとレスポンスの伝送経路をトレースします。

これらはよく使われる方法の一部で、よく学ぶ必要があります。

• GET HEAD

  1. GETはサーバーにリソースを要求するのに適しており、一般的にurl上のデータを運びます。
  2. HEADはGETリクエストの簡略版に似ており、サーバーはHEADリクエストを受け取るとレスポンスヘッダのみを返し、レスポンスヘッダはGETと同じです。

• POST PUT

  1. POSTはデータをサーバーに送信するために使用され、ボディにデータを運びます。
  2. PUTはPOSTメソッドに似ており、サーバーにデータを送信することもできます。

• GETPOSTとの違い

ここで特に問われやすいのが、GETとPOSTの違いですが、この作品でもそれについて詳しく書きたいと思います。以下は私の個人的な理解に基づいています。

1.サイズ： GETは通常、URL内のデータを運び、POSTはボディにデータを置くので、URLの長さに関するブラウザの制限のために、GETリクエストで運ぶことができるデータのサイズは、一般的に2キロバイト以下です。 ChromeブラウザのURLの長さの制限が2MBに増加したことは注目に値しますが、URLの長さの互換性を考慮すると、最大限の最小基準に基づいている必要があります。最小限の基準は、ブラウザの制限に加えて、メインであり、また、考慮サーバー側の制限を取る必要があります。

2.セキュリティ： セキュリティは、リクエストメソッドは、サーバーのリソースに影響を与えることを指しますGETメソッドは、読み取り専用ですので、限り、サーバーが "誤解 "クライアントの要求をしないように、サーバー上のデータは安全です。POSTは、データの "追加、削除、変更 "操作のサーバー側になるので、それは安全ではありません！

3.パワー： パワーは、操作が何度も繰り返されることを意味し、効果は同じです。明らかに、GETメソッドは、リソースの読み取り専用操作を行うためにサーバー上にのみあるので、それはidempotentです。 RFCのPOSTは、 "データの追加または提出 "として定義されており、データの複数の提出は、複数のリソースを作成するので、それはidempotentではありません。

4.キャッシュ： これはそのメソッドがキャッシュ可能であることを意味し、ブラウザの実装の大半はGETキャッシュしかサポートしていません。GETは読み込みなので、GETで要求されたデータをキャッシュすることができます。一方POSTは冪等性ではないので、自由に複数回実行することはできません。したがって、キャッシュすることはできません。

URI

URI（統一資源識別子）は、ブラウザのアドレスバーに表示されることが多いため、一般に「ウェブアドレス」として知られています。ブラウザのアドレスバーに表示されることが多いため、一般に「ネットワークアドレス」、略して「URL」として知られています。 URIはウェブアドレスと全く同じではなく、URLとURNの2つの部分を含んでおり、HTTPの世界で使われているURLは実際にはHTTPの世界では、ウェブアドレスは実際にはURL - Uniform Resource Locatorです。HTTP の世界では、ウェブアドレスは実際には URL - Uniform Resource Locator - です。

URIは基本的に、リソースの場所や名前を一意に識別する文字列です。上のイメージは完全なURIで、詳細な構造は以下の通りです。

スキーム プロトコル名は、リソースがどのプロトコルでアクセスされるべきかを示します。最も一般的なのはもちろん "http "で、これはHTTPプロトコルが使用されることを意味します。暗号化された安全なHTTPSプロトコルを意味する "https "もあります。その他、ftp、ldap、file、newsなど、あまり一般的ではないスキームもあります。

スキームの後に3文字「://」で 区切られる「://」 セパレータは、スキームとそれに続くものを区切ります。特に意味はありません。

user:passwd@ ホストにログインするためのユーザ名とパスワードを示す ID 情報ですが、この形式は機密情報を平文で公開することになり、重大なセキュ リティ上のリスクがあるため、現在では推奨されていません。

host:port リソースがあるホストのホスト名で、通常は「host:port」、つまりホスト名＋ポート番号の形です。

path リソースの場所を示すパスで、ファイルシステムの「ディレクトリ」に似ており、通常は「/」で始まります。

query クエリパラメータ。"?" で始まります。で始まり、"? "を含まないクエリパラメータ。queryは複数の "key=value "文字列を"&"文字で連結したもので、ブラウザやサーバは長いクエリパラメータ文字列を理解しやすいようにパースすることができます。ブラウザやサーバは、クエリパラメータの長い文字列を、このフォーマットで理解可能な辞書や連想配列にパースすることができます。

フラグメント 識別子（#fragment fragment identifier）は、URIで指定されたリソース内の「アンカー」であり、ブラウザはリソースを取得した後、この識別子で指定された場所に直接ジャンプすることができます。ただし、フラグメント識別子はブラウザなどのクライアントのみが使用でき、サーバーからは見えません。

URIでは、唯一のASCIIコードを使用することができ、文字セットと特殊文字の外側のASCIIコードは、特殊な操作を行うために、彼らはURIのセマンティクスに変換されますフォームと競合しません。これは、一般的に "エスケープ "として知られているRFC仕様で "エスケープ "と "アンエスケープ "と呼ばれています。URIのエスケープのルールはやや「単純」で、非ASCII文字や特殊文字を16進数のバイト値に変換し、その前に「%」をつけます。

ステータスコード

HTTPステータス行のHTTPメッセージ部分では、このセクションでステータスコードのステータス行を参照してください。

ステータスコードは10進数で表されます。RFC規格では、ステータスコードを5つのカテゴリーに分類しており、番号の1桁目が分類を表すのに使われます：

• 1×××：現在プロトコル処理の中間状態であり、以降の処理が必要であることを示すプロンプトメッセージ；
• 2×××：成功、メッセージは正しく受信され処理されました；
• 3×××: リダイレクト(Redirection): リソースの場所が変わり、クライアントがリクエストを再送 する必要がある場合；
• 4×××：クライアントエラー、リクエストメッセージに誤りがあり、サーバーで処理できません；
• 5××：サーバーエラー、サーバーがリクエストを処理中に内部エラーが発生しました。

1 x x

1××クラスステータスコードは、プロトコル処理の中間状態であるリマインダーメッセージに属し、実際にはほとんど使用されません。

「100継続 "それがより頻繁に接触されるため、POSTリクエストでは、サーバーに大きなファイルを送信するかどうかを要求ヘッダの使用を受け入れることができるかどうかをサーバーに依頼する必要があります期待：100-continue。このプロセスは、多くの場合、POSTとしてサーバーに2つのTCPパケットを送信するステートメントのソースと呼ばれますが、クライアントはまだのために待機する必要はありません。サーバーの応答を待つ必要はありませんが、一定期間内に否定的な答えを受信しなかった場合でも、サーバーにデータの本体を送信します。

2 x x

2××クラスのステータスコードは、サーバーがクライアントのリクエストを受信し、正常に処理したことを示します。

「200 OK" は最も一般的な成功ステータスコードで、サーバーがクライアントの期待通りの結果を返したことを示します。

「204 No Content "も非常に一般的な成功ステータスコードで、基本的には "200 OK "と同じ意味ですが、レスポンスヘッダの後に本文データがありません。ですから、ウェブサーバにとっては、200と204を正しく区別する必要があります。

"206 Partial Content" は HTTP チャンクダウンロードや断続的な転送の基本で、クライアントがリソースの一部に対して "range request" を送信したときに発生します。200と同様、サーバーがリクエストを正常に処理したことを意味しますが、ボディのデータはリソースのすべてではなく、その一部です。ステータスコード206は通常Content-Rangeというヘッダフィールドを伴います。これはクライアントが確認できるように、応答メッセージ中のボディデータの特定の範囲を示すもので、例えば "Content-Range: bytes 0-99/2000 "のように、2000バイトのうち最初の100バイトが取り出されることを意味します。バイトです。

3 x x

3 ××クラスのステータスコードは、クライアントがリソースの変更を要求したことを示し、クライアントはリソースを取得するためにリクエストを再送するために新しいURIを使用する必要があり、これは通常、有名な301、302ジャンプを含む "リダイレクト "と呼ばれています。

"301 Moved Permanently"は、要求されたリソースがもはや存在せず、新しいURIで再度アクセスする必要があることを意味します。

"302 Found "は、かつては "Moved Temporarily "というフレーズで表現され、一般に「一時的なリダイレクト」として知られています。これは、リクエストされたリソースはまだ存在するが、一時的に別のURIからアクセスする必要があることを意味します。

"304 Not Modified" は興味深いステータスコードで、キャッシュ制御の目的でリソースが変更されていないことを示すために If-Modified-Since のような条件付きリクエストで使われます。これは通常のジャンプの意味ではなく、「キャッシュされたファイルへのリダイレクト」と解釈できます。

4 x x

4 × ×クラスのステータスコードは、クライアントが送信した要求メッセージが正しくないことを示し、サーバーはそれを処理することはできません、それは "エラーコード "の本当の意味です。

"400 Bad Request" はリクエストメッセージにエラーがあることを示す一般的なエラーコードで、ステータスコードの明確な意味を持たない一般的なエラーです。

「403 Forbidden "は、実際にはクライアントのリクエストのエラーではなく、サーバーがリソースへのアクセスを禁止したことを示します。

404 Not Found」の本来の意味は、サーバーでリソースが見つからなかったので、クライアントに提供できなかったというものです。しかし、現在では「乱用」され、サーバーが「不幸」である限り、404を与えることができ、バックが本当に見つからないのか、何か他の理由があるのかを知る方法がないため、ある意味、403よりもさらに迷惑です。

5 x x

5 × ×クラスのステータスコードは、クライアントの要求メッセージが正しいことを示しますが、内部エラーの処理のサーバーは、応答データを返すことはできませんする必要があります、"エラーコード "のサーバー側です。

"500 Internal Server Error" は 400 と似ていて、サーバーに何が起こったのか正確にはわからない一般的なエラーコードです。しかし、これはサーバにとっては良いことだと考えるべきで、サーバ内部で何が起こっているのか、例えばうまくいかなかった関数のコールスタックなどの詳細な情報を外部に伝えることは、通常はお勧めできません。デバッグには不向きですが、ハッカーによる盗み見や解析を防ぐことができます。

"501 Not Implemented "は、クライアントが要求した機能がまだサポートされていないことを意味します。このエラーコードは500より少しマイルドで、"Coming soon, stay tuned！このエラーコードは500より少しマイルドで、"Opening soon, stay tuned "の意味も似ていますが、いつ「オープン」になるかはわかりません。

"502 Bad Gateway" は通常、ゲートウェイやプロキシとして動作するサーバが返すエラーコードで、サーバ自体は正常に動作しており、バックエンドサーバへのアクセス時にエラーが発生したことを示しますが、エラーの正確な原因も不明です。

503 Service Unavailable」は、サーバーが現在ビジー状態であり、しばらくの間サービスに応答できないことを意味します。 インターネットサーフィンをしているときに時々遭遇する「Network service is busy, please try again later」というメッセージは、ステータスコード503です。503は「一時的な」ステータスであり、数秒後にはサーバーがそれほどビジー状態でなくなり、サービスの提供を継続できる可能性があります。は "一時的な "ステータスで、数秒後にはサーバはそれほど忙しくなくなり、サービスを提供し続けることができる可能性が高いので、503応答メッセージは通常 "Retry-After "フィールドも持っています。というフィールドがあります。

HTTP

1. 柔軟性と拡張性：このようなスペースで単語を区切り、改行でフィールドを区切り、"ヘッダ+ボディ "など、メッセージの基本的な形式のみの誕生の冒頭でHTTPは、メッセージの様々なコンポーネントは、厳密な構文を行うことはありませんし、制限のセマンティクスは、自由に開発者によってカスタマイズすることができます。そして、これらのRFC文書は、実際には、好循環の "実践から実践へ "を達成するために、既存の "認識と標準化 "の拡張として理解することもできます。
2. 信頼できる転送: HTTPプロトコルはTCP/IPをベースにしており、TCP/IP自体が "信頼できる "トランスポートプロトコルであるため、HTTPはこの特性を受け継ぎ、リクエスト側とレスポンス側の間で "信頼できる "データ転送を行うことができます。HTTP
3. アプリケーションレイヤープロトコル：HTTPは、任意のヘッダーフィールドやエンティティデータを伝送できるメッセージの構造、コネクションコントロール、キャッシュプロキシなど便利で使いやすい機能を備えているため、「何でも屋」的なプロトコルであり、過剰なパフォーマンスを求めない限り、HTTPは様々なニーズを満たすためにほとんど何でも提供できます。
4. リクエスト-レスポンス: リクエスト-レスポンスモデルは、HTTP プロトコルの最も基本的な通信モデルであり、一般に "one sends, one receives" として知られています。リクエスト-レスポンスモデルはまた、HTTP プロトコルにおける 2 つの通信相手の立場を明確にします。 リクエスト側は常に最初に接続とリクエストを開始し、これはプロアクティブであり、レスポンス側はリクエストを受信した後にのみ返信することができ、これはパッシブであり、リクエストがなければ何もしません。
5. ステートレス： "状態 "は、実際には通信プロセスにおけるいくつかの変更を記録し、クライアントまたはサーバーに格納されているいくつかのデータやフラグです。HTTPは、プロトコル全体で任意の "状態 "を指定しませんが、HTTPは "柔軟性と拡張性 "であることを忘れないでください。"柔軟性と拡張性 "は、標準では "状態 "を提供していませんが、この機能を追加するには、"パッチ "を与えるために、プロトコルのフレームワークにすることができます。
6. プレーンテキスト伝送：「プレーンテキスト」とは、バイナリ・データを使う代わりに、プロトコルのメッセージが単純で読みやすいテキスト形式であることを意味します。
7. セキュリティの欠如：セキュリティには様々な側面がありますが、平文は「機密性」という点では欠点の一つに過ぎず、HTTPは「認証」や「完全性のチェック」という点でも欠けています。

HTTP用エンティティデータ

データタイプ

Accept

TCP/IPスタックでは、データはHeader+bodyの形で転送されます。トランスポート層のプロトコルでは、データが何であるかを気にする必要はありませんが、アプリケーション層ではデータの型を上位層に伝える必要があります。初期の HTTP プロトコルでは、追加のデータ型情報はなく、送信されたデータはすべてクライアントプログラムによって HTML ドキュメントとして解釈されます。マルチメディアデータ型をサポートするために、HTTP プロトコルは MIME (Multipurpose Internet Mail Extensions Multipurpose Internet Mail Extensions type) に付属するドキュメントを使用します。MIME（Multipurpose Internet Mail Extensions）は、データ型を識別するために文書に添付されるデータ型情報を指定します。MINEはデータを7つのカテゴリに分け、type/subtypeの形式でそのサブカテゴリに細分化します。例えば、text/html、text/css、image/jpeg、applaction/jsonなどがよく使われます。

Accept-encoding

さらに、HTTPプロトコルはデータの圧縮フォーマットを開発しました。

• gzip: GNU zip圧縮フォーマットで、インターネットで最もよく使われている圧縮フォーマットです；
• deflate: gzipに次いで人気のあるzlib圧縮フォーマット；
• br：HTTP専用に最適化された新しい圧縮アルゴリズム。

Accept-Language

クライアントが理解できる自然な言語をマークアップし、例えば「,」を区切り文字として複数のタイプをリストアップすることもできます：Accept-Language: ja-JP, zh, en

リクエストヘッダにおけるデータ型の表現

HTTP

• データ圧縮
  
  先に述べたaccept-encodingリクエストヘッダは、大容量のファイルを送信するためのソリューションとみなすことができる、サーバーはcontent-encoding応答ヘッダにブラウザがサポートするデータ圧縮方法を選択することができますし、元のデータ圧縮は、クライアントに返されます。欠点は、このアプローチは、イメージや音声などのマルチメディアデータ自体が高度に圧縮されているテキスト圧縮率にのみ良いですが、それについて何かを行うことはできませんされていることです。
• チャンキング
  
  Transfer-Encoding: chunkedHTTPヘッダは、メッセージの本体部分が一度に送信されないことを意味しますが、多くのチャンクに分割されます。Transfer-Encoding: chunkedとContent-Lengthこれら2つのフィールドは、相互に排他的である、つまり、応答メッセージ、これら2つのフィールドが同時に表示されないことができ、メッセージの送信への応答は、既知の長さ、または未知の長さのいずれかである、この点は覚えておく必要があります。
• 範囲リクエスト
  
  大きなファイルの断片を取得したい場合、チャンキングという選択肢はありません。HTTPプロトコルは範囲リクエストという概念を導入しており、クライアントはファイルの一部だけを取得することができます。クライアントはまず HEAD リクエストを送って、サーバが範囲リクエストをサポートしているかどうかを確認し、サーバは Accept-Ranges レスポンスヘッダで範囲リクエストをする能力があるかどうかをクライアントに伝えなければなりません。リクエストヘッダの Ranges は HTTP の範囲リクエストのための特別なフィールドで、値は x ~ y の範囲を示す bytes=x-y の形式です。サーバーがRangesリクエストヘッダを受信すると、最初にx-yの範囲が正当であることを確認し、読み取りオフセットの計算が続き、206ステータスコードとファイルの読み取りを返し、最後にContent-Rangeで応答ヘッダに実際のリターンオフセットとバイトの総数x-y /長さの形式を示します。
  
  multipart/byterangesRangeリクエストはヘッダーで複数のx-y定義もサポートしますが、この場合はメッセージが複数のセグメントで構成されていることを示す特別なMIMEタイプが必要です。

HTTP接続管理

httpの通信プロセスは、リクエスト/アンサーモードを取り、http0.9/1.0の期間では、リクエストの各開始は、接続を確立する必要があります->データを送信->切断、全体の要求プロセスは非常に短いため、初期のhttpはまた、短いリンクなしリンクプロトコルとして知られています。TCPレジューム接続は3ハンドシェイクと4波を通過するので、全体のプロセスは、HTTPからの単純な要求は、通常、わずか2 RTTを取りながら、3 RTTを取り、時間の60％が無駄になります。

: keep-alive

HTTP1.1では、Keep-aliveとしても知られている長い接続の概念を導入しました。複数のHTTPリクエストは、長い接続を介して単一のTCP接続を確立することによって送信することができます。しかし、接続が生きているので、それが閉じられていない場合、それは、サービスがタイムリーに本当の要求に応答することができませんで、その結果、サーバーのリソースをたくさん占有するので、また、タイムリーに接続を閉じる必要があります。クライアントリクエストヘッダーに Connection: close フィールドを追加することで、積極的にコネクションを閉じることができます。サーバ側は通常、積極的にコネクションを閉じることはしませんが、 持続時間やリクエスト数などを設定することで、コネクション切断の条件を取り決めることもできます。

キューヘッドブロッキング

http1.1パイプラインも導入された。つまり、同じTCPコネクション上で次のリクエストは、前のリクエストに対する応答を待たずに行えるが、クライアントは依然として通常の順序で応答を受け取る。httpプロトコルのリクエストレスポンスモデルに基づいて、シリアル要求キュー（）の形成は、キュー要求の頭がブロック状態である場合、リクエストの背面は、時間の長い期間の結果として適切に応答することはできませんパフォーマンスの無駄です。

同時接続とドメイン名のスライスは、キューブロッキング対象の最適化戦略の先頭には、ブラウザの制限は、各クライアントが同時に6〜8接続を確立することができますが、また、複数のドメイン名は、接続の実際の数よりも多くなるように、同じサーバーを指すことができますアイデアの質を解決するための量です。

リダイレクト

ブラウザにURLを入力してエンターキーを押すと、入力されたアドレスにページがジャンプします。ブラウザはHTTPリダイレクトであるパッシブジャンプもサポートしています。

ステータスコード

前の HTTP ステータスコードで、3XX はリダイレクトを意味します。以下は、各ステータスコードの意味の詳細な説明です。

恒久的なリダイレクトは、ドメイン名のオフライン、ドメイン名の移行やその他の理由かもしれない、元のアドレスはもはや維持されません。この時点で、リダイレクトのブラウザは、同時にリダイレクト後のアドレスを記録するために、ドメイン名への次の訪問は自動的に新しいURIにアクセスします。

一時的なリダイレクトを指し、サーバーのメンテナンス、一時的な閉鎖やその他の理由、新しいアドレスへの一時的なジャンプかもしれない、この時点でブラウザは、元のアドレスがまだ有効であること、リダイレクトされたアドレスを記録されません、次の訪問はまだ元のアドレスを訪問することが好ましいです。

302と似ていますが、リダイレクト後のリクエストは、POST/PUTの繰り返し操作を避けるために、結果ページにアクセスするGETメソッドに変更する必要があります。

302と似ていますが、リダイレクトされたリクエストのメソッドとエンティティの変更は許可されていません。

307に似ていますが、リダイレクト後のリクエストの変更を許可しませんが、301の "恒久的なリダイレクト "の意味です。

あなたは、アドレスバーにbing.comを入力することができ、ブラウザコンソールのステータスは以下のとおりです。

クライアントがリダイレクトを処理する方法

ブラウザのアドレスバーにbing.conと入力すると、ステータスコードが以下のように表示されます：

ブラウザはレスポンスを受信した後、レスポンスヘッダのLocationフィールドに基づいてリダイレクト先のアドレスを決定し、パッシブジャンプを行います。

リダイレクトは非常に汎用性が高い反面、多くの問題があります。

• 最初の問題は「パフォーマンスの低下」です。明らかに、リダイレクトのメカニズム上、1つのホップでリクエストとレスポンスの時間が2回になり、通常の訪問よりも1回多くなります。301/302メッセージは小さなものですが、多数のホップがサーバに与える影響は無視できません。サイト内リダイレクトは長いコネクションで多重化できますが、サイト外リダイレクトは2つのコネクションが必要です。
• 2つ目の問題は、A->B->C->Aのような循環リダイレクトです。そのため HTTP プロトコルでは、ブラウザが "循環リダイレクト" を検出する機能を持たなければならず、このような状況を発見した場合はリクエストの送信を停止し、エラーメッセージを出すように規定しています。

cookie

HTTPは "ステートレス "であり、これには長所と短所があります。利点は、サーバーに状態の違いがなく、容易にクラスタ化できることですが、欠点は、状態を記録する必要のあるトランザクション操作をサポートできないことです。良い点は、HTTPプロトコルが拡張可能であり、後に発明されたクッキーがHTTPに「メモリ」を追加したことです。

クッキーはHTTPヘッダーフィールドにも存在します。サーバはクライアントを識別するためにset-cookieを使うことができ、クライアントはリクエスト時にサーバにその情報を伝えるためにcookieを運びます。cookieフィールドはkey=valueの形式で保存され、ブラウザはcookieフィールドに複数のデータのペアを;で分割して保存することができます。

クッキーは主に3つの方法で使用されます：

• セッション状態管理
• パーソナライゼーション
• ブラウザの行動追跡

関連属性

ライフサイクル

期限切れは一般的に「有効期限」と呼ばれ、「期限」と解釈できる絶対的な時点です。

Max-Age は秒単位の相対的な時間を使用します。 ブラウザはメッセージを受信した時点に Max-Age を追加して、有効期限の絶対的な時間を取得します。

Expires と Max-Age は同時に存在することができ、二つの有効期限時間が同じでない場合、ブラウザは Max-Age を優先して有効期限を計算します。サーバが Max-Age、Expires を設定しないか、フィールドの値が 0 の場合、クッキーはキャッシュできませんが、セッション中は利用可能であり、ブラウザのセッションは閉じられるので、ユーザの情報をクッキーで記録することができます。

スコープ

Domain と Path はクッキーが属するドメイン名とパスを指定します。 クッキーを送る前に、ブラウザは URI から host と path の部分を抽出し、それらをクッキーの属性と比較します。もし条件が満たされなければ、クッキーはリクエスト・ヘッダで送信されません。通常、Path は単に「/」か、単に省略されます。これは、ドメイン名の下のどのようなパスでもクッキーの使用が許可されることを意味します。

セキュリティ

HttpOnlyとは、このクッキーがブラウザのHTTPプロトコルのみを介して送信され、他の手段ではアクセスできないことを意味します。これは「クロスサイト・スクリプティング」攻撃を防ぐ効果的な方法でもあります。

SameSite は「クロスサイト・リクエスト・フォージェリ」攻撃を防ぐことができます。SameSite = strict は、リンクを飛び越えるときにドメインを越えてクッキーが転送されることを禁止することを意味します。デフォルト値は none で、これはクッキーの運搬と転送に制限がないことを意味します。

セキュアとは、このクッキーが HTTPS プロトコルを使って暗号化されてのみ送信されることを意味し、プレーンテキストの HTTP プロトコルは送信を禁止します。しかしクッキー自体は暗号化されず、ブラウザにプレーンテキストで存在します。

HTTPキャッシュ制御

サーバーキャッシュ制御

ブラウザはリソースをキャッシュし、次の再利用を待ちます。これがクライアントサイドキャッシュです。リソースの有効期限を示すためにサーバーが使用するヘッダーフィールドはCache-Controlで、その中の値max-age=xxxはリソースの有効期限です。

さらに、ブラウザがキャッシュをどのように使用すべきかをより正確に示すために、応答メッセージで他の値を使用することもできます：

no-store：キャッシュは許可されず、秒ページのような非常に頻繁に変更されるデータに使用されます；

no-cache：キャッシュは許可されていますが、使用するにはサーバー上で有効期限が切れていないことを確認する必要があります；

must-revalidate: キャッシュの有効期限が切れていなければ使い続けることができますが、切れている場合は検証する必要があります。

クライアント側のキャッシュ制御

ブラウザはCache-Controlも送ることができます。つまり、リクエスト側と応答側の双方がこのフィールドをキャッシュ制御に使うことができ、キャッシュの使用ポリシーについてお互いに交渉することができます。Cache-Control はブラウザがフォワード、バックワード、リダイレクトをするときに 有効になり、from disk cache という語を持つ応答ヘッダは、ブラウザが リクエストを送らずにローカルキャッシュを直接使ったことを示します。

条件付きリクエスト

Cache-Control:no-cacheブラウザがページをリフレッシュするとき、リクエストヘッダに追加するのと同じことなので、ページがリフレッシュされたときにもサーバにリクエストを送り、キャッシュをうまく利用できません。そのため HTTP プロトコルでは、"If" で始まる一連の "条件付きリクエスト" フィールドを定義し、リソースが期限切れかどうかをチェックするために特別に使用しています。

条件付きリクエストには5つのヘッダーフィールドがあり、最もよく使われるのは if-Modified-Since と If-None-Match です。最初のレスポンスメッセージであらかじめ Last-modified と ETag を与えておき、2回目のリクエストでキャッシュの元の値を持ってきて、リソースが最新かどうかを検証することが必要です。リソースが変更されていない場合、サーバはキャッシュがまだ有効であることを示す "304 Not Modified" で応答し、ブラウザは有効期間を更新することができます。

プロキシキャッシュ

プロキシサーバー

プロキシサーバーは、クライアントとサーバーの間の仲介役で、上流のリクエストと下流のレスポンスを中間地点で転送します。プロキシサーバはコンピュータの分野で非常に重要な機能を持っています。

• ヘルスチェック：「ハートビート」などのメカニズムを使用してサーバーを監視し、サーバーの可用性を確保します。
• セキュリティ：ネットワーク攻撃や負荷の問題からプロキシサーバーのIPとトラフィックを保護します。
• 暗号化オフロード：外部と内部で異なる暗号化ポリシーを使用し、暗号化コストを削減します。
• コンテンツキャッシュ：サーバーの応答をステージング/リセットします。

キャッシングエージェント

HTTPサーバ側のキャッシュは、主にプロキシサーバによって実装され、プロキシサーバは、メッセージも独自のキャッシュに格納されていると同時に、クライアントに転送されるソースサーバーからの応答を受信し、同じ要求がある次の時間は、ソースサーバーのコストを節約し、304またはキャッシュされたデータに直接送信することができます。

プロキシサーバはサーバであると同時にクライアントでもあるという性質上、 いくつかの特別なキャッシュ制御プロパティがあります：

• サイド

private: クライアントサイドでのキャッシュのみが許可され、プロキシサーバでのキャッシュは許可されないことを意味します。

punlic: 完全に公開され、クライアントとプロキシの両方がキャッシュできることを意味します。

proxy-revalidate: キャッシュの有効期限が切れたときに、プロキシサーバがキャッシュを検証することを要求します。

s-maxage: プロキシキャッシュの有効期間。

no-transform: プロキシサーバによるデータ形式の変換を許可しません。

• クライアント

max-stale: プロキシ上のキャッシュが期限切れであっても受け付けますが、期限切れが多すぎることはできません。

min-flash: x秒未満のキャッシュは受け付けません。

only-if-cached: ソースサーバからのレスポンスではなく、プロキシがキャッシュしたデータのみを受け付けます。プロキシにキャッシュがなかったり、キャッシュの有効期限が切れたりした場合は、クライアントに504を返す必要があります。

HTTPS

HTTPは本質的に "平文 "であるため、送信プロセス全体が完全に透過的であり、誰でもリンク内のリクエスト/レスポンスメッセージを傍受、変更、または偽造することができ、データを信頼できないものにしてしまいます。リクエストは、機密性、完全性、認証、および否認防止を備えている場合にのみ安全であるとみなされます。 HTTPSは、HTTPにこれら4つの機能を追加します。

HTTPSとは、HTTP over TLS/SSlの略で、HTTPプロトコルにTLS/SSLプロトコルを追加したものです。

SSL/TLS

SSL（セキュア・ソケット・レイヤー）はOSIモデルのレイヤー5にあり、1994年にネットスケープ社によって発明されました。SSLはv3までに非常に優れた安全な通信プロトコルであることが証明されたため、1999年にTLSと改名され、現在最も広く使われているTLSは1.2ですが、他のプロトコルは安全ではないと判断されています。

機密性

SSL/TLSは暗号文を暗号化することでデータ通信の安全性を確保し、鍵を所有する人だけが復号して平文を得ることができ、その暗号化と復号の過程が暗号化アルゴリズムです。つまり、「鍵」とは長い数字の羅列であり、合意された単位は「ビット」です。例えば、鍵長128は16バイトの2進数文字列、鍵長1024は128バイトの2進数文字列です。鍵の使われ方によって、暗号化は対称暗号と非対称暗号の2つに大別されます。

対称暗号化

その名の通り、同じ鍵を使って暗号化と復号化を行うことを対称暗号と呼びます。TLSで最もよく使われるのはAESとChaCha20で、これは「Advanced Encryption Standard」という意味です。

AESは "Advanced Encryption Standard "を意味し、鍵長は128、192、256のいずれかを選択できます。DESアルゴリズムの代替となるもので、セキュリティ強度が高く、パフォーマンスが良く、ハードウェアによっては特別な最適化を行うものもあります。

ChaCha20はGoogleが設計した別の暗号化アルゴリズムで、鍵長は256ビットに固定され、純粋なソフトウェア操作の性能はAESより高く、以前はモバイルクライアントでより人気がありましたが、ARMv8以降、AESハードウェア最適化も追加されたため、明確な優位性はなくなりました。

符号なしコード

対称暗号は機密性の実装としては優れているように見えますが、鍵をどのように安全に伝送するかという問題が残っています。というのも、暗号化アルゴリズムでは鍵さえあれば復号できてしまうため、送信中に鍵が盗まれてしまうと機密性が保てなくなってしまうからです。この問題を解決するために、非対称暗号化アルゴリズムがあります。それぞれ公開鍵と秘密鍵の2つの鍵を持ち、公開鍵は公開され、秘密鍵は厳重に秘匿されます。公開鍵と秘密鍵は暗号化と復号化に使用できますが、公開鍵の暗号化は秘密鍵でしか復号化できず、秘密鍵の暗号化は公開鍵でしか復号化できません。非対称暗号化は鍵交換の問題を解決することができます。ウェブサイトは秘密鍵を秘密にし、公開鍵をインターネット上で任意に配布します。 ウェブサイトにログインしたい場合は、公開鍵で暗号化すればよく、暗号文は秘密鍵の所有者しか解読できません。ハッカーは秘密鍵を持っていないので、暗号文を解読することはできません。

非対称暗号化アルゴリズムは対称暗号化アルゴリズムよりも設計が難しく、TLSにはDH、DSA、RSA、ECCなど数種類しかありません。

RSAはおそらく最も有名な暗号化方式で、非対称暗号化の代名詞のようなものです。 その安全性は「整数分解」という数学的問題に基づいており、2つの非常に大きな素数の積を鍵生成の材料として使用するため、公開鍵から秘密鍵を推測することが非常に困難です。

ECCは「楕円曲線離散対数」の数学的問題に基づいており、特定の曲線方程式と基点を用いて公開鍵と秘密鍵を生成し、鍵交換にはECDHE、電子署名にはECDSAというサブアルゴリズムを使用します。電子署名。160ビットのECCは1024ビットのRSAに相当し、260ビットのECCは2048ビットのRSAに相当します。

ハイブリッド暗号

非対称暗号化には鍵交換の課題はありませんが、どちらも複雑な数学的パズルに基づいているため、計算には時間がかかり、ECCでさえAESより桁違いに劣ります。そのため、TLSでは現在ハイブリッド暗号化を採用しており、この2つを補完することで効率的な暗号化と復号化、そして安全なデータ伝送を実現しています。

接続の最初に、非対称暗号化の形で鍵が渡され、次に乱数が対称アルゴリズムで使われる「セッション鍵」の生成に使われ、それが公開鍵で暗号化されます。セッション鍵は非常に短く、通常は16バイトか32バイトなので、遅くても問題ありません。相手側は暗号文を取得し、それを秘密鍵で復号してセッション鍵を取得します。このようにして、両者は対称鍵の安全な交換を実現し、非対称暗号化を使わず、すべて対称暗号化を使うようになります。

完全性

要約アルゴリズム

完全性を達成するための手段は、主にダイジェストアルゴリズムであり、これはしばしばハッシュ関数、ハッシュ関数と呼ばれています。ダイジェストアルゴリズムは、特殊な暗号化アルゴリズムとして近似することができ、任意の長さのデータを固定長で一意の「ダイジェスト」文字列に暗号化することができ、元のテキストの圧縮された暗号文から推測することはできません。SETTINGSヘッダーも可変長エンコーディングで符号化され、最小2バイトを必要とする、PRIORITY これらは最も一般的に使用されている2つのダイジェストアルゴリズムで、長さが16バイトと20バイトのデジタルダイジェストを生成することができます。しかし、これら2つのアルゴリズムのセキュリティ強度は比較的低く、十分な安全性が確保されていないため、TLSでは使用が禁止されています。TLSでは現在、「デジタル・ダイジェスト」が元のテキストと完全に等価であることを保証するダイジェスト・アルゴリズム、SLA-2を使用しています。したがって、原文にダイジェストが添付されている限り、データの完全性は保証されます。しかし、ダイジェスト・アルゴリズムは機密ではないため、真の完全性は機密性に基づく必要があります。

認証と否認防止

デジタル署名

電子署名の原理は実はとても単純で、公開鍵秘密鍵の使い方を逆にすると、公開鍵の暗号化、秘密鍵の復号、そして今度は秘密鍵の暗号化、公開鍵の復号となります。しかし、非対称暗号化の効率が低すぎるため、秘密鍵は原文の要約を暗号化するだけで、演算量が大幅に少なくなり、得られるデジタル署名も非常に小さく、保存や送信が簡単になります。

デジタル証明書とCA

公開鍵は誰でも発行することができるため、公開鍵の信頼性を保証するために第三者を導入する必要があります。この「第三者」はしばしばCAと呼ばれ、公開鍵のCA署名証明は、公開鍵のシリアル番号、目的、発行者、有効時間などを含むフォーマットでもあり、これらをパッケージにして署名することで、完全な公開鍵が "デジタル証明書 "を形成するための様々な情報と関連付けられていることを証明します。小規模な認証局は、大規模な認証局から署名を受けて認証を受けることができますが、連鎖の末端、つまりルート認証局は、「自己署名証明書」または「ルート証明書」と呼ばれる、自分自身を証明することしかできません。そうでなければ、証明書の信頼チェーン全体が続かないからです。

TLS1.3

TLSプロトコルの構成要素

レコードプロトコル：TLSが送受信するデータの基本単位であるレコードを指定します。他のすべてのサブプロトコルはロギングプロトコルを介して送信する必要がありますが、複数のログを1つのTCPパケットで一度に送信することができます。

アラートプロトコル：HTTPプロトコルのステータスコードのようなもので、相手側にアラートメッセージを送信する役割を担います。例えば、protocol_versionは古いバージョンがサポートされていないことを意味し、bad_certificateは証明書に問題があることを意味します。

ハンドシェイクプロトコル: TLSで最も複雑なサブプロトコルで、TCPのSYN/ACKよりもはるかに複雑です。 ブラウザとサーバはハンドシェイクの間にTLSのバージョン番号、乱数、暗号スイート、その他の情報をネゴシエートし、次に証明書と鍵のパラメータを交換し、最終的にその後のハイブリッド暗号化システムで使われるセッション鍵をネゴシエートします。

暗号仕様変更プロトコル：後続のデータが暗号化で保護されることを相手に「通知」するもの。その後、今度はその中でデータが平文になります。

ECDHEベース TLS1.2

TLS 1.3

HTTP/2

HTTP1.Xは、ステートレスの問題を解決するためにクッキーを導入し、安全でない平文伝送の問題を解決するためにTLS/SSLを導入しました。HTTP2の次の焦点はパフォーマンスで、GoogleはSPDYプロトコルを発明し、その後、インターネット技術タスクフォース（IETF）はSPDYをベースにHTTP2をリリースし、パフォーマンスの最適化として、1）パケットヘッダーサイズが大きすぎる。

パフォーマンス最適化

バンヘッドが大きすぎる

HTTP 1.xの時代には、GETリクエストや301/302/204レスポンスなど、多くのリクエストやレスポンスボディのサイズは、ヘッダーフィールドのサイズよりもはるかに小さいものでした。HTTP/1.xでは、重複したヘッダーフィールドを送信するために多くの帯域幅を浪費していたため、HTTP/2ではパフォーマンス改善の焦点として "ヘッダー圧縮 "を採用しました。

HPACK アルゴリズムは、HTTP ヘッダを圧縮するためにカスタマイズされたアルゴリズムです。 gzip や zlib などの圧縮アルゴリズムとは異なり、「ステートフル」なアルゴリズムで、クライアントとサーバは「インデックス付きテーブル」を保持する必要があり、圧縮と解凍はテーブルのチェックと更新の問題です。圧縮と解凍は、テーブルのチェックと更新の操作です。管理・圧縮を容易にするため、HTTP/2では、当初の開始行の概念を廃止し、リクエストメソッド、URI、ステータスコードなどの開始行をヘッダーフィールドの統一形式に変換し、「本当のヘッダーフィールド」と区別するために、これらの「擬似ヘッダーフィールド」を設けました。本当のヘッダーフィールドと区別するために、これらの「擬似ヘッダー フィールド」はその名前の前に":」を付けます。例えば、":authority" ":method"":status "のように、それぞれドメイン名、リクエストメソッド、 ステータスコードを示します。開始行のバージョン番号とエラー原因のフレーズは非推奨です。繰り返される文字列はインデックス番号で表現され、整数と文字列の圧縮にはハフマン符号化が使われます。

次の表は「静的テーブル」の一部をリストしたもので、テーブルを調べるだけで、フィールド名と対応する値を知ることができます。例えば、数字「2」は「GET」を表し、数字「8」はステータスコード「200」を表します。例えば、"2 "は "GET "を表し、"8 "はステータスコード200を表します。

新しいヘッダーフィールドや値は、静的テーブルの後に追加される動的テーブル に、同じ構造で格納されますが、エンコード中やデコード中にいつでも更新されま す。例えば、最初にリクエストを送るとき、"user-agent" フィールドは100バイト以上あり、それをハフマン圧縮エンコーディングで 送った後、クライアントとサーバーの両方は新しいインデックス番号 "65" を追加するために動的テーブルを更新します。そうすると、次に送信するときは、そんなに多くのバイトを再度送信する必要はなく、1バイトを使って番号を送信するだけでいいのです。

キューヘッドブロッキング

httpプロトコルのリクエスト・レスポンスモデルに基づいて、キューヘッダのブロッキング問題があり、前述の同時接続とドメインスライシングは、アイデアの質を解決するために量を犠牲にしています。HTTP2 では、この問題を解決するためにバイナリフレミング ストリーミングを使用します。

フレームの2進分割

HTTP/2は、ヘッダーデータを格納するHEADERフレーム、エンティティデータを格納するDATAフレームを持つバイナリ "フレーム "のいくつかの小片に "分割 "メッセージの元のヘッダー+ボディに。

ストリーミング

HTTP/2は、バイナリフレームの双方向シーケンスである "ストリーム "の概念も定義しており、同じメッセージのラウンドトリップ内のフレームには固有のストリームIDが割り当てられます。HTTP/2 は、"ストリーム" を使って TCP 接続上で複数の "断片化された" メッセージを同時に送信することができ、これはしばしば "多重化" と呼ばれます。これはしばしば "多重化" と呼ばれ、複数のラウンドトリップが単一の接続上で多重化されます。ストリーム "レベルでは、メッセージは順序付けられた "フレーム "のシーケンスであり、"コネクション "レベルでは、メッセージは無秩序に送受信される "フレームフレーム "です。複数のリクエスト/レスポンスの間に順序関係はなく、キューイングもなく、「キューの先頭がブロックされる」こともないため、待ち時間が短縮され、コネクションの利用率が劇的に向上します。

フレームの先頭はフレームの長さで、デフォルトの上限は2^14、最大は2^24、つまりHTTP/2フレームは通常16K、最大は16Mを超えません。

( HTTP/2 接続的には、フレームは無秩序な順序で送受信されるが、それらがすべて同じストリームIDを持つ限り、それらはすべて1つのストリームに属し、フレームはこのストリーム内で無秩序ではなく、厳密な優先順位を持つ）。次のバイトはフレームタイプで、データフレームと制御フレームに大別されます。 HEADERS フレームと DATA フレームはデータフレームに属し、HTTP メッセージを格納します。

5バイト目は非常に重要なフレームフラグ情報であり、8つのフラグビットを保持し、単純な制御情報を伝えます。よく使われるフラグは、ヘッダの終了を表す END_HEADERS と、一方向データ転送の終了を表す END_STREAM です。

Accept-Language: ja-JP, zh, enメッセージヘッダの最後の4バイトはストリーム識別子で、フレームが "ストリーム "に属していることを示します。ストリーム識別子は4バイトですが、最上位ビットが予約されているため、31ビットしか使用できません。

ストリームの特徴

• ストリームは同時進行 HTTP/2接続で複数のストリームを同時に送信することができます；
• クライアントもサーバーも、お互いに干渉することなくストリームを作成できます；
• ストリームは双方向で、クライアントもサーバーもストリーム内でデータフレームを送受信することができます；
• ストリームは互いに一定の関係を持たず、独立していますが、ストリーム内のフレームは厳密な順序になっています；
• 例えば、HTML/CSSが先でイメージが後など、ユーザー体験を最適化するために、ストリームを優先してサーバーで処理することができます；
• ストリームIDは再利用できず、クライアント側で開始されるIDは奇数、サーバー側で開始されるIDは偶数で、順次インクリメントされるのみです；
• ストリーム上で "RST_STREAM "フレームを送信すると、いつでもストリームを終了させることができ、受信や送信をキャンセルすることができます；
• ストリーム0は特殊で、クローズすることができず、データフレームを送信することもできません。

プロトコルスタック

HTTP/3

HTTP/2は "フレーム"、"ストリーム"、"多重化 "を "ヘッダー・ブロッキング "なしで使用しますが、これらの手段はアプリケーション層にあり、"ヘッダー・ブロッキング "は依然としてTCPプロトコルで発生します。GoogleはSPDYを推し進めたときにこの問題に気づき、HTTPをTCPではなくQUIC上で動作させる新しいQUICプロトコルを発明しました。HTTP over QUICはHTTPプロトコルの次の大きなバージョンであるHTTP/3で、HTTP/2から飛躍的に進歩しており、キューヘッドブロッキングの問題を完璧に解決しています。

QUIC

QUICは「コネクションレス」であるUDPをベースとしており、「ハンドシェイク」や「ウェーブ」を必要としないため、TCPよりも本質的に高速です。QUICは暗号化通信を全面的に採用し、独自のフレームを使用してTLSの「レコード」を「引き継ぎ」、ハンドシェイク・メッセージやアラート・メッセージはTLSレコードを使用せず、QUICフレームに直接カプセル化して送信するため、ワンタイムのオーバーヘッドが発生しません。パケットは複数のフレームで構成され、パケットは "コネクション "に、フレームは "フロー "に向いています。

QUICは通信の2つのエンドポイントをマークするために不透明な "接続ID "を使用し、クライアントとサーバーは自分自身をマークするためにIDのセットを選択することができます。"接続の移行。

HTTP/3

QUICはすでに暗号化、ストリーム、多重化をサポートしているので、HTTP/3はストリームを定義する必要がなく、QUICのストリームを直接使用します。ストリーム管理がQUICに "委任 "されているので、HTTP/3のフレーム構造はより単純です。ヘッダには type と length の2つのフィールドがあるだけで、それらは可変長エンコーディングで符号化され、最低2バイトが必要です。