wsmwzms123 / blog Goto Github PK

最近在某些大厂官网上看网页结构的时候，发现了一个很有意思的地方，那就是dns-prefech。

虽然是老生常谈，但是对于某些用得频率不是很高的技术细节，我的印象往往都是模模糊糊的，为了加深巩固相关印象，特意在此著一篇小文。

首先放上一篇看过的写的还不错的技术文章，我的观点大都提炼于此

DNS Prefetching的两三事

那么DNS Prefetching 是什么 ：

• DNS 是什么-- Domain Name System，域名系统，作为域名和IP地址相互映射的一个分布式数据库。
• DNS 大家都懂，那么浏览器访问域名的时候，是需要去解析一次DNS，也就是把网址域名 pornhub 解析到对应的ip地址上。相信有些人也通过修改本机hosts来翻墙访问Google吧，这个就是主动的影响DNS解析
• 定义--浏览器根据自定义的规则，提前去解析后面可能用到的域名，来加速网站的访问速度。

使用 DNS Prefetching：

最简单的使用方法：

<link rel="dns-prefetch" href="[//host_name_to_prefetch.com](http://the_worlds_best_vendor.com/)">

需要注意的点：

• 标签默认加载：所有的a标签的href都会自动去启用DNS Prefetching，也就是说，你网页的a标签href带的域名，是不需要在head里面加上link手动设置的。

谷歌定义原文

