1 つ: http

1. http メッセージの理解

リモートアドレス :アクセス先 URL から解析された IPアドレス、 443 : 現在の https プロトコルを示します。

リファラーポリシー: リファラーユーザーは現在のリクエストのソースページを指定します。同じソースからのリクエストの場合、ホットリンクを防ぐために完全な URL がリファラーアドレスとして送信されます。

accept : リクエストは応答フォーマットのリスト情報をサポートできます

accept-encoding : ローカルブラウザが圧縮をサポートしていることをサーバーに伝えます

sec-fetch-dest : 予期されるリソースのタイプ

sec-fetch-mode : navigate 、これがブラウザのページ切り替えリクエストであることを示します

sec-fetch-site : リクエストの送信元とターゲットリソースのソースとの関係を示します。クロスサイト: クロスドメインリクエスト、 same-origin: 同一オリジンリクエストです。none: 同一オリジンでもクロスドメインでもない、リクエストはいかなるコンテキストとも関係がありません。たとえば、ブラウザウィンドウにファイルをドラッグアンドドロップします。

秒フェッチユーザー： 表示一个导航请求是否由用户激活触发（如用户主动点击鼠标、键盘） 。

Sec-Fetch-User: ?0 いいえ Sec-Fetch-User: ?1 はい

upgrade-insecure-requests: 1. ブラウザは、アクセスされた httpsリクエストに他のhttpリクエストが含まれている場合でも、ブラウザが https リクエストを処理できることをサーバーに伝えます。

user-agent : ブラウザを説明する情報

応答の属性は基本的にリクエストの属性に対応しており、サポートされている属性の 1 つが選択されて使用されます。

2つを紹介します。

サーバー : Web アプリケーションがデプロイされるコンテナー。 openresty : Nginx およびサードパーティのクラスライブラリ、Lua 言語、 redis などをカプセル化します。

変更 : エンコーディングを受け入れます。リクエスト内の accept-Encoding 属性を参照して、どの形式がサポートされているかを確認し、対応する形式 (圧縮または非圧縮) のリソースをキャッシュするようにプロキシサーバーに指示します。プロキシサーバーとは、CDN などのさまざまなリージョンにあるエッジサーバーを指し、すべてのリクエストがメインサーバーを要求することは不可能です。

2. http リンク管理 - TCP

HTTP 通信は tpc/ip に基づいており、https には追加のセキュリティ層があるため、https は安全です。

TCP は、接続を確立してデータを送信するためのパイプラインです。デバイスは同時に複数のパイプを持つことができるため、TCP はエンベロープのようなもの、つまり各パイプのデータパケットを分離する TCB データ構造を使用します。

TCP では、接続を確立するには 3 ウェイハンドシェイクが必要で、接続を解放するには 4 回のハンドシェイクが必要です。

1. スリーウェイハンドシェイク:

( 0 ) 準備

最初は、クライアントとサーバーの両方が CLOSED 状態にあります。クライアントは能動的に接続を開き、サーバーは受動的に接続を開きます。

TCP サーバープロセスは、まず送信制御ブロック TCBを作成し、クライアントプロセスの接続要求を常に受け付けられるようにしており、この時点でサーバーは LISTEN (監視) 状態になります。

( 1 ) 握手 1 回:

TCP クライアントは、送信制御ブロック TCB を作成し、サーバーに接続要求メッセージを送信します。メッセージヘッダーの同期ビット SYN=1 は、同期を開始して接続を確立し、同時に接続を選択することを示します。初期シーケンス番号 seq=x は識別子であり、追跡を蓄積する必要があります。

この時点で、TCPクライアントプロセスは SYN-SENT (同期送信状態) 状態に入ります。

TCP では、SYN セグメント ( SYN=1 セグメント) はデータを伝送できないが、シーケンス番号を消費する必要があると規定しています。

( 2 ) 2 回目のハンドシェイク:

TCP サーバーはリクエストメッセージを受信した後、接続に同意すると、確認メッセージを送信します。

ACK=1 は、接続を確立することに同意して確認することを意味します (0 は確認情報を含まないことを意味します)。

ack=x+1、確認応答番号。前のクライアントによって開始された要求を確認します。

SYN=1、サーバーも同期を開始することを示します

seq=y 、クライアントとの同期を開始するには、独自のシリアル番号も必要です。

この時点で、TCPサーバープロセスは SYN-RCVD (同期受信) 状態に入ります。

( 3 ) スリーウェイハンドシェイク:

TCP クライアントは確認を受信した後、サーバーにも確認を行う必要があります。確認メッセージの ACK=1 、

ack=y+1 は、サーバーから送信されたシリアル番号と、自身のシリアル番号 seq=x+1を確認し、この時点で TCP コネクションが確立され、クライアントは ESTABLISHED (コネクション確立) 状態になります。

TCP では、 ACKメッセージセグメントがデータを搬送できると規定していますが、データを搬送しない場合、シーケンス番号は消費されません。

サーバーがクライアントから確認を受信すると、サーバーも確立状態になり、その後、両者は通信を開始できるようになります。

なぜ 3 回目のハンドシェイクが必要なのでしょうか?

