【DataCom基础01】基于TCP/IP模型理解数据通信过程

【DataCom基础01】基于TCP/IP模型理解数据通信过程

1、回顾TCP/IP模型

什么是数据网络（Data Network）？ 简单来说，数据网络的基础就是一个由各种设备搭建起来的一张网，常见的设备有：

路由器，交换机，防火墙，负载均衡器，IDS/IPS，VPN等等。数据网络最基本的功能就是实现不同节点之间的数据互通，也就是数据通信。

TCP/IP模型是当今IP网络的基础，它将整个数据通信的任务划分为不同的功能层次（Layer），每一个层次都有其所定义的功能，以及对应的协议。打个比方，对于一家公司而言，公司的一笔业务需要其各个部门相互协同工作才能完成，部门与部门之间既相互独立，但又需要相互配合，可以借用这种思路来理解TCP/IP参考模型。分层参考模型的设计是非常经典的理念：

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

上面这张图显示的就是每个层次对应的代表性协议。

2、理解数据通信过程

根据上图所示的网络拓扑（Topology），我们来分析一下PC访问Server的WEB服务的详细通信过程。在阐述过程中，我们聚焦的重点是利用TCP/IP参考模型理解通信过程，因此可能会忽略部分技术细节，例如DNS、TCP三次握手等，这些技术细节在这里暂不做讨论。现在你要换一种视野来看待这个“世界”了，想像一下上图所示的终端和路由器都是一个个的“TCP/IP通信模型”，事实上，整个过程的宏观层面如下：

我们一步一步的来分析：

1. PC的用户在WEB浏览器中访问Server的WEB服务（这里我们暂且不去关注底层的HTTP交互、DNS交互等细节。重点看通信过程部分），PC的这次操作将触发HTTP应用为用户构造一个应用数据（如下图所示）。当然这个数据最终要传递到Server并“递交”到Server的HTTP应用来处理，但是HTTP不关系数据是怎么传、怎么寻址、怎么做差错校验等等，这些事情都交由专门的Layer来完成，所以HTTP应用数据还得经过一番“折腾”才能从PC传到Server，OK，Let’s Go！

2. 由于HTTP基于TCP，因此这个应用数据会交由TCP/IP模型中的传输层（也就是第4层）进一步的处理。在该层，上层的HTTP应用的数据会被封装上一个TCP的头部（可以简单的理解为套了一个TCP的信封），在TCP头部中我们重点关注两个字段（信封上写的东西），一个是源端口号，另一个是目的端口号，源端口号是随机产生的端口号（是PC本地专门用于本次HTTP会话的临时端口），目的端口号为80（HTTP服务对应的默认端口号是80）。然后这个数据段（Segment）将被交给下一层去处理。

3. 下一层是网络层，处于这个层的IP协议会为这个上层（传输层）下来的数据段封装上一个IP头部 （相当于在之前TCP的信封上又套了一个信封，如下图所示），以便于该数据能够在IP网络中被网络设备从源端转发（路由）到目的端。在IP头中我们重点关注源IP地址、目的IP地址和协议号这三个字段。其中源IP地址填写的是PC自己的IP地址192.168.1.1 ，目的IP地址填写的是Server的IP地址192.168.2.1 ，而协议号字段则存放的是值6，这个值是一个众所周知（Well-Known）也就是行业约定的值，该值对应上层协议类型为TCP，表示这个IP头后面封装的上层协议是TCP协议（形象点的描述是，协议字段用于表示这个IP信封里面装的是一个TCP信封）。搞定之后，这个数据被交给下一层进行处理。

4. 为了让这个IP数据包（Packet）能够在数据链路上进行传输，还要给数据包封装上一个数据链路层的头部，以便该数据能够在链路上被顺利传输到链路对端。由于我们这里是以太网链路，因此上层下来的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响应。另外，以太网数据帧头的类型字段会填写上0x0800这个值，表示我这个数据帧后头封装的是一个IP包。好了废了老大劲儿，这个数据帧（Frame）终于搞定了：

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

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

7. ​ 现在R1的IP协议栈接着处理这个报文：

它会先校验一下数据在传输的过程中，IP头部有没有受损，如果没有，它就查看IP头中的目的IP地址字段，结果发现目的IP地址是192.168.2.1，并不是自己的IP地址——原来这个数据包是发给别人的啊。于是，它开始拿着这个目的IP地址192.168.2.1到自己的地图（路由表）里去查找，去看看有没有到192.168.2.1这个目的地的路径，结果发现是有的，并且这个路由条目指示它把数据包从它自己的GE0/0/1口发送出去交给192.168.12.2这个IP。于是乎，它也不再继续去IP头包裹里面的东东了，而是乖乖的讲IP数据往下层提交，给数据链路层去处理。

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

9. R2收到这些010101后，同样的，还是先将其还原成数据帧，然后看到数据帧头，发现目的MAC填写的就是自己接口的MAC地址，并且帧头的类型字段值是0x0800（指示上层协议是IP协议，也就是数据帧头内封装的是一个IP包），于是将数据帧头剥去，将里头的IP数据包交给IP协议去处理。
10. 而IP协议在处理的过程中发现，目的IP地址并非是本路由器上的IP，于是它也就知道了，这个数据包不是发给它自己的。R2就拿着这个目的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首先也是把010110的比特流还原成数据帧，然后做帧的完整性校验看看帧头是否损坏，如果没有，则继续查看数据帧的目的MAC，结果发现就是自己的网卡MAC，于是再查看帧的类型字段，发现是0x0800，知道这里头是IP包，于是将帧头剥去，将内层的IP数据包给上层的IP协议进行处理。IP收到这个数据包后，首先也是检验这个IP包头是否有损坏，如果没有，那再查看目的IP地址，发现目的IP正是自己网卡的IP 192.168.2.1。于是，它知道这个就是发送给自己的IP包，因此继续查看IP包头中的协议字段，发现协议字段填的是6这个值。哦，原来这个IP包头后面封装的是TCP的数据啊，因此将IP包头剥去，奖里面的TCP数据交给上层的TCP协议进行处理。而TCP在处理这个数据的时候，发现TCP头部中目的端口号是80，而Server本地的TCP80 端口号是开放的，并且是开放给HTTP应用了，接着它将TCP头部剥去，将里面的DATA给到了HTTP应用。好了，终于从PC发送出来的HTTP应用数据，到达了目的地-Server的HTTP应用手中。