很久以前理解過一個URL從在瀏覽器位址列輸入，到呈現頁面都發生了什麼。前兩天碰到一個nginx反向代理的問題，又回想起這個流程，我想是對這個流程理解的還不夠透徹，所以特意抽出時間來總結一下。
廢話不多說先上圖
一個URL從在瀏覽器位址列輸入，到呈現頁面經歷了：
- DNS解析，查詢域名伺服器
- TCP三次握手
- 傳送http請求
- nginx反向代理
- servlet處理請求，返回http請求資訊
- 關閉TCP連線，四次揮手
- 瀏覽器根據返回內容渲染頁面
DNS解析
DNS解析就是使用你輸入的域名：www.kaola.com 去定位真正的ip地址
DNS解析是一個遞迴查詢的過程，具體步驟如下圖
- 本地域名伺服器查詢有沒有www.kaola.com所對應的ip
- 本地伺服器未查詢到，則去根域名伺服器查詢
- 根域名伺服器未找到相應ip，會返回一級域名伺服器地址
- 查詢一級域名伺服器
- 一級域名伺服器未找到相應ip，返回二級域名伺服器地址
- 查詢二級域名伺服器
- 二級域名伺服器檢視本地name.conf，是否有www主機的記錄
- 查到www主機的記錄，返回www主機的ip到二級域名伺服器
- 返回ip到本地域名伺服器
- 返回ip到瀏覽器
**第9步，本地域名伺服器拿到ip以後，會存入本地DNS快取。
DNS優化
- DNS快取： 瀏覽器快取，系統快取，路由器快取，IPS伺服器快取，根域名伺服器快取，頂級域名伺服器快取，主域名伺服器快取。通過快取直接讀取域名相對應的ip，減去了繁瑣的查詢ip的步驟，大大加快訪問速度。
- DNS負載均衡：使用CDN進行負載均衡，利用DNS的重定向技術，同步伺服器執行情況，然後根據該情況及時適當調整排程策略，從而使得負載均衡能力大大提高。
HTTP請求
客戶端根據域名得到相應ip以後開始傳送http請求，HTTP請求分為三個部分：TCP三次握手(圖一3)、http請求響應資訊(圖一4、圖一6)、關閉TCP連線(圖一7)
TCP三次握手
在客戶端傳送資料之前會發起tcp三次握手用以同步客戶端和服務端的序列號和確認號，並交換TCP視窗大小資訊。tcp三次握手的過程如下：
- 第一次握手：客戶端向服務端傳送連線請求報文段，SYN和Seq，等待服務端確認（你在嗎？）
- 第二次握手：服務端收到報文段確認後，向客戶端傳送報文段。SYN、ACK和Seq（我在的！）
- 第三次握手：客戶端收到伺服器的報文段，向伺服器傳送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跨域問題
- 可對所有請求進行的統一控制；
- 等等……
瀏覽器解析渲染頁面
瀏覽器解析渲染頁面分為一下五個步驟：
- 根據HTML解析出DOM樹
- 根據CSS解析生成CSS規則樹
- 結合DOM樹和CSS規則樹，生成渲染樹
- 根據渲染樹計算每一個節點的資訊
- 根據計算好的資訊繪製頁面
根據HTML解析DOM樹
- 根據HTML的內容，將標籤按照結構解析成為DOM樹，DOM樹解析的過程是一個深度優先遍歷。即先構建當前節點的所有子節點，再構建下一個兄弟節點。
- 在讀取HTML文件，構建DOM樹的過程中，若遇到script標籤，則DOM樹的構建會暫停，直至指令碼執行完畢。
根據CSS解析生成CSS規則樹
- 解析CSS規則樹時js 執行將暫停，直至CSS規則樹就緒。
- 瀏覽器在CSS規則樹生成之前不會進行渲染。
結合DOM樹和CSS規則樹，生成渲染樹
- DOM樹和CSS規則樹全部準備好了以後，瀏覽器才會開始構建渲染樹。
- 精簡 CSS 並可以加快CSS規則樹的構建，從而加快頁面相應速度。
根據渲染樹計算每一個節點的資訊（佈局）
- 佈局：通過渲染樹中渲染物件的資訊，計算出每一個渲染物件的位置和尺寸
- 迴流：在佈局完成後，發現了某個部分發生了變化影響了佈局，那就需要倒回去重新渲染。
根據計算好的資訊繪製頁面
- 繪製階段，系統會遍歷呈現樹，並呼叫呈現器的“paint”方法，將呈現器的內容顯示在螢幕上。
- 重繪：某個元素的背景顏色，文字顏色等，不影響元素周圍或內部佈局的屬性，將只會引起瀏覽器的重繪。
- 迴流：某個元素的尺寸發生了變化，則需重新計算渲染樹，重新渲染。