表面的には、2 回のハンドシェイク後に接続を確立できますが、これは厳密ではありません。たとえば、クライアントが同期リクエストを送信しましたが、ネットワークまたはその他の理由により、サーバーがそれを一時的に受信しなかったため、クライアントは再試行し、まったく同じリクエストを別のリクエストに送信しました。2 回のハンドシェイクの後、接続が確立されてデータが送信され、最初のリクエストが通常に戻ってサーバーに到着し、サーバーが応答します。このようにして、データを送信するために接続が再度確立されるため、リソースのオーバーヘッドと無駄が発生します。

3 回目のハンドシェイクの後、クライアントがハンドシェイクを再試行するための確認を受け取ったとしても、同じリンクが確立されていることがわかっていても、3 回目のハンドシェイクは実行されません。

また別の角度から：

最初のハンドシェイク: クライアントは送信能力が正常であることのみを確認し、サーバーは受信能力が正常であることのみを確認します。

2 回目のハンドシェイク: クライアントは、自身とサーバーの送信能力と受信能力が正常であることを確認しますが、サーバーは自分の送受信能力が正常であることと、クライアントの送信能力が正常であることのみを知っています (サーバーは、クライアントの送受信能力が正常であるかどうかを知りません)。クライアントは独自の応答を受信しました）。

3 回目のハンドシェイク: サーバーとクライアントの両方が、自分自身と相手の送受信能力を確認します。

TCP プロトコルの欠陥

DDOS は分散型サービス拒否とも呼ばれ、通常の要求に応答しないことを意味します。たとえば、古典的な SYN フラッド攻撃は次のような状況を引き起こします。

1. SYN フラッド攻撃は、まず多数の送信元 IP アドレスを偽造し、それぞれサーバーに大量の SYN パケットを送信します。

2. サーバーは SYN/ACK パケットを返します。送信元アドレスが偽造されているため、偽造された IP は応答しません。

3.サーバーは、偽造 IP からの応答を受信しない場合、 3 ～ 5回再試行し、 SYN 時間(通常 30秒～2分) が経過するまで待機します。タイムアウトになると、接続は破棄されます。

4. 攻撃者は、送信元アドレスを偽造して大量の SYN リクエストを送信します。サーバーは、この半接続を処理するために大量のリソースを消費し、同時にこれらの IP で SYN +ACKを再試行し続けます。

5. 最終的な結果として、サーバーは通常の接続要求に注意を払う時間がなくなり、サービス拒否が発生します。

2. 4 回手を振ります:

データ転送が完了したら、双方が接続を解放できます。最初は、クライアントとサーバーの両方が確立状態 (接続が確立されていることを示します) にあり、その後、クライアントはアクティブに閉じ、サーバーは受動的に閉じます。

( 1 ) TCPクライアントは、(SYN とは対照的に) クライアントからサーバーへのデータ送信を終了するためにFIN を送信します。

( 2 ) サーバーはこの FINを受信すると、シリアル番号が受信したシリアル番号に 1 を加えたものであることを確認するACK を返します。もちろん、この確認には、独立した要求応答を識別する独自のシーケンスも必要です。

( 3 ) サーバーはクライアントの接続を閉じ、クライアントに FIN を送信して、私も接続を閉じたいことを示します ( なぜこの FIN がステップ 2 に配置されないのか) 。

( 4 ) クライアントは確認用の ACK メッセージを返信し、受信したシーケンス番号に 1を加えた値を確認シーケンス番号に設定します。

サーバー側の FIN がステップ 2 に配置されないのはなぜですか?

接続を閉じるとき、サーバーが相手の FIN メッセージを受信したとき、それは相手がデータを送信しなくなったことを意味するだけですが、相手は引き続きデータを受信でき、すべてのデータを相手に送信していない 可能性があります。相手に何らかのデータを送信し、すぐに接続を閉じることに同意するために FIN メッセージを相手に送信することも可能です。そのため、サーバーの ACK と FIN は通常別々に送信されます。これも 3 回のハンドシェイクであり、4 回のハンドシェイクの理由です。

接続は確立されているが、クライアントが突然失敗した場合はどうなるでしょうか?

サーバーにはタイマーがあり、クライアントからのリクエストを受信するたびにリセットされ、2 時間以内にデータを受信しない場合、検出メッセージを送信し、その後 75 秒に 1 回、合計 10 回検出します。フィードバックがない場合、接続は閉じられます。

3. TCP データ送信方式 - スライディングウィンドウプロトコル

TCP伝送はメッセージを複数の部分に分割して順次送信しますが、ネットワークにはトラフィックサイズの制限があるため、通常、各部分のサイズはデフォルトで536バイトで、受信後に順番につなぎ合わされます。そこで問題となるのが、シリアルに送信すると効率が低すぎ、パラレルに送信するとネットワークの輻輳を引き起こす可能性があるということです。この程度をどのように把握すればよいでしょうか？

スライディングウィンドウを使用して、セグメントのデータサイズとネットワークの状況に応じて、毎回適切な数のセグメントを送信し、どのセグメントを送信するかを決定します。図に示すように:

グレー: 送信され、承認されました。

黄色: 送信されましたが、確認されていません。

緑: 送信を待っていますが、まだ確認されていません。

白: 送信も確認もされていません。

