2. 瀏覽器查找域名的IP地址

DNS有一點(diǎn)令人擔(dān)憂，這就是像 或者 這樣的整個(gè)域名看上去只是對(duì)應(yīng)一個(gè)單獨(dú)的IP地址。還好，有幾種方法可以消除這個(gè)瓶頸：
* 循環(huán) DNS 是DNS查找時(shí)返回多個(gè)IP時(shí)的解決方案。舉例來(lái)說(shuō)，F(xiàn)acebook.com實(shí)際上就對(duì)應(yīng)了四個(gè)IP地址。
* 負(fù)載平衡器 是以一個(gè)特定IP地址進(jìn)行偵聽(tīng)并將網(wǎng)絡(luò)請(qǐng)求轉(zhuǎn)發(fā)到集群服務(wù)器上的硬件設(shè)備。 一些大型的站點(diǎn)一般都會(huì)使用這種昂貴的高性能負(fù)載平衡器。
* 地理 DNS 根據(jù)用戶所處的地理位置，通過(guò)把域名映射到多個(gè)不同的IP地址提高可擴(kuò)展性。這樣不同的服務(wù)器不能夠更新同步狀態(tài)，但映射靜態(tài)內(nèi)容的話非常好。
* Anycast 是一個(gè)IP地址映射多個(gè)物理主機(jī)的路由技術(shù)。 美中不足，Anycast與TCP協(xié)議適應(yīng)的不是很好，所以很少應(yīng)用在那些方案中。
大多數(shù)DNS服務(wù)器使用Anycast來(lái)獲得高效低延遲的DNS查找。
3. 瀏覽器給web服務(wù)器發(fā)送一個(gè)HTTP請(qǐng)求

因?yàn)橄馞acebook主頁(yè)這樣的動(dòng)態(tài)頁(yè)面，打開(kāi)后在瀏覽器緩存中很快甚至馬上就會(huì)過(guò)期，毫無(wú)疑問(wèn)他們不能從中讀取。
所以，瀏覽器將把一下請(qǐng)求發(fā)送到Facebook所在的服務(wù)器：
GET HTTP:/// 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:
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]
GET 這個(gè)請(qǐng)求定義了要讀取的URL： “HTTP:///”。 瀏覽器自身定義 (User-Agent 頭)， 和它希望接受什么類型的相應(yīng) (Accept and Accept-Encoding 頭). Connection頭要求服務(wù)器為了后邊的請(qǐng)求不要關(guān)閉TCP連接。
請(qǐng)求中也包含瀏覽器存儲(chǔ)的該域名的cookies?？赡苣阋呀?jīng)知道，在不同頁(yè)面請(qǐng)求當(dāng)中，cookies是與跟蹤一個(gè)網(wǎng)站狀態(tài)相匹配的鍵值。這樣cookies會(huì)存儲(chǔ)登錄用戶名，服務(wù)器分配的密碼和一些用戶設(shè)置等。Cookies會(huì)以文本文檔形式存儲(chǔ)在客戶機(jī)里，每次請(qǐng)求時(shí)發(fā)送給服務(wù)器。
用來(lái)看原始HTTP請(qǐng)求及其相應(yīng)的工具很多。作者比較喜歡使用fiddler，當(dāng)然也有像FireBug這樣其他的工具。這些軟件在網(wǎng)站優(yōu) 化時(shí)會(huì)幫上很大忙。
除了獲取請(qǐng)求，還有一種是發(fā)送請(qǐng)求，它常在提交表單用到。發(fā)送請(qǐng)求通過(guò)URL傳遞其參數(shù)(e.g.: HTTP:///puzzle.aspx?id=85)。發(fā)送請(qǐng)求在請(qǐng)求正文頭之后發(fā)送其參數(shù)。
像“HTTP:///”中的斜杠是至關(guān)重要的。這種情況下，瀏覽器能安全的添加斜杠。而像“HTTP: ///folderOrFile”這樣的地址，因?yàn)闉g覽器不清楚folderOrFile到底是文件夾還是文件，所以不能自動(dòng)添加 斜杠。這時(shí)，瀏覽器就不加斜杠直接訪問(wèn)地址，服務(wù)器會(huì)響應(yīng)一個(gè)重定向，結(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./
P3P: CP=”DSP LAW”
Pragma: no-cache
Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
path=/; domain=.; 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)一個(gè)301永久重定向響應(yīng)，這樣瀏覽器就會(huì)訪問(wèn)“HTTP://www./” 而非“HTTP:///”。
為什么服務(wù)器一定要重定向而不是直接發(fā)會(huì)用戶想看的網(wǎng)頁(yè)內(nèi)容呢？這個(gè)問(wèn)題有好多有意思的答案。
其中一個(gè)原因跟搜索引擎排名有 關(guān)。你看，如果一個(gè)頁(yè)面有兩個(gè)地址，就像HTTP://www./ 和HTTP:///，搜索引擎會(huì)認(rèn)為它們是兩個(gè)網(wǎng)站，結(jié)果造成每一個(gè)的搜索鏈接都減少?gòu)亩档团琶?。而搜索引擎知?01永久重定向是 什么意思，這樣就會(huì)把訪問(wèn)帶www的和不帶www的地址歸到同一個(gè)網(wǎng)站排名下。
還有一個(gè)是用不同的地址會(huì)造成緩存友好性變差。當(dāng)一個(gè)頁(yè)面有好幾個(gè)名字時(shí)，它可能會(huì)在緩存里出現(xiàn)好幾次。
5. 瀏覽器跟蹤重定向地址