DNS prefetching is an attempt to resolve domain names before a user tries to follow a link. This is done using the computer's normal DNS resolution mechanism; no connection to Google is used. Once a domain name has been resolved, if the user does navigate to that domain, there will be no effective delay due to DNS resolution time. The most obvious example where DNS prefetching can help is when a user is looking at a page with many links to various domains, such as a search results page. When we encounter hyperlinks in pages, we extract the domain name from each one and resolving each domain to an IP address. All this work is done in parallel with the user's reading of the page, using minimal CPU and network resources. When a user clicks on any of these pre-resolved names, they will on average save about 200 milliseconds in their navigation (assuming the user hadn't already visited the domain recently). More importantly than the average savings, users won't tend to experience the "worst case" delays for DNS resolution, which are regularly over 1 second.

• 针对上一点：a标签的默认启动在HTTPS不起作用。

The most obvious example where DNS prefetching can help is when a user is looking at a page with many links to various domains, such as a search results page.

我们如何解决呢

对于以上问题我们怎么解决呢--> 使用 meta里面http-equiv来强制启动功能

说到这里，我们来总结一下

1. DNS Prefetching是提前加载域名解析的，省去了解析时间。
2. a标签的href是可以在chrome。firefox包括高版本的IE，但是在HTTPS下面不起作用，需要meta来强制开启功能
3. 这是DNS的提前解析，并不是css，js之类的文件缓存，大家不要混淆了两个不同的概念。
4. 如果直接做了js的重定向，或者在服务端做了重定向，没有在link里面手动设置，是不起作用的。
5. 这个对于什么样的网站更有作用呢--- 类似taobao这种网站，你的网页引用了大量很多其他域名的资源，如果你的网站，基本所有的资源都在你本域名下，那么这个基本没有什么作用。因为DNS Chrome在访问你的网站就帮你缓存了。

深入Chrome实现底层

在Google的官方文档中，最后介绍到Chrome针对这个功能的各种优化。

浏览器实现方式

Chromium直接启动了8个完全异步的线程来做这个预解析，每个线程都处理一个队列，等待域名响应，最终操作系统会响应一个DNS解析给线程，然后线程剔除队列，开始下一个。因为有8个同时，基本上最多一两个会阻塞，其他都很快执行完。所以从上也可以看出直接修改本机的hosts会影响浏览器的解析。也算一种简单的翻墙方式。以下命令可以查看队列状态

about:histograms/DNS.PrefetchQueue

浏览器启动

Chrome浏览器启动的时候，就会自动的快速解析浏览器最近一次启动时记录的domin的前10个。所以一般说来你经常访问的网址打开的速度就比没有DNS解析得更快

Browser Startup

Chromium automatically remembers the first 10 domains that were resolved the last time the Chromium was started, and automatically starts to resolve these namesvery early in the startup process. As a result, the domains for a user's home page(s), along with any embedded domains (or anything the user "always" visits just after startup), are generally resolved before much of Chromium has ever loaded. When Chromium finally starts to try to load and render those pages, there is typically no DNS induced latency, and the application effectively "starts up" (becoming usable) faster. Average startup savings are 200ms or more, with common acceleration over 1 second.

功能的有效性

1. 如果本地就有缓存，那么解析大概是0~1ms,如果去路由器查找大概是15ms，如果当地的服务器，一些常见的域名可能需要150ms左右，那么不常见的可能要1S以上。
2. DNS解析的包很小，因为DNS是分层协议的，不需要跟http协议一样，一个UDP的包就ok，大概100bytes，快速。
3. 本机的DNS缓存是有限，例如XP大概50到200个域名，所以Chrome这里做了优化，会根据你的网站访问频率，来保证你常用的网站的DNS都能被缓存住。

大家可以记住以下两个命令在chrome的地址栏输入查看

about:histograms/DNS  
about:dns

浮动

在说浮动之前，先说几个前置概念

常规流 脱离常规流 包含块

常规流-normal flow

网页中的流就是对文档的读取和输出的顺序. 其遵循从左到右, 从上到下的读取, 输出和显示顺序.
通常的资料中,常常称之为文档流,但是标准中没有这种说法,只有normal flow一词,应称之为普通流,或常规流.
在普通流中, 元素按照其在HTML 中的先后位置至上而下布局, 在这个过程中, 行内元素水平排列, 直到当行被占满然后换行; 块级元素则会被渲染为完整的一个新行.
除非另外指定, 否则所有元素默认都是普通流定位, 也可以说, 普通流中元素的位置由该元素在HTML 文档中的位置决定.

脱离常规流

脱离常规流的元素会创建一个新的块级格式化上下文（Block Formatting Context: BFC）环境，其中包含的所有元素构成了一个小的布局环境，与页面中的其他内容分隔开来。而根元素，作为页面中所有内容的容器，自身脱离常规流，为整个文档创建了一个块级格式化上下文环境。

下列元素会脱离常规流：

• floated items。浮动的元素
• items with position: absolute (including position: fixed which acts in the same way)。通过设置position属性为absolute或者fixed的元素
• the root element (html)根元素

包含块

一个元素的尺寸和位置经常受其包含块(containing block)的影响。大多数情况下，包含块就是这个元素最近的祖先块元素的内容区，但也不是总是这样。

确定包含块儿

确定一个元素的包含块的过程完全依赖于这个元素的 position 属性：

1. 如果 position 属性为 static 、 relative 或 sticky，包含块可能由它的最近的祖先块元素（比如说inline-block, block 或 list-item元素）的内容区的边缘组成，也可能会建立格式化上下文(比如说 a table container, flex container, grid container, 或者是 the block container 自身)。
2. 如果 position 属性为 absolute ，包含块就是由它的最近的 position 的值不是 static （也就是值为fixed, absolute, relative 或 sticky）的祖先元素的内边距区的边缘组成。
3. 如果 position 属性是 fixed，在连续媒体的情况下(continuous media)包含块是 viewport ,在分页媒体(paged media)下的情况下包含块是分页区域(page area)。
4. 如果 position 属性是 absolute 或 fixed，包含块也可能是由满足以下条件的最近父级元素的内边距区的边缘组成的：

1. transform 或 perspective 的值不是 none
2. will-change 的值是 transform 或 perspective
3. filter 的值不是 none 或 will-change 的值是 filter(只在 Firefox 下生效).
4. contain 的值是 paint (例如: contain: paint;)

根据包含块计算百分值

如果某些属性被赋予一个百分值的话，它的计算值是由这个元素的包含块计算而来的。这些属性包括盒模型属性和偏移属性：

1. 要计算 height top 及 bottom 中的 百分值 ，是通过包含块的 height 的值。如果包含块的 height 值会根据它的内容变化，而且包含块的 position 属性的值被赋予 relative 或 static ，那么，这些值的计算值为 auto。
2. 要计算 width, left, right, padding, margin 这些属性由包含块的 width 属性的值来计算它的 百分值 。

浮动元素的摆放会遵循如下的规则：

• 尽量靠上
• 尽量靠左
• 尽量一个挨着一个
• 不能超出包含块，除非元素比包含块更宽
• 上边距不能超过它前面浮动元素的最高点
• 左边缘在同一水平线上不能超过它前面浮动元素的最左边

上面两点可以总结为只能进行下左方向的运动

• 不能超过所在行的最高点
• 行内元素绕着浮动元素摆放：

• 行内元素会出现在左浮动元素的右边一集右浮动元素的左边
• 左浮动元素的左边和右浮动元素的右边不能摆放行内元素

• 脱离文档流，也就是将元素从普通的布局排版中拿走，其他盒子在定位的时候，会当做脱离文档流的元素不存在而进行定位。需要注意的是，使用float脱离文档流时，其他盒子会无视这个元素，但其他盒子内的文本依然会为这个元素让出位置，环绕在周围。而对于使用absolute
  positioning脱离文档流的元素，其他盒子与其他盒子内的文本都会无视它。

浮动的清除：（只针对块元素，且清楚后margin不起效）

clear: none |left | right | both
块元素下移到某一变没有浮动元素为止