HTTP/2基础教程(txt+pdf+epub+mobi电子书下载)


发布时间:2020-08-15 11:39:42

点击下载

作者:(美) 斯蒂芬·卢丁(Stephen Ludin),哈维尔·加尔萨(Javier Garza)

出版社:人民邮电出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

HTTP/2基础教程

HTTP/2基础教程试读:

前言

HTTP/2,简称 h2,是万维网(World Wide Web)所使用的 HTTP 网络协议的一个重大修订版本,其目的是提升加载 Web 内容时的感知性能。

自从 1999 年 HTTP/1.1(h1)通过以来,Web 发生了翻天覆地的变化。最早大小只有几千字节、包含资源只有个位数、主要基于文1本的网页,如今已发展为平均大小超过 2MB、包含资源数平均为 140 的富媒体网站。然而,用来传输 Web 内容的 HTTP 协议这些年并没有什么变化。于是一个新的工种出现了:Web 性能专家,他们精于发掘变通办法,在原有协议上提升网页加载速度。大家对性能的期望也改变了——在 20 世纪 90 年代后期,大家愿意为一个页面等上 7 秒,而技术和市场调研公司 Forrester Research 在 2009 年的一项研究中发现,在线购物者期望单个页面能在 2 秒内完成加载,其中很大一部分用户会放弃加载时间超过 3 秒的页面。近期 Google 的一项研究表明,甚至 400 毫秒(一眨眼的时间)的延迟,都可能降低人们的搜索意愿。

1 http://httparchive.org/trends.php?s=Top1000&minlabel=Oct+15+2015&maxlabel=Oct+1+2016

这就是 h2 诞生的原因——该协议可以更好地适应如今的复杂页面,同时又不牺牲速度。 HTTP/2 的应用在不断增多,因为越来越多的网站管理员意识到,他们可以借此花很小的成本来提高他们网站的感知性能。

我们每天都在使用 h2——它支撑了若干最流行的网站,如 Facebook、Twitter、Google 和 Wikipedia——但很多人并不了解它。我们的目标是讲解 h2 的原理及其性能优势,这样你就可以充分利用它。本书目标读者

不管你在工作中扮演什么角色,只要你的工作涉及网站生命周期的任意部分,本书就会对你有所帮助。本书的目标读者是网站开发和运维人员,以及那些正考虑要实现 h2 或者希望了解 h2 如何工作的人。

阅读本书要求你熟悉 Web 浏览器、Web 服务器、网站和 HTTP 协议的基础知识。本书涵盖范围

本书的目标是讲解 h2,并帮你充分利用新版的 HTTP 协议。本书不是一份针对所有 h2 客户端、服务器、调试工具、性能基准测试的全面指南。本书虽然是为不太熟悉 HTTP/2 的人而准备的,但专家没准儿也会觉得这是份称手的资源。推荐资源

你可以浏览本书在 O'Reilly 网站上的页面(http://shop.oreilly.com/product/0636920052326.do)获取更多信息。此外,我还推荐以下这些书。●《 高性能网站建设指南》,作者 Steve Souders,前端工程师的基

础知识。●《 高性能网站建设进阶指南》,作者 Steve Souders,Web 开发者

的性能最佳实践。2●《 Web 性能权威指南》,作者 Ilya Grigorik,快速上手指南,关

于各种网络、传输协议、应用协议,以及浏览器中可用的 API。●《 WebPageTest 应用指南》,作者 Rick Viscomi、Andy Davies 和

Marcel Duran,介绍 WebPagetest 的基础和高级应用,

WebPagetest 是一个用以优化网站的免费性能检测工具。3● High Performance Mobile Web,作者 Maximiliano Firtman,介绍

