作為一個軟件開發(fā)者,你一定會對網(wǎng)絡(luò)應(yīng)用如何工作有一個完整的層次化的認(rèn)知符喝,同樣這里也包括這些應(yīng)用所用到的技術(shù):像瀏覽器闪彼,HTTP,HTML协饲,網(wǎng)絡(luò)服務(wù)器畏腕,需求處理等等。
本文將更深入的研究當(dāng)你輸入一個網(wǎng)址的時候茉稠,后臺到底發(fā)生了一件件什么樣的事~
導(dǎo)航的第一步是通過訪問的域名找出其IP地址。DNS查找過程如下:
瀏覽器緩存 –瀏覽器會緩存DNS記錄一段時間而线。 有趣的是铭污,操作系統(tǒng)沒有告訴瀏覽器儲存DNS記錄的時間,這樣不同瀏覽器會儲存?zhèn)€自固定的一個時間(2分鐘到30分鐘不等)吞获。
系統(tǒng)緩存– 如果在瀏覽器緩存里沒有找到需要的記錄况凉,瀏覽器會做一個系統(tǒng)調(diào)用(windows里是gethostbyname)谚鄙。這樣便可獲得系統(tǒng)緩存中的記錄各拷。
路由器緩存– 接著,前面的查詢請求發(fā)向路由器闷营,它一般會有自己的DNS緩存烤黍。
ISP DNS 緩存– 接下來要check的就是ISP緩存DNS的服務(wù)器知市。在這一般都能找到相應(yīng)的緩存記錄。
遞歸搜索– 你的ISP的DNS服務(wù)器從跟域名服務(wù)器開始進(jìn)行遞歸搜索速蕊,從.com頂級域名服務(wù)器到Facebook的域名服務(wù)器嫂丙。一般DNS服務(wù)器的緩存中會有.com域名服務(wù)器中的域名,所以到頂級服務(wù)器的匹配過程不是那么必要了规哲。
DNS遞歸查找如下圖所示:
DNS有一點令人擔(dān)憂跟啤,這就是像wikipedia.org 或者 facebook.com這樣的整個域名看上去只是對應(yīng)一個單獨的IP地址。還好唉锌,有幾種方法可以消除這個瓶頸:
循環(huán) DNS是DNS查找時返回多個IP時的解決方案隅肥。舉例來說,F(xiàn)acebook.com實際上就對應(yīng)了四個IP地址袄简。
負(fù)載平衡器是以一個特定IP地址進(jìn)行偵聽并將網(wǎng)絡(luò)請求轉(zhuǎn)發(fā)到集群服務(wù)器上的硬件設(shè)備腥放。 一些大型的站點一般都會使用這種昂貴的高性能負(fù)載平衡器赊时。
地理 DNS根據(jù)用戶所處的地理位置鹰祸,通過把域名映射到多個不同的IP地址提高可擴(kuò)展性声登。這樣不同的服務(wù)器不能夠更新同步狀態(tài)隅熙,但映射靜態(tài)內(nèi)容的話非常好咙俩。
Anycast是一個IP地址映射多個物理主機(jī)的路由技術(shù)庭敦。 美中不足务蝠,Anycast與TCP協(xié)議適應(yīng)的不是很好定欧,所以很少應(yīng)用在那些方案中匹耕。
大多數(shù)DNS服務(wù)器使用Anycast來獲得高效低延遲的DNS查找莹规。
3. 瀏覽器給web服務(wù)器發(fā)送一個HTTP請求
因為像Facebook主頁這樣的動態(tài)頁面,打開后在瀏覽器緩存中很快甚至馬上就會過期泌神,毫無疑問他們不能從中讀取良漱。
所以,瀏覽器將把一下請求發(fā)送到Facebook所在的服務(wù)器:
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頭)母市, 和它希望接受什么類型的相應(yīng) (AcceptandAccept-Encoding頭).Connection頭要求服務(wù)器為了后邊的請求不要關(guān)閉TCP連接。
請求中也包含瀏覽器存儲的該域名的cookies损趋』季茫可能你已經(jīng)知道,在不同頁面請求當(dāng)中浑槽,cookies是與跟蹤一個網(wǎng)站狀態(tài)相匹配的鍵值蒋失。這樣cookies會存儲登錄用戶名,服務(wù)器分配的密碼和一些用戶設(shè)置等桐玻。Cookies會以文本文檔形式存儲在客戶機(jī)里篙挽,每次請求時發(fā)送給服務(wù)器。
用來看原始HTTP請求及其相應(yīng)的工具很多镊靴。作者比較喜歡使用fiddler铣卡,當(dāng)然也有像FireBug這樣其他的工具链韭。這些軟件在網(wǎng)站優(yōu)化時會幫上很大忙。
除了獲取請求煮落,還有一種是發(fā)送請求敞峭,它常在提交表單用到。發(fā)送請求通過URL傳遞其參數(shù)(e.g.: http://robozzle.com/puzzle.aspx?id=85)蝉仇。發(fā)送請求在請求正文頭之后發(fā)送其參數(shù)旋讹。
像“http://facebook.com/”中的斜杠是至關(guān)重要的。這種情況下轿衔,瀏覽器能安全的添加斜杠骗村。而像“http: //example.com/folderOrFile”這樣的地址,因為瀏覽器不清楚folderOrFile到底是文件夾還是文件呀枢,所以不能自動添加 斜杠胚股。這時,瀏覽器就不加斜杠直接訪問地址裙秋,服務(wù)器會響應(yīng)一個重定向琅拌,結(jié)果造成一次不必要的握手。
4. facebook服務(wù)的永久重定向響應(yīng)
圖中所示為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ù)器給瀏覽器響應(yīng)一個301永久重定向響應(yīng)摘刑,這樣瀏覽器就會訪問“http://www.facebook.com/” 而非“http://facebook.com/”进宝。
為什么服務(wù)器一定要重定向而不是直接發(fā)會用戶想看的網(wǎng)頁內(nèi)容呢?這個問題有好多有意思的答案枷恕。
其中一個原因跟搜索引擎排名有 關(guān)党晋。你看,如果一個頁面有兩個地址徐块,就像http://www.igoro.com/ 和http://igoro.com/未玻,搜索引擎會認(rèn)為它們是兩個網(wǎng)站,結(jié)果造成每一個的搜索鏈接都減少從而降低排名胡控。而搜索引擎知道301永久重定向是 什么意思扳剿,這樣就會把訪問帶www的和不帶www的地址歸到同一個網(wǎng)站排名下。
還有一個是用不同的地址會造成緩存友好性變差昼激。當(dāng)一個頁面有好幾個名字時庇绽,它可能會在緩存里出現(xiàn)好幾次。
現(xiàn)在橙困,瀏覽器知道了“http://www.facebook.com/”才是要訪問的正確地址瞧掺,所以它會發(fā)送另一個獲取請求:
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
頭信息以之前請求中的意義相同。
服務(wù)器接收到獲取請求凡傅,然后處理并返回一個響應(yīng)辟狈。
這表面上看起來是一個順向的任務(wù),但其實這中間發(fā)生了很多有意思的東西- 就像作者博客這樣簡單的網(wǎng)站像捶,何況像facebook那樣訪問量大的網(wǎng)站呢!
Web 服務(wù)器軟件
web服務(wù)器軟件(像IIS和阿帕奇)接收到HTTP請求,然后確定執(zhí)行什么請求處理來處理它懂鸵。請求處理就是一個能夠讀懂請求并且能生成HTML來進(jìn)行響應(yīng)的程序(像ASP.NET,PHP,RUBY...)。
舉 個最簡單的例子,需求處理可以以映射網(wǎng)站地址結(jié)構(gòu)的文件層次存儲。像http://example.com/folder1/page1.aspx這個地 址會映射/httpdocs/folder1/page1.aspx這個文件。web服務(wù)器軟件可以設(shè)置成為地址人工的對應(yīng)請求處理酱虎,這樣 page1.aspx的發(fā)布地址就可以是http://example.com/folder1/page1爹土。
請求處理
請求處理閱讀請求及它的參數(shù)和cookies琼娘。它會讀取也可能更新一些數(shù)據(jù),并講數(shù)據(jù)存儲在服務(wù)器上俯在。然后跷乐,需求處理會生成一個HTML響應(yīng)肥败。
所 有動態(tài)網(wǎng)站都面臨一個有意思的難點 -如何存儲數(shù)據(jù)。小網(wǎng)站一半都會有一個SQL數(shù)據(jù)庫來存儲數(shù)據(jù)愕提,存儲大量數(shù)據(jù)和/或訪問量大的網(wǎng)站不得不找一些辦法把數(shù)據(jù)庫分配到多臺機(jī)器上拙吉。解決方案 有:sharding (基于主鍵值講數(shù)據(jù)表分散到多個數(shù)據(jù)庫中),復(fù)制揪荣,利用弱語義一致性的簡化數(shù)據(jù)庫筷黔。
委 托工作給批處理是一個廉價保持?jǐn)?shù)據(jù)更新的技術(shù)。舉例來講仗颈,F(xiàn)ackbook得及時更新新聞feed佛舱,但數(shù)據(jù)支持下的“你可能認(rèn)識的人”功能只需要每晚更新 (作者猜測是這樣的,改功能如何完善不得而知)挨决。批處理作業(yè)更新會導(dǎo)致一些不太重要的數(shù)據(jù)陳舊请祖,但能使數(shù)據(jù)更新耕作更快更簡潔。
7. 服務(wù)器發(fā)回一個HTML響應(yīng)
圖中為服務(wù)器生成并返回的響應(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
2b3Tn@[...]
整個響應(yīng)大小為35kB脖祈,其中大部分在整理后以blob類型傳輸肆捕。
內(nèi)容編碼頭告訴瀏覽器整個響應(yīng)體用gzip算法進(jìn)行壓縮。解壓blob塊后盖高,你可以看到如下期望的HTML:
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
lang="en" id="facebook" class=" no_js">
...
關(guān)于壓縮慎陵,頭信息說明了是否緩存這個頁面,如果緩存的話如何去做喻奥,有什么cookies要去設(shè)置(前面這個響應(yīng)里沒有這點)和隱私信息等等席纽。
請注意報頭中把Content-type設(shè)置為“text/html”。報頭讓瀏覽器將該響應(yīng)內(nèi)容以HTML形式呈現(xiàn)撞蚕,而不是以文件形式下載它润梯。瀏覽器會根據(jù)報頭信息決定如何解釋該響應(yīng),不過同時也會考慮像URL擴(kuò)展內(nèi)容等其他因素。
在瀏覽器沒有完整接受全部HTML文檔時纺铭,它就已經(jīng)開始顯示這個頁面了:
在瀏覽器顯示HTML時寇钉,它會注意到需要獲取其他地址內(nèi)容的標(biāo)簽。這時舶赔,瀏覽器會發(fā)送一個獲取請求來重新獲得這些文件扫倡。
下面是幾個我們訪問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
…
這些地址都要經(jīng)歷一個和HTML讀取類似的過程。所以瀏覽器會在DNS中查找這些域名顿痪,發(fā)送請求镊辕,重定向等等...
但 不像動態(tài)頁面那樣油够,靜態(tài)文件會允許瀏覽器對其進(jìn)行緩存蚁袭。有的文件可能會不需要與服務(wù)器通訊,而從緩存中直接讀取石咬。服務(wù)器的響應(yīng)中包含了靜態(tài)文件保存的期限 信息揩悄,所以瀏覽器知道要把它們緩存多長時間。還有鬼悠,每個響應(yīng)都可能包含像版本號一樣工作的ETag頭(被請求變量的實體值)删性,如果瀏覽器觀察到文件的版本 ETag信息已經(jīng)存在,就馬上停止這個文件的傳輸焕窝。
試著猜猜看“fbcdn.NET”在地址中代表什么蹬挺?聰明的答案是"Facebook內(nèi)容分發(fā)網(wǎng)絡(luò)"。Facebook利用內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN)分發(fā)像圖片它掂,CSS表和JavaScript文件這些靜態(tài)文件巴帮。所以,這些文件會在全球很多CDN的數(shù)據(jù)中心中留下備份虐秋。
靜態(tài)內(nèi)容往往代表站點的帶寬大小榕茧,也能通過CDN輕松的復(fù)制。通常網(wǎng)站會使用第三方的CDN客给。例如用押,F(xiàn)acebook的靜態(tài)文件由最大的CDN提供商Akamai來托管。
舉例來講靶剑,當(dāng)你試著ping static.ak.fbcdn.Net的時候蜻拨,可能會從某個akamai.net服務(wù)器上獲得響應(yīng)。有意思的是桩引,當(dāng)你同樣再ping一次的時候官觅,響應(yīng)的服務(wù)器可能就不一樣,這說明幕后的負(fù)載平衡開始起作用了阐污。
在Web 2.0偉大精神的指引下休涤,頁面顯示完成后客戶端仍與服務(wù)器端保持著聯(lián)系。
以 Facebook聊天功能為例,它會持續(xù)與服務(wù)器保持聯(lián)系來及時更新你那些亮亮灰灰的好友狀態(tài)功氨。為了更新這些頭像亮著的好友狀態(tài)序苏,在瀏覽器中執(zhí)行的 JavaScript代碼會給服務(wù)器發(fā)送異步請求。這個異步請求發(fā)送給特定的地址捷凄,它是一個按照程式構(gòu)造的獲取或發(fā)送請求忱详。還是在Facebook這個例 子中,客戶端發(fā)送給http://www.facebook.com/ajax/chat/buddy_list.PHP一個發(fā)布請求來獲取你好友里哪個 在線的狀態(tài)信息跺涤。
提起這個模式匈睁,就必須要講講"AJAX"-- “異步JavaScript 和 XML”,雖然服務(wù)器為什么用XML格式來進(jìn)行響應(yīng)也沒有個一清二白的原因桶错。再舉個例子吧航唆,對于異步請求,F(xiàn)acebook會返回一些JavaScript的代碼片段院刁。
除了其他糯钙,fiddler這個工具能夠讓你看到瀏覽器發(fā)送的異步請求。事實上退腥,你不僅可以被動的做為這些請求的看客任岸,還能主動出擊修改和重新發(fā)送它們。AJAX請求這么容易被蒙狡刘,可著實讓那些計分的在線游戲開發(fā)者們郁悶的了享潜。(當(dāng)然,可別那樣騙人家~)
Facebook聊天功能提供了關(guān)于AJAX一個有意思的問題案例:把數(shù)據(jù)從服務(wù)器端推送到客戶端嗅蔬。因為HTTP是一個請求-響應(yīng)協(xié)議剑按,所以聊天服務(wù)器不能把新消息發(fā)給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下服務(wù)器端看自己有沒有新消息购城。
這些情況發(fā)生時長輪詢是個減輕服務(wù)器負(fù)載挺有趣的技術(shù)吕座。如果當(dāng)被輪詢時服務(wù)器沒有新消息,它就不理這個客戶端瘪板。而當(dāng)尚未超時的情況下收到了該客戶的新消息吴趴,服務(wù)器就會找到未完成的請求,把新消息做為響應(yīng)返回給客戶端侮攀。
希望看了本文锣枝,你能明白不同的網(wǎng)絡(luò)模塊是如何協(xié)同工作的