原文："天龍八步"細說瀏覽器輸入URL後發生了什麼   慕課大神

本文摘要：
1.DNS域名解析；
2.建立TCP連接；
3.發送HTTP請求；
4.服務器處理請求；
5.返回響應結果；
6.關閉TCP連接；
7.瀏覽器解析HTML；
8.瀏覽器佈局渲染；
 

1.瀏覽器（客戶端）進行地址解析，補全域名，然後DNS域名解析；

    瀏覽器會對一些默認的東西進行補齊。例如：互聯網url默認端口號爲80，瀏覽器默認補齊功能會補齊協議http，有些還會直接在域名前面補上www。所以實際上，即使我們輸入的是imooc.com，然而實際訪問的卻是http://www.imooc.com

dns解析分爲以下幾個步驟：
1、先查看瀏覽器dns緩存中是否有域名對應的ip。
2、如果沒有，則查看操作系統dns緩存中是否有對應的ip（例如windows的hosts文件）。
3、依舊沒有就對本地區的dns服務器發起請求，
4、如果還是沒有，就直接到Root Server域名服務器請求解析。
<1>、DNS在進行區域傳輸的時候使用TCP協議，其它時候則使用UDP協議；

<2>、全球只有十三臺邏輯根服務器

2.通過ip尋址和arp，找到目標（服務器）地址，三次握手建立TCP連接；

    ip協議在第三層互聯網層（網絡層），arp協議在第四層網絡訪問層（鏈路層）。第2步獲取到了ip，此時直接通過ip尋址找到ip對應的服務器，然後通過arp協議找到服務器的mac地址。

ip尋址主要有兩種方式，一種是同一網段，一種是不同網段。要判斷兩個IP地址是不是在同一個網段，就將它們的IP地址分別與子網掩碼做與運算，得到的結果一網絡號，如果網絡號相同，就在同一子網，否則，不在同一子網。arp就是地址轉化協議，也就是把ip地址轉化爲mac地址。和dns很像，先查緩存，然後查路由器。

爲什麼有了ip地址，還要mac地址？這個問題很關鍵，就像是我有駕駛證了你非要讓我提供身份證。這個涉及一些歷史問題，因爲一開始沒有互聯網的時候就只有mac地址，還不存在ip地址。後來互聯網越來越大之後，發現mac地址找起來太麻煩，並且耗時也越來越久，就發明了ip地址。並且mac地址在一個局域網中還是很有用的，所以就兩個一起存在了。

第三步我們找到了目標ip，並獲得了服務器ip的mac地址。此時瀏覽器就會請求和服務器連接，用來傳輸數據。tcp 是穩定雙向面向連接的，斷開時也會分兩邊分別斷開。面向連接不是說tcp一個雙方一直開着的通道，而是維持一個連接的狀態，讓它看起來有連接。

 

上圖也可以這麼理解：

3.發送HTTP請求；等待響應

    瀏覽器會對請求進行包裝，包裝成請求報文。請求報文的格式如下：
起始行：如 GET / HTTP/1.0 （請求的方法 請求的URL 請求所使用的協議）
頭部信息：User-Agent Host等成對出現的值

主體：請求頭部和主體之間有一個回車換行。如果是get請求，則沒有主體部分，post請求有主體部分。

4.服務器處理請求；

 

    瀏覽器請求報文到達服務器之後，服務器接口會對請求報文進行處理，執行接口對應的代碼，處理完成後響應客戶端。由於http是無狀態的，正常情況下，客戶端收到響應後就會直接斷開連接，然後一次http事物就完成了。但是http1.0有一個keep-alive的請求字段，可以在一定時間內不斷開連接（有時時間甚至很長）。http1.1直接就默認開啓了keep-alive選項。這導致了一個後果是服務器已經處理完了請求，但是客戶端不會主動斷開連接，這就導致服務器資源一直被佔用。這時服務器就不得不自己主動斷開連接，而主動斷開連接的一方會出現TIME_WAIT，佔用連接池，這就是產生SYN Flood攻擊的原因。

5.返回響應結果；

 

    需要關注一個報文頭--accept。accept代表發送端（客戶端）希望接受的數據類型，這是瀏覽器自動封裝的請求頭。如果服務器返回的content-type是accept中的任何一個，瀏覽器都能解析，並直接展示在網頁上。如果服務器返回的content-type是其他類型，此時瀏覽器有三種處理狀態：
1、正常顯示。例如返回類型爲text/javascript，瀏覽器能直接處理並展示。
2、下載。例如返回類型爲application/octet-stream（二進制流，不知道下載文件類型），這種瀏覽器不能直接處理的，會被下載。
3、報錯。當我們返回一個字符串hello world，卻使用text/xml，格式時，瀏覽器不能正確解析，就會報錯，並把報錯信息呈現在網頁中。

瀏覽器能直接處理很多種格式，並直接呈現在網頁中，並不限於accept中規定的字段。

6.關閉TCP連接；

上圖可以這麼理解：
客戶端：「兄弟，我這邊沒數據要傳了，咱關閉連接吧。」
服務端：「收到，我看看我這邊有木有數據了。」
服務端：「兄弟，我這邊也沒數據要傳你了，咱可以關閉連接了。」
客戶端：「好嘞。」

7.瀏覽器解析HTML；

瀏覽器通過解析HTML，生成DOM樹，解析CSS，生成CSS規則樹，然後通過DOM樹和CSS規則樹生成渲染樹。渲染樹與DOM樹不同，渲染樹中並沒有head、display爲none等不必顯示的節點。

8.瀏覽器佈局渲染

    瀏覽器會根據相應的content-type字段對響應字符串進行解析。能夠解析併成功解析就顯示，能夠解析但解析錯誤就報錯，不能解析就下載。由於瀏覽器採用至上而下的方式解析，所以會先解析html，直到遇到外部樣式和外部腳本。這時會阻塞瀏覽器的解析，外部樣式和外部腳本（在沒有async、defer屬性下）會並行加載，但是外部樣式會阻塞外部腳本的執行，dom加載完畢，js腳本執行成功後dom樹構建完成（DOMContentLoaded），之後就加載dom中引用的圖片等靜態資源。
html解析->外部樣式、腳本加載->外部樣式執行->外部腳本執行->html繼續解析->dom樹構建完成->加載圖片->頁面加載完成
 

總結一下：運維人員需要處理頁面緩存、cdn及keep-alive引起的連接池佔用等問題；後端人員需要處理代碼邏輯、緩存、傳輸優化、報錯等問題；前段人員需要做好前端性能優化和配合運維、後端做好藉口調試，緩存處理等問題。所以無論是前端、後臺、運維都應該很清楚整個流程中的每一步，才能在配合時，得心應手，才能在出現問題時，快速準確的定位問題解決問題，才能在需要優化時，迅速完整的給出方案。

 

WEB服務器如何選擇 Apache or Nginx？

Apache擁有豐富的模塊組件支持，穩定性強，BUG少，動態內容處理強。

Nginx輕量級，佔用資源少，負載均衡，高併發處理強，靜態內容處理高效

 

程序員最核心的競爭力是什麼？

「看文檔」其實是最快的學習方法
「讀源碼」