普段はwebアプリ開発をしていますが、 
ブラウザ内部で実装したコード達がどのように動いているのかなんとなくでしかわかっていなかったので、 
ちょっと調べてみた系の記事です。

 

## ブラウザの全体的な構造

![ブラウザ全体構造](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/browser.webp 'ブラウザ全体構造')

この図の四角がブラウザのコンポーネントというらしいです。

 

## コンポーネントの役割

1. User Interface

- アドレスバーや、進む、戻る、リロードボタンやお気に入りなど、
 chromeを開いたときに目に見えるもの全部

2. Browser Engine

- UIとレンダリングエンジンの中間にいて、2つの間でのアクションをそれぞれにわかりやすく変換する役割
- UIから入力を受け取り、それを元にレンダリングエンジンへ命令を渡す

3. Rendering Engine

- 2からの命令に従ってブラウザ画面にちゃんと表示できるように働く場所
- 全てのコンポーネントで `ここが一番負荷がかかっていて大事な部分`
- HTMLがリクエストされた場合は、ここでHTML, CSSを解析してパパッと画面に出せるように頑張る
- #### `なので、このコンポーネントが解析しやすいコードにしないとパフォーマンスが落ちるということ`
- 代表的なレンダリングエンジン
 - Blink(Chrome, Edge, Operaなどで使用)
 - Webkit(Safariで使用)
 - Gecko(Firefoxで使用)

4. Networking

- リクエスト...ブラウザがHTTPやHTTPSリクエストを送信して、HTML, CSS, Javascript, 画像などを取得する
- レスポンス...受け取ったレスポンスをレンダリングエンジンや、ブラウザエンジンに渡したりする

5. Javascript Interpreter

- JSコードを解析して実行するために使用される
- 代表的なJSエンジン
 - V8(Chrome, Edge)
 - JavascriptCore(Safari)
 - SpiderMonkey(Firefox)

6. UI Backend

- UIで操作した(クリックなど)ことを裏側で行うために使用

7. Data Persistence

- Cookie, LocalStorage, SessionStorage, IndexedDB, WebSQL, FileSystemなどデータ永続性のために使用

 

## レンダリングエンジンについてもう少し詳しく

Webアプリ開発において、このコンポーネントからレンダリングエンジンについて考慮する必要がかなりある。

 

https://web.dev/articles/howbrowserswork?hl=ja

 

レンダリングエンジンは、各タブごとにそれぞれのプロセスで実行される。

## レンダリングエンジンの内部処理の流れ

![レンダリングエンジン](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/render.webp 'レンダリングエンジン')

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

- HTMLを受け取り、画面を構成するためDOMツリーを構築する

https://ja.javascript.info/dom-nodes

- CSSを適用
 1で構築したDOMツリーに対し、外部ファイルやスタイルタグのCSSを解析する。
 この解析結果は、CSSOM(CSS Object Model)というツリーにまとめられる

2. レンダーツリーを構築
 1でできたDOMツリー、CSSOMを組み合わせレンダーツリーが作成されます。
 ここでは、レンダリング対象の要素のみ入っている。
 そのため、画面を構成しない下記のものはこちらには入っていない

- meta情報
- display: none など

3. レンダーツリーをレイアウト

- 2のレンダーツリーを元に、位置・サイズを計算し正確なCSS情報を計算
- そして、正確なCSSをHTMLに当てていく。
 ex. z-indexの重ね順などが整理されていく

4. レンダーツリーをペイント

- 6番のコンポーネントにあった`UI Backend`を使用して各ノードを画面上にペイントしていく。
- 重ね順に従って、背景から前面へと描画されていく。

#### 2〜4は全て終わってから描画されるのではなく、できたものからどんどん描画を進めていく。

 

## レンダリングエンジンが解析しやすい書き方

ChatGPTにちょっと聞いてみました。

- 適切なHTML

 - ほとんどdivで囲むのではなく、ヘッダーなら `headerタグ`, フッターなら `footerタグ`, など役割にあったタグをちゃんと使用する
 - 深い階層にしない

 ```html:index.html
 <div>
 <ul>
 <li>
 <a href="https://google.com"> googleへ </a>
 </li>
 </ul>
 </div>
 ```

 このコードより、

 ```html:index.html
 <li>
 <a href="https://google.com"> googleへ </a>
 </li>
 ```

 このように短いネストの方が解析しやすいらしい

 - 非推奨タグは使用しない

 

