Chinaunix首页 | 论坛 | 博客
  • 博客访问: 33212
  • 博文数量: 8
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 87
  • 用 户 组: 普通用户
  • 注册时间: 2013-11-16 16:47
文章分类

全部博文(8)

文章存档

2014年(6)

2013年(2)

我的朋友

分类: 网络与安全

2014-07-25 16:43:58

1.回顾TCP/IP模型
 


TCP/IP模型是当今IP网络的基础(由OSI七层参考模型发展而来,也称为DoD模型)。
分层参考模型的设计是非常经典的理念:

  • 层次化的模型设计将网络的通信过程划分为更小、更简单的部件,因此有助于各个部件的独立开发、设计和故障排除;
  • 层与层之间相互独立,又互相依赖,每一层都有该层的功能、以及定义的协议标准。层与层之间相互配合,共同完成数据通信的过程;
  • 通过组件的标准化,允许多个供应商进行开发;
  • 通过定义在模型的每一层实现什么功能,鼓励产业的标准化;
  • 允许各种类型的网络硬件和软件相互通信。

 


2.理解数据通信过程
 


下面我们来分析一下PC去访问Server的WEB服务的详细通信过程。在阐述过程中,我们重点放在利用TCP/IP参考模型理解通信过程,因此可能会忽略部分技术细节,例如DNS、TCP三次握手等,这些技术细节这里暂不做讨论。事实上,整个过程的宏观层面如下:
 


我们一步一步的来分析:

1) PC的用户在WEB浏览器中访问Server的WEB服务(这里我们暂且不去关注底层的HTTP交互、DNS交互等细节。重点看通信过程),PC的这次操作将触发HTTP应用为用户构造一个应用数据。当然这个数据最终要传递到Server并最终“递交”到Server的HTTP应用来处理,但是HTTP不关心数据怎么传、怎么寻址、怎么做差错校验等等,那么这些事情就交由专门的Layer来完成,所以HTTP应用数据还的经过一番“折腾”才能从PC传出去到达Server,现在开始。
 


 

2) 由于HTTP基于TCP,因此这个应用数据交由TCP/IP模型中的主机到主机层进一步处理。在该层,上层HTTP应用数据被封装上一个TCP的头部,在TCP头部中,这里我们重点关注两个字段,一个是源端口号,另一个是目的端口号,源端口号为随机,目的端口号为80(HTTP服务对应的默认端口号是80)。然后这个数据segment被交给下一个Layer处理。
 



3) 到了IP层,IP协议为这个上层下来的数据封装上一个IP头,以便该数据能够在IP网络中被网络设备转发(路由)。IP头当中,我们重点关注源IP地址、目的IP地址、协议号这三个字段。其中源地址存放的是PC自己的IP地址192.168.1.1,目的地址存放的是Server的IP地址192.168.2.1,而协议号字段则存放的是值6,这个值是一个well-known值,也就是行业约定的、众所周知的值,该值对应上层协议类型TCP,表示我这个IP头后面封装的上层协议为TCP。搞定之后,这个数据被交给下一层处理。
 


4)为了让这个IP数据包能够在链路上传输,还要给数据包封装上一个数据链路层的头部,由于我们这里是以太网链路,因此上层下来的IP数据包被封装上一个以太网的数据帧头。这个数据帧头中源MAC地址为PC的网卡MAC,那么目的MAC呢?PC知道,数据的目的地是192.168.2.1这个IP,而本机IP是192.168.1.1/24,显然,目的地与自己并不在同一个网段,因此需要借助自己的网关,让网关来帮助自己将数据包转发出去。那么首先我得把数据转发到网关吧?因此目的MAC地址填写的就是网关192.168.1.254对应的MAC地址。但是初始情况下,PC可能并没有192.168.1.254的MAC,所以,它会发送一个ARP广播去请求192.168.1.254的MAC,R1的GE0/0/0口会收到这个ARP请求并且回送ARP响应。如此一来PC就知道了网关的MAC,它将网关MAC 0018-0011-0001填写在以太网数据帧头部的目的MAC中。另外,以太网数据帧头的类型字段写上0x0800这个值,表示我这个数据帧头后面封装的是一个IP包。好了费了好大劲儿,这个数据帧终于搞定了:
 


