瀏覽器輸入URL回車會經歷什麼（最全）

瀏覽器輸入URL會經歷什麼

總體流程

1. 瀏覽器查找域名的IP地址 DNS
2. 瀏覽器與服務器進行TCP鏈接 3次握手
3. 瀏覽器經過http協議發送請求，請求數據包
4. 有些服務器會作永久重定向響應（爲了負載均衡或者導入流量）
5. 瀏覽器跟蹤重定向地址
6. 服務器處理請求
7. 服務器返回HTML響應（200）
8. 瀏覽器顯示頁面（數據渲染）
9. 瀏覽器發送獲取嵌入在HTML的其餘內容（樣式文件、圖片url）
10. 釋放TCP鏈接

包含知識點

1、瀏覽器的主要組件爲：

一、用戶界面 - 包括地址欄、前進/後退按鈕、書籤菜單等。除了瀏覽器主窗口顯示的您請求的頁面外，其餘顯示的各個部分都屬於用戶界面。
二、瀏覽器引擎 - 在用戶界面和呈現引擎之間傳送指令。
三、呈現引擎 - 負責顯示請求的內容。若是請求的內容是 HTML，它就負責解析 HTML 和 CSS 內容，並將解析後的內容顯示在屏幕上。
四、網絡 - 用於網絡調用，好比 HTTP 請求。其接口與平臺無關，併爲全部平臺提供底層實現。
五、用戶界面後端 - 用於繪製基本的窗口小部件，好比組合框和窗口。其公開了與平臺無關的通用接口，而在底層使用操做系統的用戶界面方法。
六、JavaScript 解釋器。用於解析和執行 JavaScript 代碼。
七、數據存儲。這是持久層。瀏覽器須要在硬盤上保存各類數據，例如 Cookie。新的 HTML 規範 (HTML5) 定義了「網絡數據庫」，這是一個完整（可是輕便）的瀏覽器內數據庫。

2、解析域名過程（包括DNS）

拿URL爲www.cnblogs.com舉例

一、Chrome瀏覽器會首先搜索瀏覽器的DNS緩存（緩存時間比較短，TTL默認是1000，且只能容納1000條緩存），看自身的緩存中是否有www.cnblogs.com對應的條目，並且沒有過時，若是有且沒有過時則解析到此結束。

二、Chrome搜索操做系統的DNS緩存,若是找到且沒有過時則中止搜索解析到此結束。

三、若是在Windows系統的DNS緩存也沒有找到，那麼嘗試讀取hosts文件（位於C:WindowsSystem32driversetc），看看這裏面有沒有該域名對應的IP地址，若是有則解析成功。

四、若是在hosts文件中也沒有找到對應的條目，瀏覽器就會發起一個DNS的系統調用，就會向本地配置的首選DNS服務器（通常是電信運營商提供的）發起域名解析請求（經過的是UDP協議向DNS的53端口發起請求，這個請求是遞歸的請求，也就是運營商的DNS服務器必須得提供給咱們該域名的IP地址）
4.一、運營商的DNS服務器首先查找自身的緩存，找到對應的條目，且沒有過時，則解析成功。若是沒有找到對應的條目，則有運營商的DNS代咱們的瀏覽器發起迭代DNS解析請求，
4.二、它首先是會找根域的DNS的IP 地址（這個DNS服務器都內置13臺根域的DNS的IP地址），找到根域的DNS地址，就會向其發起請求（請問www.cnblogs.com這個域名的 IP地址是多少啊？），根域發現這是一個頂級域com域的一個域名，
4.三、因而運營商的DNS就獲得了com域的IP地址，又向com域的IP地址發起了請求（請問www.cnblogs.com這個域名的IP 地址是多少?）,
4.四、因而運營商的DNS又向www.cnblogs.com這個域名的DNS地址（這個通常 就是由域名註冊商提供的，像萬網，新網等）發起請求（請問www.cnblogs.com這個域名的IP地址是多少？），
4.五、這個時候cnblogs.com 域的DNS服務器一查，果然在我這裏，因而就把找到的結果發送給運營商的DNS服務器，這個時候運營商的DNS服務器就拿到了 www.cnblogs.com這個域名對應的IP地址，並返回給Windows系統內核，內核又把結果返回給瀏覽器，終於瀏覽器拿到了 www.cnblogs.com對應的IP地址，該進行一步的動做了。
4.六、通常狀況下是不會進行如下步驟的，若是通過以上的4個步驟，尚未解析成功，那麼會繼續。操做系統就會查找NetBIOS name Cache（NetBIOS名稱緩存，就存在客戶端電腦中的），那這個緩存有什麼東西呢？凡是最近一段時間內和我成功通信的計算機的計算機名和Ip地址， 就都會存在這個緩存裏面。什麼狀況下該步能解析成功呢？就是該名稱正好是幾分鐘前和我成功通訊過，那麼這一步就能夠成功解析。
4.七、若是第5步也沒有成功，那會查詢WINS 服務器（是NETBIOS名稱和IP地址對應的服務器）
4.八、若是第6步也沒有查詢成功，那麼客戶端就要進行廣播查找
4.九、若是第7步也沒有成功，那麼客戶端就讀取LMHOSTS文件（和HOSTS文件同一個目錄下，寫法也同樣）
若是第八步尚未解析成功，那麼此次解析失敗，那就沒法跟目標計算機進行通訊。只要這八步中有一步能夠解析成功，那就能夠成功和目標計算機進行通訊。

