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

圖 2
第一步是找出所訪問(wèn)域名對(duì)應(yīng)的IP地址，按以下順序循環(huán)查找DNS記錄：
◆瀏覽器緩存 - 瀏覽器會(huì)緩存DNS記錄一段時(shí)間，有趣的是，操作系統(tǒng)不會(huì)告訴瀏覽器每條DNS記錄的存活時(shí)間，瀏覽器按照固定的周期進(jìn)行緩存（每種瀏覽器的保留時(shí)間從2-30分鐘長(zhǎng)度不定）。
◆操作系統(tǒng)緩存 - 如果瀏覽器緩存中沒(méi)有要找的記錄，瀏覽器會(huì)產(chǎn)生一個(gè)系統(tǒng)調(diào)用（在Windows中是gethostbyname），操作系統(tǒng)有它自己的緩存。
◆路由器緩存 - 請(qǐng)求繼續(xù)來(lái)到你的路由器，路由器通常也有自己的DNS緩存。
◆ISP DNS緩存 - 下一步要檢查的是ISP的DNS服務(wù)器，當(dāng)然也是有緩存的。
◆遞歸查找 - ISP的DNS服務(wù)器開(kāi)始一個(gè)遞歸查找，從根域服務(wù)器開(kāi)始，到.com頂級(jí)域名服務(wù)器，再到Facebook的域名服務(wù)器，正常情況下，DNS服務(wù)器將會(huì)緩存.com域名服務(wù)器的名字，因此不一定需要訪問(wèn)根域服務(wù)器。
下面是一個(gè)遞歸DNS查找過(guò)程示意圖：

圖 3
關(guān)于DNS一個(gè)令人擔(dān)心的問(wèn)題是，整個(gè)域名如wikipedia.org或facebook.com只映射到單個(gè)IP地址，幸運(yùn)的是，有許多方法來(lái)消除這個(gè)問(wèn)題。
◆循環(huán)DNS ：DNS查找返回多個(gè)IP地址，例如，facebook.com真實(shí)情況是映射到了4個(gè)IP地址。
◆負(fù)載均衡： 由專用硬件監(jiān)聽(tīng)一個(gè)特定IP地址，然后將請(qǐng)求轉(zhuǎn)發(fā)給其它服務(wù)器，大型網(wǎng)站一般都使用了昂貴的高性能負(fù)載均衡設(shè)備。
◆基于地理位置的DNS： 將域名映射到不同地理位置的IP地址提高擴(kuò)展性，對(duì)于托管靜態(tài)內(nèi)容的服務(wù)器布局來(lái)說(shuō)，這個(gè)方法很有用，不同服務(wù)器之間不需要相互同步狀態(tài)。
◆Anycast（任播）： 它是一種路由技術(shù)，單個(gè)IP地址可以映射到多臺(tái)物理服務(wù)器，遺憾的是，任播對(duì)TCP不友好，在實(shí)際中很少使用。
大多數(shù)DNS服務(wù)器本身使用任播實(shí)現(xiàn)高可用和DNS查找的低延遲。

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

