從輸入網址到網頁顯示：DNS查找與請求發送 - 瀏覽器工作原理

（本文轉自http://www.nowamagic.net/academy/detail/48110180）

上一篇文章講到了DNS過濾，那麼如何實現DNS過濾，DNS過濾具體在什麼位置呢？以下是關於瀏覽器的工作流程。

從你在瀏覽器輸入一個網址，到網頁顯示，其中背後發生了什麼呢？接下來的小節裏讓我們好好探討下這個問題。

1. 在瀏覽器裏輸入網址

2. 瀏覽器查找域名的IP地址

導航的第一步是通過訪問的域名找出其IP地址。DNS查找過程如下：

1. 瀏覽器緩存 – 瀏覽器會緩存DNS記錄一段時間。 有趣的是，操作系統沒有告訴瀏覽器儲存DNS記錄的時間，這樣不同瀏覽器會儲存個自固定的一個時間（2分鐘到30分鐘不等）。
2. 系統緩存 – 如果在瀏覽器緩存裏沒有找到需要的記錄，瀏覽器會做一個系統調用（windows裏是gethostbyname）。這樣便可獲得系統緩存中的記錄。
3. 路由器緩存 – 接着，前面的查詢請求發向路由器，它一般會有自己的DNS緩存。
4. ISP DNS 緩存 – 接下來要check的就是ISP緩存DNS的服務器。在這一般都能找到相應的緩存記錄。
5. 遞歸搜索 – 你的ISP的DNS服務器從跟域名服務器開始進行遞歸搜索，從.com頂級域名服務器到Facebook的域名服務器。一般DNS服務器的緩存中會有.com域名服務器中的域名，所以到頂級服務器的匹配過程不是那麼必要了。

DNS遞歸查找如下圖所示：

DNS有一點令人擔憂，這就是像wikipedia.org 或者 facebook.com這樣的整個域名看上去只是對應一個單獨的IP地址。還好，有幾種方法可以消除這個瓶頸：

1. 循環 DNS 是DNS查找時返回多個IP時的解決方案。舉例來說，Facebook.com實際上就對應了四個IP地址。
2. 負載平衡器 是以一個特定IP地址進行偵聽並將網絡請求轉發到集羣服務器上的硬件設備。 一些大型的站點一般都會使用這種昂貴的高性能負載平衡器。
3. 地理 DNS 根據用戶所處的地理位置，通過把域名映射到多個不同的IP地址提高可擴展性。這樣不同的服務器不能夠更新同步狀態，但映射靜態內容的話非常好。
4. Anycast 是一個IP地址映射多個物理主機的路由技術。 美中不足，Anycast與TCP協議適應的不是很好，所以很少應用在那些方案中。

大多數DNS服務器使用Anycast來獲得高效低延遲的DNS查找。

3. 瀏覽器給web服務器發送一個HTTP請求

因爲像Facebook主頁這樣的動態頁面，打開後在瀏覽器緩存中很快甚至馬上就會過期，毫無疑問他們不能從中讀取。所以，瀏覽器將把一下請求發送到Facebook所在的服務器：

1	GET http://facebook.com/ HTTP/1.1

2	Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]

3	User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]

4	Accept-Encoding: gzip, deflate

5	Connection: Keep-Alive

6	Host: facebook.com

7	Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

GET 這個請求定義了要讀取的URL： “http://facebook.com/”。 瀏覽器自身定義 (User-Agent 頭)， 和它希望接受什麼類型的相應 (Accept and Accept-Encoding 頭). Connection頭要求服務器爲了後邊的請求不要關閉TCP連接。

請求中也包含瀏覽器存儲的該域名的cookies。可能你已經知道，在不同頁面請求當中，cookies是與跟蹤一個網站狀態相匹配的鍵值。這樣cookies會存儲登錄用戶名，服務器分配的密碼和一些用戶設置等。Cookies會以文本文檔形式存儲在客戶機裏，每次請求時發送給服務器。

用來看原始HTTP請求及其相應的工具很多。作者比較喜歡使用fiddler，當然也有像FireBug這樣其他的工具。這些軟件在網站優化時會幫上很大忙。

除了獲取請求，還有一種是發送請求，它常在提交表單用到。發送請求通過URL傳遞其參數(e.g.: http://example.com/test.php?id=5)。發送請求在請求正文頭之後發送其參數。

像“http://facebook.com/”中的斜槓是至關重要的。這種情況下，瀏覽器能安全的添加斜槓。而像“http: //example.com/folderOrFile”這樣的地址，因爲瀏覽器不清楚folderOrFile到底是文件夾還是文件，所以不能自動添加 斜槓。這時，瀏覽器就不加斜槓直接訪問地址，服務器會響應一個重定向，結果造成一次不必要的握手。

4. facebook服務的永久重定向響應

圖中所示爲Facebook服務器發回給瀏覽器的響應：

01	HTTP/1.1 301 Moved Permanently

02	Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,

03	pre-check=0

04	Expires: Sat, 01 Jan 2000 00:00:00 GMT

05	Location: http://www.facebook.com/

06	P3P: CP="DSP LAW"

07	Pragma: no-cache

08	Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;

09	path=/; domain=.facebook.com; httponly

10	Content-Type: text/html; charset=utf-8

11	X-Cnection: close

12	Date: Fri, 12 Feb 2010 05:09:51 GMT

13	Content-Length: 0

服務器給瀏覽器響應一個301永久重定向響應，這樣瀏覽器就會訪問“http://www.facebook.com/” 而非“http://facebook.com/”。

爲什麼服務器一定要重定向而不是直接發會用戶想看的網頁內容呢？這個問題有好多有意思的答案。

其中一個原因跟搜索引擎排名有 關。你看，如果一個頁面有兩個地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎會認爲它們是兩個網站，結果造成每一個的搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是 什麼意思，這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。

還有一個是用不同的地址會造成緩存友好性變差。當一個頁面有好幾個名字時，它可能會在緩存裏出現好幾次。

5. 瀏覽器跟蹤重定向地址

現在，瀏覽器知道了“http://www.facebook.com/”纔是要訪問的正確地址，所以它會發送另一個獲取請求：

1	GET http://www.facebook.com/ HTTP/1.1

2	Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]

3	Accept-Language: en-US

4	User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]

5	Accept-Encoding: gzip, deflate

6	Connection: Keep-Alive

7	Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]

8	Host: www.facebook.com

頭信息以之前請求中的意義相同。

至此，服務器那邊纔開始處理生成網頁的請求，這一部分下一小節繼續談。