現(xiàn)在，瀏覽器知道了 “HTTP://www./”才是要訪問(wèn)的正確地址，所以它會(huì)發(fā)送另一個(gè)獲取請(qǐng)求：
GET HTTP://www./ 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.
頭信息以之前請(qǐng)求中的意義相同。
6. 服務(wù)器“處理”請(qǐng)求


服務(wù)器接收到獲取請(qǐng)求，然后處理并返回一個(gè)響應(yīng)。
這表面上看起來(lái)是一個(gè)順向的任務(wù)，但其實(shí)這中間發(fā)生了很多有意思的東西- 就像作者博客這樣簡(jiǎn)單的網(wǎng)站，何況像facebook那樣訪問(wèn)量大的網(wǎng)站呢！
* Web 服務(wù)器軟件web服務(wù)器軟件（像IIS和阿帕奇）接收到HTTP請(qǐng)求，然后確定執(zhí)行什么請(qǐng)求處理來(lái)處理它。請(qǐng)求處理就 是一個(gè)能夠讀懂請(qǐng)求并且能生成HTML來(lái)進(jìn)行響應(yīng)的程序（像ASP.NET,PHP,RUBY…）。
舉 個(gè)最簡(jiǎn)單的例子，需求處理可以以映射網(wǎng)站地址結(jié)構(gòu)的文件層次存儲(chǔ)。像HTTP:///folder1/page1.aspx這個(gè)地 址會(huì)映射/httpdocs/folder1/page1.aspx這個(gè)文件。web服務(wù)器軟件可以設(shè)置成為地址人工的對(duì)應(yīng)請(qǐng)求處理，這樣 page1.aspx的發(fā)布地址就可以是HTTP:///folder1/page1。* 請(qǐng)求處理請(qǐng)求處理閱讀 請(qǐng)求及它的參數(shù)和cookies。它會(huì)讀取也可能更新一些數(shù)據(jù)，并講數(shù)據(jù)存儲(chǔ)在服務(wù)器上。然后，需求處理會(huì)生成一個(gè)HTML響應(yīng)。
所 有動(dòng)態(tài)網(wǎng)站都面臨一個(gè)有意思的難點(diǎn) -如何存儲(chǔ)數(shù)據(jù)。小網(wǎng)站一半都會(huì)有一個(gè)SQL數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)數(shù)據(jù)，存儲(chǔ)大量數(shù)據(jù)和/或訪問(wèn)量大的網(wǎng)站不得不找一些辦法把數(shù)據(jù)庫(kù)分配到多臺(tái)機(jī)器上。解決方案有：sharding （基于主鍵值講數(shù)據(jù)表分散到多個(gè)數(shù)據(jù)庫(kù)中），復(fù)制，利用弱語(yǔ)義一致性的簡(jiǎn)化數(shù)據(jù)庫(kù)。
委托工作給批處理是一個(gè)廉價(jià)保持?jǐn)?shù)據(jù)更新的技術(shù)。舉例來(lái)講，F(xiàn)ackbook得及時(shí)更新新聞feed，但數(shù)據(jù)支持下的“你可能認(rèn)識(shí)的人”功能只需要每晚更新（作者猜測(cè)是這樣的，改功能如何完善不得而知）。批處理作業(yè)更新會(huì)導(dǎo)致一些不太重要的數(shù)據(jù)陳舊，但能使數(shù)據(jù)更新耕作更快更簡(jiǎn)潔。7. 服務(wù)器發(fā)回一個(gè)HTML響應(yīng)


