ハクソク

世界を動かす技術を、日本語で。

Show HN: ブラウザの仕組みを学ぶためのインタラクティブガイド

103日前原文(howbrowserswork.com)

概要

本ガイドはエンジニアや好奇心旺盛なWeb利用者向けの、ブラウザの仕組みを直感的に理解できるインタラクティブな解説。
複雑すぎず、浅すぎないバランスの良い内容を目指し、重要な詳細はあえて省略。
様々なインタラクティブ例を通じて、技術的な流れや直感的な理解をサポート。
オープンソースとして公開され、誰でも改善提案が可能。
主な流れは「URLからHTTPリクエスト」「DNS解決」「TCP接続」「HTMLパース」「レンダリングパイプライン」。

ブラウザの仕組み インタラクティブガイド

  • 対象者：エンジニアやWebを日常的に使うが、ブラウザ内部の動作を体系的に理解していない人
  • 特徴：従来の技術解説よりも直感的・実践的なアプローチ
  • 省略事項：HTTPバージョン、SSL/TLS、DNSの細かな挙動などは割愛
  • 参加方法：インタラクティブな例を操作しながら学習可能
  • オープンソース：GitHubで改善提案やプルリクエストが可能

ブラウザとURL

  • アドレスバーには何でも入力可能だが、内部ではURLとして扱う
  • 例：「pizza」と入力→検索URL（例: https://google.com/search?q=pizza）へ変換
  • 「example.com」などのドメイン名→完全なURL（例: https://example.com）へ正規化
  • 実際にアドレスバーに入力し、変換を体験できるインタラクション

URLからHTTPリクエストへの変換

  • ブラウザはHTTPプロトコルを使い、サーバーへリクエストを送信
  • URLをHTTPリクエスト形式に変換する過程を体験可能
  • 例：Hostヘッダ（Host: example.com）、Acceptヘッダ（Accept: text/html）など
  • Hostヘッダはリクエスト先のサーバー識別に利用

サーバーアドレスの解決（DNS）

  • ブラウザはドメイン名（例: example.com）をそのまま扱えない
  • DNSシステムを使い、ドメイン名をIPアドレスに変換
  • 入力したドメイン名をIPアドレスに解決するインタラクション

TCPコネクションの確立

  • IPアドレス取得後、TCPプロトコルでサーバーと信頼性の高い通信路を確立
  • 三者間ハンドシェイク（SYN、SYN-ACK、ACK）の流れ
    • SYN: クライアントから接続要求
    • SYN-ACK: サーバーが応答
    • ACK: クライアントが確認し接続完了
  • パケットの流れや通信の信頼性維持の仕組みを可視化
  • ネットワークの遅延や切断をシミュレート可能

HTTPリクエストとレスポンス

  • TCP接続確立後、HTTPリクエストをサーバーへ送信
  • サーバーからのHTTPレスポンスを受信
  • パケットの往復を可視化し、レスポンス到着後にHTMLがブラウザで処理される流れを体験

HTMLパースとDOMツリーの構築

  • レスポンス到着後、HTMLのヘッダとボディを分離
  • HTMLタグをトークン化し、DOMツリーを生成
  • 例：<h1>タグがノードとしてDOMツリーに追加
  • パースはストリーミング&エラー耐性あり
    • 文書全体が揃う前にノード作成
    • タグ抜けも自動補完
    • <script>タグで一時停止する場合あり
  • DOMツリーとCSSが統合され、レンダーツリーへ

DOMの重要性

  • DOMはドキュメントのメモリ上モデルで、HTMLパーサ・CSSセレクタエンジン・JavaScript実行系が共有
  • DOM変更は即座にレイアウト・スタイル・ユーザー操作に反映
  • クエリ選択・動的スタイル・イベント処理の基盤
  • JavaScript編集でリアルタイムにDOM変化を確認できるインタラクション

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

  • DOM・CSS準備後、レンダリングパイプラインが実行
    • Layout（リフロー）：サイズ・位置計算
    • Paint：ピクセル描画
    • Composite：レイヤー合成（GPU上で処理）
  • 変更内容により再実行されるステージが異なる
    • 色変更：Paintのみ
    • サイズ変更：LayoutとPaint両方
  • 各変更がどのステージに影響するかを体験できる
  • コンポジットで最終フレームが生成されるため、レイアウト負荷が高いページは表示が遅く感じやすい

