CCNP 筆記本

2010 年 04 月 18 日

Http 運作的流程

Filed under: 網路基本服務原理 — nkongkimo @ 01:05:42

為一個軟體發展者,你一定會對網路應用如何工作有一個完整的層次化的認知,同樣這裏也包括這些應用所用到的技術:像本文將更深入的研究當你輸入一個網址的時候,後臺到底發生了一件件什麼樣的事~

1. 首先,你得在流覽器裏輸入網址:

2. 流覽器查找Domain nameIP位址

導航的第一步是通過訪問的Domain name找出其IP位址。DNS查找過程如下:

l 流覽器cache – 流覽器會cache DNS記錄一段時間。 有趣的是作業系統沒有告訴流覽器儲存DNS記錄的時間,這樣不同流覽器會儲存一個固定的時間(2分鐘到30分鐘不等)。

l 系統cache – 如果在流覽器cache裏沒有找到需要的記錄,流覽器會做一個系統調用(windows裏是gethostbyname)。這樣便可獲得系統cache中的記錄。

l 路由器cache– 接著,前面的查詢request發向router,router一般會有自己的DNScache。

l ISP DNS cache– 接下來要check的就是ISP DNS cache server。在這一般都能找到相應的cache記錄。

l 遞迴搜索– ISP的DNS server從root功能變數Name server開始進行遞迴搜索,從.com頂級Domain nameserver到Facebook的Domain nameserver。一般DNSserver的cache中會有.comDomain nameserver中的Domain name,所以到頂級server的匹配過程不是那麼必要了。

DNS遞迴查找如下圖所示:

DNS有一點令人擔憂,這就是像wikipedia.org 或者 facebook.com這樣的整個Domain name看上去只是對應一個單獨的IP位址。還好,有幾種方法可以消除這個issue:

  • 迴圈 DNS 是DNS查找時返回多個IP時的解決方案。舉例來說,Facebook.com實際上就對應了四個IP位址。
  • 負載平衡器 是以一個特定IP位址進行偵聽並將網路request轉發到一群server上。 一些大型的站點一般都會使用這種昂貴的高性能負載平衡器。
  • 地理 DNS 根據client所處的地理位置,通過Domain name映射到多個不同的IP位址提高可擴展性。這樣不同的server不能夠更新同步狀態,但mirror靜態內容的話就非常好。
  • Anycast 是一個IP位址映射多個物理主機的路由技術。 美中不足,Anycast與TCP協議適應的不是很好,所以很少應用在那些方案中。

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

3. 流覽器給web server發送一個HTTP request

因為像Facebook主頁這樣的動態頁面,打開後在流覽器cache中很快甚至馬上就會過期,毫無疑問他們不能從中讀取。

所以,流覽器將把一下請求發送到Facebook所在的server:

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頭要求server為了後邊的請求不要關閉TCP連接。

請求中也包含流覽器存儲的Domain name的cookies。可能你已經知道,在不同頁面請求當中,cookies是與跟蹤一個網站狀態相匹配的鍵值。這樣cookies會存儲登錄用戶名,server分配的密碼和一些用戶設置等。Cookies會以文本文檔形式存儲在客戶機裏,每次請求時發送給server。

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

