一、從輸入一個(gè)網(wǎng)址開始

當(dāng)我們?cè)跒g覽器輸入一個(gè)網(wǎng)址，然后按下回車，接下來瀏覽器顯示了頁面。網(wǎng)速好的話這之間可能就一秒，但在這一秒內(nèi)到底發(fā)生了什么？

本文主要內(nèi)容是試圖記錄一個(gè)完整 Web 請(qǐng)求的詳細(xì)過程，從用戶在瀏覽器中輸入 URL 地址說起，然后瀏覽器如何找到服務(wù)器地址的過程，并發(fā)起請(qǐng)求；分析請(qǐng)求在達(dá)反向代理服務(wù)器內(nèi)部處理過程；最后到請(qǐng)求在服務(wù)器端處理完成后，瀏覽器渲染響應(yīng)頁面過程。

大致過程如下：

總流程圖

Web請(qǐng)求的工作原理可以簡(jiǎn)單地歸納為：

1. 瀏覽器通過 DNS 把域名解析成對(duì)應(yīng)的IP地址；

2. 根據(jù)這個(gè) IP 地址在互聯(lián)網(wǎng)上找到對(duì)應(yīng)的服務(wù)器，建立 TCP 連接；

3. 客戶端向服務(wù)器發(fā)送 HTTP 協(xié)議請(qǐng)求包，請(qǐng)求服務(wù)器里的資源文檔；

4. 在服務(wù)器端，實(shí)際上還有復(fù)雜的業(yè)務(wù)邏輯：服務(wù)器可能有多臺(tái)，到底指定哪臺(tái)服務(wù)器處理請(qǐng)求，這需要一個(gè)負(fù)載均衡設(shè)備來平均分配所有用戶的請(qǐng)求；

5. 還有請(qǐng)求的數(shù)據(jù)是存儲(chǔ)在分布式緩存里還是一個(gè)靜態(tài)文件中，或是在數(shù)據(jù)庫里；

6. 當(dāng)數(shù)據(jù)返回瀏覽器時(shí)，瀏覽器解析數(shù)據(jù)發(fā)現(xiàn)還有一些靜態(tài)資源（如：css，js或者圖片）時(shí)又會(huì)發(fā)起另外的請(qǐng)求，而這些請(qǐng)求可能會(huì)在 CDN 上，那么 CDN 服務(wù)器又會(huì)處理這個(gè)用戶的請(qǐng)求。

7. 客戶端與服務(wù)器斷開。由客戶端解釋 HTML 文檔，在客戶端屏幕上渲染圖形結(jié)果。

一個(gè) HTTP 事務(wù)就是這樣實(shí)現(xiàn)的，看起來很簡(jiǎn)單，原理其實(shí)是挺負(fù)責(zé)的。需要注意的是客戶機(jī)與服務(wù)器之間的通信是非持久連接的，也就是當(dāng)服務(wù)器發(fā)送了應(yīng)答后就與客戶機(jī)斷開連接，等待下一次請(qǐng)求。

但需要注意的是，從 HTTP 1.1 開始，服務(wù)器可以與客戶端保持長(zhǎng)連接，不一定是請(qǐng)求完成后就斷開連接。

二、DNS 域名解析

首先來看看最先發(fā)生的事情——DNS 域名解析，簡(jiǎn)單的說就是把域名翻譯成 IP 地址。例如：把 www.baidu.com 這個(gè)域名翻譯成對(duì)應(yīng) IP 192.168.1.2，這里只是舉個(gè)例子。

如果你在瀏覽器中直接輸入的 IP 地址，那么實(shí)際上會(huì)跳過這個(gè)步驟，否則會(huì)經(jīng)理下面幾部：

1、瀏覽器緩存檢查

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

2、操作系統(tǒng)緩存檢查 + hosts 解析

如果瀏覽器的緩存里沒有找到對(duì)應(yīng)的條目，操作系統(tǒng)也會(huì)有一個(gè)域名解析的過程，那么瀏覽器先搜索操作系統(tǒng)的 DNS 緩存中是否有這個(gè)域名對(duì)應(yīng)的解析結(jié)果，如果找到且沒有過期則停止搜索，解析到此結(jié)束。