圖中為服務(wù)器生成并返回的響應(yīng)：
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 GMT
2b3Tn@[...]
整個(gè)響應(yīng)大小為35kB，其中大部分在整理后以blob類型傳輸。
內(nèi)容編碼頭告訴瀏覽器整個(gè)響應(yīng)體用 gzip算法進(jìn)行壓縮。解壓blob塊后，你可以看到如下期望的HTML：
“HTTP://www./TR/xhtml1/DTD/xhtml1-strict.dtd”>lang=”en” id=”facebook”>
…
關(guān)于壓縮，頭信息說(shuō)明了是否緩存這個(gè)頁(yè)面，如果緩存的話如何去做，有什么cookies要去設(shè)置（前面這個(gè)響應(yīng)里沒(méi)有這點(diǎn)）和隱私信息等 等。
請(qǐng)注意報(bào)頭中把Content-type設(shè)置為“text/html”。報(bào)頭讓瀏覽器將該響應(yīng)內(nèi)容以HTML形式呈現(xiàn)，而不是以文件形式下 載它。瀏覽器會(huì)根據(jù)報(bào)頭信息決定如何解釋該響應(yīng)，不過(guò)同時(shí)也會(huì)考慮像URL擴(kuò)展內(nèi)容等其他因素。8. 瀏覽器開(kāi)始顯示HTML
在瀏覽器沒(méi)有完整接受全部HTML文檔時(shí)，它就已經(jīng)開(kāi)始顯示這個(gè)頁(yè)面了：


9. 瀏覽器發(fā)送獲取嵌入在HTML中的對(duì)象


在瀏覽器顯示HTML時(shí)，它會(huì)注意到需要獲取其他地址內(nèi)容的標(biāo)簽。這時(shí)，瀏覽器會(huì)發(fā)送一個(gè)獲取請(qǐng)求來(lái)重新獲得這些文件。
下面是幾個(gè)我們?cè)L問(wèn)時(shí)需要重獲取的幾個(gè)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)歷一個(gè)和HTML讀取類似的過(guò)程。所以瀏覽器會(huì)在DNS中查找這些域名，發(fā)送請(qǐng)求，重定向等等…
但不像動(dòng)態(tài)頁(yè)面那樣，靜態(tài)文件會(huì)允許瀏覽器對(duì)其進(jìn)行緩存。有的文件可能會(huì)不需要與服務(wù)器通訊，而從緩存中直接讀取。服務(wù)器的響應(yīng)中包含了靜態(tài)文件保存的期限信息，所以瀏覽器知道要把它們緩存多長(zhǎng)時(shí)間。還有，每個(gè)響應(yīng)都可能包含像版本號(hào)一樣工作的ETag頭（被請(qǐng)求變量的實(shí)體值），如果瀏覽器觀察到文件的版本 ETag信息已經(jīng)存在，就馬上停止這個(gè)文件的傳輸。
試著猜猜看“fbcdn.net”在地址中代表什么？聰明的答案是”Facebook內(nèi)容分發(fā)網(wǎng)絡(luò)”。Facebook利用內(nèi)容分發(fā)網(wǎng)絡(luò) （CDN）分發(fā)像圖片，CSS表和 JavaScript文件這些靜態(tài)文件。所以，這些文件會(huì)在全球很多CDN的數(shù)據(jù)中心中留下備份。
靜態(tài)內(nèi)容往往代表站點(diǎn)的帶寬大小，也能通過(guò)CDN輕松的復(fù)制。通常網(wǎng)站會(huì)使用第三方的CDN。例如，F(xiàn)acebook的靜態(tài)文件由最大的 CDN提供商Akamai來(lái)托管。
舉例來(lái)講，當(dāng)你試著ping static.ak.fbcdn.net的時(shí)候，可能會(huì)從某個(gè)akamai.net服務(wù)器上獲得響應(yīng)。有意思的是，當(dāng)你同樣再ping一次的時(shí)候，響應(yīng)的 服務(wù)器可能就不一樣，這說(shuō)明幕后的負(fù)載平衡開(kāi)始起作用了。10. 瀏覽器發(fā)送異步（AJAX）請(qǐng)求


在Web 2.0偉大精神的指引下，頁(yè)面顯示完成后客戶端仍與服務(wù)器端保持著聯(lián)系。
以 Facebook聊天功能為例，它會(huì)持續(xù)與服務(wù)器保持聯(lián)系來(lái)及時(shí)更新你那些亮亮灰灰的好友狀態(tài)。為了更新這些頭像亮著的好友狀態(tài)，在瀏覽器中執(zhí)行的 JavaScript代碼會(huì)給服務(wù)器發(fā)送異步請(qǐng)求。這個(gè)異步請(qǐng)求發(fā)送給特定的地址，它是一個(gè)按照程式構(gòu)造的獲取或發(fā)送請(qǐng)求。還是在Facebook這個(gè)例子中，客戶端發(fā)送給HTTP://www./ajax/chat/buddy_list.php一個(gè)發(fā)布請(qǐng)求來(lái)獲取你好友里哪個(gè) 在線的狀態(tài)信息。
提起這個(gè)模式，就必須要講講”AJAX”– “異步JavaScript 和 XML”，雖然服務(wù)器為什么用XML格式來(lái)進(jìn)行響應(yīng)也沒(méi)有個(gè)一清二白的原因。再舉個(gè)例子吧，對(duì)于異步請(qǐng)求，F(xiàn)acebook會(huì)返回一些 JavaScript的代碼片段。
除了其他，fiddler這個(gè)工具能夠讓你看到瀏覽器發(fā)送的異步請(qǐng)求。事實(shí)上，你不僅可以被動(dòng)的做為這些請(qǐng)求的看客，還能主動(dòng)出擊修改和重 新發(fā)送它們。AJAX請(qǐng)求這么容易被蒙，可著實(shí)讓那些計(jì)分的在線游戲開(kāi)發(fā)者們郁悶的了。（當(dāng)然，可別那樣騙人家~）
Facebook聊天功能提供了關(guān)于AJAX一個(gè)有意思的問(wèn)題案例：把數(shù)據(jù)從服務(wù)器端推送到客戶端。因?yàn)镠TTP是一個(gè)請(qǐng)求-響應(yīng)協(xié)議，所 以聊天服務(wù)器不能把新消息發(fā)給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下服務(wù)器端看自己有沒(méi)有新消息。
這些情況發(fā)生時(shí)長(zhǎng)輪詢是個(gè)減輕服務(wù)器負(fù)載挺有趣的技術(shù)。如果當(dāng)被輪詢時(shí)服務(wù)器沒(méi)有新消息，它就不理這個(gè)客戶端。而當(dāng)尚未超時(shí)的情況下收到了 該客戶的新消息，服務(wù)器就會(huì)找到未完成的請(qǐng)求，把新消息做為響應(yīng)返回給客戶端。總結(jié)一下
希望看了本文，你能明白不同的網(wǎng)絡(luò)模塊是如何協(xié)同工作的
本篇文章來(lái)源于 站長(zhǎng)資訊網(wǎng) 原文鏈接：http://www./1007/127890385919293_2.html

