HTTP、HTTPS、HTTP 1.X、HTTP 2.0が混乱している？今日はここにある

まず、HTTP/1.0

ハイパーテキスト転送プロトコル：HTTPプロトコルはアプリケーション層に属し、トランスポート層プロトコルTCPの上に構築されています。クライアントはサーバーとTCP接続を確立し、TCPプロトコルのソケットインターフェースにアクセスしてHTTPリクエストを送信し、HTTPレスポンスを受信します。HTTPリクエストメッセージは、リクエスト行、リクエストヘッダ、リクエストボディの3つの部分で構成されます。

リクエスト行とレスポンス行はリクエスト行と同じです。

// 例えば
1 . METHODS （リクエストメソッド) /ALEX/login.html（(リクエストURL) HTTP/1.1 （(プロトコルとバージョン)
2 . STATUS CODE （(ステータスコード) 理由フレーズ HTTP/1.1 （(プロトコルとバージョン)

リクエストヘッダとレスポンスヘッダは互いにあまり変わりません。

サーバーがクライアントの情報を取得するためのいくつかの属性と属性値。

共通属性とその値、意味
* Accept: 'text/plain, text/html, application/json' // クライアントが受信できるコンテンツの種類を指定する
* Accept-Charset: 'xxx' //ブラウザで使用可能な文字エンコーディング
 Accept-Encoding: 'gzip, compress' // ウェブサービスがサポートする圧縮の種類を指定する。
 Accpet-Language: 'en, zh, ja-JP' // ブラウザの対応言語
 Accept-Ranges: 'bytes' //ウェブページ・エンティティの1つ以上のサブスコープ・フィールドをリクエストできる。
 Authorization: 'sdfgvqw3f' // 認証証明書
** Access-Contorl-Allow-Credentials(証明書、ke dun笑死): 'true' //リクエストに対するレスポンスをページに公開できるかどうか、つまり、クライアントに認証情報(クッキー)を持たせることができるかどうか。, authorization headers / TLS client certificates）
** Access-Control-Allow-Headers: '*' // 許可されるリクエストヘッダ
** Access-Control-Allow-Methods: '*' // 許可されるインポジション方式
** Access-Control-Allow-Origin *' //
リクエストされたリソースが共有されているかどうか、つまりクロスドメインリクエストであるかどうか。
** Access-Control-Max-Age: 'xx' //レスポンスヘッダは、プリフライトリクエストの結果をどれくらいの期間キャッシュできるかを示す。
** Access-Control-Expose-Headers { // 以下は、レスポンスの一部として公開できるもののデフォルトである。
 Cache-Contorl, // 強力なキャッシュ、最新のリソース更新時間に対する有効期限を設定する。
 Content-Language,
 Content-Type, // エンティティヘッダはリソースの MIME タイプを示すために使われる
 Expires, // 強力なキャッシュ、有効期限の設定
 Last-Modified, // リソースの最新更新時間
 Pragma, // 最優先でキャッシュする
 }
 Access-Control-Request-Headers: 'xxx' // 実際のリクエストでどのリクエストヘッダが使われるかをサーバに通知するために登場する。
 Access-Control-Request-Method: 'xx' // リクエストヘッダは、実際のリクエストでどのHTTPメソッドが使われるかを サーバーに通知するために現れる。プリフライトリクエストで使われるメソッドは常に OPTIONS であり、実際のリクエストで使われるメソッドとは異なるので、このリクエストヘッダは必要である。
 Content-Type: {
 text/html for normal web pages
 text/plain for plain text
 text/css for Cascading Style Sheets
 text/javascript for scripts
 application/octet-stream meaning "download this file"
 application/x-java-applet for Java applets
 application/pdf for PDF documents
 }
** Cache-Control: 'no-cache' // キャッシュの相対期間を指定する
 Connection: 'close' // 持続的な接続が必要かどうか， http1.1デフォルトの持続的接続
