更智能的HTTP/2(HTTP/2: Smarter at scale)
https://www.cncf.io/blog/2018/07/03/http-2-smarter-at-scale/安全
发布于2018-07-03服务器
本篇博客的做者为：Jean de Klerk， 谷歌公司的程序开发工程师网络
当前大部分网页都基于HTTP/1.1 协议。HTTP/1.1 协议的规则发表于1999年6月，距今小20年了; 尽管发生了如此大的变化，HTTP/1.1延用至今并蓬勃发展，真是让人注目；但在一些领域，她仍是略显老态，由于HTTP/1.1并非为其处理当前如此大规模和大流量的应用而设计的并发
HTTP/2协议规范发表于2015年5月，解决了其前身HTTP/1.1 的可扩展问题并提供了相似的使用体验；HTTP/2在几个方面对HTTP/1.1进行了改进，最重要的改进是在链接上提供了语义映射。在本文中咱们将探讨流的概念，以及它给软件工程师带来的实际帮助；负载均衡
链接的语义映射
建立一个HTTP链接的开销很大，你必须建立一个TCP链接，使用TLS保证链接的安全，交换HTTP的header和settings数据，等；HTTP/1.1为了简化这一流程，加长了链接的生命周期，并将链接看做一个可重用的对象。HTTP/1.1的链接保持空闲，当新的、一样目的地的请示到来时就能够复用已存在且空闲的链接；虽然复用链接缓解了这个问题，但一个链接一次只能处理一个请示，它们是1：1耦合的。若是一个大消息在发送，新的请示必须等待它发送结束，这就致使了行道阻塞（head-of-line blocking），或者，大部分状况下，咱们须要建立另外一个链接；框架
HTTP/2经过在链接之上提供一个语义层：流，来加强持久链接；流能够被认为是一系列语义上的消息，这些消息称为帧；一个流的生命周期可能很短，像请示用户状态的一元流，在HTTP/1.1中，相似于 GET /users/1234/status，当请示频率增长，其生命周期变长; 在这种状况下，客户端可能会创建一个长期存在的流，这样就能够持续的，实时的获取用户的状态；性能
流提供的并发性
流提供的主要优势是链接的并发性，如，链接上交错处理消息的能力；spa
为了解释这一点，咱们想像这样一个场景；几个A服务向服务B发送HTTP/1.1 请求来建立用户，更新我的资料信息，建立产品订单；产品订单比较大，每个订单都会分为5个TCP包；简况更新很小，只须要一个TCP包；用记建立请示也很小须要两个TCP包；设计
在某个时间段快照中，服务A有一个空闲的链接须要向服务B发送数据；服务A须要发送一个产品订单（request 1)， 一个我的资料更新（request 2) 和两个建立用户请求（request 3, 4)。由于产品订单请求先到，request 1便占据了空闲的链接，其他的三个请示要么等待产品订单完成发送,要么建立一些新的HTTP/1.1链接.代理
同时，使用HTTP / 2，流技术容许在同一链接上同时发送消息。 假设服务A建立了与服务B的链接，该链接有三个流：“新用户”流，“我的资料更新”流和“产品订单”流。 如今，后一个请求没必要等待第一个到达的大型产品订单请求； 全部请求同时发送。
可是，并发并不意味着并行。 咱们一次只能发送一个数据包。 所以，发送方可能会轮流在流之间循环发送数据包（请参见下文）。 或者，发送者能够将某些流优先于其余流。 也许让新用户注册对该服务更重要！
流量控制
可是，并发流包含一些微妙的陷阱。 请考虑如下状况：同一链接上的两个流A和B。 流A接收大量数据，远远超出了短期内能够处理的数据量。 最终，接收者的缓冲区已满，而且TCP接收窗口限制了发送者。 对于TCP，这都是至关标准的行为，可是这种状况对于流来讲是不利的，由于这两个流都不会接收更多数据。 理想状况下，流B应该不受流A缓慢处理的影响。
HTTP / 2经过提供流量控制机制做为流规范的一部分来解决此问题。 流量控制用于限制每一个流（和每一个链接）的未完成数据量。 它做为一种信用系统运行，接收方分配必定的“预算”，而发送方“支出”该预算。 更具体地说，接收方分配一些缓冲区大小（“预算”），发送方经过发送数据来填充（“支出”）缓冲区。接收方使用专用的WINDOW_UPDATE帧向发送方通告其余可用的缓冲区（在可用时）。 当接收方中止播发额外的缓冲区时，发送方必须在缓冲区（其“预算”）用尽时中止发送消息。
使用流量控制，能够确保并发流独立分配缓冲区。 结合循环请求发送，能够在单个链接上多路复用全部大小，处理速度和持续时间的流，而没必要担忧跨流问题。
智能代理
HTTP / 2的并发属性使代理的性能更高。 例如，考虑一个HTTP / 1.1负载均衡器，它接受并转发尖峰流量：当出现尖峰时，代理启动更多链接以处理负载或将请求排队。 前者（新链接）一般（在某种程度上）是首选； 这些新链接的缺点不只在于等待系统调用和套接字的时间，还在于在TCP慢启动发生时未充分利用链接所花费的时间。
相反，考虑配置为每一个链接多路复用100个流的HTTP / 2代理。 必定数量的请求峰值仍将致使新的链接被启动，可是与HTTP / 1.1须要的链接数相比，只须要其1/100的链接数。 更笼统地说：若是n个HTTP / 1.1请求发送到代理，则n个HTTP / 1.1请求必须发送出去； 每一个请求都是单个有意义的数据请求/有效负载，而且链接的请求为1：1。 相反，对于HTTP / 2，发送到代理的n个请求须要n个流，可是并不须要n个链接！
代理具备进行各类智能干预的空间，如：
- 测量其自身与服务之间的带宽延迟积（BDP），而后透明地建立支持传入流所需的最小链接数
- 在不影响基础链接的状况下杀死空闲流
- 跨链接的负载平衡流，在这些链接之间平均分配流量，确保最大程度地利用链接
- 基于WINDOW_UPDATE帧来衡量处理速度，并使用加权负载平衡来区分从消息处理速度更快的流发送消息的优先级。
更智能的HTTP/2
与HTTP / 1.1相比，HTTP / 2具备许多优点，可大大下降大规模实时系统的网络成本。 流提供了用户将看到的最大灵活性和性能改进之一，可是HTTP / 2还提供了与优美关闭（请参阅：GOAWAY），标头压缩，服务器推送，查验，流优先级等相关的语义。 若是您想了解更多内容，请查看HTTP / 2规范-它很长，可是很容易阅读。
要当即使用HTTP / 2，请查看gRPC，它是一种使用HTTP / 2的高性能，开源通用RPC框架。 在之后的文章中，咱们将深刻研究gRPC，并探索gRPC如何利用HTTP / 2提供的机制来大规模地提供使人难以置信的高性能通讯。