TLSハンドシェイク
クライアントコンピューターは、TLSバージョン、暗号化アルゴリズムのリスト、および使用可能な圧縮方法を示すClientHelloメッセージをサーバーに送信します。 サーバーは、同じデータとパブリックサーバー証明書を含むServerHelloメッセージで応答します。 証明書には、クライアントがグリーティングの残りを暗号化する公開鍵が含まれています。 クライアントは、証明書が信頼できるCA（認証局）のリストの誰かによって署名されていることを確認します。 チェックに合格すると、クライアントは一連の疑似ランダムバイトを作成し、サーバーの公開キーで暗号化します。 このシーケンスは、対称キーを作成するために使用されます。
サーバーは、秘密鍵でシーケンスを解読し、それに基づいて対称鍵のコピーを作成します。 クライアントは、送信全体のハッシュを対称キーで暗号化したFinishedメッセージを送信します。 サーバーは独自のハッシュを作成し、クライアントからのハッシュを復号化して検証します。 それらが同一の場合、彼は対称メッセージで暗号化されたFinishedメッセージを送信します。
この時点から、TLSセッションは、対称キーで暗号化されたHTTPプロトコルを介してデータを送信します。
HTTPプロトコル
ユーザーがGoogleのブラウザを使用している場合、ページのコンテンツに対するHTTPリクエストの代わりに、HTTPからSPDYにプロトコルをアップグレードするリクエストが送信されます。 クライアントがHTTPプロトコルをサポートしていない場合、次の形式でサーバーにリクエストを送信します。
GET / HTTP/1.1 Host: google.com Connection: close [ ]
残りのヘッダーには、コロンで区切られたキーと値のペアが含まれます。 各ペアは、改行によって他のペアから分離されています。 クライアントがHTTP / 1.1より古いプロトコルを使用している場合、リクエストにはHostヘッダーが含まれず、最初の行のバージョンは異なる-1.0または0.9
HTTP / 1.1プロトコルでは、応答の終了後に接続を閉じる機能が指定されています。 タイトルは次のようになります。
Connection: close
クライアントが永続的な接続をサポートしていない場合、リクエストにそのようなヘッダーを含める必要があります。
リクエストとヘッダーを送信した後、ブラウザはリクエストコンテンツの終わりを知らせる空の行を送信します。 サーバーは、要求のステータスを示すコードで応答し、その後に応答ヘッダーが続きます。
200 OK [ ]
その後に空の行が続きます。その後、 www.google.comページのHTMLコンテンツがクライアントにダンプされます。 サーバーは、クライアントの要求に応じて、接続を閉じるか、開いたままにします。
クライアントからのHTTPリクエストのヘッダーに、ブラウザキャッシュにファイルを保存した後、サーバー上で変更されなかったと判断できる情報が含まれている場合（たとえば、ブラウザーにETagヘッダーが含まれていた場合）、サーバーは次のように応答できます：
304 Not Modified [ ]
応答にファイルの内容を含めないでください。 次に、ブラウザはキャッシュからファイルをロードします。
HTMLを解析した後、サーバーを備えたブラウザは、HTMLからのリンクがある各リソース（画像、スタイルのファイル、スクリプトなど）に対してこの手順を繰り返します。 GET / HTTP / 1.1リクエストの代わりにのみ、GET / $ファイル（ www.google.comからの相対URL）HTTP / 1.1へのパスを示します。
リソースがHTMLでwww.google.com以外のドメインから言及されている場合、ブラウザはドメインアドレスを受信した瞬間から手順を繰り返します。 リクエストのHostヘッダーには、google.comではなく目的のドメイン名が示されます
HTTPサーバー要求ハンドル
HTTPDサーバー（HTTPデーモン）はサーバー側の要求を処理します。 最も一般的なサーバーは、Linuxの場合はApacheまたはnginx、Windowsの場合はIISです。 サーバーはリクエストを受信すると、次のパラメータに従ってリクエストを解析します。
-HTTPリクエストメソッド（GET、POST、HEAD、PUT、またはDELETE）。 私たちの場合、それはGETになります
-ドメイン、この場合はgoogle.com。
-パス/ページ、この場合/（デフォルトのパス）
サーバーは以下をチェックします。
-要求されたドメインに対応する仮想ホストの存在
-このドメインはGETリクエストを受け入れます
-クライアントには、そのようなリクエストを行う権利があります（IP、許可などに制限がある可能性があります）
サーバーにパス変換モジュール（Apacheの場合はmod_rewrite、IISの場合はURL Rewrite）がある場合、指定されたルールのいずれかに要求をマップしようとします。 ルールが見つかった場合、サーバーはそれに応じてリクエストを変換します。
次に、サーバーは要求に対応するファイルを読み取ります。 たとえば、GoogleがPHPを実行している場合、サーバーはPHPを使用してインデックスファイルを解釈し、解釈の結果をクライアントに返します。
ブラウザの舞台裏
ブラウザーがすべてのリソース（HTML、CSS、JS、写真など）を受信すると、ブラウザーはテキストリソース（HTML、CSS、JS）を解析し、ページのレンダリングを開始します。 これを行うために、DOMツリーが構築され、それが処理され、要素の場所が計算され、画面に表示されます。
ブラウザ
ブラウザー機能は、選択したWebリソースをサーバーから要求することにより提供し、ウィンドウに表示することです。 これは通常HTMLドキュメントですが、PDF、画像、またはその他のコンテンツにすることができます。 リソースの場所は、ユニバーサルURIによって指定されます。
ブラウザがHTMLファイルを解釈して表示する方法は、W3C（World Wide Web Consortium）でサポートされているHTMLおよびCSS仕様で定義されています。
通常、すべてのブラウザには次のものがあります。
-URIを挿入するアドレスバー
-前後のボタン
-ブックマークする機能
-更新ボタンと中断ボタン
-ホームボタン
高レベルのブラウザ構造
-ユーザーインターフェイス-ボタン、アドレスバー、メニュー。 これは、ページが表示されるウィンドウの主要部分を除くすべてです。
-ブラウザーエンジン-UIとレンダリングエンジンの相互作用を処理します
-レンダリングエンジン-要求されたコンテンツを視覚的に表示します
-ネットワーク部分-HTTPリクエストなど
-インターフェースバックエンド-ドロップダウンメニュー、ウィンドウ、その他の要素を描画します。 このインターフェイスはプラットフォームに依存せず、その操作は特定のOSのユーザーインターフェイスのメソッドによって提供されます。
-JavaScriptインタープリター-コードの解析と実行
-データストレージ-Cookieおよびローカルストレージ（localStorage、IndexedDB、WebSQL、およびFileSystem）。
HTML解析（パーサー）
レンダリングエンジンは、要求されたドキュメントのコンテンツを、通常は8 KB単位で受け取ります。 パーサーのタスクは、マークアップをツリーに変えることです。 パーサーツリーは、DOM要素とノードのツリー構造です。 DOM、またはドキュメントオブジェクトモデルは、HTMLドキュメントと、JavaScriptなどの他のエンジン用の要素の表現です。 スクリプト処理の前に、DOMにはマークアップとほぼ完全な1対1の対応があります。
パーサーアルゴリズム
HTMLは、上から下、または下から上で動作する従来のパーサーでは解析できません。 マークアップはあまりにもリベラルであり、ブラウザーは特定のマークアップエラーを発生させ、スクリプトの作業により、解析プロセスが既に通過した場所に強制的に戻ることがあります。 この点で、解析プロセスは時々入力データを変更します。 解析アルゴリズムの詳細は、HTML5仕様で説明されています。
解析の終わりに
ブラウザーは外部リソース（CSS、画像、JavaScriptなど）を要求します。 この段階で、ドキュメントはインタラクティブになり、ドキュメントの準備ができたときに実行されるスクリプト（遅延モード）の処理が開始されます。 次に、ドキュメントのステータスが完了に設定され、ロードイベントが発生します。
CSSの解釈
CSSファイル、タグコンテンツが処理されます