输入URL按下回车后究竟发生了什么
51CTO
黄永兵 译
摘要： 作为一名软件开发或是网络技术人员，你应该对Web应用程序的运行原理和协议交换，以及涉及到的技术：如浏览器、HTTP、HTML、Web服务器和请求处理程序等都有所了解才行。在这篇文章中，我们将深入探讨你访问某个URL时发生的一系列事情。
Abstract：
Key words :
1、你在瀏覽器中輸入某個URL
我們從這里開始：
圖 1
2、瀏覽器查找該域名對應的IP地址
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查找過程示意圖：
第一步是找出所訪問域名對應的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不友好，在實際中很少使用。
大多數DNS服務器本身使用任播實現高可用和DNS查找的低延遲。
關于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不友好，在實際中很少使用。
大多數DNS服務器本身使用任播實現高可用和DNS查找的低延遲。
3、瀏覽器向Web服務器發(fā)送一個HTTP請求
圖 4
Facebook的主頁是不會直接從瀏覽器緩存提取的，因為動態(tài)頁面要么很快（或立即）過期，因此瀏覽器將向Facebook服務器發(fā)送一條請求：
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請求的URL是"http://facebook.com/"，瀏覽器通過User-Agent消息頭標識自己，并聲明可接受的響應類型（Accept和Accept-Encoding消息頭），Connection消息頭要求服務器保持TCP連接打開，以便處理下一步請求。
請求包含了瀏覽器對該域名的cookie，你可能已經知道，cookie是key-value成對出現的，它可以跟蹤不同頁面請求之間網站的狀態(tài)，因此cookie保存了登錄的用戶名，服務器會給用戶分配一段密碼數字，cookie在客戶端上實際是一個文本文件，它會跟隨每個請求發(fā)給服務器。
有許多工具可以查看原始HTTP請求和對應的響應，我最喜歡的是fiddler，也許你想說的是FireBug，沒錯，工具很多，就看個人喜好了，這些工具都能幫助你優(yōu)化網站。
除了GET請求外，你可能還熟悉另一種類型的請求-
POST請求，它通常用于提交表單，GET請求通過URL發(fā)送它的參數（如http://robozzle.com/puzzle.aspx？id=85），POST請求在請求主體中發(fā)送它的參數。
在URL"http://facebook.com/"中的斜線非常重要，在這里，瀏覽器可以安全地添加斜線，對于"http://example.com/folderOrFile"這種格式的URL，瀏覽器不能自動添加一個斜線，因為尚不清楚folderOrFile是一個文件夾還是一個文件，在這種情況下，瀏覽器不會擅自添加斜線，服務器將會以重定向作為響應，導致不必要的來回通信。
4、Facebook服務器以一個永久重定向響應
Facebook的主頁是不會直接從瀏覽器緩存提取的，因為動態(tài)頁面要么很快（或立即）過期，因此瀏覽器將向Facebook服務器發(fā)送一條請求：
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請求的URL是"http://facebook.com/"，瀏覽器通過User-Agent消息頭標識自己，并聲明可接受的響應類型（Accept和Accept-Encoding消息頭），Connection消息頭要求服務器保持TCP連接打開，以便處理下一步請求。
請求包含了瀏覽器對該域名的cookie，你可能已經知道，cookie是key-value成對出現的，它可以跟蹤不同頁面請求之間網站的狀態(tài)，因此cookie保存了登錄的用戶名，服務器會給用戶分配一段密碼數字，cookie在客戶端上實際是一個文本文件，它會跟隨每個請求發(fā)給服務器。
有許多工具可以查看原始HTTP請求和對應的響應，我最喜歡的是fiddler，也許你想說的是FireBug，沒錯，工具很多，就看個人喜好了，這些工具都能幫助你優(yōu)化網站。
除了GET請求外，你可能還熟悉另一種類型的請求-
POST請求，它通常用于提交表單，GET請求通過URL發(fā)送它的參數（如http://robozzle.com/puzzle.aspx？id=85），POST請求在請求主體中發(fā)送它的參數。
在URL"http://facebook.com/"中的斜線非常重要，在這里，瀏覽器可以安全地添加斜線，對于"http://example.com/folderOrFile"這種格式的URL，瀏覽器不能自動添加一個斜線，因為尚不清楚folderOrFile是一個文件夾還是一個文件，在這種情況下，瀏覽器不會擅自添加斜線，服務器將會以重定向作為響應，導致不必要的來回通信。
4、Facebook服務器以一個永久重定向響應
圖 5
下面是Facebook服務器向瀏覽器請求發(fā)回的響應：
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
服務器以301永久移走響應告訴瀏覽器應轉到"http://www.facebook.com/"而不是"http://facebook.com/"。
你可能會問，為什么服務器要堅持用重定向進行響應呢？為什么不用用戶想看的網頁進行響應呢？
一個原因是搜索引擎排名，如果相同網頁有兩個URL，如http://www.igoro.com/和http://igoro.com/，搜索引擎會將他倆看作是兩個不同的網站，分攤到每個URL的入站連接就要少得多，從而降低了網站的排名，搜索引擎理解永久重定向（301），將會把來自這兩個源的入站連接合并成一個排名。
同樣，相同內容對應的URL太多也利于緩存，如果某段內容有多個名字，在緩存中可能也會出現多次。
5、瀏覽器跟隨重定向
下面是Facebook服務器向瀏覽器請求發(fā)回的響應：
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
服務器以301永久移走響應告訴瀏覽器應轉到"http://www.facebook.com/"而不是"http://facebook.com/"。
你可能會問，為什么服務器要堅持用重定向進行響應呢？為什么不用用戶想看的網頁進行響應呢？
一個原因是搜索引擎排名，如果相同網頁有兩個URL，如http://www.igoro.com/和http://igoro.com/，搜索引擎會將他倆看作是兩個不同的網站，分攤到每個URL的入站連接就要少得多，從而降低了網站的排名，搜索引擎理解永久重定向（301），將會把來自這兩個源的入站連接合并成一個排名。
同樣，相同內容對應的URL太多也利于緩存，如果某段內容有多個名字，在緩存中可能也會出現多次。
5、瀏覽器跟隨重定向
圖 6
瀏覽器現在知道"http://www.facebook.com/"才是正確的URL，于是發(fā)出第二個GET請求。
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
消息頭和第一個請求的含義一樣，就不再啰嗦了。
瀏覽器現在知道"http://www.facebook.com/"才是正確的URL，于是發(fā)出第二個GET請求。
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
消息頭和第一個請求的含義一樣，就不再啰嗦了。
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。
◆請求處理程序
請求處理程序讀取請求，它的參數和cookie，它可能會讀取和更新服務器上的某些數據，然后生成一個HTML頁面作為響應。
每個動態(tài)網站面臨的一個有趣的困難是如何保存數據，小網站通常只有一個SQL數據庫來保存數據，但大型網站必須將數據庫部署到多臺服務器上，解決辦法包括水平分區(qū)（根據主鍵，將一張表拆分到多個數據庫），復制和使用簡化數據庫（不追求一致性）。
保持數據廉價更新的一個技術是使用批處理作業(yè)，例如，Facebook會及時更新新聞消息源，但"你可能知道"功能可能只需要每晚進行更新（我猜的，我也不知道真實情況如何），批處理作業(yè)更新會產生一些過時的不重要的數據，但它使數據更新更快，更簡單。
7、服務器發(fā)回HTML響應
服務器將會收到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。
◆請求處理程序
請求處理程序讀取請求，它的參數和cookie，它可能會讀取和更新服務器上的某些數據，然后生成一個HTML頁面作為響應。
每個動態(tài)網站面臨的一個有趣的困難是如何保存數據，小網站通常只有一個SQL數據庫來保存數據，但大型網站必須將數據庫部署到多臺服務器上，解決辦法包括水平分區(qū)（根據主鍵，將一張表拆分到多個數據庫），復制和使用簡化數據庫（不追求一致性）。
保持數據廉價更新的一個技術是使用批處理作業(yè)，例如，Facebook會及時更新新聞消息源，但"你可能知道"功能可能只需要每晚進行更新（我猜的，我也不知道真實情況如何），批處理作業(yè)更新會產生一些過時的不重要的數據，但它使數據更新更快，更簡單。
7、服務器發(fā)回HTML響應
圖 8
下面是服務器生成并發(fā)回的一個響應：
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:...
除了壓縮外，消息頭指定是否以及如何緩存頁面，cookie設置（在這個響應中沒有），隱私信息等等。
注意消息頭中的Content-Typt設置成text/html了，它告訴瀏覽器以HTML呈現響應的內容，而不是作為一個文件下載，瀏覽器通過消息頭決定如何解釋響應的內容，但也會考慮其他因素，如URL擴展。
8、瀏覽器開始渲染HTML
在瀏覽器未接收完整個HTML文檔之前，它就開始渲染了。
下面是服務器生成并發(fā)回的一個響應：
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:...
除了壓縮外，消息頭指定是否以及如何緩存頁面，cookie設置（在這個響應中沒有），隱私信息等等。
注意消息頭中的Content-Typt設置成text/html了，它告訴瀏覽器以HTML呈現響應的內容，而不是作為一個文件下載，瀏覽器通過消息頭決定如何解釋響應的內容，但也會考慮其他因素，如URL擴展。
8、瀏覽器開始渲染HTML
在瀏覽器未接收完整個HTML文檔之前，它就開始渲染了。
圖 9
9、瀏覽器發(fā)送嵌入到HTML中的對象請求
9、瀏覽器發(fā)送嵌入到HTML中的對象請求
圖 10
在瀏覽器渲染HTML時，它會發(fā)現還需要訪問其它URL，瀏覽器繼續(xù)為這些資源發(fā)出GET請求，下面是我訪問facebook.com時進一步訪問的一些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…
每個URL都會經歷訪問HTML頁面類似的過程，因此，瀏覽器會在DNS中查找域名，發(fā)送請求，跟隨重定向等。
但靜態(tài)文件 - 和動態(tài)頁面不一樣 - 允許瀏覽器緩存，有些文件在下一次訪問時可直接從瀏覽器緩存中提取，不用聯系服務器，瀏覽器知道某個特定文件的緩存有效期，因為第一次從服務器返回到瀏覽器時就包含了Expires頭信息，此外，每個響應可能也包含一個類似版本號的ETag頭，如果瀏覽器看到一個ETag，它會立即停止傳輸文件。
你能猜到URL中的fbcdn.net代表什么嗎？沒錯，它表示Facebook內容交付網絡，Facebook使用內容交付網絡（CDN）分發(fā)靜態(tài)內容 - 圖像，樣式表和JavaScript文件，因此，文件將被復制到全球許多服務器上。
靜態(tài)內容通常會占用網站的大量帶寬，但也很容易被復制到CDN網絡中的加速節(jié)點，一般情況下，網站會使用第三方CDN提供商，而不是自己運營CDN，例如，Facebook的靜態(tài)文件由世界最大的CDN提供商Akamai托管。
我們還是舉一個例子，當你ping static.ak.fbcdn.net時，你會從akamai.net服務器得到一個應答，同樣，如果你分多次ping URL，可能會從不同的服務器得到應答，這說明背后的負載均衡正在發(fā)生作用。
10、瀏覽器進一步發(fā)送異步（Ajax）請求
在瀏覽器渲染HTML時，它會發(fā)現還需要訪問其它URL，瀏覽器繼續(xù)為這些資源發(fā)出GET請求，下面是我訪問facebook.com時進一步訪問的一些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…
每個URL都會經歷訪問HTML頁面類似的過程，因此，瀏覽器會在DNS中查找域名，發(fā)送請求，跟隨重定向等。
但靜態(tài)文件 - 和動態(tài)頁面不一樣 - 允許瀏覽器緩存，有些文件在下一次訪問時可直接從瀏覽器緩存中提取，不用聯系服務器，瀏覽器知道某個特定文件的緩存有效期，因為第一次從服務器返回到瀏覽器時就包含了Expires頭信息，此外，每個響應可能也包含一個類似版本號的ETag頭，如果瀏覽器看到一個ETag，它會立即停止傳輸文件。
你能猜到URL中的fbcdn.net代表什么嗎？沒錯，它表示Facebook內容交付網絡，Facebook使用內容交付網絡（CDN）分發(fā)靜態(tài)內容 - 圖像，樣式表和JavaScript文件，因此，文件將被復制到全球許多服務器上。
靜態(tài)內容通常會占用網站的大量帶寬，但也很容易被復制到CDN網絡中的加速節(jié)點，一般情況下，網站會使用第三方CDN提供商，而不是自己運營CDN，例如，Facebook的靜態(tài)文件由世界最大的CDN提供商Akamai托管。
我們還是舉一個例子，當你ping static.ak.fbcdn.net時，你會從akamai.net服務器得到一個應答，同樣，如果你分多次ping URL，可能會從不同的服務器得到應答，這說明背后的負載均衡正在發(fā)生作用。
10、瀏覽器進一步發(fā)送異步（Ajax）請求
圖 11
根據Web 2.0的精神，即使頁面渲染完畢后，客戶端也要繼續(xù)和服務器通信。例如，Facebook chat會持續(xù)更新你的朋友列表（他們登錄和退出都會很快反饋給你），在你瀏覽器中執(zhí)行的JavaScript向服務器發(fā)送一個異步請求，異步請求是通過編程實現的指向特定URL的GET或POST請求，還是以Facebook為例，客戶端向http://www.facebook.com/ajax/chat/buddy_list.php發(fā)送一個POST請求，獲取你的在線朋友列表。
這種模式有時指的是Ajax，Ajax表示異步JavaScript和XML，但服務器不一定非要以XML格式進行響應，例如，Facebook返回JavaScript代碼片段響應異步請求。
Fiddler工具允許你查看瀏覽器發(fā)送的異步請求，實際上，你不但可以觀察請求，而且還可以修改這些請求并進行重發(fā)，因此可以輕松欺騙Ajax請求，許多在線游戲的開發(fā)人員也因此而郁悶不已。
Facebook chat提供了一個有趣的Ajax問題示例：將數據從服務器推向客戶端。因為HTTP是一個請求-響應協(xié)議，聊天服務器不能將新消息推送給客戶端，相反，客戶端必須每隔幾秒從服務器去取數據，以了解是否有新消息到達。
長輪詢在這種情景中對降低服務器負載很有用，輪詢時如果服務器沒有任何新消息，它就不發(fā)回應答，同時，如果該客戶端有新消息到達，服務器會發(fā)現未完成的請求，并返回消息作為響應。
原文出處：http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/
原文名：What really happens when you navigate to a URL
作者：Igor Ostrovsky
根據Web 2.0的精神，即使頁面渲染完畢后，客戶端也要繼續(xù)和服務器通信。例如，Facebook chat會持續(xù)更新你的朋友列表（他們登錄和退出都會很快反饋給你），在你瀏覽器中執(zhí)行的JavaScript向服務器發(fā)送一個異步請求，異步請求是通過編程實現的指向特定URL的GET或POST請求，還是以Facebook為例，客戶端向http://www.facebook.com/ajax/chat/buddy_list.php發(fā)送一個POST請求，獲取你的在線朋友列表。
這種模式有時指的是Ajax，Ajax表示異步JavaScript和XML，但服務器不一定非要以XML格式進行響應，例如，Facebook返回JavaScript代碼片段響應異步請求。
Fiddler工具允許你查看瀏覽器發(fā)送的異步請求，實際上，你不但可以觀察請求，而且還可以修改這些請求并進行重發(fā)，因此可以輕松欺騙Ajax請求，許多在線游戲的開發(fā)人員也因此而郁悶不已。
Facebook chat提供了一個有趣的Ajax問題示例：將數據從服務器推向客戶端。因為HTTP是一個請求-響應協(xié)議，聊天服務器不能將新消息推送給客戶端，相反，客戶端必須每隔幾秒從服務器去取數據，以了解是否有新消息到達。
長輪詢在這種情景中對降低服務器負載很有用，輪詢時如果服務器沒有任何新消息，它就不發(fā)回應答，同時，如果該客戶端有新消息到達，服務器會發(fā)現未完成的請求，并返回消息作為響應。
原文出處：http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/
原文名：What really happens when you navigate to a URL
作者：Igor Ostrovsky
此內容為AET網站原創(chuàng)，未經授權禁止轉載。