前言
關於這方面知識有點欠缺，看到這經典考題卻不知道該怎麼說 ?
時常接觸網路卻不太了解背後運作流程是什麼 ! 但其實這內容很有深度
所以先不探討背後的深奧含意，先理解基本內容有點架構後，未來再回頭時也會有點相對概念，萬丈高樓平地起，現在開始研究吧~
整體流程
向瀏覽器輸入網址(域名) → DNS解析 → 取得IP → TCP三次握手(連接)
→ 發出HTTP請求 → Server端處理過程 → 瀏覽器解析並渲染
→ TCP四次握手(斷開連接)
先認識你最熟悉的網址吧 https://www.google.com.tw/
protocol傳輸協定: https
定義通訊協定類型負責決定請求傳輸的方式 ，例如 https 要另外加密
host網域名稱: www.google.com.tw
通常會是一組IP但考量不好記憶以這種方式呈現，會再以DNS方式去解析
DNS 是什麼 ?
DNS 中文就是域名系統，這是在我們整體網路的一部分缺一不可，而這域名就是我們常見的 http://www.wikipedia.org 的形式，透過這個域名換取對應的 IP 位置。
為什麼不直接給 IP 位址就好 ?
網路世界中有所謂的網路協定問題，TCP/IP 在第四版 IPv4 改為 32bits 為了方便人類去記憶，但誰會去無聊背 32bits ? 而且也背不起來 !!
解決方案
為了解決這狀況，我們一樣輸入域名，並交由電腦去找這域名對應的IP是什麼 ! 當獲取到 IP 後會返回給瀏覽器去執行訪問。
DNS 如何去找到 IP ?
範例 : https://www.google.com.tw/
當輸入域名後，先查看瀏覽器緩存是否有 ! (這會是一連串向上查詢的旅程)
如果沒有 ? ➜ 查詢你電腦作業系統緩存 ( 在你筆電搜尋 hosts 就會看到)
如果沒有 ? ➜ 查詢 DNS Server，如果他沒有會幫你去詢問其他人
如果沒有 ? ➜ 查詢 root Server，請問有 www.google.com.tw 嗎 ? 沒有
如果沒有 ? ➜ 查詢 .tw Server，請問有 www.google.com.tw 嗎 ? 沒有
如果沒有 ? ➜查詢 .com Server，請問有 www.google.com.tw 嗎 ? 沒有
如果沒有 ? ➜查詢 .google Server，請問有 www.google.com.tw 嗎 ? 有
DNS Server 它找到了
費盡千辛萬苦終於找到你要的 https://www.google.com.tw/ 對應的 IP 位置
於是它保存一份在他這裡當作緩存，未來其他人需要它就能快速回應 !
之後再將這份 IP 位置傳送給你瀏覽器，執行下一步驟。
三次握手過程
— — -生活案例 — — -
飛機 : 塔台你好，我是1012班機，請准許我降落 !
塔台: 1012喔~ 我查一下，好喔准許你降落 !
飛機: 感謝塔台，我現在降落
飛機: 轉向機場開始降落
— — 實際情況 — — -
客戶端: 傳送一包SYN
伺服器端: 收到SYN包，並回傳SYN/ACK
客戶端: 收到SYN/ACK包，並回傳ACK (此時握手結束)
客戶端: 發送正式HTTP請求
交握過程細節參考此處
TCP/IP四層架構
這過程需要做很多事情，於是分四層專注在自己的領域上處理某件事
應用層 (application)
傳輸層 (transport)
網路層 (internet)
網路存取層 (network)
參考此處
為什麼要使用 TCP而不是 UDP ? 差別在哪裡
以結論來說 TCP 比較可靠，UDP 感覺就像射後不理。
一. TCP簡介
設備之間溝通採用二進位的資訊交流，在傳輸時並不會一大包就丟出去，會切分許多小包裹方式進行傳輸，這裡可以說是封包 (packet)，每分封包都知道各自要去哪裡，但必須自行前往在無數個光纖中奔走，這個路程稱為路由器，在抵達目的地後進行合體，而 TCP會確定都到齊後才送出 !
------ TCP 特性------
1. 識別碼 : 為每個封包配上識別碼與序號，即使抵達後也能排序完成
2. 確認機制: 全部封包都抵達目的地後，如果封包遺失或未抵達都會重送
3. 錯誤檢查: 封包傳送過程可能有不可抗因素導致損毀，藉此機制有效檢查
4. 流量控制: 會有交通指揮的概念，如果某個路由塞車會另外指引方向
5. 三次握手: 藉由連接相互確認是否存在後，才發出HTTP請求。
二. UDP 本身 與 TCP 做比較
UDP 使用者資料協定，是屬於非可靠傳輸與 TCP 一樣在傳輸層，但不同的是並沒有所謂的三次握手連線確認的原則，也沒有攜帶識別碼做確認排序，即使封包遺失依然繼續傳送到目的地並直接前往不會等到全部到齊。
三. 結論
兩者差異頗大一個追求穩定與一個追求速度，瀏覽器本身更適合 TCP，
UDP更適合用在語音或是影片傳輸內容，還有線上遊戲 ! 可以接收丟失一點封包但並不會中斷服務是UDP的應用場景。
正式發出 HTTP請求
在實際送出請求時都會依照對應的method動詞來代表你想取得怎樣的資源 !
GET : 取資源
HEAD: 取資源但只取Header
POST: 提交指定資源
PUT: 取代指定資源
PATCH: 修改指定資源
DELETE: 刪除指定資源
OPTION: 指定資源的溝通方式
瀏覽器解析並渲染
依序建立 HTML DOM tree 與 CSS CSSOM tree，最後結合產生 Render tree
渲染過程如果先遇到 <script>會影響到 HTML 的建構，正常都會放到 <body> 的最後一行，但也有辦法另外放在<body>之前。
採用 <script> 專用的 async & defer
defer ， 這部分與 async 類似一樣在被背景拉資源 ， 但會等到 DOM 完成後才輪到它執行!
async ， 可以當作與 DOM 同步進行再背景拉資源完成後才開始執行並暫停 DOM 的建立 !
