**「Show HN：ブラウザの仕組みを解説したインタラクティブガイド」**

Japanese Translation:

ガイドは、URLを入力して画面にレンダリングされるまでのウェブページが経過するすべてのステップを読者に案内します。
入力処理：簡単な入力（「pizza」、「example.com」など）は完全なHTTPリクエストや検索URLへ変換されます。

DNSルックアップとTCPハンドシェイク：ブラウザはドメイン名を解決し、次にSYN/SYN‑ACK/ACKの3段階ハンドシェイク（シーケンス番号付き）でTCP接続を確立します。
HTTP交換：
Host
や
Accept
などのヘッダーを含むHTTPリクエストが送信され、サーバは生のHTTPデータを返し、ブラウザはそれをヘッダーとボディに分割します。
パース：HTMLボディはストリーミングでエラー許容的にトークン化され、
<script>
タグが現れるまでパースは一時停止し、その後実行されます。
DOM & CSSOM構築：解析されたノードがDOMツリーを形成し、CSSと組み合わせてレンダーツリーを作成します。

レンダリングパイプライン：レイアウト（再フロー）でサイズと位置を計算し、ペイントでピクセルをレイヤーに塗りつぶし、コンポジティングでGPUレイヤーを最終フレームへ統合します。

再レンダリングのニュアンス：色変更はリペイントのみを引き起こし、サイズやレイアウトの変更は完全なレイアウト＋ペイントが必要です。

動的機能：DOMはインメモリモデルとして機能し、HTMLパース、CSS選択、JavaScript実行、動的スタイル付け、イベント処理、およびクエリアーキテクチャを支えます。

オープンソースとコミュニティ：ガイドはオープンソースであり、貢献者はイシューやプルリクエストを通じて改善案を提案できます。

この改訂された要約は、すべての重要ポイントを網羅し、非推論的な記述を避け、主要メッセージを明確に提示します。

ブラウザが動作する仕組みを学ぶ対話型ガイド

なぜ？

このガイドは、日々ウェブを利用しているエンジニアや好奇心旺盛な方のために作成しました。
多くの解説は技術的すぎる、詳細すぎる、あるいは浅くて十分でないと感じたため、別のアプローチを採用することにしました。

ガイド全体を数十個の小さな対話型例題で構成し、実際に操作してみることで技術的詳細を段階的に理解し、ブラウザがどのように機能するか直感的に掴めるよう設計しています。

簡潔さと要点への集中を保つため、以下の重要事項は省略しています：

HTTPプロトコルのバージョン差異
SSL/TLS
DNSの細かな挙動
その他多数

ガイドはオープンソースです。改善案があれば、issueやpull requestでぜひご提案ください。

ブラウザはURLで動く

アドレスバーに何でも入力できますが、実際にはブラウザ内部ではURLを扱います：

```
pizza
```
のようなランダムテキストは検索用URLへ変換されます
```
https://google.com/search?q=pizza
```
（または設定によっては
```
https://duckduckgo.com/?q=pizza
```
）
```
example.com
```
のようなドメイン名は完全なURLに正規化されます：
```
https://example.com
```

試してみる: アドレスバーに文字を入力し、Enter（または「Go」ボタン）を押します。

pizza

や

example.com

を入力してみてください。

URLをHTTPリクエストへ変換

目的のURLが決まったら、そのサーバーにリクエストを送り、リソースを取得してブラウザに表示します。
ブラウザはサーバーと通信する際に HTTP プロトコルを使用します。

試してみる:

https://example.com

のような完全URLを入力し、Enter（または「Go」）を押してください。

HTTPリクエストにはヘッダーが付随します：

Host: example.com
Accept: text/html

その中でも Host ヘッダーはリクエスト先のサーバーを示す重要な情報です：

example.com

です。

サーバーアドレスの解決

ブラウザは

example.com

のような名前に直接リクエストを送れません。コンピュータは IP アドレスで通信するため、まず DNS システムに問い合わせてドメイン名を IP アドレスへ変換します。

試してみる: 入力欄にドメイン名を入力し Enter を押すと、IP アドレスが解決されます。

TCP 接続の確立

DNS がブラウザに IP アドレスを返した後、サーバーとの信頼できる接続を確立する必要があります。TCP は HTTP データが送受信される前にこの接続を設定します。