- CSSを分離

 - HTMLに直書きするのではなくちゃんと別ファイルに分離する

- 効率的なJavascript

 - 不要なJavascriptは読み込まないようにして実行されないようにする

- キャッシュコントロール

 - 適切なキャッシュコントロールヘッダーを設定する

- レスポンシブ
 - メディアクエリを使用しレスポンシブデザインを書いておく

## まとめ

簡単に書いてみましたので、本当はもっといろいろなことが内部で行われて画面が見えるようになっております。 
URLを叩いてすぐ画面が出てくるのに、裏側で色々なことが一瞬でやってると思うとすごいなーという感じですね！

#### 引用

https://web.dev/articles/howbrowserswork?hl=ja

https://dev.to/itswillt/the-components-of-a-browser-23mn

検索ブラウザの内部構造を見てみる

とある企業さんとのカジュアル面談時に、 
面談相手のエンジニアへキャッチアップはどのようにしているかを聞いてみたら、 
下記のシステム設計などをみたりしていると教えてもらったので、 
その中から興味があった、負荷分散の項目を追ってみようと思う。 

 

## 一般的な負荷分散アルゴリズム(ロードバランサーを使用した場合)
1. ラウンドロビン

![Round Robin](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/roundrobin.webp "Round Robin")

ユーザーからのリクエストに対して、順番にサーバーへ送信される。 
簡単な設計だが、サーバー側の負荷を考慮しないので、サーバーAが死んだ場合もリクエストが送られてしまう。

 

2. スティッキーラウンドロビン

![Sticky Round Robin](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/stickyRoundRobin.webp "Sticky Round Robin")

ユーザーからのリクエストはずっと同じサーバーに送信するようにする。 
セッションパーシステムを実現するためのアルゴリズム。 
特にユーザーのセッション状態を維持してサービスを展開したいもの(ECサイトなどなど)に有効。 
しかし、これも同じサーバーに接続し続けるのでサーバーが死んだらエラーになってしまい、負荷が均等に分散されない。 
※ セッションパーシステム 
特定のユーザーから来る一連のリクエストを同じサーバーに振り分けること。 
 
下記でセッションを固定している 
・IPアドレスベースでセッションを固定 
・ユーザーにセッションIDを割り当てて固定 
・Cookieを使用してセッション情報を保持して固定

 

3. 加重ラウンドロビン

![Weighted Round Robin](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/WeightedRoundRobin.webp "Weighted Round Robin")

各サービスに対して重みを設定する。 
図だとServiceAに80%,その他に10%ずつ重みを設定している。 
そうすると80%までのリクエストはServiceAに、81%〜90%はServiceB、90%〜100%はServiceCに割り振られる。 
サーバーの能力に応じて重みを設定することが大事。

 

4. ハッシュ

![IP URL Hash](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/ipUrlHash.webp "IP URL Hash")

受信トラフィックの送信元と送信先のIPアドレス、URLを組み合わせて、 
数学的関数を使用しハッシュに変換。そのハッシュの値で指定したサーバーに割り振られる。
図だと、req1, req2のipアドレスやURLが0になると、ServiceAのインスタンスにルーティングされる。

 

5. 最小接続数

![Least Connections](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/leastConnections.webp "Least Connections")

同時接続数が最も少ないサービスに送信される。
サーバー間の負荷を均等に分散できるため動的な環境に適している。

 


6. 最短応答時間

![Least Time](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/leastTime.webp "Least Time")

最もレスポンス時間が短いサーバーに送信される。 
リアルタイムにサーバーのパフォーマンスを監視し、動的に負荷を分散している。

 

※ロードバランサーは、複数サーバー間でのトラフィックを効率的に分散する

## まとめ
なんとなくで負荷分散している部分もあったので、
こういったアルゴリズムを取り入いれ品質を高めていこうと思う今日この頃。

Zaki-dev

architectureの記事

検索ブラウザの内部構造を見てみる

【システム設計1】負荷分散アルゴリズムについて考えてみる

architectureの記事

検索ブラウザの内部構造を見てみる

【システム設計1】 負荷分散アルゴリズムについて考えてみる

【システム設計1】負荷分散アルゴリズムについて考えてみる