发展史 http0.9 –>http1.0 –>http1.1 –>http2.0
http请求和http响应
主要步骤包括:
请求 html 文件,及其编码、字符集和元数据
对原始 HTML 请求的分块响应
以 ASCII 十六进制数字表示的分块数据的字节数( 256 字节)
分块数据流响应结束
在同一个 TCP 连接上请求图标文件
通知服务器不再使用连接了
图标响应,随后关闭连接
啊,这一次可复杂多了。首先,最明显的差别是这里发送了两次对象请求,一次请求 HTML 页面,一次请求图片,这两次请求都是通过一个连接完成的。这个连接是持久的,因而可以重用 TCP 连接对同一主机发送多次请求,从而实现更快的用户体验。
为终止持久连接,客户端的第二次请求通过 Connection 首部,向服务器明确发送了关闭令牌。类似地,服务器也可以在响应完成后,通知客户端自己想要关闭当前TCP 连接。从技术角度讲,不发送这个令牌,任何一端也可以终止 TCP 连接。但为确保更好地重用连接,客户端和服务器都应该尽可能提供这个信息。
以上就是我们最熟悉的HTTP.1,HTTP 1.1 改变了 HTTP 协议的语义,默认使用持久连接。换句话说,除非明确告知(通过 Connection: close 首部),否则服务器默认会保持连接打开。
不过,这个功能也反向移植到了 HTTP 1.0,可以通过Connection: KeepAlive 首部来启用。实际上,如果你使用的是 HTTP 1.1,从技术上说不需要 Connection: Keep-Alive 首部,但很多客户端还是选择加上它。
优化方向
在了解更宏观的 web 性能优化之前,先看看下面这些优化方向:
浏览器解析和优化方向;
延迟和带宽对 Web 性能的影响;
传输协议( TCP)对 HTTP 的限制;
HTTP 协议自身的功能和缺陷;
浏览器解析过程
我们得先回顾一下浏览器架构,了解一下解析、布局和脚本如何相互配合在屏幕上绘制出像素来。
浏览器在解析 HTML 文档的基础上构建 DOM( Document Object Model,文档对象模型)。与此同时,还有一个常常被忽略的模型——CSSOM( CSS Object Model, CSS 对象模型),也会基于特定的样式表规则和资源构建而成。这两个模型共同创建“渲染树”,之后浏览器就有了足够的信息去进行布局,并在屏幕上绘
制图形。到目前为止,一切都很好理解。
然而,此时不得不提到我们最大的朋友和祸害: JavaScript。脚本执行过程中可能遇到一个同步的 document.write,从而阻塞 DOM 的解析和构建。类似地,脚本也可能查询任何对象的计算样式,从而阻塞 CSS 处理。结果, DOM 及 CSSOM的构建频繁地交织在一起: DOM 构建在 JavaScript 执行完毕前无法进行,而JavaScript 在 CSSOM 构建完成前也无法进行。
应用的性能,特别是首次加载时的“渲染前时间”,直接取决于标记、样式表和JavaScript 这三者之间的依赖关系。顺便说一句,还记得流行的“样式在上,脚本在下”的最佳实践吗?现在你该知道为什么了。渲染和脚本执行都会受样式表的阻塞,因此必须让 CSS 以最快的速度下载完。
与桌面应用相比, Web 应用不需要单独安装,只要输入 URL,按下回车键,就可以正常运行。可是,桌面应用只需要安装一次,而 Web 应用每次访问都需要走一遍“安装过程”——下载资源、构建 DOM 和 CSSOM、运行 JavaScript。正因为如此,Web 性能研究迅速发展,成为人们热议的话题也就不足为怪了。上百个资源、成兆
字节的数据、数十个不同的主机,所有这些都必须在短短几百 ms 内亲密接触一次,才能带来即刻呈现的 Web 体验。
速度、 性能与用户期望
现在,把 DNS 查询,随后的 TCP 握手,以及请求网页所需的几次往返时间都算上,光网络上的延迟就能轻易突破 100~1000 ms 的预算。难怪有那么多用户,特别是那些移动或无线用户,抱怨上网速度慢了!
分析资源瀑布
谈到 Web 性能,必然要谈资源瀑布。WebPageTest
HTTP 请求的构成( WebPageTest)
资源瀑布图记录的是 HTTP 请求,而连接视图展示了每个 TCP 连接(这里共 30个)的生命期,这些连接用于获取 Yahoo! 主页的资源。哪里比较突出呢?注意蓝色的下载时间,很短,在每个连接的总延迟里几乎微不足道。这里总共发生了 15次 DNS 查询, 30 次 TCP 握手,还有很多等待接收每个响应第一个字节的网络延迟(绿色)。
最早渲染时间、文档完成时间和最后资源获取时间,这三个时间说明我们讨论 Web性能时有三个不同测量指标。
Web 应用的执行主要涉及三个任务:取得资源、页面布局和渲染、 JavaScript 执行。
其中,渲染和脚本执行在一个线程上交错进行,不可能并发修改生成的 DOM。实际上,优化运行时的渲染和脚本执行是至关重要的,可是,就算优化了 JavaScript 执行和渲染管道,如果浏览器因网络阻塞而等待资源到来,那结果也好不到哪里去。对运行在浏览器中的应用来说,迅速而有效地获取网络资源是第一要义。
针对浏览器的优化建议
大多数浏览器都利用了如下四种技术。
资源预取和排定优先次序
文档、 CSS 和 JavaScript 解析器可以与网络协议层沟通,声明每种资源的优先级:初始渲染必需的阻塞资源具有最高优先级,而低优先级的请求可能会被临时保存在队列中。
DNS预解析
对可能的域名进行提前解析,避免将来 HTTP 请求时的 DNS 延迟。预解析可以通过学习导航历史、用户的鼠标悬停,或其他页面信号来触发。
TCP预连接
DNS 解析之后,浏览器可以根据预测的 HTTP 请求,推测性地打开 TCP 连接。如果猜对的话,则可以节省一次完整的往返( TCP 握手)时间。
页面预渲染
某些浏览器可以让我们提示下一个可能的目标,从而在隐藏的标签页中预先渲染整个页面。这样,当用户真的触发导航时,就能立即切换过来。
每个页面的结构和交付:
CSS 和 JavaScript 等重要资源应该尽早在文档中出现;
应该尽早交付 CSS,从而解除渲染阻塞并让 JavaScript 执行;
非关键性 JavaScript 应该推迟,以避免阻塞 DOM 和 CSSOM 构建;
HTML 文档由解析器递增解析,从而保证文档可以间隙性发送,以求得最佳性能。
除了优化页面结构,还可以在文档中嵌入提示,以触发浏览器为我们采用其他优化机制:
来源: http://www.2cto.com/kf/201608/540185.html