看懂「www.google.com」背后的逻辑

在前两篇文章中，我们完整的描述了计算机网络 OSI 五层模型的相关内容。那么，本篇将会从一个实践案例开始，带你从整体上重新认识我们的计算机网络。

我们以访问 Google 为例，当我们在浏览器地址栏中敲下回车键之后，整个计算机网络将会发生什么呢？

本机的网络相关参数如下：

首先我们应用层的浏览器决定向 DNS 服务器请求解析域名「www.google.com」，那么就要遵循 DNS 协议。

DNS 运行在 53 号端口，于是浏览器会创建一个 UDP 套接字，标识该套接字的二元组分别是『目的 IP 地址』和『目的端口』。而套接字本质上就是为了唯一标识应用层进程，就是为了让响应报文能够找到目的地。

那么这里会创建一个 UDP 套接字，二元组为「本机 IP 地址 192.168.43.138」和「随机产生一个未使用的端口号」。

接着，浏览器将 DNS 请求报文封装好推入套接字，开始我们的 DNS 解析过程。

有关 DNS 的相关细节，这里不再赘述了，可以参考前面的文章，拿到 DNS 服务器的响应报文，运输层拆开数据报，得到该报文的目的 IP 地址和目的端口号，于是对应着去找套接字交付报文即可。

最终我们会从『本地 DNS 服务器』得到 Google 的 IP 地址为：172.194.72.105。

整个 HTTP 请求可以说才刚刚开始：

应用层

浏览器封装 HTTP 请求报文，然后创建一个 TCP 套接字，采用四元组标识，具体为「源 IP 地址：192.168.43.138」+「源端口号：随机的，这里假设为 1234」+「目的 IP 地址：172.194.72.105」+「目的端口号：80」。

HTTP 报文也就是我们的应用层数据报，大致是这样的：

指定了一些请求参数与动作，以及一些要求响应报文的返回格式要求，具体的我们不细说了。

紧接着，这个报文会被推进 TCP 套接字中，等待运输层来收取。

运输层

运输层收取了报文，并判断与目的主机是否建立了 TCP 连接，这里假设没有。

那么，运输层将不急着发送应用层数据，得先判断与目的主机之间能够正常通讯，也就是需要『握手』打招呼。

『三次握手』的相关细节，我们这里也不再赘述了，上篇文章描述的很详细了，通过『三次握手』，发送端和接收端确认过发送与确认序号，分配了相应的缓存资源等。

一切准备就绪之后，运输层将应用层发过来的数据报又一层封装，添加进『源端口号』和『目的端口号』以及相关差错检验字段。

最后将 TCP 数据报向下传递到网络层。

网络层

网络层其实很简单，拿到数据报并封装成 IP 数据报，即在原 TCP 报文的前提之上添加『源 IP 地址』和『目的 IP 地址』等字段信息。

然后交由数据链路层。

链路层

数据链路层拿到 IP 数据报，它需要封装成以太网帧才能在网络中传输，也就是它需要目的主机的 Mac 地址，然而我们只知道目的主机的 IP 地址。

所以，链路层有一个 ARP 协议，直接或间接的能够根据目的 IP 地址获得使用该 IP 地址的主机 Mac 地址。

当然，ARP 协议运行的前提是，目的 IP 地址和当前发送方主机处于同一子网络中。如果不然，发送方将目的 Mac 地址填自己网关路由的 Mac 地址，然后通过物理层发送出去。

网关路由由于具有转发表和路由选择算法，所以它知道目的网络该怎么到达，所以一路转发，最终会发送到目的网络的网关路由上。

最后，目的网络的网关路由同样会经由 ARP 协议，取得目的主机的 Mac 地址，然后广播发送，最后被目的主机接受。

这样谷歌的服务器就接受到一个 HTTP 请求，于是它解析这个请求，确定该请求的动作是什么，也就是它需要什么东西，并构建响应报文，以同样的方式从网络到达源主机。

最后你将看到你想要的谷歌搜索页面：

整体上我们自顶而下的描述了一个请求到达目的地的完整过程，旨在宏观上建立完整的框架体系，相关细节之处可以参照前两篇文章。

---

文章中的所有代码、图片、文件都云存储在我的 GitHub 上：

(https://github.com/SingleYam/overview_java)

欢迎关注微信公众号：扑在代码上的高尔基，所有文章都将同步在公众号上。