陸仴

一、從輸入一個網址開始

當我們在瀏覽器輸入一個網址，然後按下回車，接下來瀏覽器顯示了頁面。網速好的話這之間可能就一秒，但在這一秒內到底發生了什麼？

本文主要內容是試圖記錄一個完整 Web 請求的詳細過程，從用戶在瀏覽器中輸入 URL 地址說起，然後瀏覽器如何找到服務器地址的過程，併發起請求；分析請求在達反向代理服務器內部處理過程；最後到請求在服務器端處理完成後，瀏覽器渲染響應頁面過程。

Web請求的工作原理可以簡單地歸納為：

瀏覽器通過 DNS 把域名解析成對應的IP地址；

根據這個 IP 地址在互聯網上找到對應的服務器，建立 Socket 連接；客戶端向服務器發送HTTP協議請求包，請求服務器裡的資源文檔；

服務器端，實際上還有複雜的業務邏輯：服務器可能有多臺，到底指定哪臺服務器處理請求，這需要一個負載均衡設備來平均分配所有用戶的請求；還有請求的數據是存儲在分佈式緩存裡還是一個靜態文件中，或是在數據庫裡；當數據返回瀏覽器時，瀏覽器解析數據發現還有一些靜態資源（如：css，js或者圖片）時又會發起另外的請求，而這些請求可能會在CDN上，那麼CDN服務器又會處理這個用戶的請求。

客戶端與服務器斷開。由客戶端解釋HTML文檔，在客戶端屏幕上渲染圖形結果。

一個 HTTP 事務就是這樣實現的，看起來很簡單，原理其實是挺負責的。需要注意的是客戶機與服務器之間的通信是非持久連接的，也就是當服務器發送了應答後就與客戶機斷開連接，等待下一次請求。

但需要注意的是，從 HTTP 1.1 開始，服務器可以與客戶端保持長連接，不一定是請求完成後就斷開連接，這取決於服務器的操作。

二、DNS 域名解析

首先來看看最先發生的事情——DNS 域名解析，簡單的說就是把域名翻譯成 IP 地址。例如：把 http://www.test.com 這個域名翻譯成對應 IP 192.168.1.1，這裡只是舉個例子。

如果你在瀏覽器中直接輸入的 IP 地址，那麼實際上會跳過這個步驟，否則會經理下面幾部：

1、瀏覽器緩存檢查

瀏覽器會首先搜索瀏覽器自身的 DNS 緩存，緩存時間比較短，大概只有1分鐘，且只能容納1000條緩存，看自身的緩存中是否有對應的條目，而且沒有過期，如果有且沒有過期則解析到此結束。

2、操作系統緩存檢查 + hosts 解析

如果瀏覽器的緩存裡沒有找到對應的條目，操作系統也會有一個域名解析的過程，那麼瀏覽器先搜索操作系統的 DNS 緩存中是否有這個域名對應的解析結果，如果找到且沒有過期則停止搜索，解析到此結束。

在 Linux 中可以通過 /etc/hosts 文件來設置，可以將任何域名解析到任何能夠訪問的 IP 地址。如果在這裡指定了一個域名對應的 IP 地址，那麼瀏覽器會首先使用這個 IP 地址。當解析到這個配置文件中的某個域名時，操作系統會在緩存中緩存這個解析結果，緩存的時間同樣是受這個域名的失效時間和緩存的空間大小控制的。

3、本地區域名服務器(Local DNS Server)解析

如果在 hosts 文件中也沒有找到對應的條目，瀏覽器會發起一個 DNS 的系統調用，會向本地配置的首選 DNS 服務器發起域名解析請求（通過的是 UDP 協議向 DNS 的 53 端口發起請求，這個請求是遞歸的請求，也就是運營商的DNS服務器必須得提供給我們該域名的IP地址）。

在我們的網絡配置中都會有“DNS 服務器地址”這一項，這個地址就用於解決前面所說的如果兩個過程無法解析時要怎麼辦。操作系統會把這個域名發送給這裡設置的 LDNS，也就是本地區的域名服務器。

這個 DNS 通常都提供給你本地互聯網接入的一個 DNS 解析服務，例如你是在學校接入互聯網，那麼你的 DNS 服務器肯定在你的學校；如果你是在一個小區接入互聯網的，那這個 DNS 就是提供給你接入互聯網的應用提供商，即電信或者聯通。大約 80% 的域名解析都到這裡就已經完成了，所以 LDNS 主要承擔了域名的解析工作。

