- DNS 決議:將域名決議成 IP 地址
- TCP 連接：TCP 三次握手
- 發送 HTTP 請求
- 服務器處理請求并回傳 HTTP 報文
- 瀏覽器決議渲染頁面
- 斷開連接：TCP 四次揮手
一、什么是URL？
URL（Uniform Resource Locator），統一資源定位符，用于定位互聯網上資源，俗稱網址，
scheme: // host.domain:port / path / filename ? abc = 123 # 456789
scheme - 定義因特網服務的型別，常見的協議有 http、https、ftp、file，
其中最常見的型別是 http，而 https 則是進行加密的網路傳輸，
host - 定義域主機（http 的默認主機是 www）
domain - 定義因特網域名，比如 baidu.com
port - 定義主機上的埠號（http 的默認埠號是 80）
path - 定義服務器上的路徑（如果省略，則檔案必須位于網站的根目錄中），
filename - 定義檔案/資源的名稱
query - 即查詢引數
fragment - 即 # 后的hash值，一般用來定位到某個位置
二、DNS域名決議
在瀏覽器輸入網址后，首先要經過域名決議，因為瀏覽器并不能直接通過域名找到對應的服務器，而是要通過 IP 地址，
DNS 是： 一個由分層的 DNS 服務器實作的分布式資料庫 一個使得主機能夠查詢分布式資料庫的應用層協議
-
什么是分布式？
這個世界上沒有一臺 DNS 服務器擁有因特網上所有主機的映射，每臺 DNS 只負責部分映射，
-
什么是層次？
DNS 服務器有 3 種型別：根 DNS 服務器、頂級域（Top-Level Domain, TLD）DNS 服務器和權威 DNS 服務器，它們的層次結構如下圖所示：
- IP 地址
IP 地址是指互聯網協議地址，是 IP Address 的縮寫，IP 地址是 IP 協議提供的一種統一的地址格式， 它為互聯網上的每一個網路和每一臺主機分配一個邏輯地址，以此來屏蔽物理地址的差異，
- 什么是域名決議
DNS 協議提供通過域名查找 IP 地址，或逆向從 IP 地址反查域名的服務， DNS 是一個網路服務器，我們的域名決議簡單來說就是在 DNS 上記錄一條資訊記錄，
- 瀏覽器如何通過域名去查詢 URL 對應的 IP 呢？
DNS域名決議分為遞回查詢和迭代查詢兩種方式，現一般為迭代查詢，
三、TCP三次握手
-
客戶端發送一個帶 SYN=1，Seq=X 的資料包到服務器埠
（第一次握手，由瀏覽器發起，告訴服務器我要發送請求了） -
服務器發回一個帶 SYN=1， ACK=X+1， Seq=Y 的回應包以示傳達確認資訊
（第二次握手，由服務器發起，告訴瀏覽器我準備接受了，你趕緊發送吧） -
客戶端再回傳一個帶 ACK=Y+1， Seq=Z 的資料包，代表“握手結束”
（第三次握手，由瀏覽器發送，告訴服務器，我馬上就發了，準備接受吧）
四、發送 HTTP 請求
TCP 三次握手結束后，開始發送 HTTP 請求報文，
HTTP是無連接的：無連接的含義是限制每次連接只處理一個請求，服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接，采用這種方式可以節省傳輸時間， 一個連接是由傳輸層來控制的，這從根本上不屬于HTTP的范圍，HTTP并不需要其底層的傳輸層協議是面向連接的，只需要它是可靠的，或不丟失訊息的（至少回傳錯誤），HTTP是可擴展的：在 HTTP/1.0 中出現的 HTTP headers 讓協議擴展變得非常容易，只要服務端和客戶端就新 headers 達成語意一致，新功能就可以被輕松加入進來，HTTP是無狀態：HTTP協議是無狀態協議，無狀態是指協議對于事務處理沒有記憶能力，缺少狀態意味著如果后續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連接傳送的資料量增大，另一方面，在服務器不需要先前資訊時它的應答就較快， 使用Cookies可以創建有狀態的會話，HTTP頭部資訊
根據不同背景關系，可將訊息頭分為：
1、General headers（通用標頭）: 同時適用于請求和回應訊息，但與最終訊息主體中傳輸的資料無關的訊息頭，
2、Request headers: 包含更多有關要獲取的資源或客戶端本身資訊的訊息頭，
3、Response headers: 包含有關回應的補充資訊，如其位置或服務器本身（名稱和版本等）的訊息頭，
4、Entity headers（物體標頭）: 包含有關物體主體的更多資訊，比如主體長(Content-Length)度或其MIME型別，
五、服務器處理請求并回傳 HTTP 報文
每臺服務器上都會安裝處理請求的應用——Web server，常見的web server產品有apache、nginx、IIS、Lighttpd等，
六、瀏覽器決議渲染頁面
用戶界面 (User Interface) － 包括地址欄、后退/前進按鈕、書簽目錄等，也就是你所看到的除了用來顯示你所請求頁面的主視窗之外的其他部分 瀏覽器引擎 (Browser Engine) － 用來查詢及操作渲染引擎的介面 渲染引擎 (Rendering Engine) － 用來顯示請求的內容，例如，如果請求內容為html，它負責決議html及css，并將決議后的結果顯示出來 網路 (Networking) － 用來完成網路呼叫，例如http請求，它具有平臺無關的介面，可以在不同平臺上作業 JS解釋器 (JS Interpreter) － 用來解釋執行JS代碼 UI后端 (UI Backend) － 用來繪制類似組合選擇框及對話框等基本組件，具有不特定于某個平臺的通用介面，底層使用作業系統的用戶介面 資料存盤 (DB Persistence) － 屬于持久層，瀏覽器需要在硬碟中保存類似cookie的各種資料，HTML5定義了web database技術，這是一種輕量級完整的客戶端存盤技術
1.多行程的瀏覽器
瀏覽器是多行程的，有一個主控行程，以及每一個tab頁面都會新開一個行程（某些情況下多個tab會合并行程）
行程可能包括主控行程，插件行程，GPU，tab頁（瀏覽器內核）等等
- Browser行程：瀏覽器的主行程（負責協調、主控），只有一個
- 第三方插件行程：每種型別的插件對應一個行程，僅當使用該插件時才創建
- GPU行程：最多一個，用于3D繪制
- 瀏覽器渲染行程（內核）：默認每個Tab頁面一個行程，互不影響，控制頁面渲染，腳本執行，事件處理等（有時候會優化，如多個空白tab會合并成一個行程）
2.多執行緒的瀏覽器內核
每一個tab頁面可以看作是瀏覽器內核行程，然后這個行程是多執行緒的，它有幾大類子執行緒：
- GUI執行緒
- JS引擎執行緒
- 事件觸發執行緒
- 定時器執行緒
- 網路請求執行緒
3.瀏覽器內核拿到內容后，渲染步驟大致可以分為以下幾步：
1. 決議HTML，構建DOM樹 2. 決議CSS，生成CSS規則樹 3. 合并DOM樹和CSS規則，生成render樹 4. 布局render樹（Layout/reflow），負責各元素尺寸、位置的計算 5. 繪制render樹（paint），繪制頁面像素資訊
（1） HTML決議，構建DOM
簡單的理解，這一步的流程是這樣的：瀏覽器決議HTML，構建DOM樹， 決議HTML到構建出DOM當然程序可以簡述如下：
Bytes → characters → tokens → nodes → DOM
1. Conversion轉換：瀏覽器將獲得的HTML內容（Bytes）基于他的編碼轉換為單個字符 2. Tokenizing分詞：瀏覽器按照HTML規范標準將這些字符轉換為不同的標記token，每個token都有自己獨特的含義以及規則集 3. Lexing詞法分析：分詞的結果是得到一堆的token，此時把他們轉換為物件，這些物件分別定義他們的屬性和規則 4. DOM構建：因為HTML標記定義的就是不同標簽之間的關系，這個關系就像是一個樹形結構一樣 例如：body物件的父節點就是HTML物件，然后段略p物件的父節點就是body物件
（2） 決議CSS，生成CSS規則樹
同理，CSS規則樹的生成也是類似，
Bytes → characters → tokens → nodes → CSSOM
（3）合并DOM樹和CSS規則，生成render樹
當DOM樹和CSSOM都有了后，就要開始構建渲染樹了
一般來說，渲染樹和DOM樹相對應的，但不是嚴格意義上的一一對應,因為有一些不可見的DOM元素不會插入到渲染樹中，如head這種不可見的標簽或者display: none等
（4）布局render樹（Layout/Reflow），負責各元素尺寸、位置的計算
布局：通過渲染樹中渲染物件的資訊，計算出每一個渲染物件的位置和尺寸，
（5）繪制render樹（Paint），繪制頁面像素資訊
繪制階段，系統會遍歷呈現樹，并呼叫呈現器的“paint”方法，將呈現器的內容顯示在螢屏上，
這張圖片中重要的四個步驟 1. 計算CSS樣式 2. 構建渲染樹 3. 布局，主要定位坐標和大小，是否換行，各種position overflow z-index屬性 4. 繪制，將影像繪制出來
- Layout，也稱為Reflow，即回流，一般意味著元素的內容、結構、位置或尺寸發生了變化，需要重新計算樣式和渲染樹
- Repaint，即重繪，意味著元素發生的改變只是影響了元素的一些外觀之類的時候（例如，背景色，邊框顏色，文字顏色等），此時只需要應用新樣式繪制這個元素就可以了
七、斷開連接
當資料傳送完畢，需要斷開 tcp 連接，此時發起 tcp 四次揮手，
- 發起方向被動方發送報文，Fin、Ack、Seq，表示已經沒有資料傳輸了，并進入 FIN_WAIT_1 狀態，
(第一次揮手：由瀏覽器發起的，發送給服務器，我請求報文發送完了，你準備關閉吧) - 被動方發送報文，Ack、Seq，表示同意關閉請求，此時主機發起方進入 FIN_WAIT_2 狀態，
(第二次揮手：由服務器發起的，告訴瀏覽器，我請求報文接受完了，我準備關閉了，你也準備吧) - 被動方向發起方發送報文段，Fin、Ack、Seq，請求關閉連接，并進入 LAST_ACK 狀態，
(第三次揮手：由服務器發起，告訴瀏覽器，我回應報文發送完了，你準備關閉吧) - 發起方向被動方發送報文段，Ack、Seq，然后進入等待 TIME_WAIT 狀態，被動方收到發起方的報文段以后關閉連接，發起方等待一定時間未收到回復，則正常關閉，
(第四次揮手：由瀏覽器發起，告訴服務器，我回應報文接受完了，我準備關閉了，你也準備吧)
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/472300.html
標籤：其他