** Cookie: 'xxxxxxx' // クライアントとサーバーの通信は、保存されている情報を縮小する
 Content-Length: '12344' // リクエストコンテンツの長さ
 Date: 'xxx' // リクエスト送信時間
 Expect: '100-continue' // リクエスト固有のサーバの挙動
 From: 'xxxx' // リクエストを送ったユーザの電子メール
 Host: 'xxxx' // リクエストサーバーのドメイン名とポートを指定する
 If-Match: 'xxx' // エンティティにマッチするリクエストコンテンツだけが有効である。
** IF-None-Match: 'xxx' // 304を返した場合、比較のためにサーバが以前に送ったEtagのパラメータは、If-Modified-Sinceを無視する。
** If-Modified-Since: 'xxx' // サーバーは、リクエストされたリソースが指定された日時以降に変更された場合のみ、ステータスコード200を返し、そうでない場合は304を返す。
** Pragma: 'no-cache' // 特定のコマンドの実装を含むために使われる
 Referer: 'xxx' // ページのソース
 Upgrade: 'xx' // トランスポートプロトコルをサーバに知らせ、サーバがそれを変換できるようにする。
 User-Agent: 'xxx' // リクエストを送ったユーザの情報を含む

リクエスト・ボディとレスポンス・ボディはリクエスト・ボディと同じです。

リクエストボディは post リクエストメソッドのリクエストパラメータで、key = value の形式で格納され、複数のリクエストパラメータは & で連結されます。リクエストボディがリクエストされた場合、リクエストヘッダの Content-Length 属性にリクエストボディの長さが記録されます。フォーマット

• 任意の型、サーバーは解析されません、POST JSONのようなリクエストボディの処理が解析される必要があります。
• ファイルとして扱われるかどうかを見分ける鍵は、Content-Dispositionにfilenameが含まれているかどうかです。ファイルにはさまざまな種類があるため、Content-Typeでファイルの種類を示す必要があります。バイナリファイルであることを意味します。例：Content-Type: 'multipart/form-data; boundary={boundary}'でファイルをアップロード。

フォームやモックアップは、2番目と3番目のタイプを指します。

リクエストメソッドのhttpリクエスト行

• GET 指定されたページに関する情報を要求し、データを返します。
• HEADはGETに似ていますが、エンティティを返さず、ヘッダを取得します。
• POST は、指定されたリソースを送信します。
• PUT 指定されたドキュメントの内容を、クライアントからサーバーに送信されたデータに置き換えます。
• DELETE 指定されたコンテンツの削除をサーバーに要求します。
• CONNECT HTTP/1.1プロトコルは、パイプラインへの接続を変更できるプロキシのために予約されています。
• OPTIONSは、クライアントがサーバ側のパフォーマンスを見ることを可能にします。これは通常、リクエストを許可するかどうかなどを事前にチェックするときに送られます。
• TRACE 主にテストや診断のために、サーバーが受け取ったリクエストを リコールします。
• PATCH 既知のリソースに対するPUTメソッドの補足。

GETとPOSTの違い。

1. GET：バック/リフレッシュは無害です。 POST：データは再送信されます。
2. GET: ブックマークできます。 POST: ブックマークできません。
3. GET: キャッシュ可能 POST: キャッシュ不可
4. GET: データの長さに制限があります。 POST: 制限はありません。
5. GET：ASCII文字のみ使用可能。POST：制限なし。
6. GET：セキュリティが低い、パラメータが見える、全員に見える POST：セキュリティが高い、パラメータが見えない

次に、TCP 接続を確立します

TCP プロトコルを介して、クライアントとサーバーの通信方法を指定することで、データをより安定的に宛先に配信することができます。クライアントがリクエストを開始すると、https は最初に SSL を検証する必要があります。