4、根域名服務器解析(Root Server)

如果 LDNS 沒有找到對應的條目，則由運營商的 DNS 代我們的瀏覽器發起迭代 DNS 解析請求。它首先是會找根域的 DNS 的 IP 地址，找到根域的 DNS 地址，就會向其發起請求。然後根域名服務器返回給本地域名服務器一個所查詢域的主域名服務器(gTLD Server)地址。

5、主域名服務器(gTLD Server)

本地域名服務器(LDNS Server)再向上一步返回的 gTLD 服務器發送請求。

接受請求的 gTLD 服務器查找並返回此域名對應的 Name Server 域名服務器的地址，這個 Name Server 通常就是你註冊的域名服務器，例如你在某個域名服務提供商申請的域名，那麼這個域名解析任務就由這個域名提供商的服務器來完成。

Name Server 域名服務器會查詢存儲的域名和IP的映射關係表，正常情況下都根據域名得到目標IP記錄，連同一個 TTL 值返回給 DNS Server 域名服務器。

三、TCP 的 3 次握手

拿到域名對應的 IP 地址後，User-Agent（一般是指瀏覽器）會以一個隨機端口（1024 < 端口 < 65535）向服務器的 WEB 程序發起 TCP 的連接請求。

這裡還涉及 ARP（地址解析協議）：是根據 IP 地址獲取物理地址 (MAC 地址) 的一個協議。

當一個數據幀經過多次路由到達目的網絡時，路由器只能知道其數據幀中的目的 IP 地址，而不知目標主機的硬件地址，網絡層使用的是 IP地址，但是在實際網絡鏈路上傳送數據幀時，最終必須使用該網絡的硬件地址，此時需要目的主機的硬件地址，就要使用 ARP 來獲取到對應 IP 地址主機的物理地址。

這個連接請求（原始的 Http 請求經過 TCP/IP 4層模型的層層封包）到達服務器端後（這中間通過各種路由設備，局域網內除外），進入到網卡，然後是進入到內核的 TCP/IP 協議棧（用於識別該連接請求，解封包，一層一層的剝開），還有可能要經過Netfilter防火牆（屬於內核的模塊）的過濾，最終到達WEB程序，最終建立了TCP/IP的連接。

Client 首先發送一個連接試探，SYN = 1 表示這是一個連接請求或連接接受報文，同時表示這個數據報不能攜帶數據，seq = x 表示 Client 自己的初始序號（seq = 0 就代表這是第 0 號包），這時候 Client 進入 syn_sent 狀態，表示客戶端等待服務器的回覆。

Server 監聽到連接請求報文後，如同意建立連接，則向 Client 發送確認。報文中的 SYN 和 ACK 都置 1 ，ACK = x + 1 表示期望收到對方下一個報文段的第一個數據字節序號是 x+1，同時表明 x 為止的所有數據都已正確收到（ACK = 1 其實是 ACK = 0 + 1，也就是期望客戶端的第 1 個包），seq = y 表示 Server 自己的初始序號（seq = 0 就代表這是服務器這邊發出的第 0 號包）。這時服務器進入 syn_rcvd，表示服務器已經收到 Client 的連接請求，等待確認。

Client 收到確認後還需再次發送確認，同時攜帶要發送給 Server 的數據。ACK 置 1 表示確認號 ack= y + 1 有效（代表期望收到服務器的第 1 個包），Client自己的序號 seq= x + 1（表示這就是我的第1個包，相對於第0個包來說的），一旦收到Client的確認之後，這個TCP連接就進入 Established 狀態，就可以發起請求了。

四、Nginx 反向代理

1、反向代理

反向代理（Reverse Proxy）方式是指：代理服務器來接受 Internet 上的連接請求，然後將請求轉發給內部網絡上的服務器，並將從內部網絡上服務器得到的結果返回給 Internet 上請求連接的客戶端。此時代理服務器對外就表現為一個服務器，反向代理服務器對於客戶端而言它就像是原始服務器，並且客戶端不需要進行任何特別的設置。

反向代理的作用：

保證內網的安全，可以使用反向代理提供 WAF 功能，阻止 web 攻擊。

負載均衡，通過反向代理服務器來優化網站的負載。

2、正向代理

既然有反向代理，就肯定有正向代理。什麼叫正向代理呢？