スライディングウィンドウは、データの中央の 2 つの部分を管理します。たとえば、5 が確定すると、ウィンドウが 1 グリッド右に移動し、5 は灰色になり、10 は黄色に送信され、12 はメモリに追加されて送信準備が整い、緑色になります。（もちろん、必ずしも一つの段落だけを扱うわけではありません）

タイムアウト再送信:

スライディングウィンドウでは、各セグメントが正常に送信され確認されたかどうかを確認できますが、5 がブロックされて 5 の ACK を待っている場合、12 を追加することはできません。。このとき、5 回再試行されますが、原理としては、再試行の待ち時間を決定するタイムアウト再送時間 RTO があり、初回のデフォルトは 6 秒で、その後の 2 と 4 の倍数は指数関数的に増加します。再試行回数が制限に達すると、問題があるとみなされ、接続が閉じられます。

4. TCP パフォーマンス分析

http トランザクションにかかる時間には主に次のものが含まれます。

DNS 解決。URL 内のドメイン名をサーバーの IP に解決します。

TCP 接続 (3 ウェイハンドシェイク) を確立します。

ネットワークがメッセージを送信し、サーバーがメッセージを処理するまでには時間がかかります。

サーバーはメッセージを返します。

これらの問題は、ネットワークとデバイスのパフォーマンスに大きく関係しています。ネットワークと機器の状態が良好な場合、パフォーマンスは主に TCP に依存します。

TCP パフォーマンスの問題を作成します。

TCP の確立には 3 ウェイハンドシェイクが必要です。

http リンクを確立するには、TCP を確立する必要があります。これには 3 回のハンドシェイク後に時間がかかります。ページを開くために大量の http にアクセスする必要がある場合、表示されるまでに時間がかかります。

TCP スロースタート:

上で述べたように、スライディングウィンドウはネットワークに応じて送信するパケットの数を決定できますが、どのように決定するのでしょうか? 実際、TCP は確立された後、ネットワークの状況を継続的に検出し、初めて 1 つ、2 回目で 2 つ、4 つ... 適切な量に達するまで送信します。http に多くのパケットメッセージが含まれている場合、一度にすべてを送信することはできません。

遅延確認ACK:

ACK 確認を実行するとき、ネットワークを効果的に使用するために、他の出力データを「便乗」しようとします。つまり、すぐに相手にACK確認を返すのではなく、途中で返せるデータがあるかどうかを一定時間待ってみるということです。そうでない場合、待つのは時間の無駄です。つまり、遅延確認 ACK アルゴリズムにより、ある程度のパフォーマンスの低下が発生します。

5.HTTP機能

TCPの特性上、ページを開く際に複数のhttpにアクセスする、つまり複数のTCPリクエストを確立する必要があると考えられますが、それをシリアルに実行した場合、ページの読み込みはどのくらい遅くなりますか。http は最適なパフォーマンスを達成するために TCP をどのように使用しますか?

並列接続

複数の TCP は、最初の TCP の終了を待たずに、2 番目の TCP を作成する前に並行して実行されます。(もちろん、いくつの http リクエストがあり、いくつの TCP が並行して作成されるかを言うことは不可能なので、サーバーが使い果たされてはいけません。たとえば、ブラウザは実際に同じドメイン名、同じオリジンに対して http リクエストを作成します)リクエストを実行し、並行して TCP の数を作成します。制限。ほとんどのブラウザは 6 です。)

永続的な接続

接続: キープアライブ

アクセス頻度の高いサイトへのリンクの場合、多重化を常にオンにして、毎回 TCP を作成する手間を省くことができます。 HTTP/1.1 (および HTTP/1.0 に対するさまざまな拡張機能) がサポートされるようになりました。もちろん、同じ接続内で複数の http トランザクションがシリアル化されます (次のトランザクションは 1 つのトランザクションが終了した後にのみ開始できます) 。

パイプ接続

永続的な接続に基づいて、パフォーマンスを向上させるために、複数の HTTP トランザクションが 1 つの TCP でシリアル化されず、応答が到着する前に複数の要求をキューに入れることができます。最初のリクエストがネットワークを介して相手側のサーバーに流れている間に、2 番目と 3 番目のリクエストも送信を開始する可能性があります。

パイプライン接続にはいくつかの制限があります。

パケットは、要求されたのと同じ順序で返されなければなりません。http リクエストメッセージにはシリアル番号ラベルがないため、一度順序を間違えると混乱を引き起こします。したがって、応答は順序立てて行う必要があります。ただし、リクエストに時間がかかりすぎると、後続のリクエストが蓄積してブロックされる可能性が高くなります。

クライアントはいつでも接続が切断される可能性があることに備えておく必要があります。これが発生した場合、クライアントは適切に応答して、失敗したリクエストを再送信できなければなりません。

べき等なリクエストのみをパイプライン処理できます。 GET などの冪等リクエストの場合、ブラウザは get の URL をキャッシュして毎回同じ結果を返すことができますが、POST は書き込み操作であるため、毎回新しいリソースが作成される可能性があります。

上記で紹介した http 機能は、http の開発中に継続的に最適化されます。HTTP1.1でのみ利用できる永続的な接続とパイプライン技術とはどのようなものですか。http2 に入ってからパフォーマンスが飛躍的に向上しました。http2の特徴を見てみましょう。

6. http2の新機能

