『Webブラウザエンジニアリング』第15-16章を読みました。

以下の書籍を15章と16章を読みました。
これで最後になります。

Webブラウザエンジニアリング

Webブラウザは、現代のコンピューティング環境において欠かせない存在であり、最も広く使われているプラットフォームの一つです。本書は、その仕組みを実践的に学ぶための解説書です。実際にWebブラウザを構築する過程をたどりながら、レンダリング、HTMLパーサー、CSS、JavaScript、マルチスレッド対応、セキュリティモデル、アニメーションとコンポジット処理、ブラウザAPI、アクセシビリティなど、モダンなWebブラウザの主要な要素を順を追って解説していきます。章ごとにコードを動かしながら、ブラウザに機能が積み重なっていく過程を通じて、ソフトウェアを成長させ改善していく経験を自然に体得できます。ブラウザ技術の研究者とChrome開発者による豊富な知見をもとに、Webの進化をたどりながら、手を動かしてブラウザの内部構造を深く理解できる一冊です。

oreilly.co.jp

1章から14章の感想については、以下で書いています。

画像

img要素を使って、画像表示したいです。
今までは、HTTP通信ではプレーンなテキストでのやりとりでしたが、バイナリデータを扱うようにします。
これまでのURLクラスの request 関数ではバイナリデータをレスポンスに返すようにします。
レスポンス参照していた箇所は、decodeして元の動作にしつつ、画像はdecodeしません。

画像バイナリデータを手に入れたら、Skia で画像描画します。
画像はデータサイズが大きい場合を考慮して、バイナリデータの複製はせずに参照（ポインタ）を使います。
画像が欠損していた場合は、以下の欠損画像を表示します。

https://commons.wikimedia.org/wiki/File:Broken\_Image.png

画像のサイズを計算して、Input 要素を追加したのと同じ流れで画像の描画実装をします。
画像自体のサイズだと困る場合があるので、img要素にはheight属性とwidth属性も実装します。

以下は、ブラウザで画像を表示している例です。

MIME

Multipurpose Internet Mail Extensions（略して、MIME）は、メールの添付ファイルで許容できるデータ種類を指します。
MIME には、 text/html や image/png などがあります。
この MIME は HTTP の Content Type で使用されています。

メール用に開発された MIME が Web で使用されるようになりましたし、
Webからメールできるようになりましたし、
クルクルしている感じがして、興味深いですね。

マジックバイト

バイナリデータの先頭に記述されている文字列によって、どの種類のファイルであるか判断できるようです。
その文字列を、マジックバイトと呼ぶそうです。

以下の Wiki に一覧があります。

List of file signatures - Wikipedia

en.wikipedia.org

png だと、バイナリに PNG の文字が入っているようです。

画像の高さ

画像の高さは、フォントサイズに依存するようです。
画像とテキストをインラインで並べる際に、テキストのフォントサイズと画像の高さを比較し、
大きい方を画像の高さとして採用するみたいです。
フォントサイズよりも小さい画像の高さは、フォントサイズと同じになるみたいです。

iframe

次は、iframeの実装です。
iframe は inline frame の略で、body の代わりに frameset を使うのと異なり、
body 内のどこでも行内にフレームを置くことができます。

iframeの実装の考え方としては、ブラウザのタブ内のタブです。
そこで、これまで実装してきたTabクラスをTabとFrameに分割します。
Frame には、HTMLドキュメントや、DOMやレイアウトのツリーを持ち、読み込みとイベント処理（フォーカスなど）も持ちます。
Tab には、ブラウザとFrameとの間のインターフェースとなり、Frame間や、ブラウザとFrameの間のやりとりを橋渡しします。
また、Tab は Frameすべてのディスプレイリストを描画し、ブラウザスレッドへコミットし画面へ反映します。

いざ実装を進めていくと、iframe には画像と違い、高さや横幅の固有サイズがありません。
iframe のheightやwidth属性、CSSのheight,widthプロパティを元に計算します。
また子の iframe へクリックイベントが発生したら、現在のframeから子の iframe へイベントxy座標の位置を調整したイベントを送ります。
送ったら、元の親frameの処理に戻ります。

以下は、iframeを埋め込んで表示した例です。

他には、同一オリジンであれば、JavaScriptのコンテキストを参照できたり、
フレームの親要素へアクセスできたりなど、実際のブラウザと近い実装もあります。
異なるオリジンの場合は、postMessage を使って相互通信できるようにします。

ドメインの書き換え

もう非推奨になっていますが、domain を書き換える Web API があるのですね。

Document: domain プロパティ - Web API | MDN - developer.mozilla.org

これを使えば、クロスオリジンを突破できるのかもしれませんが、やっちゃダメなやつですね。

その他

iframe を導入することで、悪意ある人が自身のサイトを埋め込まれてしまうことがあります。
攻撃を受けないためにも、ブラウザからのさまざまな対策が練られています。
ただ、ブラウザにもバグが生まれないことはあり得ないため、サンドボックス化という技術が使われているみたいです。

The Linux Sandbox - chromium.googlesource.com

システムコールできるものを制限することで、個人データの外部流出を防ぐことができるようです。
これで完全に防いでいるわけではなく、他にはCPUの実行タイミングからデータを予測するメルトダウンという攻撃があるそうです。

Meltdown and Spectre - meltdownattack.com

SharedArrayBuffer のような API を使って攻撃できるみたいです...。

キャッシュと無効化

次は、テキスト入力による描画時間についてです。

画面のコンテンツが多いと、テキスト入力のレスポンスが遅くなります。
これは、テキスト入力による画面描画が発生するためです。
画面コンテンツに量に比例して、描画時間が増えるのではなく、
変更のサイズに比例して、描画時間を増えるようにしたいです。
これを、インクリメンタルパフォーマンスの原則と呼んでるそうです。

考え方としては、最初のレンダリングと2回目以降のレンダリングを分けて考えます。
1回目のレンダリングは、ページ全体をゼロから行います。
このページをキャッシュし、2回目以降のレンダリングは、変更箇所のみキャッシュを無効化してレンダリングする、という具合です。
どれが変更されたか？を影響範囲を追跡できるように、依存関係グラフの構築が重要になります。

その依存関係グラフを構築するために、現在実装してきたレイアウトを大幅に変更しています。
その中で、関数を冪等性であることを担保する必要があります。
処理の中で、append のような処理をせずに、何度実行しても、入力が同じなら結果が同じになるように関数を修正します。

依存関係を把握するために、ProtectedField というクラスを用意し、ダーティビットのON/OFF、依存管理を制御するようにします。

また、レイアウトに関わるCSSのプロパティを列挙します。
それらの変更があれば、レイアウト変更とみなすように最適化します。

以上で、キャッシュと無効化による描画時間の高速化を実現します。

終わりに

ようやく、読み終えることができました。
3月17日にこちらの本が自宅に届いたので、読書期間は1ヶ月以内です。
最初はかなり小さなブラウザだったので、丁寧に1つずつ読み込んでいましたが、
終盤になるにつれて、ざっくりと読み進めてしまいました。笑

ブラウザの仕組みについて、知っていたことは奥深く理解できるようになりましたし、
知らなかった部分へ触れることもできました。
特に、opacityやtransformに関連するCompositeの作られた背景には、具体のイメージを持てて何よりの収穫でした。
終盤のダーティビットによる最適化は、混乱が半端ないので、
多分自分の手で動かしてやらないと、理解できないかもなと思います。

実務で活かせるように、もう一度自身の読書レビューを振り返っておこうと思いました。
読み応え抜群の良い本でした！