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

    這意味著瀏覽器要向百度傳送一個網頁資料包，要傳送資料包，需要知道對方的IP地址，這裡我們只知道網址為www.baidu.com,卻不知道IP地址，此時應用層協議DNS協議會幫我們把網址解析為IP地址，此時會發送一個DNS資料包給DNS伺服器，DNS伺服器再做出響應來告訴我們百度的IP地址為220.181.111.147，這樣我們就知道百度（我們需要通訊的主機）的IP地址。

第1步，瀏覽器會檢查快取中有沒有這個域名對應的解析過的IP地址，如果快取中有，這個解析過程就將結束。瀏覽器快取域名也是有限制的，不僅瀏覽器快取大小有限制，而且快取的時間也有限制，通常情況下為幾分鐘到幾小時不等，域名被快取的時間限制可以通過TTL屬性來設定。這個快取時間太長和太短都不好，如果快取時間太長，一旦域名被解析到的IP有變化，會導致被客戶端快取的域名無法解析到變化後的IP地址，以致該域名不能正常解析，這段時間內有可能會有一部分使用者無法訪問網站。如果時間設定太短，會導致使用者每次訪問網站都要重新解析一次域名。

第2步，如果使用者的瀏覽器快取中沒有，瀏覽器會查詢作業系統快取中是否有這個域名對應的DNS解析結果。其實作業系統也會有一個域名解析的過程，在Windows中可以通過C:\Windows\System32\drivers\etc\hosts檔案來設定，你可以將任何域名解析到任何能夠訪問的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來負載均衡控制，這都有可能會影響域名解析的過程。
 

2、應用層：
瀏覽網頁採用的是HTTP 協議，HTTP資料包會嵌入在TCP資料包中，此時我們傳送HTTP格式資料包

3、傳輸層：
TCP資料包需要設定埠，接收方（百度）的Http埠預設是80，本機的埠是一個1024-65535之間的隨機整數，這裡假設為1025，這樣TCP資料包由標頭（標識著發方和接收方的埠資訊）+HTTP資料包，這樣TCP資料包再嵌入IP資料包中在網路上傳送

4、網路層：
IP資料包需要知道雙方的IP地址，本機IP地址假定為192.168.1.5，接受方IP地址為220.181.111.147（百度），這樣IP資料包由頭部（IP地址資訊）+TCP資料包，

5、資料鏈路層：
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通訊了。

6、伺服器處理請求
    經過多個閘道器的轉發到百度伺服器220.181.111.147，中間通過各級物理層找到終端伺服器IP，並請求對應埠服務，服務接收到傳送過來的乙太網數包據開始解析請求資訊，從乙太網資料包中提取IP資料包——>TCP資料包——>HTTP資料包，並組裝為有效資料交與對應執行緒池中分配的執行緒進行處理，在這個過程中，生成相應request、response物件。

    處理完畢後，將資料通過response物件內部的out給客戶輸出資訊，輸出資訊也需要拼接HTTP協議頭部分，標誌out關閉後為斷開連線（注意動態內容已經在伺服器端被翻譯為靜態內容，到客戶端全部是靜態內容，JS動態組裝不算），斷開後，伺服器端自動登出request、response物件，並將釋放對應執行緒的使用標識（一般一個請求單獨由一個執行緒處理，部分特殊情況有一個執行緒處理多個請求的情況）

7、伺服器發回一個HTML響應

8、瀏覽器開始顯示HTML

客戶端接收到返回資料，去掉對應頭資訊，形成也可以被瀏覽器認識的頁面HTML字串資訊，交與瀏覽器翻譯為對應頁面規則資訊展示為介面內容。瀏覽器同樣的過程讀取到HTTP響應的內容（HTTP響應資料包），然後瀏覽器對接受到的HTML頁面進行解析，把網頁顯示出來呈現給使用者。

9、瀏覽器傳送獲取嵌入在HTML中的物件

在瀏覽器顯示HTML時，它會注意到需要獲取其他地址內容的標籤。這時，瀏覽器會發送一個獲取請求來重新獲得這些檔案。
下面是幾個我們訪問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
…
這些地址都要經歷一個和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一次的時候，響應的伺服器可能就不一樣，這說明幕後的負載平衡開始起作用了。

10. 瀏覽器傳送非同步（AJAX）請求
在Web 2.0偉大精神的指引下，頁面顯示完成後客戶端仍與伺服器端保持著聯絡。
以 Facebook聊天功能為例，它會持續與伺服器保持聯絡來及時更新你那些亮亮灰灰的好友狀態。為了更新這些頭像亮著的好友狀態，在瀏覽器中執行的 JavaScript程式碼會給伺服器傳送非同步請求。這個非同步請求傳送給特定的地址，它是一個按照程式構造的獲取或傳送請求。還是在Facebook這個例 子中，客戶端傳送給http://www.facebook.com/ajax/chat/buddy_list.php一個釋出請求來獲取你好友裡哪個 線上的狀態資訊。

提起這個模式，就必須要講講"AJAX"-- “非同步JavaScript 和 XML”，雖然伺服器為什麼用XML格式來進行響應也沒有個一清二白的原因。再舉個例子吧，對於非同步請求，Facebook會返回一些JavaScript的程式碼片段。除了其他，fiddler這個工具能夠讓你看到瀏覽器傳送的非同步請求。事實上，你不僅可以被動的做為這些請求的看客，還能主動出擊修改和重新發送它們。AJAX請求這麼容易被蒙，可著實讓那些計分的線上遊戲開發者們鬱悶的了。（當然，可別那樣騙人家~）
Facebook聊天功能提供了關於AJAX一個有意思的問題案例：把資料從伺服器端推送到客戶端。因為HTTP是一個請求-響應協議，所以聊天伺服器不能把新訊息發給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下伺服器端看自己有沒有新訊息。這些情況發生時長輪詢是個減輕伺服器負載挺有趣的技術。如果當被輪詢時伺服器沒有新訊息，它就不理這個客戶端。而當尚未超時的情況下收到了該客戶的新訊息，伺服器就會找到未完成的請求，把新訊息做為響應返回給客戶端。