3、TCP三次握手

一、解析出IP地址後，根據IP地址和默認端口80和服務器創建鏈接
瀏覽器發出讀取文件（URL中域名後邊部分對應的文件）的HTTP請求，該請求報文做爲TCP三次握手的第三個報文的數據發送給服務器
服務器對瀏覽器的請求做出響應，並把對應的html文本發送給瀏覽器
釋放TCP鏈接（四次揮手斷開鏈接）
瀏覽器解析該HTML文本並顯示內容

二、TCP是主機對主機層的傳輸控制協議，提供可靠的鏈接服務，採用三次握手確認創建一個鏈接:
位碼即tcp標誌位,有6種表示:

SYN(synchronous創建鏈接)
ACK(acknowledgement 表示響應、確認)
PSH(push表示有DATA數據傳輸)
FIN(finish關閉鏈接)
RST(reset表示鏈接重置)
URG(urgent緊急指針字段值有效)

2.一、第一次握手：客戶端發送syn包(syn=x)到服務器，並進入SYN_SEND狀態，等待服務器確認；
2.二、第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時本身也發送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
2.三、第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=y+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
另外：握手過程當中傳送的包裏不包含數據，三次握手完畢後，客戶端與服務器才正式開始傳送數據。理想狀態下，TCP鏈接一旦創建，在通訊雙方中的任何一方主動關閉鏈接以前，TCP 鏈接都將被一直保持下去。
三、四次揮手
3.一、第一次揮手：主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的數據傳送，也就是主動關閉方告訴被動關閉方：我已經不會再給你發數據了(固然，在fin包以前發送出去的數據，若是沒有收到對應的ack確認報文，主動關閉方依然會重發這些數據)，可是，此時主動關閉方還能夠接受數據。
3.二、第二次揮手：被動關閉方收到FIN包後，發送一個ACK給對方，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號）。
3.三、第三次揮手：被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的數據傳送，也就是告訴主動關閉方，個人數據也發送完了，不會再給你發數據了。
第四次揮手：主動關閉方收到FIN後，發送一個ACK給被動關閉方，確認序號爲收到序號+1，至此，完成四次揮手。

4、用到的協議及其做用

一、所涉及的協議

1.一、域名解析用到DNS協議
DNS服務器是基於UDP的，所以會用到UDP協議
獲得IP地址後，瀏覽器會與服務器創建HTTP鏈接，用到HTTP協議
1.二、http協議生成GET請求報文，將該報文傳給TCP層處理，用到了TCP協議
1.三、若是用到了HTTPS協議還會對HTTP協議內容進行加密
TCP層如有須要會對HTTP數據報分片，分片依據路徑MTU和MSS
1.四、TCP的數據報會發送給IP層，用到IP協議
1.五、IP層經過路由選擇，將數據發送給目的端口
以太網協議須要知道目的IP的物理地址，須要用到ARP協議

二、協議所處層級

2.一、DNS協議，HTTP協議，HTTPS協議屬於應用層
應用層是體系結構中的最高層。應用層肯定進程之間通訊的性質知足用戶的須要。這裏所說的進程就是指正在運行的程序。應用層不只須要提供應用進程須要的信息交換，並且還要做爲相互做用的應用進程的用戶代理，來完成一些爲進行語義上有意義的交換所必須的功能。
2.二、TCP/UDP屬於傳輸層
傳輸層的任務就是負責主機中兩個進程間的通訊。因特網的傳輸層可以使用兩種不一樣的協議；即面向鏈接的傳輸控制協議TCP和無鏈接的用戶數據報協議UDP。面向鏈接的服務可以提供可靠的交付，兩種方式都各有其優勢
2.三、IP協議和ARP協議屬於網絡層
網絡層負責爲分組交換網上的不一樣主機提供通訊。在發送數據時，網絡層將傳輸層產生的報文段或用戶數據報封裝成分組或者包進行傳送。在TCP/IP體系中，分組也叫做IP數據報。網絡層的另外一個任務就是選擇合適的路由，使源主機傳輸層傳下來的分組可以交付到目的主機。
2.四、數據鏈路層
當發送數據時，數據鏈路層的任務是將在網絡層交下來的IP數據報組裝成幀，在兩個相鄰節點間的鏈路上傳送以幀爲單位的數據。每一幀包括數據和必要的控制信息（如同步信息、地址信息、差錯控制以及流量控制等信息）。控制信息使接收端可以知道一個幀從那個比特開始到那個比特結束。控制信息還使接收端可以檢測到所收到的幀中有沒有差錯。
2.五、物理層
物理層的任務就是透明的傳送比特流。在物理層上所傳輸的數據的單位是比特。傳遞信息所利用的一些物理媒介，如雙絞線、同軸電纜、光纜等，並非在物理層以內而是在物理層的下面。所以也有人把物理媒體當作第0層。

