更智能的HTTP/2(HTTP/2: Smarter at scale)

_PS_

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,当请示频率增加,其生命周期变长; 在这种情况下,客户端可能会建立一个长期存在的流,这样就可以持续的,实时的获取用户的状态;

流提供的并发性

流提供的主要优点是连接的并发性,如,连接上交错处理消息的能力;

为了解释这一点,我们想像这样一个场景;几个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提供的机制来大规模地提供令人难以置信的高性能通信。

阅读 585

1 声望
0 粉丝
0 条评论

1 声望
0 粉丝
文章目录
宣传栏