圖 4
Facebook的主頁(yè)是不會(huì)直接從瀏覽器緩存提取的，因?yàn)閯?dòng)態(tài)頁(yè)面要么很快（或立即）過(guò)期，因此瀏覽器將向Facebook服務(wù)器發(fā)送一條請(qǐng)求：
GET http://facebook.com/ HTTP/1.1Accept: 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, deflateConnection:
Keep-AliveHost: facebook.comCookie: datr=1265876274-［...］; locale=en_US;
lsd=WW［...］; c_user=2101［...］
GET請(qǐng)求的URL是"http://facebook.com/"，瀏覽器通過(guò)User-Agent消息頭標(biāo)識(shí)自己，并聲明可接受的響應(yīng)類型（Accept和Accept-Encoding消息頭），Connection消息頭要求服務(wù)器保持TCP連接打開(kāi)，以便處理下一步請(qǐng)求。
請(qǐng)求包含了瀏覽器對(duì)該域名的cookie，你可能已經(jīng)知道，cookie是key-value成對(duì)出現(xiàn)的，它可以跟蹤不同頁(yè)面請(qǐng)求之間網(wǎng)站的狀態(tài)，因此cookie保存了登錄的用戶名，服務(wù)器會(huì)給用戶分配一段密碼數(shù)字，cookie在客戶端上實(shí)際是一個(gè)文本文件，它會(huì)跟隨每個(gè)請(qǐng)求發(fā)給服務(wù)器。
有許多工具可以查看原始HTTP請(qǐng)求和對(duì)應(yīng)的響應(yīng)，我最喜歡的是fiddler，也許你想說(shuō)的是FireBug，沒(méi)錯(cuò)，工具很多，就看個(gè)人喜好了，這些工具都能幫助你優(yōu)化網(wǎng)站。
除了GET請(qǐng)求外，你可能還熟悉另一種類型的請(qǐng)求-
POST請(qǐng)求，它通常用于提交表單，GET請(qǐng)求通過(guò)URL發(fā)送它的參數(shù)（如http://robozzle.com/puzzle.aspx？id=85），POST請(qǐng)求在請(qǐng)求主體中發(fā)送它的參數(shù)。
在URL"http://facebook.com/"中的斜線非常重要，在這里，瀏覽器可以安全地添加斜線，對(duì)于"http://example.com/folderOrFile"這種格式的URL，瀏覽器不能自動(dòng)添加一個(gè)斜線，因?yàn)樯胁磺宄olderOrFile是一個(gè)文件夾還是一個(gè)文件，在這種情況下，瀏覽器不會(huì)擅自添加斜線，服務(wù)器將會(huì)以重定向作為響應(yīng)，導(dǎo)致不必要的來(lái)回通信。
4、Facebook服務(wù)器以一個(gè)永久重定向響應(yīng)

圖 5
下面是Facebook服務(wù)器向?yàn)g覽器請(qǐng)求發(fā)回的響應(yīng)：
HTTP/1.1 301 Moved PermanentlyCache-Control: private, no-store, no-cache,
must-revalidate, post-check=0, pre-check=0Expires: Sat, 01 Jan 2000 00:00:00
GMTLocation: http://www.facebook.com/P3P: CP="DSP LAW"Pragma:
no-cacheSet-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50
GMT; path=/; domain=.facebook.com; httponlyContent-Type: text/html;
charset=utf-8X-Cnection: closeDate: Fri, 12 Feb 2010 05:09:51 GMTContent-Length: 0
服務(wù)器以301永久移走響應(yīng)告訴瀏覽器應(yīng)轉(zhuǎn)到"http://www.facebook.com/"而不是"http://facebook.com/"。
你可能會(huì)問(wèn)，為什么服務(wù)器要堅(jiān)持用重定向進(jìn)行響應(yīng)呢？為什么不用用戶想看的網(wǎng)頁(yè)進(jìn)行響應(yīng)呢？
一個(gè)原因是搜索引擎排名，如果相同網(wǎng)頁(yè)有兩個(gè)URL，如http://www.igoro.com/和http://igoro.com/，搜索引擎會(huì)將他倆看作是兩個(gè)不同的網(wǎng)站，分?jǐn)偟矫總€(gè)URL的入站連接就要少得多，從而降低了網(wǎng)站的排名，搜索引擎理解永久重定向（301），將會(huì)把來(lái)自這兩個(gè)源的入站連接合并成一個(gè)排名。
同樣，相同內(nèi)容對(duì)應(yīng)的URL太多也利于緩存，如果某段內(nèi)容有多個(gè)名字，在緩存中可能也會(huì)出現(xiàn)多次。
5、瀏覽器跟隨重定向

圖 6
瀏覽器現(xiàn)在知道"http://www.facebook.com/"才是正確的URL，于是發(fā)出第二個(gè)GET請(qǐng)求。
GET http://www.facebook.com/ HTTP/1.1Accept: application/x-ms-application,
image/jpeg, application/xaml＋xml, ［...］Accept-Language: en-USUser-Agent:
Mozilla/4.0 （compatible; MSIE 8.0; Windows NT 6.1; WOW64; ［...］Accept-Encoding:
gzip, deflateConnection: Keep-AliveCookie: lsd=XW［...］; c_user=21［...］;
x-referer=［...］Host: www.facebook.com
消息頭和第一個(gè)請(qǐng)求的含義一樣，就不再啰嗦了。

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

