https

前書き

ビデオ画面に従ってhttpの知識を学んだ後、記録し、印象を深め、将来確認しやすいように記事を書く必要性を感じています！

http

httpの起源と言えば、World Wide Webの生みの親であるTim Berners-Leeが1990年10月にhttpプロトコルのコンセプトを提案し、1991年にTimが提案されたhttpプロトコルを説明し、提案された実装プロセスを説明する記事を発表したことであり、特定の組織から発表されたものではありませんが、彼はhttpの最初のバージョンとして使用されています。http0.9

http0.9

関数の実装のhttp0.9バージョンは非常にシンプルで、単純なGETリクエストのみをサポートし、プレーンテキストの送信だけで、要求ヘッダと応答ヘッダは、その時のシナリオの単純な使用のため、これらは、学術的な通信を満たすことができるされていません。

http1.0

その後、インターネットの普及に伴い、明らかにhttp0.9では日常的な利用シーンを想定したより高機能なhttpの必要性に応えられず、http1.0が登場し、http1.0では以下の機能が追加されました。

• リクエストヘッダとレスポンスヘッダの追加
• プレーンテキストだけでなく、複数の種類のファイル転送をサポート
• 新しいPOSTとHEADリクエストメソッド
• キャッシュ機構と認証の追加

デメリット

http1.0はhttp0.9よりも柔軟ですが、以下のような欠点もあります。

• http1.0は短い接続です。つまり、接続の各リクエストは3回のハンドシェイクと4回のブレークアップを確立する必要があり、これはパフォーマンスを消費し、待ち時間を増加させます。
• http1.0 にはホスト属性がないため、物理マシンが複数の VM にバインドされている場合、対応する VM を区別して適切なロジックを作成することができません。

http1.1

上記の欠点とインターネットのさらなる発展に伴い、httpのより完璧なバージョンを必要とするため、http1.1は、次のようにhttpの柔軟性が生まれてきました。

• 増加長い接続メカニズムConnect:keep-aliveは、各TCP接続の後、すぐに切断されないように、固定時間または同時実行の量で設定することができますときに切断は、複数の要求がRTTの数を減らすために、同じTCP接続で多重化されるように、待ち時間を短縮し、RTTは、クライアントからサーバーにデータのパケットを送信し、データの背部を受信するまでの往復時間を表します。RTTは、クライアントがパケットを送信してからサーバーからデータを受信して戻ってくるまでの往復時間であり、3つのTCP接続では1.5RTTとなります。
• 異なるVMドメインを区別するために、ホストフィールドが追加されました。
• 範囲指定フィールドの追加
• キャッシュ機構を改善し、etag、last-modified、その他のフィールドを追加しました。

デメリット

http1.1は非常に優れたものですが、主に以下のような問題が残っています。

• 帯域幅が十分に利用されません

帯域幅とは、ネットワークが送受信できる最大バイト数のことです。

http1.1が複数のTCP接続を開くことができるように、クロームは、最大6であり、その後、各TCPは、帯域幅のリソースを争う、帯域幅のリソースが不足している場合、要求または応答の速度が遅くなり、一度要求がjs、cssなどの重要なテキストであり、それは、ホームページのレンダリングの遅れにつながる、とTCPはスロースタートの特性を持って、TCPの伝送速度は一度に安定していない、彼は車の始動速度は速度が安定する前に、一定期間ゆっくりと増加しているのと同じように、ゆっくりとしたプロセスです。TCPの伝送速度は、すべての突然安定していない、彼は車のスタート速度が速度が安定する前に、一定期間の後にゆっくりと増加しているのと同じように、ゆっくりとしたプロセスである、100Mのブロードバンドの伝送速度は、実際には12.5M / sですが、最初の数回のリクエストはわずか2.5M / sである可能性があり、帯域幅が完全に利用されていません。

• 長いコネクションがあるとはいえ、サーバーのリターンはシーケンシャルなので、リクエストに対するレスポンスが何らかの理由で返されなかった場合、後続のレスポンスがブロックされ、結果としてキューヘッダーがブロックされます。
• リクエストはクライアントからのみ可能で、サーバーサイドからメッセージをプッシュすることはできません。
• リクエストとレスポンスのヘッダーに重複フィールドが増え、トラフィックを浪費
• リクエストヘッダとレスポンスヘッダは圧縮されずに送信されます。
• リクエストは平文で、安全ではありません。

http2.0

上記は、http1.1は非常に柔軟性が、まだ多くの欠点は、上記の問題を解決するために、インターネット技術のプロモーター、および導入されたhttp2.0（http2.0は、SPDYプロトコルに基づいて構築され、彼は新しいプロトコルのhttp1.1の欠点を解決するためにgooleによって導入された）と述べたが、その後、あきらめ、全身に入れhttp2.0の構築は、次のhttp2.0の問題を解決するために見て