5、http狀態碼

5.一、2XX成功
   1. 200 OK
   表示從客戶端發來的請求在服務器被正常處理了。
   2. 204 no content
   表示從客戶端發來的請求在服務器被正常處理了，但在返回的響應報文中不含實體的主體部分。
   3. 206 partial content
   表示客戶端進行了範圍請求，而服務器成功執行了這部分的GET請求。

   5.二、3XX重定向
   1. 301 moved permanently
   永久性重定向。該狀態碼錶示請求的資源已被分配了新的URI，之後應使用資源如今所指的URI。也就是說，若是已經把資源對應的URI保存爲書籤了，這時應按Location首部字段提示的URI從新保存。
   以下方給出的請求URI，當指定資源路徑的最後忘記添加斜槓「/」，就會產生301狀態碼
   http://example.com/sample
   2. 302 found
   臨時性重定向。該狀態碼錶示請求的資源已被分配了新的URI，但願用戶（本次）能使用新的URI訪問。
   與301的區別：302表明的資源不是被永久移動，只是臨時性質的，已移動的資源對應的URI未來還有可能發生改變。
   如用戶把URI保存成書籤，但不會像301出現時那樣去更新書籤，而是仍舊保留返回302的頁面對應的URI。
   3. 303 see other
   該狀態碼錶示因爲請求對應的資源存在着另外一個URI，應使用GET方法定向獲取請求的資源。
   與302的區別：303明確表示客戶端應採用GET方法獲取資源
   4. 304 not modified
   該狀態碼錶示客戶端發送附帶條件的請求時，服務器端資源已找到，但未符合條件請求。304返回時，不包含任何響應的主體部分。
   304雖然被劃分在3XX類別中，可是和重定向沒有關係。
   5. 307 temporary rediect
   臨時重定向。該狀態碼與302有着相同的含義，但307會遵守瀏覽器標準，不會從POST變成GET。對於處理響應時的行爲，每種瀏覽器有可能出現不一樣的狀況。
   
   5.三、4XX客戶端錯誤
   1. 400 bad request
   該狀態碼錶示請求報文中存在語法錯誤。當錯誤發生時，需修改請求的內容後再次發送請求。
   2. 401 unauthorized
   該狀態碼錶示發送的請求須要有經過HTTP認證（BASIC認證、DIGEST認證）的認證信息。另外，若以前已進行過1次請求，則表示用戶認證失敗。
   返回含有401的響應必須包含一個適用於被請求資源的WWWAuthenticate首部用以質詢（challenge）用戶信息。當瀏覽器初次接收到401響應，會彈出認證用的對話窗口。
   3. 403 forbidden
   該狀態碼代表對請求資源的訪問被服務器拒絕了
   4. 404 not found
   該狀態碼代表服務器上沒法找到請求的資源。除此以外，也能夠在服務器端拒絕請求且不想說明理由時使用。

   5.四、5XX 服務器錯誤
   1. 500 internal server error
   該狀態碼代表服務器端在執行請求時發生了錯誤。也有多是Web應用存在的bug或某些臨時的故障。
   2. 503 service unavailable
   該狀態碼代表服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。若是事先得知解除以上情況須要的時間，最好寫入RetryAfter首部字段再返回給客戶端。

6、http請求有幾種

1：GET
 請求指定的頁面信息，並返回實體主體。
2：HEAD
相似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
3：POST
向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。
4：PUT
從客戶端向服務器傳送的數據取代指定的文檔的內容。
5：DELETE
請求服務器刪除指定的頁面。
6：CONNECT
HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。
7：OPTIONS
容許客戶端查看服務器的性能。
8：TRACE
回顯服務器收到的請求，主要用於測試或診斷。
9：PATCH
實體中包含一個表，表中說明與該URI所表示的原內容的區別。
10：MOVE
請求服務器將指定的頁面移至另外一個網絡地址。
11：COPY
請求服務器將指定的頁面拷貝至另外一個網絡地址。
12：LINK
請求服務器創建連接關係。
13：UNLINK
斷開連接關係。
14：WRAPPED
容許客戶端發送通過封裝的請求。
15：Extension-mothed
在不改動協議的前提下，可增長另外的方法