如何优化移动网站和移动应用性能。● http2 explained(https://daniel.haxx.se/http2/),作者 Daniel

Stenberg。

2 该书已由人民邮电出版社出版,书号:9787115349101。——编者注

3 该书中文版即将由人民邮电出版社出版,暂名《高性能移动 Web 开发》,参见 http://www.ituring.com.cn/book/1911。——编者注排版约定

本书使用了下列排版约定。 该图标表示提示或建议。 该图标表示一般注记。 该图标表示警告或警示。使用代码示例

补充材料(代码示例、练习等)可以从 https://github.com/oreillymedia/learning-http2 下载。

本书是要帮你完成工作的。一般来说,如果本书提供了示例代码,你可以把它用在你的程序或文档中。除非你使用了很大一部分代码,否则无需联系我们获得许可。比如,用本书的几个代码片段写一个程序就无需获得许可,销售或分发 O'Reilly 图书的示例光盘则需要获得许可;引用本书中的示例代码回答问题无需获得许可,将书中大量的代码放到你的产品文档中则需要获得许可。

我们很希望但并不强制要求你在引用本书内容时加上引用说明。引用说明一般包括书名、作者、出版社和 ISBN。比如:“Learning HTTP/2 by Stephen Ludin and Javier Garza (O'Reilly). Copyright 2017 Stephen Ludin and Javier Garza, 978-1-491-96244-2.”

如果你觉得自己对示例代码的用法超出了上述许可的范围,欢迎你通过 permissions@oreilly.com 与我们联系。O'Reilly Safari

Safari(前身为 Safari Books Online)是为企业、政府、教育机构和个人提供的会员制的培训和参考平台。

会员可以观看和收听来自 250 多家出版商的上千种图书、培训视频、学习路径、互动教程和推荐歌单。这些出版商包括 O'Reilly Media、Harvard Business Review、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Adobe、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology,等等。

欲知更多信息,请访问 https://www.safaribooksonline.com/。致谢

我们要感谢 Akamai 的 h2 核心团队和 Moritz Steiner(Akamai 的研究员,也是 Foundry 团队的一员,与 Stephen 共同撰写了几篇有关 h2 的论文);Pierre Lermant(感谢他的幽默和对细节的关注,也感谢他审阅本书并贡献了部分内容);Martin Flack(也是 Akamai Foundry 团队的一员,时常会提出颇具启发意义的 Lisp 实现);Jeff Zitomer(感谢他的支持、鼓励,以及富有感染力的微笑);Mark Nottinghan(感谢他对 h2 协议的贡献);Pat Meenan(感谢他为 Webpagetest.org 做出的数不清的贡献,这可能是测试 Web 性能最棒的免费工具了);Andy Davies(本书中广泛使用的工具 WebPagetest Bulk Tester 就是他开发的)。

感谢本书的编辑 Brian Anderson、Virginia Wilson 和 Dawn Schanafelt,有了他们,一切才变得简单。还要感谢为本书提供反馈和意见的每一位 h2 专家:Ilya Grigorik、Patrick McManus、Daniel Stenberg、Ragnar Lonn、Colin Bendell、Mark Nottingham、Hooman Beheshti、Rob Trace、Tim Kadlec 以及 Pat Meenan。Javier Garza

首先,我要感谢妻子 Tina 的支持、鼓励和理解。感谢我的孩子们(Keona、Diego 和 Lani),在我花费无数个夜晚和周末以及大段的暑假时间写作本书的时候,他们一如既往地爱着我。感谢我的经理 Aditi 和 Austin,在工作非常紧张的情况下,依然鼓励我写作本书。Stephen Ludin

我最想感谢的是身边人的耐心。我家人的耐心——感谢 Sarah、Tomas 和 Liam 容忍我以及令人抓狂的出版过程。在写作过程中,他们的支持是无价的。感谢我的雇主 Akamai 允许我在工作非常忙的时候写这本书。感谢 O'Reilly 工作人员的耐心,他们非常理解 O'Reilly 作者平日里的工作已经非常繁忙,只能利用零散的碎片时间来写作。最后,感谢我父母的耐心,他们的付出我无以为报,唯有珍惜当下——在我 9 岁的时候,父亲带回家一台 Atari 800,那时他是否知道,这使我从此走上了一条路,并且如今依然奋力前行。  第1章 HTTP 进化史

在 20 世纪 30 年代,美国 MIT 工程学院的电子工程师 Vannevar Bush 研究了人们生产的信息量和社会消化信息的能力之间的关系。在 1945 年发表于《大西洋月刊》的文章“As We May Think”中,他写道:从专业角度来看,我们传播和查阅研究结果的方法已经

过时,现在已经完全不能满足需要了。如果在写作和阅读学

术著作上花费的总时间可以被量化分析,那么两者的比例恐

怕非常惊人。

他设想了这样一个系统:聚合起来的知识存储在微缩胶卷上,可以极其方便快速地查阅。他进一步指出,这些信息应当有上下文关联性,就像人类大脑构建的知识链接那样。尽管他设想的 memex(扩展存储器)系统从未实现,其思想却影响了后来者。

如今人们所熟知的术语超文本于 1963 年左右被创造出来,于 1965 年首次出现在 Ted Nelson 发表的文章中。Nelson 是一位软件设计师,同时也极具前瞻眼光。他提出“超文本”一词的含义如下:大量的书面材料或图像材料以复杂的方式相互联系,因

此不便在纸介质上呈现或展示。其中可能包含内容摘要,或

者内容分布的脉络图以及各部分的内在联系;也可能包含审1

阅过其中内容的学者所添加的注释、补充或脚注。

1 T. H. Nelson. “Complex information processing: a file structure for the complex, the changing and the indeterminate.” ACM '65 Proceedings of the 1965 20th national conference.

Nelson 想要建立“文档库”,让信息之间互相关联,永不删除,并且方便所有人获取。20 世纪 70 年代,基于 Bush 的思想,Nelson 在他的 Xanadu 项目中实现了一个超文本系统的原型。很遗憾,该项目没有完成,但为后来者提供了基础。2

1989 年,HTTP的 Tim Berners-Lee 提出了一个新的系统 ,用以记录粒子加速器(指日后的大型强子对撞机)和 CERN 所做实验产生的信息。他采用了 Nelson 的两个概念:超文本,或者说“以一种无约束的方式联系起来的人类可读信息”;超媒体,表示“不限于文本”。在提案中,Tim 提出要搭建“通用系统”,它由服务器和众多机器上的浏览器组成。

2 https://www.w3.org/History/1989/proposal.html1.1 HTTP/0.9和HTTP/1.0

HTTP/0.9 是个相当简单的协议。它只有一个方法(GET),没有首部,其设计目标也无非是获取 HTML(也就是说没有图片,只有文本)。

经过随后几年的发展,HTTP 逐渐流行起来。截至 1995 年,世界上有超过 18 000 台服务器在 80 端口处理 HTTP 请求。此协议在 30.9 版本的基础之上有了长足的发展,并于 1996 年通过 RFC 1945 制定为 HTTP/1.0 规范。

3 https://tools.ietf.org/html/rfc1945

1.0 版本为原有的轻量协议新增了大量内容。0.9 版本的规范大概有 1 页,1.0 版本则有 60 页。所以,你可以说它从玩具成长为了工具。它包含了一些我们如今非常熟悉的概念:● 首部● 响应码● 重定向● 错误● 条件请求● 内容编码(压缩)● 更多的请求方法

    ……

尽管相对于 0.9 版本来说,HTTP/1.0 是一个巨大的飞跃,但仍存在很多瑕疵,尤其是不能让多个请求共用一个连接,缺少强制的 Host 首部,并且缓存的选择也相当简陋。这三点影响了 Web 可扩展的方式,因此应该在这里强调一下。1.2 HTTP/1.1

1.0 版本刚刚制定,1.1 版本就接踵而来。截至目前,1.1 版本的协议已经使用了 20 多年了。它修复了之前提到的 1.0 版本的大量问题。因为强制要求客户端提供 Host 首部,所以虚拟主机托管成为可能,也就是在一个 IP 上提供多个 Web 服务。当使用新的连接指令时, Web 服务器也不需要在每个响应之后关闭连接。这对于提升性能和效率而言意义重大,因为浏览器再也不用为每个请求重新发起 TCP 连接了。

添加的变更如下:● 缓存相关首部的扩展● OPTIONS 方法● Upgrade 首部● Range(范围)请求● 压缩和传输编码(transfer-encoding)● 管道化(pipelining) 管道化这种特性允许客户端一次发送所有的请求。但

是有些问题阻碍了管道化的普及,服务器仍然只能按顺序响

应请求。具体来说,如果某个请求花了很长时间,那么队头

阻塞(head of line blocking)会影响其他请求。另外,互联

网上的服务器和代理常常没有实现管道化特性(这很糟

糕),或者实现得有问题(这更糟糕)。

HTTP/1.1 要归功于 HTTP/1.0 的成功,以及该版本运行那几年所积累的经验。

HTTP/1.1 的RFC互联网工程任务组(IETF)发布的由委员会创建的草

案中的协议规范,叫作 RFC(Request for Comments,请求

注解)。委员会对所有人开放,前提是你有时间和意愿参与。

HTTP/1.1 最早在 RFC 2068 中定义,之后被 RFC 2616 取

代,最终在 RFC 7230 到 RFC 7235 中增补和修订。1.3 1.1版本之后

自 1999 年起,RFC 2616(HTTP/1.1 规范)定义了建立现代 Web 所依赖的标准。正式定稿之后,它就不再变化,也不再改进。然而,Web 和我们使用 Web 的方式一直在变,这种变化甚至超出了它的创造者的想象。普通商业网站的交互性和实用性,已经远远超出了当年互相联系的文档库的设想,并且从根本上改变了我们与世界交互的方式。虽然我们今天看到了协议的各种限制,但进化并没有因此停止。

我们能指出的最明显的变化是网页的构成。HTTP 档案库(HTTP Archives)最早的记录是 2010 年,尽管距今的时间相对较短,变化也足够让人震惊。HTTP 协议设计之初的考虑是单次请求获取单个对象,但如今,新加入的每种元素都增加了复杂度,也带来了压力。1.4 SPDY

2009 年,Google 的工程师 Mike Belshe 和 Roberto Peon 提出了4一种 HTTP 的替代方案: SPDY(发音同 speedy)。SPDY 不是第一个希望替代 HTTP 的方案,但它是其中最重要的一个,因为它带来了显而易见的性能提升。在 SPDY 之前,人们普遍认为在商业应用中没有必要对 HTTP/1.1 做出突破性的、不兼容的改变。要兼容浏览器、服务器、网络代理和其他各种各样的中间件,代价极其高昂。

4 http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1

然而,SPDY 改变了这一切。它很快证明了人们想要更高效的协议,并且愿意改变。SPDY 为 HTTP/2 奠定了基础,并证明了其中一些关键特性的合理性,如多路复用、帧和首部压缩等。即使在互联网时代,SPDY 的发展也算“快”的——它很快被整合进了 Chrome 和 Firefox,并最终几乎被所有主流浏览器所采有。而且几乎在同一时间,服务器和网络代理也对 SPDY 提供了必要的支持。1.5 HTTP/2

2012 年初,HTTP 工作组(IETF 工作组中负责 HTTP 规范的小5组)启动了开发下一个 HTTP 版本的工作。其纲领的关键部分 阐述了工作组对新协议的一些期望。

5 https://datatracker.ietf.org/wg/httpbis/charter/HTTP/2.0 被寄予了如下期望:● 相比于使用 TCP 的 HTTP/1.1,最终用户可感知的多数延迟都有能够量化的显著改善;● 解决 HTTP 中的队头阻塞问题;● 并行的实现机制不依赖与服务器建立多个连接,从而提升 TCP 连接的利用率,特别是在拥塞控制方面;● 保留 HTTP/1.1 的语义,可以利用已有的文档资源(如上所述),包括(但不限于)HTTP 方法、状态码、URI 和首部字段;● 明确定义 HTTP/2.0 和 HTTP/1.x 交互的方法,特别是通过中介时的方法(双向);● 明确指出它们可以被合理使用的新的扩展点和策略。

工作组发出了征求建议书的通知,并最终决定使用 SPDY 作为 HTTP/2.0 的起点。最终,RFC 7540 在 2015 年 5 月 14 日发布了,HTTP/2 成为正式协议。

下面,本书来为你讲完这个故事。  第2章 HTTP/2 快速入门

面对新事物时,我们一般不愿意先花费几小时仔细阅读操作手册、使用说明、维护指南、安全建议等。我们只想快速打开包装盒、接上电源、打开开关,然后就能安心享用。对 HTTP/2(h2)来说也是这样。

那么,现在就开始吧。2.1 启动并运行

其实,你很可能已经每天都在体验 HTTP/2 了。打开一个现代浏览器(比如 Edge、Safari、 Firefox 或 Chrome),访问某个常用网站,比如 Facebook、Instagram 或者 Twitter。瞧,你已经在使用 h2 了。老实说,这不怎么让人兴奋,也不是你阅读本书的原因。所以下面我们自己动手搭建一个 h2 服务器,嗯,下一个使用 h2 的大型网站可能就是你创建的。

要运行 h2 服务器,主要分两步:● 获取并安装一个支持 h2 的 Web 服务器;● 下载并安装一张 TLS 证书,让浏览器和服务器通过 h2 连接。

这两步都不简单,但我们会尽量做到简单。读完本章之后,你就可以跑自己的支持 h2 的服务器。7.4 节将针对这一主题做更详细的解释。2.2 获取证书

使用证书这个话题本身就可以写本书了。本章将跳过所有的理论部分,让你尽快拿到一张证书来做实验。接下来将探讨三种方法:使用在线资源;自己创建一张证书;从数字证书认证机构(CA)申请一张证书——我们将使用 Let's Encrypt。需要说明的是,前两个方法将创建一张所谓的自签名(self-signed)证书,它仅用于测试。由于自签名证书不是由 CA 签发的,浏览器会报警。2.2.1 使用在线证书生成器

有很多在线服务可以生成自签名的证书。因为你不会在自己的安全环境里生成私钥(private key),所以这些证书永远不能用于除了我们将要做的实验之外的任何情况。只需上网搜一搜,你就能找到很多这样的资源,比如 https://www.sslchecker.com/csr/self_signed。

使用这个工具,将生成的证书和密钥分别保存到两个本地文件中,并分别命名为 privkey.pem 和 cert.pem。2.2.2 自签名证书

openssl 工具是应用广泛且容易获得的,可以在 https://www.openssl.org 找到。几乎每个主流平台都有 openssl 的对应版本,我们将使用它演示如何生成自签名的证书和私钥。如果你有 Unix/Linux 或者 macOS 操作系统的设备,你可能已经有了这个工具。打开终端,输入以下命令:$ openssl genrsa -out key.pem 2048$ openssl req -new -x509 -sha256 -key privkey.pem -out cert.pem -days 365 \ -subj "/CN=fake.example.org"

这样你就有了新的私钥 privkey.pem 和新的证书 cert.pem。2.2.3 Let's Encrypt

Let's Encrypt 是 CA 领域的新玩家,在 2015 年秋天发布了它的 beta 版本。它的目标是让所有人都能容易、自动、免费地获得 TLS 证书。这是 TLS Everywhere(TLS 无处不在)行动的核心思想,简单来说,它的信念是所有的 Web 通信都应该经过加密和鉴权。在这里,我们看中的是“容易”的特性,所以可以立即动手。1

尽管还可以选择众多其他客户端和库 配合 Let's Encrypt,但电2子前哨基金会(EFF)还是推荐使用 Certbot 作为 Let's Encrypt 的客户端。Certbot 的目标是使证书的获取和维护变成完全不需要手动干预的过程,它提供从证书获取到证书安装再到 Web 服务器的一条龙服务。

1 https://community.letsencrypt.org/t/list-of-client-implementations/2103

2 https://certbot.eff.org/ 想要从 Let's Encrypt 获取一张证书,你可能需要验证

你的域名。这意味着你拥有这个域名,并且可以修改 DNS

或者 Web 服务器来证明。如果你手里没有域名,或者不想

这么麻烦,就使用之前所说的自签名的证书好了。

下载操作系统对应的 Cerbot 的说明在下面。本章是为了让大家尽可能容易地体验,所以你不需要关心选哪个 Web 服务器。对于 Linux 类的操作系统,通常最简单的方式是,在运行 Web 服务器的设备上执行下面的命令:$ wget https://dl.eff.org/certbot-auto$ chmod a+x certbot-auto

下载完成之后,像这样执行 certbot-auto:$ ./certbot-auto certonly --webroot -w -d

请把命令中的参数设置为你自己的 Web 服务器的文件目录和域名。上面的命令会自动安装所有用到的包,展示一些需要你输入的问题,最后如果都没问题的话,从 Let's Encrypt 获得证书。你新制作的证书和私钥会被放到 /etc/letsencrypt/live/:文件描述/etc/letsencrypt/live//你的证书的私钥privkey.pem/etc/letsencrypt/live//你的新证书cert.pem/etc/letsencrypt/live//Let's Encrypt 的 CA 证chain.pem书链/etc/letsencrypt/live//包含证书和证书链的fullchain.pem文件2.3 获取并运行你的第一个HTTP/2服务器

有很多能支持 HTTP/2 的服务器可供选择。(7.4 节会讲几个这样的服务器。)现在我们的目标是尽可能快和简单,因此我们将使用 3nghttp2 这个包。nghttp2 由 Tatsuhiro Tsujikawa 开发,提供了很多处理和调试 h2 的称手工具。不过现在,我们只关注 nghttpd 这个工具。

3 https://nghttp2.org/

关于 nghttp2,8.4 节会有更详细的介绍,但我们希望你现在就直接开始运行。所以,请使用你喜欢的包管理工具安装 nghttp2,或者从源码编译(如果你有勇气的话)。例如,在 Ubuntu 16 上面:$ sudo apt-get install nghttp2

安装之后,现在手上已经有了证书,启动 nghttpd 如下:$ ./nghttpd -v -d

其中 是你网站的路径, 是服务器要监听的端口号, 是你生成的私钥和证书路径。例如:$ ./nghttpd -v -d /usr/local/www 8443 \ /etc/letsencrypt/live/yoursite.com/privkey.pem \ /etc/letsencrypt/live/yoursite.com/cert.pem2.4 选择浏览器

最终,到了检验劳动成果的时候。启动一个现代浏览器,并用它访问你新安装的服务器。 7.1 节有支持 HTTP/2 的浏览器的完整列表。如果创建的是一张自签名的证书,你会看到安全警告。请确认浏览器提示的是你创建证书的问题,然后点击接受警告。现在你应该可以看到你的网站了。

这就是基于 h2 的服务!  第3章 Web 优化“黑魔法”的动机与方式

用相对古老的协议承载响应迅速的现代网页,实际上已经成了某种高超的杂技,并且以其为中心,已经发展出了一整套 Web 性能的技巧。也许有人会说,O'Reilly 举办的 Velocity 系列研讨会,部分缘于这些人的动机——他们希望分享自己的技巧和诀窍,从德高望重的协议上尽可能榨取收益。为了弄明白我们正走向何方(名义上,朝着 HTTP/2),搞清楚现在身处何处、面临什么挑战,以及当前我们如何应对这些问题,这些都是非常重要的。3.1 当前的性能挑战

发布现代 Web 页面或 Web 应用绝不是一件小事。每个页面会引用数百个对象,关联十多个域名,网络环境相差迥异,设备的处理能力也参差不齐。在这样的前提下,提供表现一致且响应迅速的 Web 体验并不简单。如果要保证用户在网站上的交互流畅,就必须重视理解客户端获取 Web 页面和渲染的步骤,以及各个步骤要面临的挑战。理解了它们,你就能理解推动 HTTP/2 的力量,也能理解其新特性相对 HTTP/1 都带来哪些益处。3.1.1 剖析Web页面请求

在进一步深入探讨之前,必须先搞清楚我们正在尽力优化的是什么;尤其要搞清楚的是,从用户在浏览器中点击链接到页面呈现在屏幕上,在此期间到底发生了什么?浏览器请求 Web 页面时,会执行重复流程,获取在屏幕上绘制页面需要的所有信息。为了更容易理解,我们把这一过程分成两部分:资源获取、页面解析 / 渲染。先从资源获取的部分开始。图 3-1 展示了它的步骤。图 3-1:资源请求 / 获取流程图

按流程图走一遍:

(1) 把待请求 URL 放入队列;

(2) 解析 URL 中域名的 IP 地址(A);

(3) 建立与目标主机的 TCP 连接(B);

(4) 如果是 HTTPS 请求,初始化并完成 TLS 握手(C);

(5) 向页面对应的 URL 发送请求。

图 3-2 展示了接收响应及页面渲染的过程。接着走这个流程:

(6) 接收响应;

(7) 如果(接收的)是主体 HTML,那么解析它,并针对页面中的资源触发优先获取机制(A);

(8) 如果页面上的关键资源已经接收到,就开始渲染页面(B);

(9) 接收其他资源,继续解析渲染,直到结束(C)。图 3-2:资源响应 / 页面渲染流程图

页面上的每一次点击,都需要重复执行前面那些流程,给网络带宽和设备资源带来压力。Web 性能优化的的核心,就是加快甚至干脆去掉其中的某些步骤。3.1.2 关键性能指标

从上面的图中,我们能找到影响 Web 性能的端点,以及能动手改进的地方。让我们从网络级别的性能指标开始,它会影响整个 Web 页面加载。

延迟

  延迟是指 IP 数据包从一个网络端点到另一个网络端点所花费的时间。与之相关的是往返时延(RTT),它是延迟的时间的两倍。延迟是制约 Web 性能的主要瓶颈,尤其对于 HTTP 这样的协议,因为其中包含大量往返于服务器的请求。

带宽

  只要带宽没有饱和,两个网络端点之间的连接会一次处理尽可能多的数据量。依据 Web 页面引用资源的大小和网络连接的传输能力,带宽可能会成为性能的瓶颈。

DNS 查询

  在客户端能够获取 Web 页面前,它需要通过域名系统(DNS)把主机名称转换成 IP 地址,DNS 相当于互联网上的电话号码簿(今天可能没有多少年轻人知道号码簿了)。获取的 HTML 页面中所引用的各个不同域名也需要转换;幸运的是,一个域名只需转换一次。

建立连接时间

  在客户端和服务器之间建立连接需要往返数据应答,称为“三次握手”。握手时间一般与客户端和服务器之间的延迟有关。握手过程包括客户端向服务器发起一个 SYN 包,接着服务器返回对应 SYN 的 ACK 响应以及新的 SYN 包,然后客户端返回对应的 ACK,如图 3-3 所示。图 3-3:TCP 三次握手

TLS 协商时间

  如果客户端发起 HTTPS 连接,它还需要进行传输层安全协议(TLS)协商;TLS 用来取代安全套接层(SSL)。除了服务器和客户端的计算处理耗时之外,TLS 还会造成额外的往返传输。

目前为止,客户端还没有真正发起 HTTP 请求,却已经用掉了 DNS 查询的往返时间,以及 TCP 和 TLS 的耗时。下面的指标严重依赖于页面内容本身或服务器性能,而不是网络。

首字节时间(TTFB)

  TTFB 是指客户端从开始定位到 Web 页面,至接收到主体页面响应的第一字节所耗费的时间。它包含了之前提到的各种耗时,还要加上服务器处理时间。对于主体页面上的资源,TTFB 测量的是从浏览器发起请求至收到其第一字节之间的耗时。

内容下载时间

  等同于被请求资源的最后字节到达时间(TTLB)。

开始渲染时间

  客户端的屏幕上什么时候开始显示内容?这个指标测量的是用户看到空白页面的时长。

文档加载完成时间(又叫页面加载时间)

  这是客户端浏览器认为页面加载完毕的时间。

如果我们关注 Web 性能,尤其是要制定新协议来提升效率,就必须把(上面提到的)那些指标牢记于心。后文讨论 HTTP/1.1 面临的问题以及我们想要寻求改变的原因时,还会提到它们。

把那些性能指标牢记于心之后,你就能看到互联网的发展趋势:各种东西都在增加,所以出现了性能瓶颈。下面是我们需要记住的一些增加的方面。

更多的字节

  毫无疑问的是,Web 页面引用的内容每年都在增长,图片越来越大,JavaScript 和 CSS 也越来越大。内容体量变大意味着(客户端需要)下载更多的字节,也意味着更长的页面加载时间。

更多的资源

  页面引用的资源不仅变大,而且数量也增多了。引用更多的资源会导致总耗时增加,因为所有的资源都需要获取并解析。

更高的复杂度

  随着我们添加更多、更丰富的功能,Web 页面和所依赖的资源正变得越来越复杂。复杂度提升,伴随而来的是计算渲染 Web 页面的时间不断延长,尤其是在处理能力较弱的移动设备上。

更多的域名

  Web 页面并不是从单一的域名拉取下来的,大多数 Web 页面会关联数十个域名。每出现一个新域名都会增加 DNS 查询耗时、建立连接耗时,以及 TLS 协商耗时。

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载