バイナリフレーム化: http2 パフォーマンス強化の中心

HTTP 2.0 は、送信されるすべての情報を小さなメッセージとフレームに分割し、バイナリ形式でエンコードします。HTTP1.x のヘッダー情報はヘッダーフレームにカプセル化され、リクエストの本文はデータフレームにカプセル化されます。

フレームはデータ伝送の最小単位であり、元の平文伝送はバイナリ伝送に置き換えられます。

Connection-connection : HTTP 2.0のすべての通信は、任意の数の双方向データストリームを伝送できるTCP接続上で完了します。

ストリームデータストリーム:データストリームはメッセージの形式で送信され、各データストリームには複数のメッセージが含まれます。各ストリームには一意の整数の識別子があり、両端でのストリームID の競合を防ぐために、クライアントによって開始されたストリームには奇数のIDが付けられ、サーバーによって開始されたストリームには偶数の ID が付けられます。

メッセージ - メッセージ: メッセージは 1 つ以上のフレームで構成されます。たとえば、一連のDATAフレームとHEADERSフレームで完全な http リクエストメッセージが構成されます。

Frame-frame : 各フレームヘッダーには、どのフローに属しているかを表すフロー識別子があるため、順番を間違えて送信し、受信側で再組み立てすることができます。

http パフォーマンスの鍵となるのは、高帯域幅ではなく、低遅延です。通常、http リクエストの時間は非常に短く、場合によっては突然です。この短期間内で、TCP 接続の作成と終了にほとんどの時間がかかる場合、パフォーマンスは確実に低下します。逆に、TCP 接続が長期間維持でき、すべての HTTP がそれを共有する場合、TCP の作成によるパフォーマンスの問題は無視できます。http2.0はこれをうまく利用しています。

頭部圧縮

HTTP/1 では、HTTPリクエストとレスポンスは「ステータス行、リクエスト/レスポンスヘッダー、メッセージボディ」で構成されます。

ボディ」は 3 つの部分から構成されます。通常、ボディ部分はgzip（またはそれ自体が画像音声などの圧縮バイナリファイル）で圧縮して送信されますが、ヘッダ部分は平文で送信されるため、多くのページで数十、数百のリクエストが生成され、ヘッダー部分も送信されるため、多くのトラフィックを消費します。

新しい圧縮方式 HPACK は HTTP/2 プロトコルで定義されており、ブラウザとサーバーの両方が HTTP2 をサポートしている必要があります。原則として、両端が同じ静的テーブルと同じ動的テーブルを維持します。同じテーブルを使用すると、ヘッダーの送信時にインデックス値を渡すことができ、受信側はインデックス値に従ってコンテンツを解析できます。

静的テーブル: ヘッダーに事前定義された 61 個の変更不可能な汎用名と値があります

動的テーブル:カスタム値などの静的テーブルには存在しません。もちろん、初回はプレーンテキストで送信する必要がありますが、受信側はそれを維持し、後でインデックスを送信することができます。

多重化
- http1.1以降でもパイプライン接続は可能ですが、ブラウザには同一ドメイン名でのリクエスト数に制限があり、制限数を超えたリクエストはブロックされます。これが、一部のサイトに複数の静的リソース CDN ドメイン名がある理由の 1 つです。
- HTTP 2.0接続は永続的であり、クライアントとサーバー間で必要な接続は 1 つだけです (それぞれ
  
  ドメイン名 1 つの接続)、http2接続は数十または数百の多重化ストリームを伝送でき、多重化手段
  
  これは、多くのフローからのパケットが混在する可能性があることを意味します。エンドポイントに到達すると、異なるフレームヘッダーのストリーム識別子に従って、異なるデータストリームが再組み立てされます。
  
  複数のストリームを混合することはできますが、フレーム内の識別子はストリームの ID であり、どのストリームに属しているかを区別することしかできないため、同じストリーム内のフレームは順序どおりである必要があります。
サーバープッシュ

サーバーはクライアント要求に対して複数の応答を送信し、クライアントが明示的に要求しなくてもリソースをクライアントにプッシュできます。たとえば、サーバーは、クライアントが必要とするリソースを、index.html とともにクライアントに送信できます。これにより、クライアントからの複数のリクエストの手順が節約されます(リクエストがクライアントのホームページによって開始されると、サーバーはおそらく次のリクエストに応答します)。ホームページのコンテンツ、ロゴ、スタイルシート、その他のリソース）、速度が大幅に向上します。

さらに、サーバープッシュにはキャッシュできるというもう 1 つの大きな利点があります。また、同じオリジンをたどりながら、異なるページ間でキャッシュリソースを共有することも可能になります。

サーバーが特定のリソースをアクティブにプッシュする必要がある場合、フレームタイプが PUSH_PROMISE のフレームを送信します。これには、 PUSHが作成する必要がある新しいストリーム IDが含まれています。これは、クライアントに「次に、この ID を使用して何かを送信します。クライアントは続行する準備ができています」と伝えることを意味します。クライアントはフレームを解析し、それが PUSH_PROMISEタイプであることを検出すると、サーバーによってプッシュされるストリームを受信する準備をします。

