聊聊Chrome：從輸入url到頁面展現

3000字長文預警~

第一關：Chrome的多進程架構：

併發與並行的區分

• 併發：擁有處理多任務的能力
• 並行：擁有同時處理多任務的能力

進程與線程的區分：

做爲科班生，先分享我在OS課堂上聽過的，印象最深的的說法：進程是資源分配的最小單位；線程是任務調度的最小單位。

• 線程必須依託於進程存在。同一進程內的線程共享進程資源。
• 進程內一個線程崩潰，則該進程崩潰。但不會影響到操做系統。
• 進程間經過IPC機制通訊：共享內存、socket、管道通訊（經過內核）

Chrome的多線程架構實現：

• 主進程×1：用戶交互、子進程管理、存儲管理。
• 網絡進程×1：資源加載
• GPU進程×1：3D渲染
• 渲染進程xn：負責文檔解析和子資源加載（每一個頁面都會建立一個）
• 插件進程×n：因爲插件不穩定，須要與其餘進程隔離開。

第二關：TCP/IP協議四層網絡模型

• OSI七層模型與TCP/IP四層模型對比

  個人理解是：OSI 是更偏重於規範性的體系結構，而 TCP/IP 則是目前網絡環境中的最佳實踐。

  實際上在本科的課本中是抽象爲五層模型來說的：

  應用層（應用層+表示層+會話層）=> 傳輸層=> 網絡層=> 鏈路層=> 物理層

  可見具體的分層方式並非關鍵，關鍵的是上圖中間列對應的重要功能是否獲得了實現。

• 數據包的流浪：

  這是每一個本科老師都很是擅長講的故事。當時聽課的我並無因這個故事而很快理解計算機網絡的基本運做，但時至今日，這個例子卻很好地指導了我對於計算機網絡的理解。

第三關：Domain Name System（DNS）

前置內容

• DNS的任務：對於給定的url查詢其對應的ip地址。

• DNS的查詢方式分爲兩種：迭代 / 遞歸；

  1. 瀏覽器向本地DNS服務器查詢通常採用遞歸方式；
  2. 本地DNS服務器向其餘服務器查詢通常採用迭代方式；
• DNS採用UDP協議進行查詢：快速高效。

查詢過程：

1. 瀏覽器將URL發送給本地DNS服務器（LDNS）；
2. 本地DNS服務器查找本地緩存，若存在該URL的記錄且還沒有過時，則返回該ip地址，DNS查詢過程結束；
3. 若本地DNS服務器不存在該URL對應的記錄，則迭代查找ip地址；
4. 本地DNS服務器首先向根域名服務器發送DNS報文，根域名服務器根據報文中請求的URL返回對應的頂級域名服務器地址
5. 本地DNS服務器向頂級域名服務器發送DNS報文，頂級域名服務器根據報文中請求的URL返回對應的權威服務器地址。
6. 重複以上過程直到獲得最終URL對應的IP地址。
7. 本地DNS服務器將該 [ip,url] 的記錄寫入緩存，將ip返回。

第四關：SSL協議 — HTTPS

HTTPS是什麼？

HTTPS （http secure）= HTTP + 混合加密 + 權威認證 + 完整性保證

因爲網絡中對於HTTPS的詳盡介紹很是豐富，此處不進行詳細地敘述了，直接奔向結論。

SSL協議運行機制

網絡上包含兩種說法（3個隨機數生成密鑰 or 2個隨機數生成密鑰），但大同小異，都採用了對稱加密+非對稱加密的方式：

1. Client向Server發送：加密套件列表 + 隨機數client_random
2. Server向Client返回：選中的加密套件 + 隨機數server_random + 數字證書（帶公鑰）
3. Client對數字證書進行合法性驗證，若合法：產生一個隨機數pre-master，並用該證書中的公鑰進行加密。將加密後的數據包發送給Server
4. Server使用私鑰對該數據包進行解密，獲得pre-master
5. 此時雙方利用已經協商好的加密套件對client_random+server_random+pre-master進行加密生成對稱密鑰。此後就可使用此對稱密鑰進行加密通信了

第五關：TCP協議

TCP協議特色

面向鏈接，可靠的傳輸層協議。

三次握手

• 三次握手的根本目的：確認我方和對方的發送、接收能力是否均正常

• 三次握手過程：

  Client與Server都明確自身的發送和接受能力正常，須要肯定對方的發送和接收能力。

  1. 第一次握手：Client向Server發送報文：SYN=1，seq=x；
  2. 第二次握手：Server接收到報文，向Client發送報文：ACK=1，ack=x+1，SYN=1，seq=y；

     Server確認Client的發送能力正常：Client發送了SYN報文。

  3. 第三次握手：Client接收到報文，向Server發送報文：ACK=1，seq=x+1，ack=y+1。

     Client確認Server的發送和接收能力正常：由於Server正確地接收並響應了Client。

     Server確認Client的接收能力正常：Server接收到了Client的ACK。

• 爲何不使用兩次握手：

  假設捨棄最後一次握手，則Server端沒法明確Client的接收能力是否正常。

四次揮手

• 四次握手的目的：保證雙方的數據均發送完畢，再關閉鏈接。

• 四次揮手過程：

  1. 第一次揮手：Client向Server發送FIN報文，代表Client不會再向Server發送數據：FIN=1,seq=x
  2. 第二次揮手：Server向Client發送ACK報文表示迴應：AKC=1,seq=y,ack=x+1

     期間Server能夠繼續向Client發送數據，此時處於TCP的半鏈接狀態；

     Client還須要繼續監聽Server發送來的報文。

  3. 第三次揮手：Server向Client發送FIN報文，代表Server不會再向Client發送數據：FIN=1,seq=z,ack=x+1
  4. 第四次揮手：Client向Server發送ACK報文表示迴應：ACK=1,seq=x+1,ack=z+1。同時等待2MSL，若此期間沒有接收到報文，則TCP鏈接順利斷開。
