經典面試題—在瀏覽器中輸入URL之后發生了什么？

一、URL決議

二、DNS決議

三、建立TCP連接（三次握手）

為什么不能用兩次握手進行連接？

四、發送HTTP請求

請求的流程

五、服務器處理請求并回傳HTTP回應

服務器處理請求的流程

MVC后臺處理階段

HTTP回應報文

六、瀏覽器決議渲染頁面

七、斷開TCP連接（四次揮手）

TCP四次揮手的程序

為什么連接時是三次握手卻是四次揮手？

為什么TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能回傳到CLOSE狀態？

總體流程：

1. URL決議
2. DNS決議：瀏覽器進行DNS域名決議，得到對應的IP地址
3. TCP連接：TCP三次握手
4. 發送HTTP請求
5. 服務器處理請求并回傳HTTP報文
6. 瀏覽器根據其請求得到的資源渲染頁面
7. 斷開連接：TCP四次揮手

一、URL決議

URL，統一資源定位符，用于定位互聯網上的資源，我們俗稱“網址”，

URL遵循以下的語法規則：scheme://host.domain:port/path/filename

1. scheme - 定義因特網服務的型別，常見的協議有 http、https、ftp、file，其中最常見的型別是 http，而 https 則是進行加密的網路傳輸，
2. host - 定義域主機（http 的默認主機是 www）
3. domain - 定義因特網域名，比如 w3school.com.cn
4. port - 定義主機上的埠號（http 的默認埠號是 80）
5. path - 定義服務器上的路徑（如果省略，則檔案必須位于網站的根目錄中），
6. filename - 定義檔案/資源的名稱

URL決議的流程為：

1.地址決議：

首先判斷你輸入的是一個合法的 URL 還是一個待搜索的關鍵詞，并且根據你輸入的內容進行自動完成、字符編碼等操作，

urlencode 和urldecode （編碼和解碼）

像 / ? : 等這樣的字符, 已經被url當做特殊意義理解了. 因此這些字符不能隨意出現.
比如, 某個引數中需要帶有這些特殊字符, 就必須先對特殊字符進行轉義.

轉義的規則：

將需要轉碼的字符轉為16進制，然后從右到左，取4位(不足4位直接處理)，每2位做一位，前面加上%，編碼成%XY格式，

如上圖中，"+" 被轉義成了 "%2B"

urldecode就是urlencode的逆程序，

2. HSTS

HSTS 是 HTTP 嚴格傳輸安全（HTTP Strict Transport Security） 的縮寫， 這是一種網站用來宣告他們只能使用安全連接（HTTPS）訪問的方法， 如果一個網站宣告了 HSTS 策略，瀏覽器必須拒絕所有的 HTTP 連接并阻止用戶接受不安全的 SSL 證書， 目前大多數主流瀏覽器都支持 HSTS，

由于安全隱患，會使用HSTS強制客戶端使用HTTPS訪問頁面，

3.其他操作

瀏覽器還會進行一些額外的操作，比如安全檢查、訪問限制等，

4.檢查快取

二、DNS決議

瀏覽器不能直接通過域名找到對應的服務器而是要通過IP地址，

IP地址

IP 地址是指互聯網協議地址，是 IP Address 的縮寫，IP 地址是 IP 協議提供的一種統一的地址格式，它為互聯網上的每一個網路和每一臺主機分配一個邏輯地址，以此來屏蔽物理地址的差異，IP 地址是一個 32 位的二進制數，比如 127.0.0.1 為本機 IP，

IP協議有兩個版本IPv4和IPv6，對于IPv4來說，IP地址是一個4位元組，32位的整數，

· 通常也使用 "點分十進制" 的字串表示IP地址, 例如 192.168.0.1 ; 用點分割的每一個數字表示一個位元組, 范圍是 0 - 255;

域名決議

DNS協議通過域名查找IP地址，或逆向從IP地址反查域名的服務，

DNS 是一個網路服務器，我們的域名決議簡單來說就是在 DNS 上記錄一條資訊記錄，DNS保存了一張域名和與之對應的IP地址的表以決議訊息的域名，

瀏覽器通過域名查詢URL對應的IP

基本的步驟：

1.查找瀏覽器快取

因為瀏覽器一般會快取DNS記錄一段時間，不同瀏覽器的時間可能不一樣，一般2-30分鐘不等，瀏覽器去查找這些快取，如果有快取，直接回傳IP，否則下一步，

2.查找作業系統快取

瀏覽器快取中找不到IP之后，瀏覽器會進行系統呼叫（windows中是gethostbyname），查找本機的hosts檔案，如果找到，直接回傳IP，否則下一步，