除了獲取請求,還有一種是發送請求,它常在提交表單用到。發送請求通過URL傳遞其參數(e.g.: http://robozzle.com/puzzle.aspx?id=85)。發送請求在請求正文頭之後發送其參數。
像“http://facebook.com/”中的’/’是至關重要的。這種情況下,流覽器能安全的添加斜杠。而像“http://example.com/folderOrFile”這樣的位址,因為流覽器不清楚folderOrFile到底是檔夾還是檔,所以不能自動添加’/’。這時,流覽器就不加’/’直接訪問位址,server會回應一個重定向,結果造成一次不必要的握手。

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

圖中所示為Facebookserver發回給流覽器的回應:

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

server給流覽器響應一個301永久重定向回應,這樣流覽器就會訪問“http://www.facebook.com/” 而非“http://facebook.com/”。

為什麼server一定要重定向而不是直接發會用戶想看的網頁內容呢?這個問題有好多有意思的答案。

其中一個原因跟搜索引擎排名有關。你看,如果一個頁面有兩個位址,就像http://www.litfresh.com/ http://litfresh.com/,搜索引擎會認為它們是兩個網站,結果造成每一個的搜索鏈結都減少從而降低排名。而搜索引擎知道301永久重定向是什麼意思,這樣就會把訪問帶www的和不帶www的位址歸到同一個網站排名下。

還有一個是用不同的位址會造成cache友好性變差。當一個頁面有好幾個名字時,它可能會在cache裏出現好幾次。


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

現在,流覽器知道了“http://www.facebook.com/”才是要訪問的正確位址,所以它會發送另一個獲取請求:

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: http://www.facebook.com

頭資訊以之前請求中的意義相同。

6. server“處理請求

server接收到獲取請求,然後處理並返回一個response。

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

  • Web server軟體
    webserver軟體(像IIS和aprch)接收到HTTP請求,然後確定執行什麼請求處理來處理它。請求處理就是一個能夠讀懂請求並且能生成HTML來進行回應的程式(像ASP.NET,PHP,RUBY…)。

舉個最簡單的例子,需求處理可以以映射網站位址結構的檔層次存儲。像http://example.com/folder1/page1.aspx這個位址會映射/httpdocs/folder1/page1.aspx這個檔。webserver軟體可以設置成為位址人工的對應請求處理,這樣page1.aspx的發佈位址就可以是http://example.com/folder1/page1。

  • 請求處理
    請求處理閱讀請求及它的參數和cookies。它會讀取也可能更新一些資料,並把資料存儲在server上。然後,需求處理會生成一個HTML回應。

所有動態網站都面臨一個有意思的難點 – 如何存儲資料。小網站一半都會有一個SQL資料庫來存儲資料,存儲大量資料和/或訪問量大的網站不得不找一些辦法把資料庫分配到多台機器上。解決方案有:sharding (基於主鍵值將資料表分散到多個資料庫中),複製,利用弱語義一致性的簡化資料庫。

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

7. server發回一個HTML響應

圖中為server生成並返回的回應:

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�@����[…]

整個回應大小為35kB,其中大部分在整理後以blob類型傳輸。

內容編碼頭告訴流覽器整個回應體用gzip演算法進行壓縮。解壓blob塊後,你可以看到如下期望的HTML:

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
lang="en" id="facebook" class=" no_js">

關於壓縮,頭資訊說明了是否cache這個頁面,如果cache的話如何去做,有什麼cookies要去設置(前面這個回應裏沒有這點)和隱私資訊等等。

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


8. 流覽器開始顯示HTML

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

9. 流覽器發送獲取嵌入在HTML中的物件

在流覽器顯示HTML時,它會注意到需要獲取其他位址內容的標籤。這時,流覽器會發送一個獲取請求來重新獲得這些檔。

下面是幾個我們訪問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
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

這些位址都要經歷一個和HTML讀取類似的過程。所以流覽器會在DNS中查找這些Domain name,發送請求,重定向等等…

但不像動態頁面那樣,靜態檔會允許流覽器對其進行cache。有的檔可能會不需要與server通訊,而從cache中直接讀取。server的回應中包含了靜態檔保存的期限資訊,所以流覽器知道要把它們cache多長時間。還有,每個回應都可能包含像版本號一樣工作的ETag頭(被請求變數的實體值),如果流覽器觀察到檔的版本ETag資訊已經存在,就馬上停止這個檔的傳輸。

試著猜猜看“fbcdn.net”在地址中代表什麼?聰明的答案是"Facebook內容分發網路"。Facebook利用內容分發網路(CDN)分發像圖片,CSS表和JavaScript檔這些靜態檔。所以,這些檔會在全球很多CDN的資料中心中留下備份。

靜態內容往往代表站點的帶寬大小,也能通過CDN輕鬆的複製。通常網站會使用第三方的CDN。例如,Facebook的靜態檔由最大的CDN提供商Akamai來託管。

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

10. 流覽器發送非同步(AJAX)請求

在Web 2.0偉大精神的指引下,頁面顯示完成後用戶端仍與server端保持著聯繫。

以Facebook聊天功能為例,它會持續與server保持聯繫來及時更新你那些好友的狀態。為了更新這些亮著的好友狀態,在流覽器中執行的JavaScript代碼會給server發送非同步請求。這個非同步請求發送給特定的位址,它是一個按照程式構造的獲取或發送請求。還是在Facebook這個例子中,用戶端發送給http://www.facebook.com/ajax/chat/buddy_list.php一個發佈請求來獲取你好友裏哪個線上的狀態資訊。

提起這個模式,就必須要講講"AJAX"– “非同步JavaScript 和 XML”,雖然server為什麼用XML格式來進行回應也沒有個一清二白的原因。再舉個例子吧,對於非同步請求,Facebook會返回一些JavaScript的代碼片段。

除了其他,fiddler這個工具能夠讓你看到流覽器發送的非同步請求。事實上,你不僅可以被動的做為這些請求的看客,還能主動出擊修改和重新發送它們。AJAX請求這麼容易被騙,可著實讓那些計分的線上遊戲開發者們鬱悶的了。(當然,可別那樣騙人家~)

Facebook聊天功能提供了關於AJAX一個有意思的問題案例:把資料從server端推送到用戶端。因為HTTP是一個請求-回應協議,所以聊天server不能把新消息發給客戶。取而代之的是用戶端不得不隔幾秒就輪詢下server端看自己有沒有新消息。

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

廣告

發表迴響 »

仍無迴響。

RSS feed for comments on this post. TrackBack URI

發表迴響

Please log in using one of these methods to post your comment:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

在 WordPress.com 建立免費網站或網誌.

%d 位部落客按了讚: