原来你是这样的http2......

欢迎你们前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~

本文由mariolu发表于云+社区专栏

序言

目前HTTP/2.0（简称h2）已经在普遍使用（截止2018年8月根据Alexa流行度排名的头部1千万网站中，h2占比约29%,https://w3techs.com/technologies/details/ce-http2/all/all）。写此文章的目的是：h2做为较新的技术，并逐渐占有率普遍，虽然目前有更新的QUIC，但其实现思路相似于h2。颠覆以往的HTTP/1.x，H2的创造性的技术值得咱们细细品味。此篇文章根据笔者在h2开发经验和思考，向你介绍全面的h2知识以及是非功过。本篇更注重于帮助读者理解h2的设计思路、亦可做为一篇RFC导读或者总结。

第一话、追踪溯源

图一、HTTP年鉴图

早在1991年，伴随WWW诞生之初，HTTP/0.9协议已经提出。HTTP0.9是简单且应用受限的协议。支持去网络主机获取对应路径的资源。可是没有扩展属性。其协议之简单甚至只用下面一个访问谷歌主机的例子归纳了HTTP/0.9的所有。以下所示，协议只支持GET，没有http头；响应只能是超文本。

telnet google.com 80

Connected to x.x.x.x

GET /about

(Hyper text)

(Conection closed)

随着人们对富媒体信息的渴望以及浏览器的普及，HTTP/1.0在1996年被提出来。HTTP/1.0的不少特性目前还被普遍使用，可是仍然像HTTP/0.9同样一次请求须要建立一次的tcp链接。随即短短几年时间内，HTTP/1.1以RFC标准形式再次展示在人们眼前。此时的HTTP协议1.1版本已经从新设计了长链接、options请求方法、cache头、upgrade头、range头、transfer-encoding头, 以及pieline(in order)等概念。

而咱们另外一个所熟知的HTTPS的SSL/TLS技术各个版本差很少在后来的十年间逐渐被提出。出于安全考虑，互联网通讯间的防火墙路由交换机等设备，这些设备通常仅会开发有限的端口（如80和443）。各类版本的通讯协议只能复用这些端口。HTTP1.1的80端口设计了upgrade请求头升级到更高级的协议，而443端口为了不多消耗个网络RTT，在tls握手过程当中使用了NPN/ALPN技术直接在通讯以前保持CS两端的协议一致。NPN/ALPN是是TLS协议扩展，其中NPN是Google为实现spdy提出的。由服务端提供可支持的协议，供客户端选择。ALPN则是更接近于HTTP交互的方式，由客户端先发出使用某种协议的请求，由服务端确认是否支持协议。ALPN为了HTTP2诞生作铺垫。

另一个不得不提的是spdy协议。Spdy旨在解决HTTP1.1的线头阻塞问题（后面章节有详细讨论）于2009被google提出。同时分别于2012提出了spdy3.0实现了流控制，2013-2014期间提出了流优先级，server push等概念。Spdy的存在乎义更像是http2.0的体验服。它为探索HTTP继续演进道路作了铺垫。

第二话、人机交互

汇编是效率最高的语言之一，可是又是最晦涩难懂的语言之一。而人脑易懂的编程语言每每牺牲性能做为折衷。简单说，HTTP/1.x协议就是为了人类语言习惯所设计的协议，可是转换成机器执行协议并非高效的。让咱们在回顾下计算机执行解析HTTP1.x的流程。

GET / HTTP/1.1<crlf>

Host: xxx.aa.com<crlf>

<crlf>

对应的解析伪代码是

loop

while(! CRLF)

read bytes

end while

if line 1:

parse line as Request-Line

else if empty line:

Break out and We have done

else If start with non-whitespace

parse header

else if space

continue with last heade

end if

end loop

在伪代码解析流程能够看到，肉眼看起来简洁的协议解析起来是这么的费劲。并且在HTTP服务器中还要考虑这种问题：字节行的长度是未知的，也不知道预先分配多大内存。