7、get和post請求區別

7.一、GET提交的數據會放在URL以後，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中.
7.二、GET提交的數據大小有限制（由於瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制.
7.三、GET方式須要使用Request.QueryString來取得變量的值，而POST方式經過Request.Form來獲取變量的值，也就是說Get是經過地址欄來傳值，而Post是經過提交表單來傳值。
7.四、GET方式提交數據，會帶來安全問題，好比一個登陸頁面，經過GET方式提交數據時，用戶名和密碼將出如今URL上，若是頁面能夠被緩存或者其餘人能夠訪問這臺機器，就能夠從歷史記錄得到該用戶的帳號和密碼.
7.五、多數瀏覽器對於POST採用兩階段發送數據的，先發送請求頭，再發送請求體，即便參數再少再短，也會被分紅兩個步驟來發送（相對於GET），也就是第一步發送header數據，第二步再發送body部分。HTTP是應用層的協議，而在傳輸層有些狀況TCP會出現兩次連結的過程，HTTP協議自己不保存狀態信息，一次請求一次響應。對於TCP而言，通訊次數越多反而靠性越低，能在一次連結中傳輸完須要的消息是最可靠的，儘可能使用GET請求來減小網絡耗時。若是通訊時間增長，這段時間客戶端與服務器端一直保持鏈接狀態，在服務器側負載可能會增長，可靠性會降低。

8、瀏覽器解析html

8.一、總體流程

1. 解析html
2. 構建dom樹
3. 處理CSS標記，構成層疊樣式表模型CSSOM(CSS Object Model)。
4. dom樹結合cssOM，構建渲染樹
5. 佈局
6. 繪製

8.二、注意點：

一、解析html和構建dom樹是同步進行的，這個過程就是逐行解析代碼，包括html標籤和js動態生成的標籤，最終生成dom樹。　　　　
二、構建渲染樹，就是把css文件和style標籤的中的內容，結合dom樹的模型，構建一個渲染樹，寫到內存，等待進一步生成界面。呈現樹必定依賴dom樹， 呈現節點必定會有對應的dom節點，可是dom節點不必定會有對應的呈現節點，好比，被隱藏的一個div。　　　　
三、佈局，這一步就是結合呈現樹，把dom節點的大小、位置計算出來。雖然呈現節點已經附着在都沒節點上，會有對元素大小、位置的定義，可是瀏覽器 還須要根據實際窗口大小進行計算，好比對auto的處理。　　　
四、繪製，把css中有關顏色的設置，背景、字體顏色等呈現出來。
五、瀏覽器遇到img等媒體資源時，不會阻塞渲染，會去異步加載這些資源。
六、瀏覽器若是遇到內聯的script腳本，則會當即執行該腳本。
七、瀏覽器若是遇到含有外部文件的script（先討論不含defer、async屬性的狀況）標籤，會阻塞當前渲染，建立新的網絡鏈接，開始下載腳本文件，下載完成後當即執行。
八、因此，若在HTML頭部加載JS文件，因爲JS阻塞，會推遲頁面的首繪。爲了加快頁面渲染，通常將JS文件放到HTML底部進行加載，或是對JS文件執行async或defer加載
九、defer屬性和async屬性都能防止腳本下載阻塞頁面渲染
若是script標籤包含defer屬性，則瀏覽器會當即去下載該js文件，可是卻不會執行該js文件，該文件執行時機爲，瀏覽器渲染至</html>時。defer的js文件會在DOMContentLoaded事件以前完成執行。
若是script標籤包含async屬性,是會去異步下載該js文件，而且當該js下載完成後當即執行，async的js文件會在load事件以前完成執行。
十、onload事件和DOMContentLoaded事件
DOMContentLoaded事件是當初始HTML文檔徹底被加載和解析（即全部的DOM徹底解析）時觸發的，無須要等待樣式表，圖片，子框架完成加載。而onload事件要等頁面全部元素，包括圖片以及腳本等所有加載完成才觸發，所以它比DOMContentLoaded要更晚執行。
在頁面的圖片不少，網絡很差的狀況下，從用戶訪問到onload觸發可能須要很長的時間，此時若是在onload中加入許多初始化的動做, 必然會影響用戶的體驗。這事使用DOMContentLoaded事件代替onload事件是更合適的。

---

以上爲樓主的筆記整理，但願能幫到你們理解相關知識。

---

引用：

https://blog.csdn.net/yanxiao...
https://blog.csdn.net/qq_4194...
https://blog.csdn.net/qq_3265...