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

创新互联公司是一家专注于网站建设、做网站与策划设计,琼中黎族网站建设哪家好?创新互联公司做网站,专注于网站建设十多年,网设计领域的专业建站公司;建站业务涵盖:琼中黎族等地区。琼中黎族做网站价格咨询:13518219792

  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’地址，然后查找路由表（路由转发表），选择合适的接口发出去。

名称栏目：利用TCP/IP　参考模型　分析数据传输过程
网页地址：http://kswjz.com/article/ppcsjj.html