在 Linux 中可以通過 /etc/hosts 文件來設(shè)置，可以將任何域名解析到任何能夠訪問的 IP 地址。如果在這里指定了一個(gè)域名對(duì)應(yīng)的 IP 地址，那么瀏覽器會(huì)首先使用這個(gè) IP 地址。當(dāng)解析到這個(gè)配置文件中的某個(gè)域名時(shí)，操作系統(tǒng)會(huì)在緩存中緩存這個(gè)解析結(jié)果，緩存的時(shí)間同樣是受這個(gè)域名的失效時(shí)間和緩存的空間大小控制的。

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

如果在 hosts 文件中也沒有找到對(duì)應(yīng)的條目，瀏覽器會(huì)發(fā)起一個(gè) DNS 的系統(tǒng)調(diào)用，會(huì)向本地配置的首選 DNS 服務(wù)器發(fā)起域名解析請(qǐng)求（通過的是 UDP 協(xié)議向 DNS 的 53 端口發(fā)起請(qǐng)求，這個(gè)請(qǐng)求是遞歸的請(qǐng)求，也就是運(yùn)營(yíng)商的DNS服務(wù)器必須得提供給我們?cè)撚蛎腎P地址）。

在我們的網(wǎng)絡(luò)配置中都會(huì)有“DNS 服務(wù)器地址”這一項(xiàng)，這個(gè)地址就用于解決前面所說的如果兩個(gè)過程無法解析時(shí)要怎么辦。操作系統(tǒng)會(huì)把這個(gè)域名發(fā)送給這里設(shè)置的 LDNS，也就是本地區(qū)的域名服務(wù)器。

這個(gè) DNS 通常都提供給你本地互聯(lián)網(wǎng)接入的一個(gè) DNS 解析服務(wù)，例如你是在學(xué)校接入互聯(lián)網(wǎng)，那么你的 DNS 服務(wù)器肯定在你的學(xué)校；如果你是在一個(gè)小區(qū)接入互聯(lián)網(wǎng)的，那這個(gè) DNS 就是提供給你接入互聯(lián)網(wǎng)的應(yīng)用提供商，即電信或者聯(lián)通。大約 80% 的域名解析都到這里就已經(jīng)完成了，所以 LDNS 主要承擔(dān)了域名的解析工作。

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

如果 LDNS 沒有找到對(duì)應(yīng)的條目，則由運(yùn)營(yíng)商的 DNS 代我們的瀏覽器發(fā)起迭代 DNS 解析請(qǐng)求。它首先是會(huì)找根域的 DNS 的 IP 地址，找到根域的 DNS 地址，就會(huì)向其發(fā)起請(qǐng)求。然后根域名服務(wù)器返回給本地域名服務(wù)器一個(gè)所查詢域的主域名服務(wù)器(gTLD Server)地址。

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

本地域名服務(wù)器(LDNS Server)再向上一步返回的 gTLD 服務(wù)器發(fā)送請(qǐng)求。

接受請(qǐng)求的 gTLD 服務(wù)器查找并返回此域名對(duì)應(yīng)的 Name Server 域名服務(wù)器的地址，這個(gè) Name Server 通常就是你注冊(cè)的域名服務(wù)器，例如你在某個(gè)域名服務(wù)提供商申請(qǐng)的域名，那么這個(gè)域名解析任務(wù)就由這個(gè)域名提供商的服務(wù)器來完成。

Name Server 域名服務(wù)器會(huì)查詢存儲(chǔ)的域名和IP的映射關(guān)系表，正常情況下都根據(jù)域名得到目標(biāo)IP記錄，連同一個(gè) TTL 值返回給 DNS Server 域名服務(wù)器。

下圖匯總了上面所說的 DNS 解析過程：

DNS 解析過程

三、TCP 的 3 次握手

拿到域名對(duì)應(yīng)的 IP 地址后，User-Agent（一般是指瀏覽器）會(huì)以一個(gè)隨機(jī)端口（1024 < 端口 < 65535）向服務(wù)器的 WEB 程序發(fā)起 TCP 的連接請(qǐng)求。

