从输入URL到页面呈现知识点详解

• Expires是一个绝对时间，即服务器时间。浏览器检查当前时间，如果还没到失效时间就直接使用缓存文件。但是该方法存在一个问题：服务器时间与客户端时间可能不一致。因此该字段已经很少使用。

• cache-control中的max-age保存一个相对时间。例如Cache-Control: max-age = 484200，表示浏览器收到文件后，缓存在484200s内均有效。 如果同时存在cache-control和Expires，浏览器总是优先使用cache-control。

• Pragma

Pragma 是 HTTP/1.1 之前版本遗留的通用首部字段，仅作为 于HTTP/1.0 的向后兼容而使用。虽然它是一个通用首部，但是它在响应报文中时的行为没有规范，依赖于浏览器的实现。 RFC 中该字段只有 no-cache 一个可选值，会通知浏览器不直接使用缓存，要求向服务器发请求校验新鲜度。因为它优先级最高，当存在时一定不会命中强缓存。

如果响应报文首部的 expires 的时间大于请求的时间或者 max-age 不为0并且 cache-control 设置的值不为 no-cache 或者 no-store ，同时请求报文首部不存在 Pragma 字段的时候才会命中强缓存。

对比缓存

• last-modified 是第一次请求资源时，服务器返回的字段，表示最后一次更新的时间。下一次浏览器请求资源时就发送 if-modified-since 字段。服务器用本地 Last-modified 时间与 if-modified-since 时间比较，如果不一致则认为缓存已过期并返回新资源给浏览器；如果时间一致则发送 304 状态码，让浏览器继续使用缓存。
• Etag ：资源的实体标识（哈希字符串），当资源内容更新时， Etag 会改变。服务器会判断 Etag 是否发生变化，如果变化则返回新资源，否则返回304。

TCP三次握手

由上图我们可以清晰的看到 TCP 三次握手的详细过程。

• 首先是由客户端发送一个建立连接的请求， SYN 置为1(表示要建立连接)，生成一个随机数 seq=x ，进入 SYN_SEND 状态
• 服务端接收到请求，首选确认 ack=x+1 ，将 SYN 置为1， ACK 置为1，也生成一个随机数 seq=y ，进入 SYN_RECV ；
• 客户端收到请求后，发送确认包 ACK=y+1 ,服务器接收到确认包，连接建立成功，客户端和服务器进入 ESTABLISHED 状态。

服务器接收到客户端的 http 请求后会将该 http 请求封装成一个 Request 对象，并通过不同的 web 服务器处理，处理完结果以 Response 对象返回给客户端，主要内容为 状态码 、 请求头 、 响应报文 三个部分。

常见状态码

页面渲染

基本流程

• 解析 HTML 文件，生成 DOM 树
• 解析 CSS 文件，生成 CSS 树
• 合并 DOM 树和 CSS 树，生成渲染树
• 布局和绘制页面（回流，重绘）

浏览器解析 HTML 文件自上而下解析遇到 CSS 文件会阻塞页面渲染和 JS 文件的执行， CSS 文件不会阻塞 js 文件加载，他们是可以并行的，如果 js 文件具有 defer (IE)或者 async 属性时，该 js 文件加载完就立即执行，不会受到 css 加载的影响。

一旦页面 DOM 树生成接解析完毕就会触发 DOMContentLoaded （ PS:IE用onreadystatechange ），就可以通过 document.addListener('DOMContentLoaded',callback,false) 来进行绑定监听事件。

回流和重绘

概念

• 回流

Reflow ，又叫 layout ，一般意味着 DOM 元素内容、结构、位置或尺寸发生变化，需要重新计算样式和渲染树，这个过程叫做回流。

• 重绘

Repaint ，一般是因为元素一些外观上的改变（例如：背景色，边框颜色，字体颜色等），此时只要应用新样式绘制到元素上就行了，这个过程叫重绘。

所以回流比重绘的代价高的多得多，每个节点都有 reflow 方法，一个节点产生回流，可能会导致子元素产生回流，甚至会导致父节点或者兄弟节点产生回流。

触发回流的一些操作

• 删除、新增 DOM 节点会触发 Repaint 和 Reflow
• 操作节点位置改变或给节点添加一个动画
• 改变 CSS 一些样式（如：改变节点尺寸等）
• 窗口大小改变
• 修改网页默认字体
• 网页初始化的时候
• js 获取精确 CSS 样式的时候（如： getComputedStyle ， scroll 家族， offset 家族, client 家族等，使用这些方法将强制刷新队列)

会产生上面的问题的根源还是现代浏览器都比较聪明，他们通过队列化修改并批量执行来优化重排的过程，浏览器会将修改操作都放入一个队列当中，等到过了一段时间或者达到一个阈值才会清空队列。

那么我们为了减少回流优化页面性能又该采取什么样的措施呢？

• 在需要对一个节点采用数次操作时可以先将该元素 display:none ，修改完之后再让他显示，这样只会触发两次重排
• 需要使用js操作多个节点时可以借用 DocumentFragment 来进行批量操作后再插回页面
• 让需要被操作的节点先脱离标准文档流

  position:absolute(fixed)
  

• 使用 cssText 。将需要操作的样式一次性合并然后作用到元素上。

我们说了这么多的减少重绘、重排，好像还忘了一个神奇的东西。 bingo ，就是我们的 CSS3 GPU加速 啦！

CSS3 GPU加速

能触发GPU硬件加速的有如下几个属性：

transform
filter
opacity
Wall-change

他们的优点在于，在使用 transform filter opacity 属性实现动画时，不会触发重排和重绘;当然，在享受GPU硬件加速带来的好处的同时呢，我们也得考虑一个问题就是如果太多元素使用这个特性，将会出现内存内存占用过大，影响性能。

TCP四次挥手

FIN 代表断开连接标志位， ACK 确认标志位， seq 随机数，这里笔者就不多说了，类似于前面所述的三次握手

• 首先客户端向服务器端发送一个 FIN=1 + seq=u 标志位
• 服务端收到请求发送一个确认号 ACK=1 ，其中 ack=u+1 , seq=v
• 之后服务器再次向客户端发送一个 FIN=1 + seq=w + ACK=1 + ack=u+1
• 客户端收到后，向服务端发送一个 ACK=1 , ack=w+1 , seq=w+1

到这里一次完整的 TCP 四次挥手就完结了，大家看完这个可能会有疑问，为什么是四次挥手而不是三次，为什么 FIN 和 ACK 并不是一起发送的，那么这里笔者就得说道说道了。

因为刚开始是客户端主动请求断开连接，这仅仅表示客户端没有数据传给服务端了，并不代表服务端的数据也传输完了，发送一个 ACK 确认标志位只是告诉客户端我知道了。

等到服务端数据也传输完了，才会出现第三次握手，也就是服务端主动发送一个 FIN+ACK 给客户端，告诉客户端我的数据也发送完了，我们分手吧，然后客户端收到了，再告诉服务端我知道了。至此，分手完毕。

笔者一次性巴拉巴拉这么多，可能大家会有点不好消化，可是笔者的初衷还是希望能够遇到一个知识点就解决它并延申一些相关知识点，这样比零散的查找会好得多。