Linux 系统应用编程——网络编程（利用TCP/IP 模型分析数据传输过程）

TCP/IP参考模型是一个非常基础，而且也非常重要的基础框架，要想入门数通这是个必须掌握的基本概念，本文档通过一个简单的示例，结合参考模型来分析一下数通的基本过程。



网络环境非常简单，如下图所示，我们现在来分析一下PC去访问Webserver的WEB服务，整个数据通信过程是如何发生的，为了简化描述，我们这里暂时忽略DNS、ARP、帧校验等等机制的工作细节，只考虑较为宏观的层面。

1）PC访问WebServer的WEB服务，实际上是访问Webserver的HTTP服务。这个过程对于人来说，就是在PC浏览器里输入了Webserver的IP地址或域名，这个行为在PC的应用层面将触发本地的HTTP进程产生一些数据，我们把这些数据称为DATA，它是HTTP的有效荷载：

2）数通的最终任务是，要帮助PC把这个HTTP的有效荷载传递到Webserver上的HTTP进程中。这是一个看起来简单的任务，但是实际上，这份数据却要翻山越岭。PC的应用层将这份HTTP的有效荷载交给“传输层”（我们这里忽略TCP三次握手等内容），传输层会为应用层下来的这份数据封装上一个报文头部，由HTTP是基于TCP的应用，因此这里压上的是TCP的头部，在这个头部之中，有目的端口号80，这个端口号将在数据到达Webserver后告诉对端，我要访问你啥服务。当然，为了让这份数据能够可靠的被传输，TCP头部里还有其他重要的内容，这里暂不赘述。

3）好了，HTTP的荷载被封装上了TCP的头，为了让这份数据能够在IP网络中进行传输，我们还需要一个“信封”，于是数据到了PC的“因特网层”，在这一层，数据被封装上了一个IP报文头部，在IP包头中，写入了源和目的IP地址，源IP地址为PC的IP：192.168.1.1，而目的IP地址是WebServer的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地址，因此，当访问Webserver
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报文：红茶三杯（http://weibo.com/vinsoney）原创技术博文，版权归作者所有，转载请注明出处。

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协议去处理：红茶三杯（http://weibo.com/vinsoney）原创技术博文，版权归作者所有，转载请注

11）结果一样的，丫一看IP头中的目的IP地址，擦类又不是给自己的，咦，为什么要说又字？不管了，反正不是给自己的就对了：

12）于是查路由表，发现目的IP地址192.168.2.1就是在自己FA1/0口直连的网络192.168.2.0/24中的一个IP地址，好办了，缘来是家门口的人啊。于是它将数据再封装上以太网帧头，源MAC是自己Fa1/0口的MAC地址，目的MAC是Webserver的MAC，如果没有Webserver的192.168.2.1对应的MAC，同样的，还是发送ARP消息去请求：

13）数据有上路了，传递给了Webserver

14）说好的宏观分析的，说着说着有变成微观的了。Webserver收到这个数据帧后，查看帧头，目的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发送数据到了WebServer，为了让服务交互能够正常进行，数据还会回程，因此实际上还有一个数据返程的过程这里我们就不再分析了，原理大同小异。