圖 7
服務(wù)器將會(huì)收到GET請(qǐng)求并進(jìn)行處理，然后發(fā)回響應(yīng)，看起來(lái)是一個(gè)非常簡(jiǎn)單的操作，但實(shí)際上在這個(gè)期間發(fā)生了許多有趣的事情。
◆Web服務(wù)器軟件
Web服務(wù)器軟件（如IIS或Apache）收到HTTP請(qǐng)求后，立即確定由哪個(gè)請(qǐng)求處理程序來(lái)處理這個(gè)請(qǐng)求，請(qǐng)求處理程序讀取請(qǐng)求，生成HTML。
舉一個(gè)最簡(jiǎn)單的例子，請(qǐng)求處理程序可以保存在一個(gè)文件中，其結(jié)構(gòu)和URL結(jié)構(gòu)完全對(duì)應(yīng)，如http://example.com/folder1/page1.aspx
URL映射到文件/httpdocs/folder1/page1.aspx，Web服務(wù)器軟件也可以配置，將URL手工映射到請(qǐng)求處理程序，因此page1.aspx的公共URL應(yīng)該是http://example.com/folder1/page1。
◆請(qǐng)求處理程序
請(qǐng)求處理程序讀取請(qǐng)求，它的參數(shù)和cookie，它可能會(huì)讀取和更新服務(wù)器上的某些數(shù)據(jù)，然后生成一個(gè)HTML頁(yè)面作為響應(yīng)。
每個(gè)動(dòng)態(tài)網(wǎng)站面臨的一個(gè)有趣的困難是如何保存數(shù)據(jù)，小網(wǎng)站通常只有一個(gè)SQL數(shù)據(jù)庫(kù)來(lái)保存數(shù)據(jù)，但大型網(wǎng)站必須將數(shù)據(jù)庫(kù)部署到多臺(tái)服務(wù)器上，解決辦法包括水平分區(qū)（根據(jù)主鍵，將一張表拆分到多個(gè)數(shù)據(jù)庫(kù)），復(fù)制和使用簡(jiǎn)化數(shù)據(jù)庫(kù)（不追求一致性）。
保持?jǐn)?shù)據(jù)廉價(jià)更新的一個(gè)技術(shù)是使用批處理作業(yè)，例如，F(xiàn)acebook會(huì)及時(shí)更新新聞消息源，但"你可能知道"功能可能只需要每晚進(jìn)行更新（我猜的，我也不知道真實(shí)情況如何），批處理作業(yè)更新會(huì)產(chǎn)生一些過(guò)時(shí)的不重要的數(shù)據(jù)，但它使數(shù)據(jù)更新更快，更簡(jiǎn)單。
7、服務(wù)器發(fā)回HTML響應(yīng)

圖 8
下面是服務(wù)器生成并發(fā)回的一個(gè)響應(yīng)：
HTTP/1.1 200 OKCache-Control: private, no-store, no-cache, must-revalidate,
post-check=0, pre-check=0Expires: Sat, 01 Jan 2000 00:00:00 GMTP3P: CP="DSP
LAW"Pragma: no-cacheContent-Encoding: gzipContent-Type: text/html;
charset=utf-8X-Cnection: closeTransfer-Encoding: chunkedDate: Fri, 12 Feb 2010
09:05:55 GMT2b3？？？？？？？？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:...
除了壓縮外，消息頭指定是否以及如何緩存頁(yè)面，cookie設(shè)置（在這個(gè)響應(yīng)中沒(méi)有），隱私信息等等。
注意消息頭中的Content-Typt設(shè)置成text/html了，它告訴瀏覽器以HTML呈現(xiàn)響應(yīng)的內(nèi)容，而不是作為一個(gè)文件下載，瀏覽器通過(guò)消息頭決定如何解釋響應(yīng)的內(nèi)容，但也會(huì)考慮其他因素，如URL擴(kuò)展。
8、瀏覽器開(kāi)始渲染HTML
在瀏覽器未接收完整個(gè)HTML文檔之前，它就開(kāi)始渲染了。

圖 9
9、瀏覽器發(fā)送嵌入到HTML中的對(duì)象請(qǐng)求

