【51CTO.com 獨家譯稿】作為一名軟件開發(fā)或是網(wǎng)絡(luò)技術(shù)人員，你應(yīng)該對Web應(yīng)用程序的運行原理和協(xié)議交換，以及涉及到的技術(shù)：如瀏覽器、HTTP、HTML、Web服務(wù)器和請求處理程序等都有所了解才行。在這篇文章中，我們將深入探討你訪問某個URL時發(fā)生的一系列事情。

1、你在瀏覽器中輸入某個URL

我們從這里開始：

圖 1

2、瀏覽器查找該域名對應(yīng)的IP地址

圖 2

第一步是找出所訪問域名對應(yīng)的IP地址，按以下順序循環(huán)查找DNS記錄：

◆瀏覽器緩存 - 瀏覽器會緩存DNS記錄一段時間，有趣的是，操作系統(tǒng)不會告訴瀏覽器每條DNS記錄的存活時間，瀏覽器按照固定的周期進行緩存（每種瀏覽器的保留時間從2-30分鐘長度不定）。

◆操作系統(tǒng)緩存 - 如果瀏覽器緩存中沒有要找的記錄，瀏覽器會產(chǎn)生一個系統(tǒng)調(diào)用（在Windows中是gethostbyname），操作系統(tǒng)有它自己的緩存。

◆路由器緩存 - 請求繼續(xù)來到你的路由器，路由器通常也有自己的DNS緩存。

◆ISP DNS緩存 - 下一步要檢查的是ISP的DNS服務(wù)器，當(dāng)然也是有緩存的。

◆遞歸查找 - ISP的DNS服務(wù)器開始一個遞歸查找，從根域服務(wù)器開始，到.com頂級域名服務(wù)器，再到Facebook的域名服務(wù)器，正常情況下，DNS服務(wù)器將會緩存.com域名服務(wù)器的名字，因此不一定需要訪問根域服務(wù)器。

下面是一個遞歸DNS查找過程示意圖：

圖 3

關(guān)于DNS一個令人擔(dān)心的問題是，整個域名如wikipedia.org或facebook.com只映射到單個IP地址，幸運的是，有許多方法來消除這個問題。

◆循環(huán)DNS ：DNS查找返回多個IP地址，例如，facebook.com真實情況是映射到了4個IP地址。

◆負載均衡： 由專用硬件監(jiān)聽一個特定IP地址，然后將請求轉(zhuǎn)發(fā)給其它服務(wù)器，大型網(wǎng)站一般都使用了昂貴的高性能負載均衡設(shè)備。

◆基于地理位置的DNS： 將域名映射到不同地理位置的IP地址提高擴展性，對于托管靜態(tài)內(nèi)容的服務(wù)器布局來說，這個方法很有用，不同服務(wù)器之間不需要相互同步狀態(tài)。

◆Anycast（任播）： 它是一種路由技術(shù)，單個IP地址可以映射到多臺物理服務(wù)器，遺憾的是，任播對TCP不友好，在實際中很少使用。

大多數(shù)DNS服務(wù)器本身使用任播實現(xiàn)高可用和DNS查找的低延遲。

3、瀏覽器向Web服務(wù)器發(fā)送一個HTTP請求

圖 4#p#

Facebook的主頁是不會直接從瀏覽器緩存提取的，因為動態(tài)頁面要么很快（或立即）過期，因此瀏覽器將向Facebook服務(wù)器發(fā)送一條請求：

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消息頭標(biāo)識自己，并聲明可接受的響應(yīng)類型（Accept和Accept-Encoding消息頭），Connection消息頭要求服務(wù)器保持TCP連接打開，以便處理下一步請求。

請求包含了瀏覽器對該域名的cookie，你可能已經(jīng)知道，cookie是key-value成對出現(xiàn)的，它可以跟蹤不同頁面請求之間網(wǎng)站的狀態(tài)，因此cookie保存了登錄的用戶名，服務(wù)器會給用戶分配一段密碼數(shù)字，cookie在客戶端上實際是一個文本文件，它會跟隨每個請求發(fā)給服務(wù)器。

有許多工具可以查看原始HTTP請求和對應(yīng)的響應(yīng)，我最喜歡的是fiddler，也許你想說的是FireBug，沒錯，工具很多，就看個人喜好了，這些工具都能幫助你優(yōu)化網(wǎng)站。

除了GET請求外，你可能還熟悉另一種類型的請求- POST請求，它通常用于提交表單，GET請求通過URL發(fā)送它的參數(shù)（如http://robozzle.com/puzzle.aspx?id=85），POST請求在請求主體中發(fā)送它的參數(shù)。

