從輸入URL到頁面加載完成的過程當中都發生了什麼事情？

從輸入URL到頁面加載完成的過程當中都發生了什麼事情？

1、初始準備（服務器端）

1.服務器啓動監聽服務,準備迎接來自客戶機的請求。服務器啓動操做系統—啓動http服務進程（apache or nginx or ..）--服務進程開始定位到服務器上的www文件夾，通常是位於/var/www。

2.服務器啓動一些附屬的模塊。例如php，或者，使用fastcgi方式鏈接到php的fpm管理進程。

3.向操做系統申請一個tcp鏈接

4.綁定在80端口

5.調用了accept函數

6.開始監聽。監聽着可能來自位於地球任何一個地方的請求，隨時準備作出響應

補充：典型的狀況下，機房裏面應該還有一個數據庫服務器，或許，還有一臺緩存服務器，若是對於流量巨大的網站，那麼動態腳本的解釋器可能還有單獨的物理機器來跑，若是是中小的站點，那麼，上述的各色服務，甚至均可能在一臺物理機上，無論怎麼說，他們作好了準備，靜候差遣。

2、查找服務器IP

1.輸入地址URL（Uniform Resource Identifier統一資源標識符）。鍵盤上的每一個按鍵都有不一樣的電頻，經過按鍵，電腦得知輸入的內容。在瀏覽器中輸入網址的時候，瀏覽器其實就已經在智能的匹配可能得url了，他會從歷史記錄，書籤等地方，找到已經輸入的字符串可能對應的url，而後給出智能提示。

2.把URL分割成幾個部分：協議、網絡地址、資源路徑。例如：http://www.guokr.com/question/554991/中<協議:http>從該計算機獲取資源的方式，常見的是HTTP、HTTPS、FTP、FILE，不一樣協議有不一樣的通信內容格式；<網絡地址: www.guokr.com>指示該鏈接網絡上哪一臺計算機，能夠是域名或者IP地址，能夠包括端口號。一般端口號不常見是由於大部分的都是使用默認端口，如HTTP默認端口80，HTTPS默認端口443。更多詳細內容請參考：同源策略和跨域問題；<資源路徑: /question/554991/>指示從服務器上獲取哪一項資源。咱們最多見的的協議是HTTP協議，除此以外還有加密的HTTPS協議、FTP協議、FILe協議等等。

3.DNS解析域名（根據域名找ip）

根據瀏覽器緩存->操做系統緩存（host）->路由器緩存->DNS服務器…..->全世界的頂級DNS上，逐級遞歸向上找,找到該域名對應的IP地址。DNS同時佔用UDP和TCP的53端口。客戶端進行DNS查詢時，通常使用UDP協議，而域名服務器之間進行區域傳輸，例如數據同步時則使用TCP協議。（此處可根據傳輸數據量來理解，其中UDP報文的最大長度爲512字節，而TCP則容許報文長度超過512字節。）

瀏覽器緩存：瀏覽器會記錄DNS一段時間，所以，只是第一個地方解析DNS請求；

操做系統緩存：若是在瀏覽器緩存中不包含這個記錄，則會使系統調用操做系統，獲取操做系統的記錄(保存最近的DNS查詢緩存)；

路由器緩存：若是上述兩個步驟均不能成功獲取DNS記錄，繼續搜索路由器緩存；

ISP緩存：若上述均失敗，繼續向ISP搜索。ISP(Internet Service Provider)，互聯網服務提供商，即電信運營商。

補充：

A.IP地址對應着網絡上一臺計算機，DNS服務器自己也有IP，你的網絡設置包含DNS服務器的IP。

B.若是有病毒把一些經常使用的域名，修改hosts文件，指向一些惡意的IP，那麼瀏覽器也會不加判斷的去鏈接。

C.在不一樣的地區或者不一樣的網絡（電信、聯通、移動）的狀況下，轉換後的IP地址極可能是不同的，這首先涉及到負載均衡的第一步。即，經過DNS解析域名時將你的訪問分配到不一樣的入口，同時儘量保證你所訪問的入口是全部入口中可能較快的一個。

3、客戶端和服務器進行鏈接

1.向肯定的IP和端口號，構造一個http請求

肯定端口號。端口號之於計算機就像窗口號之於銀行，一家銀行有多個窗口，每一個窗口都有個號碼，不一樣窗口能夠負責不一樣的服務。端口只是一個邏輯概念，和計算機硬件沒有關係。例如：www.guokr.com不包含端口號，http協議默認端口號是80。若是你輸入的url是http://www.guokr.com:8080/，那表示不使用默認的端口號，而使用指定的端口號8080。

發起請求方法。一個典型的http request header通常須要包括請求的方法，例如GET或者POST等，不經常使用的還有PUT和DELETE方法，更加不經常使用的還有HEAD和OPTION以及TRACE方法，通常的瀏覽器只能發起GET或者POST請求，

2.瀏覽器發起一條tcp鏈接(傳輸層)

開始三次握手的過程，tcp包被封裝到網絡層的ip包裏面，ip包再被封裝到數據鏈路層的數據幀結構中，再經過物理層的比特流送出去。這些分層的意義在於分工合做，數據鏈路層經過CSMA/CD協議保證了相鄰兩臺主機之間的數據報文傳遞，而網絡層的ip數據包經過不一樣子網之間的路由器的路由算法和路由轉發，保證了互聯網上兩臺遙遠主機之間的點對點的通信，不過這種傳輸是不可靠，因而可靠性就由傳輸層的tcp協議來保證。tcp經過慢開始，乘法減少等手段來進行流量控制和擁塞避免，同時提供了兩臺遙遠主機上進程到進程的通訊，最終保證了http的請求頭可以被遠方的服務器上正在監聽的http服務器進程收到。終於，數據包在跳與跳之間被拆了又封裝，在子網與子網之間被轉發了又轉發，最後進入了服務器的操做系統的緩衝區。服務器的操做系統由此給正在被阻塞住的accept函數一個返回，將他喚醒。

