利用TCP/IP　參考模型　分析數(shù)據(jù)傳輸過程

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

  TCP/IP 參考模型是一個非常基礎(chǔ)，同是也非常重要的基礎(chǔ)框架，本文檔通過一個簡單的示例，結(jié)合參考模型來分析一下數(shù)據(jù)包流轉(zhuǎn)的基本過程。

  網(wǎng)絡(luò)環(huán)境非常簡單，如下圖所示，我們現(xiàn)在來分析一下 PC 去訪問 Web Server 的WEB服務(wù)，整個數(shù)據(jù)通信過程是如何發(fā)生的，為了簡化描述(我們這里暫時忽略DNS、ARP、幀校驗(yàn)等等機(jī)制的工作細(xì)節(jié))只考慮較為宏觀的層面。

利用 TCP/IP 參考模型分析數(shù)據(jù)傳輸過程:

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

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

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

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

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

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

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

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

     我們還需要一個‘?dāng)?shù)據(jù)鏈路層’的頭部，由于這里是以太網(wǎng)的環(huán)境、以太網(wǎng)的鏈路，因此上層下來的數(shù)據(jù)又被封裝上了一個以太網(wǎng)幀頭，這是為了使得 PC 能夠?qū)⑦@份數(shù)據(jù)傳遞到同在鏈路上的網(wǎng)關(guān) R1（的F0/0口）。

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

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

5). 費(fèi)了好大的勁兒，層層加料，終于，這份數(shù)據(jù)最終做好了傳輸?shù)臏?zhǔn)備，從 PC 傳輸?shù)搅送阪溌飞系腞1，距離目的地又更近了一點(diǎn)，當(dāng)然，在數(shù)據(jù)在傳輸過程中，是不可能像我們圖畫的這么文藝的，它應(yīng)該是一些電氣化的信息，例如1010101神馬的，不鳥他了，反正是這一坨東西是傳到了R1。

6). R1 的 F0/0 口收到了這份東西，先把它還原成‘?dāng)?shù)據(jù)幀’，查看幀頭，發(fā)現(xiàn)‘目的 MAC’地址正是自己 F0/0 口的 MAC地址，高興壞了，以為是誰寫給自己的情書呢，于是結(jié)合查看類型字段，發(fā)現(xiàn)是0800，于是知道上層被封裝的是一個IP包，它將以太網(wǎng)幀頭剝?nèi)ィ瑢⒗镱^的 IP 報文交上去給 IP 協(xié)議棧處理。

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

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

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

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

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

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

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

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

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

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

16). 知道 IP 頭后面包裹的是一個 TCP 報文后，它將 IP 頭剝?nèi)ィ瑢⒗镱^的 TCP 包拿出來，發(fā)現(xiàn) TCP頭部中‘目的端口號’是 80，這是一個 well-known 眾所周知的端口號：

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

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

關(guān)于 MAC地址 和 IP地址 在傳輸過程中變與不變的問題

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

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

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

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

      MAC地址是在同一個廣播域有效的，那么去了另外一個廣播域（網(wǎng)段）MAC地址肯定要改變的；在同一個廣播域中數(shù)據(jù)幀的 MAC 地址是不會變的，因?yàn)樗薪粨Q機(jī)應(yīng)該都知道該廣播域中的所有主機(jī)的 MAC 地址（如果不知道會通過被動廣播的方式來學(xué)習(xí)到）。既然知道所有的MAC地址，那么當(dāng)我交換機(jī)收到數(shù)據(jù)幀的時候就看一下目標(biāo) MAC 地址，然后對照一下MAC地址表，從對應(yīng)的接口仍出去就好了。

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