HTTP/2 协议给 REST API 的新增益
21CTO社区导读：HTTP/2一出生以来就会给REST API提供很多的新特性，包括集成方便，物联网以及性能、安全等重大特性。
HTTP/1.x 与 HTTP/2
首先，我们来看这两个协议的一些重要区别：
HTTP/ 2是二进制的，而非文本式。
二进制协议解析更有效率，更“紧密”。最重要的是，与HTTP/ 1.x文本式协议相比，错误率要低得多。文本有许多额外的“帮助”要处理，比如空白字符，大小写字符，行尾，空行等。
比如， HTTP / 1.1定义了四种不同的解析消息的方式，而在HTTP / 2中，只有一个代码路径。
HTTP/ 2在通信链路上做到了完全复用，而不再是排队和阻塞式。
HTTP/ 1.x有一个著名的叫做“头部阻塞”的问题，实际上一次只能有一个请求在一个连接上出现。
HTTP/ 1.1试图用“流水线”机制来解决这个问题，但是它并没有完全解决这个问题（一个数据较大或很慢的响应仍然会阻止其它人）。 另外，由于许多代理和服务器不能正确处理流水线，流水线的部署也比较困难。
这迫使客户端用一些启发式（经常猜）来确定什么请求以及何时放在哪个连接上; 由于页面加载可用连接数量的10倍（或更多）是很常见的，这可能会严重影响性能，通常会导致请求被阻止的“瀑布”。
多路复用通过允许多个请求和响应消息同时在飞行中来解决这些问题;甚至有可能将一条消息的一部分与另一条消息混合在一起。
这反过来又允许客户端在每个来源只使用一个连接来加载一个页面。
HTTP/ 2可以使用一个并行连接
使用HTTP / 1.1中，浏览器在每个页面打开4到8个连接。 由于许多网站使用多个来源，这可能意味着单个页面加载打开超过30个连接。
一个打开这么多连接的应用程序同时打破了TCP构建的许多假设; 由于每个连接都会在响应中启动大量的数据，因此中间网络中的缓冲区溢出会造成拥塞事件并重新传输。
可以在这里看到HTTP / 2如何工作的演示： https： //http2.akamai.com/demo
此外，使用如此多的连接来争夺网络资源，其他更高级的应用程序（例如，VoIP）也可以“窃取”他们。
HTTP/ 2使用头压缩来减少开销
如果你认为一个页面大约有80个资源（在今天的网页这个数字是保守的），并且每个请求都有1400个字节的头文件（同样也不少见，这要归功于Cookies，Referer等），所以至少需要7-8为了让标题“出来”。 这些，还未包括响应时间。
这是因为TCP的慢启动机制 ，它基于已经确认了多少包来在新的连接上传递数据包 - 有效地限制了在前几个往返行程中可以发送的数据包的数量。
相比之下，即使是头文件的轻微压缩，也可以让这些请求在一个往返过程中进入线路 - 甚至可能是一个数据包。
这种开销是相当可观的，尤其是当您考虑对移动客户端的影响时，即使在良好的条件下，往往会看到几百毫秒的往返延迟。
HTTP/ 2允许服务器主动将“响应”推入客户端缓存
当浏览器请求一个页面时，服务器会在响应中发送HTML，然后需要等待浏览器解析HTML，然后发出对所有嵌入资源的请求，然后才能开始发送JavaScript，图像和CSS。
服务器推送可能允许服务器通过将它认为客户端需要的响应“推送”到其缓存中来避免这种延迟。
然而，推动反应并不“神奇” - 如果使用不当，可能会损害性能。 目前，很多人仍然会继续使用Webhooks 。
如何影响现有的基于HTTP/ 1.1的REST API
HTTP的主要语义已如数保留在HTTP / 2中。 这意味着它仍然具有诸如GET ， POST ， HTTP essay-headers和URI方式来标识资源。
HTTP/ 1.1的变化是HTTP语义（例如“我想在主机domain.com上放置资源/foo”）通过网络传输的方式。 这意味着构建在HTTP / 1.1上的RESTAPI将继续像以前一样透明地工作，而不会对应用程序进行任何更改 。
运行应用程序的Web容器将负责代表应用程序将新的连线格式转换为通常的HTTP语义，而应用程序只会看到更高级别的HTTP语义，不管它是通过HTTP / 1.1还是HTTP / 2。
由于HTTP / 2线格式更高效（特别是多路复用和压缩），运行在HTTP / 2之上的RESTAPI也会从中受益。
HTTP/ 2 Push中的另一个主要改进是针对相关资源的高效下载。在大多数REST API使用情况下可能没有特别明显，如果你用Amazon S3这样的对象存储服务可以从中受益更多。
HTTP/ 2的典型要求是部署在TLS上。 这要求部署者从HTTP转移到HTTPS ，这意味着从可信任的权威机构购买SSL证书等。
HTTP/ 2的好处解释
HTTP/ 2所带来的主要改进之一是多路复用流，头压缩，服务器推送和二进制协议，而不是文本协议。 这些和其他积极的变化允许获得良好的网页加载结果，包括那些附加有大量附加文件（例如样式，脚本，图像，字体等）的结果。
HTTP/ 2也提供了许多用于服务器到服务器通信的新功能：
使用推送请求的双向通信
HTTP/ 2的“服务器推送”允许服务器主动将事物发送到客户端的缓存以供将来使用。
这有助于避免获取HTML和链接的样式表和CSS之间的往返行程; 服务器可以立即开始发送这些东西，而无需等待客户请求。
主动更新让客户端的缓存无效，这也是开发者所需要的特性之一。
当然，在某些情况下，客户端不希望推送到这一特性。可能它已经存在了一个副本，或不会使用到它。 在此种情况下，可以用RST_STREAM来表示“否”。
在单个TCP连接内复用
HTTP/ 2使用多路复用来允许多个消息同时在一个连接上合并在一起，这样一个大的响应（或者服务器花费很长时间考虑）不会阻塞其它消息。
此外，它还添加了标题压缩，以便正常的请求和响应标题不会占据网络带宽，即使请求的内容非常小。 这对移动设备来说是一个巨大的价值，这种情况下，获取大的请求头可以很容易地通过多次往返来消除大量资源的页面加载时间。
长时间连接
HTTP/ 2被设计为使用更少的连接，服务器和网络将享受更少的负载。 当网络拥塞时，这一点尤其重要，因为HTTP / 1使用多个连接进行并行处理会增加问题。
例如，如果您的手机向服务器请求打开6个TCP连接来下载一个页面的资源（记住现在大多数页面使用多个服务器提供内容），它可能很容易超载移动网络的缓冲区，导致它们丢弃数据包，触发重传，使问题加大。
HTTP/ 2允许每台主机使用单个连接，并鼓励网站在可能的情况下将其内容整合到一台服务器上。
状态连接
如果您的HTTP / 1客户端发送请求，然后发现它不需要响应，则需要关闭连接以节省带宽; 没有安全的方法来恢复它。
HTTP/ 2添加了RST_STREAM框架以允许客户端改变主意; 如果浏览器导航离开页面，或者用户取消下载，则可以避免在不浪费带宽的情况下打开新的连接。
再次，这是关于提高感知性能和网络友好性; 通过允许客户在这种常见情况下保持连接活跃，避免了额外的往返和资源消耗。
但是，一如既往，不是一切都是有用的，HTTP2也有一些缺点：
使用二进制代替文本，这确实是一个不错的功能。
但是HTTP / 1能够使用telnet，用键盘来键入请求头和内容（如果服务器不超时！），然后查看响应。 这在HTTP/ 2中是不要用的，因为它是一个二进制协议。
为什如何？我们考虑如何将short int 30000（0x7530）存储为文本形式和二进制形式：
正如你所看到的，而不是使用5个字节，我们使用了2个字节，尺寸减少了50％以上。
虽然二进制协议的解析开销较低，但网络的体积略小，但这一重大变革的真正原因是二进制协议更简单，也不容易出错。
由于文本协议须包括如何分隔字符串（如双引号，换行符等），如何处理空格，多余的字符等问题。 这导致了很多实现的复杂性。 在HTTP / 1中，有至少3种方法可以告诉消息什么时候结束，还有一套复杂的规则来确定哪个方法正在使用。
HTTP/ 1的纯文本性质也是一些安全问题的来源; 因为不同的实现方式对于如何解析消息做出了不同的决定，所以恶意方可以发起攻击（例如，响应分裂攻击）。
当然，对于那些想调试协议的人们来说，需要新的工具来解决这个缺点。 让我们欣慰的是，Wireshark已经有了一个插件。
更多的加密方式
HTTP/ 2不再需要使用TLS（SSL的标准形式，Web的加密层）。但其更高的性能使得使用加密变得更加容易，因为它减少了对网站速度的影响，这意味着我们需要购买SSL证书，续订等。当您使用REST API处理许多微服务时，这确实是一笔小额的资金。
事实上，大多数人都认为在“开放”互联网上部署新协议的唯一安全方法是使用加密技术，Firefox和Chrome的制造商们已经表示，他们将只支持使用TLS的HTTP / 2。
这存在两个原因。 一个是在互联网上部署新版本的HTTP很难，因为像代理和防火墙这样的许多“中间件”都假定HTTP / 1不会改变，如果它们能引入互操作性甚至是安全问题尝试解释一个HTTP / 2连接。
另外Web已经是一个越来越危险的地方，使用加密技术是减少一些威胁攻击的一种有效方法。 通过使用HTTP/ 2作为主协议，对Web的整体安全性能够得以大幅度改善。
小结
在当今的微服务架构中，大多数基于REST的微服务正在进行服务器到服务器的通信，当许多微服务在许多方面彼此通信时但仍使用REST时，HTTP/ 2可以提高流的传输速度。
HTTP/ 2没有定义JavaScript API，也不能帮助您更轻松地构建RESTAPI 。 目前，在Web浏览器中运行的JavaScript客户端只能有限地使用这些新功能。 但是对于服务器到服务器的通信，HTTP / 2提供了很多方法来超越现有的REST API。
HTTP经历了很长一段时间的制定，实验与演变。越来越明显的是，社区的注意力正在转向TCP以及其对性能的影响。目前有消息说，已经有关于在IETF中调整甚至取代TCP的讨论已经开始。
作者：Guy Levin
译者：21CTO社区
地址：https://dzone.com/articles/ben ... http2
本文为 @ 21CTO 创作并授权 21CTO 发布，未经许可，请勿转载。
内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 公众号。
该文观点仅代表作者本人，21CTO 平台仅提供信息存储空间服务。
评论
