WebブラウザがWebページを表示するまで

この2つの記事を読めば分かることなのですが、自分なりにまとめておこうと思います。

URLの解析

アドレスバーにhttps://komura-c.hatenablog.com/が入力されてenterキー(スマホなら開くとか)が押された時、 WebブラウザはURL(Uniform Resource Locators)を次の3つの要素に解析(パース)します。

スキーム
- スキームはHTMLファイルなどのリソースを取得するための方法を表します。ここではhttpsであり暗号化されたhttp通信を表します。
ホスト名
- リソースが存在するホスト(コンピュータ)名を表します。ホスト名は、2つの要素に分けられます。1つはローカル名であり、ここではkomura-cです。2つ目はドメイン名であり、ここではkomura-c.hatenablog.comです。
パス名
- ホスト名で指定されたコンピュータ上のリソースの位置やファイル名を示します。ここでは/です。ブラウザに省略されることがあります。

DNSによる名前解決

URL解析の後、WebブラウザはそのURLのIPアドレスを探します。URLは人間が覚えやすいようにIPアドレスの数字を文字列として置き換えたものであり、実際にはIPアドレスを指定してデータを送受信しています。

DNS(Domain Name System)は、ドメイン名に対応するIPアドレスが自動的にわかる仕組みです。DNSの仕組みは、情報が欲しいクライアント、情報を探すフルリゾルバー、情報を持っている権威DNSサーバーに分けられます。次の手順でIPアドレスを探します。

ルートサーバーにkomura-c.hatenablog.comのIPアドレスを聞くと、ドメイン名右端のTopLevelDomein、ここでは.comのネームサーバーを案内されます。
.comのネームサーバーにkomura-c.hatenablog.comのIPアドレスを聞くと、.hatenablog.comのネームサーバを案内されます。
.hatenablog.comのネームサーバにkomura-c.hatenablog.comのIPアドレスを聞くと、IPアドレスである、35.77.187.130が返ってきます。(ここでは、はてな側で〇〇.hatenablog.comを割り当てるため、IPアドレスを直で入力してもアクセスできません)

この流れをDNSの名前解決といいます。フルリゾルバーは、初回の名前解決の後、ドメイン情報を一定期間保持しておき、次回以降の名前解決で再利用するキャッシュをもつため、実際にはWebブラウザは初めにキャッシュがないか探します。また、このように階層的にネームサーバーを持ち分散管理することでたくさんのIPアドレスの情報持つことができています。

プロトコルに応じたソケット通信

DNSによる名前解決の後、スキーマに応じたプロトコルで通信を行います。適切なポート(HTTPは80, HTTPSは443)を用いて送信元IPアドレス(送信ポート)と宛先IPアドレス(宛先ポート)を接続するためのソケットを開いて通信を行います。ここでは、HTTPSのため、SSLにより暗号化されたHTTP通信が行われます。

HTTP通信

HTTP(Hypertext Transfer Protocol)は、WebサーバーとクライアントのWebブラウザがデータを送受信するために使用するアプリケーション層のプロトコルです。Webページを記述するために使用するHTMLによる文書、画像、音声、動画等のファイルを表現形式を含めてやりとりできます。ステートレスなプロトコルであり、サーバーはリクエスト間で何もデータを保持しません。また、HTTPはTCP プロトコル上で動作しています。

主な流れとしては、クライアントはサーバーにリクエストを送信するためにポートを開き、サーバー側からのレスポンスが返ってくるまで待機します。つまり、Webブラウザが送り出したHTTPリクエストというTCPパケットを使ったメッセージに対して、WebサーバーがHTTPレスポンスを返します。

TCP/IP

TCP(Transmission Control Protocol)は、IP(Internet Protocol)を基盤にその上層で利用されるプロトコルです。IPネットワーク上の2地点間で信頼性の高い通信を可能にするコネクション型プロトコル（通信相手の応答があってはじめて通信を開始する）であることから、データ転送を行う前にコネクションの確立を行います。その流れを3ウェイハンドシェイクといい、次の手順を踏みます。