在URL"http://facebook.com/"中的斜線非常重要，在這里，瀏覽器可以安全地添加斜線，對于"http://example.com/folderOrFile"這種格式的URL，瀏覽器不能自動添加一個斜線，因為尚不清楚folderOrFile是一個文件夾還是一個文件，在這種情況下，瀏覽器不會擅自添加斜線，服務(wù)器將會以重定向作為響應(yīng)，導(dǎo)致不必要的來回通信。

4、Facebook服務(wù)器以一個永久重定向響應(yīng)

圖 5

下面是Facebook服務(wù)器向瀏覽器請求發(fā)回的響應(yīng)：

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

服務(wù)器以301永久移走響應(yīng)告訴瀏覽器應(yīng)轉(zhuǎn)到"http://www.facebook.com/"而不是"http://facebook.com/"。

你可能會問，為什么服務(wù)器要堅持用重定向進行響應(yīng)呢？為什么不用用戶想看的網(wǎng)頁進行響應(yīng)呢？

一個原因是搜索引擎排名，如果相同網(wǎng)頁有兩個URL，如http://www.igoro.com/和http://igoro.com/，搜索引擎會將他倆看作是兩個不同的網(wǎng)站，分?jǐn)偟矫總€URL的入站連接就要少得多，從而降低了網(wǎng)站的排名，搜索引擎理解永久重定向（301），將會把來自這兩個源的入站連接合并成一個排名。

同樣，相同內(nèi)容對應(yīng)的URL太多也利于緩存，如果某段內(nèi)容有多個名字，在緩存中可能也會出現(xiàn)多次。

5、瀏覽器跟隨重定向

圖 6

瀏覽器現(xiàn)在知道"http://www.facebook.com/"才是正確的URL，于是發(fā)出第二個GET請求。

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

消息頭和第一個請求的含義一樣，就不再啰嗦了。#p#

6、服務(wù)器處理請求

圖 7

服務(wù)器將會收到GET請求并進行處理，然后發(fā)回響應(yīng)，看起來是一個非常簡單的操作，但實際上在這個期間發(fā)生了許多有趣的事情。

◆Web服務(wù)器軟件

Web服務(wù)器軟件（如IIS或Apache）收到HTTP請求后，立即確定由哪個請求處理程序來處理這個請求，請求處理程序讀取請求，生成HTML。

舉一個最簡單的例子，請求處理程序可以保存在一個文件中，其結(jié)構(gòu)和URL結(jié)構(gòu)完全對應(yīng)，如http://example.com/folder1/page1.aspx URL映射到文件/httpdocs/folder1/page1.aspx，Web服務(wù)器軟件也可以配置，將URL手工映射到請求處理程序，因此page1.aspx的公共URL應(yīng)該是http://example.com/folder1/page1。

◆請求處理程序

請求處理程序讀取請求，它的參數(shù)和cookie，它可能會讀取和更新服務(wù)器上的某些數(shù)據(jù)，然后生成一個HTML頁面作為響應(yīng)。

每個動態(tài)網(wǎng)站面臨的一個有趣的困難是如何保存數(shù)據(jù)，小網(wǎng)站通常只有一個SQL數(shù)據(jù)庫來保存數(shù)據(jù)，但大型網(wǎng)站必須將數(shù)據(jù)庫部署到多臺服務(wù)器上，解決辦法包括水平分區(qū)（根據(jù)主鍵，將一張表拆分到多個數(shù)據(jù)庫），復(fù)制和使用簡化數(shù)據(jù)庫（不追求一致性）。

保持?jǐn)?shù)據(jù)廉價更新的一個技術(shù)是使用批處理作業(yè)，例如，F(xiàn)acebook會及時更新新聞消息源，但"你可能知道"功能可能只需要每晚進行更新（我猜的，我也不知道真實情況如何），批處理作業(yè)更新會產(chǎn)生一些過時的不重要的數(shù)據(jù)，但它使數(shù)據(jù)更新更快，更簡單。

7、服務(wù)器發(fā)回HTML響應(yīng)

圖 8

下面是服務(wù)器生成并發(fā)回的一個響應(yīng)：

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
2b3????????T?n?@????[...]
The entire response is 36 kB, the bulk of them in the byte blob at the end that I trimmed.
The Content-Encoding header tells the browser that the response body is compressed using the gzip algorithm.
After decompressing the blob, you'll see the HTML you'd expect:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"   
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
      lang="en" id="facebook" class=" no_js">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />
...

除了壓縮外，消息頭指定是否以及如何緩存頁面，cookie設(shè)置（在這個響應(yīng)中沒有），隱私信息等等。

注意消息頭中的Content-Typt設(shè)置成text/html了，它告訴瀏覽器以HTML呈現(xiàn)響應(yīng)的內(nèi)容，而不是作為一個文件下載，瀏覽器通過消息頭決定如何解釋響應(yīng)的內(nèi)容，但也會考慮其他因素，如URL擴展。

