PC访问WEB服务器的数据通信过程

宏观通信过程

如上图的网络拓扑，我们来详细讲解下PC访问web server的数据通信过程，PC和server通信经过两台路由器R1和R2，那么PC的数据是如果经过路由器R1,R2到达server的呢？（在这里我们利用PC访问WEB服务器的通信过程重点讲解TCP/IP参考模型）整个的宏观通信过程如下图所示。

微观过程分析

下面我们来详细分析下（微观层面）

1. 终端PC用户在谷歌浏览器中输入URL，访问Server的WEB服务，PC用户的这次操作将触发HTTP应用为用户构造一个应用数据（如下图所示）。

这个数据最终要传递到Server并“递交”到Server的HTTP应用来处理，但是HTTP不关心数据怎么传、怎么寻址、怎么做差错校验等等，这些事情交由专门的层次来完成。

2. 大家都知道HTTP应用是基于TCP协议的，因此这个HTTP应用数据交由TCP/IP参考模型中传输层（第4层）进一步处理。

在该层，上层HTTP应用的数据被封装一个TCP的头部（可以简单的理解为套了一个TCP的信封），在TCP头部中我们重点关注两个字段（信封上写的东西），一个是源端口号，另一个是目的端口号，源端口号为随机产生的端口号（是PC本地设置的、专门用于本次会话的端口），目的端口号为80（HTTP服务对应的默认端口号是80），如下图所示。然后这个数据段（Segment）被交给下一个层处理。 

3. 下一层是网络层（第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的内容）。搞定之后，这个数据被交给下一层处理。

4. 为了让这个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）终于搞定了，如下图所示： 

5. 事实上在物理链路中传输的是比特（bit）流，最终这个以太网数据帧变成了一堆的10101001 从传输介质中传到了路由器R1上，如下图所示：

6. R1在收到一串的比特流01010后，先将他们还原成数据帧（如下图所示）。

之后会检查一下数据帧在传输过程中是否有损坏，如果没有损坏，那么就解析数据帧头部中的目的MAC地址，确认目的MAC地址是不是自己接口GE0/0/0的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. 接着由R1的数据链路层继续处理上层下来的IP包，它为这个IP包封装上一个新的以太网帧头，帧头中源MAC地址为R1的GE0/0/1口的MAC：0000-0000-0002，目的MAC是这个数据包即将交给的下一跳路由器192.168.12.2对应的MAC。

当然初始情况下R1是不知道这个MAC的，因此又是一轮ARP请求广播及回应过程并最终拿到这个MAC：0000-0000-0003，于是它将这个值填写在目的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首先将这些比特流还原成帧，然后做校验看看帧是否损坏，如果没有，则查看数据帧的目的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应用的手中。