HTTP/2技术解密：如何处理线端阻塞HOLB

发布日期：2017-06-30

最近有一个围绕HTTP/2迁移的重要传言，从该协议草案被批准时起，我们一直听到越来越多关于浏览器、web服务器和网站添加HTTP/2支持的消息。网络性能专家鼓励大家采用新的标准，可以享受到已被经验证明的速度提升效果。有很多帖子解释了HTTP/2是什么，所以我们将会跳过这一环节，重点关注一个还未被解决的关键问题。

这是一个旧有的联网问题，叫做“线端阻塞(HOLB)”。你可以把它看做车辆管理局办公室门前排起的长队，在那里人们必须严格按照次序办事。“线端”的人是当前正在办理的那个人，这人可能会阻塞整个等待的队伍。当一个需要按顺序处理的数据包的队列，加上各种不同的处理时间、网络延迟或数据包丢失时，我们称这种问题为HOLB。

HTTP/2正在通过HTTP请求的多路复用来解决HOLB问题中的一种。如果我们仍然用车辆管理局来模拟的话，这就像是在为很多人同时办理。但这怎么可能呢?车辆管理局的员工不可能同时和所有人说话，对吗?但是，想象一下，他们说：“在计算机处理你的请求的时候，请站在旁边等候。请下一位办理!”。在这个例子中，造成HOLB现象的原因是计算机的运行速度缓慢，我们从这个方面着手开展工作，通过重新配置计算机运行时间来解决问题，此外，当连接丢失的时候，我们要开始处理一个新的请求。

HTTP在响应上一个请求之前往往无法接受新的请求。因此，网络延迟和请求的复杂性决定了其空闲程度。值得注意的是，HTTP/1.1支持流水线操作。但它确实没有解决这类HOLB问题，因为一个需要大量服务器处理时间的请求仍会阻塞随后的响应。而有了HTTP/2多路复用技术，情况就与上面的车辆管理局的例子类似了，很多请求和响应可以同时处理。

那么HTTP/2是否解决了HOLB问题呢?

完整的答案是“是，也不是”。实际上，有两个HOLB问题：一个在HTTP层面，另一个在TCP层面。正像HTTP服务器处理请求一样，TCP堆栈也必须处理数据包，并确保按顺序接收所有字节，这样HTTP才能使用这些数据。想象一个对应多个应用程序请求的数据包队列。如果这个队列头部的一个数据包延迟或丢失，你将会在TCP层面对HOLB问题。HTTP/2的确在HTTP层面解决了这个问题。但是，它仍处于与HTTP/1.1相同的TCP协议的上层，所以它无法解决TCP的HOLB问题。但是，有没有可能使情况变得更糟糕的情景呢?是的，原因在于，由于流水线操作/多路复用功能的存在，使用HTTP/2的应用程序可以通过一个单独的TCP连接发送更多请求。网络延迟的令人超乎想象的巨大的变化范围或影响TCP队列头部片段的连接丢失使得HTTP/2更有可能解决HOLB，它的作用也大得多。基本上，在头部恢复以前，接收方会一直处于空闲状态，而随后的所有数据片段都由TCP堆栈来处理。这意味着，一张图片可能已经下载成功，但由于HOLB的原因而仍然无法显示。

TCP有一些从HOLB中恢复的方法，但成本很高——在较为糟糕的情况下，会花费几秒钟时间。在转发“队列头部”片段的过程中至少会发生一次请求——响应往返过程。这些丢失的往返过程会对移动通信的性能产生巨大影响。

这很可能是谷歌没停留在SPDY(HTTP/2的前身)，而继续试验QUIC的原因，他们声称这么做的目标之一就是减少HOLB现象。还有一个IETF草案提出修改TCP来应对HOLB问题的方法。尽管这是一个公认的问题，但开发人员还一直没有找到可以欣然采纳的解决方案。

有一个叫Salesforce的公司想了个办法，将一个HTTP请求和一个TCP连接分隔开来：把数据传输想象成由多个TCP连接(网络环境需要多少个连接就有多少个)组成。HTTP请求的任何一部分都可以对应任何一个TCP连接。所以，如果你在一个连接中碰到了HOLB问题，这种方法不仅可以帮助你减少受影响的请求，它还可以最大程度地降低那些使用健康连接的其他应用程序的请求所受的影响。结果就有了这样一种能力，使发生HOLB的风险最小化，同时还能享受多路复用和流水线操作带来的好处。

HTTP/2是HTTP协议的一个激动人心的修订版本。它提供的性能提升是毫无疑问的。但与此同时，它也带来了一个问题，那就是如何最好地使用这些来自现实世界部署中的新功能和经验，来为我们提供最好的指导。

HTTP/2技术解密：如何处理线端阻塞HOLB

数字证书

技术支持

关于沃通

旗下网站