3.查找路由器快取

如果1,2步都查詢無果，則需要借助網路，路由器一般都有自己的DNS快取，將前面的請求發給路由器，查找ISP 服務商快取 DNS的服務器，如果查找到IP則直接回傳，沒有的話繼續查找，

4.ISP DNS快取

如果以上步驟還找不到，則ISP的DNS服務器就會進行遞回查詢，所謂遞回查詢就是如果主機所詢問的本地域名服務器不知道被查詢域名的IP地址，那么本地域名服務器就以DNS客戶的身份，向其他根域名服務器繼續發出查詢請求報文，而不是讓該主機自己進行下一步查詢，（本地域名服務器地址是通過DHPC協議獲取地址，DHPC是負責分配IP地址的）

5.根域名服務器查詢

本地域名服務器采用迭代查詢，它先向一個根域名服務器查詢，本地域名服務器向根域名服務器的查詢一般都是采用迭代查詢，所謂迭代查詢就是當根域名服務器收到本地域名服務器發出的查詢請求報文后，要么告訴本地域名服務器下一步應該查詢哪一個域名服務器，然后本地域名服務器自己進行后續的查詢，（而不是替代本地域名服務器進行后續查詢）

DNS原理及決議程序詳解

遞回查詢：一路查下去中間不回傳，得到最終結果才回傳資訊（瀏覽器到本地DNS服務器的程序）

迭代查詢：本地DNS服務器到根域名服務器的查詢方式

DNS劫持：域名劫持，通過攻擊域名決議服務器或偽造域名決議服務器的方法，把目標網站域名決議到錯誤的IP地址從而實作用戶無法訪問目標網站的目的或者蓄意或惡意要求用戶指定IP地址的目的，

三、建立TCP連接（三次握手）

在客戶端發送資料之前需要發起TCP三次握手建立與服務端的連接，用以同步客戶端和服務端的序列號和確認號，并交換 TCP 視窗大小資訊，所謂三次握手是指建立一個TCP連接時，需要客戶端和服務器總共發送3個包，

TCP三次握手的程序

1. 第一次握手：建立連接時，客戶端A發送SYN包（SYN=1同時選擇一個初始序列號seq = x）到服務器B，并進入SYN_SEND狀態，等到服務器B確認，
2. 第二次握手：服務器B收到SYN包，必須確認客戶A的SYN=1，同時自己也發送一個SYN包(SYN=1,確認號是ack = x+1，同時也要問自己初始化一個序列號seq = y)，即SYN+ACK包，此時服務器B進入SYN_RECV狀態，
3. 第三次握手：客戶端A收到服務器B的SYN+ACK包，向服務器B發送確認包ACK（ack = y+1，自己的序列號為seq = z），此包發送完畢后，客戶端A和服務器B進入ESTABLISHED狀態，建立連接完成，

為什么不能用兩次握手進行連接？

3次握手完成了兩個重要的功能，既要雙方做好發送資料的準備作業，也要允許雙方就初始序列號進行協商，這個序列號在握手程序中被發送和確認，

如果把三次握手改成僅需要兩次握手，死鎖是可能發生的，如下圖所示，如果計算機Client和Server之間的通信，假定Client給Server發送一個連接請求分組，Server收到了這個分組，并發送了確認應答分組，按照兩次握手的協定，Server認為連接已經成功地建立了，可以開始發送資料分組，可是，Client在Server的應答分組在傳輸中被丟失的情況下，將不知道Server是否已準備好，不知道Server建立什么樣的序列號，Client甚至懷疑Server是否收到自己的連接請求分組，在這種情況下，Client認為連接還未建立成功，將忽略Server發來的任何資料分組，Client只等待連接確認應答分組，而Server在發出的資料分組超時后，重復發送同樣的資料分組，這樣就形成了死鎖，

另外三次握手可以防止已失效的連接請求報文段突然又傳到了Server，因而產生錯誤，假定出現一種例外情況，即Client發出的第一個連接請求報文段并沒有丟失，而是在某些網路結 點長時間滯留了，一直延遲到連接釋放以后的某個時間才到達Server，本來這是一個早已失效的報文段，但Server收到此失效的連接請求報文段后，就誤認為是Client又發出一次 新的連接請求，于是就向Client發出確認報文段，同意建立連接，假定不采用三次握手，那么只要Server發出確認，新的連接就建立了，這樣一直等待Client發來資料，Server的許多資源就這樣白白浪費了，

四、發送HTTP請求

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

HTTP請求報文由請求行、請求頭、請求體三個部分組成:

1.請求行包括請求方法、URL、協議版本 ；

請求方法包括：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE；

POST  /chapter17/user.html HTTP/1.1

2.請求頭包含請求的附加資訊，由關鍵字/值 對組成，每行一對，關鍵在和值用":"分隔；

HTTP常見的Header：

1. Content-Type：資料型別——訊息體的格式，告訴對方應該用什么方式進行決議
2. Content-Length：訊息體的長度
3. Host：客戶端告知服務器，所請求的資源是在哪個主機的哪個埠上
4. User-Agent:宣告用戶的瀏覽器版本資訊
5. referer：當前頁面是從哪一個頁面條狀過來的，
6. location：搭配3XX狀態碼使用，告訴客戶端接下來要去哪個訪問；
7. Cookie：在客戶端存盤少量的資訊，通常用于實作會話session的功能，

3.請求體，可以承載多個請求引數的資料，包括回車符、換行符和請求資料，并不是所有請求都具有請求資料，

關于HTTP請求相關的可以詳細瀏覽必須掌握的HTTP相關知識，

請求的流程

TCP/IP分為四層，在發送資料時，每層都要對資料進行封裝：

應用層:發送HTTP請求

在得到服務器的IP地址后，瀏覽器會開始構造一個HTTP報文

瀏覽器只能發送GET、POST方法，打開網頁使用的時GET方法，

傳輸層：TCP傳輸報文

傳輸層會發起一條到達服務器的 TCP 連接，為了方便傳輸，會對資料進行分割（以報文段為單位），并標記編號，方便服務器接受時能夠準確地還原報文資訊，

在建立連接前，會先進行 TCP 三次握手，

網路層：IP協議查詢Mac地址

將資料段打包，并加入源及目標的IP地址，并且負責尋找傳輸路線，判斷目標地址是否與當前地址處于同一網路中，是的話直接根據 Mac 地址發送，否則使用路由表查找下一跳地址，以及使用 ARP 協議查詢它的 Mac 地址，

資料鏈路層：以太網協議

以太網協議

根據以太網協議將資料分為以“幀”為單位的資料包，每一幀分為兩個部分：標頭：資料包的發送者、接受者、資料型別；資料：資料包具體內容，

Mac 地址

以太網規定了連入網路的所有設備都必須具備“網卡”介面，資料包都是從一塊網卡傳遞到另一塊網卡，網卡的地址就是 Mac 地址，每一個 Mac 地址都是獨一無二的，具備了一對一的能力，

廣播

發送資料的方法很原始，直接把資料通過 ARP 協議，向本網路的所有機器發送，接收方根據標頭資訊與自身 Mac 地址比較，一致就接受，否則丟棄，

五、服務器處理請求并回傳HTTP回應

服務器處理請求的流程：

服務器是網路環境中的高性能計算機，它偵聽網路上的其他計算機（客戶機）提交的服務請求，并提供相應的服務，比如網頁服務、檔案下載服務、郵件服務、視頻服務，

而客戶端主要的功能是瀏覽網頁、看視頻、聽音樂等等，兩者截然不同，

每臺服務器上都會安裝處理請求的應用——Web Server ，常見的Web server 產品有apache、nginx等，

web server 擔任管控的角色，對于不同用戶發送的請求，會結合組態檔，把不同請求委托給服務器上處理相應請求的程式進行處理（例如 CGI 腳本，JSP 腳本，servlets，ASP 腳本，服務器端 JavaScript，或者一些其它的服務器端技術等），然后回傳后臺程式處理產生的結果作為回應，

MVC后臺處理階段

后臺開發現在有很多框架，但大部分都還是按照 MVC 設計模式進行搭建的，MVC 是一個設計模式，將應用程式分成三個核心部件：模型（model）-- 視圖（view）--控制器（controller），它們各自處理自己的任務，實作輸入、處理和輸出的分離，

首先瀏覽器發送過來的請求先經過控制器，控制器進行邏輯處理和請求分發，接著會呼叫模型，這一階段模型會獲取 redis db 以及 MySQL 的資料，獲取資料后將渲染好的頁面，回應資訊會以回應報文的形式回傳給客戶端，最后瀏覽器通過渲染引擎將網頁呈現在用戶面前，

HTTP回應報文

回應報文由回應行、回應頭部、回應體三部分組成，

(1) 回應行包括：協議版本、狀態碼以及狀態碼描述

狀態碼規則：

1XX：資訊性狀態碼，接收的請求正在處理

2XX：成功狀態碼，請求正確處理完畢

3XX：重定向狀態碼，需要進行附加操作以完成請求