• ハンドシェイク1: クライアントはリクエストメッセージを送信しますが、シリアル番号を消費します。
• ハンドシェイク2: メッセージセグメントを受信した後、サーバは、クライアントがコネクションの確立に同意した場合、確認メッセージをクライアントに送信します。 確認メッセージセグメントでは、TCPサーバプロセスはSYN-RCVD状態に入ります。
• ハンドシェイク3：TCPクライアントは、サービスエンドに確認メッセージセグメントを与えるために、サービスエンドから確認情報を受信し、ACKメッセージセグメントは、データを運ぶことができる、データを運ばないし、シリアル番号を消費しません。 TCP接続が確立されている、TCPクライアントは、ESTABLISHEDに入ります。 サービスエンドは、TCPクライアントからの確認を受信すると、それもESTABLISHED状態に入ります。サーバーがTCPクライアントからの確認を受信すると、サーバーもESTABLISHED状態になり、TCPが正常に確立され、データのやり取りが開始されます。

TCP伝送の信頼性を一言で表すと、相手からデータを受信するたびにACKを送信して判断し、送信後に送信者がACKを受信しなければ、間隔を空けて再送信するということです。

HTTPS について

まず、HTTPSリクエストはHTTPをベースにしていますが、HTTPもTCPをベースにしているため、最初にTCPハンドシェイクを3回確立する必要があります。さらに、SSL認証が追加されます。

，暗号化アルゴリズム

• 対称暗号化：ストリームとパケットの2種類があり、暗号化と復号化の両方に同じ鍵を使用。
• 非対称暗号化：暗号化キーと復号化キーが異なり、公開キー、キーがあり、性能は低いが、セキュリティが高く、データの長さが制限されています。
• ハッシュアルゴリズム：任意の長さのメッセージを、通常はメッセージよりもはるかに小さい、より短い固定長の値に変換します。
• デジタル署名：署名は、メッセージが変更されていないことを証明するために、メッセージの末尾に追加されるコンテンツの一部です。通常、ハッシュ値は暗号化され、このハッシュ値が変更されていないことを保証するためにメッセージと一緒に送信されます。

，SSL 証明書の検証段階

証明書：各サーバーは、CA機関に独自の証明書を申請するために、CA機関は、信頼されたグローバルな信頼に設定され、SSL証明書のすべてのブラウザをサポートするクライアント側に再度インストールする必要はありませんが、サーバー側にインストールされて正常に使用することができますが、あなたのSSL証明書は、すべてのブラウザ、または自己署名証明書をサポートしていない場合は、通常のアクセスには、クライアントはまだインストールする必要があります。証明書をインストールする必要があります。クライアント側証明書の中身秘密鍵はサーバ側に存在します。

• クライアントがHTTPSリクエストを開始すると、サーバはSSL証明書をクライアントに送信します。
• クライアントはSSL証明書を受信して読み、証明書の情報を一つ一つ確認します。
• クライアントは、オペレーティング・システムに組み込まれている信頼できる認証局を探し始め、サーバから送られてきた認証局を調べ、信頼できるものであれば続行し、そうでなければエラーを報告します。
• 一致する場合、クライアントはオペレーティング・システムから発行者CAの公開鍵を取り出し、署名を復号化します。
• クライアントは同じハッシュ・アルゴリズムを使ってサーバから送られてきた証明書のハッシュ値を計算し、署名のハッシュ値と比較します。

クライアントサーバー認証SSL通信フェーズ。

• 証明書が正常に検証された後、クライアントはサーバーに「データ転送に対称暗号を使いたい」と伝えます。
• サーバーはメッセージを受信し、クライアントに「OK」と応答します。
• 公開鍵を読み取り、リクエスト内容を暗号化してサーバに送信し、サーバはそれを受け取って復号化します。
• クライアントはサーバーの暗号化された応答内容を受け取ります。

第四に、HTTPとHTTPSの違いです。

• HTTPにはSSL認証がありません。 HTTPSプロトコルはcaで証明書を申請する必要があり、一般的に無料の証明書は少ないため、有料となります。
• HTTPはハイパーテキスト転送プロトコルで、情報は平文で転送され、HTTPSはssl暗号化転送プロトコルで、データが正しいクライアントとサーバーに送信されることを保証するセキュリティです。
• HTTPとHTTPSでは、接続方法も使用するポートも全く異なり、前者は80、後者は443です。
• HTTP接続はシンプルでステートレスです。 HTTPSプロトコルは、HTTP + SSLプロトコルから構築されたネットワークプロトコルであり、暗号化された伝送、認証を可能にし、HTTPプロトコルよりも安全です。