我們似乎每天都要做這樣一件事情，打開(kāi)一個(gè)瀏覽器，輸入網(wǎng)址，回車，一個(gè)空白的頁(yè)面頓時(shí)有了東西，它可能是百度之類的搜索頁(yè)面，或是一個(gè)擠滿了文字和圖片的門戶網(wǎng)站。從我們打開(kāi)瀏覽器，到我們看到我們想看的內(nèi)容，這過(guò)程究竟發(fā)生了什么？
下面我們就從三個(gè)方面理解這個(gè)過(guò)程，一個(gè)是瀏覽器，二個(gè)是服務(wù)器，第三個(gè)是瀏覽器和服務(wù)器之間通信的協(xié)議。在理解這三方面之前我們必須先搞明白將這三方面聯(lián)系起來(lái)的一個(gè)詞：web。
1，world wide web
我們通常所說(shuō)的web就是指world wide web。一般來(lái)講，這一種通過(guò)瀏覽器來(lái)訪問(wèn)資源的技術(shù)。我們經(jīng)常說(shuō)的上網(wǎng)，應(yīng)該大部都是指的是上萬(wàn)維網(wǎng)(web)，但是我們經(jīng)常將萬(wàn)維網(wǎng)和因特網(wǎng)(Internet)搞混。因特網(wǎng)是一種網(wǎng)絡(luò)互連的技術(shù)，它更指的是物理層面上的互連，而萬(wàn)維網(wǎng)應(yīng)該算是跑在因特網(wǎng)上的一種服務(wù)。
我們通常通過(guò)瀏覽器還訪問(wèn)web，我們常見(jiàn)到的網(wǎng)頁(yè)中包含超文本，圖片，視頻音頻等各項(xiàng)內(nèi)容。向我們提供這些資源的是一個(gè)一個(gè)的站點(diǎn)，通過(guò)互聯(lián)網(wǎng)，這些站點(diǎn)相互連接起來(lái)。我們通過(guò)超鏈接從一個(gè)網(wǎng)頁(yè)訪問(wèn)到另外一個(gè)網(wǎng)頁(yè)，從一個(gè)站點(diǎn)到另外一個(gè)站點(diǎn)，所有的這一切組成一個(gè)龐大的網(wǎng)，這就是web。
支持web的技術(shù)，首先是底層的網(wǎng)絡(luò)，因?yàn)閣eb就是建立在Internet之上，web的基本協(xié)議是HTTP協(xié)議，它跑在TCP上的協(xié)議之上，而TCP協(xié)議又需要IP協(xié)議的支持，IP協(xié)議又要由底層鏈路來(lái)支撐，所以我們可以從高到第看到這樣一個(gè)協(xié)議棧 http->tcp->ip->連路層協(xié)議。要理解web到ip就已經(jīng)足夠了。
我們可以想一想web上的資源有哪些？ 首先是文本，后來(lái)添加了圖片，到現(xiàn)在的各種音頻視頻資源，所有互聯(lián)網(wǎng)上的資源都要通過(guò)一個(gè)叫做URI的東西還標(biāo)記，當(dāng)然了我們更常見(jiàn)是URL?，F(xiàn)在也不必糾結(jié)于兩者有何不同，URL就是URI的一個(gè)子集，URL給了我們資源的地址，所以我們能夠找到它。
現(xiàn)在看一個(gè)URL： 這是一個(gè)圖片的url。它是按照這樣的語(yǔ)法來(lái)定義：scheme://domain:port/path?query_string#fragment_id.scheme就是協(xié)議，在瀏覽器里通常是http，例子中的是https是一種由HTTP和SSL/TLS組合起來(lái)的應(yīng)用，用以提供加密通信和對(duì)網(wǎng)絡(luò)服務(wù)器的身份驗(yàn)證（http://zh./zh/HTTPS ）。然后就是域名，每個(gè)站點(diǎn)都至少有一個(gè)域名，上面例子上的域名部分是www.,這個(gè)域名也是分為三部分的，www是主機(jī)名，com.hk算是頂級(jí)域名，除了com還有cn,net等。域名后面是端口號(hào)默認(rèn)為80，通常被省略，這是服務(wù)器端服務(wù)器軟件偵聽(tīng)的端口，也是TCP里面一個(gè)端口號(hào)的值。然后就是path，資源在服務(wù)器上的路徑。最后問(wèn)號(hào)部分的客戶端利用url傳給服務(wù)器的一些參數(shù)值，通常值比較少，不太重要時(shí)這么做。
2，協(xié)議
（1）HTTP協(xié)議
web里最重要的協(xié)議就是HTTP協(xié)議，對(duì)于經(jīng)典的ISO七層網(wǎng)絡(luò)模型來(lái)說(shuō)， HTTP處于最高層--應(yīng)用層。HTTP應(yīng)用的模型是client/server模型。因此對(duì)應(yīng)著兩種HTTP消息類型，request和response。客戶端向服務(wù)器發(fā)出請(qǐng)求，服務(wù)器向客戶端發(fā)回請(qǐng)求。下面看一下兩種類型消息的格式：