這里還涉及 ARP(Address Resolution Protocol 地址解析協(xié)議)：根據(jù) IP 地址獲取物理地址 (MAC 地址) 的一個(gè)協(xié)議。
當(dāng)一個(gè)數(shù)據(jù)幀經(jīng)過多次路由到達(dá)目的網(wǎng)絡(luò)時(shí)，路由器只能知道其數(shù)據(jù)幀中的目的 IP 地址，而不知目標(biāo)主機(jī)的硬件地址。網(wǎng)絡(luò)層使用的是 IP 地址，但是在實(shí)際網(wǎng)絡(luò)鏈路上傳送數(shù)據(jù)幀時(shí)，最終必須使用該網(wǎng)絡(luò)的硬件地址，此時(shí)需要目的主機(jī)的硬件地址，就要使用 ARP 來獲取到對(duì)應(yīng) IP 地址主機(jī)的物理地址。

這個(gè)連接請(qǐng)求（原始的 HTTP 請(qǐng)求經(jīng)過 TCP/IP 4層模型的層層封包）到達(dá)服務(wù)器端后（這中間通過各種路由設(shè)備，局域網(wǎng)內(nèi)除外），進(jìn)入到網(wǎng)卡，然后是進(jìn)入到內(nèi)核的 TCP/IP 協(xié)議棧（用于識(shí)別該連接請(qǐng)求，解封包，一層一層的剝開），還有可能要經(jīng)過 Netfilter 防火墻（屬于內(nèi)核的模塊）的過濾，最終到達(dá) Web 程序，最終建立了TCP/IP的連接。

TCP 三次握手

1. Client 首先發(fā)送一個(gè)連接試探，SYN = 1 表示這是一個(gè)連接請(qǐng)求或連接接受報(bào)文，同時(shí)表示這個(gè)數(shù)據(jù)報(bào)不能攜帶數(shù)據(jù)，seq = x 表示 Client 自己的初始序號(hào)（seq = 0 就代表這是第 0 號(hào)包），這時(shí)候 Client 進(jìn)入 syn_sent 狀態(tài)，表示客戶端等待服務(wù)器的回復(fù)。

2. Server 監(jiān)聽到連接請(qǐng)求報(bào)文后，如同意建立連接，則向 Client 發(fā)送確認(rèn)。報(bào)文中的 SYN 和 ACK 都置 1 ，ACK = x + 1 表示期望收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)序號(hào)是 x+1，同時(shí)表明 x 為止的所有數(shù)據(jù)都已正確收到（ACK = 1 其實(shí)是 ACK = 0 + 1，也就是期望客戶端的第 1 個(gè)包），seq = y 表示 Server 自己的初始序號(hào)（seq = 0 就代表這是服務(wù)器這邊發(fā)出的第 0 號(hào)包）。這時(shí)服務(wù)器進(jìn)入 syn_rcvd，表示服務(wù)器已經(jīng)收到 Client 的連接請(qǐng)求，等待確認(rèn)。

3. Client 收到確認(rèn)后還需再次發(fā)送確認(rèn)，同時(shí)攜帶要發(fā)送給 Server 的數(shù)據(jù)。ACK 置 1 表示確認(rèn)號(hào) ack= y + 1 有效（代表期望收到服務(wù)器的第 1 個(gè)包），Client自己的序號(hào) seq= x + 1（表示這就是我的第1個(gè)包，相對(duì)于第0個(gè)包來說的），一旦收到Client的確認(rèn)之后，這個(gè)TCP連接就進(jìn)入 Established 狀態(tài)，就可以發(fā)起請(qǐng)求了。

具體流程可以參看《TCP、UDP、HTTP、HTTPS》。

四、Nginx 反向代理

1、反向代理

反向代理（Reverse Proxy）方式是指：代理服務(wù)器來接受 Internet 上的連接請(qǐng)求，然后將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從內(nèi)部網(wǎng)絡(luò)上服務(wù)器得到的結(jié)果返回給 Internet 上請(qǐng)求連接的客戶端。此時(shí)代理服務(wù)器對(duì)外就表現(xiàn)為一個(gè)服務(wù)器，反向代理服務(wù)器對(duì)于客戶端而言它就像是原始服務(wù)器，并且客戶端不需要進(jìn)行任何特別的設(shè)置。

