HTTP 2应该比HTTP 1.1快得多，因为它允许在同一TCP连接上进行多个请求，而无需首先等待每个答复。
但是，我在HTTP 1.1中看不到任何阻止此行为的内容。 TCP只是两种单向流，因此服务器不应该知道或关心在客户端接收到响应k之前是否已发送请求k + 1。
因此，客户端可以一次发送所有请求，然后拉回所有响应。如果服务器是一个不错的输出缓冲区，它将在响应k完全发送完之前处理请求k + 1。
我能看到的HTTP 1.1的唯一限制是响应必须以接收请求的相同顺序发送，并且不能被交错。但是，如果管道是主要瓶颈，则不太可能成为主要限制，因为它们最终都需要发送。
肯定有几个客户端API涉及发送请求但在收到响应后才返回给调用者的方法，但这是API问题，而不是协议问题。
Http 1.1客户端通常会打开与同一服务器的多个连接以提高速度。如果使用双重缓冲并且管道是瓶颈，那将不会适得其反。但是也许路由器实际上会优先考虑多个TCP连接，但这将消除HTTP 2单连接方法的优势。
我在这里想念东西吗？
HTTP 2的另一个优点是能够主动将内容推送到客户端。但是要使其有效，服务器将需要知道客户端缓存的状态。再次重申，在正常应用中不太可能产生太大变化。最好只有一次往返的时间，通常在初始页面加载时不到10ms。
Google有一些（精心构建的）基准测试，表明SPDY的速度要快得多。但是其他诸如
https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2/
显示微不足道的差异。 （尽管声称只有几个百分点的差异很重要-您无需重新设计协议就可以将性能提高几个百分点。）
所以我要么不理解HTTP 1.1，要么HTTP 2实际上只是复杂性而没有什么好处。
（Web套接字是一个单独的问题。）