I. 何が起こったかをレンダリングするページのURLを入力します。

• まず第一に、URLが解決され、DNSシステムのIPルックアップによると、IPによると、サーバーを見つけることができ、その後、ブラウザとサーバーが接続を確立するためにTCP 3ハンドシェイクされ、これはhttpsである場合だけでなく、TLS接続を確立するだけでなく、暗号化アルゴリズムのネゴシエーションは、ここで別の注意が必要になります "httpsとhttpの違い "の問題。
• ブラウザがファイルの要求を送信し始めた後に確立された接続は、キャッシュは、接続の確立は、キャッシュまたは直接再取得に移動することですここで状況があるでしょう、あなたは、バックグラウンドの設定を見てする必要がありますので、ここでは "ブラウザのキャッシュ機構"、キャッシュなどの話の懸念があるだろう、今キャッシュがない場合は、ファイルを取得するために直接移動します！
• まず、htmlファイルを取得し、DOMツリーを構築し、このプロセスは、すべてのhtmlファイルがダウンロードされるのを待たずに、パースしながらダウンロードすることであり、その後、時間の無駄である、htmlを解析しに行くが、少しをダウンロードするために少しをパースし
• cssファイルで見つかったhtmlヘッダを解析し、この時間は、cssファイルをダウンロードするには、cssファイルも解析中にダウンロードされ、CSSOMツリーの構築は、DOMツリーとCSSOMツリーが構築されると、ブラウザは、レンダリングツリーにDOMツリーとCSSOMツリーを構築します。
• スタイルの計算は、上記の最後の文は、"DOMツリーとCSSOMツリーは、レンダリングツリーに一緒に構築される "少し一般的な、実際には、もう少し詳細な操作がありますが、上記の一般的な答えは十分なはずです、今、他のことが行われたときにレンダリングツリーの構築と言うために上記をピックアップします。最初はスタイルの計算、DOMツリーとCSSOMツリーの後、ブラウザは、主にDOMツリーのノードに対応するスタイルを見つけるために、スタイルの計算を開始します。
• レイアウトツリーの構築 スタイルが計算されたら、レイアウトツリーの構築を開始します。主な目的は、DOMツリーのノードのページ上の対応する位置を見つけることと、いくつかの「display:none」要素を非表示にすることです。
• ビルド階層ツリーは、レイアウトツリーが完了した後、ブラウザはまた、主にスクロールバー、zインデックス、これらの複雑な階層操作の位置を満たすために、階層ツリーを構築する必要があります。
• 階層ツリーをブロック化し、ラスターを使ってビューウィンドウの下に対応するビットマップを見つけます。主に、ページが数画面に及ぶことがあり、一度にレンダリングするのはもったいないので、ブラウザはビューウィンドウで対応するブロックを見つけ、その部分をレンダリングします。
• 最終的なレンダリングプロセスでは、ページ全体がレンダリングされますが、レンダリングの過程では、再配置や再描画も表示されます。"再配置や再描画はなぜレンダリングに影響を与えるのか、どのように回避するのか？" という質問にも似ています。

握手

• クライアントはサーバーに接続を要求するパケットを送信します。
• サーバーは、クライアントからのパケットの受信を示す確認応答パケットを返します。
• クライアントはまた、サーバからのパケットを受信し、接続が確立されたことを示す確認パケットを返します。

4つの波。

• クライアントは切断を要求するパケットをサーバーに送信し、データの送信を停止して、tcp接続をアクティブに閉じます。
• サーバーは確認応答パケットを返し、シャットダウン待機状態に入ります。
• サーバーも切断したい場合は、切断FINパケットを送信します。
• クライアントはそれを受信すると、サーバーに確認応答パケットを送信し、サーバーがそれを受信するのを待って切断します。

Q：なぜ3回も握手するのですか？

これは、両当事者が送受信能力を確認することで確認できます：

1. クライアントがサーバから確認パケットを送受信すると、クライアントは送受信が可能であることを認識します。
2. クライアントが別の確認パケットを返した後、サーバーも送受信能力が正常であることを認識します。

もし2回なら、つまり、C--S S--C サービスセグメントは、送信した確認応答パケットを相手が受け取ったかどうかを知ることができないので、少なくとも3回のハンドシェイクが許可されます。

Cはパケットを送信しますが、この時点でネットワークの問題によりSはそれを受信しません。タイムアウトに達した後、CはSからの確認パケットを受信していないことに気づき、別のパケットを送信します。

しばらくして、この時点で失われたパケットがSに送信され、Sはそれに応じて確認応答を返しましたが、Cが失われたと思ったパケットは無視されたので、Cはそれを無視しただけで、サーバーはこの時点でもまだバカバカ待っていました。

Q：なぜ4回も手を振ったのですか？

サービス・セグメントは、コネクションが確立したときにackとfinを一緒に送信しますが、サービス側はコネクションが切断されたときに受信する能力を維持します。

プロセス全体を思い起こすと、Cはまず切断を要求し、データの送信を停止しますが、Sはこの時点でまだ手元に処理すべきことがあるかもしれず、切断できるまでに時間がかかるため、確認メッセージを送信することしかできず、4回行う必要があります

XSS & CSRF

XSS: csrf: