當你浏覽一個網頁時，協定棧中發生了什麼？

說在前面的話

下面的例子是來自與計算機網絡自頂向下方法，根據書上的描述、我的了解以及一些相應的修改，進行回顧總結。

場景：使用者Bob有一個筆記本電腦，他用網線連接配接到學校實驗室的網絡，然後準備通路谷歌（www.google.com），假設學校的網絡是接在了一個ISP上，該ISP又和google的網絡是相連的，同時，DNS服務由該ISP提供，DHCP服務（後面會提到）由學校路由器提供，Bob的筆記本通過交換機和學習的路由器互聯，場景圖示如下：

詳細流程

假設最開始Bob的計算機對網絡的資訊什麼都不知道（即從來沒做過任何關于網絡資訊的緩存），那麼Bob通路google首頁會經曆以下步驟：

第一關——主要通過DHCP來得到一個本機IP位址

• （1）Bob的筆記本一開始是沒有IP位址的，沒有IP位址，也就沒辦法上Internet。于是，将利用

  DHCP（Dynamic Host Configuration Protocol）動态主機配置協定

  請求從DHCP伺服器那邊分到一個IP位址。筆記本上的作業系統将生成一個DHCP封包，并将這個封包放入一個

  UDP封包

  中（DHCP協定是建立在UDP協定上的哈），該UDP封包的

  目的端口是67

  （DHCP伺服器的端口），

  源端口是68

  （Bob筆記本的端口）。由于此時這台筆記本還沒有被分到一個具體的IP，而UDP封包肯定又要封裝到IP資料報中，于是這時的IP資料包的源IP位址是

  0.0.0.0（表示本網絡）

  ，目的IP位址是

  255.255.255.255（廣播）

• （2）包含DHCP請求封包的IP資料報又被封裝在

  以太網幀

  （假設鍊路層用的是以太網）中，該以太網幀具有的

  源MAC位址是00:16:D3:23:68:8A(Bob筆記本網卡的MAC位址)

  ,

  目的MAC位址是FF:FF:FF:FF:FF:FF(廣播)

  ,為什麼這裡需要廣播呢？因為用戶端（Bob的筆記本）也不知道自己所處的區域網路中到底由哪台機器來提供DHCP服務，是以自然就把DHCP請求向各個機器都發一遍，相當于一個一個問，诶，兄弟，你能給我分個IP位址嗎？A機器說，不能，滾！它又去問機器B…就這樣一直問下去
• （3）為了達到上述的以太網幀廣播的目的，實際上是Bob的計算機先把這個包含DHCP的以太網幀（中間依次又封裝了UDP封包、IP封包）發送到該計算機連接配接到的交換機，交換機向所有連接配接到的機器廣播該以太網幀。
• （4）我們假設學校的路由器提供DHCP服務。因為這個路由器又是連接配接在交換機上的，自然就會收到上述包含Bob計算機DHCP請求的以太網幀了，則路由器在它的具有MAC位址為

  00:22:6B:45:1F:1B

  的接口上接受到DHCP請求的以太網幀，并從中抽出IP資料報，還記得第（1）步中Bob計算機發送的IP報的目的IP位址嗎？——對，

  255.255.255.255

  ，這樣一來，路由器解析到了該目的IP，就知道這個資料報應當由該結點的上層協定來處理，于是該IP報的資料段中的UDP封包會被分解，路由器上運作的DHCP服務程式(綁定在67号端口上)會從該UDP封包中解析出DHCP請求封包，然後做配置設定IP的操作。
• （5）假設學校路由器上的DHCP伺服器能夠在

  CIDR塊68.85.2.0/24

  的一堆網絡IP中給Bob的筆記本配置設定一個IP

  68.85.2.101

  ，而學校的這個CIDR塊又是從ISP Comcast那邊

  68.80.0.0/13

  分到的一小塊。然後DHCP伺服器會生成一個包含分出來的IP位址（

  68.85.2.101

  ）、DNS伺服器的IP位址（

  68.87.71.226

  ）、預設網關路由器的IP位址（

  68.85.2.1

  )、子網塊（

  68.85.2.0/24

  相當于子網路遮罩）的

  DHCP ACK封包

  ，這個封包又會被封裝進UDP封包，進而封裝進IP資料報，進而封裝進以太網幀中，該以太網幀具有的

  源MAC位址是00:22:6B:45:1F:1B(路由器一個接口的MAC位址)

  ,

  目的MAC位址是00:16:D3:23:68:8A

  ，這個目的MAC位址就是從包含DHCP請求封包的以太網幀中解析出來的哈。

