我们是光大科技有限公司智能云计算部基础设施团队，致力于规划、设计、运维管理集团基础设施环境，保障集团基础设施环境稳定运行，我们团队拥有经验丰富的网络，应用交付，安全专家。将不定期分享网络运维技巧，分析各种网络协议，提供应用交付及安全案例。将与大家共同探索金融行业基础架构发展趋势。
简介
亲爱的朋友们，很高兴又与各位见面。笔者在之前的文章中，有幸带大家简单了解过HTTP协议以及有关HTTPS TLS的相关知识。而近几年，随着HTTP2.0的迅速发展，引来了一场互联网界的血雨腥风，颠覆了我们对于传统应用的认识，今天笔者将为您介绍HTTP2的相关知识，请您领略HTTP2的风范。了解我们日常所访问的网站，为何越来越流畅，越来越精彩。
HTTP1.1回顾
要说HTTP2，不得不先回顾下HTTP1.1为我们的生活工作带来了哪些便利。早在互联网发展的早期，我们去访问一个网站，给人的唯一感觉就是慢！这取决于当时网络带宽的瓶颈以及早期HTTP协议效率的低下。而伴随着网络技术的大规模发展，我们的网速得到了极大的提升。而早期HTTP1.0的低效率却成为唯一的绊脚石。就在这时，HTTP1.1在众人的注目下横空出世。
为何HTTP1.1能如此受人爱戴，我们不妨先来了解下HTTP1.0所遇到的困难。我们知道，HTTP协议是建立在TCP的连接之上，以请求-响应来完成的。
下面是HTTP1.0的工作模式：
从上图中，我们可以发现，当我们客户端去请求服务端一个资源时，在HTTP1.0模式下，首先我们先要经历TCP三次握手，在三次握手完成后，客户端发出HTTP1.0请求，随后服务端收到后，会定位资源并反馈给客户端，客户端收到后，会立即通过四次挥手与服务端断开连接。现在我们打开一个网站，虽然我们看到的只是一个页面，但其中却包含了很多资源，比如图片以及CSS以及Javascript等文件。也就是说，我请求一个页面涉及很多次HTTP请求，每个请求都会进行三次握手和四次挥手，这样的效率低的惊人。所以虽说TCP是万能协议，但也架不住HTTP1.0的无力。
那么HTTP1.1又给我们带来了怎样新奇的体验呢，不如先看下图，了解下HTTP1.1的工作模式：
通过上图，我们发现了惊喜，甚是激动，HTTP1.1可以在同一个TCP连接上发送多次请求并接收响应。效率得到了极大的提高，之前HTTP1.0时，我请求三个资源需要历经9*3=27次交互。而HTTP1.1使交互的数量变为了13，如果请求的数量越多，那么效率还会越高。这种举措正顺应了互联网高速发展的历程。为我们快速访问资源，浏览页面立下了汗马功劳。
然而HTTP1.1也存在着自己的硬伤，虽然访问效率提高了，但还是有两个问题比较突出：
第一个问题是依旧基于请求-响应的模式，服务端无法主动推送内容至客户端。比如我在某论坛发表了言论，别人正好之前登录了这个论坛，那么他只有通过重新刷新页面的方式，来看到我所发表的内容。为了解决这个问题，应运而生的技术有AJAX，但提升效果有限。随后HTTP2以及WEBSOCKET技术的出现，彻底颠覆了这种格局。
第二个问题是必须等待前一个请求收到响应后才可发出本请求。这点也无疑制约了HTTP1.1的发展。比如：我访问的页面有许多个资源，其中第三个资源较大，那么我必须等待第三个请求得到响应后，才会发出第四个请求。这点也成为了HTTP1.1的阿喀琉斯之踵。但HTTP2的异军突起，也同样解决了这个问题。
HTTP2横空出世
上面，我们探讨了HTTP1.1所做出的贡献以及所遇到的困难，而HTTP2的出现将颠覆我们的传统认知。
下面我们来看一下HTTP2服务端与客户端交互。
HTTP2主动推送消息：
上图中，我希望获取三个资源分别是index.html，CSS以及Javascript文件。但大家可以发现，我只使用了一次请求，CSS和JS文件是服务端推送给我的。这要是在传统HTTP1.1中，需要三个请求并获取三个响应才能完成。HTTP2.0极大的提高了效率，减少请求的数量，令我们喜上眉梢。
但一般的事情总是双喜临门，HTTP2不仅带来了主动推送的福音，还有更令人兴奋的变化，接着上图：
在HTTP2中下一个请求并不需要等待上一个请求收到响应。这也就是HTTP2另外一个让人为之疯狂的地方。请求可以并行发送，极大提高效率，漫长等待的日子一去不复返。
HTTP2协议分析
在吹嘘这么多HTTP2的优点后，我们是时候来进一步了解HTTP2为何能实现如此强大的功能。
下面我们揭开HTTP2的神秘面纱，从协议和工作方式上来了解HTTP2的魅力。
首先我们知道在HTTP1.1中，传输是以请求为单位，服务端收到请求后会得到响应，每个请求中携带请求方法，URL以及大量的header，同时部分例如post等请求可以携带用户数据，简称Body。
而HTTP2的工作过程中，引入了流即Stream的概念，而最小的请求单位为frame帧，每个帧都属于一条流。且有如下原则：客户端主动发起的请求Stream流的ID序号为单数，而服务端主动发起的Stream流的序号ID为偶数。
下面我们通过示意图来直观的感受：
这张图是笔者抓取新浪首页的抓包结果，我们发现新浪首页www.sina.com.cn 站点已经支持HTTP2，在笔者标红框的内容就是一个HEADER帧，同时指明了Stream流的ID为1。因为此帧由客户端主动发起，故ID号为基数。
我们接着往下看：
大家是否发现很熟悉，这些就是我们常见的HTTP Header。与HTTP1.1直接在请求里包含Header字段不同，HTTP2将Header字段封装在帧中传送。最重点的是，原来在HTTP1.1中，每个请求都需要携带大量Header，但HTTP2在同一条流上，分为了Header帧和DATA帧，DATA负责传输数据，不用携带Header的内容，从而大大减少所传输的内容，提升效率。
咱继续往下看：
后面我们通过上图发现，客户端可以连续的发送请求，而不用等待上一个请求收到响应，这效率堪称完美。这取决于Stream的区分，上图中的Stream号为15，17，19，21，23，25。不同Stream的这些帧是可以连续发送的。
另外一点就是我们提到的主动推送功能。在HTTP1.1中除了通过客户端与服务端协商upgrade到Websocket协议，否则无法实现服务端主动推送消息。我们知道TCP的连接本身就是双向的，在三次握手之后，服务端和客户端都可以主动发送消息，故HTTP2在设计时，同样考虑到了如何把TCP的优秀能力进行传承，将主动推送功能最为了重点功能加以实现。
我们还是以截图为例：
PUSH_PROMISE帧的出现使原来的不可能变为了可能。服务端将主动告诉客户端，接下来将推送的内容为/app/poster.jpg这个文件。客户端从而做好了接收准备，接收文件。
最后大家可以访问一个测试网站来真实感受下HTTP2所带来的提升。
网址为：http2.akamai.com/demo。
打开后，浏览器会分别以HTTP1.1及HTTP2两种方式去请求同一张图片，我们可以看到HTTP2的效率相比HTTP1.1有了明显的提升。笔者测试时所处的网络环境质量比较好，而当在网络质量一般的状况下测试，显示的差距将更大。
总结
HTTP2的出现无疑为我们的互联网高速互联添砖加瓦。本文只是对HTTP2的一些特性做出最基本的分析，实际上HTTP2对Header的压缩也是很有学问的地方，包括HPACK算法。有兴趣的伙伴，也可以进一步学习HTTP2，了解其精髓。也欢迎随时与我们沟通，共同学习，共同进步。
作者：任远
往期回顾
浅谈自然语言处理中基于机器学习
初识日志管理系统
IT设备部署及上架
基于P2P的分布式网络存储服务
快来关注吧！
公众号：EBCloud
原创文章，作者：EBCloud，如若转载，请注明出处：https://www.sudun.com/ask/32610.html
