# 7/30讀書會(網路概念)

###### tags: `面試考古題`

## 翊廷：
https://docs.google.com/presentation/d/1OHbsULw0uKGY2DhHr7M6559IOvecvrqrRIIElJcxmoE/edit#slide=id.ge724138769_0_145

## Marco：
https://drive.google.com/drive/folders/188njmubuXRzRbFwfB_UlgvJ4SsFAPpXY?usp=sharing

## 同源政策：
- 定義：
- 需要後端回傳的Header包含你所在的origin(scheme + host + port)，瀏覽器才會把收到的response給你
- 允許HTML tag產生的跨來源寫入(write)、嵌入(embed)、讀取(read)，但對於JS的跨來源write/embed/read有限制
- 用途：安全性，讓資料不能透過瀏覽器隨意撈取不同來源的資料
- 執行環境：瀏覽器
- 常見理解錯誤：
- origin跟domain是不一樣的，特別發生在cookie v.s. cors的差異上

### jsonp = json with padding
- 定義：是資料格式JSON的一種使用模式
- 用途：跨網域取得資料，補充：另一個方式是跨來源資源共享
- 使用方式：透過<script>作為同源策略的例外，網頁可以得到其他來源動態產生的JSON資料，而這個使用模式就是JSONP
- 危險性：容易遭受CSRF的攻擊，
- 預防：存放隱私性低的資料
- 我理解的範例：~~我們會運用ajax去撈取其他API的資料，並拿來使用在本身的網頁上~~
上述的內容正好就是要繞開的地方：
- 參考資料：
- [JSONP概念](https://www.fooish.com/json/jsonp.html)
- [實作範例](https://medium.com/@brianwu291/jsonp-with-simple-example-4711e2a07443)
- [CSRF攻擊][[reference](https://www.itread01.com/content/1546912094.html)]

### cors = Cross-Origin Resource Sharing
- 定義：使用額外HTTP HEADER令**目前瀏覽網站**可以取得**其他網域伺服器**特定資源權限的機制
- 用途：跨網域取得資料
- 使用方式：
- 簡單請求：server會做CORS設定，並且在回傳時加上Access-Control-Allow-Origin，瀏覽器會讀取這個HEADER，確定自己有在符合範圍內
- 非簡單請求：在上述動作前會先完成預檢請求，方式是客戶端會先發送方法為option的請求，並夾帶兩個HEADER屬性，包括Access-Control-Request-Method、Access-Control-Request-Headers以告訴伺服器實際請求會是什麼方法以及是否有額外標頭，而後伺服器會回應是否接受請求。

- 參考資料：
- [Huli大大的文章](https://blog.huli.tw/2021/02/19/cors-guide-1/)
- local host vs → proxy → 撈取資料(API) → header Access-Control-Allow-Origin: '*'

## GET 和 POST的差別：
| | GET | POST |
| ---------- | ----------------------------------- | -------------------------- |
| ==用途== | 從特定位址取得資源 | 傳送資源去server新增或更新 |
| ==差異== | 可以被快取 | 不會被快取 |
| | 會被保存在瀏覽器的歷史中 | 不會 |
| | 有長度限制(query)(url最長是2048) | 資料長度沒有限制 |
| 資料位置 | 資料會放在path上，以query的方式呈現 | 資料放在request-body |
| 重新整理後 | 會重新執行(但瀏覽器有快取的話不會) | 不會重新執行 |

設計API時GET只會使用在取得資料的功能上；POST則會用來作為新增資料的http method

## stack & queue
處理陣列的兩種常見方式

- stack 堆疊
- 遵循後進先出原則
- 例子：疊盤子、發牌、走迷宮
- 實作：Leetcode第20題、反轉字串實作
- 參考網站：[堆疊解法](https://ithelp.ithome.com.tw/articles/10205260)

- queue 柱列
- 遵循先進先出原則
- 例子：排隊、坐公車、記憶體緩衝區、印表機佇列、電商or搶票

## CDN：
- 目的：判斷使用者位置，讓使用者使用最近的伺服器

## cookie / session
- 翊廷：session重點是讓無狀態的http可以認得狀態
- session: 都有開始和結束
- cookie: 伺服器發回來response會夾帶HEADER: Set-cookie

## ajax:
- 翊廷：
- 目的：透過非同步解決同步載入網頁時會有的卡頓問題
- 歷史：從原生物件→jquery→axios、fetch

## 取的資料過程
- 翊廷：
- 怎麼拿到資料 → 怎麼渲染

## https：
- 翊廷：
- 需要申請certification

## DNS：
-翊廷：
- a record：將DNS網域名稱指定到特定主機的IP位址
- c name record：

## Session
- 定義：是一種讓request變成stateful的機制，也可以說是**具有狀態的一段期間**
- 特性：
- 每個session都有開始與結束
- 每個session都是相對短暫的
- 瀏覽器or伺服器任一方，都可以終止這個seesion
- session包含了交換狀態資訊的概念

## Cookie
- 定義：瀏覽器的儲存空間，用來協助儲存所造訪網頁上的偏好和其他資訊
- 屬性：
- `domain`，如果未設定，會自動綁在執行Set-Cookie的domian下
- `path`，指定在特定路徑下生效，預設是`/`
- `Max-Age`，有效期限，單位是秒
- `Expires`，同上，指定的是時間點
- `secure`，當這個屬性被設定為true，只會在『安全協議下』傳輸，通常是HTTPS
- `HttpOnly`，只能在網路傳輸中使用，若設定為true，就無法透過js取得

**可以透過`domain`、`path`限縮Cookie的使用範圍，以及`Max-Age`指定有效期限**

- 限制：
- 單個最大4K
- 一個domain下最多設置20個

- 缺點：
- 可以被用來追蹤使用者
- 第三方cookie在渲染頁面同時，會發送一些request去其他server，所以儘管使用者沒有直接去這些網站，這些網站可以利用cookie追蹤使用者

### cookie-based session
- 定義：將所有session狀態都存放在cookie中

### session ID
- 定義：瀏覽器只在cookie裡存放一組用來辨識身份的ID，其餘狀態都存在server端

## DNS (網域名稱系統 Domain Name System )
- 將網址區分為許多不同的網域(Domain)，並且定義了不同的層級


### A Record 與 CNAME Record
- A Record會指向一個特定的主機的IP位址
- CNAME Record 可以讓一個A Record使用其他或多個名稱，例如一個叫blog.marco.com的網站，加上CNAME紀錄如：web.marco.com讓它也連到同一個網站上

## 所有HTTP methods
- GET
- 動作：讀取
- 向指定的資源發出『顯示』資料的請求，GET應該只用在讀取資料，而不應當被用於產生副作用的操作中

- POST
- 動作：新增
- 向指定資源提交資料，請求伺服器進行處理（例如提交表單或者上傳檔案）

- PATCH
- 動作：部分更新
- 請求更新一筆資源的部分內容，必須是存在的資源

- PUT
- 動作：完整更新
- 請求更新一筆資源的所有內容，必須是存在的資源，資源傳遞必須完整否則為空

- DELETE
- 動作：刪除
- 請求伺服器刪除所標識的資源

- HEAD
- 動作：讀取
- 與GET相同，但它沒有回應主體(response body)，伺服器只傳出HTML的狀態跟表頭(如同html都有一塊head，只取這一塊資料)

- CONNECT
- 預留給能將連線改為管道方式的代理伺服器，通常用於SSL加密伺服器的連結

- TRACE
- 回顯伺服器收到的請求，主要用於測試或診斷

- OPTIONS
- 可使伺服器回傳該資源所支援的所有HTTP請求方法，主要用於詢問伺服器哪些方法可以讓人使用，但也可以被惡意攻擊者刺探敏感資訊，弱點掃描檢測時建議關閉此方法

## CDN：
- 目的：CDN 會透過判斷目前使用者的位置，找到最近的 CDN 伺服器並讀取其中的快取內容，讓該使用者需要伺服器回應的時間降到最低。
- 可以先看看這支影片：[Youtube連結](https://www.youtube.com/watch?v=Bsq5cKkS33I&feature=emb_title)
- CDN 的好處：
1. 減少網站載入時間
透過連結最近的 CDN 伺服器內的快取內容，網站內容能更快的被讀取，同時讓使用者等待載入的時間變短，若是使用較多網站會使用的 JavaScript Library，可能使用者在別的網站已經被載入過，因此在讀取你的網站時，又可以省去載入時間了！
2. 降低網站主機的 loading
假設當一個使用者讀取你的網站需要載入 HTML 內容及 50 張圖片，這時候如果將載入 50 張圖片的任務交給 CDN，那每個使用者對伺服器就只需要發出載入 HTML 內容的需求，這樣就能讓更多使用者對網路發出需求，也就能增加更多在線使用者了！
3. 提高網站穩定度及安全性
當使用者分別在不同地區連線網站，並透過不同 CDN 載入內容，就可避免瞬間湧入過大流量，讓主網域更穩定。
也因為流量分散，故惡意攻擊也比較難攻擊到主網域，加上 CDN 提供了 DDoS 防護、改善安全憑證等服務，也讓安全性更提升了！
- CDN 缺點：
1. 增加成本
雖然像 GoogleAPI, BootstrapCDN 等是提供免費的 CDN 服務，但大多數的CDN 會依照網站所發出的請求量收費，因此也有可能使用了 CDN 每月還需要付另外的費用。
2. 讓網站架構更複雜甚至可能被 Block
如果 CDN 突然無法載入資源，你的網站就會出事了，或是你使用的 CDN 公司被使用者的網路 Blocked （可能是 spamming 或是其他問題），你的網站也會顯示的不完整，導致看起來很像壞了
3. 可能讓載入時間更長
如果剛好使用者的城市附近沒有 CDN 的伺服器，且他附近的伺服器可能距離比你和他的城市更遠，就會導致載入時間反而會更長的情況發生。

參考閱讀資料：
1.[ Advantages and Disadvantages of a Content Delivery Network]( https://blog.webnames.ca/advantages-and-disadvantages-of-a-content-delivery-network/)
2. [什麼是 CDN？| CDN 的工作原理是什麼？]( https://www.cloudflare.com/zh-tw/learning/cdn/what-is-a-cdn/)

## cookie / session
- 翊廷：session重點是讓無狀態的 http 可以認得狀態
- session: 都有開始和結束
- cookie: 伺服器發回來 response 會夾帶 HEADER: Set-cookie

## [JSON](https://developer.mozilla.org/zh-TW/docs/Learn/JavaScript/Objects/JSON) (JavaScript Object Notation)
- 定義：獨立於語言的純文字格式（雖然 JSON 是從 JavaScript 出來的，但他是純文字格式所以很多其他語言也都可以讀寫 JSON）
- 用途：
- 用來傳輸由屬性值或者序列性 (serialize) 的值組成的資料物件
- 支援的資料格式：物件、陣列、數字、字串、布林值、null
- 資料以 key-value pair 型式儲存
- 優點：
- 許多語言都支援 JSON 格式，可使用範圍廣
- 容易閱讀
- 支援許多資料格式（物件、陣列、數字、字串、布林值、null）
- 在 JavaScript 使用方法：
- [JSON.parse ( )](https://developer.mozilla.org/zh-TW/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse) ：把一個 JSON 字串轉換成 JavaScript 的數值或是物件
- [JSON.stringify ( )](https://developer.mozilla.org/zh-TW/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify) ：將 JavaScript 的數值或物件轉換成 JSON 字串

## [YAML](https://yaml.org/)（YAML Ain't Markup Language）（副檔名 .yml）
- 定義：
- YAML 官網強調 YAML 不是標註語言，而是一種適用於所有語言，人性化的資料序列標準。
- 也就是說它一種描述 **設定** 的文字格式，可以簡單表達清單、雜湊表，純量等資料形態。
- JSON 是 YAML 的子集，因此 YAML 支援 JSON 的格式。從用途而言，JSON 大多用於資料傳輸，YAML 大多用於組態設定。
- 語法：
- 參照 C 語言、Python、Perl，並從 XML、電子郵件的數據格式（[RFC](https://zh.wikipedia.org/wiki/RFC) 2822）中獲得靈感。
- 使用 空格 縮行 表示資料的階層，左側對齊的節點視為同一階層的資料
- YAML 格式中，含有一個到多個 節點 (node)，每個節點必定是 純量 (Scalar)、序列 (Sequence)、映射 (Mapping) 資料 其中一種。
- 純量：以文字描述不可分割的資料值
- 序列（-）：有順序的節點清單
- 映射（:）：key-value pair
- 參考資料：[延伸補充 - YAML](https://ithelp.ithome.com.tw/articles/10206454)

## ajax:
- 翊廷：
- 目的：透過非同步解決同步載入網頁時會有的卡頓問題
- 歷史：從原生物件 → jquery → axios、fetch
- Tina：
- 介紹：當前端透過 Axios 發出請求時，背後的技術就是 Ajax，Ajax 並不是單一的技術，而是一套綜合性的瀏覽器端網頁開發技術，而 Ajax 是 Asynchronous JavaScript and XML 的縮寫：
Asynchronous：非同步
JavaScript：使用的程式語言
XML：Client 與 Server 交換資料用的資料與方法，近年由於 JSON 等格式的流行，使用 Ajax 處理的資料並不限於 XML。

- 優點：而 Ajax 技術的出現，讓瀏覽器可以向 Server 請求資料而不需費時等待，若是同步請求的話，瀏覽器會需要等到接受到 response 後才會開始渲染畫面，而這時候整個網站是沒辦法再進行任何動作的！
所以當非同步請求出現時，只要瀏覽器接收到 response 之後，新的內容就會即時地添入原本網頁。
- 為什麼現在不直接使用 Ajax：因為流程麻煩，所以有其他更好的套件輔助使用。
最早期的 Ajax 會利用一個 **XMLHttpRequest** 物件 (簡稱為 XHR ) 來實作，類似這樣：

        function reqListener () {
          console.log(this.responseText);
        }

        var oReq = new XMLHttpRequest();
        oReq.addEventListener('load', reqListener);
        oReq.open('GET', 'http://www.example.org/example.txt');
        oReq.send();

傳統流程如下：

1. 建立了一個 **XMLHttpRequest** 物件
2. 使用 `.open()` 開啟一個 URL
3. 最後使用 `.send()` 發出 request。

因為手續繁瑣，後來就有 jQuery 的 $.ajax() 出現，然而在 JavaScript 日趨成熟之後，許多新的替代方案應運而生，例如加入 ES6 promise 物件的 Fetch API，和 axios 也出現了。

但其實你不一定能夠隨便透過 Ajax 亂串一個路人的 API，會被瀏覽器的安全性考量同源政策所擋下

意思就是說如果你現在這個網站的跟你要呼叫的 API 的網站「不同源」的時候，瀏覽器一樣會幫你發 Request，但是會把 Response 給擋下來，不讓你的 JavaScript 拿到並且傳回錯誤。

同源不同源：只要是 Domain 不一樣就是不同源，或者是一個用 http 一個用 https 也是不同源。

- 參考資料：
[AJAX介紹]( https://blog.techbridge.cc/2017/05/20/api-ajax-cors-and-jsonp/)
[AJAX 和 AXIOS](https://ithelp.ithome.com.tw/articles/10244631)

## HTTP 狀態碼 by Tina
定義：伺服器端回應的狀態，需要記住五大開頭數字代表的涵意

### 1xx -參考資訊

**重點： 在用戶端收到定期回應之前，用戶端會收到一或多個 1 xx 回應，主要重點就是回應正在處理請求，而 client 端應該要準備接收這個狀態碼。**

HTTP/1.0 沒有定義任何 1xx 狀態碼，Server 不得向 HTTP/1.0 的 Client 發送 1xx 狀態碼。

- 100 Continue - 繼續執行所發出的請求。
這也有助於 Client 提高一些錯誤處理的效率，若 Sever 根本不同意 User 上傳資料，則可以直接回應錯誤，而非讓 Client 傻傻地上傳完整檔案才拒絕。
- 101 Switching Protocols - 切換通訊協定。

### 2 xx -成功

**重點：這些 HTTP 狀態碼表示伺服器已成功接受要求**

- 200-確定。 用戶端要求已成功。
- 201-已建立。
- 202-已接受，Server 已經接受請求，但尚未處理完成。
- 203-非授權資訊。
- 204-沒有內容。
- 205-重設內容。
- 206-部分內容。

### 3 xx -重新導向

**重點：瀏覽器必須採取更多動作來完成要求，例如瀏覽器可能必須重新發出 HTTP Request 要求伺服器上的不同頁面。**

- 301- 要求的網頁已經永久改變網址。此狀態要求用戶端未來在連結此網址時應該導向至指定的 URI。（前端應該要重新導向）
通常使用「**301**」導向頁面，能使 SEO 的影響最小，這也正是 Google Search Console 網站欲變更網址的必備步驟之一
- 302-物件已移動，目標資源 (target resource) 暫時存在於不同的 URI
和 301 不同的是，302 是有可能更改重新導向的URL，因此 302 是預設不可快取的。
- 303 See Other - 通知用戶端使用 GET 連到另一個 URI 去查看。
- 304  Not Modified - 未修改。用戶端要求該網頁時，其內容並沒有變更。
- 305 Use Proxy - 要求的網頁必須透過 Server 指定的 proxy 才能查看(需透過 Location 標頭)。
- 306 (Unused)- (未使用) 此代碼僅用來為了向前相容而已。
- 307 Temporary Redirect - 暫時重新導向。要求的網頁只是「暫時」改變網址而已，和302很像，但是他不能更改請求方式 (Request Method)。
- 308 (Permanent Redirect) — 永久重新導向，和 301 很像，但是他不能更改請求方式 (Request Method)。

### 4 xx -用戶端錯誤

**重點：表示瀏覽器發生錯誤，問題出現在客戶端**

- 400-錯誤的要求。 由於語法錯誤，導致伺服器無法瞭解要求
- 401-拒絕存取`（重點是驗證錯誤）`。
- 401.1-登入失敗。
- 401.2-由於伺服器設定，登入失敗。
- 401.501-拒絕存取：來自相同用戶端 IP 的要求太多;已達到動態 IP 限制同時要求速率限制。
- 401.502-禁止訪問：來自相同用戶端 IP 的要求太多;已達到動態 IP 限制最大要求速率限制。
- 401.503-拒絕存取： IP 位址會包含在 IP 限制的拒絕清單中
- 401.504-拒絕存取：主機名稱會包含在 IP 限制的「拒絕」清單中
- 403-已禁止，例: Server 禁止訪客存取某頁面，即可使用 403 (Forbidden)`（重點是權限不足）`
- 404-找不到。
- 405 - 用來存取這個頁面的 HTTP 動詞不受允許 (方法不受允許)。
- 406 - 用戶端瀏覽器不接受要求頁面的 MIME 類型。
- 407 - 需要 Proxy 驗證。
- 412 - 指定條件失敗。
- 413 - 要求的實體太大。
- 414 - 要求 URI 太長。
- 415 - 不支援的媒體類型。
- 416 - 無法滿足要求的範圍。
- 417 - 執行失敗。
- 423 - 鎖定錯誤。

### 5 xx -伺服器錯誤

**重點：表示伺服器由於伺服器發生錯誤而無法完成要求。**

- 500-內部伺服器錯誤。
- 500.12 - 應用程式正忙於在 Web 伺服器上重新啟動。
- 500.13 - Web 伺服器過於忙碌。
- 501-標頭值指定未執行的設定。
- 502-網頁伺服器充當閘道或 proxy 時收到不正確回應。
- 503-服務無法使用。
- 504 - 閘道逾時。
- 505 - 不支援的 HTTP 版本。

## 延伸閱讀：

[微軟的官方說明，很詳細但中文有點難懂](https://docs.microsoft.com/zh-tw/troubleshoot/iis/http-status-code)

[網路神人整理，中文有夠詳細](https://notfalse.net/48/http-status-codes)

## 取的資料過程
- 翊廷：
- 怎麼拿到資料 → 怎麼渲染

## 請說明什麼是 HTTPS？：
- 翊廷：
- 需要申請 certification
- [HTTPS](https://zh.wikipedia.org/wiki/超文本传输协议) 超文本傳輸協定 (HyperText Transfer Protocol Secure)
- HTTPS 經由 HTTP 進行通訊，但利用 [SSL/TLS (Secure Sockets Layer/ Transport Layer Security)](https://ithelp.ithome.com.tw/articles/10219106) 來加密封包。所以會用在傳輸敏感性資訊：信用卡號、銀行帳號、登入資料等。

## [HTTP 和 HTTPS 的差別是？](https://tw.alphacamp.co/blog/http-https-difference)需要做什麼步驟才能佈署 HTTPS？
1. HTTPS 的 S 是 Secure，比起 HTTP 是以一般非安全模式下進行傳輸，HTTPS 是經過加密的超文本傳輸協定。HTTP 不經過加密會使用較少運算資源，也會佔用較少傳輸頻寬，但因資料可能被竊取因此不適合用於傳輸敏感性資料。HTTP 使用的是 80 Port 的協定（純文字模式）；HTTPS 是 443 Port 的協定（可通行二進制字元模式）。
2. 部署 HTTPS 的步驟：
- 有一個專屬 IP
- [獲取 SSL 證書](https://www.cloudflare.com/zh-tw/learning/ssl/what-is-an-ssl-certificate/)：
- 自己生成，但因無被認證因此仍可能被標記為不安全網頁
- 向第三方 Certificate Authority (CA) 購買，較為安全
啟用證書
- 產生憑證簽署要求 CSR。
- CSR 是一個加密過的文字檔，內容記載身份，以及所要簽署的域名（主域名、子域名或萬用字元域名）。 須先透過特定的軟體產生 CSR 檔，並將生成的內容複製、貼上在購買 SSL 憑證的訂單表格中，才能夠啟動 SSL 憑證購買程序。
- 成功購買 SSL 證書後即可成功部署 HTTPS

## DNS：
-翊廷：
- a record：將 DNS 網域名稱指定到特定主機的 IP 位址
- c name record：

## 從輸入 URL 後按下 Enter，到瀏覽器顯示出畫面，這中間發生了什麼事? by Tina
我覺得可以分成兩大部分來說，一個是按下 enter 到後端伺服器回應，另一部分是網頁渲染過程。

### 瀏覽器 --> 伺服器

#### 1. 解析 URL：
URL 全名是 Uniform Resource Locator，中文是「統一資源定位符」，而他主要會由三部分組成，就以 https://www.google.com.tw/maps 這個網址來說：
通訊協定：https
伺服器主機名稱：www.google.com.tw ，可以放 domain name 或是 IP address 但通常是放 domain name
路徑：maps 特定網頁的路徑
#### 2. 解析 DNS ：
每個提供網站服務的伺服器都會有他自己獨一無二的 IP 位址，而當你輸入的是像 https://www.google.com.tw/maps 這種有意義的網址內容時，就需要有人來將英文組成的網址配對到他的 IP 位址。
#### 3. 建立 TCP 連線：
TCP 是 Transmission Control Protocol，中文是傳輸控制協定，他的作用簡單來說是確保資料傳送完整的一道關卡，其中會通過三次握手後才建立連線：
Client 端向伺服器發送請求，確認是否可以建立連線
伺服器端收到請求，並回應給 Client 端「收到請求！」
現在換Client 端回應給伺服器端說「收到消息！」
這樣一來一往一共三次後，確認雙方都能收到對方的訊息後，則代表雙方通訊成功，可以往下進行後續動作了！
#### 4. Client 端發送 HTTP 請求
此時通常瀏覽器Client 端會向伺服器發送 GET 請求，但除了 GET method外，也會遇到如 post / put / delete / patch 等請求形式。
#### 5. 伺服器端回應請求
若順利執行的話並收到正確回應後就能進到下個步驟，但如果此時出了問題，伺服器就會回傳狀態碼 (status code) ，其中可以看開頭的字了解問題方向：
2XX：伺服器有成功回應，例如 200
3XX：重新轉向，例如 301 (永久轉向)、302 (暫時轉向)
4XX：客户端錯誤回應，例如最常見的 404 Not Found（目前也最常遇到這個錯誤）
5XX：伺服器的問題，例如 500 Internal Server Error

接下來就是針對網頁必備的三項元素的渲染過程了，這部分除了基本執行流程外，還能延伸到 Critical Render Path （關鍵渲染路徑），透過優化讓整個網頁能渲染得更有效率，使用者體驗會更好！

### 瀏覽器解析渲染頁面

#### 6. 瀏覽器會讀取HTML 並開始解析，開始產生 DOM
DOM 文件物件模型 (Document Object Model)，DOM 背後用的是樹狀結構 (tree) 的資料結構，透過樹狀結構，能夠讓查找階層父子關係的 HTML 能夠更快速

#### 7. 當遇到 Header 標籤中的 CSS 時，就會開始解析 CSSDOM
CSSOM CSS 物件模型 (CSS Object Model)
CSS 物件模型其實和 DOM 的建構方式差不多，一樣是透過樹狀結構來讓網頁中的 CSS code能夠更快速地被建構以及查找，這也就是 CSS 有優先級順序的原因，當你先定義了 span 的樣式，此時他會在第二層就被觸發，而當 CSS 繼續往下查找時，就會覆蓋掉原先的設定，因此在階層上也要很注意層級關係。

#### 8. 繼續建構 DOM 及 CSSDOM
#### 9. 解析完讀到 <body> 上方的 <script> ，此時會透過 JavaScipt 去增修節點內
#### 10. 將 DOM 和 CSSOM 合併為 Render Tree，準備開始運算
#### 11. 接著計算畫面排版比例
#### 12. 最後刻出畫面細節