• http1.1は、あまりにも多くのTCP接続、帯域幅のハイジャックと利用不足の問題なので、http2.0は、TCP接続を確立するためにのみ、すべての要求と応答のドメイン名は、上記の問題に対する良い解決策の完了以下のTCP以下のドメイン名を使用します！

• http1.1最大の問題は、チームヘッドのブロッキングですので、http2.0は、この問題を解決するために、多重化の導入は、つまり、並列にTCP接続は、要求と応答の並列受け入れを送信するには、順序がカオスではないことを確認する方法は、この問題を解決するために、重要な課題であるだけでなく、http2.0は、最もコア技術のバイナリサブフレームは、バイナリサブフレームレートは、大まかな原理のされて入ってきましたバイナリフレームレートの一般的な原則は次のとおりです：

  1: TCPレイヤーの上に、いやTSLレイヤーの上に、バイナリー・スプリット・フレーム・レイヤーを作成します。

  2: 並列リクエストはバイナリー・フレーミング・レイヤーを通して処理され、0,1バイトにバイナリー処理された非常に小さなデータ・ストリームを生成し、各データ・ストリームに対してフレームIDが生成されてサーバーに送信されます。

  3：サーバーはこのデータストリームを取得し、フレームIDに従って結合し、完全な情報を生成し、処理後に応答データを並行して送信します。

  4: レスポンスデータはバイナリフレーミングレイヤーを通して処理され、対応するフレームIDを生成します。

• http2.0はヘッダー圧縮をサポートし、無駄なトラフィックを削減します。

• http2.0は暗号化通信を可能にし、通信のセキュリティを保護するために必須です。

• 優先順位を設定することで、並列送信時に最初に返すデータを設定することができます。

デメリット

http2.0は非常に良い仕事をしている、インターネットプロモーターの知恵の実装ですが、しかし、まだ問題がある、どのような問題が存在するか、またはブロックの問題は、http2.0は、TCP接続を確立することですので、並列要求パケットは、TCPの安全で信頼性の高いメカニズムに起因する、この1つのTCPにある、一度パケットの要求が失われると、応答が停止され、ブラウザの必要性は、すべての要求がブロックされるように、新しいパケットを再入力します。HTTP1.1 TCPは1つ以上であるため、1つのブロックは、他のTCPに影響を与えません、http2.0 TCPは1つである、一度パケットの損失のための複数の要求、他の要求の応答を再通過するパケットのための複数の要求の必要性は、他の要求の応答がブロックされるように、ブロックされますので、すべての要求が、ブロックされます。他の要求の応答がブロックされますので、HTTP2.0は最適化の多くを行っているが、最も恐れているリクエストのパケットの損失です。

http3.0

変更が他の問題を引き起こす可能性があるため、http3.0は、思考の別の方法を持って、UDPに変更された従来のTCPプロトコルをあきらめ、その後、http1.1またはhttp2.0は、TCPプロトコルの問題を持っていない関係なく、TCPを変更する場合は、明らかに非現実的な、その後http3.0を促進するか、いくつかの時間を必要とする、まだ計画のプロトコルです。プロトコルは、我々はTCPの欠点を避けることができるように、しかし、UDPだけでは十分ではありません、UDPは欠点を持っているので、UDPを使用する必要性が、また、受信データ、セキュリティおよびその他の問題の信頼性を満たすために。ここでは、QUIC層の追加の上のUDP層でhttp3.0の概念図は、この層では、多くのロジックの内部では、目的は、UDP自体の欠点を解決することです、あなたはhttp3.0は、プロトコルの非常に完璧なバージョンであると言うことができる、ここにhttp3の紹介.0記事があります、あなたは深く学ぶことができます！

https

httpsのプロトコルは、TSL（SSL）プロトコルの層の確立の上にTCPプロトコルに基づいており、送信されたメッセージを暗号化するために使用される、HTTPSの暗号化の説明では、対称暗号化と非対称暗号化についていくつかの単語を言う必要があります。

対称暗号

つまり、暗号化と復号化は鍵で行われ、この暗号化は比較的簡単で高速です。しかし、それは比較的安全ではありません。

非対称暗号

非対称暗号化 多くのオンライン記事では、情報の交換に公開鍵と秘密鍵の2つの鍵が必要な暗号化について述べています。情報の交換に2つの鍵が必要である限り、非対称暗号化と呼ぶことができます。しかし、今、非対称暗号化を説明するプロセス全体では、公開鍵と秘密鍵のペアが2つあるはずです。非対称暗号化はまだ少しラウンド、再び説明で自分の言葉で次の単語は、プロセスは次のとおりです。

