关于前端:从输入URL到渲染出页面

参考笔记：https://zhuanlan.zhihu.com/p/…

1. 输出地址

2. 浏览器查找域名的 ip 地址

一图知 DNS：

1. 查看本地硬盘中的 hosts 文件，看看有没有和这个域名对应的规定。有的话用本地 hosts 文件（实习的时候有遇到测试环境跟开发环境应用 switchhosts 配置不同的 host 的用法）
2. 本地无，浏览器发送 DNS 申请给本地 DNS 服务器，本地的个别是网络接服务器商提供
3. 本地服务器首先查问它的缓存记录，若缓存中有这条记录，能够间接返回后果。（递归查问），如果没有，则向 DNS 跟服务器进行查问
4. 以 www.baidu.com. 为例，若根服务器. 上没有具体对应关系，则通知本地 DNS 服务武器，去域服务器.com 上进行查问，并给出域服务器地址，而后本地 DNS 对.com 发动申请，如果域服务器上.com 也没有，则通知本地 DNS 服务器，去下二级域服务器.baidu.com 上查找。（迭代过程），最初 DNS 域名夫区其向域名的解析服务器发动请 i 去，这是就能收到一个域名和 IP 地址的对应关系，本地 DNS 服务器不仅能将 IP 地址返回给用户电脑，还能将对应关系保留在本地 DNS 缓存中，下次查问，可间接返回后果，放慢网络拜访。
   PS: www.baidu.com. . 是根服务器，com 是一级域服务器，而后 baidu.com 是二级域服务器

3. 浏览器向 web 服务器发动 HTTP 申请

拿到域名对应 ip 地址后，浏览器以一个随机端口（1024< 端口 <65535）向服务器的 web 程序（罕用 httpd,nginx)的 80 端口发动 TCP 申请，这个连贯申请达到服务器端后（这两头通过各种路由设施，局域网内除外），进入到网卡，而后是进入到内核的 TCP/IP 协定栈（用于辨认该连贯申请，解封包，一层一层的剥开），还有可能要通过 Netfilter 防火墙（属于内核的模块）的过滤，最终达到 WEB 程序，最终建设了 TCP/IP 的连贯。建设了 TCP 连贯之后，发动一个 http 申请。一个典型的 http request header 个别须要包含申请的办法，例如 GET 或者 POST 等，不罕用的还有 PUT 和 DELETE、HEAD、OPTION 以及 TRACE 办法，个别的浏览器只能发动 GET 或者 POST 申请。客户端向服务器发动 http 申请的时候，会有一些申请信息，申请信息蕴含三个局部：

申请办法 URI 协定 / 版本
申请头 (Request Header)
申请注释
TCP 连贯图示：

TCP 断开连接图示

4. 服务器的永恒重定向响应

服务器给浏览器响应一个 301 永恒重定向响应，这样浏览器就会拜访 http://www.baidu.com/ 而非 http://baidu.com/。

5. 浏览器跟踪重定向地址

当初浏览器晓得了 http://www.baidu.com/ 才是要拜访的正确地址，所以它会发送另一个 http 申请。

6. 服务器解决申请

通过后面的重重步骤，咱们终于将咱们的 http 申请发送到了服务器这里，其实后面的重定向曾经是达到服务器了，那么，服务器是如何解决咱们的申请的呢？
后端从在固定的端口接管到 TCP 报文开始，它会对 TCP 连贯进行解决，对 HTTP 协定进行解析，并依照报文格式进一步封装成 HTTP Request 对象，供下层应用。
一些大一点的网站会将你的申请到反向代理服务器中，因为当网站访问量十分大，网站越来越慢，一台服务器曾经不够用了。于是将同一个利用部署在多台服务器上，将大量用户的申请调配给多台机器解决。

此时，客户端不是间接通过 HTTP 协定拜访某网站应用服务器，而是先申请到 Nginx，Nginx 再申请应用服务器，而后将后果返回给客户端，这里 Nginx 的作用是反向代理服务器。同时也带来了一个益处，其中一台服务器万一挂了，只有还有其余服务器失常运行，就不会影响用户应用。

