目錄

1、瀏覽器解析url

2、DNS域名解析

3、瀏覽器獲取端口號

4、TCP建立連接

5、發送HTTP請求

6、服務器處理請求

7、返回響應結果

8、關閉TCP連接

9、瀏覽器加載解析渲染

---

先概括一下整個過程：

首先，瀏覽器向本地DNS服務器發送請求，如果本地沒有緩存該域名的IP地址，就需要通過遞歸或迭代的方式向根域名服務器、頂級域名服務器、權威域名服務器發起查詢請求，直至返回一個IP地址給瀏覽器。然后根據該IP地址建立TCP連接，客戶端發送HTTP請求，服務器返回報文，關閉TCP連接，再由瀏覽器進行解析渲染頁面，最后TCP四次揮手結束連接（404:服務器找不到請求的頁面）

應用層：DNS、HTTP、HTTPS

傳輸層：TCP

網絡層：IP、ARP

1、瀏覽器解析url

瀏覽器會對我們輸入的url進行解析，主要將其分為下部分：協議、網絡地址、資源路徑。其中網絡地址指示該連接網絡上哪一臺計算機，可以是域名或者IP地址，可以包括端口號；協議是從該計算機獲取資源的方式，常見的是HTTP，HTTPS，FTP等。不同協議有不同的通訊內容格式；資源路徑指示從服務器上需要獲取資源的具體路徑。

這里瀏覽器對輸入的url解析為如下內容：
url：https://mp.csdn.net/mp_blog/creation/editor/119778557
協議：https
網絡地址（網站名）：mp.csdn.net
資源路徑：/mp_blog/creation/editor/119778557

2、DNS域名解析

客戶端收到你輸入的域名地址后，它首先去找本地的hosts文件，檢查在該文件中是否有相應的域名、IP對應關系，如果有，則向其IP地址發送請求，如果沒有，再去找DNS服務器。一般用戶很少去編輯修改hosts文件。
可以理解ip是你家的具體住址 如南京市建鄴區吉慶家園04棟603室

DNS服務器層級如下：

DNS查詢的具體步驟如下：
a、從瀏覽器緩存中查詢。瀏覽器會存儲一定時間的DNS記錄，操作系統不會告訴瀏覽器每個DNS記錄的保存時限，不同瀏覽器設置保存時限為一個固定值（不同瀏覽器情況不同，一般在2-30分鐘）。

b、從操作系統緩存中查詢。如果瀏覽器中沒有包含想要的緩存記錄，那瀏覽器就會發起操作系統請求，繼續查詢操作系統緩存

c、從路由器中查詢DNS緩存。請求持續發送到你的路由，它通常會有自己的DNS緩存。

d、從ISP中查詢DNS緩存。下一個被查詢地方是ISP緩存DNS的服務器。

e、域名服務器迭代查詢，根據返回的地址逐級向上查詢。首先從root域名服務器中查詢如.com域名服務器，然后逐步向前查詢，.com頂級域名服務器到ruanyifeng的域名服務器。一般來說，.com級別的都已經在緩存中了，所以一般不會進行對root域名服務器的查詢。下面給出一張迭代查詢的圖。

瀏覽器客戶端向本地DNS服務器發送一個含有域名https://mp.csdn.net的DNS查詢報文。
本地DNS服務器把查詢報文轉發到根DNS服務器，根DNS服務器注意到其com后綴，于是向本地DNS服務器返回comDNS服務器的IP地址。
本地DNS服務器再次向comDNS服務器發送查詢請求，comDNS服務器注意到其https://mp.csdn.net后綴并用負責該域名的權威DNS服務器的IP地址作為回應。
最后，本地DNS服務器將含有https://mp.csdn.net的IP地址的響應報文發送給客戶端。
從客戶端到本地服務器屬于遞歸查詢，而DNS服務器之間的交互屬于迭代查詢。
正常情況下，本地DNS服務器的緩存中已有comDNS服務器的地址，因此請求根域名服務器這一步不是必需的。

3、瀏覽器獲取端口號

知道ip地址后，還需要端口號，這樣才能知道具體在603室的哪個房間里。http協議默認端口號是80。

4、TCP建立連接

IP和端口都有了，在http消息發送前，需要建立客戶端與服務器的TCP鏈接，也就是進行所謂的三次握手。

TCP是因特網中的傳輸層協議，使用三次握手協議建立連接。當主動方發出SYN連接請求后，
等待對方回答SYN+ACK，并最終對對方的 SYN 執行 ACK 確認。這種建立連接的方法可以防止產生錯誤的連接，
TCP使用的流量控制協議是可變大小的滑動窗口協議。

TCP三次握手的過程如下：

a、客戶端發送SYN（SEQ=x）報文給服務器端，進入SYN_SEND狀態。

b、服務器端收到SYN報文，回應一個SYN （SEQ=y）ACK(ACK=x+1）報文，進入SYN_RECV狀態。

c、客戶端收到服務器端的SYN報文，回應一個ACK(ACK=y+1）報文，進入Established狀態。

三次握手完成，TCP客戶端和服務器端成功地建立連接，可以開始傳輸數據了。

5、發送HTTP請求

經過三次握手之后，與服務器建立了連接后，就可以向服務器發起請求了。

6、服務器處理請求

請求到達服務器之后，接下來服務器需要響應瀏覽器的請求。服務器端收到請求后的由web服務器（準確說應該是http服務器）處理請求，諸如Apache、Ngnix、IIS等。web服務器解析用戶請求，知道了需要調度哪些資源文件，再通過相應的這些資源文件處理用戶請求和參數，并調用數據庫信息，最后將結果通過web服務器返回給瀏覽器客戶端。下面以靜態渲染的頁面為例，ajax渲染不需要在服務器做頁面數據寫入

7、返回響應結果

在HTTP里，有請求就會有響應，哪怕是錯誤信息。這里我們同樣看下響應報文的組成結構：

在響應結果中都會有個一個HTTP狀態碼，比如我們熟知的200、301、404、500等。通過這個狀態碼我們可以知道服務器端的處理是否正常，并能了解具體的錯誤。
狀態碼由3位數字和原因短語組成。根據首位數字，狀態碼可以分為五類：

8、關閉TCP連接

為了避免服務器與客戶端雙方的資源占用和損耗， 當雙方沒有請求或響應傳遞時，任意一方都可以發起關閉請求。

建立一個連接需要三次握手，而終止一個連接要經過四次揮手，這是由TCP的半關閉（half-close）造成的。具體過程如下圖所示。

(1) 某個應用進程首先調用close，稱該端執行“主動關閉”（active close）。該端的TCP于是發送一個FIN分節，表示數據發送完畢。
(2) 接收到這個FIN的對端執行 “被動關閉”（passive close），這個FIN由TCP確認。
注意：FIN的接收也作為一個文件結束符（end-of-file）傳遞給接收端應用進程，放在已排隊等候該應用進程接收的任何其他數據之后，因為，FIN的接收意味著接收端應用進程在相應連接上再無額外數據可接收。
(3) 一段時間后，接收到這個文件結束符的應用進程將調用close關閉它的套接字。這導致它的TCP也發送一個FIN。
(4) 接收這個最終FIN的原發送端TCP（即執行主動關閉的那一端）確認這個FIN。

既然每個方向都需要一個FIN和一個ACK，因此通常需要4個分節。

9、瀏覽器加載解析渲染

總結

以上是生活随笔為你收集整理的详解浏览器解析一个URL的全过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。