，HTTP1.x

• 多重化されていない接続: 多重化されていない接続では、リクエストごとに3回のハンドシェイクとスロースタートが発生します。3回のハンドシェイクの影響は高レイテンシシシナリオでより顕著になり、スロースタートは大量の小さなファイルリクエストでより大きな影響を与えます。

1. データを転送する場合、接続を毎回確立し直す必要があり、待ち時間が長くなります。
2. キープアライブを追加することで、コネクションの一部を再利用することはできますが、ドメインスライシングやその他のケースでは複数のコネクションを確立する必要があり、リソースを消費してサーバーのパフォーマンスを圧迫します。

• Head-Of-Line Blocking (ヘッド・オブ・ライン・ブロッキング): 帯域幅が十分に利用されず、後続のヘルス要求がブロックされる結果。HOLBとは、最初のパケットのためにブロックされる一連のパケットのことで、1ページ内で多くのリソースを要求する必要がある場合、HOLBが発生すると、残りのリソースは、要求の最大数に達したときに要求を開始できるようになる前に、他のリソース要求が完了するまで待たなければならなくなります。
• プロトコルのオーバーヘッド：使用時に、ヘッダで運ばれるコンテンツが大きすぎる、ある程度、伝送コストを増加させ、各リクエストヘッダは基本的にあまり変更されません、特にモバイルエンドでは、ユーザのトラフィックを増加させます。一方向リクエストは、クライアントによってのみ開始することができます。
• セキュリティ要因：データを送信する際、送信された内容はすべて平文であり、クライアントとサーバー側はお互いの身元を確認することができないため、データのセキュリティをある程度保証することができません。

HTTP 2 を理解する.0

1. HTTP/2は、1999年にHTTP 1.1がリリースされて以来初めてのHTTPプロトコルのアップデートであり、主にSPDYプロトコルをベースにしています。
2. SPDYはSpeedyのニックネームで、「より速く」という意味。TCPプロトコルをベースにGoogleが開発したアプリケーション層プロトコル。その目的は、HTTPプロトコルのパフォーマンスを最適化することであり、圧縮、多重化、優先順位付けの技術を通じて、ウェブページの読み込み時間を短縮し、セキュリティを向上させることです。

，特徴

• バイナリ送信

HTTP 2.0におけるすべてのパフォーマンス向上の中心はバイナリ転送であり、すべての送信データがセグメント化され、HTTP 1.xではテキストが使用される新しいエンコーディングメカニズムを導入しています。

• 多重化

HTTP 2.0 では、フレームとストリーム (複数のフレームからなるデータの流れ) という 2 つの概念が非常に重要です。= いわゆる多重化、つまり TCP 接続には複数のストリームがあり、つまり複数のリクエストを同時に送信することができ、相手側はフレーム内の表現によってフレームがどのリクエストに属するかを知ることができます。クライアント側では、これらのフレームは順番が入れ替わった状態で送信され、 各フレームの先頭にあるストリーム識別子に従って相手側で再アセンブルされます。この技術により、古いバージョンの HTTP のキューヘッドブロッキング問題が回避され、送信性能が大幅に向上します==。

• Header

HTTP1.Xでは、ヘッダを送信するためにテキストを使用します。ヘッダでクッキーを運ぶことは、大きすぎてリソースを消費します。

• サーバ PUSH

サーバーは、クライアントからの特定のリクエストの後に、他のリソースを積極的にプッシュすることができます。

• より安全

プロトコルのアップグレードとしてtls拡張ALPNを使用して、さらに、HTTP 2.0にtlsのセキュリティは、もはや安全な暗号化アルゴリズムの数百を無効にするブラックリストメカニズムを通じて、ほぼ強化されています。