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

總體流程：

URL解析

DNS解析：瀏覽器進行DNS域名解析，得到對應的IP地址

TCP連線：TCP三次握手

傳送HTTP請求

伺服器處理請求並返回HTTP報文

瀏覽器根據其請求得到的資源渲染頁面

斷開連線：TCP四次揮手

一、URL解析

URL，統一資源定位符，用於定位網際網路上的資源，我們俗稱“網址”。

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

scheme - 定義因特網服務的型別。常見的協議有 http、https、ftp、file，其中最常見的型別是 http，而 https 則是進行加密的網路傳輸。

host - 定義域主機（http 的預設主機是 www）

domain - 定義因特網域名，比如 w3school.com.cn

port - 定義主機上的埠號（http 的預設埠號是 80）

path - 定義伺服器上的路徑（如果省略，則文件必須位於網站的根目錄中）。

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三次握手的過程

 第一次握手：建立連線時，客戶端A傳送SYN包（SYN=1同時選擇一個初始序列號seq = x）到伺服器B，並進入SYN_SEND狀態，等到伺服器B確認。

第二次握手：伺服器B收到SYN包，必須確認客戶A的SYN=1，同時自己也傳送一個SYN包(SYN=1,確認號是ack = x+1，同時也要問自己初始化一個序列號seq = y)，即SYN+ACK包，此時伺服器B進入SYN_RECV狀態。

第三次握手：客戶端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：

Content-Type：資料型別——訊息體的格式，告訴對方應該用什麼方式進行解析

Content-Length：訊息體的長度

Host：客戶端告知伺服器，所請求的資源是在哪個主機的哪個埠上

User-Agent:宣告使用者的瀏覽器版本資訊

referer：當前頁面是從哪一個頁面條狀過來的。

location：搭配3XX狀態碼使用，告訴客戶端接下來要去哪個訪問；

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個步驟：

根據HTML解析出DOM樹

根據CSS解析生成CSS規則樹

結合DOM樹和CSS規則樹，生成渲染樹

根據渲染樹計算出每一個結點的資訊

根據計算好的資訊繪製頁面

轉載於：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連線。

————————————————

版權宣告：本文為CSDN博主「小王～同學」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。

原文連結：https://blog.csdn.net/qq_45754055/article/details/115116931