看懂「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)

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