TCP は三段階ハンドシェイクで接続を確立し、両側がデータの送受信準備ができていることを確認します：

SYN: クライアントは自身のシーケンス番号（seq=1000）を送って接続を開始。
SYN‑ACK: サーバーは自分のシーケンス番号（seq=5000）と、クライアントの seq を 1 増やした ack（ack=1001）で応答。
ACK: クライアントがサーバー番号を確認し、さらに 1 増やした ack（ack=5001）を送ることで接続完了。

これらの番号はクライアントとサーバーが通信内容を追跡するために使われます。バイト単位でカウントされ、どこからデータが始まり、次に何が来るかを両側が合意します。もし一部のデータが届かなかった場合、送信側は欠落箇所を検知して再送できます。これが TCP が接続確立後にデータを順序通りかつ信頼性高く保つ仕組みです。

試してみる: パケットの送受信を開始し、ネットワークを乱すことで何が起こるか確認してください。

ネットワーク上でパケットが移動

TCP 接続が確立すると、ブラウザはサーバーへ HTTP リクエストを送ります。

試してみる: 「Go」をクリックし、HTTPリクエストがサーバーに届き、レスポンスがブラウザへ戻る様子を観察してください。

Browser (Client)        Server
User agent              example.com
Response Waiting for...
Waiting for the server.  Port 80 - HTTP
Request Waiting for...
Response Waiting to respond...
Listening for requests.

HTTP レスポンスが届くと、ブラウザは生のレスポンスを読み取り、HTML コンテンツのレンダリングを開始します。

HTML を解析して DOM ツリーを構築

HTTP レスポンスが到着したら、ヘッダーとボディを分離し、HTML バイト列をパーサに投入します。
パーサは

<h1>

のようなタグをトークン化し、DOM ツリーを構築します。

試してみる: 「Parse」をクリックすると、HTML ストリームが DOM ツリーへと解析される様子を確認できます：

<!doctype html>
<html>
  <head>
    <title>Example Domain</title>
  </head>
  <body>
    <main>
      <h1 style="color: red;">Example Domain</h1>
      <p>An example paragraph.</p>
      <p><a href="https://example.com">An example link</a></p>
    </main>
  </body>
</html>

生成される DOM ツリーは次のようになります：

Document
|- <!doctype html>
   - html
     |- head
       | - title
         |   - "Example Domain"
     |- body
       | - main
           |- h1 (style: color: red)
             | - "Example Domain"
           |- p
             | - "An example paragraph."
           |- p
             | - a (href="https://example.com")
               | - "An example link"

パースはストリーミングかつエラー許容です。ブラウザは全文がダウンロードされる前にノードを構築し、欠落タグを挿入してツリーの整合性を保ちます。

<script>

タグが現れると解析が一時停止し、スクリプト実行へ移ります。

DOM ツリーは CSS と結合され、レイアウト・ペイント用のレンダーツリーを生成します。

DOM の重要性

DOM はブラウザ内で保持されるドキュメントモデルです。
HTML パーサ、CSS セレクタエンジン、JavaScript 実行環境の共有契約となり、DOM への変更は即座にレイアウトやスタイル、ユーザー操作へ反映されます。

DOM はクエリ選択から動的スタイリング・イベント処理まで全てを支える基盤です。スクリプトを編集し、右側の DOM がどのように変化するか観察してみてください。

レイアウト、ペイント、コンポジット

DOM と CSS が揃うと、ブラウザはレンダリングパイプラインを実行します：

レイアウト（リフロー） – サイズ・位置の計算
ペイント – ピクセル層への描画
コンポジット – GPU 上で層を結合

すべての変更が毎回全ステージを再実行するわけではありません。色の変更は通常ペイントのみ、サイズ変更はレイアウトとペイントを再計算します。

Change → Layout → Paint → Composite

そのためレイアウト負荷の高いページは遅く感じられます：次フレームが描画される前に多くの作業が必要になるからです。

まとめ

以上で完了です！
すべての例題を実行したなら、ブラウザがどのように機能するか明確なメンタルモデルを持っているはずです。

ガイドをご覧いただきありがとうございました。楽しんでいただけたでしょうか？