http2 以降、TCP の使用は限界に達し、パフォーマンスのボトルネックのほとんどが TCP 自体の特性に集中しているため、http3 では TCP に代わって UDP が使用され始めています。将来的には http3 が主流になることは間違いありません。

2:https

https は、http をベースにセキュリティ層 SSL/TLS を追加するものであり (これはセキュリティプロトコルであり、現在 SSL はほとんど使用されていませんが、TLS が使用されています)、その機能は http 通信をより安全にすることだけです。したがって、https は、http1、http2、http3 とは何の関係もありません。http のバージョンに関係なく、セキュリティ層が設定されている限り、https になります (ただし、http2 以降のバージョンの http では、デフォルトでセキュリティ層を設定する必要があります) 。 https をデフォルトとして使用する必要があります) ベース)。

https はどのように安全ですか? 実際、これはクライアントとサーバー間のブリッジを提供して、両者が暗号文を送信するための暗号化アルゴリズムに合意できるようにするためのものであり、暗号文を解析できるのは 2 者だけです。https について理解する前に、いくつかの基本概念を見てみましょう。

対称暗号化:

暗号化と復号化の両方で同じキー、一般的に使用されるアルゴリズムが使用されます。

DES ( Data Encryption Standard): データ暗号化規格 (暗号化強度が十分ではなく、乱暴に解読される可能性があります)

3DES : 原理はDESとほぼ同じですが、暗号化強度を高めるために3 つのキーを使用して同じデータを 3 回暗号化する点が異なります。(デメリット: 3つのキーをメンテナンスする必要があり、メンテナンスコストが大幅に増加します)

AES ( Advanced Encryption Standard ): 米国国家安全保障局によって現在使用されているオリジナルの DES を置き換えるために使用される Advanced Encryption Standard。Apple のキーチェーンアクセスはAES暗号化を使用します。これは現在、最も安全な暗号化方法であり、対称キー暗号化の最も一般的なアルゴリズムとして認識されています。AES128 とAES256の主な違いは、鍵の長さ (それぞれ128 ビット、256 ビット) と暗号化処理ラウンド数 (それぞれ10ラウンド、14ラウンド) であり、後者の強度は前者よりも高くなります。

利点:高速で暗号化効率が高い。

短所: 秘密鍵は 1 つしかないため安全ではなく、傍受されると簡単に解読されます。

非対称暗号化:

公開キーと秘密キーという秘密キーのペアがあります。公開キー暗号化には復号化するために秘密キーが必要であり、その逆も同様です。一般的に使用されるアルゴリズム:

RSA 、 DSA 、 ECDSA等。

メリット：アルゴリズムが複雑で解読が困難である公開鍵はクライアント側、秘密鍵はサーバー側に存在するため、対称暗号のように秘密鍵を送信する必要がなく、安全性が大幅に向上する。

デメリット：対称暗号ほど効率が良くない、また、公開鍵が公開されているため漏洩する可能性がある。

上記 2 つの暗号化方式にはそれぞれ長所と短所があるため、組み合わせることができます。送信される業務データは対称暗号化（高効率）で暗号化されますが、対称暗号化の秘密鍵は、安全性を確保するため、まず非対称暗号化により暗号化されます。以下に示すように:

現時点でもまだ問題が残っています。クライアントリクエストが最初からハッカーによって傍受されている場合、つまり、リクエストが常に偽のサーバーであり、ハッカーがそれを認識していない場合、まだ問題が残っています。以下に示すように:

この問題を解決するには、次の 2 つのことを確認する必要があります。

1. 送信されたメッセージが改ざんされているかどうか。解決策: デジタル署名。

2. サーバーの ID が偽装されているかどうか。解決策: デジタル証明書。

デジタル署名: メッセージの出所とメッセージの完全性を判断するため

送信者:ハッシュアルゴリズムを通じて メッセージダイジェストを生成し、秘密キーでダイジェストを暗号化してデジタル署名を取得し、元のメッセージとデジタル署名を一緒に送信します。

受信者: 公開キーを使用してデジタル署名を復号化し、ダイジェスト 1 を取得します (復号化は、メッセージが実際に送信者によって送信され、秘密キーと公開キーが一致することを意味します)。次に、同じハッシュアルゴリズムを使用してダイジェストを生成します。 -元のメッセージのダイジェスト 2 そして、それをダイジェスト 1 と比較します (ダイジェスト 1 と 2 が同じである限り、メッセージが改ざんされていないことを意味します)。

デジタル証明書:メッセージの送信者が正当であることを証明します

デジタル証明書は ID カードのようなもので、権威ある組織の認証センターによって送信者 (サーバー) に発行され、サーバーが合法であることを証明します。ただし、権威ある認証局 ( Certificate Authority 、略して CA ) は世界にそれほど多くないため、正規のサーバーはまず CA に証明書を申請する必要があります。

実際、私たちが使用する証明書には多くの種類があり、SSL 証明書はそのうちの 1 つにすぎません。これらはHTTPプロトコル、つまりHTTPSとTLSの暗号化に使用されます。Webアプリケーションを https にアップグレードする場合は、証明書を購入する必要があります。

プロセスは次のとおりです。

サーバーの運営者は、公開鍵、組織情報、ドメイン名などの情報を第三者機関CA（またはその代理店）に提出し、認証を申請します。

