前端開發者應該明白的瀏覽器工做原理

時間 2019-11-07

原文原文鏈接

原文地址：banggan.github.io/2019/02/20/…html

前言

做爲前端開發，咱們日常跟瀏覽器打交道的時間也是最多的。在前端面試中，一個較爲經典的問題：在瀏覽器地址中輸入url地址，敲回車，發生了什麼？瀏覽器究竟作了什麼？相信不少人腦海裏都會出現個大概的輪廓，但是一到細化具體的過程就答不上來。那麼，做爲前端開發者，應該從哪些方面延伸來回答這個問題呢？前端

瀏覽器工做流程

對於瀏覽器來講，當在地址欄輸入url地址，瀏覽器所作的事情就是把一個url變成一個在屏幕上顯示的網頁,大體的過程是這樣的： git

從HTTP請求回來，產生流式的數據，DOM的構建、CSS計算、渲染、繪製，都是儘量的流式處理前一步的產出，不須要等待上一步徹底接受纔開始處理，因此咱們在瀏覽網頁的時候，纔會逐步出現頁面。

瀏覽器接受url開啓一個網絡請求線程
瀏覽器發出一個完整的http請求
服務器接收請求到後臺接收請求
使用http請求請求頁面
把請求回來的html代碼解析成DOM樹
CSS的可視化格式模型解析
根據CSS屬性對元素進行渲染，獲得內存中的位圖
對位圖的合成
繪製頁面

瀏覽器接受url開啓網絡請求線程

第一點主要涉及的是瀏覽器的進程、線程模型以及JS的運行機制：github

多進程的瀏覽器

大多數瀏覽器是多進程的，有一個主控進程，以及每個tab頁面都會新開一個進程（某些狀況下多個tab會合並進程）進程可能包括主控進程，插件進程，GPU，tab頁（瀏覽器內核）等等。面試

Browser進程：瀏覽器的主進程（負責協調、主控），只有一個
第三方插件進程：每種類型的插件對應一個進程，僅當使用該插件時才建立
GPU進程：最多一個，用於3D繪製
瀏覽器渲染進程（內核）：默認每一個Tab頁面一個進程，互不影響，控制頁面渲染，腳本執行，事件處理等（有時候會優化，如多個空白tab會合併成一個進程）

多線程的瀏覽器內核

每個tab頁面能夠看做是瀏覽器內核進程，而後這個進程是多線程的，它有幾大類子線程：json

GUI線程
JS引擎線程
事件觸發線程
定時器線程
網絡請求線程

開啓網絡線程發出一個完整的http請求

該部分主要包括：dns查詢、tcp/ip請求構建、五層因特網等內容segmentfault

DNS查詢

若是輸入的是域名，須要進行dns解析成IP，大體流程：瀏覽器

若是瀏覽器有緩存，直接使用瀏覽器緩存，不然使用本機緩存，再沒有的話就是用host
若是本地沒有，就向dns域名服務器查詢（固然，中間可能還會通過路由，也有緩存等），查詢到對應的IP。

tcp/ip請求

這裏的tcp/ip請求須要瞭解3次握手規則創建鏈接以及斷開鏈接時的四次揮手,能夠參考以前的博客：blog.csdn.net/bangbanggan…緩存

五層因特網協議

其實這個概念挺難記全的，記不全不要緊，可是要有一個總體概念。其實就是一個概念：從客戶端發出http請求到服務器接收，中間會通過一系列的流程。簡括就是：從應用層的發送http請求，到傳輸層經過三次握手創建tcp/ip鏈接，再到網絡層的ip尋址，再到數據鏈路層的封裝成幀，最後到物理層的利用物理介質傳輸。固然，服務端的接收就是反過來的步驟。五層因特爾協議棧其實就是： 1.應用層(dns,http) 2.傳輸層(tcp,udp) 創建tcp鏈接（三次握手） 3.網絡層(IP,ARP) IP尋址 4.數據鏈路層(PPP) 5.物理層 OSI七層框架：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。表示層：主要處理兩個通訊系統中交換信息的表示方式，包括數據格式交換，數據加密與解密，數據壓縮與終端類型轉換等會話層：它具體管理不一樣用戶和進程之間的對話，如控制登錄和註銷過程服務器

網絡通信HTTP協議

HTTP協議是基於TCP協議出現的，在TCP的基礎上規定了Request-Response的模型，決定了通信必須由瀏覽器端發起的，首先來了解下HTTP協議的格式：