4XX：客戶端錯誤狀態碼，服務器無法處理請求

5XX：服務器錯誤狀態碼，服務器處理請求出錯

常見的HTTP狀態碼：

(2) 回應頭包含回應報文的附加資訊

• allow：服務器支持哪些請求方法；
• Date：表示訊息發送的時間
• server：服務器名字
• Connection：瀏覽器與服務器之間連接的型別
• Content-Type：表示后面的檔案屬于什么MIME型別；Servlet默認為text/plain，但通常需要顯式地指定為text/html，
• Content-Length：表示內容的長度
• Location：表示客戶應當到哪里去提取檔案，Location通常不是直接設定的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設定狀態代碼為302，
• Set-Cookie：設定和頁面關聯的Cookie，

(3) 回應主體包含回車符、換行符和回應回傳資料，并不是所有回應報文都有回應資料，

六、瀏覽器決議渲染頁面

瀏覽器決議渲染頁面分為以下5個步驟：

1. 根據HTML決議出DOM樹
2. 根據CSS決議生成CSS規則樹
3. 結合DOM樹和CSS規則樹，生成渲染樹
4. 根據渲染樹計算出每一個結點的資訊
5. 根據計算好的資訊繪制頁面

轉載于：https://www.cnblogs.com/aiqiqi/p/11479185.html#_label5_2

七、斷開TCP連接（四次揮手）

TCP四次揮手的程序

當資料傳送完畢，需要斷開TCP連接，此時發起TCP四次揮手，TCP的連接的拆除需要發送四個包，因此稱為四次揮手(four-way handshake)，客戶端或服務器均可主動發起揮手動作，在socket編程中，任何一方執行close()操作即可產生揮手操作，

（1）客戶端A發送一個FIN，用來關閉客戶A到服務器B的資料傳送(報文段4)，發起方向被動方發送報文，Fin、Ack、Seq，表示已經沒有資料傳輸了，并進入 FIN_WAIT_1 狀態，(第一次揮手：由瀏覽器發起的，發送給服務器，我請求報文發送完了，你準備關閉吧)

（2）服務器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1(報文段5)，和SYN一樣，一個FIN將占用一個序號，被動方發送確認報文，Ack、Seq，表示同意關閉請求，此時主動發起方進入 FIN_WAIT_2 狀態，服務器B進入CLOSE_WAIT狀態，(第二次揮手：由服務器發起的，告訴瀏覽器，我請求報文接受完了，我準備關閉了，你也準備吧)

（3）服務器B關閉與客戶端A的連接，發送一個FIN給客戶端A(報文段6)，被動方向發起方發送報文段，Fin、Ack、Seq，請求關閉連接，并進入 LAST_ACK 狀態，(第三次揮手：由服務器發起，告訴瀏覽器，我回應報文發送完了，你準備關閉吧)

（4）客戶端A發回ACK報文確認，并將確認序號設定為收到序號加1(報文段7)，發起方向被動方發送報文段，Ack、Seq，然后進入等待 TIME_WAIT 狀態，被動方收到發起方的報文段以后關閉連接，發起方等待一定時間2MSL未收到回復，則正常關閉(第四次揮手：由瀏覽器發起，告訴服務器，我回應報文接受完了，我準備關閉了，你也準備吧)

為什么連接時是三次握手卻是四次揮手？

建立連接時：當Server端收到Client端的SYN連接請求報文后，可以直接發送SYN+ACK報文，其中ACK報文是用來應答的，SYN報文是用來同步的，

關閉連接時：當Server端收到FIN報文后，TCP在系統內核實作時，自動回應的ACK；再次發送FIN是應用程式手動的呼叫close()來關閉連接，程式在關閉連接前，可能需要執行釋放資源等前置操作，所以兩次不能進行合并，在斷開連接的時候就需要四次揮手，

為什么TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能回傳到CLOSE狀態？

理論上，四個報文發送完畢，可以直接進入CLOSE狀態，但是如果網路不可靠，有可能最后一個ACK丟失，所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文，在Client發送出最后的ACK回復，但該ACK丟失，Server如果沒有收到ACK，將不斷重復發送FIN片段，

所以Client不能立即關閉，它必須確認Server接收到了該ACK，Client會在發送出ACK之后進入到TIME_WAIT狀態，Client會設定一個計時器，等待2MSL的時間，如果在該時間內再次收到FIN，那么Client會重發ACK并再次等待2MSL，所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)，

MSL指一個片段在網路中最大的存活時間，2MSL就是一個發送和一個回復所需的最大時間，如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經被成功接收，Client置為CLOSE狀態，則結束TCP連接，