• 爲何是四次揮手而不是像創建鏈接時使用三次揮手？

  這是由於服務端在LISTEN（監聽）狀態下，收到創建鏈接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。而關閉鏈接時，當收到對方的FIN報文時，僅僅表示對方再也不發送數據了可是還能接收數據，己方是否如今關閉發送數據通道，須要上層應用來決定，所以，己方ACK和FIN通常都會分開發送。

• 爲何要等待2MSL？

  1. 第四次握手，客戶端發出ACK但並不會收到迴應，因此客戶端沒法確認本身的ACK可否順利到達，因此此時須要等待2MSL來給服務器重發FIN報文的機會。
  2. 客戶端發送ACK後的1MSL內，服務器的計時器也會到時，若是因爲某種緣由並無收到ACK，則會重發FIN報文。
  3. FIN文件會在1MSL內到達客戶端；此時客戶端的計時器還未清零，收到FIN後重啓2MSL計時器並回送ACK。

第五關：ARP協議

定義

• 地址解析協議，是經過解析ip地址來尋找MAC地址的一個在網絡協議包中很是重要的網絡傳輸協議。ARP屬於鏈路層協議。

工做過程

• 同一網段：廣播查詢 -> 單播迴應
• 不一樣網段：廣播查詢 -> 單播迴應 -> 網關中轉 -> 重複
• 參考：https://juejin.cn/post/6890167829984149518

從輸入URL到頁面展現發生了什麼？

瀏覽器側：

1. 用戶輸入url

   由瀏覽器判斷地址欄中的字符串是否符合url命名規則。若不符合則將該字符串交由搜索引擎處理；若合理則進入第二步。

2. 構建HTTP報文

   GET url HTTP/1.1

   主進程將該報文經過IPC交給網絡進程處理。

3. 查找瀏覽器內的文件緩存

   若瀏覽器曾經請求過該資源且資源並未過時，則網絡進程將緩存文件返回並攔截HTTP請求。若查找緩存未命中，則進入第4步。

4. DNS查詢

   詳情見第二關DNS；

   獲得的ip最終返回到瀏覽器的網絡進程中。

5. HTTP報文在傳輸層的處理完畢，準備下放到傳輸層（TCP）。

   Chrome瀏覽器有對於TCP鏈接的限制（同個域名最多維持6個TCP鏈接），若超過6個則須要放入TCP隊列中等待。

6. 若使用了HTTPS協議，在應用層HTTP和傳輸層TCP之間還要增長一層SSL層，保證鏈接安全

   詳情見上文HTTPS相關內容。

7. 進行TCP的三次握手鍊接：

   詳情見第四關TCP協議

8. 傳輸層TCP協議處理報文

   • TCP層將HTTP報文切分爲相等大小的報文段，併爲報文段增長TCP頭部。
   • 頭部添加序號：保證順序交付並在目的端從新組裝。
   • 頭部添加源端的端口號和目的端的端口號：確認數據包應該交付給目的端的哪一個應用程序（端口）。
   • 將報文段下放到網絡層

9. 網絡層IP協議處理報文段

   • 爲報文段增長IP頭部，添加源IP地址和目的IP地址。
   • 使用靜態路由算法或動態路由算法在網絡層進行路由

10. 鏈路層傳輸報文

    • 爲IP數據包增長以太網頭部，添加了MAC地址
    • 應用ARP協議進行鏈路層數據傳輸：詳情見第六關

服務端側：

1. 鏈路層和網絡層：

   一次除去以太網頭和IP頭部，提交到傳輸層

2. 傳輸層重組報文交給指定應用程序

   • TCP協議根據報文段頭部的序號保證數據的正確性和完整性，組成HTTP報文
   • 將HTTP報文交付給TCP頭部指定的目的端口號程序，上交到應用層

3. 客戶端對HTTP請求進行分析並構建響應報文

   1. 對於請求行中指定的URL，查看是否須要重定向。

      若須要重定向則返回301（永久重定向）或302（暫時重定向）狀態碼，並在響應報文首部Location字段寫入重定向的地址。

   2. 查看請求報文首部if-none-match字段對應的資源是否更新

      若爲更新返回304狀態碼，表示資源未更新。

   3. 查看是否須要通知瀏覽器進行緩存

      若須要瀏覽器更新，則設定cache-control：max-age=2000（以2000秒爲例）

4. 服務端應用層將HTTP報文發送回客戶端

   過程與上述無異。

5. 關閉HTTP鏈接

   查看是否處於長鏈接

   • HTTP1.0中經過Connection:keep-alive聲明長鏈接，不然默認使用短鏈接；HTTP1.1中默認長鏈接）
   • 若使用長鏈接則暫時不關閉HTTP鏈接；若使用短鏈接則進行HTTP四次揮手過程（詳情見第五關）

瀏覽器側：

1. 網絡進程接收到HTTP響應報文進行分析

   1. 若響應狀態碼爲301或302則從新構建HTTP請求報文，url爲響應報文的location對應的url
   2. 若響應碼爲304則直接使用瀏覽器的緩存資源
   3. 若狀態碼爲200，則請求成功。根據資源類型進行處理。

2. 根據content-Type處理相應數據

   • 若content-Type是html/text則是html頁面，經過IPC通知瀏覽器主線程準備渲染頁面。
   • 若content-Type是字節流類型，則使用下載管理器進行資源下載。

3. 渲染頁面並顯示

   這部份內容十分複雜（包括了瀏覽器的渲染過程和 Javascript的執行機制）

   請看下次博客分享~