红茶三杯(http://weibo.com/vinsoney)原创技术博文,版权归作者所有,转载请注明出处。
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,为了让服务交互能够正常进行,数据还会回程,因此实际上还有一个数据返程的过程这里我们就不再分析了,原理大同小异。