瀏覽器輸入URL到頁面渲染完成，這個過程大致可分爲兩個階段：網絡通信和頁面渲染。
一、網絡通信
互聯網內各網絡間設備的通信遵循TCP/IP協議，利用TCP/IP協議進行網絡通信時，會通過分層與對方通信。數據傳輸的過程：由應用層產生數據後，經過傳輸層的分段處理（添加TCP或UDP包頭）、網絡層（添加IP地址信息）、數據鏈路層（封裝成MAC幀）、物理層傳輸電信號。
瀏覽器輸入URL：
1.1、瀏覽器根據域名查找IP地址
在瀏覽器中輸入域名 jd.com後，查找IP地址分爲兩個部分：客戶機本地的遞歸查詢和服務器的迭代查詢。
<1> 客戶機本地的遞歸查詢：
客戶機本地會依次去查找瀏覽器本身的域名緩存、客戶機系統自身的緩存、客戶機系統中的hosts文件，如果在當前的緩存中找到了對應的IP地址映射，則直接返回，如果在本地的緩存中都未找到對應的IP地址，則會去服務器查詢。
<2> 服務器的迭代查詢：
如果本地配置的服務器沒有緩存相域名的IP，那麼它就會去ISP運營商服務器去查找，如果也沒有，運營商的服務器會返回給本地服務器一個根域的服務器地址。然後去根服務器發起訪問，進行遞歸查詢，如果也沒有，就會去頂級域名的服務器去查找.com，然後再查找覺得jd.com的二級域名的服務器，以此類推就能找到相應的IP。如果仍然未找到，代表域名是錯誤的。
1.2、瀏覽器發送HTTP請求
找到IP地址後，則向對應IP地址的服務發送HTTP請求，HTTP請求消息包括請求起始行、請求頭和請求主體
1）請求消息起始行：
包括：請求方法、請求URI（請求地址報過URL和URN）、協議版本。
2）請求頭
包括：請求消息的專用頭（ Host、Accept、Origin、Referer、User-Agent、Accept-Encoding、Accept-Language）、請求消息通用頭（Connection、Cache-Control、Pragma、Date）、請求主體描述頭（Content-Length、Content-Type）
3）請求主體（Body）
客戶端想給服務器傳遞的消息。
1.3、TCP傳輸報文
TCP把應用層發送的用於網間傳輸的、用8位字節表示的數據流分成適當長度的報文段（報文段的長度不能超過MTU限制）。TCP爲了保證不發生丟包，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包按序接收。然後接收端實體對已成功收到的包發回一個響應的確認（ACK）；如果發送端實體在合理的往返延時（RTT）內未收到確認，那麼對應的數據包就被假設爲已丟失將會被進行重傳。TCP用一個校驗和函數來檢驗數據是否有錯誤；在發送和接收時都要計算校驗和。當TCP要發送數據時，需要通過三次握手協議建立連接。之後TCP把結果包傳給IP層由它通過網絡將包傳送給接收端實體的TCP層。
第一次握手：客戶端發送syn包到服務器，並進入SYN_SENT狀態，等待服務器的確認。 第二次握手：服務器收到syn包，必須確認客戶端的syn，同時自己也發送一個syn包，即SYN+ACK包，此時服務器進入SYN_RECV狀態。 第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK，此包發送完畢，客戶端與服務器端進入ESTABLISHED狀態，即TCP連接成功，完成三次握手。
1.4、IP協議查詢MAC地址並將數據發送的數據鏈路層
IP協議的作用是把TCP分割好的各種數據包傳送給接收方，要保證確實能傳到接收方還需要接收方的MAC地址，也就是物理地址。IP地址和MAC地址是一一對應的關係，一個網絡設備的IP地址可以更改，但是MAC地址一般是固定不變的。當通信的雙方不在同一個局域網時，需要多次中轉才能到達最終的目標，在中轉的過程中需要通過下一個中轉站的MAC地址來搜索下一個中轉目標。
ARP是地址解析協議，功能是根據IP地址獲取物理地址的一個TCP/IP 協議，即把IP地址轉化爲MAC地址。發送方首先檢查ARP緩存表，查找目的地址的IP與MAC地址。如果存在地址中，直接使用ARP協議解析，完成的封裝，傳輸數據。如果不存在目的地址的MAC地址，則發送一個ARP廣播（包含本主機的IP地址、MAC地址、目的主機的IP地址）。網絡中主機接收到廣播後，先檢查自己的IP地址，不符合丟棄該廣播，符合則把源主機的IP地址和MAC地址映射添加到本地ARP緩存中，並向源主機發出ARP應答（包含自己的IP地址和MAC地址）。源主機收到應答後，把目標主機的IP和MAC地址添加到緩存中，然後開始進行通信。
在找到對方的MAC地址後，將數據發送到數據鏈路層傳輸，此時客戶端發送階段結束。
1.5、服務器接收數據並相應請求返回相應的文件
接收端的服務器在鏈路層接收到數據，然後再一層層去掉添加的首部。這個過程包括在傳輸層通過TCP協議將分段的數據包重新組成原來的HTTP請求報文。然後服務器發送HTTP響應。HTTP的響應消息包括響應起始行、響應頭、響應主體。
1）響應起始行：
包括：協議版本、空格、響應狀態碼、空格、原因短句（描述給你的狀態碼的原因）。
2）響應頭
包括：響應消息的專用頭（ Server、Last-Modified、Content-Encoding）、響應消息通用頭（Connection、Cache-Control、Pragma、Date）、請求主體描述頭（Content-Length、Content-Type）
3）響應主體描述頭
客戶端想給服務器傳遞的消息。
二、頁面渲染
請求成功後，服務器返回給瀏覽器的文本信息，通常包括HTML、CSS、JS、圖片等文件。不同瀏覽器內核由於內核不同，懟頁面的渲染的過程也不相同。
webkit的渲染過程：
Gecko的渲染過程：
渲染的基本流程：HTML解析DOM Tree、CSS解析Style Rules、將兩者關聯生成Render Tree、Layout根據Render Tree計算每個節點的信息、Painting根據計算好的信息繪製整個頁面。
2.1、HTML解析
HTML Parser的任務是將HTML標籤解析成DOM Tree
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Document</title>
</head>
<body>
<p>p標籤的內容</p>
<div>div標籤的內容</div>
</body>
</html>
經過解析後的DOM Tree
2.2、CSS解析
CSS Parser將CSS解析成Style Rules，Style Rules也叫CSSOM（CSS Object Model），CSS Parser的作用就是將很多個CSS文件中的樣式合併解析出具體樹形結構。
2.3、js腳本處理、呈現樹
瀏覽器解析文檔時，當遇到script標籤的時候會立即解析腳本，停止解析文檔，因爲javascript可能會改動DOM和CSS，所以繼續解析會造成浪費。如果腳本是外部的，會等待下載完畢，再繼續解析文檔。腳本解析會將腳本中的DOM和CSS的地方分別解析出來，然後追加到DOM Tree和Style Rules上。
Render Tree的構建其實就是DOM Tree和CSSOM attach的過程。實際上就是一個計算好的樣式與HTML對應的Tree。
2.4、樣式計算
計算樣式是一個很複雜的過程，DOM中一個元素可以對應樣式表中的多個樣式，樣式表包含了所有的樣式：瀏覽器默認樣式、自定義樣式表、inline樣式表元素、HTML可視化屬性。爲了簡化樣式計算，Friefox還採用了另外兩種樹：規則樹和樣式上下文樹。WebKit 也有樣式對象，但它們不是保存在類似樣式上下文樹這樣的樹結構中，只是由 DOM 節點指向此類對象的相關樣式。
樣式上下文樹包含端值，要計算出這些值，應按照正確順序應用所有的匹配規則，並將其從邏輯值轉化爲具體的值。例如，如果邏輯值是屏幕大小的百分比，則需要換算成絕對的單位。規則樹使得節點之間可以共享這些值，以避免重複計算，還可以節約空間。所有匹配的規則都存儲在樹中。路徑中的底層節點擁有較高的優先級。規則樹包含了所有已知規則匹配的路徑。規則的存儲是延遲進行的。規則樹不會在開始的時候就爲所有的節點進行計算，而是隻有當某個節點樣式需要進行計算時，纔會向規則樹添加計算的路徑。樣式對象具有與每個可視化屬性一一對應的屬性（均爲CSS屬性但更爲通用）。如果某個屬性未由任何匹配規則所定義，那麼部分屬性就可由父代元素樣式對象繼承，其他屬性具有默認值。
2.5、佈局並繪製
創建渲染樹後，下一步就是佈局（Layout），或者叫回流（reflow，relayout），這個過程就是通過渲染樹中的渲染對象的信息，計算出每一個渲染對象的位置和尺寸，將其安置在瀏覽器窗口的正確位置，而有些時候我們會在文檔佈局完成後對DOM進行修改，這時候可能需要重新進行佈局，也可稱爲迴流，本質上還是一個佈局的過程，每一個渲染對象都有一個佈局或迴流的方法，實現其佈局或迴流。
在繪製的階段，系統會遍歷呈現樹，並調用呈現器的“paint”方法，將呈現器的內容顯示在屏幕上。繪製工作是使用用戶界面基礎組件完成。CSS2規範定義了繪製流程的順序，繪製的順序其實就是元素進入堆棧樣式上下文的順序，這些堆棧會從後往前繪製，因此這樣的順序會影響繪製。塊呈現器的堆棧順序如下：背景顏色、背景圖片、邊框、子代、輪廓。
經過上述一序列的請求和渲染，就形成了瀏覽器中所展示的頁面。