CAは、オンライン、オフラインなどのさまざまな手段を通じて、申請者から提供された情報の信頼性を検証します。

情報が承認されると、CA は認証文書(証明書) を申請者に発行します。証明書の内容には、申請者の公開鍵、申請者の組織情報および個人情報、発行機関の情報、有効期間、証明書のシリアル番号などが平文で含まれ、また、証明書のデジタル署名も含まれます。 CA組織。署名アルゴリズムは、ハッシュ関数を使用して上記の平文情報を計算し、情報の概要を取得し、次にCAの秘密キーを使用して情報の概要を暗号化します。これは証明書自体の署名です。

クライアント (ブラウザなど) が https 経由でサーバーと通信する場合、最初にサーバーの CA 証明書を要求して検証する必要があります。ブラウザやOSなどには、あらかじめ多くのCA証明書が組み込まれており、つまりCAの公開鍵情報を持っています（OSは正規のものである必要があります）。このとき、サーバーの証明書署名を要求されると、復号化して証明書の内容が正当であるかどうかを検証することができます。

証明書が合法であれば、サーバーの CA 証明書の内容を取得できます。つまり、サーバーの公開キーを取得できます (このように、公開キーは安全であり、サーバーは合法である必要があります)。次に、両当事者は、前述したように、非対称暗号化および対称暗号化を通じてビジネスデータを送信できます。

SSL 証明書の分類:

DV （ドメインベース SSL ）：個人サイト

OV (Enterprise SSL ): 企業の公式 Web サイト

EV (Enhanced SSL ): セキュリティ要件が強化された企業公式 Web サイト、電子商取引、インターネット金融 Web サイト

3: http を https にアップグレードする

https を導入した後、http を https にアップグレードするにはどうすればよいですか? まず CA 証明書を申請し、サーバー側で https を設定します。プロセスは次のとおりです。

証明書を申請します。

Alibaba Cloud に直接アクセスして購入できます: Alibaba Cloud ログイン - 安全で安定したクラウドコンピューティングサービスプラットフォームである Alibaba Cloud へようこそ

証明書をダウンロードします。

購入が成功したら、Alibaba Cloud コンソールにログインしてダウンロードします。解凍後、証明書ファイルと秘密鍵ファイルの 2 つのファイルが取得されます。

Nginx 設定 https:

Nginx インストールディレクトリ (デフォルトは /usr/local/nginx/conf ) にcert ディレクトリを作成し、解凍した 2 つのファイルをこのディレクトリにアップロードします。

設定ファイルの設定: vim /usr/local/nginx/conf/nginx.conf、次のような設定:

# 次の属性の sslで始まる属性は証明書の構成に関連しています。他の属性は必要に応じてください。

設定します。

サーバー {

#HTTPSのデフォルトのアクセスポート番号を 443 に設定します。デフォルトのHTTPSが設定されていない場合はここで

ポートにアクセスすると、 Nginx の起動に失敗する可能性があります。

#Nginx 1.15.0 以降では、 listen 443 の代わりにlisten 443 sslを使用してください。

と SSLがオンになっています。

443 SSL をリッスンします。

#www.certificatestests.com を証明書にバインドされたドメイン名に変更します。たとえば、

例: www.example.com 。ワイルドカードドメイン名証明書を購入した場合は、

# ワイルドカードドメイン名に変更するには、例: *.aliyun.com 。

サーバー名 www.certificatestests.com;

#リターンを通じてすべての HTTP リクエストを HTTPSにリダイレクトします(ユーザーはドメイン名を入力するときに https を追加しません。デフォルトは http であり、自動的に https にジャンプする必要があります) 。

戻り値 301 https:// $server_name$request_uri ;
ルートHTML;

インデックスindex.htmlインデックス.htm;

#domain name.pem を証明書のファイル名に置き換えます。

ssl_certificate 証明書/ドメイン名.pem;

#domain name.key を証明書のキーファイル名に置き換えます。

ssl_certificate_key 証明書/ドメイン名.key;

ssl_session_timeout 5分;

# この暗号スイートを使用します。

ssl_ciphers ECDHE-RSA-AES128-GCM-

SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;

# このプロトコルを構成に使用します。

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_prefer_server_ciphers がオン。

位置 / {

# サイトディレクトリ。

ルートHTML;

インデックスindex.htmlインデックス.htm;

}}

設定を保存してロードします。

cd /usr/local/nginx/sbin

./nginx -s リロード

構成が完了したら、ドメイン名にアクセスすると、ドメイン名のアドレスバーにロックが追加されていることがわかります。

4: https パフォーマンスの最適化

http に基づいて、https はセキュリティ層を追加しますが、そのパフォーマンスは http より悪く、主に以下の点に反映されます。

1.ネットワークRTT (ラウンドトリップタイム: クライアントとサーバーの対話の往復時間) は、プロトコルの対話によって増加します。

3 ウェイ TCP ハンドシェイクを通過することに加えて、セキュリティや暗号化方法などを決定するために TLS セキュリティプロトコルハンドシェイクも通過する必要があるためです。さらに、多くのユーザーは HTTP を使用して Web サイトをリクエストすることに慣れています。まず、ユーザーに 302/301 をHTTPSに強制させます。このジャンプにより遅延が少なくとも1 RTT増加します。1 RTT 遅延。