• クライアントはリクエストを送信し、自身の公開鍵をサーバに提供し、クライアントは自身の秘密鍵を保持します。
• サーバはクライアントの公開鍵を取得し、自分の公開鍵をクライアントの公開鍵で暗号化してクライアントに返します。
• サーバの公開鍵はクライアントの公開鍵で暗号化されているため、クライアントの秘密鍵でしか復号化できず、クライアントは復号化してサーバの公開鍵を取得します。
• これで、クライアントはサーバの公開鍵と自分の秘密鍵を持ち、サーバはクライアントの公開鍵と自分の秘密鍵を持つことになります。
• クライアントとサーバーの次の転送データは、送信するために、お互いの公開鍵で暗号化され、他の当事者は、セキュリティの役割をするように、自分の秘密鍵で復号化される 非対称暗号化は、より複雑であり、より多くの時間を必要としますが、上記の暗号化のどれに関係なく、最も安全ではありませんが、しばしば中間者攻撃と呼ばれる攻撃があるので

中間者攻撃

中間者攻撃（man-in-the-middle attack）とは、クライアントやサーバーの通信を傍受し、暗号化を行う攻撃のことです。対称暗号の場合、鍵の転送が必要ですが、この転送を第三者のサーバーが簡単に傍受して情報を得ることができます。非対称暗号化の場合、秘密鍵を復号化するためには公開鍵の暗号化が必要なため、クライアントやサーバの公開鍵の傍受はほとんど意味がありませんが、中間者攻撃は一般的に非常に強力で、彼はあなたの公開鍵を傍受し、自分の公開鍵に置き換えることができます、そして、あなたは自分の秘密鍵を持っている中間者の公開鍵を使用し、完全に復号化することができます。

CA

HTTPSプロトコルは非常に安全であると主張しているので、その暗号化プロセスは確かにそう単純ではありません。HTPPSの暗号化は、実際にはより複雑であり、CA証明書を利用する必要があり、なぜCA証明書は安全である、我々は彼の全体のプロセスを見てする必要があります。

• サーバーは、まず証明書を購入するためにCA認証機関に行く必要があり、このステップは、あなたが何かを購入するために淘宝網に行くのと同じように、偽造することはできません、ビジネスは証明書の購入で、自分の公開鍵、ドメイン名といくつかの他の情報を提供する必要があり、他の誰かに置き換えられることはありません。 CA認証機関はまた、ビジネスの責任を取る、オンラインとオフラインであなたの正当性を確認するためにされ、それが正式な会社や集団であるかどうか、その後、発行された証明書をお渡しします。証明書は、確認が完了した後、証明書を発行する前に、すべての検証、。では、証明書には何が記載されているのでしょうか？

  1: 証明書には、購入者のドメイン名、公開鍵、CA認証局に関する情報などが含まれます。

  2：デジタル署名を含む、これは非常に重要です、デジタル署名はどのように？まず、CAは上記1の情報の要約を生成し、自分のCAの秘密鍵を使ってこの要約を暗号化し、署名を生成します。

• さて、サーバーは証明書を持って、リクエストを確立するためにクライアントは、サーバーがクライアントに証明書を送信し、クライアントは、証明書の正当性を確認し、一度合法、あなたはHTTPSセッションパスワードを生成する前提であるサーバーの公開鍵を取得することができます。

証明書の正当性を確認する方法

ブラウザは多くの認証局と提携しており、多くの認証局のルート証明書はオペレーティングシステム内に保管されています。そうでない場合は、証明書をアップロードする必要があります。オペレーティングシステムがすでに認証局のルート証明書を持っているとします。彼は証明書の公開鍵を取得するルート証明書によると、サーバーから送信されたCA証明書を受信したとき、それは復号化することができる場合は、証明書が正当であり、その後、中間者攻撃は、ルート証明書を取得することはありません？これは、証明書の発行は、オンラインとオフラインの調査を確認する必要があるので、ミドルマンの偽造証明書を心配しないで、そう簡単ではないと言われています。

では、どのようにして証明書の内容が改ざんされていないことを確認するのでしょうか？

ハッカーが証明書を置き換えることはありませんが、上記のように、証明書の正当性の保証は、彼はまだ証明書をコンパイルする能力を持っている、どのように証明書が改ざんされていないことを確認するには、この時間は、証明書の要約は、プレイの内部では、仲介者が証明書の内容を変更した場合、クライアントは、要約の生成に自己証明書のルートによると、要約とサーバーが要約を送信する場合は、証明書の情報のコンパイルと同じではありません。同じことが成文化され、その後、誰かが真ん中が証明書情報を変更し、その後、彼らはまた、要約を変更すると言うだろう、これは不可能ですが、一度電子署名の内容を移動したいので、まず、要約を置き換えるために署名を復号化するために、対応するCA証明書の公開鍵を持っている必要があり、一般的に持っていない、上記は、ルート証明書を取得したいと述べたので、あなたはCA機関によって認定される必要があり、あなたが要約を置き換えるために公開鍵を取得する場合でも、外が、署名は、CA機関への必要性であり、証明書の要約は、CA機関のキーです。しかし、署名は、CA機関の秘密鍵の暗号化の要約を生成するために必要な、CA機関の秘密鍵は、一般的なハッカーは確かに持っていないので、このような状況を達成することは不可能と見なされます。

