利用 TCP IP 模型理解数据通信过程
1. 回顾TCP/IP模型
什么是数据网络(Data Network)?简单地说,数据网络就是一个由各种设备搭建起来的一张网,常见的设备有:路由器、交换机、防火墙、负载均衡器、IDS/IPS、VPN服务器等等。数据网络最基本的功能就是实现不同节点之间的数据互通,也就是数据通信。
TCP/IP模型是当今IP网络的基础(也被称为DoD模型,上图我贴出的并不是标准的TCP/IP模型,为了方便下文的阐述,这里给出的是一个TCP/IP模型与OSI模型的对等模型),它将整个数据通信的任务划分成不同的功能层次(Layer),每一个层次有其所定义的功能,以及对应的协议。打个比方,对于一家公司而言,一笔业务需要各个部门相互协同工作才能完成,部门与部门之间既相互独立,但是又需要相互配合,可以借用这种思路来理解TCP/IP参考模型。分层参考模型的设计是非常经典的理念:
- 层次化的模型设计将网络的通信过程划分为更小、更简单的部件,因此有助于各个部件的独立开发、设计和故障排除;
- 层与层之间相互独立,又互相依赖,每一层都有该层的功能、以及定义的协议标准。层层之间相互配合,共同完成数据通信的过程;
- 通过组件的标准化,允许多个供应商进行开发;
- 通过定义在模型的每一层实现什么功能,鼓励产业的标准化;
- 允许各种类型的网络硬件和软件相互通信。
上面这张图显示的就是每个层次对应的代表性协议。
2. 理解数据通信过程
根据上图所示的网络拓扑(Topology),我们来分析一下PC访问Server的WEB服务的详细通信过程。
在阐述过程中,我们聚焦的重点是利用TCP/IP参考模型理解数据通信过程,因此可能会忽略部分技术细节,例如DNS、TCP三次握手等,这些技术细节这里暂不做讨论。现在你要换一种视野来看待这个“世界”了,想象一下上图所示的终端以及路由器都是一个个的“TCP/IP通信模型”,事实上,整个过程在宏观层面体现如下:
我们一步一步的来分析:
- PC的用户在WEB浏览器中访问Server的WEB服务(这里我们暂且不去关注HTTP交互、DNS交互等细节,重点看通信过程),PC的这次操作将触发HTTP应用为用户构造一个应用数据(如下图所示)。当然这个数据最终要传递到Server并“递交”到Server的HTTP应用来处理,但是HTTP不关心数据怎么传、怎么寻址、怎么做差错校验等等,这些事情交由专门的层次来完成,所以HTTP应用数据还需经过一番“折腾”才能从PC传到Server,OK GO。
- 由于HTTP基于TCP,因此这个应用数据交由参考模型中的主机到主机层(第4层)进一步处理。在该层,上层HTTP应用的数据被封装一个TCP的头部(可以简单的理解为套了一个TCP的信封)在TCP头部中我们重点关注两个字段(信封上写的东西),一个是源端口号,另一个是目的端口号,源端口号为随机产生的端口号(是PC本地设置的、专门用于本次会话的端口),目的端口号为80(HTTP服务对应的默认端口号是80),如下图所示。然后这个数据段(Segment)被交给下一个层处理。
- 下一层是网络层,也叫因特网层(第3层),处于这个层的IP协议为这个上层下来的数据封装一个IP头部(在之前的基础上又套了一个信封,如下图所示),以便该数据能够在IP网络中被网络设备从源转发(路由)到目的地。在IP头当中我们重点关注源IP地址、目的IP地址、协议号这三个字段。其中源地址填写的是PC自己的IP地址192.168.1.1,目的地址存放的是Server的IP地址192.168.2.1,而协议号字段则存放的是值6,这个值是一个众所周知(Well-Known),也就是行业约定的值,该值对应上层协议类型TCP,表示这个IP头后面封装的上层协议为TCP(形象点的描述是,协议字段用于表示这个IP信封里装的是一个TCP的内容)。搞定之后,这个数据被交给下一层处理。
- 为了让这个IP数据包能够在链路上传输(从链路的一个节点传到另一节点),还要给数据包封装上一个数据链路层(第2层)的头部,以便该数据能够在链路上被顺利传输到对端。由于PC与R1之间为以太网链路,因此上层来的IP数据包被封装一个以太网的数据帧头(再增加一个信封)。这个帧头中写入的源MAC地址为PC的网卡MAC,那么目的MAC呢?PC知道,数据的目的地是192.168.2.1这个IP,而本机IP是192.168.1.1/24,显然,目的地与自己并不在同一个IP网段,因此需要求助于自己的默认网关,让网关来帮助自己将数据包转发出去。那首先得把数据转发到网关吧?因此目的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包。费了好大劲儿,这个数据帧(Frame)终于搞定了,如下图所示:
- 值得一提的是,事实上在物理链路中传输的是比特(bit)流,或者电气化的脉冲型号,只不过为了方便理解和更加直观地分析,我们往往会以IP包或者数据帧的形式来阐述通信过程。所以从物理上说,最终这个以太网数据帧变成了一堆的101110101从网线传到了路由器R1上,如下图所示:
- 路由器R1在收到这一串的1010…后,先将他们还原成数据帧(如下图所示)。然后会采用相应的机制检查一下数据帧在传输过程中是否有损坏,如果没有损坏,那么就瞅瞅数据帧头部中的目的MAC地址,看看目的MAC地址是不是我收到这个数据帧的GE0/0/0接口的MAC,结果发现正好是自己的MAC,那么它会很高兴,觉得这个数据帧是给它的,它查看数据帧头部的类型字段,发现是0x0800,于是它知道里头装的是一个IP包,接着它将以太网帧头剥去,或者说解封装,然后将里面的数据移交给上层的IP协议继续处理。
- 现在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数据包往下交还给数据链路层去处理。
- 现在数据链路层继续处理上层下来的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。
-
R2收到这些10101…后,同样的,还是先将其还原成帧,然后查看帧头,发现目的MAC填写的就是自己接口的MAC,并且帧头中类型字段写的是0x0800(指示上层协议是IP,也就是数据帧头内封装的是一个IP包),于是将数据帧头剥去,将里头的IP数据包交给IP协议去处理。
-
而IP协议在处理过程中发现,目的IP地址并非本路由器的IP(如下图所示),于是它知道这个数据包不是发送给自己的,它拿着目的IP地址192.168.2.1在自己路由表中查询,结果发现,R2的GE0/0/1口就连接着192.168.2.0/24网络,原来家门口就是了,于是它将这个IP包交还给下层协议去处理。
- 接下来又是重新封装成帧,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,如下图所示:
- 好不容易,终于数据帧到达了Server(如下图所示)。Server首先将这些比特流还原成帧,然后做校验看看帧是否损坏,如果没有,则查看数据帧的目的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,而Server本地的TCP 80端口是开放的,开放给HTTP应用了,因此它将TCP头部剥去,将里头的载荷交给HTTP应用。终于,从PC发送出来的HTTP应用数据到达了目的地——Server的HTTP应用的手中。
文章来源: blog.csdn.net,作者:wljslmz,版权归原作者所有,如需转载,请联系作者。
原文链接:blog.csdn.net/weixin_43025343/article/details/109112303
- 点赞
- 收藏
- 关注作者
评论(0)