HTTP/2.0使用了计算机易懂的二进制编码信息，并且得向上兼容HTTP的涵义。具体咱们来看下他是如何作到的。像大多数通讯协议同样，桢是传输最小单位。桢分为数据帧和控制桢。数据帧做为数据的载体，控制桢控制信道的信令。h2桢的通用格式为首部9字节+额外的字符。正如你能想到的那样，桢的第一个部分是描述长度，第二个部分描述了桢的类型，第三个部分描述了标志Flag，第四个部分是惟一序列号。这是全部桢的通用头。通用头紧接的是桢的实体。图4展现了桢的结构。

图二、通用桢的格式

这样设计有什么好处呢。再来看一下桢的解析流程，你就会发现对计算机来讲更简洁。

loop

read 9 byte

payload_Length=first 3 bytes

read payload

swith type:

Take action

end loop

HTTP2.0使用header桢表达HTTP header+request line，data桢表达Body。header桢和data桢使用相同的stream id组成一个完整的HTTP请求/响应包。这里的stream描述了一次请求和响应，至关于完成了一次HTTP/1.x的短链接请求和响应。

第三话、并行不悖

上节讲到咱们用h2桢完整表达了HTTP/1.x。可是h2协议抱负远不止于此。它的真正目的是解决以前HTTP1.x的线头阻塞问题、改善网络延迟和页面加载时间。