圖 10
在瀏覽器渲染HTML時(shí)，它會(huì)發(fā)現(xiàn)還需要訪問(wèn)其它URL，瀏覽器繼續(xù)為這些資源發(fā)出GET請(qǐng)求，下面是我訪問(wèn)facebook.com時(shí)進(jìn)一步訪問(wèn)的一些URL：
◆圖像http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gifhttp://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif…◆CSS樣式表http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.csshttp://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css…◆JavaScript文件http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.jshttp://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js…
每個(gè)URL都會(huì)經(jīng)歷訪問(wèn)HTML頁(yè)面類似的過(guò)程，因此，瀏覽器會(huì)在DNS中查找域名，發(fā)送請(qǐng)求，跟隨重定向等。
但靜態(tài)文件 - 和動(dòng)態(tài)頁(yè)面不一樣 - 允許瀏覽器緩存，有些文件在下一次訪問(wèn)時(shí)可直接從瀏覽器緩存中提取，不用聯(lián)系服務(wù)器，瀏覽器知道某個(gè)特定文件的緩存有效期，因?yàn)榈谝淮螐姆?wù)器返回到瀏覽器時(shí)就包含了Expires頭信息，此外，每個(gè)響應(yīng)可能也包含一個(gè)類似版本號(hào)的ETag頭，如果瀏覽器看到一個(gè)ETag，它會(huì)立即停止傳輸文件。
你能猜到URL中的fbcdn.net代表什么嗎？沒(méi)錯(cuò)，它表示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)容通常會(huì)占用網(wǎng)站的大量帶寬，但也很容易被復(fù)制到CDN網(wǎng)絡(luò)中的加速節(jié)點(diǎn)，一般情況下，網(wǎng)站會(huì)使用第三方CDN提供商，而不是自己運(yùn)營(yíng)CDN，例如，F(xiàn)acebook的靜態(tài)文件由世界最大的CDN提供商Akamai托管。
我們還是舉一個(gè)例子，當(dāng)你ping static.ak.fbcdn.net時(shí)，你會(huì)從akamai.net服務(wù)器得到一個(gè)應(yīng)答，同樣，如果你分多次ping URL，可能會(huì)從不同的服務(wù)器得到應(yīng)答，這說(shuō)明背后的負(fù)載均衡正在發(fā)生作用。
10、瀏覽器進(jìn)一步發(fā)送異步（Ajax）請(qǐng)求

圖 11
根據(jù)Web 2.0的精神，即使頁(yè)面渲染完畢后，客戶端也要繼續(xù)和服務(wù)器通信。例如，F(xiàn)acebook chat會(huì)持續(xù)更新你的朋友列表（他們登錄和退出都會(huì)很快反饋給你），在你瀏覽器中執(zhí)行的JavaScript向服務(wù)器發(fā)送一個(gè)異步請(qǐng)求，異步請(qǐng)求是通過(guò)編程實(shí)現(xiàn)的指向特定URL的GET或POST請(qǐng)求，還是以Facebook為例，客戶端向http://www.facebook.com/ajax/chat/buddy_list.php發(fā)送一個(gè)POST請(qǐng)求，獲取你的在線朋友列表。
這種模式有時(shí)指的是Ajax，Ajax表示異步JavaScript和XML，但服務(wù)器不一定非要以XML格式進(jìn)行響應(yīng)，例如，F(xiàn)acebook返回JavaScript代碼片段響應(yīng)異步請(qǐng)求。
Fiddler工具允許你查看瀏覽器發(fā)送的異步請(qǐng)求，實(shí)際上，你不但可以觀察請(qǐng)求，而且還可以修改這些請(qǐng)求并進(jìn)行重發(fā)，因此可以輕松欺騙Ajax請(qǐng)求，許多在線游戲的開(kāi)發(fā)人員也因此而郁悶不已。
Facebook chat提供了一個(gè)有趣的Ajax問(wèn)題示例：將數(shù)據(jù)從服務(wù)器推向客戶端。因?yàn)镠TTP是一個(gè)請(qǐng)求-響應(yīng)協(xié)議，聊天服務(wù)器不能將新消息推送給客戶端，相反，客戶端必須每隔幾秒從服務(wù)器去取數(shù)據(jù)，以了解是否有新消息到達(dá)。
長(zhǎng)輪詢?cè)谶@種情景中對(duì)降低服務(wù)器負(fù)載很有用，輪詢時(shí)如果服務(wù)器沒(méi)有任何新消息，它就不發(fā)回應(yīng)答，同時(shí)，如果該客戶端有新消息到達(dá)，服務(wù)器會(huì)發(fā)現(xiàn)未完成的請(qǐng)求，并返回消息作為響應(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