クライアントがサーバにコネクション確立の要求
- SYNパケットを送ります。
サーバはクライアントのコネクション要求に応答、そしてサーバからもコネクション確立を要求
- サーバが接続を受け入れる場合は、クライアントにSYNフラグとACKフラグの両方が1にセットされたSYN/ACKパケットを応答します。
クライアントもサーバからのコネクション要求に応答
- ACKフラグを立てたACKパケットを送ることで接続を確立します。

TLS/SSLによる暗号化通信

SSL(Secure Socket Layer)は、インターネット上でデータを暗号化して送受信する方法のひとつです。

HTTPSを有効にしたいウェブサイトは、CA(Certificate Authority)からTLS/SSL証明書を取得する必要があります。SSL証明書は次の3つのレベルがあります。

ドメイン認証（DV）ドメインの使用権があるかどうか。
企業実在認証・組織認証（OV）登記簿などを確認し、組織として法的に実在しているかどうか。
EV認証（EV）上記2つの認証の項目に加え、物理的に組織が存在しているか、事業が存在・運営されているか、承認者・署名者は誰なのか。

TLS(Transport Layer Security)は、SSLをもとに標準化させたものをいいます。 TLS暗号化通信には、対になる2つの共通鍵暗号方式と公開鍵暗号方式という仕組みを用います。

一般的な公開鍵暗号の一つはRSA暗号で、512bit、1024bit、2048bit、3072bitの鍵長をもちます。一般的な共通鍵暗号の一つは、AES暗号で、128bit、192bit、256bitの鍵長をもちます。鍵長が長ければ長いほど、暗号文は解読しにくくなり安全です。しかし計算手順は増えるため暗号化とその復号に時間がかかります。現在では基本的に鍵長2048bit以上のRSA鍵を使用が推奨されています。

通信手順は次のとおりです。

接続要求
- クライアント側からSSL通信のリクエストをサーバ側へ送信します。
SSL サーバ証明書と公開鍵をクライアント側へ送付
- サーバ側から、公開鍵付きのSSL サーバ証明書をクライアント側に送付します。
- クライアント側のブラウザに搭載されているルート証明書で署名を確認し、SSL サーバ証明書を検証します。
- 共通鍵(セッションキー)を生成します。
共通鍵を暗号化しサーバ側へ送付
- クライアント側で生成された暗号用の共通鍵を、サーバ側から送られてきた公開鍵を用いて暗号化し、サーバ側へ送信されます。
- サーバ側に送信された共通鍵は、サーバ側で保持している秘密鍵で復号され、共通鍵が取り出されます。
TLS/SSL暗号化通信開始
- 個人情報などの機密性の高いデータを、クライアント側で保持している共通鍵で暗号化し、サーバ側へ送信します。
- サーバ側は、受け取った暗号データをサーバ側で保持している共通鍵で復号してデータを取得します。
- 共通鍵は、サーバとクライアントが使用するブラウザの双方が対応する、最も強度の高い暗号方式・鍵長が使用されます。

ブラウザのレンダリング

プロトコルに応じたソケット通信の完了、ここではHTTPS通信のレスポンスによって、サーバーからindex.htmlを取得した後ブラウザはレンダリングを開始します。

ブラウザのレンダリングは主に次の手順で行われます。

Loading

HTML中のタグでCSS、JavaScriptファイルなどの外部リソースを取得します。

Scripting

JavaScriptを字句解析、構文解析し、実行します。

Rendering

HTML Parsing
- HTMLファイルを字句解析、構文解析します。
- HTMLファイルをJavaScriptで操作できるデータ構造であるDOMの、tree(抽象構文木)に変換します。
CSS(Style) Parsing
- CSSのスタイルを適用します。
- DOM treeをスタイル情報(ComputedStyle)付きDOM treeに変換します。
Layout
- HTMLとStyleを基に場所とサイズを計算して、各要素の位置座標を確定します。
- スタイル情報(ComputedStyle)付きDOM treeをLayout treeに変換します。
Layering
- 独立に描画可能な範囲をレイヤーに分割します。(iframeなど)
- Layout treeをLayerに変換します。

Painting

どの順番で描画するかを決め、描画します

DOMというデータ構造を渡すことで、JavaScriptなどによる動的レンダリングの高速化、Partial invalidation(部分実行)ができる仕組みになっています。

komura-c.log

https://blog.komura-c.page/ に移動しました