url从输入到返回请求的过程以及包含知识点扩展

问题： 从浏览器地址栏输入url到请求返回发生了什么？

1、url解析，根据dns系统进行ip查找

• url为什么要解析（编码）？

1、一般来说， url只能有字母和数字和某些标点符号组成，如果url中有汉字或者其他字符，需要编码后使用。
2、url里是通过key=value&key=value的方式进行传参的，如果value里面包含=和&符号容易出现歧义。
3、url的编码规则：
    1、网址路径的编码，用的是utf-8编码。
    2、IE实际上就是将查询字符串，以GB2312编码的格式发送出去。
    3、Get方法生成的URL包含汉字时，编码方法由网页的编码决定
    <meta http-equiv="Content-Type" content="text/html;charset=xxxx">
4、encodeURIComponent()与encodeURI()的区别：
    4.1、encodeURI()着眼于对整个URL进行编码，输出符号的utf-8形式
    4.2、encodeURIComponent用于对URL的组成部分进行个别编码，"; / ? : @ & = + $ , #"，这些在encodeURI()中不被编码的符号，在encodeURIComponent()中统统会被编码。

• dns解析流程

    1、 浏览器自身检查缓存中有没有这个域名的缓存ip，如果有，结束。
    2、如果浏览器缓存中没有命中，浏览器会检查自身操作系统缓存中有没有相应的已经解析的过程。
    3、如果没有命中，去查本地dns解析器有没有缓存。
    4、然后去找计算机配置的dns有误缓存
    5、如果还没有就去查根dns服务器

• html如何做dns优化

进行DNS预获取 。
<meta http-equiv="x-dns-prefetch-control" content="on" />
强制查找特定主机名
<link rel="dns-prefetch" href="http://bdimg.share.baidu.com" />

2、查找到ip后， 进行http协议的三次握手，建立链接

第一次握手： 主机A发送位码为SYN=1的TCP包给服务器，并且随机产生一个作为确认号，主机B收到SYN码后知道A要求建立链接；
第二次握手：主机B收到请求后，向A发送确认号（主机A的seq+1），syn = 1，seq = 随机数的tcp包；
第三次握手：主机A收到后检查确认号是否正确，及第一次A发送的确认号是否+1，以及位码ack是否为1，若正确，主机A会再次发送确认号（主机B的seq+1），ack=1， 主机B收到后确认seq值与ack=1，则建立链接。
完成三次握手客户端与服务器开始传输数据。

第三次握手不能省略，因为第二次握手后还不能确认主机A已经收到确认请求，这个时候如果主机B还是发送数据，A一直没有接受到，服务器很容易挂。

3、建立完链接，就该请求html文件，如果浏览器的缓存中有html文件，浏览器直接返回，如果没有，向后台请求html文件。

• 强缓存：不会向服务器发送请求直接从浏览器读取缓存，返回请求状态码为200。

强缓存在chrome控制台的network选项中可以看到size显示from disk cache或from memory cache。
from memory cache代表使用内存中的缓存，from disk cache则代表使用的是硬盘中的缓存，浏览器读取缓存的顺序为memory –> disk。
强缓存读取顺序：
1、先查找内存，如果内存中存在，从内存中加载；
2、如果内存中未查找到，选择硬盘获取，如果硬盘中有，从硬盘中加载；
3、如果硬盘中未查找到，那就进行网络请求；
4、加载到的资源缓存到硬盘和内存；

• 协商缓存：强缓存失效后，浏览器携带缓存标志向服务器发起请求，由服务器决定是否使用缓存。当协商缓存生效时,返回304和Not Modified。

1.首先在精确度上，Etag要优于Last-Modified，Last-Modified的时间单位是秒，如果某个文件在1秒内改变了多次，那么他们的Last-Modified其实并没有体现出来修改，但是Etag每次都会改变确保了精度；如果是负载均衡的服务器，各个服务器生成的Last-Modified也有可能不一致。
2.性能上，Etag要逊于Last-Modified，毕竟Last-Modified只需要记录时间，而Etag需要服务器通过算法来计算出一个hash值。
3.优先级上，服务器校验优先考虑Etag

4、html返回后解析html

• • 构建DOM树(DOM tree)：从上到下解析HTML文档生成DOM节点树（DOM tree），也叫内容树（content tree）；
• 构建CSSOM(CSS Object Model)树：加载解析样式生成CSSOM树；
• 结合DOM和CSSOM，生成一棵渲染树（包含每个节点的视觉信息）；
• 生成布局（layout），即将所有渲染树的所有节点进行平面合成；
• 绘制（painting）将布局绘制（paint）在屏幕上；

"生成布局"（flow）和"绘制"（paint）这两步，合称为"渲染"（render）。

重绘和重排

网页生成的时候，至少会渲染一次。用户访问的过程中，还会不断重新渲染。

导致网页重新渲染的情况：
    1、修改DOM
    2、修改样式表
    3、用户事件（比如鼠标悬停、页面滚动、输入框键入文字、改变窗口大小等等）
    
重新渲染，就需要重新生成布局和重新绘制。前者叫做"重排"（reflow），后者叫做"重绘"（repaint）。

"重绘不一定重排："比如改变某个元素的颜色只会触发重绘，不会触发重排，因为网页布局没有改变。
"重排一定重绘："改变一个网页元素的位置，就会同时触发"重排"和"重绘"，因为布局改变了。

"重排和重绘的不断触发，非常耗费资源，是网页性能底下的根本原因"

扩展：

1、提高网页性能

• 如果某个样式是通过重排得到的，最好缓存结果，避免下次用到又要重排。
• 不要一条一条改变样式，通过class或csstext属性，一次性的改变样式。
• 先将元素设为display: none（需要1次重排和重绘），然后对这个节点进行100次操作，最后再恢复显示（需要1次重排和重绘）。这样一来，你就用两次重新渲染，取代了可能高达100次的重新渲染。
• position属性为absolute或fixed的元素，重排的开销会比较小，因为不用考虑它对其他元素的影响。
• 只在必要的时候，才将元素的display属性为可见，因为不可见的元素不影响重排和重绘。另外，visibility : hidden的元素只对重绘有影响，不影响重排。
• DOM 的多个读操作（或多个写操作），应该放在一起。不要两个读操作之间，加入一个写操作。