下面分別進(jìn)行解釋。
首先是HTTP Request Message
請(qǐng)求行：請(qǐng)求行以一個(gè)方法符號(hào)開(kāi)頭，以空格分開(kāi)，后面跟著請(qǐng)求的URI和協(xié)議的版本。請(qǐng)求方法常見(jiàn)的有:GET POST HEAD PUT等。
消息報(bào)頭：在普通報(bào)頭中，有少數(shù)報(bào)頭域用于所有的請(qǐng)求和響應(yīng)消息，但并不用于被傳輸?shù)膶?shí)體，只用于傳輸?shù)南ⅰ?請(qǐng)求報(bào)頭允許客戶端向服務(wù)器端傳遞請(qǐng)求的附加信息以及客戶端自身的信息。 請(qǐng)求和響應(yīng)消息都可以傳送一個(gè)實(shí)體。一個(gè)實(shí)體由實(shí)體報(bào)頭域和實(shí)體正文組成，但并不是說(shuō)實(shí)體報(bào)頭域和實(shí)體正文要在一起發(fā)送，可以只發(fā)送實(shí)體報(bào)頭域。實(shí)體報(bào)頭定義了關(guān)于實(shí)體正文（eg：有無(wú)實(shí)體正文）和請(qǐng)求所標(biāo)識(shí)的資源的元信息。 POST請(qǐng)求的內(nèi)容放在實(shí)體正文中。
HTTP Response Message
狀態(tài)行：最主要的一個(gè)字段是服務(wù)器響應(yīng)代碼。比如，200 OK ，400 Bad Request ，401 Unauthorized ，403 Forbidden ，404 Not Found ，500 Internal Server Error ，503 Server Unavailable
消息報(bào)頭：普通報(bào)頭和實(shí)體報(bào)頭與 請(qǐng)求報(bào)頭的類似。有區(qū)別的在于響應(yīng)包頭，響應(yīng)報(bào)頭允許服務(wù)器傳遞不能放在狀態(tài)行中的附加響應(yīng)信息，以及關(guān)于服務(wù)器的信息和對(duì)Request-URI所標(biāo)識(shí)的資源進(jìn)行下一步訪問(wèn)的信息。
（這部分說(shuō)的比較粗略，網(wǎng)上的資源比較多，可以參考這一篇：http://blog.csdn.net/gueter/article/details/1524447 和http://book.51cto.com/art/200902/109036.htm ）
下面是ethereal抓到的一個(gè)get報(bào)文，post報(bào)文和響應(yīng)報(bào)文，可以大概看一下。



