我们大多数人都在浏览 Web 时见过 HTTP 这个缩写——至少如果你曾经上过网的话。它代表超文本传输协议（Hypertext Transfer Protocol），是 1999 年制定的一项协议，用于规范你的浏览器与服务器之间的通信。换句话说，它是 Safari、Chrome、Mozilla 等浏览器用来下载和显示网页的规则。
自 HTTP/1.X 诞生以来，计算世界的变化有目共睹。例如，与 HTTP/1 集成时的计算机相比，今天的计算机拥有远为强大的硬件能力。这种演进的影响推动了对协议的更新，以满足现代浏览需求。
一个简要方案：SPDY 的提出
2009 年，Google 的两名工程师（Mike Belshe 和 Roberto Peon）决定用一个名为 SPDY 的研究项目来解决 HTTP/1.1 中的问题。该项目的目标是：
允许跨 TCP 连接的同时请求，即多路复用；允许浏览器对资源设置优先级，使显示网页所需的每个资源都能优先发送给服务器；压缩并最小化 HTTP 头；允许服务器在浏览器请求之前就将资源推送给浏览器。
鉴于 SPDY 项目并非要取代 HTTP，它被服务器和主流浏览器广泛采用。目前，Microsoft Edge、Firefox、Chrome 和 Opera 都能同时运行 SPDY 和 HTTP/2。不过，得益于一项名为 HTTP/2 的更新协议，这种支持将大幅减少。事实上，Google 正是弃用 SPDY 转向 HTTP/2 的厂商之一。那么，HTTP/2 究竟特别在哪里？
HTTP/2 的特性
二进制协议：通过将协议改为更易于解析的二进制协议，解决了 HTTP/1.X 中存在的延迟问题，并使用头部压缩来最小化开销。
帧与流（Frames and Streams）：HTTP/2 消息由一个或多个帧组成，如 HEADERS、DATA、RST_STREAM、SETTINGS、PRIORITY 等。每个请求被分配一个唯一的流 ID，然后被拆分为称为"帧"的数据二进制分块。若干帧的集合构成一条"流"，因此每个帧都必须带有流 ID 以标识其所属的流。RST_STREAM 是客户端用来中止某条流的特殊帧类型。相比 HTTP/1.X 中唯一能中止流的方式是关闭连接，这是一个巨大的飞跃。
多路复用（Multiplexing）：一旦 TCP 连接打开，流就可以同步发送，无需再建立其他连接。
服务器推送（Server Push）：在 HTTP/2 中，服务器可以预先判断客户端将请求什么，并在客户端请求之前就将这些资源推送给它。
请求优先级（Request Prioritization）：该特性允许客户端通过 HEADERS 帧中的优先级信息为某条流分配优先级；客户端还可在需要时通过发送 PRIORITY 帧来更新该信息。
HPACK 头部压缩：HTTP/2 利用了这样一个事实——当客户端与服务器反复通信时，头部中可能会发送冗余数据。头部使用霍夫曼编码（Huffman code）进行压缩，意味着服务器和客户端可以省略重复头部，并通过双方共同维护的头部表来引用它们。
HTTP/2 的好处
从上述 HTTP/2 的特性可以看出，它建立在 SPDY 的基础之上。结果令人惊艳！尤其是在使用 SSL/TLS 时，性能更快。值得期待的 HTTP/2 好处包括：
每服务器单一连接：HTTP/2 在服务器与浏览器之间仅使用单一连接，意味着建立连接所需的时间将减少。
HTTP/2 简化了 Web 应用：开发者可以松一口气了！不再有 HTTP/1.X 的"优化"让你头疼。
设计混合型网页：HTTP/2 配合包含 HTML、CSS、JavaScript、多媒体的网页。浏览器可以区分文件请求的展示。
安全性：HTTP/2 将鼓励更多人选择 TLS，因为它减少了与之相关的性能问题。
是否会被迫为 HTTP/2 改造你的网站
好在 HTTP/2 向后兼容 HTTP/1.X，因此一切应当像以前一样无缝运行。事实上，这一新协议对用户完全透明，但你被"逼上船"只是时间问题。
HTTP/2 + TLS
将 HTTP 与 TLS 结合即产生 HTTPS，无论你运行哪个版本的 HTTP，这都是一种更安全的协议。HTTPS 一直是可选的，但在全球安全威胁的水平下，它不再是可选项。难怪你未来几乎别无选择，只能将 HTTP/2 与 TLS 结合使用。这是因为主流浏览器共同决定将以这种方式工作。需要说明的是，HTTP/2 的规范允许你在明文 TCP 上运行它。尽管如此，门槛已被设得很高。例如，如果你要在 TLS 上运行 HTTP/2，则需要使用 TLS 1.2 或更高版本。一个合乎逻辑的问题是：为什么不直接强制要求 TLS + HTTP/2？反对者不多，但事情并非那么简单。以下是一些原因：
小型设备仍无法处理 TLS——当然，TLS 带来的 CPU 负载对这些设备来说过于沉重；证书往往有些昂贵；有些人不信任证书颁发机构的安全体系；有时需要拦截 HTTP 流量，特别是在缓存方面。
更快的 HTTP/2 性能指南
终止（Terminate）HTTP/2 和 TLS：所谓终止，是指让客户端先使用 HTTP/2 连接到代理服务器，再由代理连接到数据库服务器、应用服务器等其他服务器。代理服务器与这些服务器之间的连接可以运行任何协议，无论是 HTTP/1、FASTCGI、UWSGI 等。这意味着你必须采用包含云服务器、虚拟服务器或物理服务器的多服务器架构。它肯定比单服务器设计复杂一些，但也有一些值得期待的优势。一旦该服务器搭建完成，它将接管客户端通信的工作，并可用于静态文件缓存和负载均衡。这种设置的另一个好处是，替换应用服务器和其他必要服务器变得非常容易。
了解你对 HTTP/1.X 优化的使用：在跳入 HTTP/2 之前，建议你先评估为 HTTP/1.X 量身定制的代码库。需要留意的优化包括：
域名分片（Domain Sharding）：将资源拆分到多个域名以提升加载速度和搜索引擎可见性的过程。这种 HTTP/1.X 优化对你帮助不大，可取的做法是采用对 HTTP/2 友好的域名分片，仅服务于 HTTP/1.X 用户。
图片精灵（Image Sprites）：这组图片可以在单个文件中下载。将图片打包成精灵并不会带来显著收益，尤其是当你的图片很大时。你可以在单一 TCP 连接上并行加载多张图片。
合并代码文件：通常被分开处理的代码块将被合并为一个。这样，浏览器只需从集中文件中获取所需代码。
撤销或说修订 HTTP/1.X 实现可能有些棘手，但如果使用旧浏览器的用户会受到改动影响。一个可取的办法是采用混合方案。
尝试域名分片
你也可以采用一种在 HTTP/1 下有益但被 HTTP/2 忽略的域名分片版本。如何确保对 HTTP/2 友好的分片？有两种方法：确保分片资源的域名始终解析到相同的 IP 地址；使用对所有分片域名有效的通配符 SSL 证书——你也可以选用多域名证书作为替代。
何时切换
如果你是设计者或开发者，或许在想何时才是切换的恰当时机。最好的决定是：如果你对用户所使用的服务器没有完全控制权，那就等待你使用的服务器更新到新协议。许多公司已快速完成从旧协议到新版本的过渡，这一点相当好。许多主机商即使在共享主机环境中也提供 HTTP/2。你需要了解使用支持 HTTP/2 浏览器的访客数量。如果该数字在增长，那么采用 HTTP/2 是个好主意。不过，如果你今天正在构建一个全新网站，建议将 HTTP/2 优化纳入考量。
结论
HTTP/2 无疑是提升性能、同时确保向所有人交付所需安全级别的更好的协议。无论你是第一次尝试实施它，还是让 HTTP/2 跑起来，都应该相当轻松且有趣！