說明一下，因為學校這塊區域網路中隻有一個路由器，是以預設網關也肯定隻能是這個路由器了

• (6）包含DHCP ACK封包的以太網幀由路由器發給交換機，由于交換機這個東西呢，它有個所謂的

  自學習

  特性，其實就是說，交換機會從每次交換的以太網幀中提取到源主機的MAC位址，然後記錄到一張交換表中（學習過程），萬一有一個MAC位址沒在交換表中呢（沒學習到）？—— 對了，簡單粗暴，廣播給所有接入的機器上去。 由于之前Bob的筆記本在發送DHCP請求封包的時候經過了一次交換機，是以它的MAC位址（也就是DHCP ACK封包的目的MAC位址）肯定會被學習到。然後交換機就将路由器那邊發過來的DHCP ACK封包直接轉發給Bob的筆記本了
• （7）Bob的筆記本接受到DHCP ACK封包，然後就會像DHCP伺服器那樣依次解析出DHCP封包中的資訊，然後把各個字段（分到的IP位址、DNS伺服器位址、預設網關位址、子網路遮罩這些）解析出來，然後把本機的配置改一下。

呼。。。。這麼一大通操作下來，Bob的算是通網了，離着通路google更近了一步。

第二關——DNS協定和ARP協定

Bob打開浏覽器，在位址欄裡面輸入：

www.google.com

• （8）我們知道，域名肯定是要對應到它的IP位址才能進行通信的，于是Bob的作業系統是以生成一個

  DNS（Domain Name System）查詢封包

  （這個協定也是基于UDP協定的），于是

  www.google.com

  這個URL被放進了DNS封包的問題段中，且該DNS封包的

  目的端口是53

  （DNS伺服器），這個DNS封包被封裝進UDP封包中，UDP封包的

  源IP是68.85.2.101

  ，

  目的IP是68.87.71.226

  （DHCP ACK封包中已經擷取到）
• （9）上一步包含DNS請求封包的資料報被放入一個以太網幀中，好了，這個幀即将轉發到學校的路由器上去，然後再通過中間一些列路由器轉發到DNS伺服器上去（當然，這個過程對用戶端來說是透明的）。！！！等等！！！，好像有點不對大頭，這個以太網幀的

  目的MAC

  是什麼？？？目前Bob的筆記本是知道網關的IP位址的，可是不止到網關的MAC位址呀！這樣一來，就不知道讓交換機轉發給誰了。 是的，這個時候

  ARP(Address Resolution Protocol)位址解析協定

  就派上用場了。
• （10）Bob的筆記本生成一個ARP查詢封包，該封包的目的IP位址是

  68.85.2.1

  ,也就是預設網關，因為不知道那個網關IP對應的MAC位址嘛（也正是我們想要得到的），沒辦法，被逼無奈，隻能用最簡單粗暴的方法了——廣播。老鐵再一次逐個詢問（挨個問交換機出口的所有機器），你的IP位址是不是

  68.85.2.1

  啊？是的話，麻煩你把你的MAC位址告訴我一下，我想送點東西到你家裡去，要不然我找不到你。 是的，和上面說到的DHCP請求封包類似，這裡也會生成一個目的位址為

  FF:FF:FF:FF:FF:FF

  的以太網幀，交換機會廣播出去。
• （11）交換機出端口這邊的所有機器都收到了廣播以太網幀，而隻有網關路由器發現，自己的IP位址和這個封裝了ARP請求封包的幀中的目的IP位址比對，于是就把自己的MAC位址封裝進一個

  ARP回答封包

  中（它估計是有人有好事要找他了，呵呵），然後把這個ARP回答封包封裝進一個以太網幀中，該幀的

  源MAC位址是00:22:6B:45:1F:1B(路由器一個接口的MAC位址)

  ,

  目的MAC位址是00:16:D3:23:68:8A

  ，并将該幀發送給交換機，交換機發給Bob的筆記本。

細心的你可能會發現，诶，這個幀的目的和源位址好像和之前DHCP ACK封包一樣啊！是的，回顧一下說在前面的話，我們假設DHCP服務是在學校路由器上提供的，于是這裡就産生了一個目的和源MAC位址一樣的幀。但是實際情況中，DHCP伺服器可能和預設網關伺服器不是在同一台機器上（是以，你可以認為這是湊巧吧。）

• （12）Bob的筆記本收到了上述包含ARP回答封包的幀，并從中解析出預設網關的MAC位址（

  00:22:6B:45:1F:1B

  ）
• （13）現在Bob的筆記本知道了預設網關的MAC位址了，于是在第（9）步中的問題解決了，封裝DNS查詢請求的以太網幀終于可以通過交換機轉發到預設網關那邊去了，至于預設網關路由器再怎麼轉發這個DNS查詢封包，對不起，Bob的筆記本就不管那麼多了。

第三關——路由選擇到DNS伺服器

• (14) 網關路由器接受到交換器轉發過來的包含DNS查詢封包的以太網幀，并從中抽取出IP資料報，路由器找到IP資料報中的目的IP位址

  68.87.71.226

  ，并根據路由器中的轉發表知道應該發送到ISP提供方的最左側的那個路由器上去（這裡可能會涉及到

  不同自治域之間的路由選擇協定

  ），然後把原以太網幀進行相應修改并發送出去（這裡會把最初始的MAC源位址和目的位址進行變換哈）
• （15）在Comcast網絡中，最左邊的路由器接收到該幀後，抽取IP資料封包，發現目的位址是

  68.87.71.226（DNS伺服器）

  ，于是它根據

  域内路由選擇協定（RIP或OSPF等）

  将資料報繼續向下一站轉發。
• （16）最終，包含DNS查詢的IP資料報到達了DNS伺服器，DNS伺服器從中抽取出DNS查詢封包，發現用戶端是想查詢www.google.com的IP位址，伺服器于是從本地檔案系統（檔案或資料庫中）從查詢到谷歌的IP位址，生成一個DNS回答封包，并将之封裝進UDP封包中，然後發回到Bob的筆記本。

這裡發回的過程和Bob發送的過程剛好完全相反

• （17）Bob的筆記本接受到DNS回答封包，然後從中解析出了www.google.com的IP位址，準備開始接觸谷歌伺服器了！

最後一關—— Web用戶端和伺服器互動：TCP和HTTP

• （18）假設Web用戶端希望發送一個

  HTTP GET

  請求，請求到www.google.com頁面，為了達到此目的，用戶端好伺服器之間要建立TCP連接配接（HTTP是面向連接配接的協定），準備開始

  三次握手

  過程。于是Bob的筆記本首先生成一個目的端口為

  80（伺服器HTTP端口）

  的

  TCP SYN（TCP連接配接封包）

  ，該TCP封包放置在具有目的IP位址為

  64.233.169.105(www.google.com DNS回複封包中所得)

  的IP資料報中，并将該資料包放在MAC位址為

  00:22:6B:45:1F:1B(網關路由器的MAC位址)

  的以太網幀中，并向交換機發送該幀
• （19）經過一些列的路由器轉發，包含TCP SYN的資料包到達谷歌伺服器，伺服器分解封包，并将之分解到與80端口聯系的

  歡迎套接字

  ，然後谷歌HTTP伺服器和Bob筆記本之間的TCP連接配接生成一個

  連接配接套接字

  ,産生一個

  TCP SYN ACK

  封包，并将之發回到Bob的筆記本（和TCP SYN封包剛好相反）
• （20）Bob筆記本收到

  TCP SYN ACK封包

  ，并且生成一個

  ACK封包

  确認收到伺服器端的響應，此時三次握手完畢，用戶端和服務端之間建立好了連接配接。
• （21）包含HTTP GET請求的HTTP封包被封裝進TCP封包中，從Bob筆記本傳往谷歌HTTP伺服器。
• （22）谷歌HTTP伺服器收到TCP封包後，解析出封包内容，知道用戶端想要得的www.google.com的内容，于是将該頁面的HTML内容封裝進TCP封包中作為響應，發送回Bob的筆記本。
• （23）Bob的筆記本收到HTTP 響應封包，交給浏覽器，解析出其中的HTML内容，顯示網頁内容！

以上所有的步驟，就是浏覽一個網頁時，協定棧中發生的事情。

如有錯誤，請留言指明。