Skip to content

Latest commit

 

History

History
155 lines (93 loc) · 14.4 KB

File metadata and controls

155 lines (93 loc) · 14.4 KB

HTTP/1.1

目录

  1. 前言
  2. 持久连接
  3. HTTP 管道
  4. 使用多个 TCP 连接
  5. 域名分区
  6. 度量和控制协议开销
  7. 连接和拼合
  8. 嵌入资源

前言

HTTP/1.1 引入了大量增强性能的重要特性,其中一些大家比较熟知的有:

  • 持久化连接以支持连接复用
  • 分块传输编码以支持流式响应
  • 请求管道以支持并行请求处理
  • 字节服务以支持基于范围的资源请求
  • 改进的更好的缓存机制

但是有些 HTTP/1.1 特性,比如请求管道,由于缺乏支持而流产,而其他协议限制,比如队首响应阻塞,则导致了更多问题。为此,Web 开发社区,创造和推行了很多自造的优化手段:域名分区、连接文件、拼合图标、嵌入代码,等等,不下十种。它们都是针对当前 HTTP/1.1 协议的局限性而采用的权宜之计。

持久连接

HTTP/1.1 的一个主要改进就是引入了持久 HTTP 连接。

每个 TCP 连接开始都有三次握手,要经历一次客户端与服务器间完整的往返。此后,会因为 HTTP 请求和响应的两次通信而至少引发另一次往返,最后,还要加上服务器处理时间,才能得到每次请求的总时间。

服务器处理时间无法预测,因为这个时间因资源和后端硬件而异。不过,这里的重点其实是由一个新 TCP 连接发送的 HTTP 请求所花的总时间,最少等于两次网络往返的时间:一次用于握手,一次用于请求和响应。这是所有非持久连接 HTTP 会话都要付出的固定时间成本。

实际上,这时候最简单的优化就是重用底层连接!添加对 HTTP 持久连接的支持,就可以避免第二次 TCP 连接时的三次握手、消除另一次 TCP 慢启动的往返,节约整整一次网络延迟。

HTTP/1.1 默认启用持久连接,如果只能使用 HTTP/1.0,则可以明确使用 Connection: Keep-Alive 首部声明使用持久连接。

HTTP 管道

持久 HTTP 可以让我们重用已有的连接来完成多次应用请求,但多次请求必须严格满足先进先出(FIFO)的队列顺序:发起请求,等待响应完成,再发送客户端队列中的下一个请求。HTTP 管道是一个很小但对上述工作流却非常重要的一次优化,管道可以让我们把 FIFO 队列从客户端(请求队列)迁移到服务器(响应队列)。

服务器处理完第一次请求之后,会发生一次完整的往返:先是响应回传,接着是第二次请求。在此期间,服务器空闲。如果服务器能在处理完第一次请求后,立即开始处理第二次请求呢?甚至,如果服务器可以并行或在多线程上或者多个工作进程,同时处理两个请求呢?

通过尽早分派请求,不被每次响应阻塞,可以再次消除额外的网络往返。这样,就从非持久连接状态下的每个请求两次往返,变成了整个请求队列只需要两次网络往返。

但是,HTTP/1.x 也有它的局限性,HTTP/1.x 只能严格串行的返回响应。特别是,HTTP/1.x 不允许一个连接上的多个响应数据交错到达(多路复用),因而一个响应必须完全返回后,下一个响应才会开始传输。

比如,服务器并行处理两个请求,一个是 HTML 请求,一个是 CSS 请求。服务器处理 HTML 请求比 CSS 请求耗时,即使 CSS 资源先准备就绪,服务器也会先发送 HTML 响应,然后再交互 CSS,这种情况通常被称为队首阻塞,并经常导致次优化交互:不能充分利用网络连接,造成服务器缓冲开销,最终导致无法预测的客户端延迟。假如第一个请求无限期挂起,或者要花很长时间才能处理完,怎么办呢?在 HTTP/1.1 中,所有后续的请求都将被阻塞,等待它完成。

实际中,由于不可能实现多路复用,HTTP 管道会导致 HTTP 服务器、代理和客户端出现很多微妙的、不见文档记载的问题:

  • 一个慢响应就会阻塞所有后续请求
  • 并行处理请求时,服务器必须缓冲管道中的响应,从而占用服务器资源,如果有个响应非常大,则很容易形成服务器的受攻击面
  • 响应失败可能终止 TCP 连接,从而强迫客户端重新发送对所有后续资源的请求,导致重复处理
  • 由于可能存在中间代理,因此检测管道兼容性,确保可靠性很重要
  • 如果中间代理不支持管道,那它可能会中断连接,也可能会把所有请求串行起来