まとめ

  • 一連のインタラクティブ例を体験することで、ブラウザの内部動作の全体像を直感的に把握
  • ガイドの目的：Web技術の基礎理解と、日常利用時の「なぜ？」に答える知識の提供
  • 感謝の言葉：最後まで読んでくれた方へ感謝

Hackerたちの意見

すごい！何もインストールしなくても、https://browser.engineering にワクワクしながら飛び込める感じだね。Browser/Serverの例に、デスクトップやノートパソコンのアイコンとサーバーのアイコンを使った小さなビジュアルがあったらいいなと思ってる。
└
もっと詳細なセクションを追加する予定なんだけど、まずはフィードバックを集めることにしたよ。ありがとう！いい提案だね。ちょっと考えてみるね。
狭いブラウザウィンドウ（< 1170）だと、コンテンツセクションが内容の上に浮いてて、ちょっと気が散るんだよね。
└
ありがとう！修正中だよ...
いいプロジェクトだね、シェアしてくれてありがとう！HNの読者は、https://hpbn.co（ハイパフォーマンスブラウザネットワーキング）や https://every-layout.dev（素晴らしいCSSリソース）もチェックすべきだよ。有料コンテンツはそれだけの価値があるけど、無料の部分も素晴らしいよ。
└
HPBNは本当に良く書かれてる。第4章のおかげで、前の仕事で高遅延の問題をデバッグするためにTLSを理解するのに役立ったよ。特に不完全なTLSフレームを受信して、その後のビットが来ないせいで、サーバーが残りのビットを30分待ってた問題があったんだ。HPBNは大きな助けになったよ。まだ読み終えてないけど、TLSフレームサイズを大きくするのと小さくするののトレードオフについて触れている部分があったのを覚えてる。これはHPBNのおかげで存在することを知った低レベルのノブなんだ。使うかどうかは分からないけど、面白いね。
└
Hpbnは本当に面白いね、リンクしてくれてありがとう！
すごく気に入った！--> ブックマークしたよ :-) 欲しいのは、HTML/DOMに基づいて他のリソース（画像、スタイルシート、スクリプト）がどう読み込まれるかってこと。これが分かると、画像が時々消えたり、ページがスタイルなしで表示されたりする理由が理解できると思うんだ。
└
これについて考えたけど、シンプルに保つようにしたよ。ガイドを複雑にしないで、これらのブロックをどう追加するか考えてみるね。ありがとう！
これ、今取り組んでるプロジェクトにすごく関連してるんだ。ChromiumやFirefoxに基づかない新しいウェブブラウザを作ってるの。ウェブブラウザは非常に複雑で、インターネットのさまざまな標準に対応するために何百万行ものコードが必要なんだ（HTML、JavaScript、CSSの基本的なものだけじゃなくてね）。少し前に、このAIがどれだけ自律的にできるか（または人間が関わる形で）を見たくて、数日前に投稿した10分のデモがあるよ：https://www.youtube.com/watch?v=4xdIMmrLMLo&t=42s これのソースコードは今ここにあるよ：http://taonexus.com/publicfiles/jan2026/160toy-browser.py.tx... たった2000行くらいだから、機能はあまりないけど、POSTリクエストを送ったり、いくつかのウィキペディアの記事を読むことができるよ。試してみて。残念ながらすごく遅いけどね。改善したいことがあったら教えてね。ここにフィーチャーリクエストのページもあるよ：https://pollunit.com/en/polls/ahysed74t8gaktvqno100g
└
コードをざっと見たけど、結構いい感じの基本的なアプローチだね。遅くなってる理由はいくつか見えるよ。マルチプロセッシングやスレッディングを使ってないし、レンダリングを再構築する必要があるかも。レンダラーをループで動かして、スタックが変わったときに再レンダリングする必要があるし、マルチプロセッシング/スレッドループがリクエストが終わったときにスタックを調整する感じかな。次に、既存のPython DOM処理モジュールを見てみることをおすすめするよ。これで既存のコードを使って、自分のブラウザに合うように拡張できるし、面倒なパースのエッジケースを見つける必要もないから。これで少しはスピードアップするかも。壊れたサイトをレンダリングしてみるのもおすすめだよ（コピーを保存して壊してみて、自分のブラウザがどうなるか見るために）。完成度を高めるためにね。
└
Pythonのウェブブラウザに興味があったら、Grailを見てみるのをおすすめするよ！ https://grail.sourceforge.net/
すべてのブラウザがDOMを持っていたわけじゃなくて、後のバージョンまで持ってなかったものもあったんだ。初期のDOMなしブラウザ（初リリース日）：WorldWideWeb (Nexus)（1990年12月）、Erwise（1992年4月）、ViolaWWW（1992年5月）、Lynx（1992年）、NCSA Mosaic 1.0（1993年4月）、Netscape 1.0（1994年12月）、IE 1.0（1995年8月）。注意：Lynxは設計上、非DOMブラウザのままだよ。AOL 1.0～2.0（1994～1995年）は、プログラム可能なオブジェクトがない静的なAOLPressエンジンを使ってた。DOMとのインタラクションは、Netscape 2.0（1995年9月）、IE 3.0（1996年8月）、AOL 3.0（1996年、統合されたIEエンジン経由）、Opera 3.0（1997年）で始まった「Legacy DOM」（レベル0）から始まったんだ。その後、1997年にはNetscape 4.0（document.layers）とIE 4.0（document.all）がそれぞれ独自のモデルを使ってた中間のフェーズがあった。最初の普遍的な標準はW3C DOM Level 1 Recommendation（1998年10月）だった。主要なブラウザはこれをゆっくり採用していった：IE 5.0（1999年3月）は部分的なサポートを提供し、Konqueror 2.0（2000年10月）とNetscape 6.0（2000年11月）が最初のW3C準拠エンジン（KHTMLとGecko）だった。Safari 1.0（2003年）、Firefox 1.0（2004年）、Chrome 1.0（2008年）は、バージョン1.0からネイティブの標準DOMサポートを持ってスタートした。現在、ほとんどの主要なブラウザエンジンはWHATWG DOM Living Standardに従って、リアルタイム機能の実装をサポートしてるよ。
└
提案ありがとう！「現代のブラウザにおけるDOM」って書く方が正しいかな？
└
最後に確認したとき、Dilloにはその用語の合理的な定義におけるDOMがないってことだったよ。代わりに、レンダリング時にテキストのHTMLを直接解釈するから、すごく少ないRAMしか使わない理由がわかるね。
子供の頃、CRTテレビの仕組みについての電子工学の本を持ってたんだ。こういう投稿は、その現代版って感じだね。
ページの半分以上がネットワークリクエストに割かれてるのはちょっと残念だけど、ブラウザの作業と複雑さのほとんどはパースとレンダリングパイプラインにあるんだよね。
└
それにDOMもね（レンダリングパイプラインの一部だって言えるけど）。
└
レンダリングエンジンについてもっと詳しく説明する予定だよ。どのセクションを深掘りするか分からなかったから、ちょっと止めてフィードバックを集めることにしたんだ。ありがとう！
URLの解析についてもう少し手を加えることを提案したいな（ほとんどのユーザーは誤解されるような入力はしないと思うけど）。例えば、https://やhttp://以外のプロトコルスキームが使われた場合、ブラウザは何らかの形で特別扱いするかもしれないし（ブラウザは以前よりもこれらをサポートする数が減っているみたいだけど！）。こういうケースもキャッチできるといいかも。 https://en.wikipedia.org/wiki/List_of_URI_schemes
これはすべてのブラウザを考慮しているわけじゃなくて、SafariとChromeだけだね。別々の検索バーとアドレスバーについては一言も触れられてないし。