PS：非原創！本質是隻是對學習過程中看的材料進行整理！

從URL到頁面渲染

1、瀏覽器的位址列輸入URL並按下回車。
2、瀏覽器查詢當前URL的DNS快取記錄。
3、DNS解析URL對應的伺服器的IP。
4、根據IP和伺服器建立TCP連線（三次握手）
5、客戶端傳送HTTP請求(Request)
6、伺服器處理請求，瀏覽器接收HTTP響應(Response)
7、渲染頁面，構建DOM樹。
8、關閉TCP連線（四次揮手）

一、DNS域名解析（URL域名->IP地址）

DNS：Domain Name System，即域名系統，是 應用層協議，用於將使用者提供的主機名解析為ip地址。
DNS伺服器使用 分散式叢集的工作方式

DNS為什麼不採用單點的集中式的設計方式：

在因特網上只使用一個DNS伺服器，該伺服器包含所有的對映，在這種集中式的設計中，客戶機直接將所有查詢請求發往單一的DNS伺服器，同時該DNS伺服器直接對所有查詢客戶機做出響應。

• 單點故障（嗝屁一個，全球著急）
• 通訊容量（上億臺主機發送的查詢DNS報文請求，包括但不限於所有的HTTP請求，電子郵件報文伺服器，TCP長連線服務）
• 遠距離的時間延遲（澳大利亞到紐約的舉例）
• 維護開銷大（因為所有的 主機名-ip對映 都要在一個服務站點更新）等問題

解析流程

域名只是IP地址的一個對映，域名解析的過程實際是將域名還原為IP地址的過程。

解析流程

• 1、使用者主機上執行著 DNS客戶端，就是我們的PC機或者手機客戶端執行著DNS客戶端了
• 2、瀏覽器將接收到的URL中抽取出 域名欄位，並將這個主機名傳送給 DNS客戶端
• 3、DNS客戶端 向 DNS伺服器端 傳送一份 查詢報文，報文中包含著要訪問的主機名欄位（中間包括一些列快取查詢以及分散式DNS叢集的工作）
• 4、該DNS客戶機最終會收到一份 回答報文，其中包含有該主機名對應的IP地址
• 5、一旦該瀏覽器收到來自DNS的IP地址，就可以向該IP地址定位的HTTP伺服器發起TCP連線

所有DNS請求和回答報文使用的 UDP資料報 經過 埠53 傳送

PS：為什麼使用UDP而不是TCP？

一次UDP名字伺服器交換可以短到兩個包：一個查詢包、一個響應包。

一次TCP交換則至少包含9個包：三次握手初始化TCP會話、一個查詢包、一個響應包以及四次分手的包交換。

考慮到效率原因，TCP連線的開銷大得，故採用UDP作為DNS的運輸層協議，這也將導致只有13個根域名伺服器的結果。

查詢方式

• 1、作業系統先檢查 本地hosts檔案 是否有這個網址的對映關係，如果有就呼叫這個IP地址對映，完成域名解析。
• 2、沒找到則會查詢 本地DNS解析器快取，如果查詢到則返回。
• 3、還是沒有找到則會查詢 本地DNS伺服器，如果查詢到則返回。
• 4、還沒找到
  • 轉發模式：本地DNS伺服器就會把請求轉發至上一級DNS伺服器，由上一級伺服器進行解析，上一級伺服器如果不能解析，或找根DNS或把轉請求轉至上上級，以此迴圈。
  • 非轉發模式：會去找13臺 根DNS伺服器，使用 迭代查詢 或 遞迴查詢

從 客戶端到本地DNS伺服器 是屬於 遞迴查詢，而 DNS伺服器之間 就是 迭代查詢。

• 遞迴查詢：返回的結果只有兩種：查詢成功、查詢失敗

• 迭代查詢：又稱作 重指引，返回的是 最佳的查詢點 或者 主機地址

DNS快取

DNS快取涉及將資料儲存在更靠近請求客戶端的位置，以便可以更早地解析DNS查詢，並且可以避免在DNS查詢鏈中進一步查詢，從而改善載入時間並減少頻寬/ CPU消耗。DNS資料可以快取在各種位置，每個位置將儲存DNS記錄一段時間，該時間由生存時間（TTL）決定。

• 瀏覽器DNS快取

  當用戶通過瀏覽器訪問某域名時，瀏覽器首先會在 瀏覽器快取 中查詢是否有該域名對應的IP地址

• 作業系統（OS）級DNS快取

  當瀏覽器快取中無域名對應IP則會自動檢查 使用者計算機系統Hosts檔案 DNS快取是否有該域名對應IP

• 路由器快取

  當瀏覽器及系統快取中均無域名對應IP則進入路由器快取中檢查，以上三步均為 客服端的DNS快取

• ISP（網際網路服務提供商）DNS快取

當在使用者客服端查詢不到域名對應IP地址，則將進入ISP DNS快取 中進行查詢。比如你用的是電信的網路，則會進入電信的DNS快取伺服器中進行查詢

二、客戶端和服務端通訊（HTTP協議、TCP協議、IP協議）

1、HTTP協議

2、TCP協議

(1) TCP三次握手

(2) TCP資料傳輸的可靠性

• 校驗和
• 序列號
• 確認應答
• 超時重傳
• 連線管理
• 流量控制
• 擁塞控制

(3) TCP四次揮手

3、UDP協議

三、頁面渲染

思考：為什麼需要三次握手和四次揮手

“這個問題的本質是，通道不可靠，但是通訊雙發需要就某個問題達成一致。而要解決這個問題, 無論你在訊息中包含什麼資訊, 三次通訊是理論上的最小值。所以三次握手不是TCP本身的要求，而是為了滿足 “在不可靠通道上可靠地傳輸資訊” 這一需求所導致的。三次達到了, 後面你想接著握手也好, 發資料也好, 跟進行可靠資訊傳輸的需求就沒關係了。因此,如果通道是可靠的, 即無論什麼時候發出訊息, 對方一定能收到, 或者你不關心是否要保證對方收到你的訊息, 那就能像UDP那樣直接傳送訊息就可以了。”

參考文章

• https://www.cnblogs.com/daijinxue/articles/6640153.html （從輸入url到頁面載入完成發生了什麼？）
• https://www.zhihu.com/question/23042131 （DNS解析的過程）
• https://github.com/jawil/blog/issues/14 （通俗大白話來理解TCP協議的三次握手和四次分手）
• https://www.zhihu.com/question/24853633 （TCP 為什麼是三次握手，而不是兩次或四次？）