當你輸入一個網址的時候，實際會發(fā)生什么?2010-02-25原文:http://igoro.com/archive/what-really-happens-when-you-navigate-to-a

當你輸入一個網址的時候，實際會發(fā)生什么?

2010-02-25

原文:http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/

作為一個軟件開發(fā)者，你一定會對網絡應用如何工作有一個完整的層次化的認知，同樣這里也包括這些應用所用到的技術：像瀏覽器，HTTP ，HTML ，網絡服務器，需求處理等等。

本文將更深入的研究當你輸入一個網址的時候，后臺到底發(fā)生了一件件什么樣的事～

1. 首先嘛，你得在瀏覽器里輸入要網址

:

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

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

? 瀏覽器緩存 –瀏覽器會緩存DNS 記錄一段時間。 有趣的是，操作系統(tǒng)沒有告訴瀏覽器儲存DNS 記錄的時間，這樣不同瀏覽器會儲存?zhèn)€自固定的一個時間（2分鐘到30分鐘不等）。 ? 系統(tǒng)緩存– 如果在瀏覽器緩存里沒有找到需要的記錄，瀏覽器會做一個系統(tǒng)調用（windows 里是gethostbyname ）。這樣便可獲得系統(tǒng)緩存中的記錄。

?

? 路由器緩存– 接著，前面的查詢請求發(fā)向路由器，它一般會有自己的DNS 緩存。 ISP DNS 緩存– 接下來要check 的就是ISP 緩存DNS 的服務器。在這一般都能找到相應的緩存記錄。

? 遞歸搜索– 你的ISP 的DNS 服務器從跟域名服務器開始進行遞歸搜索，從.com 頂級域名服務器到Facebook 的域名服務器。一般DNS 服務器的緩存中會有.com 域名服務器中的域名，所以到頂級服務器的匹配過程不是那么必要了。

DNS 遞歸查找如下圖所示：

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

? 是DNS 查找時返回多個IP 時的解決方案。舉例來說，Facebook.com 實際上就對應了四個IP 地址。

? 負載平衡器是以一個特定IP 地址進行偵聽并將網絡請求轉發(fā)到集群服務器上的硬件設備。 一些大型的站點一般都會使用這種昂貴的高性能負載平衡器。

? 地理 DNS 根據用戶所處的地理位置，通過把域名映射到多個不同的IP 地址提高可擴展性。這樣不同的服務器不能夠更新同步狀態(tài)，但映射靜態(tài)內容的話非常好。

? 是一個IP 地址映射多個物理主機的路由技術。 美中不足，Anycast 與TCP 協議適應的不是很好，所以很少應用在那些方案中。

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

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

因為像Facebook 主頁這樣的動態(tài)頁面，打開后在瀏覽器緩存中很快甚至馬上就會過期，毫無疑問他們不能從中讀取。

所以，瀏覽器將把一下請求發(fā)送到Facebook 所在的服務器：

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

Accept: application/x-ms-application, image/jpeg, application/xaml xml, [...] User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...] Accept-Encoding: gzip, deflate

Connection: Keep-Alive

Host: facebook.com

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 是與跟蹤一個網站狀態(tài)相匹配的鍵值。這樣cookies 會存儲登錄用戶名，服務器分配的密碼和一些用戶設置等。Cookies 會以文本文檔形式存儲在客戶機里，每次請求時發(fā)送給服務器。

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

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

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

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

圖中所示為Facebook 服務器發(fā)回給瀏覽器的響應：

HTTP/1.1 301 Moved Permanently

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

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

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

P3P: CP="DSP LAW"

Pragma: no-cache

Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT; path=/; domain=.facebook.com; httponly

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

X-Cnection: close

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

Content-Length: 0

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

為什么服務器一定要重定向而不是直接發(fā)會用戶想看的網頁內容呢？這個問題有好多有意思的答案。 其中一個原因跟搜索引擎排名有 關。你看，如果一個頁面有兩個地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎會認為它們是兩個網站，結果造成每一個的搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是 什么意思，這樣就會把訪問帶www 的和不帶www 的地址歸到同一個網站排名下。

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

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

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

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

Accept: application/x-ms-application, image/jpeg, application/xaml xml, [...] Accept-Language: en-US

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...] Accept-Encoding: gzip, deflate

Connection: Keep-Alive

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

Host: www.facebook.com

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

6. 服務器“處理”請求

服務器接收到獲取請求，然后處理并返回一個響應。

這表面上看起來是一個順向的任務，但其實這中間發(fā)生了很多有意思的東西- 就像作者博客這樣簡單的網站，何況像facebook 那樣訪問量大的網站呢！

? Web 服務器軟件web 服務器軟件（像IIS 和阿帕奇）接收到HTTP 請求，然后確定執(zhí)行什么請求處理來處理它。請求處理就是一個能夠讀懂請求并且能生成HTML 來進行響應的程序（像ASP .NET ,PHP ,RUBY ... ）。

舉 個最簡單的例子，需求處理可以以映射網站地址結構的文件層次存儲。像http://example.com/folder1/page1.aspx這個地 址會映射/httpdocs/folder1/page1.aspx這個文件。web 服務器軟件可以設置成為地址人工的對應請求處理，這樣 page1.aspx 的發(fā)布地址就可以是http://example.com/folder1/page1。

? 請求處理請求處理閱讀請求及它的參數和cookies 。它會讀取也可能更新一些數據，并講數據存儲在服務器上。然后，需求處理會生成一個HTML 響應。

所 有動態(tài)網站都面臨一個有意思的難點 -如何存儲數據。小網站一半都會有一個SQL 數據庫來存儲數據，存儲大量數據和/或訪問量大的網站不得不找一些辦法把數據庫分配到多臺機器上。解決方案 有：sharding （基于主鍵值講數據表分散到多個數據庫中），復制，利用弱語義一致性的簡化數據庫。

