從輸入頁面地址到展現頁面信息都發生了些什麼？

好久之前理解過一個URL從在瀏覽器地址欄輸入，到呈現頁面都發生了什麼。前兩天碰到一個nginx反向代理的問題，又回想起這個流程，我想是對這個流程理解的還不夠透徹，因此特地抽出時間來總結一下。

廢話很少說先上圖

一個URL從在瀏覽器地址欄輸入，到呈現頁面經歷了：

1. DNS解析，查找域名服務器
2. TCP三次握手
3. 發送http請求
4. nginx反向代理
5. servlet處理請求，返回http請求信息
6. 關閉TCP鏈接，四次揮手
7. 瀏覽器根據返回內容渲染頁面

DNS解析

DNS解析就是使用你輸入的域名：www.kaola.com 去定位真正的ip地址

DNS解析是一個遞歸查詢的過程，具體步驟以下圖

1. 本地域名服務器查找有沒有www.kaola.com所對應的ip
2. 本地服務器未查找到，則去根域名服務器查找
3. 根域名服務器未找到相應ip，會返回一級域名服務器地址
4. 查找一級域名服務器
5. 一級域名服務器未找到相應ip，返回二級域名服務器地址
6. 查找二級域名服務器
7. 二級域名服務器查看本地name.conf，是否有www主機的記錄
8. 查到www主機的記錄，返回www主機的ip到二級域名服務器
9. 返回ip到本地域名服務器
10. 返回ip到瀏覽器

**第9步，本地域名服務器拿到ip之後，會存入本地DNS緩存。

DNS優化

• DNS緩存： 瀏覽器緩存，系統緩存，路由器緩存，IPS服務器緩存，根域名服務器緩存，頂級域名服務器緩存，主域名服務器緩存。經過緩存直接讀取域名相對應的ip，減去了繁瑣的查找ip的步驟，大大加快訪問速度。
• DNS負載均衡：使用CDN進行負載均衡，利用DNS的重定向技術，同步服務器運行狀況，而後根據該狀況及時適當調整調度策略，從而使得負載均衡能力大大提升。

HTTP請求

客戶端根據域名獲得相應ip之後開始發送http請求，HTTP請求分爲三個部分：TCP三次握手(圖一3)、http請求響應信息(圖一四、圖一6)、關閉TCP鏈接(圖一7)

TCP三次握手

在客戶端發送數據以前會發起tcp三次握手用以同步客戶端和服務端的序列號和確認號，並交換TCP窗口大小信息。tcp三次握手的過程以下：

1. 第一次握手：客戶端向服務端發送鏈接請求報文段，SYN和Seq，等待服務端確認（你在嗎？）
2. 第二次握手：服務端收到報文段確認後，向客戶端發送報文段。SYN、ACK和Seq（我在的！）
3. 第三次握手：客戶端收到服務器的報文段，向服務器發送ACK和Seq。（好的，我知道你在了。）

HTTP請求響應信息

TCP三次握手結束後，開始發送HTTP請求報文

http請求報文

TTP請求報文由請求行（request line）、請求頭部（header）、請求主體三個部分組成。以下圖所示：

1. 請求行包含：請求方法、URL、協議版本

• 請求方法包含8種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。
• URL即請求地址，由 <協議>：//<主機>：<端口>/<路徑>?<參數> 組成
• 協議版本即http版本號

2. 請求頭部包含請求的附加信息，由 名/值 對組成

3. 請求主體包含回車符、換行符和請求數據，並非全部請求都具備請求數據

http響應報文

http請求報文發送後，通過nginx服務器轉發（圖一5）、服務端servlet處理請求（圖一6）以後，響應信息會以響應報文的形式返回給客戶端。 （圖一5步驟後續補充）

TTP響應報文由響應行（request line）、響應頭部（header）、響應主體三個部分組成。以下圖所示：

1. 響應行包含：協議版本，狀態碼，狀態碼描述

狀態碼規則以下：