咱们知道一个完整的网页包含了主页请求和数次或数十次的子请求。HTTP/1.1已经能够并行发出全部请求.可是HTTP自己是无状态的协议，它依赖于时间的顺序来识别请求和响应直接的对应关系。先来的请求必须先给响应。那么若是后面的响应资源对浏览器构建DOM或者CSSOM更重要。那它必须阻塞等待前者完成。固然这也难不倒咱们，咱们能够多开几条tcp链接（浏览器规定一个origin(协议+host+port）最多6个）或者合并资源来减小没必要要的阻塞。这是有代价的。首先tcp建连的开销，其实合并资源带来一小块子资源过时致使整个合并资源的缓存过时。对此，h2有一揽子的解决方案，接下来一一道来。

h2在一个tcp链接建立多个流。每一个流能够有从属关系，好比说根据浏览器加载的优先级顺序（主请求>CSS>能改变DOM结构的JS文件>图片和字体资源文件）创建一条依赖关系链。处于同一等级的依赖关系中能够设置权重。权重用于分配传输信道资源多少。

图6例子说明了有一次主页请求index.html、一次main.css，一次jq.js以及一些image文件和字体文件qq.tff

图三、h2请求的依赖树

HTML的优先级最高，在HTML传输完成以前，其余文件不会被传输。HTML传输完成后，JS和CSS根据其分配的权重占比分配信息传输资源。若是CSS传输完成后，TFF和PNG若是是相同权重，那么他们将占有1/4的信道资源。

这里抛出3个问题和答案。

• 若是CSS被阻塞了,那么 JS 获得本属于CSS的通讯资源
• 若是CSS传输完成但没有被移依赖树, TFF和PNG继承CSS的通讯份额 (假设TFF和PNG权重同样，那么各分得1/4通讯资源).
• 若是CSS在依赖数被移除，JS, TFF, PNG平分通讯资源（假设3个权重同样，那么三者各分得1/3通讯资源）

第四话、众星捧月

HTTP2还设计了一系列方案来改善网络的性能、包括流量控制，HPack压缩，Server Push。

什么你说TCP已经有流量控制了，HTTP不是画蛇添足吗？没错，可是在单条TCP内部，各个流但是没有流量控制。流量控制使用了Update Frame不断告知发送方更新发送的窗口大小（上限）。流量控制一个现实用途是阻塞不重要的请求，以腾出更大的通讯资源给重要的请求使用。流量控制是不能够被关闭的，流量大小能够设置2的31次方-1（2GB）。不一样的中间网络设备有不同的吞吐能力。流控的另外一个用途在于同步全部的中间设备交换机最小的上限。流量窗口初始大小为65535（2的16次方-1）。

就像世界上的大多数财富汇集在少数人身上同样。在一份对48,452,989个请求的统计中，如下11个头占据了99%的数量，依名次递减分别是user-agent、accetp-encoding、accept-language、accept、referer、host、connection、cookie、origin、upgrade-inseure-request、content-type。http header的值也有很大类似性，好比说”/index.html“, “gzip, deflate”。Cookie也携带冗余的信息。

这些都组成了http header大量能够压缩的内容。

而在一份GET请求和一个304响应或者content-length不多的响应中，这些头占据了很大比例的通讯资源。2016年发布的一份HTTP报告中，请求头大约在460bytes，对一个一般的网页，平均会有140个请求对象。这些头总共须要63KB。这些量颇有可能会是首屏和页面加载时间优化的瓶颈。

可能你会说用gzip等压缩算法这些请求头，不就完了吗？的确spdy就这样干过，直到2013年BREACH攻击暴露了gzip压缩在https应用的安全性，这种攻击让攻击者很容易得到session cookie等数据。因而才有了HPACK。

HPACK简单来讲就是索引表，包括静态表和动态表。静态表由RFC定义，从不改变，静态表预留了62个表项。每一个链接的通讯双方维护着动态表。

H2协议使用索引号表明http中的name、value或者name-value。假设被索引的是name，value没有索引，那么value还能够用霍夫曼编码压缩。

• 在预约的头字段静态映射表 中已经有预约义的 Header Name 和 Header Value值，这时候的二进制数据格式如图4， 第一位固定为1， 后面7位为映射的索引值。图8的83就是这样的，83的二进制字节标示1000 0011，抹掉首位就是 3 ， 对应的静态映射表中的method：POST。

图四、index索引name和value

图五、抓包示意

• 预约的头字段静态映射表中有 name，须要设置新值。图6所示例子，一个指定 path的Header，首字符 为 44 ，对应的二进制位0100 0100。前两个字符为 01 ，Index 为 4 ，即对应静态映射表中的 path 头。第二个字符为 95对应的二进制位 1001 0101，排除首字符对应的 Value Length 为 十进制的21。即 算上 44，一共23个字符来记录这个信息。

图六、index索引name和自定义value

图七、抓包示意

• 预约的头字段静态映射表中没有 name，须要设置新name和新值。40 的二进制是0100 0000，02 的二进制是0000 0010，后七位的十进制值是 2，86 的二进制是1000 0110，后7位的十进制值是6。

图八、index索引自定义name和自定义value

图九、抓包示意

• 明确要求该请求头不作hpack的index

HTTP2.0还有个大杀器是Server Push，Server Push利用闲置的带宽资源能够向浏览器预推送页面展现的关键资源，Server push有效得下降了页面加载时间。具体详情参考笔者的另外一篇文章https://cloud.tencent.com/developer/article/1159626。

第五话、庖丁解牛

HTTP2相比HTTP1更适合计算机执行。可是其二进制特性不易于人脑理解。这一话咱们专门来说讲关于http2的调试工具。

• Chrome(qq浏览器)能够按住F12查看h2协议。图13所示为浏览器网络时序图，列出了具体协议名称。chrome还能够在地址栏敲入chrome://net-internals/#http2查看到h2协议细节，如图11所示。点击相应的host就能够看到h2协商过程，如图12所示。

图十、浏览器的网络时序图

chrome://net-internals/#http2

图十一、chrome调试h2

图十二、h2协商过程

• wireshark（需和chrome或firefox搭配使用）。设置环境变量SSLKEYLOGFILE=c:\temp\sslkeylog.log。而后在Wireshark->Preferences->Protocols->SSL配置key所在路径。

图1三、wireshark配置

图1四、wireshark抓h2包

• Nghttp2是一个完整的http2协议实现的组件。做者也参与过spdy实现。目前nghttp2库被不少知名软件做为h2协议实现库使用。另外nghttp2也自带了h2协议的分析工具。图18展现了在明文状态使用upgrade头升级到h2c。图19展现了在https基础上升级到h2。

图1五、明文状态使用upgrade头升级到h2c

图1六、展现了在https基础上升级到h2

Curl的—http2选项（须要和nghttp2一块儿编译）

图1七、支持h2的curl客户端调试

• Github还有些实用的http2工具组件，诸如chrome-http2-log-parser、http2-push-manifest等组件，笔者后续会专门开篇文章介绍这些工具。对于移动端的调试，ios能够用charles proxy作代理，android须要开发者模式使用移动端的chrome，笔者在移动端使用较少，这里就不作展开。

第六话、雕栏玉砌

H2怎么部署呢，目前主流服务端像nginx、apache都已经支持http2，主流的客户端curl和各类浏览器（包括移动端safari和chrome-android）基本也支持http2。代理服务器如ATS、Varnish，Akamai、腾讯云等CDN服务也支持http2。那么怎么把一套网站部署到h2。或者说部署h2网站和以前h1网站有什么不同？

若是是本身的源站，那么请确保服务器支持TLS1.2已经RFC7540所要求的加密套件，h2须要保证支持alpn。你可使用ssllabs等网站检查。对于h2服务器的要求是h2必须了解如何设置流的优先级，h2服务器须要支持server push。h2客户端须要尽可能多的发送请求。

若是你的网站是从http1.x迁移过来的，那么以前对于http1.x所作的优化可能无任何帮助甚至更差。合并小文件不在须要，由于额外的小文件请求在h2看来只是开销不多。而且若是大文件的局部更改使得整个大文件缓存失效。在http1.0时代使用多个域名来并发http链接，在http2也毫无必要，由于http2天生就是并发的。http1.x作的优化好比说图片资源文件不使用cookie来减小请求大小，http2的header压缩功能也减小了这种影响。即便不作这种优化也亦可。像合并css、小图片带来的增益在http2.0也是可忽略的。

若是网页使用第三方网站组件，那么请尽量减小使用第三方网站组件。第三方网站不能保证支持h2，因此它可能成为木桶理论的最大短板。

谨慎使用2.0-1.x的部署方案，h2流转化成h1请求。由于这样没法发挥h2性能。

图1八、2.0-1.x的部署方案

CDN代理服务器的h2支持，能够屏蔽h2强制走tls的代理服务器。如图19，代理能够在与各类协议客户端的网络环境下，切断和客户端的tls链接，和服务器新建链接。也能够做为load balancer，至关于HTTP2.0用户和HTTP2.x服务器直接通讯。

图1九、带tls客户端功能的代理

图20列举若是绕过proxy到达h2服务器。此时的proxy至关于tcp转发的load balance功能的设备。若是该proxy支持tls的alpn协议，那么它也能够选择HTTP代理功能，和h2服务器能够创建加密链接。若是即不支持alpn，也不支持tcp转发。那么proxy只能用upgrade升级成h2协议。

图20、通过代理服务器的H2部署方案

第七话、十全九美

HTTP2.0是创建在TCP之上，因此TCP的全部缺点他都有，因此H2能发挥最大性能得益于调优的tcp协议栈。TCP的慢启动特性，决定h2一开始的并发流量不会太大，TCP以及SSL的握手链接也会拖慢h2的首包网络耗时。QUIC则彻底地抛弃TCP，在UDP基础上实现了HTTP2的一系列特性。同时作了应用层的如TCP的可靠性保障。同时这些TLS1.3传输更快更简洁。这些都为HTTP2.0进化到HTTP3.0提供了一些思路。

总结

以上内容都来源于笔者的实践经验和理论总结。篇幅所限不能涵盖各个细节。具体能够继续参考RFC7540和RFC7541协议。

问答
没有“http | https”的网址怎么实现？
相关阅读
我是怎么一步步用go找出压测性能瓶颈
HTTP/2之服务器推送(Server Push)最佳实践
低于0.01%的极致Crash率是怎么作到的？
【每日课程推荐】新加坡南洋理工大学博士，带你深度学习NLP技术

此文已由做者受权腾讯云+社区发布，更多原文请点击

搜索关注公众号「云加社区」，第一时间获取技术干货，关注后回复1024 送你一份技术课程大礼包！

海量技术实践经验，尽在云加社区！