瀏覽器工作原理

2022-05-10 11:34:08 字數 2810 閱讀 6481

輸入網域名稱,瀏覽器做簡單的篩選判斷

預設為http協議,https的話需要手動輸入

dns查詢,獲取ip位址

先查自己記憶體裡的dns cache

再查本地硬碟裡的host檔案

查詢dns服務

建立tcp/ip連線

傳送http請求

伺服器處理

瀏覽器收到返回,解析展示

我們在瀏覽器輸入**,其實就是要向伺服器請求我們想要的頁面內容,所有瀏覽器首先要確認的是網域名稱所對應的伺服器在**。將網域名稱解析成對應的伺服器ip位址這項工作,是由dns伺服器來完成的。

客戶端收到你輸入的網域名稱位址後,它首先去找本地的hosts檔案,檢查在該檔案中是否有相應的網域名稱、ip對應關係,如果有,則向其ip位址傳送請求,如果沒有,再去找dns伺服器。一般使用者很少去編輯修改hosts檔案。

瀏覽器客戶端向本地dns伺服器傳送乙個含有網域名稱的dns查詢報文。本地dns伺服器把查詢報文**到根dns伺服器,根dns伺服器注意到其com字尾,於是向本地dns伺服器返回comdns伺服器的ip位址。本地dns伺服器再次向comdns伺服器傳送查詢請求,comdns伺服器注意到其字尾並用負責該網域名稱的權威dns伺服器的ip位址作為回應。最後,本地dns伺服器將含有的ip位址的響應報文傳送給客戶端。

從客戶端到本地伺服器屬於遞迴查詢,而dns伺服器之間的互動屬於迭代查詢。 正常情況下,本地dns伺服器的快取中已有comdns伺服器的位址,因此請求根網域名稱伺服器這一步不是必需的。

費了一頓周折終於拿到伺服器ip了,下一步自然就是鏈結到該伺服器。對於客戶端與伺服器的tcp鏈結,必然要說的就是『三次握手』。

客戶端傳送乙個帶有syn標誌的資料報給服務端,服務端收到後,回傳乙個帶有syn/ack標誌的資料報以示傳達確認資訊,最後客戶端再回傳乙個帶ack標誌的資料報,代表握手結束,連線成功。

上圖也可以這麼理解:

客戶端:「你好,在家不,有你快遞。」

服務端:「在的,送來就行。」

客戶端:「好嘞。」

與伺服器建立了連線後,就可以向伺服器發起請求了。這裡我們先看下請求報文的結構(如下圖):

在瀏覽器中檢視報文首部(以google瀏覽器為例):

請求行包括請求方法、uri、http版本。首部字段傳遞重要資訊,包括請求首部字段、通用首部欄位和實體首部字段。我們可以從報文中看到發出的請求的具體資訊。具體每個首部欄位的作用,這裡不做過多闡述。

伺服器端收到請求後的由web伺服器(準確說應該是http伺服器)處理請求,諸如apache、ngnix、iis等。web伺服器解析使用者請求,知道了需要排程哪些資源檔案,再通過相應的這些資源檔案處理使用者請求和引數,並呼叫資料庫資訊,最後將結果通過web伺服器返回給瀏覽器客戶端。

在http裡,有請求就會有響應,哪怕是錯誤資訊。這裡我們同樣看下響應報文的組成結構:

在響應結果中都會有個乙個http狀態碼,比如我們熟知的200、301、404、500等。通過這個狀態碼我們可以知道伺服器端的處理是否正常,並能了解具體的錯誤。

狀態碼由3位數字和原因短語組成。根據首位數字,狀態碼可以分為五類:

為了避免伺服器與客戶端雙方的資源占用和損耗,當雙方沒有請求或響應傳遞時,任意一方都可以發起關閉請求。與建立tcp連線的3次握手類似,關閉tcp連線,需要4次握手。

上圖可以這麼理解:

客戶端:「兄弟,我這邊沒資料要傳了,咱關閉連線吧。」

服務端:「收到,我看看我這邊有木有資料了。」

服務端:「兄弟,我這邊也沒資料要傳你了,咱可以關閉連線了。」

客戶端:「好嘞。」

瀏覽器通過解析html,生成dom樹,解析css,生成css規則樹,然後通過dom樹和css規則樹生成渲染樹。渲染樹與dom樹不同,渲染樹中並沒有head、display為none等不必顯示的節點。

要注意的是,瀏覽器的解析過程並非是串連進行的,比如在解析css的同時,可以繼續載入解析html,但在解析執行js指令碼時,會停止解析後續html,這就會出現阻塞問題,關於js阻塞相關問題,這裡不過多闡述,後面會單獨開篇講解。

根據渲染樹布局,計算css樣式,即每個節點在頁面中的大小和位置等幾何資訊。html預設是流式布局的,css和js會打破這種布局,改變dom的外觀樣式以及大小和位置。這時就要提到兩個重要概念:replaint和reflow。

replaint:螢幕的一部分重畫,不影響整體布局,比如某個css的背景色變了,但元素的幾何尺寸和位置不變。

reflow: 意味著元件的幾何尺寸變了,我們需要重新驗證並計算渲染樹。是渲染樹的一部分或全部發生了變化。這就是reflow,或是layout。 所以我們應該儘量減少reflow和replaint,我想這也是為什麼現在很少有用table布局的原因之一。

最後瀏覽器繪製各個節點,將頁面展示給使用者。

瀏覽器工作原理

首先對上篇blog 進行乙個補充 以我做的 基於執行緒池和資料庫連線池的web 伺服器 為例,說說http 通訊的流程,大體分為三個階段 a 連線 伺服器通過乙個serversocket 類物件對8000 埠進行監聽,監聽到之後建立 連線,開啟乙個socket 虛擬檔案。b 請求 建立與建立sock...

瀏覽器工作原理

介紹 渲染引擎又叫排版引擎或者瀏覽器核心 主流的渲染引擎有 解析html構造dom樹 document object model,文件物件模型 dom是w3c組織推薦的處理可擴充套件置標語言的標準程式設計介面。構建渲染數,渲染數並不等同於dom數,因為像head標籤或者display none這樣的...

瀏覽器工作原理

關於渲染是否被loadrunner計入到響應時間 瀏覽器的主要元件包括 1.使用者介面 包括位址列 後退 前進按鈕 書籤目錄等,也就是你所看到的除了用來顯示你所請求頁面的主視窗之外的其他部分 2.瀏覽器引擎 用來查詢及操作渲染引擎的介面 3.渲染引擎 用來顯示請求的內容,例如,如果請求內容為html...