5)值得一提的是,事实上在物理链路中传输的是bit流,或者电气化的脉冲,只不过为了方便理解和更加直观的分析,我们往往会以IP包或者数据帧的形式来阐述通信过程。所以从物理上说,最终这个以太网数据帧变成了一堆的101010101从网线传到了路由器R1上。
 


6)路由器R1在收到这一串的1010后,先将他们还原成数据帧。
然后会采用相应的机制检查一下数据帧在传输过程中是否有损坏,如果没有损坏,那么就瞅瞅数据帧头部中的目的MAC地址,看看目的MAC地址是不是我收到这个数据帧的GE0/0/0口的MAC,结果发现是,它很高兴,觉得这个数据帧是给我的,它查看数据帧头部的类型字段,发现是0x0800,于是它知道里头装的是一个IP包,接着它将以太网数据帧头剥去或者说解封装,然后移交给上层IP协议继续处理。
 


7)现在R1的IP协议栈接着处理这个报文:
 


它会先校验一下数据在传输过程中,IP头有没有受损,如果没有,它就查看IP头中的目的IP地址字段,结果发现目的IP地址为192.168.2.1,发现其实并不是自己的IP地址 – 原来这个数据包是发给别人的,于是它开始拿着目的地址192.168.2.1到地图(路由表)里去查,看看有没有到192.168.2.1这个目的地去的路径,结果发现有,并且这个路由条目指示它把数据包从从GE0/0/1口送出去交给192.168.12.2这个IP。于是它不再继续拆IP头看包裹里头的东东了,而是乖乖的将IP数据包往下交还给以太网协议去处理。

8)现在以太网协议继续处理上层下来的IP包,它为这个IP包封装上一个新的以太网帧头,帧头中源MAC地址为R1的GE0/0/1口的MAC:0018-0011-0002,目的MAC是这个数据包即将交给的下一跳路由器192.168.12.2对应的MAC,当然初始情况下R1是不知道这个MAC的,因此又是一轮ARP广播并最终拿到这个MAC:0018-0022-0001,于是它将这个值填写在目的MAC字段中。完成新的数据帧头的封装后,R1把这个数据帧变成1010101通过电气信号传递给R2。
 


9)R2收到这些10101后,同样的,还是先成帧,然后查看帧头,发现目的MAC填写的就是自己接口的MAC,并且帧头中类型字段写的是0x0800(指示上层协议是IP,也就是数据帧头内封装的是一个IP包),于是将数据帧头剥去,将里头的IP数据包交给IP协议去处理。
 


10)而IP协议在处理过程中发现,目的IP地址并非本路由器的IP,于是它知道,这个数据包不是发送给自己的,它拿着目的IP地址192.168.2.1在路由表中去查,结果发现,R2的GE0/0/1口就连接着192.168.2.0/24网络,原来家门口就是了,于是它将这个IP包交还给下层协议去处理。
 


11)接下来又是重新封装成帧,R2为这个IP包封装上一个新的数据帧头部,帧头中,源MAC为R2的GE0/0/1口的MAC,目的MAC为192.168.2.1这个IP地址对应的MAC,如果ARP表里有192.168.2.1对应的MAC,则直接将MAC地址写入目的MAC中,如果没有,则发ARP去请求。另外类型字段依然填写0x0800。最终,R2将这个数据帧传给了Server。
 


12)好不容易,终于数据帧是到了Server了。Server首先是将101010这些比特流还原成帧,然后做校验看看帧头是否损坏,如果没有,则查看数据帧的目的MAC,结果发现就是自己的MAC,于是查看类型字段,发现是0x0800,于是知道这里头装的是一个IP包,于是将帧头剥去,将内层的IP数据包交给上层协议IP去处理。IP收到这个数据包之后,首先依然是查看IP包头是否损坏,如果没有,则查看目的IP地址,发现目的IP地址是192.168.2.1正是自己的网卡IP,于是它知道,这个IP包是发给自己的,因此继续查看IP包头中的协议字段,发现协议字段填写的是6这个值,原来这个IP包头后面封装的是一个TCP的数据,因此将IP包头剥去,将里头的TCP数据交给上层的TCP协议去处理。而TCP在处理这个数据的时候,查看TCP头部的目的端口号,发现目的端口号是80,而本地的TCP80端口是开放的,开放给HTTP应用了,接着它将TCP头部剥去,交给HTTP应用,好了终于从PC发送出来的HTTP应用数据,到达了目的地 –Server的HTTP应用的手中。

阅读(1348) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~