HTTP/2（超文本传输协议第2版，最初命名为HTTP 2.0），简称为h2（基于TLS/1.2或以上版本的加密连接）或h2c（非加密连接），是HTTP協議的的第二个主要版本，使用於全球資訊網。

HTTP/2是HTTP協議自1999年HTTP 1.1的改进版RFC 2616发布后的首个更新，主要基於SPDY協定。它由互联网工程任务组（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小组进行开发。该组织于2014年12月将HTTP/2标准提议递交至进行讨论，于2015年2月17日被批准。 

HTTP/2标准于2015年5月以RFC 7540正式发表。HTTP/2的标准化工作由Chrome、Opera、Firefox、Internet Explorer 11、Safari、及Edge等浏览器提供支持。 

多数主流浏览器已经在2015年底支持了该协议。此外，根据W3Techs的数据，截至2021年10月，全球有46.5%的网站支持了HTTP/2。

协议的制定 
协议制定伊始，工作组章程关注了下列目标和受关心的问题：
 建立一个协商协议标准，即应用层协议协商（ALPN），以便客户端能够从HTTP/1.0、HTTP/1.1、HTTP/2乃至其他非HTTP协议中做出选择。
 与HTTP/1.1在请求方法、状态码乃至URI和绝大多数HTTP头部字段等方面保持高度兼容性。
 通过以下举措，减少网络延迟，提高浏览器的页面加载速度：
 对HTTP头字段进行数据压缩（即HPACK算法）；
 HTTP/2服务端推送（Server Push）；
 请求管線化；
 修复HTTP/1.0版本以来未修复的队头阻塞问题；
 对数据传输采用多路复用，让多个请求合并在同一TCP连接内。
 支持现有的HTTP应用场景，包括桌面和移动设备浏览器、网络API、不同规格的网络服务器和正向代理、反向代理服务器软件、防火墙和CDN等。

Facebook对各方案进行了评价并最终推荐了SPDY协议。HTTP 2.0的首个草稿于2012年11月发布，其内容基本和SPDY协议相同。

协议之间的的比较

HTTP/2与HTTP/1.1比较
HTTP/2相比HTTP/1.1的修改并不会破坏现有程序的工作，但是新的程序可以藉由新特性得到更好的速度。

HTTP/2保留了HTTP/1.1的大部分语义，例如请求方法、状态码乃至URI和绝大多数HTTP头字段一致。而HTTP/2采用了新的方法来编码、传输客户端和服务器之间的数据。

HTTP/1.1与SPDY的区别 

SPDY（发音同“speedy”）是一个由Google主导的HTTP替代协议。SPDY一开始主要关注降低延迟，采用了TCP通道，但是使用了不同的协议来达到此目的。其与HTTP/1.1相比，主要的改变有：
 实现无需先入先出的多路复用
 为简化客户端和服务器开发的消息—帧机制
 强制性压缩（包括HTTP头部）
 优先级排序
 双向通讯

HTTP/2与SPDY的比较 
HTTP/2的开发基于SPDY进行跃进式改进。在诸多修改中，最显著的改进在于，HTTP/2使用了一份经过定制的压缩算法，基于霍夫曼编码，以此替代了SPDY的动态流压缩算法，以避免对协议的Oracle攻击——这一类攻击以CRIME为代表。此外，HTTP/2禁用了诸多加密套件，以保证基于TLS的连接的前向安全。

新特性 
在HTTP/2的第一版草案（对SPDY协议的复刻）中，新增的性能改进不仅包括HTTP/1.1中已有的多路复用，修复队头阻塞问题，允许设置设定请求优先级，还包含了一个头部压缩算法（HPACK）。此外， HTTP/2采用了二进制而非明文来打包、传输客户端和服务器之间的数据。

帧、消息、流和TCP连接
有别于HTTP/1.1在连接中的明文请求，HTTP/2与SPDY一样，将一个TCP连接分为若干个流（Stream），每个流中可以传输若干消息（Message），每个消息由若干最小的二进制帧（Frame）组成。这也是HTTP/1.1与HTTP/2最大的区别所在。HTTP/2中，每个用户的操作行为被分配了一个流编号（Stream ID），这意味着用户与服务端之间建立了一个TCP通道；协议将每个请求分割为二进制的控制帧与数据帧部分，以便解析。这个举措在SPDY中的实践表明，相比HTTP/1.1，新页面加载可以加快11.81%到47.7%