由于存在这些以及其他类似的问题,而 HTTP/1.1 标准中也未对此作出说明,HTTP 管道技术的应用非常有限,虽然其优点毋庸置疑。今天,一些支持管道的浏览器,通常都将其作为一个高级配置选项,但大多数浏览器都会禁用它。换句话说,如果浏览器是 Web 应用的主要交互工具,那还是很难指望通过 HTTP 管道来提升性能。

使用多个 TCP 连接

由于 HTTP/1.x 不支持多路复用,浏览器可以不假思索的在客户端排队所有 HTTP 请求,然后通过一个持久连接,一个接一个的发送这些请求。然鹅,这种方式在实践中太慢。实际上,浏览器开发商没有别的办法,只能允许我们并行打开多个 TCP 会话。多少个?现实中,大多数现代浏览器,包括桌面和移动浏览器,都支持每个主机打开六个连接。

进一步讨论之前,有必要先想一想同时打开多个 TCP 连接意味着什么。当然,有正面的也有负面的。下面我们以每个主机打开最多六个独立连接为例:

  • 客户端可以并行分派最多六个请求
  • 服务端可以并行处理最多六个请求
  • 第一次往返可以发送的累积分组数量(TCP cwnd)增长为原来的六倍

在没有管道的情况下,最大的请求数与打开的连接数相同。相应的,TCP 拥塞窗口也要乘以打开的连接数量,从而允许客户端绕开由 TCP 慢启动规定的分组限制。这好像是一个方便的解决方案,我们再看看这样做的代价:

  • 更多的套接字会占用客户端、服务器以及代理的资源,包括内存缓冲区和 CPU 时钟周期
  • 并行 TCP 流之间竞争共享的带宽
  • 由于处理多个套接字,实现复杂性更高
  • 即使并行 TCP 流,应用的并行能力也受限制

实践中,CPU 和内存占用并非微不足道,由此会导致客户端和服务端的资源占用量上升、运维成本提高。类似的,由于客户端实现的复杂性提高,开发成本也会提高。最后,说到应用的并行性,这种方式提供的好处还是非常有限的。这不是一个长期的方案,了解这些之后,可以说今天之所以使用它,主要有三个原因:

  1. 作为绕过应用协议(HTTP)限制的一个权宜之计
  2. 作为绕过 TCP 中低起始阻塞窗口的一个权宜之计
  3. 作为让客户端绕过不能使用 TCP 窗口缩放的一个权宜之计

域名分区

根据 HTTP Archive 的统计,目前平均每个页面都包含 90 多个独立的资源,如果这些资源都来自同一个主机,那么仍然会导致明显的排队等待。既然每个主机最多 6 个 TCP 流,那么何必把自己只限制在一个主机上呢?我们不必只通过一个主机(例如 www.example.com)提供所有资源,而是可以手工将所有资源分散到多个子域名:{shard1.shardn}.example.com。由于主机名称不一样了,就可以突破浏览器的连接限制,实现更高的并行能力,域名分区使用的越多,并行能力就越强。

当然,天下没有免费的午餐,域名分区也不例外:每个新主机名都要求有一次额外的 DNS 查询,每多一个套接字就会多消耗两端的一些资源,而更糟糕的是,站点作者必须手工分离这些资源,并分别把它们托管到多个主机上。

实践中,域名分区经常会被滥用,导致几十个 TCP 流都得不到充分利用,其中很多永远也避免不了 TCP 慢启动,最坏的情况下还会降低性能。此外,如果使用的是 HTTPS,那么由于 TLS 握手导致额外的网络往返,会使上述代价更高。

域名分区是一种合理但又不完美的优化手段,所以实践中一定先从最小分区数目开始,然后逐个增加分区并度量分区后对应用的影响。

度量和控制协议开销

HTTP/1.0 增加了请求和响应首部,以便双方能够交换有关请求和响应的元信息。最终,HTTP/1.1 把这种格式变成了标准:客户端和服务端都可以轻松扩展首部,而且始终以纯文本形式发送,以保证与之前的 HTTP 保持兼容。

今天,每个浏览器发起的 HTTP 请求,都会携带额外 500-800 字节的 HTTP 元数据:用户代理字符串、很少改变的接收和传输首部、缓存指令,等等。有时候,500-800 字节都说少了,因为没有包含最大的一块:HTTP Cookie。现代应用经常通过 Cookie 进行会话管理,记录个性选项或者完成分析。综合到一起,所有这些未经压缩的 HTTP 元数据经常会给每个 HTTP 请求增加几千字节的协议开销。

连接和拼合

最快的请求是不用请求,减少请求次数总是最好的优化手段。可是,如果你无论如何也无法减少请求,那么对 HTTP/1.x 而言,可以考虑把多个资源捆绑打包到一块,通过一次网络请求获取:

  • 连接

    把多个 JavaScript 或 CSS 文件组合为一个文件。

  • 拼合

    把多张图片组合为一个更大的复合的图片。

