利用TCP/IP　參考模型　分析數據傳輸過程

本文章轉載自：http://blog.sina.com.cn/s/blog_5ec353710101i892.html　稍微做了整理

  TCP/IP 參考模型是一個非常基礎，同是也非常重要的基礎框架，本文檔通過一個簡單的示例，結合參考模型來分析一下數據包流轉的基本過程。

  網絡環境非常簡單，如下圖所示，我們現在來分析一下 PC 去訪問 Web Server 的WEB服務，整個數據通信過程是如何發生的，為了簡化描述(我們這里暫時忽略DNS、ARP、幀校驗等等機制的工作細節)只考慮較為宏觀的層面。

利用 TCP/IP 參考模型分析數據傳輸過程:

1).  PC 訪問 Web Server 的 WEB 服務，實際上是訪問 Web Server 的 HTTP 服務。這個過程對于人來說，就是在 PC 的瀏覽器中輸入了 Web Server 的“IP地址”或“域名”，這個行為在 PC 的應用層面將觸發本地的 HTTP 進程產生一些數據，我們把這些數據稱為 DATA，它是 HTTP 的有效荷載。

2). 數據通信的最終任務是，要幫助 PC 把這個 HTTP 的有效荷載傳遞到 Web Server 上的 HTTP 進程中。

     這是一個看起來簡單的任務，但是實際上，這份數據卻要翻山越嶺。PC 的應用層將這份 HTTP 的有效荷載交給“傳輸層”（我們這里忽略TCP三次握手等內容），‘傳輸層’會為‘應用層’下來的這份數據封裝上一個報文頭部，由 HTTP 是基于 TCP 的應用，因此這里壓上的是 TCP 的頭部。

     在這個頭部之中，有目的端口號80，這個端口號將在數據到達 Web Server 后告訴對端，我要訪問你啥服務。當然，為了讓這份數據能夠可靠的被傳輸，TCP 頭部里還有其他重要的內容，這里暫不贅述。

3). 好了，HTTP 的荷載被封裝上了 TCP 的頭，為了讓這份數據能夠在IP網絡中進行傳輸，我們還需要一個“信封”，于是數據到了 PC 的“網絡層”。

     在這一層，數據被封裝上了一個 IP 報文頭部，在 IP 包頭中，寫入了源和目的 IP 地址，源IP地址為PC 的IP：192.168.1.1，而目的 IP 地址是 Web Server 的IP：192.168.2.1。

     IP 包頭部中的另一個重要的字段是協議號，這里寫入的值為6，這個值對應著 IP 頭后面封裝的協議，也就是 TCP。好了，有了IP頭這個信封，我們這份數據，就能夠在IP網絡中被從源傳遞到目的地。

4). 然而光有信封還是不夠的，至少，我們要把這個信件一段鏈路一段鏈路的搬運過去，而不能一下就從源直接穿越到目的地去吧，也不是天朝的穿越劇不是，那咋辦？

     我們還需要一個‘數據鏈路層’的頭部，由于這里是以太網的環境、以太網的鏈路，因此上層下來的數據又被封裝上了一個以太網幀頭，這是為了使得 PC 能夠將這份數據傳遞到同在鏈路上的網關 R1（的F0/0口）。

      由于 PC 設置的網關地址為 192.168.1.254，也就是 R1 的 F0/0 口IP地址，因此，當訪問 Web Server  192.168.2.1這個非本地網絡的 IP 時，PC 要求助于它的網關，因此在數據鏈路層面上，PC 要把數據傳遞到網關，它將封裝上去的以太網頭部中寫入 ‘源 MAC’也就是自己的 MAC：00DD.F800.0001，同時寫入‘目的 MAC’也就是路由器 R1 的 F0/0 口的 MAC：000.AAAA.0001，當然如果此刻 PC 沒有網關 IP 對應的 MAC，那么它會發送 ARP 消息去請求。

     以太網幀頭中還有一個重要的字段，是類型字段，類型字段用于描述我這個以太網的幀頭后面被封裝的是什么報文，這里寫入的值是0x0800,表示后面是一個IP報文。

5). 費了好大的勁兒，層層加料，終于，這份數據最終做好了傳輸的準備，從 PC 傳輸到了同在鏈路上的R1，距離目的地又更近了一點，當然，在數據在傳輸過程中，是不可能像我們圖畫的這么文藝的，它應該是一些電氣化的信息，例如1010101神馬的，不鳥他了，反正是這一坨東西是傳到了R1。

6). R1 的 F0/0 口收到了這份東西，先把它還原成‘數據幀’，查看幀頭，發現‘目的 MAC’地址正是自己 F0/0 口的 MAC地址，高興壞了，以為是誰寫給自己的情書呢，于是結合查看類型字段，發現是0800，于是知道上層被封裝的是一個IP包，它將以太網幀頭剝去，將里頭的 IP 報文交上去給 IP 協議棧處理。

7).  接下去是 R1 的‘網絡層’的工作了，他收到下層傳遞過來的 IP 包，查看 IP 包的目的 IP 地址，發現目的地是 192.168.2.1，我艸，原來不是給我的是給別人的，沒辦法，R1 拿著這個地址去自己的地圖--路由表中去查找，發現有個目的地 192.168.2.0/24 的網絡，出口是自己的 FA1/0 口，下一跳地址是192.168.12.2也就是R2。

8). 發現數據包目的 IP 地址不是自己的 R1，找到將數據送到目的地的路徑，是交給離目的地更近的192.168.12.2，而為了將數據較給同在鏈路上的 192.168.12.2，又得將數據重新封裝上以太網的幀頭，這次幀頭中的‘源 MAC’填寫的是 R1 的 FA1/0 口的 MAC地址，而‘目的 MAC’寫的是 R2 的 F0/0 口的MAC地址：

9).  妥妥兒的，數據又被R1傳遞給了R2：

10). R2 收到這個數據后，同樣的是先還原成數據幀，然后查看幀頭，結果發現‘目的 MAC’是自己的MAC，也挺高興，將數據幀丟給上層的 IP 協議去處理：

11). 結果一樣的，丫一看 IP頭部中的‘目的 IP’地址，擦類又不是給自己的，不管了，反正不是給自己的就對了：

12). 于是查路由表，發現‘目的 IP’地址 192.168.2.1 就是在自己 FA1/0 口直連的網絡192.168.2.0/24 中的一個IP地址，好辦了，緣來是家門口的人啊。于是它將數據再封裝上以太網幀頭，‘源 MAC’是自己 FA1/0 口的MAC地址，‘目的 MAC’是 Web Server 的 MAC，如果沒有 Web Server 的192.168.2.1對應的 MAC，同樣的，還是發送ARP消息去請求：

13).  數據有上路了，傳遞給了 Web Server ：

14). 說好的宏觀分析的，說著說著有變成微觀的了。 Web Server 收到這個數據幀后，查看幀頭，‘目的 MAC’是自己的網卡 MAC，而且類型字段為0800：

15). 于是將這個幀頭拆開，將里頭的‘IP 報文’交給 IP 協議去處理。

     接著 IP 協議分析這個 IP 包，查看包頭中的‘目的 IP’地址，發現正是自己的網卡 IP 沒跑兒了，又發現 IP 頭中的協議號是6，說明這 IP 頭里包裹著的是一個TCP的報文：

16). 知道 IP 頭后面包裹的是一個 TCP 報文后，它將 IP 頭剝去，將里頭的 TCP 包拿出來，發現 TCP頭部中‘目的端口號’是 80，這是一個 well-known 眾所周知的端口號：

17). 80 端口號對應的服務是 HTTP。PC發現，自己的80端口正好是打開的，HTTP 服務正在工作，于是將TCP 頭部摘掉，露出了里頭的有效荷載，哎，終于……小姑娘終于又出來了，最終被交給了 HTTP 服務。

     這樣，一份數據最終就被傳遞到了目的地的目的應用中。當然，這一過程中我們依然省略了大量的細節。值得注意的是數據通信的過程是雙向的，因此 PC 發送數據到了 Web Server ，為了讓服務交互能夠正常進行，數據還會回程，因此實際上還有一個數據返程的過程這里我們就不再分析了，原理大同小異。

關于 MAC地址 和 IP地址 在傳輸過程中變與不變的問題

  原文鏈接：http://nanjingfm.blog.51cto.com/2121842/1179368

     我們可能注意到了在上述數據包的傳輸過程中，MAC 地址發生了變化，但 IP 地址卻沒有變，為什么呢？

     實際上 MAC 地址在同一個廣播域傳輸過程中是不變的，在跨越廣播域的時候會發生改變的；而IP地址在傳輸過程中是不會改變的（除NAT的時候）。

     首先我們要知道，MAC 地址是用于同一物理或邏輯第2層網絡上的設備間進行通信的；而第三層地址（IP地址）是可以在多個網絡設備之間通信的。

      MAC地址是在同一個廣播域有效的，那么去了另外一個廣播域（網段）MAC地址肯定要改變的；在同一個廣播域中數據幀的 MAC 地址是不會變的，因為所有交換機應該都知道該廣播域中的所有主機的 MAC 地址（如果不知道會通過被動廣播的方式來學習到）。既然知道所有的MAC地址，那么當我交換機收到數據幀的時候就看一下目標 MAC 地址，然后對照一下MAC地址表，從對應的接口仍出去就好了。

     IP地址是在整個網絡中有效的，整個 Internet 網絡就相當于是一個大的地圖，同樣知道所有的 IP 地址如何到達，那么在傳輸過程中 ‘源 IP’和‘目的 IP’也是不會改變的。當路由器收到數據包的時候，檢查數據包的‘目的 IP’地址，然后查找路由表（路由轉發表），選擇合適的接口發出去。