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

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

我們從這里開始：

圖 1

2、瀏覽器查找該域名對應的IP地址

圖 2

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

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

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

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

◆ISP DNS緩存 - 下一步要檢查的是ISP的DNS服務器，當然也是有緩存的。

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

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

圖 3

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

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

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

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

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

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

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

圖 4#p#

Facebook的主頁是不會直接從瀏覽器緩存提取的，因為動態(tài)頁面要么很快（或立即）過期，因此瀏覽器將向Facebook服務器發(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消息頭標識自己，并聲明可接受的響應類型（Accept和Accept-Encoding消息頭），Connection消息頭要求服務器保持TCP連接打開，以便處理下一步請求。

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

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

除了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是一個文件夾還是一個文件，在這種情況下，瀏覽器不會擅自添加斜線，服務器將會以重定向作為響應，導致不必要的來回通信。

4、Facebook服務器以一個永久重定向響應

圖 5

下面是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/"。

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

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

同樣，相同內容對應的URL太多也利于緩存，如果某段內容有多個名字，在緩存中可能也會出現(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、服務器處理請求

圖 7

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

◆Web服務器軟件

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

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

◆請求處理程序

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

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

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

7、服務器發(fā)回HTML響應

圖 8

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

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設置（在這個響應中沒有），隱私信息等等。

注意消息頭中的Content-Typt設置成text/html了，它告訴瀏覽器以HTML呈現(xiàn)響應的內容，而不是作為一個文件下載，瀏覽器通過消息頭決定如何解釋響應的內容，但也會考慮其他因素，如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都會經歷訪問HTML頁面類似的過程，因此，瀏覽器會在DNS中查找域名，發(fā)送請求，跟隨重定向等。

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

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

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

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

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

圖 11

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

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

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

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

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

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

原文出處：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獨家譯稿，非經授權謝絕轉載！合作媒體轉載請注明原文出處及出處！】