HTTP協議格式

HTTP協議大體能夠分紅如下部分：其中path是請求路徑、version是固定的字符串，依次介紹下面的每一個部分：

HTTP Method 請求方法

在requestline裏面的方法部分，表示HTTP的操做類型，常見的幾種請求方法以下：

GET：瀏覽器經過地址訪問頁面均屬於get請求
POST：常見的表單提交
HEAD ：跟get相似，區別在於只返回請求頭
PUT：表示添加資源
DELETE：表示刪除資源
CONNECT：多用於HTTPS和WebSocket
OPTIONS
TRACE

HTTP Status code狀態碼

常見的狀態碼有如下幾種：

1xx：臨時迴應
2xx：請求成功，如200
3xx：請求目標有變化，如301和302表示臨時和永久重定向，304表示客戶端沒有更新內容
4xx;請求錯誤，如403無權限，404訪問的資源不存在
5xx：服務端錯誤，如500服務端錯誤，503服務端暫時錯誤等

在前端開發中，最熟悉的系列無非是你們都喜歡的200請求成功的標誌，在面試中，問得較多的是304緩存問題和30一、302重定向的問題。

HTTP HEAD（HTTP頭）

HTTP頭能夠看作是一個鍵值對，在HTTP標準中，Request Header以下圖：

Response Header以下圖：

在實際的開發中，完整的列表能夠參考rfc2616標準。

HTTP Request Body

HTTP請求的body主要用於表單的提交，常見的body格式：

application/json
application/x-www-form-urlencoded:使用form標籤提交的html請求，默認產生
multipart/form-data:當有文件上傳時，使用的格式

HTTPS

HTTPS在HTTP的基礎上增長了兩個做用，一是肯定請求的目標服務端身份，二是保證傳輸的數據不會被篡改或者竊聽，該協議使用加密通道來傳輸HTTP內容，因此首先須要與服務端簡歷TLS加密通道。能夠在此處查看詳情：tools.ietf.org/html/rfc281…

HTTP2

HTTP2是HTTP1.1的升級版，有兩大改進：一是支持服務端推送，二是支持TCP連接複用：則使用同一個TCP連接來傳輸多個HTTP請求。詳情見:tools.ietf.org/html/rfc754…

構建DOM樹

當瀏覽器使用HTTP向服務端請求頁面後，那麼如何去解析請求回來的HTML代碼、構建DOM樹呢？

字符流如何解析成詞

首先瀏覽器讀取獲取的HTML，根據指定的文件編碼方式如UTF-8轉換爲字符流，再將字符串轉換爲詞Token。那什麼是詞？詞是編譯原理中的最小單元，如標籤開始、屬性、標籤結束、註釋、CDATA節點。Token會標識出當前Token的種類。舉個列子： <p class="a" >hello</p>

這裏就能夠拆分紅<p（p標籤的開始）、class="a"（屬性）、>（p標籤的結束）、hello（文本）、</p>（結束標籤）

構建DOM樹

接下來就是將詞變成DOM樹。在構建DOM樹時，是一邊生成Token一邊消耗Token來生成節點的。

<html>
<head>
    <title>Web page parsing</title>
</head>
<body>
    <div>
        <h1>Web page parsing</h1>
        <p>This is an example Web page.</p>
    </div>
</body>
</html>
複製代碼

構建的DOM樹：

構建CSSOM

在構建完DOM樹，當前的對象只包含節點和屬性，沒有任何樣式信息，那麼瀏覽器是如何給DOM樹添加CSS屬性呢？咱們知道瀏覽器是流式的處理整個過程，咱們拿到DOM樹構造好的元素，依次去檢查他匹配的規則，再根據規則的優先級，作覆蓋和調整。

構建渲染樹

當CSSOM樹和DOM樹都獲得以後，將兩個樹進行合併就獲得了渲染樹：

佈局與繪製

當瀏覽器生成渲染樹之後，就會根據渲染樹來進行佈局。在這個過程當中，每個元素都要要弄清楚各個節點在頁面中的確切位置和大小，把對應的盒變爲相應的位圖。一個元素可能對應多個盒（如內聯元素，可能被分紅多行）每個盒都對應着一個位圖。合成把部分位圖合成變成合成層。最終的繪製過程就是把位圖合成層繪製到屏幕上。這裏提一個常見的問題，重繪和迴流？具體的相關知識參考：segmentfault.com/a/119000001…