7. 服务器返回一个 HTTP 响应

通过后面的 6 个步骤，服务器收到了咱们的申请，也解决咱们的申请，到这一步，它会把它的处理结果返回，也就是返回一个 HTPP 响应。

HTTP 响应与 HTTP 申请类似，HTTP 响应也由 3 个局部形成，别离是：

• 状态行
• 响应头(Response Header)
• 响应注释

8. 浏览器显示 HTML

在浏览器没有残缺承受全副 HTML 文档时，它就曾经开始显示这个页面了，浏览器是如何把页面出现在屏幕上的呢?

解析 html 以构建 dom 树 -> 构建 render 树 -> 布局 render 树 -> 绘制 render 树

浏览器在解析 html 文件时，会”自上而下“加载，并在加载过程中进行解析渲染。在解析过程中，如果遇到申请内部资源时，如图片、外链的 CSS、iconfont 等，申请过程是异步的，并不会影响 html 文档进行加载。

解析过程中，浏览器首先会解析 HTML 文件构建 DOM 树，而后解析 CSS 文件构建渲染树，等到渲染树构建实现后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，波及到两个概念: reflow(回流)和 repain(重绘)。

DOM 节点中的各个元素都是以盒模型的模式存在，这些都须要浏览器去计算其地位和大小等，这个过程称为 relow; 当盒模型的地位, 大小以及其余属性，如色彩, 字体, 等确定下来之后，浏览器便开始绘制内容，这个过程称为 repain。

页面在首次加载时必然会经验 reflow 和 repain。reflow 和 repain 过程是十分耗费性能的，尤其是在挪动设施上，它会毁坏用户体验，有时会造成页面卡顿。所以咱们应该尽可能少的缩小 reflow 和 repain。

当文档加载过程中遇到 js 文件，html 文档会挂起渲染（加载解析渲染同步）的线程，不仅要期待文档中 js 文件加载结束，还要期待解析执行结束，才能够复原 html 文档的渲染线程。因为 JS 有可能会批改 DOM，最为经典的 document.write，这意味着，在 JS 执行实现前，后续所有资源的下载可能是没有必要的，这是 js 阻塞后续资源下载的根本原因。所以我明平时的代码中，js 是放在 html 文档开端的。

JS 的解析是由浏览器中的 JS 解析引擎实现的，比方谷歌的是 V8。JS 是单线程运行，也就是说，在同一个工夫内只能做一件事，所有的工作都须要排队，前一个工作完结，后一个工作能力开始。然而又存在某些工作比拟耗时，如 IO 读写等，所以须要一种机制能够先执行排在前面的工作，这就是：同步工作 (synchronous) 和异步工作(asynchronous)。

JS 的执行机制就可以看做是一个主线程加上一个工作队列(task queue)。同步工作就是放在主线程上执行的工作，异步工作是放在工作队列中的工作。所有的同步工作在主线程上执行，造成一个执行栈; 异步工作有了运行后果就会在工作队列中搁置一个事件；脚本运行时先顺次运行执行栈，而后会从工作队列里提取事件，运行工作队列中的工作，这个过程是一直反复的，所以又叫做事件循环(Event loop)。

9. 浏览器发送申请获取嵌入在 HTML 中的资源（如图片、音频、视频、CSS、JS 等等）

其实这个步骤能够并列在步骤 8 中，在浏览器显示 HTML 时，它会留神到须要获取其余地址内容的标签。这时，浏览器会发送一个获取申请来从新取得这些文件。比方我要获取外图片，CSS，JS 文件等，相似于上面的链接：

图片：http://static.ak.fbcdn.net/rs… CSS 式样表：http://static.ak.fbcdn.net/rs… JavaScript 文件：http://static.ak.fbcdn.net/rs…
这些地址都要经验一个和 HTML 读取相似的过程。所以浏览器会在 DNS 中查找这些域名，发送申请，重定向等等…

不像动静页面，动态文件会容许浏览器对其进行缓存。有的文件可能会不须要与服务器通信，而从缓存中间接读取，或者能够放到 CDN 中