一次完整的網絡通信

一、在瀏覽器中輸入www.baidu.com

這意味着瀏覽器要向百度發送一個網頁數據包，要發送數據包，須要知道對方的IP地址，這裏咱們只知道網址爲www.baidu.com,殊不知道IP地址，此時應用層協議DNS協議會幫咱們把網址解析爲IP地址，此時會發送一個DNS數據包給DNS服務器，DNS服務器再作出響應來告訴咱們百度的IP地址爲220.181.111.147，這樣咱們就知道百度（咱們須要通訊的主機）的IP地址。

DNS查找過程以下：（參考來源：DNS域名解析過程）

第1步，瀏覽器會檢查緩存中有沒有這個域名對應的解析過的IP地址，若是緩存中有，這個解析過程就將結束。瀏覽器緩存域名也是有限制的，不只瀏覽器緩存大小有限制，並且緩存的時間也有限制，一般狀況下爲幾分鐘到幾小時不等，域名被緩存的時間限制能夠經過TTL屬性來設置。這個緩存時間太長和過短都很差，若是緩存時間太長，一旦域名被解析到的IP有變化，會致使被客戶端緩存的域名沒法解析到變化後的IP地址，以至該域名不能正常解析，這段時間內有可能會有一部分用戶沒法訪問網站。若是時間設置過短，會致使用戶每次訪問網站都要從新解析一次域名。

第2步，若是用戶的瀏覽器緩存中沒有，瀏覽器會查找操做系統緩存中是否有這個域名對應的DNS解析結果。其實操做系統也會有一個域名解析的過程，在Windows中能夠經過C:WindowsSystem32driversetchosts文件來設置，你能夠將任何域名解析到任何可以訪問的IP地址。若是你在這裏指定了一個域名對應的IP地址，那麼瀏覽器會首先使用這個IP地址。例如，咱們在測試時能夠將一個域名解析到一臺測試服務器上，這樣不用修改任何代碼就能測試到單獨服務器上的代碼的業務邏輯是否正確。正是由於有這種本地DNS解析的規程，因此黑客就有可能經過修改你的域名解析來把特定的域名解析到它指定的IP地址上，致使這些域名被劫持。Windows 7中將hosts文件設置成了只讀的，防止這個文件被輕易修改。

前面這兩個步驟都是在本機完成的。到這裏尚未涉及真正的域名解析服務器，若是在本機中仍然沒法完成域名的解析，就會真正請求域名服務器來解析這個域名了。

第3步，如何、怎麼知道域名服務器呢？在咱們的網絡配置中都會有"DNS服務器地址"這一項，這個地址就用於解決前面所說的若是兩個過程沒法解析時要怎麼辦，操做系統會把這個域名發送給這裏設置的LDNS，也就是本地區的域名服務器。這個DNS一般都提供給你本地互聯網接入的一個DNS解析服務，例如你是在學校接入互聯網，那麼你的DNS服務器確定在你的學校，若是你是在一個小區接入互聯網的，那這個DNS就是提供給你接入互聯網的應用提供商，即電信或者聯通，也就是一般所說的SPA，那麼這個DNS一般也會在你所在城市的某個角落，一般不會很遠。這個專門的域名解析服務器性能都會很好，它們通常都會緩存域名解析結果，固然緩存時間是受域名的失效時間控制的，通常緩存空間不是影響域名失效的主要因素。大約80%的域名解析都到這裏就已經完成了，因此LDNS主要承擔了域名的解析工做。

第4步，若是LDNS仍然沒有命中，就直接到Root Server域名服務器請求解析。

第5步，根域名服務器返回給本地域名服務器一個所查詢域的主域名服務器（gTLD Server）地址。gTLD是國際頂級域名服務器，如.com、.cn、.org等，全球只有13臺左右。

第6步，本地域名服務器（Local DNS Server）再向上一步返回的gTLD服務器發送請求。

第7步，接受請求的gTLD服務器查找並返回此域名對應的Name Server域名服務器的地址，這個Name Server一般就是你註冊的域名服務器，例如你在某個域名服務提供商申請的域名，那麼這個域名解析任務就由這個域名提供商的服務器來完成。

第8步，Name Server域名服務器會查詢存儲的域名和IP的映射關係表，正常狀況下都根據域名獲得目標IP記錄，連同一個TTL值返回給DNS Server域名服務器。

第9步，返回該域名對應的IP和TTL值，Local DNS Server會緩存這個域名和IP的對應關係，緩存的時間由TTL值控制。

第10步，把解析的結果返回給用戶，用戶根據TTL值緩存在本地系統緩存中，域名解析過程結束。

在實際的DNS解析過程當中，可能還不止這10個步驟，如Name Server也可能有多級，或者有一個GTM來負載均衡控制，這都有可能會影響域名解析的過程。

二、應用層：
瀏覽網頁採用的是HTTP 協議，HTTP數據包會嵌入在TCP數據包中，此時咱們發送的HTTP數據包內容爲：