正向代理（Forward Proxy）通常都被簡稱為代理，就是在用戶無法正常訪問外部資源，可以通過代理的方式，讓用戶繞過防火牆，從而連接到目標網絡或者服務。

正向代理的工作原理就像一個跳板。

比如：我訪問不了 http://google.com，但是我能訪問一個代理服務器 A，A 能訪問 http://google.com，於是我先連上代理服務器 A，告訴它我需要 http://google.com 的內容，A 就去取回來，然後返回給我。

從網站的角度，只在代理服務器來取內容的時候有一次記錄，有時候並不知道是用戶的請求，也隱藏了用戶的資料，這取決於代理告不告訴網站。

正向代理是一個位於客戶端和原始服務器(origin server)之間的服務器。為了從原始服務器取得內容，客戶端向代理發送一個請求並指定目標(原始服務器)，然後代理向原始服務器轉交請求並將獲得的內容返回給客戶端。

3、正向代理與反向代理對比

五、關閉 TCP 連接

這一步不是所有的網頁都會這麼做，例如網頁版微信就沒有關閉 TCP 連接，因為微信上別人可以隨時發消息給你，實際上別人先把消息發送到了微信服務器，微信服務器再通過 TCP 鏈接，把消息推送到你的屏幕上。

試想一下，如果網頁版微信關閉了 TCP 連接會怎樣？

結果是：你不刷新網頁，就永遠收不到消息了。同時，如果你頻繁的發消息給別人，那麼就在頻繁的創建連接，關閉連接，這是很消耗資源的。所以微信就乾脆不關閉 TCP 連接，這樣微信服務器就可以給我們的瀏覽器發消息。

下圖是一次 Http 請求報文頭部信息，其中 Connection: keep-alive 意味著這次請求結束後不會關閉 TCP 連接。

當然不是所有的 HTTP 請求都沒有關閉連接，例如一篇博文，瀏覽器收到數據顯示就可以了，沒有那麼多動態數據，我看完就關了，這時就應該關閉 TCP 連接，當然這還是取決於請求的服務器。說了這麼多，還沒說關閉連接。

關閉 TCP 連接專業點說叫做“四次揮手”，與 TCP 建立連接的“三次握手”相對應。

由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務後就能發送一個 FIN 來終止這個方向的連接。收到一個 FIN 只意味著這一方向上沒有數據流動，一個TCP連接在收到一個 FIN 後仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。

至此，一個 Web 請求的大致流程差不多就是這樣，東西還是挺多的，如果有不完善的地方，歡迎大家補充。

Kali技術

我們打開瀏覽器，在地址欄輸入\\www.wukong.com\\，幾秒後瀏覽器打開悟空問答的頁面，那麼這幾秒鐘內發生了哪些事情，我就帶大家一起看看完整的流程：

解析URL

瀏覽器首先會對輸入的URL進行驗證，如果不合法的時候，那麼會把輸入的文字傳給默認的搜索引擎，比如你只在地址欄輸入“悟空問答”幾個字。

如果URL通過驗證，那麼可以解析得到協議（http或者https）、域名（wukong）、資源（首頁）等信息。

DNS查詢

• 瀏覽器會先檢查域名信息是否在緩存中。
  

• 再檢查域名是否在本地的Hosts文件中。

• 如果還不在，那麼瀏覽器會向DNS服務器發送一個查詢請求，獲得目標服務器的IP地址。

TCP封包及傳輸

這時候瀏覽器獲得了目標服務器的IP（DNS返回）、端口（URL中包含，沒有就使用默認），瀏覽器會調用庫函數socket，生成一個TCP流套接字，也就是完成了TCP的封包。

TCP封包完成之後，就可以傳輸了，在完成“你瞅啥”，“瞅你咋地”，“來，過來嘮嘮”一系列操作之後，瀏覽器和服務器就完成了TCP的三次握手，建立了連接，後面就可以請求服務器資源了。

服務器接收請求並相應

• HTTP有很多請求方法，比如：GET/POST/PUT/DELETE等等，我們瀏覽器輸入URL這種，是GET方法。
  

• 服務器接收到GET請求，服務器根據請求信息，獲得相應的相應內容。例如我們輸入的是：\\www.wukong.com\\，那麼意味著訪問首頁文件。

瀏覽器解析並渲染

瀏覽器從服務器拿到了想要訪問的資源，大多數時候，這個資源就是HTML頁面，當然也可能是一個其他類型的文件。