反向代理的作用：

1. 保證內(nèi)網(wǎng)的安全，可以使用反向代理提供 WAF 功能，阻止 Web 攻擊。
2. 負(fù)載均衡，通過反向代理服務(wù)器來優(yōu)化網(wǎng)站的負(fù)載。

2、正向代理

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

正向代理（Forward Proxy）通常都被簡(jiǎn)稱為代理，就是在用戶無法正常訪問外部資源，可以通過代理的方式，讓用戶繞過防火墻，從而連接到目標(biāo)網(wǎng)絡(luò)或者服務(wù)。

正向代理的工作原理就像一個(gè)跳板。

比如：我訪問不了 Google，但是我能訪問一個(gè)代理服務(wù)器 A，A 能訪問 Google，于是我先連上代理服務(wù)器 A，告訴它我需要 Google 的內(nèi)容，A 就去取回來，然后返回給我。

從網(wǎng)站的角度，只在代理服務(wù)器來取內(nèi)容的時(shí)候有一次記錄，有時(shí)候并不知道是用戶的請(qǐng)求，也隱藏了用戶的資料，這取決于代理告不告訴網(wǎng)站。

正向代理是一個(gè)位于客戶端和原始服務(wù)器 (origin server) 之間的服務(wù)器。為了從原始服務(wù)器取得內(nèi)容，客戶端向代理發(fā)送一個(gè)請(qǐng)求并指定目標(biāo) (原始服務(wù)器)，然后代理向原始服務(wù)器轉(zhuǎn)交請(qǐng)求并將獲得的內(nèi)容返回給客戶端。

3、正向代理與反向代理對(duì)比

正向代理與反向代理

五、關(guān)閉 TCP 連接

這一步不是所有的網(wǎng)頁都會(huì)這么做，例如網(wǎng)頁版微信就沒有關(guān)閉 TCP 連接，因?yàn)槲⑿派蟿e人可以隨時(shí)發(fā)消息給你，實(shí)際上別人先把消息發(fā)送到了微信服務(wù)器，微信服務(wù)器再通過 TCP 鏈接，把消息推送到你的屏幕上。

試想一下，如果網(wǎng)頁版微信關(guān)閉了 TCP 連接會(huì)怎樣？

結(jié)果是：你不刷新網(wǎng)頁，就永遠(yuǎn)收不到消息了。同時(shí)，如果你頻繁的發(fā)消息給別人，那么就在頻繁的創(chuàng)建連接，關(guān)閉連接，這是很消耗資源的。所以微信就干脆不關(guān)閉 TCP 連接，這樣微信服務(wù)器就可以給我們的瀏覽器發(fā)消息。

下圖是一次 HTTP 請(qǐng)求報(bào)文頭部信息，其中 Connection: keep-alive 意味著這次請(qǐng)求結(jié)束后不會(huì)關(guān)閉 TCP 連接。

Connection

當(dāng)然不是所有的 HTTP 請(qǐng)求都沒有關(guān)閉連接，例如一篇博文，瀏覽器收到數(shù)據(jù)顯示就可以了，沒有那么多動(dòng)態(tài)數(shù)據(jù)，我看完就關(guān)了，這時(shí)就應(yīng)該關(guān)閉 TCP 連接，當(dāng)然這還是取決于請(qǐng)求的服務(wù)器。說了這么多，還沒說關(guān)閉連接。

關(guān)閉 TCP 連接專業(yè)點(diǎn)說叫做“四次揮手”，與 TCP 建立連接的“三次握手”相對(duì)應(yīng)。

由于TCP連接是全雙工的，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè) FIN 來終止這個(gè)方向的連接。收到一個(gè) FIN 只意味著這一方向上沒有數(shù)據(jù)流動(dòng)，一個(gè) TCP 連接在收到一個(gè) FIN 后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方執(zhí)行被動(dòng)關(guān)閉。

四次揮手

具體流程可以參看《TCP、UDP、HTTP、HTTPS》。

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