[plain] view plain copy
GET http://www.baidu.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, /
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; Zune 4.7; InfoPath.3; MS-RTC LM 8)
Accept-Encoding: gzip, deflate, peerdist
Proxy-Connection: Keep-Alive
Host: www.baidu.com
Cookie: BDSFRCVID=H1K_JgC2l434o0a3SlYrhIyDwFLxPM7C3J; H_BDCLCKID_SF=tJAt_C8htDv5HTuRj63D5JcH-UnLqMkDWaOZ0h8-aI-5MbAx-jb6hhFXM-r80nblBTbT2C3nthF0HPonHj8Bej5L3J; BAIDUID=C0E879D1A40237E70E9FA559D40EE0AC:FG=1; BDUT=w5n3C0E879D1A40237E70E9FA559D40EE0AC13914a661370; BDUSS=FEQVdNdjllMTYyYlRxY3ZZbW1hM2htemdqZFVJcWRLWmFBaEtqd1FoTDNXeE5SQUFBQUFBJCQAAAAAAAAAAAoqyysAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEwLjI2LjE5Ny43NwAAAADAxFInAAAAAPcNJlD3DSZQYV; BDRCVFR[eYjbPwSqvSs]=2g3v5sBI-NCpv4EILPoXi4WUvY; Hm_lvt_9f14aaa038bbba8b12ec2a4a3e51d254=1344671219756; Hm_lpvt_9f14aaa038bbba8b12ec2a4a3e51d254=1344671219756
X-P2P-PeerDist: Version=1.0
用來看原始HTTP請求及其響應的工具不少。比較喜歡使用fiddler，固然也有像FireBug這樣其餘的工具。這些軟件在網站優化時會幫上很大忙。

三、傳輸層：
TCP數據包須要設置端口，接收方（百度）的Http端口默認是80，本機的端口是一個1024-65535之間的隨機整數，這裏假設爲1025，這樣TCP數據包由標頭（標識着發方和接收方的端口信息）+HTTP數據包，這樣TCP數據包再嵌入IP數據包中在網絡上傳送

四、網絡層：
IP數據包須要知道雙方的IP地址，本機IP地址假定爲192.168.1.5，接受方IP地址爲220.181.111.147（百度），這樣IP數據包由頭部（IP地址信息）+TCP數據包，

五、數據鏈路層：
IP數據包嵌入到數據幀（以太網數據包）中，以太網數據包須要知道雙方的MAC（物理地址），發送方爲本機的網卡地址，接受方爲網關192.168.1.1的MAC地址（經過ARP地址解析協議獲得的）。這樣數據幀由頭部（MAC地址）+IP數據包組成。

ARP地址解析協議工做過程：
主機A的IP地址爲192.168.1.1，MAC地址爲0A-11-22-33-44-01；

主機B的IP地址爲192.168.1.2，MAC地址爲0A-11-22-33-44-02；

當主機A要與主機B通訊時，地址解析協議能夠將主機B的IP地址（192.168.1.2）解析成主機B的MAC地址，如下爲工做流程：

第1步：根據主機A上的路由表內容，IP肯定用於訪問主機B的轉發IP地址是192.168.1.2。而後A主機在本身的本地ARP緩存中檢查主機B的匹配MAC地址。
第2步：若是主機A在ARP緩存中沒有找到映射，它將詢問192.168.1.2的硬件地址，從而將ARP請求幀廣播到本地網絡上的全部主機。源主機A的IP地址和MAC地址都包括在ARP請求中。本地網絡上的每臺主機都接收到ARP請求而且檢查是否與本身的IP地址匹配。若是主機發現請求的IP地址與本身的IP地址不匹配，它將丟棄ARP請求。
第3步：主機B肯定ARP請求中的IP地址與本身的IP地址匹配，則將主機A的IP地址和MAC地址映射添加到本地ARP緩存中。
第4步：主機B將包含其MAC地址的ARP回覆消息直接發送回主機A。
第5步：當主機A收到從主機B發來的ARP回覆消息時，會用主機B的IP和MAC地址映射更新ARP緩存。本機緩存是有生存期的，生存期結束後，將再次重複上面的過程。主機B的MAC地址一旦肯定，主機A就能向主機B發送IP通訊了。

六、服務器處理請求

通過多個網關的轉發到百度服務器220.181.111.147，中間經過各級物理層找到終端服務器IP，並請求對應端口服務，服務接收到發送過來的以太網數包據開始解析請求信息，從以太網數據包中提取IP數據包——>TCP數據包——>HTTP數據包，並組裝爲有效數據交與對應線程池中分配的線程進行處理，在這個過程當中，生成相應request、response對象。

處理完畢後，將數據經過response對象內部的out給客戶輸出信息，輸出信息也須要拼接HTTP協議頭部分，標誌out關閉後爲斷開鏈接（注意動態內容已經在服務器端被翻譯爲靜態內容，到客戶端所有是靜態內容，JS動態組裝不算），斷開後，服務器端自動註銷request、response對象，並將釋放對應線程的使用標識（通常一個請求單獨由一個線程處理，部分特殊狀況有一個線程處理多個請求的狀況）

七、服務器發回一個HTML響應

服務器生成並返回的響應：

