I. HTTPSに関するいくつかの握手：
SSL/TLS
TLS/SSLの実装は、ハッシュ関数、対称暗号化、非対称暗号化という3つの基本的なアルゴリズムに依存しています。非対称暗号化を使用して認証とキーネゴシエーションを実現し、対称暗号化アルゴリズムを使用してネゴシエートされたキーを使用してデータを暗号化し、ハッシュ関数に基づいてメッセージの整合性を検証します。
1、クライアントはクライアント側乱数Aをサーバに送信し、サーバ側公開鍵を要求
2.サーバーはクライアントの乱数を受け取り、CA証明書とサーバーの乱数Bとともにクライアントに返します。
注：CA証明書には、サーバー側の公開鍵と電子署名が含まれています。
3、クライアントは、乱数だけでなく、CA証明書のサーバー側を受信し、証明書に関連するドメイン名情報、有効時間およびその他の情報を確認し、サードパーティ組織の公開鍵の復号化を介して公開鍵だけでなく、デジタル署名のサーバー側を取得するには、ハッシュ操作でデジタル署名を介して情報の概要を取得します。平文情報ハッシュ操作のCA証明書を通じて、また、を介して要約を生成します。情報の要約の比較は、情報が改ざんされているかどうかを判断するための情報の完全性を確認します。クライアント側の乱数Cのセットのサーバー側の公開鍵の暗号化の取得を介してこの時点でサーバーに送信されます。
4.サーバはクライアントから暗号化された暗号文を受信。自分の秘密鍵で復号します。次に、送信するデータを暗号化するための秘密鍵を乱数A、乱数B、乱数Cで生成します。
TCPから3回の握手と4回のウェーブ：
3つのハンドシェイク
最初のハンドシェイク
接続の確立。クライアントは、SYNポジションを1、シーケンス番号をxとして接続要求メッセージセグメントを送信し、SYN_SEND状態になり、サーバからの確認応答を待ちます；
2回目のハンドシェイク：
サーバはSYNメッセージセグメントを受信します。サーバはクライアントのSYNメッセージセグメントを受信すると、このSYNメッセージセグメントを確認する必要があり、Acknowledgment Numberをx+1(Sequence Number+1)に設定します。同時に、サーバ自身もSYNリクエスト情報を送信する必要があり、SYN位置を1、Sequence Numberをyに設定します。サーバ側は上記の情報を1つのメッセージセグメントにまとめてクライアントに送信します。サーバは上記の情報を1つのメッセージセグメントにまとめてクライアントに送信します；
3回目のハンドシェイク：
クライアントはサーバからSYN+ACKメッセージセグメントを受信します。このセグメントが送信されると、クライアントとサーバはともにESTABLISHED状態になり、TCPハンドシェイクを3回行います。3回のハンドシェイクが完了すると、クライアントとサーバはデータの送信を開始できます。以上が、TCPの3回のハンドシェイクの一般的な紹介です。
4つの波
最初の分割
ホスト1はシーケンス番号と確認応答番号を設定し、ホスト2にFINメッセージセグメントを送信します。この時、ホスト1はFIN_WAIT_1状態になります；
2回目の分割
ホスト2はホスト1からFINセグメントを受信し、シーケンス番号に1を加えた応答番号でACKセグメントをホスト1に送り返します。ホスト2はホスト1に、あなたのシャットダウン要求に「同意します」と伝えます；
第3の分解
ホスト2はホスト1にFINメッセージセグメントを送り、ホスト2がLAST_ACK状態になる間にコネクションを閉じるように要求します；
第4の分解
ホスト1はホスト2から送信されたFINメッセージセグメントを受信し、ACKメッセージセグメントをホスト2に送信し、ホスト1はTIME_WAIT状態に入ります。ホスト2はホスト1からACKメッセージセグメントを受信した後、コネクションを閉じます。この時、ホスト1は2MSL待っても返信がない場合、サーバー側が正常に閉じたことを証明するので、ホスト1もコネクションを閉じることができます！
WebSocket
ブラウザキャッシュ
キャッシュメカニズム
1、ブラウザがリクエストを送信する前に、リクエストヘッダによると、有効期限が切れるとキャッシュ制御強いキャッシュポリシーをヒットするかどうかを決定するために、ヒットした場合、直接キャッシュからリソースを取得し、リクエストを送信しません。それはヒットしない場合は、次のステップに進みます。
2、ないヒット強力なキャッシングルールは、ブラウザがリクエストを送信する、last - modifiedとetagのリクエストヘッダによると、ネゴシエーションキャッシュをヒットするかどうかを決定するために、ヒットした場合、直接キャッシュからリソースを取得します。ヒットしない場合は、次のステップに進みます。
3.最初の2つのステップがヒットしなかった場合、リソースはサーバーから直接取得されます。
強力なキャッシュ
強力なキャッシュ：リクエストをサーバーに送らず、リソースをキャッシュから直接読み込む。
HTTP / 1.1 Cache-Control，相対時間
HTTP/1.1 では、Cache-Control は最も重要なルールで、主にウェブページのキャッシュを制御するために使用されます：
public: すべてのコンテンツがキャッシュされます。
private: すべてのコンテンツはクライアントによってのみキャッシュされます。
no-cache: クライアントはコンテンツをキャッシュしますが、キャッシュを使うかどうかは、キャッシュをネゴシエートして確認する必要があります。
no-store：すべてのコンテンツがキャッシュされない、つまり強制キャッシュもネゴシエーションによるキャッシュも使われません。
max-age=xxx : キャッシュされたコンテンツはxxx秒後に失効します。
no-cacheという名前は少し誤解を招きやすいので注意してください。no-cacheを設定した後、ブラウザがデータをキャッシュしなくなるということではなく、ブラウザがキャッシュされたデータを使用するときに、データがサーバと整合性がとれているかどうかを確認する必要がある、つまりネゴシエーションによるキャッシュが必要であるということを意味します。そして、no-store はキャッシュされない、つまり、強制キャッシュやネゴシエーションによるキャッシュを使わないことを意味します。
HTTP / 1.0 期限付き、絶対時間。現地時間による制限
リソースがいつ期限切れになるかを指定するために使用されるキャッシュの有効期限は、サーバー側固有のものです。言い換えると、Expires = max-age + リクエスト時間であり、Last-modified と組み合わせて使用する必要があります。 Expires はウェブサーバのレスポンスメッセージヘッダフィールドで、http リクエストに応答してブラウザに、ブラウザのキャッシュから直接データにアクセスでき、有効期限までに再度リクエストする必要がないことを伝えます。
Expires は HTTP/1.0 の産物で、ローカル時間によって制限されます。
キャッシュの交渉
ETagイフ・ノーンマッチ
Etag：ウェブサーバがリクエストに応答するとき、現在のリソースがサーバ上で一意に識別されることをブラウザに伝えます。Apacheでは、ETagの値はデフォルトでは、ファイルのインデックスセクション、サイズ、取得したハッシュの最終更新時刻です。
If-None-Match：リソースの有効期限が切れ、リソースにEtage文があることが判明した場合、If-None-Matchヘッダを付けて再度ウェブサーバーにリクエストします。ウェブサーバーがリクエストを受信し、If-None-Matchヘッダがあることを発見すると、リクエストされたリソースの対応するチェックサム文字列と比較し、200または304を返すかどうかを決定します。
Last-Modified，If-Modified-Since
Last-Modified：このレスポンスリソースの最終更新時刻を示します。ウェブサーバーはリクエストに応答する際、ブラウザにリソースの最終更新時刻を伝えます。
If-Modified-Since：リソースの有効期限が切れ、リソースにLast-Modified文があることがわかった場合、リクエスト時間を示すIf-Modified-Sinceヘッダを付けて再度ウェブサーバーにリクエストします。ウェブサーバーはリクエストを受信し、If-Modified-Sinceヘッダがあることを見つけると、リクエストされたリソースの最終更新時間と比較します。ウェブサーバがリクエストを受け取り、ヘッダ If-Modified-Since を見つけると、リクエストされたリソースの最終更新時刻と比較します。最終更新時刻が新しい場合は、リソースが再び変更されたことを意味し、リソースのコンテンツ全体に対して HTTP 200 を応答します。最終更新時刻が古い場合は、リソースに新しい変更がないことを意味し、ブラウザに保存されたキャッシュを使い続けるように HTTP 304 を応答します。
HTTP1.1でEtagが登場したのは、主にいくつかのLast-Modifiedの問題を解決するためです：
1.Last-Modifiedは、2番目のレベルまでしか正確に最後の更新をマークすることができません。1秒以内に何度も更新されたファイルがある場合、ファイルの更新時間を正確にマークすることはできません。
2.いくつかのファイルが定期的に生成される場合、時にはコンテンツが変更されていないが、Last-Modifiedが変更され、その結果、ファイルがキャッシュを使用することはできません。
3.サーバーがファイルの更新時刻を正確に取得しない、またはプロキシサーバーと時刻が一致しない場合があります。
http3
http1.0
シリアル接続：HTTPはコネクションレスの特性を持って、つまり、各接続は、TCP接続が切断されるべきである後に各HTTP通信のHTTP/1.0バージョンを切断する応答を受信した直後に、1つの要求を処理することができますので、各新しいHTTPリクエストは、新しい接続を確立する必要があります。しかし、HTTPリクエストの数十の場合、それはブラウザの要求の上限に達することは容易であり、各要求は、新しいTCP接続を確立するために大幅に通信オーバーヘッドを増加させます。
http1.1
永続的な接続：この問題を解決するために、永続的な接続が提案されています。HTTP/1.1の実装とデフォルトのすべての接続は、クライアントがネットワークリソースと通信時間の無駄によって引き起こされるTCPハンドシェイクを減らすために複数のHTTPリクエストを開始するように、持続的な接続です。しかし、永続的な接続はブロッキングモードを使用し、次のリクエストは、要求が応答内容を返していない場合、次のリクエストは待たなければならない、開始するために応答が返されるまで待機する必要があります。
HTTP/1.1
1.高い待ち時間 - ページ読み込み速度の低下をもたらす ネットワークの待ち時間の問題は、主にキューヘッダーのブロックによるもので、その結果、帯域幅を十分に利用することができません。
キューヘッダブロッキングとは、一連のリクエストの中の一つのリクエストが 何らかの理由でブロックされたときに、その後ろのキューにあるすべての リクエストもブロックされることを意味します。ヘッダブロッキングに関しては、以下の解決策が試みられています。
Chromeには、デフォルトで同一ドメインに6つのTCP持続的接続を許可する仕組みがあります。持続的接続を使用する場合、一般的なTCPパイプラインを使用できますが、同時に処理できるのはパイプライン内の1つのリクエストのみで、現在のリクエストが終了していない場合、他のリクエストはブロック状態にしかなりません。さらに、同じドメインで同時に10個のリクエストがあった場合、進行中の リクエストが完了するまで、そのうちの4個はキューイング状態になります。
複数の小さな絵を1つの大きな絵に統合し、JavaScriptやCSSを使って小さな絵の技術を「切り取り」直すのがスプライトです。
インライン化とは、CSSファイル内のURLにイメージの生データを埋め込むことで、小さなイメージリクエストを何度も送信することを防ぎ、ネットワークリクエストの回数を減らすもう1つのテクニックです。
スプライスは、Webpackや他のツールを使用して、より大きなJavaScriptファイルにパッケージ化された小さなJavaScriptの数になりますが、ファイルのいずれかが変更された場合、複数のファイルを再ダウンロードするために大量のデータにつながるでしょう。
2.ステートレス機能 - それに付随する膨大なHTTPヘッダー
3.平文伝送 - それに伴う安全性の欠如
4.サーバプッシュメッセージをサポートしていません
HTTP/1.1主な欠点は2つある：セキュリティの欠如とパフォーマンスの低さだ。
http2.0
HTTP/2.0多重化: 各HTTPリクエストにはシーケンス識別子があり、ブラウザは複数のリクエストを同時に処理でき、サーバーはデータを受信し、シーケンス識別子に従って別のリクエストメッセージに並び替え、間違ったデータにつながることはありません。同様に、サーバーは同時にブラウザに複数の応答を返すことができ、ブラウザは、それぞれの要求に並び替えと応答メッセージに応じてシリアル識別子を受信します。そして、同じドメイン名のすべてのリクエストは同じ TCP コネクションで多重化されます。
HTTP/2 にはフレームとストリームという2つの非常に重要な概念があります。 これらの概念を理解することは、多重化を理解するための前提条件です。フレームはデータ伝送の最小単位を表し、各フレームはどのストリームに属するかを識別するシーケンスを持ち、ストリームは複数のフレームで構成されるデータの流れで、各ストリームはリクエストを表します。現在のウェブサイトの HTTP リクエストバージョンを簡単に表示できる chrome 拡張機能を紹介します。
新しいバイナリ形式: HTTP/1.x の解析はテキストベースです。テキストベースのプロトコル解析には当然の欠点があります。テキストの表現には多様性があり、包括性を達成するために考慮すべきシナリオは必然的に多くなります。一方バイナリは異なり、0 と 1 の組み合わせのみを認識します。この点を考慮し、HTTP/2.0 は便利で強力なバイナリ形式でプロトコルを解析します。
**HTTP/1.1の持続的接続からのアップグレードです。多重化とは、TCP 接続に複数のストリームが存在できることを意味します。つまり、複数のリクエストを送信することができ、サーバーはフレーム内の識別によってフレームがどのストリームに属するかを知ることができ、リクエストを並べ替えることで復元することができます。多重化により、複数のリクエストを同時に開始することができ、各リクエストとそのリクエストに対するレスポンスは、他のリクエストやレスポンスを待つことがないため、ヘッドオブラインブロッキングの問題を回避することができます。このようにして、特定のリクエストの時間のかかるタスクが、他のコネクションの正常な実行に影響を与えることがなくなり、伝送性能が大幅に向上します。
ヘッダの圧縮： HTTP/1.xのリクエストとレスポンスヘッダの多くの情報を、各リクエストを送信するために繰り返され、HTTP/2.0使用エンコーダは、ヘッダフィールドのテーブルの両側の間の通信は、各ヘッダのコピーをキャッシュするだけでなく、ヘッダの重複送信を避けるために、送信する必要があるサイズを減らすために送信する必要があります。
サーバーサイド・プッシュ： ここでは、サーバーサイド・プッシュとは、クライアントに送信されるindex.htmlと一緒に、クライアントが必要とするcss/js/imgリソースを指し、クライアントがリクエストステップを繰り返す必要がなくなります。
HTTP/2.0
1、TCPおよびTCP + TLSは、伝送のためのTCPプロトコルを使用して遅延HTTP / 2への接続を確立するために、HTTPSを使用する場合は、また、安全な伝送のためのTLSプロトコルを使用する必要があり、TLSの使用はまた、2つのハンドシェイクプロセスの遅延を必要とするハンドシェイクプロセスを必要とします：
TCP接続を確立する際、接続の成功を確認するためにサーバーと3回のハンドシェイクを行う必要があります。
TLSにはTLS1.2とTLS1.3という2つのバージョンがあり、それぞれ接続にかかる時間が異なります。
つまり、データ転送には3～4RTTかかります。
2、TCPのキューヘッドブロッキングは完全には解決されていません。
HTTP/2では、複数のリクエストが単一のTCPパイプで実行されます。しかし、パケットロスが発生した場合、HTTP/2のパフォーマンスはHTTP/1ほど良くありません。TCPは、信頼性の高い伝送を確保するために、特別な "失われたパケットの再送 "メカニズムがあるため、失われたパケットは、再送信の確認を待つ必要がありますHTTP / 2のパケットロスは、全体のTCPは、再送信の待機を開始するには、TCP接続内のすべての要求をブロックします。HTTP/1.1の場合は、複数のTCP接続を開くことができます、この状況は、接続の1つにのみ影響を与える、残りのTCP接続はまだ正常にデータを送信することができます。
HTTP/2HTTP/1との完全な互換性は、"より安全なHTTP、より高速なHTTPS "であり、ヘッダ圧縮、多重化および他の技術は、このように大幅にインターネット体験を改善し、遅延を低減し、帯域幅をフルに活用することができる；
http3.0
GoogleはSPDYを推進する際にすでにこれらの問題に気づいており、UDPプロトコルをベースにした "QUIC "と呼ばれる新しいプロトコルを作成し、TCPの代わりにQUIC上でHTTPを実行できるようにしました。この "HTTP over QUIC "はHTTPプロトコルの次の大きなバージョンであるHTTP/3で、HTTP/2をベースに質的な飛躍を遂げ、"キューヘッダブロッキング "問題を本当に "完璧に "解決しています。「キューヘッダーのブロッキング」問題
パケットブロッキングの回避：複数のストリームのパケットをTCPコネクション上で伝送する場合、あるストリームのパケット伝送に問題が発生すると、TCPは他のストリームのパケット伝送を継続する前に、そのパケットの再送を待つ必要があります。しかし、UDPベースのQUICプロトコルでは、異なるストリーム間のデータ伝送は真に独立しており、互いに干渉することはありません。
クイック・リスタート・セッション： 通常のtcpベースの接続は、両端のipとポート、プロトコルに基づいて作成されます。ネットワーク切り替えのシナリオでは、例えば、携帯電話側が無線ネットワークを切り替えて4Gネットワークを使用する場合、自身のipが変更され、その結果、tcp接続を再作成する必要があります。QUICプロトコルはユニークなUUIDを使用して各接続をマークするため、ネットワーク環境が変わってもUUIDが変わらない限り、ハンドシェイクなしでデータを送信し続けることができます。
DNS
DNSは、最初は、ipに起因する長いと覚えるのは難しい、ipアクセスサイトを通じて便利ではありません。だから後でDNSサーバの発明を通じて、この時間は、サイトを訪問するサイトのドメイン名を入力して、DNSサーバは、IPのドメイン名を解決するので、実際のアクセスは、対応するIPアドレスです。
ブラウザキャッシュ - システムキャッシュ - ルーターキャッシュ - ISP DNSキャッシュ - 再帰検索
DNS解決は再帰的なクエリプロセス▽▽。
V. 入力URLからページ読み込みまでの流れ
1、DNSの解像度
2、TCP接続
3、HTTPリクエストを送信
4.サーバーはリクエストを処理し、HTTPメッセージを返します。
5, ブラウザはレンダリングされたページを解析します。
6.接続終了
ブラウザはレンダリングされたページを解析する
ブラウザは解析とレンダリングを同時に行います。まずブラウザはHTMLファイルを解析してDOMツリーを構築し、次にCSSファイルを解析してレンダー ツリーを構築し、レンダー ツリーが完成すると、ブラウザはツリーをレイアウトして画面に描画し始めます。このプロセスはより複雑で、リフロー（reflow）とリペイン（repain）という2つの概念が関わっています。 要素のDOMノードはボックスモデルの形をしていますが、これらはブラウザが位置やサイズなどを計算する必要があり、リロー（relow）として知られているプロセスです。ボックスモデルの位置、ボックスモデルのサイズだけでなく、色、フォントなどの他の属性がダウンして決定すると、ブラウザは次のようになります。ボックスモデルの位置、サイズ、および色、フォントなどの他のプロパティが決定されると、ブラウザは、コンテンツの描画を開始します、このプロセスは、レインと呼ばれています。ページが初めてロードされたときに、必然的にリフローとレインを通過します。リフローとレインは非常にパフォーマンスを消費するプロセスであり、特にモバイルデバイス上で、それはユーザーエクスペリエンスを破壊し、時にはページが遅延する原因となります。そのため、リフローとリペインをできる限り最小限に抑える必要があります。