3.握手成功後，瀏覽器向服務器發送http請求，請求數據包。

若是資源路徑指示的資源不存在，服務器就會返回著名的404錯誤。

4.服務器接受並處理HTTP報文

請求進入服務器以後，服務器上的的http監聽進程會獲得這個請求，而後通常狀況下會啓動一個新的子進程去處理這個請求，同時父進程繼續監聽。

http服務器首先會查看重寫規則，而後若是是文件真實存在，例如一些圖片，或者css js等的靜態文件，就會直接把這個文件返回，若是是一個動態的請求，那麼會根據url重寫模塊的規則，把這個請求重寫到一個rest風格的url上，而後根據動態語言的腳本，來決定調用什麼類型的動態文件腳本解釋器來處理這個請求。

5.服務器構造併發送響應報文（傳輸過程略）

在視圖層把頁面準備好後，再從動態腳本解釋器送回到http服務器，由http服務器把這些正文加上一個響應頭，封裝成一個標準的http響應包，再經過TCP／IP協議，送回到客戶機瀏覽器。

前端開發人員會將併發加載的資源文件分佈在好多個域名下，變相的繞過瀏覽器的限制。即，瀏覽器在同一個域名下併發加載的資源數量是有限制的，例如ie6-7是兩個，ie8是6個，chrome各版本不大同樣，通常是4-6個。

4、渲染

當瀏覽器接收到報文，根據收到的資源的類型，將資源組織成屏幕上顯示的圖像，這個過程叫渲染。網頁渲染是瀏覽器最複雜、最核心的功能。

1.瀏覽器判斷狀態碼。

當請求的響應到達客戶端的瀏覽器後，響應到達瀏覽器以後，瀏覽器首先判斷狀態碼。

1xx：指示信息–表示請求已接收，繼續處理。

2xx：成功–表示請求已被成功接收、理解、接受，直接進入渲染流程。。

3xx：重定向–要完成請求必須進行更進一步的操做。即要去相應頭裏面找location域，根據這個location的指引，進行跳轉，這裏跳轉須要開啓一個跳轉計數器，是爲了不兩個或者多個頁面之間造成的循環的跳轉，當跳轉次數過多以後，瀏覽器會報錯，同時中止。

4xx：客戶端錯誤–請求有語法錯誤或請求沒法實現。

5xx：服務器端錯誤–服務器未能實現合法的請求。

2.當獲得一個正確的200響應以後，進行語言的編碼解析。

響應頭是一個ascii的標準字符集的文本，這個還好辦，可是響應的正文本質上就是一個字節流，對於這一坨字節流，瀏覽器要怎麼去處理呢，首先瀏覽器會去看響應頭裏面指定的encoding域，若是有了這個東西，那麼就按照指定的encoding去解析字符，若是沒有的話，那麼瀏覽器會使用一些比較智能的方式，去猜想和判斷這一坨字節流應該使用什麼字符集去解碼。相關的筆記能夠看這裏，瀏覽器對編碼的肯定

3.解析html構建dom樹

此時DOM樹只是一個樹形結構，沒規定每一個DOM節點的樣式。在html語言嵌套正常並且規範的狀況下，這種xml標記的語言是比較容易的可以構建出一棵dom樹出來的，固然，對於互聯網上大量的不規範的頁面，不一樣的瀏覽器應該有本身不一樣的容錯去處理。構建出來的dom本質上仍是一棵抽象的邏輯樹，

構建dom樹的過程當中，若是遇到了由script標籤包起來的js動態腳本代碼，那麼會把代碼送到js引擎裏面去跑，若是遇到了style標籤包圍起來的css代碼，也會保存下來，用於稍後的渲染。若是遇到了img等引用外部文件的標籤，那麼瀏覽器會根據指定的url再次發起一個新的http請求，去把這個文件拉取回來，值得一提的是，對於同一個域名下的下載過程來講，瀏覽器通常容許的併發請求是有限的，一般控制在兩個左右，因此若是有不少的圖片的話，通常出於優化的目的，都會把這些圖片使用一臺靜態文件的服務器來保存起來，負責響應，從而減小主服務器的壓力。

4.根據CSS生成CSSOM

5.構造render樹

將DOM和CSSOM整合造成RenderTree（渲染樹）。結構和DOM樹同樣，是樹形結構，但每一個節點中的樣式（位置、長、寬、高、顏色、背景圖片佈局等）被標識出來。render樹一旦構建完成，整個頁面也就準備好了。

6.佈局render樹

7.繪製render樹。注意，當遇到<script>時，會執行並阻塞渲染，由於js有權利改變dom結構時，會執行並阻塞渲染。

補充說明

下載頁面，構建dom樹，構建render樹這三個步驟，實際上並非嚴格的前後順序的，爲了加快速度，提升效率，讓用戶不要等那麼久，如今通常都並行的往前推動的，現代的瀏覽器都是一邊下載，下載到了一點數據就開始構建dom樹，也一邊開始構建render樹，構建了一點就顯示一點出來，這樣用戶看起來就不用等待那麼久了。

做者：MyNameIsAngela 連接：https://www.jianshu.com/p/8cbf8d74023c 來源：簡書 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。