• 1xx：指示信息--表示請求已接收，繼續處理。
• 2xx：成功--表示請求已被成功接收、理解、接受。
• 3xx：重定向--要完成請求必須進行更進一步的操做。
• 4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現。
• 5xx：服務器端錯誤--服務器未能實現合法的請求。

2. 響應頭部包含響應報文的附加信息，由 名/值 對組成

3.響應主體包含回車符、換行符和響應返回數據，並非全部響應報文都有響應數據

關閉TCP鏈接，四次揮手

當數據傳送完畢，須要斷開tcp鏈接，此時發起tcp四次揮手

• 發起方向被動方發送報文，Fin、Ack、Seq，表示已經沒有數據傳輸了。並進入FIN_WAIT_1狀態。（嗨，我要走了）
• 被動方發送報文，Ack、Seq，表示贊成關閉請求。此時主機發起方進入FIN_WAIT_2狀態。（好的，準了）
• 被動方向發起方發送報文段，Fin、Ack、Seq，請求關閉鏈接。並進入LAST_ACK狀態。（我也要走啦！）
• 發起方向被動方發送報文段，Ack、Seq。而後進入等待TIME_WAIT狀態。被動方收到發起方的報文段之後關閉鏈接。發起方等待必定時間未收到回覆，則正常關閉。（好的，我也批准了……怎麼一直沒回音？好吧，那我真的走了。）

nginx反向代理

反向代理即指：未來自客戶端的請求轉發至內部網絡中的服務器進行處理。並將服務器的結果返回給客戶端。具體實現步驟以下圖：

• 客戶端發送請求到服務端的nginx服務器
• nginx服務器在緩存中查找請求內容，找到直接返回客戶端。
• nginx服務器未找到請求內容，則將請求代理至相應的服務器。
• 相應服務器處理請求並返回請求信息給nginx服務器，nginx服務器將請求信息返回給用戶。

nginx的優勢

• 保護服務器，外網只能訪問到反向代理服務器，對真正提供服務的服務器起到了保護的做用
• 節約ip資源
• 負載均衡，減小WEB服務器壓力，提升響應速度
• 解決ajax跨域問題
• 可對全部請求進行的統一控制；
• 等等……

瀏覽器解析渲染頁面

瀏覽器解析渲染頁面分爲一下五個步驟：

1. 根據HTML解析出DOM樹
2. 根據CSS解析生成CSS規則樹
3. 結合DOM樹和CSS規則樹，生成渲染樹
4. 根據渲染樹計算每個節點的信息
5. 根據計算好的信息繪製頁面

根據HTML解析DOM樹

• 根據HTML的內容，將標籤按照結構解析成爲DOM樹，DOM樹解析的過程是一個深度優先遍歷。即先構建當前節點的全部子節點，再構建下一個兄弟節點。
• 在讀取HTML文檔，構建DOM樹的過程當中，若遇到script標籤，則DOM樹的構建會暫停，直至腳本執行完畢。

根據CSS解析生成CSS規則樹

• 解析CSS規則樹時js 執行將暫停，直至CSS規則樹就緒。
• 瀏覽器在CSS規則樹生成以前不會進行渲染。

結合DOM樹和CSS規則樹，生成渲染樹

• DOM樹和CSS規則樹所有準備好了之後，瀏覽器纔會開始構建渲染樹。
• 精簡 CSS 並能夠加快CSS規則樹的構建，從而加快頁面相應速度。

根據渲染樹計算每個節點的信息（佈局）

• 佈局：經過渲染樹中渲染對象的信息，計算出每個渲染對象的位置和尺寸
• 迴流：在佈局完成後，發現了某個部分發生了變化影響了佈局，那就須要倒回去從新渲染。

根據計算好的信息繪製頁面

• 繪製階段，系統會遍歷呈現樹，並調用呈現器的「paint」方法，將呈現器的內容顯示在屏幕上。
• 重繪：某個元素的背景顏色，文字顏色等，不影響元素周圍或內部佈局的屬性，將只會引發瀏覽器的重繪。
• 迴流：某個元素的尺寸發生了變化，則需從新計算渲染樹，從新渲染。