[plain] view plain copy
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
整個響應大小爲35kB，其中大部分在整理後以blob類型傳輸。
內容編碼頭告訴瀏覽器整個響應體用gzip算法進行壓縮。解壓blob塊後，你能夠看到以下指望的HTML：

[plain] view plain copy
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en" id="facebook" class=" no_js">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />
...
關於壓縮，頭信息說明了是否緩存這個頁面，若是緩存的話如何去作，有什麼cookies要去設置（前面這個響應裏沒有這點）和隱私信息等等。
請注意報頭中把Content-type設置爲「text/html」。報頭讓瀏覽器將該響應內容以HTML形式呈現，而不是以文件形式下載它。瀏覽器會根據報頭信息決定如何解釋該響應，不過同時也會考慮像URL擴展內容等其餘因素。

八、瀏覽器開始顯示HTML

客戶端接收到返回數據，去掉對應頭信息，造成也能夠被瀏覽器認識的頁面HTML字符串信息，交與瀏覽器翻譯爲對應頁面規則信息展現爲界面內容。瀏覽器一樣的過程讀取到HTTP響應的內容（HTTP響應數據包），而後瀏覽器對接受到的HTML頁面進行解析，把網頁顯示出來呈現給用戶。

九、瀏覽器發送獲取嵌入在HTML中的對象

在瀏覽器顯示HTML時，它會注意到須要獲取其餘地址內容的標籤。這時，瀏覽器會發送一個獲取請求來從新得到這些文件。
下面是幾個咱們訪問facebook.com時須要重獲取的幾個URL：

圖片
http://static.ak.fbcdn.net/rs...
http://static.ak.fbcdn.net/rs...
…
CSS 式樣表
http://static.ak.fbcdn.net/rs...
http://static.ak.fbcdn.net/rs...
…
JavaScript 文件
http://static.ak.fbcdn.net/rs...
http://static.ak.fbcdn.net/rs...
…
這些地址都要經歷一個和HTML讀取相似的過程。因此瀏覽器會在DNS中查找這些域名，發送請求，重定向等等...
但不像動態頁面那樣，靜態文件會容許瀏覽器對其進行緩存。有的文件可能會不須要與服務器通信，而從緩存中直接讀取。服務器的響應中包含了靜態文件保存的期限 信息，因此瀏覽器知道要把它們緩存多長時間。還有，每一個響應均可能包含像版本號同樣工做的ETag頭（被請求變量的實體值），若是瀏覽器觀察到文件的版本 ETag信息已經存在，就立刻中止這個文件的傳輸。
試着猜猜看「fbcdn.net」在地址中表明什麼？聰明的答案是"Facebook內容分發網絡"。Facebook利用內容分發網絡（CDN）分發像圖片，CSS表和JavaScript文件這些靜態文件。因此，這些文件會在全球不少CDN的數據中心中留下備份。
靜態內容每每表明站點的帶寬大小，也能經過CDN輕鬆的複製。一般網站會使用第三方的CDN。例如，Facebook的靜態文件由最大的CDN提供商Akamai來託管。
舉例來說，當你試着ping static.ak.fbcdn.net的時候，可能會從某個akamai.net服務器上得到響應。有意思的是，當你一樣再ping一次的時候，響應的服務器可能就不同，這說明幕後的負載平衡開始起做用了。

1. 瀏覽器發送異步（AJAX）請求

在Web 2.0偉大精神的指引下，頁面顯示完成後客戶端仍與服務器端保持着聯繫。
以 Facebook聊天功能爲例，它會持續與服務器保持聯繫來及時更新你那些亮亮灰灰的好友狀態。爲了更新這些頭像亮着的好友狀態，在瀏覽器中執行的 JavaScript代碼會給服務器發送異步請求。這個異步請求發送給特定的地址，它是一個按照程式構造的獲取或發送請求。仍是在Facebook這個例 子中，客戶端發送給http://www.facebook.com/ajax/... 在線的狀態信息。

提起這個模式，就必需要講講"AJAX"-- 「異步JavaScript 和 XML」，雖然服務器爲何用XML格式來進行響應也沒有個一清二白的緣由。再舉個例子吧，對於異步請求，Facebook會返回一些JavaScript的代碼片斷。除了其餘，fiddler這個工具可以讓你看到瀏覽器發送的異步請求。事實上，你不只能夠被動的作爲這些請求的看客，還能主動出擊修改和從新發送它們。AJAX請求這麼容易被蒙，可着實讓那些計分的在線遊戲開發者們鬱悶的了。（固然，可別那樣騙人家~）Facebook聊天功能提供了關於AJAX一個有意思的問題案例：把數據從服務器端推送到客戶端。由於HTTP是一個請求-響應協議，因此聊天服務器不能把新消息發給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下服務器端看本身有沒有新消息。這些狀況發生時長輪詢是個減輕服務器負載挺有趣的技術。若是當被輪詢時服務器沒有新消息，它就不理這個客戶端。而當還沒有超時的狀況下收到了該客戶的新消息，服務器就會找到未完成的請求，把新消息作爲響應返回給客戶端。