(2)TCP協(xié)議
HTTP協(xié)議基于TCP協(xié)議，也就是HTTP的所有內(nèi)容將作為TCP的實(shí)體被封裝到TCP報(bào)文里面。TCP協(xié)議是面向連接，可靠的傳輸機(jī)制。也就是說(shuō)客戶端在與服務(wù)器交互數(shù)據(jù)的過(guò)程中會(huì)有一個(gè)連接建立和釋放的過(guò)程，看上面的Http頭部字段可以看到相關(guān)的字段。TCP有強(qiáng)大的窗口機(jī)制能夠適應(yīng)發(fā)送方和接收方的發(fā)送接收能力，也能根據(jù)整個(gè)網(wǎng)絡(luò)狀況進(jìn)行調(diào)整。
（3）IP協(xié)議
IP協(xié)議處于整個(gè)TCP/IP協(xié)議族的承上啟下地位。我們知道因特網(wǎng)上主機(jī)是靠一個(gè)32位的ip地址來(lái)定位的，HTTP用的URL也算是地址，但是比較高級(jí)，IP協(xié)議是理解不了的，所以需要一個(gè)從URL到IP的轉(zhuǎn)換，這個(gè)過(guò)程通過(guò)DNS(域名查詢系統(tǒng))協(xié)議完成。我們用的每一臺(tái)電腦上都配置了DNS服務(wù)器的地址，如果沒(méi)有配置那么你的網(wǎng)關(guān)默認(rèn)充當(dāng)了，當(dāng)我們有一個(gè)URL想知道對(duì)應(yīng)的IP時(shí)就需要向DNS服務(wù)器發(fā)送查詢請(qǐng)求了，它會(huì)把查詢的結(jié)果發(fā)回。
2，瀏覽器
在web的世界里最不能少的角色就是瀏覽器。前面我們說(shuō)到HTTP協(xié)議，HTTP消息有兩種，request和response。瀏覽器的主要工作就是發(fā)送http request報(bào)文和接收處理http response報(bào)文。沒(méi)有看過(guò)瀏覽器的開(kāi)源文檔，但是我覺(jué)得一個(gè)軟件只要完成下面幾件事，基本上就可以稱的上一個(gè)瀏覽器了。
(1)能夠根據(jù)用戶的請(qǐng)求生成合適的HTTP REQUEST報(bào)文。比如用戶在瀏覽器地址欄上輸入地址進(jìn)行訪問(wèn)，瀏覽器要能夠生成HTTP GET報(bào)文，表單的發(fā)送生成POST報(bào)文等等。
(2) 能夠?qū)Ω鞣N的RESPONSE進(jìn)行處理。
(3)渲染Html文檔，生成文檔樹(shù)，能夠解釋css，還要有個(gè)javascript引擎。
(4)能夠發(fā)起dns查詢得到ip地址。
瀏覽器是個(gè)非常復(fù)雜的軟件，當(dāng)然現(xiàn)在的瀏覽器對(duì)http協(xié)議的支持應(yīng)該不是問(wèn)題，它們主要糾結(jié)于html文檔渲染部分，對(duì)于用戶層出不窮的新需求，w3c層出不窮的新標(biāo)準(zhǔn)，瀏覽器的路應(yīng)該才剛剛開(kāi)始。
3， 服務(wù)器
服務(wù)器有兩個(gè)層級(jí)的概念，它可以是機(jī)器，它上面存著一個(gè)站點(diǎn)的所有東西，也可以是軟件，安裝在一個(gè)也叫做服務(wù)器的機(jī)器上，幫助這個(gè)機(jī)器分發(fā)用戶想要的東西。 我對(duì)服務(wù)器研究不多,只是用過(guò)幾次apache。所以只是簡(jiǎn)單的談?wù)勎业恼J(rèn)識(shí)。
服務(wù)器最基本的功能就是響應(yīng)客戶端的資源請(qǐng)求。服務(wù)器首先會(huì)偵聽(tīng)80端口，來(lái)了http請(qǐng)求，就根據(jù)請(qǐng)求進(jìn)行處理，請(qǐng)求一個(gè)圖片那就根據(jù)路徑找到資源發(fā)回，請(qǐng)求靜態(tài)html頁(yè)面也是如此，如果請(qǐng)求的是像php這樣的動(dòng)態(tài)頁(yè)面應(yīng)該先調(diào)用php編譯器(或是解釋器吧)生成html代碼，然后返回給客戶端。當(dāng)然還要解決的一個(gè)問(wèn)題就是并行問(wèn)題以應(yīng)對(duì)大訪問(wèn)量。
因?yàn)閷?duì)這方面不太了解，只想到了這么多。

先說(shuō)到這里， 有了新的認(rèn)識(shí)再寫。


來(lái)源：http://www.cnblogs.com/orchid/archive/2012/04/21/2461442.html

來(lái)源：從輸入網(wǎng)址到顯示網(wǎng)頁(yè)的全過(guò)程分析
http://www./forum.php?mod=viewthread&tid=1655&fromuid=1931