• 瀏覽器先對HTML文檔進行解析，生成解析樹（以DOM元素為節點的樹）。
  

• 加載頁面的外部資源，比如JS、CSS、圖片。
  

• 遍歷DOM樹，並計算每個節點的樣式，最終完成渲染，變成我們看到的頁面。

這次請求響應之後，會斷開連接，就這樣，完成了一次HTTP的請求。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

會點代碼的大叔

Http請求的一次詳解:

1. 客戶端輸入URL
   

2. 客戶端檢測緩存:
   

有緩存且較新，客戶端直接讀取本地緩存進行資源展示；

有緩存但是不新，準備http請求包,發送至服務端進行緩存校驗；

備註:http1.0中Expire、http1.1中是Cache-Control根據發起http請求:

請求報文包含:
a) 請求行
用來說明請求類型(get\\post\\delete等)、要訪問的資源(URI)以及使用的HTTP版本(1.0還是1.1)
b) 首部（header）
HOST將指出請求的目的地；
User-Agent由瀏覽器來定義,自動發送；
Connection:通常設置為keep-Alive, 長連接；
其他首部包括等。

3. 提取請求首部HOST通過DNS域名解析獲取服務IP(DNS緩存\\遞歸等)

4. 通過IP與默認端口創建TCP連接,進行http請求報文數據發送,其中重點就三次握手進行描述:

客戶端向服務端發送syn=1，seq=client請求的ID;
服務端向客戶端發送syn=1,seq=服務端請求的ID,ack=客戶端請求的ID+1;
客戶端向服務端發送syn=0,seq=客戶端請求的ID+1,ack=服務端請求的ID+1,data\\data…

5. 服務端程序接受請求，定向到請求路徑處理請求：

服務器對請求報文進行解析，並獲取請求的資源及請求方法等相關信息，根據方法，資源，首部和可選的主體部分對請求進行處理

HTTP常用請求方式:MethodGET、POST、HEAD、PUT、DELETE、TRACE、OPTIONS

6.訪問資源：

服務器獲取請求報文中請求的資源web服務器，即存放了web資源的服務器，負責向請求者提供對方請求的靜態資源，或動態運行後生成的資源

7. 返回處理結果，準備http響應:

8. 通過建立的tcp連接來返回相關的http響應報文及http狀態信息，然後根據實際情況看是否關閉連接(Connection的keep-alive)

9. TCP連接關閉經歷4次握手

客戶端主動關閉連接放發送FIN進入FIN_WAIT1狀態

服務端發最後的data和ack客戶端接收進入CLOSEWAIT狀態,客戶端進入接受ACK進入FINWAIT2狀態

服務端主動發FIN,客戶端接受FIN併發送ack進入TIMEWAIT狀態

服務器端正式關閉連接進入close狀態

10. 客戶端拿到http響應的報文信息，經過一系列前端處理過程最終將請求的資源進行展示。

夕陽雨晴

專業問題我來回答，

背景

愛答問題的小星星

一次完整的HTTP請求過程是怎麼樣的？事實上，題主的這個問題，最開始我也是抱著試一試的心態進來的，後來發現整個回答區基本上都是學術回答，講的通俗一點，都是專業人士在那邊玩，但是……沒幾個民眾能看得懂。就好像評論區那邊有一個回答的評論是，“在頭條發計算機學術信息好像怪怪的。”

我大致把這個問題查了個遍，寫個最通俗的版本給大家看看吧。

其實HTTP請求過程，就是發送請求—響應的過程。

第一步

今天你想起來，有事，需要找隔壁老王要個小視頻。於是，你打開了“TCP協議牌”機器，這是一臺高清組裝的移動電話機。

第二步

電話接通了，在視頻上出現了隔壁老王那張猥瑣的笑臉。

你開始說話。

• ①你：喂，你能聽到我說話嗎？(第一次握手)

• ②隔壁老王：能能能，我能聽到，那你能聽到我的說話嗎？(第二次握手)

• ③你：哈哈，我也能聽到！那咱們開始吧！(第三次握手)

接下來，就要開始做正事了。

第三步

1.你說：

哎呀老王呀，我這邊需要一個小電影，你能給我發過來嗎？(客戶端發送請求信息)

2.接著，沒等老王說話，你就把需要的小電影名字、大小、我這網速等等信息給他發了過去(客戶端發送頭部信息)，末尾還加上了一長串省略空格(以空格做結尾)。

第四步

老王皺皺眉頭。

