商家产品展示网站源码,网站添加百度地图,如何快速学会做网站,做公司网站怎么做欢迎大家前往腾讯云 社区#xff0c;获取更多腾讯海量技术实践干货哦~ 本文由腾讯IVWEB团队发表于云 社区专栏 作者#xff1a;yangchunwen HTTP协议是前端性能乃至安全中一个非常重要的话题#xff0c;最近在看《web性能权威指南(High Performance Browser Networking)》获取更多腾讯海量技术实践干货哦~ 本文由腾讯IVWEB团队发表于云 社区专栏 作者yangchunwen HTTP协议是前端性能乃至安全中一个非常重要的话题最近在看《web性能权威指南(High Performance Browser Networking)》把其中关于HTTP部分的内容拿出来分享一下加了一点自己的想法当然没有《HTTP权威指南》讲得详细但对于理解我们平常做的事情很有启发。预计会有两三篇文章重点分别会涉及到HTTP 1.1、HTTPS、HTTP 2.0等内容本篇主要涉及HTTP 1.1及其应用。
HTTP的历史
HTTP 0.9
HTTP的第一个版本被官方称为HTTP0.9这是个只有一行的协议例如
GET /about/(超文本响应……)
(连接关闭……)
HTTP 0.9有几个要点
客户端/服务器、请求/响应协议ASCII 协议运行于TCP/IP链接之上设计用来传输超文本文档(HTML)服务器与客户端之间的连接在每次请求之后都会关闭
这个版本的HTTP主要用来传输文本并且没有共用TCP连接。
HTTP 1.0
一个典型的HTTP 1.0请求过程如下
GET /rfc/rfc1945.txt HTTP/1.0
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Accept: */* HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 01 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 1 May 1996 12:45:26 GMT Server: Apache 0.84(超文本响应……)
(连接关闭……)
相对前一个版本HTTP 1.0主要有以下几点变化
请求和相应可以由于多行首部字段构成响应对象前面添加了一个响应状态行响应对象不局限于超文本服务器与客户端之间的连接在每次请求之后都会关闭实现了Expires等传输内容的缓存控制内容编码Accept-Encoding、字符集Accept-Charset等协商内容的支持
这时候开始有了请求及返回首部的概念开始传输不限于文本其他二进制内容
HTTP 1.1
HTTP 1.1是当前大部分应用所使用的协议版本。相对前面的1.0版本HTTP 1.1语义格式基本保持不变但是它加入了很多重要的性能优化持久连接、分块编码传输、字节范围请求、增强的缓存机制、传输编码及请求管道。 实际上持久链接在后来被反向移植到了HTTP1.0上 HTTP 2.0
HTTP 2.0 的主要目标是改进传输性能,实现低延迟和高吞吐量。HTTP 2.0作了很多性能角度的优化另一方面HTTP的高层协议语义并不会因为这次版本升级而受影响。所有HTTP首部、值,以及它们的使用场景都不会变。现有的任何网站和应用,无需做任何修改都可以在 HTTP 2.0 上跑起来。换句话说, 等以后我们的服务器、客户端如浏览器都支持HTTP 2.0的时候我们不用为了利用 HTTP 2.0 的好处而修改标记作很多额外的编码却能享受到它带来的更低的延迟和更高的网络连接利用率交付 HTTP 2.0的内容将在下篇或下下篇放出本文不对其做过多润色 HTTP 1.1与前端性能
前面讲到HTTP 1.1这个版本引入了大量增强性能的重要特性其中包括
持久化连接以支持连接重用分块传输编码以支持流式响应请求管道以支持并行请求处理字节服务以支持基于范围的资源请求改进的更好的缓存机制
这里重点讲一下持久化、管道在前端性能优化中的一些应用
持久连接
所谓持久连接就是重用 TCP连接多个HTTP请求公用一个TCP连接。
HTTP 1.1 改变了 HTTP 协议的语义,默认使用持久连接。换句话说,除非明确告知(通过
Connection: close 首部),否则服务器默认会保持TCP连接打开。如果你使用的是 HTTP 1.1,从技术上说不需要
Connection: Keep-Alive 首部,但很多客户端还是选择加上它比如我们的浏览器在发起请求的时候一般会默认帮我们带上
Connection: Keep-Alive 首部。我们来看一下为什么持久连接对我们来说这么重要。
假设一个网页仅包含一个HTML文档及一个CSS样式文件服务器响应这两个文件的时间分别为40ms及20ms服务器和浏览者分别在哈尔滨和深圳两者之间单向光纤延迟为28ms(假设的理想状态实际会比这个要大)。
首先是获取HTML文档的请求过程 HTML下载完毕后TCP连接关闭。
其次发起CSS资源的请求再次经历一次TCP握手 可以看到两个HTTP请求都分别需要经历一次TCP的三次握手时间另外图中没有体现到的是每一次TCP请求都有可能会经历一次TCP慢启动 过程这是影响传播性能的一个不可忽视的重要因素。
假如我们底层的TCP连接得到重用这时候的情况会是这样子 很明显在获取CSS的请求中减少了一次握手往返。 一开始每个请求要用两个TCP连接总延迟为284ms。在使用持久连接后避免了一次握手往返,总延迟减少为228ms。这里面两次请求节省了56ms一个RTTRound-Trip Time的时间 上面的例子还只是只有一个HTML和一个CSS的简单假设情况而现实世界的web的HTTP请求数量比这个要多得多在启用持久连接的情况下N次请求节省的总延迟时间就是(N-1)×RTT。
现实情况中延迟更高、请求更多性能提升效果比这里还要高得多。事实上,网络延迟越高,请求越多,节省的时间就越多。实际应用中这个节省的总时间可按秒来算了。如果每一个HTTP都重启一个TCP连接可想而知要浪费多少时间
HTTP管道
持久 HTTP 可以让我们重用已有的连接来完成多次应用请求但多次请求必须严格满足先进先出(FIFOfirst in first out)的队列顺序发送请求,等待响应完成,再发送客户端队列中的下一个请求。
举一下上一节持久连接的那个例子首先服务器处理完第一次请求后会发生了一次完整的往返先是响应回传接着是第二次请求在第二次请求到达服务器之间的这段时间里服务器空闲。
如果服务器能在处理完第一次请求后,立即开始处理第二次请求呢甚至如果服务器可以并行处理两个请求呢?
这时候HTTP管道就派上用场了HTTP管道是一个很小但对上述工作流非常重要的一次优化。
有了HTTP管道我们的HTTP请求在一定程度上不用再一个一个地串行请求而是可以多个并行了看起来好像很理想 如上图HTML和CSS的请求同时到达服务器服务器同时处理然后返回。 这一次通过使用HTTP管道又减少了两次请求之间的一次往返,总延迟减少为 172 ms。从一开始没有持久连接、没有管道的284ms到优化后的172ms这40%的性能提升完全拜简单的协议优化所赐。 等一下刚刚那个例子好像哪里还不够好既然请求同时到达同时处理为什么后面要先返回HTML然后再返回CSS两者不能同时返回吗
理想很丰满现实却有点骨感这就是HTTP 1.1管道的一个很大的局限性HTTP请求无法很好地利用多路复用不允许一个连接上的多个响应数据交错返回(多路复用)。因而一个响应必须完全返回后下一个响应才会开始传输。
这个管道只是让我们把FIFO队列从客户端迁移到了服务器。也就是说请求可以同时到达服务器服务器也可以同时处理两个文件但是两个文件还是得按顺序返回给用户如下图 HTML和CSS请求同时到达但先处理的是HTML请求服务器并行处理两个请求其中处理 HTML 用时40ms处理CSS用时20msCSS请求先处理完成但被缓冲起来以等候HTML响应先发送发送完HTML响应后再发送服务器缓冲中的CSS响应
可以看到即使客户端同时发送了两个请求,而且CSS资源先准备就绪但是服务器也会先发送 HTML 响应然后再交付 CSS。 题外话 上面两节举的例子说到了HTML和CSS请求同时到达这是书中的例子实际上个人觉得这个例子举得不是很恰当。 实际的web中HTML及其包含的CSS一般不会同时到达服务器正常的瀑布图也不是这样的往往是要先获取HTML内容后浏览器才能发起其中的CSS等资源请求。我想作者只是为了阐述原理吧个人认为换成同一个HTML文档中CSS和JS可能更加恰当。 这个问题的原理在于TCP层面的“队首阻塞”感兴趣可以去复习下计算机网络的课程。其代价往往是不能充分利用网络连接造成服务器缓冲开销有可能导致客户端更大的延迟。更严重的时假如前面的请求无限期挂起或者要花很长时间才能处理完,所有后续的请求都将被阻塞,等待它完成。
所以在HTTP 1.1中管道技术的应用非常有限尽管其优点毋庸置疑。实际上一些支持管道的浏览器通常都将其作为一个高级配置选项但大多数浏览器都会禁用它。换句话说作为前端工程师开发的应用是面向普通浏览器应用的话还是不要过多的指望HTTP管道看来还是期待一下HTTP 2.0中对管道的优化吧。 不过实际上还是有很好地利用HTTP管道的一些应用例如在WWDC 2012上有苹果的工程师分享了一个针对HTTP优化取得巨大成效的案例通过使用HTTP的持久连接和管道重用iTunes中既有的TCP连接使得低网速用户的性能提升到原来的3倍 实际上假如你想充分利用管道的好处必须要保证下面这几点条件
HTTP客户端支持管道HTTP服务器支持管道应用可以处理中断的连接并恢复应用可以处理中断请求的幂等问题应用可以保护自身不受出问题的代理的影响
因为iTunes的服务器和客户端都受开发者控制的应用所以他们能满足以上的条件。这也许能给开发hybrid应用或者开发浏览器之外的web应用的前端工程师们一些启发如果你开发的网站面向的用户是使用五花八门的浏览器你可能就没辙了。
使用多个TCP连接
因为HTTP 1.1管道存在上面的缺点所以利用率不高。那么问题来了假设没有使用HTTP管道我们的所有HTTP请求都只能通过持久连接一个接一个地串行返回这得有多慢
实际上现阶段的浏览器厂商采取了另外的办法来解决HTTP 1.1管道的缺陷允许我们并行打开多个TCP会话。至于是多少个大家可能已经似曾相识4到8个不等。这就是前端工程师非常熟悉的
浏览器只允许从同一个服务器并行加载4到8个资源这一认识的真正来历。HTTP持久连接虽然帮我们解决了TCP连接复用的问题但是现阶段的HTTP管道却无法实现多个请求结果的交错返回所以浏览器只能开启多个TCP连接以达到并行地加载资源的目的。
只能说这是作为绕过应用协议HTTP限制的一个权宜之计。可以这样打一个比喻一个水管无法同时运输多种液体那就只能给每一种液体开通一条运输管了至于这个水管什么时候可以智能化到同时运输不同的液体又能保证各自完整不受干扰到达目的地并在目的地自行分类还是那一句期待HTTP 2.0吧。 这里的连接数为什么是4到8个是多方平衡的结果这个数字越大客户端和服务器的资源占用越多在高并发访问的服务器中因为TCP连接造成的系统开销不可忽视每个主机4到8个连接只不过是大家都觉得比较安全的一个数字。 域名分区
前面说到浏览器和服务器之间只能并发4到8个TCP连接也就是同时下载4到8个资源够吗
看看我们现在的大部分网站动不动就几十个JS、CSS一次六个会造成后面大量的资源排队等待另外只下载6个资源对带宽的利用率也是很低的。
打个比喻一个工厂装了100根水管每次却只能用其中6根接水既慢又浪费水管
所以我们前端性能优化中有一个最佳实践使用域名分区
对啊何必把自己只限制在一个主机上呢我们可以手工将所有资源分散到多个子域名由于主机名称不一样了就可以突破浏览器的连接限制实现更高的并行能力。
通过这种方式“欺骗”浏览器这样浏览器和服务器之间的并行传输数量就变多了。
域名分区使用得越多并行能力就越强
但是域名分区也是有代价的
实践中域名分区经常会被滥用。
例如假设你的应用面向的是2G网络的手机用户你分配了好几个域名同时加载十几二十多个CSS、JS这里的问题在于
每一个域名都会多出来的DNS查询开销这是额外的机器资源开销和额外的网络延时代价。2G网络的DNS查询可不像你公司的电脑一样相反可能是好几秒的延迟同时加载多个资源以2G网络那种小得可怜的带宽来看后果往往就是带宽被占满每一个资源都下载得很慢手机的耗电加快
所以在一些低带宽高延时的场景例如2G手机网络域名分区做过了的话不光不会带来前端性能的提升反而会变成性能杀手。
域名分区是一种合理但又不完美的优化手段最合适的办法就是从最小分区数目不分区开始然后逐个增加分区并度量分区后对应用的影响从而得到一个最优的域名数。
连接与拼合
我们前端性能优化中有这么一个所谓的最佳实践原则合并打包JS、CSS文件以及做CSS sprite。
现在我们应该知道为什么要这样做了实际上就是因为现在HTTP 1.1的管道太弱了这两种技术的效果就好像是隐式地启用了HTTP 管道来自多个响应的数据前后相继地连接在一起消除了额外的网络延迟。
实际上就是把管道提高了一层置入了应用中也许到了HTTP 2.0时代前端工程师就不用干这样的活了吧(HTTP 2.0的内容下篇讲)
当然连接拼合技术同样有代价的。
例如CSS sprite浏览器必须分析整个图片即便实际上只显示了其中的一小块也要始终把整个图片都保存在内存中。浏览器没有办法把不显示的部分从内存中剔除掉。再者既然JS、CSS合并了带来的一般就是体积的增大在带宽有限的环境下例如2G下载时间就变长一般导致的就是页面渲染时间延后等后果。因为JavaScript 和CSS 处理器都不允许递增式执行的对于JavaScript 和CSS 的解析及执行则要等到整个文件下载完毕。 打包文件到底多大合适呢可惜的是没有理想的大小。然而谷歌PageSpeed团队的测试表明30~50 KB压缩后是每个JavaScript 文件大小的合适范围既大到了能够减少小文件带来的网络延迟还能确保递增及分层式的执行。具体的结果可能会由于应用类型和脚本数量而有所不同。 资源内嵌
JavaScript 和CSS 代码 通过适当的script 和style 块可以直接放在页面中而图片甚至音频或PDF 文件都可以通过数据URIdata:[mediatype][;base64],data的方式嵌入到页面中。
上面的这种方式我们称为资源内嵌。
嵌入资源是另一种非常流行的优化方法 把资源嵌入文档可以减少请求的次数。尤其在2G网络等情况中内嵌资源可以有效地减少多次请求带来的时延。可以参考这篇文章在2G中的一些实践。
当然有缺点
内嵌方式的资源不能被浏览器、CDN 或其他缓存代理作为单独的资源缓存。如果在多个页面中都嵌入同样的资源那么这个资源将会随着每个页面的加载而被加载从而增大每个页面的总体大小。如果嵌入资源更新那么所有以前出现过它的页面都将被宣告无效而由客户端重新从服 务器获取。图片等非文本性资源通过base64 编码会导致开销明显增大编码后的资源大小比原大小增大33%
Google的砖家给出一些经验
只考虑嵌入1~2 KB 以下的资源因为小于这个标准的资源经常会导致比它自身更高的HTTP 开销如果文件很小而且只有个别页面使用可以考虑嵌入。理想情况下最好是只用一次的资源如果文件很小但需要在多个页面中重用应该考虑集中打包如果小文件经常需要更新就不要嵌入了通过减少 HTTP cookie 的大小将协议开销最小化
小结
本文介绍了HTTP 1.1在前端性能优化中的一些应用有些是为了绕过HTTP 1.1局限性的一些不得不做的事情比如资源合并、压缩、内嵌等这些都可以说是HTTP 2.0来临前的一些解决问题的“黑魔法”。
HTTP 1.1及其利用当然远远没有本文说得那么简单我只是浓缩了一部分内容有兴趣可以去研究《HTTP权威指南》。 问答 BDD框架的前端如何搭建 相关阅读 全面进阶 H5 直播上 NodeJs内存管理 WebGL 纹理颜色原理 【每日课程推荐】机器学习实战快速入门在线广告业务及CTR相应知识 此文已由作者授权腾讯云 社区发布更多原文请点击
搜索关注公众号「云加社区」第一时间获取技术干货关注后回复1024 送你一份技术课程大礼包
海量技术实践经验尽在云加社区
本文转载于:猿2048https://www.mk2048.com/blog/blog.php?idhkckhjtitle自从我这样撸代码以后公司网页的浏览量提高了107%