8、瀏覽器開始渲染HTML

在瀏覽器未接收完整個HTML文檔之前，它就開始渲染了。

圖 9

9、瀏覽器發(fā)送嵌入到HTML中的對象請求

圖 10#p#

在瀏覽器渲染HTML時，它會發(fā)現(xiàn)還需要訪問其它URL，瀏覽器繼續(xù)為這些資源發(fā)出GET請求，下面是我訪問facebook.com時進一步訪問的一些URL：

◆圖像
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
…
◆CSS樣式表
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
…
◆JavaScript文件
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
…

每個URL都會經(jīng)歷訪問HTML頁面類似的過程，因此，瀏覽器會在DNS中查找域名，發(fā)送請求，跟隨重定向等。

但靜態(tài)文件 - 和動態(tài)頁面不一樣 - 允許瀏覽器緩存，有些文件在下一次訪問時可直接從瀏覽器緩存中提取，不用聯(lián)系服務(wù)器，瀏覽器知道某個特定文件的緩存有效期，因為第一次從服務(wù)器返回到瀏覽器時就包含了Expires頭信息，此外，每個響應(yīng)可能也包含一個類似版本號的ETag頭，如果瀏覽器看到一個ETag，它會立即停止傳輸文件。

你能猜到URL中的fbcdn.net代表什么嗎？沒錯，它表示Facebook內(nèi)容交付網(wǎng)絡(luò)，F(xiàn)acebook使用內(nèi)容交付網(wǎng)絡(luò)（CDN）分發(fā)靜態(tài)內(nèi)容 - 圖像，樣式表和JavaScript文件，因此，文件將被復(fù)制到全球許多服務(wù)器上。

靜態(tài)內(nèi)容通常會占用網(wǎng)站的大量帶寬，但也很容易被復(fù)制到CDN網(wǎng)絡(luò)中的加速節(jié)點，一般情況下，網(wǎng)站會使用第三方CDN提供商，而不是自己運營CDN，例如，F(xiàn)acebook的靜態(tài)文件由世界最大的CDN提供商Akamai托管。

我們還是舉一個例子，當(dāng)你ping static.ak.fbcdn.net時，你會從akamai.net服務(wù)器得到一個應(yīng)答，同樣，如果你分多次ping URL，可能會從不同的服務(wù)器得到應(yīng)答，這說明背后的負載均衡正在發(fā)生作用。

10、瀏覽器進一步發(fā)送異步（Ajax）請求

圖 11

根據(jù)Web 2.0的精神，即使頁面渲染完畢后，客戶端也要繼續(xù)和服務(wù)器通信。

例如，F(xiàn)acebook chat會持續(xù)更新你的朋友列表（他們登錄和退出都會很快反饋給你），在你瀏覽器中執(zhí)行的JavaScript向服務(wù)器發(fā)送一個異步請求，異步請求是通過編程實現(xiàn)的指向特定URL的GET或POST請求，還是以Facebook為例，客戶端向http://www.facebook.com/ajax/chat/buddy_list.php發(fā)送一個POST請求，獲取你的在線朋友列表。

這種模式有時指的是Ajax，Ajax表示異步JavaScript和XML，但服務(wù)器不一定非要以XML格式進行響應(yīng)，例如，F(xiàn)acebook返回JavaScript代碼片段響應(yīng)異步請求。

Fiddler工具允許你查看瀏覽器發(fā)送的異步請求，實際上，你不但可以觀察請求，而且還可以修改這些請求并進行重發(fā)，因此可以輕松欺騙Ajax請求，許多在線游戲的開發(fā)人員也因此而郁悶不已。

Facebook chat提供了一個有趣的Ajax問題示例：將數(shù)據(jù)從服務(wù)器推向客戶端。因為HTTP是一個請求-響應(yīng)協(xié)議，聊天服務(wù)器不能將新消息推送給客戶端，相反，客戶端必須每隔幾秒從服務(wù)器去取數(shù)據(jù)，以了解是否有新消息到達。

長輪詢在這種情景中對降低服務(wù)器負載很有用，輪詢時如果服務(wù)器沒有任何新消息，它就不發(fā)回應(yīng)答，同時，如果該客戶端有新消息到達，服務(wù)器會發(fā)現(xiàn)未完成的請求，并返回消息作為響應(yīng)。

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

原文名：What really happens when you navigate to a URL

作者：Igor Ostrovsky

【51CTO.com獨家譯稿，非經(jīng)授權(quán)謝絕轉(zhuǎn)載！合作媒體轉(zhuǎn)載請注明原文出處及出處！】