“行吧！”(服務器端回應請求信息)

“你是要這個小電影《XXX》，番號XXX，1GB大小，某度網盤是吧？行！”(服務器端回應頭部信息)

老王動了動手指，查找了一下儲存卡目錄，翻出小電影。

“我給你發過去了！”(服務器端發送請求數據)

第五步

視頻聊天結束。你隨即打開收到的抖音小視頻，美滋滋的看起成都小甜甜姐姐起來。

這件事告訴我們：

我還沒有女朋友。

賴仲達

一次完整的http請求過程是怎樣的？

一次完整的http請求可以說相當迷人：

從你輸入網址點擊回車的那一刻開始，一切就開始發生：

1、首先瀏覽器會解析你輸入的這一串字符；主要是解析協議（HTTP（s）、ftp：）、域名（www.qq.com)等；如果是合法的網址就繼續進行；

2、接下啦就是要根據第一步解析到的域名找到域名指向的IP我們稱之為DNS查詢。當然這也是一個相對有趣的過程，但不是問題重點，此處簡略；

3、找到服務器的IP地址後寫下來就是http請求的開始：

三次握手建立連接：

客戶端：“在嗎？”；

服務端：“在啊”；

客服端 ：“那我開始連你啦”；開始發起http請求

建立連接後發生Http請求，請求內容有：

請求行：uri和協議的版本 (如：GET /index.php HTTP/1.1 )

請求頭部：關客戶端信息及請求正文信息（長度、編碼格式等）

請求數據：如：u=admin&pwd=123456 （可為空）

服務端在收到這些信息後作出相應的回答：

狀態：協議版本+狀態碼+簡要描述（如：HTTP/1.1 200 OK）

響應頭部：Content-Type（必須有：比如Content-Type: text/html）， 其他可選：Date 、server 等

響應數據：即服務器回應客戶端的內容

打開瀏覽器=》F12 訪問一下百度看一下這個完美的過程吧！

當然其中涉及的到東西遠不止這些，比如瀏覽器靜態文件的緩存；各個狀態碼含義；單次請求最大返回資源數；請求字節長度限制等等。

此處班門弄斧，如有錯誤請批評指正。

有點IT

“我是喲喲吼說科技，專注於數據網絡的回答，歡迎大家與我交流數據網絡的問題”

如題，一個完整的HTTP過程是怎樣的？

一個完整的HTTP過程包括建立連接、數據傳輸、斷開連接等七個步驟。

下面喲喲來詳細介紹一下每一步：

1、TCP建立連接

HTTP協議是基於TCP協議來實現的，因此首先就是要通過TCP三次握手與服務器端建立連接，一般HTTP默認的端口號為80；

2、瀏覽器發送請求命令

在與服務器建立連接後，Web瀏覽器會想服務器發送請求命令

3、瀏覽器發送請求頭消息

在瀏覽器發送請求命令後，還會發送一些其它信息，最後以一行空白內容告知服務器已經完成頭信息的發送；

4、服務器應答

在收到瀏覽器發送的請求後，服務器會對其進行回應，應答的第一部分是協議的版本號和應答狀態碼；

5、服務器回應頭信息

與瀏覽器端同理，服務器端也會將自身的信息發送一份至瀏覽器；

6、服務器發送數據

在完成所有應答後，會以Content-Type應答頭信息所描述的格式發送用戶所需求的數據信息；

7、斷開TCP連接

在完成此次數據通信後，服務器會通過TCP四次揮手主動斷開連接。但若此次連接為長連接，那麼瀏覽器或服務器的頭信息會加入keep-alive的信息，會保持此連接狀態，在有其它數據發送時，可以節省建立連接的時間；

歡迎大家多多關注我，在下方評論區說出自己的見解。

喲喲吼說科技

一，在瀏覽器地址欄輸入網址

二，解析域名，找到主機的ip地址

三，瀏覽器與主機建立TCP連接

四，瀏覽器向主機發起GET請求

五，服務器響應請求，返回html頁面

六，瀏覽器開始顯示服務器返回的頁面，並且在顯示html頁面的時候，如果遇見css文件，js文件，圖片，就又會再次給相應地址服務器發起請求。

神聖秋刀魚

域名解析 --> 發起TCP的3次握手 --> 建立TCP連接後發起http請求 --> 服務器響應http請求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給用戶

騷年不6忙

wireshark抓個包，對著資料看報文

關鍵字: 網址 科技 瀏覽器