对 JavaScript 和 CSS 来说,只要保持一定的顺序,就可以做到把多个文件连接起来而不影响代码的行为和执行。类似的,多张图片可以组合为一个 "图片精灵",然后使用 CSS 选择这张大图中的适当部分,显示在浏览器中。这两种技术都具备两方面的优点:

  • 减少协议开销

    通过把文件组合成一个资源,可以消除与文件相关的协议开销。如前所述,每个文件很容易招致 KB 级未压缩数据的开销。

  • 应用层管道

    说到传输的字节,这两种技术的效果都好像是启用了 HTTP 管道:来自多个响应的数据前后相继的连接在一起,消除了额外的网络延迟。实际上,就是把管道提高了一层,置入了应用中。

连接和拼合技术都属于以内容为中心的应用层优化,它们通过减少网络往返开销,可以获得明显的性能提升。可是,实现这些技术也要求额外的处理、部署和编码,因而也会给应用带来额外的复杂性。此外,把多个资源打包到一块,也可能给缓存带来负担,影响页面的执行速度。

要理解为什么这些技术会伤害性能,可以考虑一种并不少见的情况:一个包含十来个 JavaScript 和 CSS 文件的应用,在产品状态下把所有文件合并为一个 CSS 文件和一个 JavaScript 文件。

  • 相同类型的资源都位于一个 URL 下面
  • 资源包中可能包含当前页面不需要的内容
  • 对资源包中任何文件的更新,都要求重新下载整个资源包,导致较高的字节开销
  • JavaScript 和 CSS 只有在传输完成后才能被解析和执行,因而会拖慢应用的执行速度

实践中,大多数 Web 应用都不是只有一个页面,而是由多个视图构成,每个视图都有自己的资源,同时资源之间还有部分重叠:公用的 CSS、JavaScript 和图片。实际上,把所有资源都组合到一个文件经常会导致处理和加载不必要的字节。虽然可以把它看成一种预获取,但代价则是降低了初始启动的速度。

对很多应用来说,更新资源带来的问题更大,更新图片精灵或组合 JavaScript 文件中的某一处,可能就会导致重新传输几百 KB 数据。由于牺牲了模块化和缓存粒度,假如打包资源变动频率过高,特别是在资源包过大的情况下,很快就会得不偿失。

内存占用也会成为问题,对图片精灵来说,浏览器必须分析整个图片,即便实际上只显示其中的一小块,也要始终把整个图片都保存在内存中。浏览器是不会把不显示的部分从内存中剔除掉的!

最后,为什么执行速度还会受影响呢?我们知道,浏览器是以递增方式处理 HTML 的,而对于 JavaScript 和 CSS 的解析及执行,则要等到整个文件下载完毕。JavaScript 和 CSS 处理器都不允许递增式执行。

总之,连接和拼合是在 HTTP/1.x 协议限制的现实下可行的应用层优化。使用得当的话,这两种技术都可以带来明显的性能提升,代价则是增加应用的复杂度,以及导致缓存、更新、执行速度、甚至渲染页面的问题。应用这两种优化时,要注意度量结果。

嵌入资源

嵌入资源是另一种非常流行的优化方法,把资源嵌入文档可以减少请求的次数。比如,JavaScrpt 和 CSS 代码,通过适当的 script 和 style 块可以直接放在页面中,而图片甚至音频或 PDF 文件,都可以通过数据 URI 的方式嵌入页面中。

数据 URI 适合特别小的,理想情况下,最好是只用一次的资源。以嵌入方式放到页面中的资源,应该算是页面的一部分,不能被浏览器、CDN 或其他缓存代理作为单独的资源缓存。换句话说,如果在多个页面中都嵌入同样的资源,那么这个资源将会随着每个页面的加载而被加载,从而增大每个页面的总体大小。另外,如果嵌入资源被更新,那么所有以前出现过它的页面都将被宣告无效,而由客户端重新从服务器获取。

最后,虽然 CSS 和 JavaScript 等基于文本的资源很容易直接嵌入页面,也不会带来多余的开销,但非文本性资源则必须通过 base64 编码,而这会导致开销明显增大,编码后的资源大小比原大小增大 33%。

实践中,常见的一个经验规则是只考虑嵌入 1~2 KB 以下的资源,因为高于这个标准的资源经常会导致比它自身更高的 HTTP 开销。然而,如果嵌入的资源频繁更新,又会导致宿主文档的无效缓存率升高。如果你的应用要使用很小的、个别的文件,在考虑是否嵌入时,可以参照以下建议:

  1. 如果文件很小,而且只有个别页面使用,可以考虑嵌入
  2. 如果文件很小,但需要在多个页面中重用,应该考虑集中打包
  3. 如果小文件经常更新,就不要嵌入了
  4. 通过减少 HTTP cookie 的大小将协议开销最小化