ちなみに 301 と 302 については次のとおりです。

Web アプリケーションが https をサポートしている場合、クライアントは http://xxx にアクセスし、サーバー (Nginx) がリクエストを受信した後、そのリクエストが http リクエストであることを認識すると、ブラウザにリクエストを再送信するように指示するために 301 を返すことができます。リダイレクトステータスコードと理由フレーズ:

301 リダイレクト: 301 は永久転送 (永久に移動) を表します。

302 リダイレクト: 302 は一時的な転送 (Temporarily Moved) を表します。

2. 暗号化と復号化に関連して計算時間がかかります。送信中のデータの暗号化と復号化では、各ステップで複雑な計算、対称、非対称、データ署名、証明書の検証などが行われます。

最適化戦略:

1、誤スタート

通常の状況では、TSL ハンドシェイクプロトコルは 2 つの RTT を経由し、双方が乱数を送信し、サーバーが証明書を送信し、クライアントが暗号化リストとその他のサーバー側の確認暗号化方式を送信します。パケットキャプチャツールを使用すると、ビジネスデータアプリケーションデータを送信する前に 2 つの RTT が経過していることがわかります。

誤った開始とは、2 番目の RTT で暗号化アルゴリズムを確認するのを待たずに、ビジネスデータを先制して送信することを意味します。暗号化方式を確認するプロセスを目的としていますが、現在の主流および一般的な暗号化方式はデフォルトでクライアントによってサポートされているため、サーバー自体で直接設定および決定するだけでよく、クライアントが最初に送信する必要はありません。暗号化方式リストをサーバーに送信して確認するという処理です。

どうやって開けるのですか？

まず第一に、ほとんどのクライアント (ブラウザー) はデフォルトでこのモードをサポートするようになり、一般的な暗号化方式を設定し、サーバー側 nginx でこのモードを有効にするだけで済みます。

# サーバー {

# リッスン 443 ssl http2 デフォルトサーバー;

# listen [::]:443 ssl http2 デフォルトサーバー;

＃サーバーの名前 _;

# ルート /usr/share/nginx/html;

#

# ssl_certificate "/etc/pki/nginx/server.crt";

# ssl_certificate_key

"/etc/pki/nginx/private/server.key";

# ssl_session_cache 共有:SSL:1m;

# ssl_session_timeout 10分;

ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!aNULL:!MD5;

ssl_prefer_server_ciphers がオン。

#

# #……

# }

2. http2 にアップグレードする

http2 の利点は上記で学んだように、パフォーマンスが大幅に向上しました。したがって、https を http2 にアップグレードすると、大幅に改善されます。

設定は非常に簡単です。ポート 443 の後に http2 を指定します。

バージョン:0.9 StartHTML:0000000105 EndHTML:0000003722 StartFragment:0000000141 EndFragment:0000003682

# サーバー {

# https にアップグレードした後のWebアプリケーションは、送信用にhttp2プロトコルに基づいています

443 ssl http2 をリッスンします。

# listen [::]:443 ssl http2 デフォルトサーバー;

＃サーバーの名前 _;

# ルート /usr/share/nginx/html;

#

# ssl_certificate "/etc/pki/nginx/server.crt";

# ssl_certificate_key

"/etc/pki/nginx/private/server.key";

# ssl_session_cache 共有:SSL:1m;

# ssl_session_timeout 10分;

# ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-

SHA256:RC4:HIGH:!aNULL:!MD5;

# ssl_prefer_server_ciphers をオンにします。

#

# #……

# }

3. セッションの回復

SSL/TLS のセッションは、クライアントとサーバー間の対話の記録を保存するために使用される HTTPセッションに似ており、ここでのSSLセッションはSSLハンドシェイクレコードを保存します。以前にハンドシェークに成功したセッションをクライアントとサーバー間で再利用できる場合は、再度シェークする必要はありません。セッションの再利用を実現するには、次の 2 つの手法があります。

1）セッションID

TLS ハンドシェイクの結果、対称的に暗号化されたデータチャネルが確立され、このデータチャネルに関連するパラメータが確立されます。

データはメモリ、つまりセッションキャッシュに保存できるため、サーバーはセッション ID と呼ばれるこのパラメータ値のセットの IDを生成し、このIDを使用して対称暗号化通信チャネルを直接復元できます。したがって、クライアントの次のリクエスト (Client Hello ) が到着したときに、クライアントがSession IDを保持していれば、サーバーはSession ID に基づいて対応するセキュアコンテキストを見つけ、それによってチャネルを復元できます。

ただし、セッションキャッシュをプロセス間で共有することはできず、 Nginx はマルチプロセスビジネスモデルです。各プロセスに独立したセッションキャッシュがある場合、前回は同じSSL接続がワーカープロセスによって提供され、次回は 1 回だけ提供されることになります。別のワーカープロセスによって提供されます。これにより、 OpenSSL全体でメモリが大量に浪費され、キャッシュの精度が大幅に低下します。

そこでNginx は独自のセッションキャッシュシステムのセットを実装しました. このシステムはクロスプロセスであり, 共有メモリを使用し, 赤黒ツリーの形式でセッションキャッシュを編成し, セッション ID の定義を再定義します. カプセル化は最終的にクロスを形成します-セッションキャッシュを処理します。