委 托工作給批處理是一個廉價保持數據更新的技術。舉例來講，Fackbook 得及時更新新聞feed ，但數據支持下的“你可能認識的人”功能只需要每晚更新 （作者猜測是這樣的，改功能如何完善不得而知）。批處理作業(yè)更新會導致一些不太重要的數據陳舊，但能使數據更新耕作更快更簡潔。

7. 服務器發(fā)回一個HTML 響應

圖中為服務器生成并返回的響應：

HTTP/1.1 200 OK

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

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

P3P: CP="DSP LAW"

Pragma: no-cache

Content-Encoding: gzip

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

X-Cnection: close

Transfer-Encoding: chunked

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

2b3Tn@[...]

整個響應大小為35kB ，其中大部分在整理后以blob 類型傳輸。

內容編碼頭告訴瀏覽器整個響應體用gzip 算法進行壓縮。解壓blob 塊后，你可以看到如下期望的HTML ：

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

lang="en" id="facebook" class=" no_js">

...

關于壓縮，頭信息說明了是否緩存這個頁面，如果緩存的話如何去做，有什么cookies 要去設置（前面這個響應里沒有這點）和隱私信息等等。

請注意報頭中把Content-type 設置為“text/html”。報頭讓瀏覽器將該響應內容以HTML 形式呈現，而不是以文件形式下載它。瀏覽器會根據報頭信息決定如何解釋該響應，不過同時也會考慮像URL 擴展內容等其他因素。

8. 瀏覽器開始顯示HTML

在瀏覽器沒有完整接受全部HTML 文檔時，它就已經開始顯示這個頁面了：

9. 瀏覽器發(fā)送獲取嵌入在HTML 中的對象

在瀏覽器顯示HTML 時，它會注意到需要獲取其他地址內容的標簽。這時，瀏覽器會發(fā)送一個獲取

請求來重新獲得這些文件。

下面是幾個我們訪問facebook.com 時需要重獲取的幾個URL ：

? 圖片http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif

…

? CSS 式樣表http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css

…

? JavaScript 文件

…

這些地址都要經歷一個和HTML 讀取類似的過程。所以瀏覽器會在DNS 中查找這些域名，發(fā)送請求，重定向等等...

但 不像動態(tài)頁面那樣，靜態(tài)文件會允許瀏覽器對其進行緩存。有的文件可能會不需要與服務器通訊，而從緩存中直接讀取。服務器的響應中包含了靜態(tài)文件保存的期限 信息，所以瀏覽器知道要把它們緩存多長時間。還有，每個響應都可能包含像版本號一樣工作的ETag 頭（被請求變量的實體值），如果瀏覽器觀察到文件的版本 ETag 信息已經存在，就馬上停止這個文件的傳輸。

試著猜猜看“fbcdn.net ”在地址中代表什么？聰明的答案是"Facebook 內容分發(fā)網絡" 。Facebook 利用內容分發(fā)網絡（CDN ）分發(fā)像圖片，CSS 表和JavaScript 文件這些靜態(tài)文件。所以，這些文件會在全球很多CDN 的數據中心中留下備份。

靜態(tài)內容往往代表站點的帶寬大小，也能通過CDN 輕松的復制。通常網站會使用第三方的CDN 。例如，Facebook 的靜態(tài)文件由最大的CDN 提供商Akamai 來托管。

舉例來講，當你試著ping static.ak.fbcdn.net 的時候，可能會從某個akamai.net 服務器上獲得響應。有意思的是，當你同樣再ping 一次的時候，響應的服務器可能就不一樣，這說明幕后的負載平衡開始起作用了。

10. 瀏覽器發(fā)送異步（AJAX ）請求

在Web 2.0偉大精神的指引下，頁面顯示完成后客戶端仍與服務器端保持著聯系。

以 Facebook 聊天功能為例，它會持續(xù)與服務器保持聯系來及時更新你那些亮亮灰灰的好友狀態(tài)。

為了更新這些頭像亮著的好友狀態(tài)，在瀏覽器中執(zhí)行的 JavaScript 代碼會給服務器發(fā)送異步請求。這個異步請求發(fā)送給特定的地址，它是一個按照程式構造的獲取或發(fā)送請求。還是在Facebook 這個例 子中，客戶端發(fā)送給http://www.facebook.com/ajax/chat/buddy_list.php一個發(fā)布請求來獲取你好友里哪個 在線的狀態(tài)信息。

提起這個模式，就必須要講講"AJAX"-- “異步JavaScript 和 XML ”，雖然服務器為什么用XML 格式來進行響應也沒有個一清二白的原因。再舉個例子吧，對于異步請求，Facebook 會返回一些JavaScript 的代碼片段。

除了其他，fiddler 這個工具能夠讓你看到瀏覽器發(fā)送的異步請求。事實上，你不僅可以被動的做為這些請求的看客，還能主動出擊修改和重新發(fā)送它們。AJAX 請求這么容易被蒙，可著實讓那些計分的在線游戲開發(fā)者們郁悶的了。（當然，可別那樣騙人家~）

Facebook 聊天功能提供了關于AJAX 一個有意思的問題案例：把數據從服務器端推送到客戶端。因為HTTP 是一個請求-響應協議，所以聊天服務器不能把新消息發(fā)給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下服務器端看自己有沒有新消息。

這些情況發(fā)生時長輪詢是個減輕服務器負載挺有趣的技術。如果當被輪詢時服務器沒有新消息，它就不理這個客戶端。而當尚未超時的情況下收到了該客戶的新消息，服務器就會找到未完成的請求，把新消息做為響應返回給客戶端。

總結一下

希望看了本文，你能明白不同的網絡模塊是如何協同工作的