HPACK 算法 
HPACK算法是新引入HTTP/2的一个算法，用于对HTTP头部做压缩。其原理在于：
 客户端与服务端根据RFC 7541的附录A，维护一份共同的静态字典（Static Table），其中包含了常见头部名及常见头部名称与值的组合的代码；
 客户端和服务端根据先入先出的原则，维护一份可动态添加内容的共同动态字典（Dynamic Table）；
 客户端和服务端根据RFC 7541的附录B，支持基于该静态哈夫曼码表的哈夫曼编码（Huffman Coding）。

服务器推送 
网站为了使请求数减少，通常采用对页面上的图片、脚本进行极简化处理。但是，这一举措十分不方便，也不高效，依然需要诸多HTTP链接来加载页面和页面资源。

HTTP/2引入了服务器推送，即服务端向客户端发送比客户端请求更多的数据。这允许服务器直接提供浏览器渲染页面所需资源，而无须浏览器在收到、解析页面后再提起一轮请求，节约了加载时间。

瀏覽器支援 
截至2015年末，主要的浏览器的最新版本已经支持HTTP/2这一协议。其中：
Google Chrome、Mozilla Firefox、Microsoft Edge和Opera已支持HTTP/2，并默认启用。
Internet Explorer自IE 11开始支持HTTP/2，并預设啟用。

h2c的支持度 
HTTP/2的设计本身允许非加密的HTTP协议，也允许使用TLS 1.2或更新版本协议进行加密。协议本身未要求必须使用加密， 惟多数客户端（例如Firefox、Chrome、Safari、Opera、IE和Edge等）的开发者声明，他们只会实现通过TLS加密的HTTP/2协议，这使得经TLS加密的HTTP/2成为了事实上的强制标准，而h2c事实上被主流浏览器废弃。

SPDY退出历史舞台 
2015年9月，Google宣布了移除对SPDY支持的计划，拥抱HTTP/2，并将在Chrome 51中生效。

HTTP/2的实现 
HTTP/2工作组在其官方Github上罗列了诸多已经支持该协议的代码实现。

批评与争议
HTTP/2的开发过程乃至协议本身都曾受到批评。

针对协议开发本身 
FreeBSD和Varnish cache的开发者批评称，这个标准文件的准备过程短得不切实际，而且未基于除了SPDY之外的任何协议，以至于其他协议失去了对草案进行改进的机会。Kampala批评说，这个协议本身与HTTP不一致，而且还毫无必要地变得极为复杂。他还认为，这个协议违背了互联网协议的分层原则，例如说，将本属于TCP传输层的流控制（flow control）功能放入了协议中。

针对加密的争议 
一开始，以HTTP工作组某位主席为首的成员在邮件列表建议引入强制使用TLS协议实现的HTTP/2（Mandatory TLS in HTTP/2.0），这招致了争议。批评者认为，加密增加了十分不必要的开销，而且很多HTTP服务实际上无需加密，提供者也无意为此花费更多的资源。而支持者认为，实践中TLS加密的开销微不足道。

Poul-Henning Kamp批评IETF在制定HTTP/2时，遵循了一个特定的“政治议程”（political agenda），压缩了讨论的空间。

强制加密议程的批评者认为，其基于现有的证书框架，对于开源社区并非新创造，亦不是独特的。2013年，一位思科员工表示，现有证书模型与路由器一类的小型化设备并不兼容，因为现有的证书框架需要为每张证书付出不可避免的成本，还需要进行每年更新的流程。工作组最终未能在强制加密这一点上达成一致，但是大部分客户端只实现了基于TLS的HTTP/2，使之成为事实标准。

HTTP/2也被批评未能支持机会性加密，即类似SMTP中存在已久的STARTTLS一样能抵御的措施。 批评者指出，HTTP/2的提议违背了IETF自身制定的《最佳实践 188》（BCP 188） 即 RFC 7258。这份文件指出，被动监控应被当作一种攻击，IETF指定的标准应当设置抵御这种攻击的措施（例如机会性加密）。目前，已经有一系列机会性加密规范被提出
，工作组也制定了draft-ietf-httpbis-http2-encryption-01这一官方版方案。

参考资料

参见 
 超文本传输协议（HTTP）
 SPDY(已计划随NPN一起淘汰)
 多路复用
 QUIC
 WebSocket

外部链接 
 http://tools.ietf.org/wg/httpbis/  工作组主页
 https://http2.github.io/  HTTP/2 协议官网
 RFC 7540 – 超文本传输协议版本 2 (HTTP/2)
 RFC 7541 – HPACK: 为 HTTP/2 制定的头部压缩算法
 SPDY Protocol (draft-mbelshe-httpbis-spdy-00)
 HTTP Speed+Mobility (draft-montenegro-httpbis-speed-mobility-01)
 Proposal for a Network-Friendly HTTP Upgrade (draft-tarreau-httpbis-network-friendly-00)

网络协议
应用层协议
全球資訊網