Nginx のセッション ID の共有と多重化はssl_session_cacheを通じて設定できます。多くのオプションがあります。次のとおりです。

サーバー {

＃……

# ssl_session_cache オフ | なし | [組み込み[:サイズ]]

[共有:名前:サイズ];

# off: セッションキャッシュの使用は厳しく禁止されています。nginx はクライアントに明示的にそのことを伝えます。

言葉は再利用できません。

# none: セッションキャッシュの使用は若干禁止されています : nginx はクライアントセッションに通知します

再利用可能ですが、実際にはセッションパラメータをキャッシュに保存しません。

#builtin: 組み込み OpenSSL キャッシュ ; 1 つのワーカープロセスによってのみ使用されますキャッシュサイズはセッション単位で指定されます。キャッシュサイズが指定されていない場合、キャッシュサイズは 20480 セッションに相当します。内蔵キャッシュを使用すると、メモリの断片化が発生する可能性があります。

# 共有: キャッシュはすべてのワーカープロセスによって共有されます。キャッシュサイズはバイト単位で指定します。 1MB には約 4000 セッションを保存できます。各共有キャッシュには一意の名前が必要です。同じ名前のキャッシュは複数の仮想サーバーで使用できます。

ssl_session_cache 共有:SSL:10m;

＃……

}

セッション ID メカニズムの欠点:

1. 負荷分散では、セッション情報が複数のマシン間で同期されないことが多く、クライアントの 2 つのリクエストが同じマシンに存在しない場合、一致する情報が見つかりません。

2.サーバー側に保存されているセッション ID に対応する情報は、有効期限を制御するのが難しく、短すぎると機能しませんし、長すぎると大量のリソースを消費します。サーバー側。

ssl_session_timeout 5分;

2）セッションチケット

セッションチケットは、セッションチケットサーバーによって暗号化されたセッション情報の秘密鍵をサーバーのみが知っており、サーバーができる限り、チケットはクライアントに送信されて保存され、要求時に取得されるため、上記の問題を解決できます。復号化に成功すると、ハンドシェイクはすぐに完了します。この方法では、サーバーはキャッシュする必要がなく、上記の問題は発生しません。

分散システムでは、各サービスノード (nginx ノード) に同じ鍵を使用する必要があり、リスク要因が増大するため、秘密鍵を時々変更する必要があります。

構成：

# Open Session Ticket 。ここでは暗号化アルゴリズムが指定されていません。openssl はデフォルトで乱数キーを生成します。

# 手動で指定する必要がある場合は、次のように設定します。

ssl_session_ticket_key encode_decode.key;

# キーファイルは opensslコマンドで生成できます。例: openssl rand 80> ticket.key

#Nginxクラスタがある場合、セキュリティを確保するため、複数のクラスタアプリケーションが同じキーファイルを使用します。

定期的にキーを変更します。

ssl_session_tickets がオン。

4. HSTS -厳格なトランスポートセキュリティ (https の使用義務)

ユーザーが http を入力し、301/302 の後に https にリダイレクトすると、RTT 時間がさらに 1 回発生します。さらに、実際に https にアクセスする前に、セキュリティ上の危険が隠れています。

HSTS は、クライアント (ブラウザなど) がHTTP の代わりにHTTPSを使用してサーバーとの接続を確立することを強制する新しい Web セキュリティプロトコルです。原理：

HTTPSを介した最初のリクエストでは、サーバーはStrict-Transport-Securityヘッダーで応答し、その後この Web サイトにアクセスするリクエストでは、HTTP がHTTPSに自動的に置き換えられます。(https への最初の訪問は、301/302 ジャンプによる http である可能性もありますが、http は 1 つだけであり、その後は存在しません)。

HSTSヘッダーで設定された有効期限が切れると、それ以降の HTTP アクセスは通常モードに戻り、アクセスできなくなります。

その後、自動的にHTTPS にジャンプします。したがって、ブラウザーが Strict-Transport-Security ヘッダーを受信するたびに、この Web サイトの有効期限が更新されるため、Web サイトはこの情報を更新して有効期限の発生を防ぐことができます。

オープンメソッド:

サーバー {

443 ssl http2 をリッスンします。

サーバー名 xx.com;

#1. max-age : 単位: 秒。 HSTS ヘッダーの有効期限は通常 1 年に設定されます。

つまり 31536000 秒です。そして、応答ヘッダーが HSTS ヘッダーをもたらすたびに、有効期限を更新し続けることができます

時間。

#2. includeSubDomains : HSTS を有効にする必要があるドメイン名 / サブドメイン名。

# 来年 (つまり 31536000秒) の間、ブラウザは xxx またはそのサブドメイン名 ( includeSubDomains ) にHTTPリクエストを送信する限り、 HTTPSを使用して接続を開始する必要があります。たとえば、ユーザーがハイパーリンクをクリックするか、アドレスバーに http://xxx/ を入力すると、ブラウザは自動的にhttpをhttpsに変換し、リクエストを https://xxx/ に直接送信します。

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" 常に;

位置 / {

}

}

無料の WIFI 環境などの公共の場所では、初めて Web サイトにアクセスすると、HSTSエラーがポップアップ表示されます。

web5-HTTP/HTTPS