输入一个url之后到底发生了什么 - Hurry

背景

最近学习到 nginx 方向代理发现，nginx 可以将你的请求以 http 块的 server 形式代理到请求的域名或者 ip 地址。

一个简单的 nigx 配置如下：

1 2 3 4 5 6 7 8

server { listen 80; root /usr/share/nginx/html; location / { proxy_pass http://www.example.com/link/; } }

这不由使我想到，如果在自己的服务器前加上了 nginx 反向代理，那以前学习的“输入一个 url 之后到底发生了什么“这里面就需要再加上一个 nginx 的反向代理步骤嘛，同时，如果在代理的服务器之前再加一层 nginx 反向代理以考虑前一个 nginx 负载均衡不够时，那就还需要增加一些解析的步骤。

下面还是来凭我自己的理解，记一下“输入一个 url 之后到底发生了什么”的步骤吧。

输入一个 url 之后到底发生了什么

域名解析

在输入一个 url 之后，第一步就是域名解析

• 先在浏览器中的历史记录中查 大专栏  输入一个url之后到底发生了什么 - Hurry找域名对应的 ip
• 如果没找到 ip，查找本地的 hosts 文件，是否有对应的 ip
• 再没找到的话，浏览器就会向 DNS 域名解析服务器查询对应的 ip，这其中涉及到 DNS 的递归解析，当前 DNS 服务器找不到则向更远的服务器查找。
• 浏览器拿到对应的 ip 之后，则向服务器发送请求。

服务器请求

• 浏览器向服务器请求，如果这之中有了一层 nginx 的反向代理，则回请求代理中的内容，如果代理的值为一个域名，则重复进行域名解析，直到获得 ip，如果值为 ip，则直接访问当前 ip。
• 浏览器开始向 ip 地址发送请求建立一个 http 连接了，然后会经过 tcp 的三次握手。
• 握手成功之后，成功建立连接。
• 服务器根据特定的请求返回响应内容。

浏览器解析HTML

• 浏览器获得服务器返回的 html 内容之后，开始解析 html。
• 浏览器构建 dom 树，异步解析css，同步解析 javascript。
• 最后构建的 dom 树和 cssom 树，经过重绘和重排，通过 GPU 渲染出相应的页面。

总结

深挖这个知识点，我们还可以学习到很多计算机操作系统，网络请求，服务器配置，运维网关，以及前后端相关的知识，这只是大概梳理了一下脉络，里面还有很多深入的东西没写，比如计算机底层的文件查询，cpu指令集的运行，内存的分配等等，以后会随着自己知识的完善不断修改补充，可能也有许多不对的地方，但“纸上得来终觉浅，绝知此事要躬行”这种精神还是要继续保持。