HTPPS

CA証明書は、すでに知っている上で説明し、非常に安全な状況にすることができ、サーバーの公開鍵を取得し、HTPPSは、対称暗号化、情報の暗号化配信として、この公開鍵の使用ではありませんか？実際には、いや、実際の状況は、このCA証明書は、HTTPSプロトコルの暗号化プロセスの一部であるよりも複雑なので、プロセスの次の主な説明は、それがどのように見えるか、まず絵を見てください！

説明

上図の一般的な説明

• HTPPSリクエスト時の最初のRTTは、通常のTCPの3回のハンドシェイクプロセスであ り、これは入力がないことを想定しています。https://,下面会说
• HTPPSサイトでは、サイト名を入力した他人が必ずしもHTTPSを入力するとは限らないため、今回の背景には302ジャンプを設定する必要があります。
• HTTPSのデフォルト・ポートは443なので、TCPハンドシェイクを3回やり直す必要があります。
• TSLハンドシェークフェーズ 1
• TSLハンドシェイクの第 2 フェーズ

TSLハンドシェイクの第一フェーズ

Client Hello

TSLハンドシェイクの最初のフェーズ。クライアントは最初にClient Helloを開始します。

• クライアントがサポートするプロトコルのバージョン
• 後でセッション鍵を生成するための32ビットの乱数。
• サポート可能な暗号化スイート、重要

Server Hello

クライアントHelloを受信すると、サーバーは次のような応答を返さなければなりません。

• 通信プロトコルのバージョン確認
• 後でセッション鍵を生成するための32ビットの乱数。
• 確認された暗号化スイート、異なる暗号化スイートが異なるアクションを生成することが重要です。

Server Certificate

このプロセスは、上記のサーバーは、クライアントプロセスに証明書を送信するために、クライアントは、証明書を取得するには、最初の証明書の正当性を確認し、それがコンパイルされているかどうか、証明書の内容を見ます。もし正常であれば、証明書の内容はサーバーの公開鍵を取得するために取得されます。この時、上の質問に答えますが、この公開鍵は最終的なセッション暗号鍵ではなく、最終的な対称暗号鍵を生成するためのものです。つまり、HTTPSの暗号化は、実際には非対称暗号化と対称暗号化を含むプロセスであり、最終的な通信の暗号化は実際には対称暗号化です。

Server key Exchange

このプロセスは、実際には非常に複雑ですが、それは、主に暗号化スイートの最終的な確認に基づいて、決定を感じるように、RSA、ECDHEの2種類の鍵交換、暗号化スイートは、次のDHE_DSS、DHE_RSA、ECDHE_ECDSA、ECDHE_RSAに属していない場合、これらの種類の直接プロセスをスキップされるオプションです、それはケースに属している場合、それは送信されます。キーを確認するための追加データが送信されます。最も完全なTengine HTTPSの原則分析、実践とデバッグのhttpsハンドシェーク処理の詳細、これらの2つの記事の詳細な説明を持っています。

Server Hello Done

これは、サーバーが送信を終了し、クライアントからの応答を待っていることをクライアントに伝えます。

TSLハンドシェイクの第 2 フェーズ

Client key Exchange

Server key Exchangeの段階を省略した場合、クライアントはリクエスト元のサーバから送られた乱数とリクエスト元のサーバから送られた乱数を受け取り、連結を行ってプレマスター鍵を生成し、それをサーバの公開鍵で暗号化してサーバに送ります。サーバ鍵交換の段階を省略しない場合は、プレマスター鍵の生成について、上のリンク先の2つの記事を参照してください。

Change Cipher Spec

この合意は、私が解決したと相手に伝えることを指します。

Client Finished

私側のメッセージが送信されたことをサーバーに伝えます。

Change Cipher Spec Message

相手には、あなたが送ってくれたプレマスター・キーと、あなたの乱数、そして私の乱数を使って、同じセッション・キーを生成する、と伝えてください。

Server Finished

クライアントにもここに送ったと伝えてください。

プレマスターキー、マスターキー、セッションキーの違い

• プリマスタ鍵は主にTSLハンドシェイクの第2フェーズでクライアントが生成します。
• マスター鍵は、PRE関数で生成されたプレマスター鍵、クライアント乱数、サーバ乱数
• セッション鍵はマスター鍵、クライアント乱数、サーバ乱数からPRE関数により生成され、TSLの共通鍵はこのセッション暗号となります。