從輸入網(wǎng)址到頁面打開詳解
當(dāng)前位置：點(diǎn)晴教程→知識管理交流
→『 技術(shù)文檔交流 』
作為一個軟件開發(fā)者，你一定會對網(wǎng)絡(luò)應(yīng)用如何工作有一個完整的層次化的認(rèn)知，同樣這里也包括這些應(yīng)用所用到的技術(shù)：像瀏覽器，HTTP，HTML，網(wǎng)絡(luò)服務(wù)器，需求處理等等。 本文將更深入的研究當(dāng)你輸入一個網(wǎng)址的時(shí)候，后臺到底發(fā)生了一件件什么樣的事～ facebook.com 2. 瀏覽器查找域名的IP地址
導(dǎo)航的第一步是通過訪問的域名找出其IP地址。DNS查找過程如下： * 瀏覽器緩存 – 瀏覽器會緩存DNS記錄一段時(shí)間。 有趣的是，操作系統(tǒng)沒有告訴瀏覽器儲存DNS記錄的時(shí)間，這樣不同瀏覽器會儲存?zhèn)€自固定的一個時(shí)間（2分鐘到30分鐘不等）。 DNS遞歸查找如下圖所示：
DNS有一點(diǎn)令人擔(dān)憂，這就是像wikipedia.org 或者 facebook.com這樣的整個域名看上去只是對應(yīng)一個單獨(dú)的IP地址。還好，有幾種方法可以消除這個瓶頸： * 循環(huán) DNS 是DNS查找時(shí)返回多個IP時(shí)的解決方案。舉例來說，F(xiàn)acebook.com實(shí)際上就對應(yīng)了四個IP地址。 大多數(shù)DNS服務(wù)器使用Anycast來獲得高效低延遲的DNS查找。 3. 瀏覽器給web服務(wù)器發(fā)送一個HTTP請求
因?yàn)橄馞acebook主頁這樣的動態(tài)頁面，打開后在瀏覽器緩存中很快甚至馬上就會過期，毫無疑問他們不能從中讀取。 所以，瀏覽器將把一下請求發(fā)送到Facebook所在的服務(wù)器： GET http://facebook.com/ HTTP/1.1 GET 這個請求定義了要讀取的URL： “http://facebook.com/”。 瀏覽器自身定義 (User-Agent 頭)，和它希望接受什么類型的相應(yīng) (Accept and Accept-Encoding 頭). Connection頭要求服務(wù)器為了后邊的請求不要關(guān)閉TCP連接。 請求中也包含瀏覽器存儲的該域名的cookies?？赡苣阋呀?jīng)知道，在不同頁面請求當(dāng)中，cookies是與跟蹤一個網(wǎng)站狀態(tài)相匹配的鍵值。這樣 cookies會存儲登錄用戶名，服務(wù)器分配的密碼和一些用戶設(shè)置等。Cookies會以文本文檔形式存儲在客戶機(jī)里，每次請求時(shí)發(fā)送給服務(wù)器。 用來看原始HTTP請求及其相應(yīng)的工具很多。作者比較喜歡使用fiddler，當(dāng)然也有像FireBug這樣其他的工具。這些軟件在網(wǎng)站優(yōu)化時(shí)會幫上很大忙。 像“http://facebook.com/”中的斜杠是至關(guān)重要的。這種情況下，瀏覽器能安全的添加斜杠。而像“http: //example.com/folderOrFile”這樣的地址，因?yàn)闉g覽器不清楚folderOrFile到底是文件夾還是文件，所以不能自動添加斜杠。這時(shí)，瀏覽器就不加斜杠直接訪問地址，服務(wù)器會響應(yīng)一個重定向，結(jié)果造成一次不必要的握手。 4. facebook服務(wù)的永久重定向響應(yīng)
圖中所示為Facebook服務(wù)器發(fā)回給瀏覽器的響應(yīng)： HTTP/1.1 301 Moved Permanently 服務(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)一個頁面有好幾個名字時(shí)，它可能會在緩存里出現(xiàn)好幾次。
現(xiàn)在，瀏覽器知道了 “http://www.facebook.com/”才是要訪問的正確地址，所以它會發(fā)送另一個獲取請求： GET http://www.facebook.com/ HTTP/1.1 頭信息以之前請求中的意義相同。
服務(wù)器接收到獲取請求，然后處理并返回一個響應(yīng)。 這表面上看起來是一個順向的任務(wù)，但其實(shí)這中間發(fā)生了很多有意思的東西- 就像作者博客這樣簡單的網(wǎng)站，何況像facebook那樣訪問量大的網(wǎng)站呢！ * Web 服務(wù)器軟件 舉個最簡單的例子，需求處理可以以映射網(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。 所 有動態(tài)網(wǎng)站都面臨一個有意思的難點(diǎn) -如何存儲數(shù)據(jù)。小網(wǎng)站一半都會有一個SQL數(shù)據(jù)庫來存儲數(shù)據(jù)，存儲大量數(shù)據(jù)和/或訪問量大的網(wǎng)站不得不找一些辦法把數(shù)據(jù)庫分配到多臺機(jī)器上。解決方案有：sharding （基于主鍵值講數(shù)據(jù)表分散到多個數(shù)據(jù)庫中），復(fù)制，利用弱語義一致性的簡化數(shù)據(jù)庫。 委托工作給批處理是一個廉價(jià)保持?jǐn)?shù)據(jù)更新的技術(shù)。舉例來講，F(xiàn)ackbook得及時(shí)更新新聞feed，但數(shù)據(jù)支持下的“你可能認(rèn)識的人”功能只需要每晚更新（作者猜測是這樣的，改功能如何完善不得而知）。批處理作業(yè)更新會導(dǎo)致一些不太重要的數(shù)據(jù)陳舊，但能使數(shù)據(jù)更新耕作更快更簡潔。
圖中為服務(wù)器生成并返回的響應(yīng)： HTTP/1.1 200 OK 2b3Tn@[...] 整個響應(yīng)大小為35kB，其中大部分在整理后以blob類型傳輸。 內(nèi)容編碼頭告訴瀏覽器整個響應(yīng)體用 gzip算法進(jìn)行壓縮。解壓blob塊后，你可以看到如下期望的HTML：
關(guān)于壓縮，頭信息說明了是否緩存這個頁面，如果緩存的話如何去做，有什么cookies要去設(shè)置（前面這個響應(yīng)里沒有這點(diǎn)）和隱私信息等等。 請注意報(bào)頭中把Content-type設(shè)置為“text/html”。報(bào)頭讓瀏覽器將該響應(yīng)內(nèi)容以HTML形式呈現(xiàn)，而不是以文件形式下載它。瀏覽器會根據(jù)報(bào)頭信息決定如何解釋該響應(yīng)，不過同時(shí)也會考慮像URL擴(kuò)展內(nèi)容等其他因素。 在瀏覽器沒有完整接受全部HTML文檔時(shí)，它就已經(jīng)開始顯示這個頁面了：
9. 瀏覽器發(fā)送獲取嵌入在HTML中的對象
在瀏覽器顯示HTML時(shí)，它會注意到需要獲取其他地址內(nèi)容的標(biāo)簽。這時(shí)，瀏覽器會發(fā)送一個獲取請求來重新獲得這些文件。 下面是幾個我們訪問facebook.com時(shí)需要重獲取的幾個URL： * 圖片 這些地址都要經(jīng)歷一個和HTML讀取類似的過程。所以瀏覽器會在DNS中查找這些域名，發(fā)送請求，重定向等等… 但不像動態(tài)頁面那樣，靜態(tài)文件會允許瀏覽器對其進(jìn)行緩存。有的文件可能會不需要與服務(wù)器通訊，而從緩存中直接讀取。服務(wù)器的響應(yīng)中包含了靜態(tài)文件保存的期限信息，所以瀏覽器知道要把它們緩存多長時(shí)間。還有，每個響應(yīng)都可能包含像版本號一樣工作的ETag頭（被請求變量的實(shí)體值），如果瀏覽器觀察到文件的版本 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)容往往代表站點(diǎn)的帶寬大小，也能通過CDN輕松的復(fù)制。通常網(wǎng)站會使用第三方的CDN。例如，F(xiàn)acebook的靜態(tài)文件由最大的CDN提供商Akamai來托管。 舉例來講，當(dāng)你試著ping static.ak.fbcdn.net的時(shí)候，可能會從某個akamai.net服務(wù)器上獲得響應(yīng)。有意思的是，當(dāng)你同樣再ping一次的時(shí)候，響應(yīng)的服務(wù)器可能就不一樣，這說明幕后的負(fù)載平衡開始起作用了。
在Web 2.0偉大精神的指引下，頁面顯示完成后客戶端仍與服務(wù)器端保持著聯(lián)系。 以 Facebook聊天功能為例，它會持續(xù)與服務(wù)器保持聯(lián)系來及時(shí)更新你那些亮亮灰灰的好友狀態(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ā)送的異步請求。事實(shí)上，你不僅可以被動的做為這些請求的看客，還能主動出擊修改和重新發(fā)送它們。AJAX請求這么容易被蒙，可著實(shí)讓那些計(jì)分的在線游戲開發(fā)者們郁悶的了。（當(dāng)然，可別那樣騙人家~） Facebook聊天功能提供了關(guān)于AJAX一個有意思的問題案例：把數(shù)據(jù)從服務(wù)器端推送到客戶端。因?yàn)镠TTP是一個請求-響應(yīng)協(xié)議，所以聊天服務(wù)器不能把新消息發(fā)給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下服務(wù)器端看自己有沒有新消息。 這些情況發(fā)生時(shí)長輪詢是個減輕服務(wù)器負(fù)載挺有趣的技術(shù)。如果當(dāng)被輪詢時(shí)服務(wù)器沒有新消息，它就不理這個客戶端。而當(dāng)尚未超時(shí)的情況下收到了該客戶的新消息，服務(wù)器就會找到未完成的請求，把新消息做為響應(yīng)返回給客戶端。 希望看了本文，你能明白不同的網(wǎng)絡(luò)模塊是如何協(xié)同工作的。 該文章在 2010/8/13 17:48:20 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... 
|
400 186 1886
image13.png)
500pxAn_example_of_theoretical_DNS_recursion_svg.png)
image22.png)
image8.png)
image23.png)
image9.png)
image10.png)
image6.png)
image11.png)
image12.png)