超高性能管线式HTTP请求（实践·原理·实现）

测试数据设置如下

请求量还是10000条接收的response数据大概有326Mb 30s之内完成。基本上是网络的极限，此时cpu也基本无然后压力(100条管线，每条100个请求)。

这里其实请求是带时间戳的，因为测试时使用的是同一个时间戳，所以实际对应用服务器的影响不大，真实测试时可以为每条请求设置不同时间戳(这里是因为要演示使用了线上公开服务，测试时请使用测试服务)。

注意，这里的测试如果选择了性能较低的测试对象，大部分流量会在服务器端排队等候，导致吞吐量不大，这实际是服务器端处理过慢，与客户端关系不大。

一般情况下一台普通的pc在使用pipe进行测试时就可以让服务器出现明显延时。

原理

正常的http一般实现都是连接完成后(tcp握手)发生request流向服务器，然后及进入等待，收到response后才算结束(如下图)：

当然http1.1 即支持keep alive，完成一次收发后完全可以不关闭连接使用同一个链接发生下一个请求(如下图)：

这种方式对性能的提升还是比较明显的，特别早些年服务器性能有限，网络资源匮乏，RTT大(网络时延大)。不过对如今的情况，其实这些都已经不是最主要的问题了。

可以明显看到上面的模式，是一定要等到response到达后，客户端才能发起下一个request的，如果应用服务器需要时间处理，所有后面的请求都需要等待，即使不需要任何处理直接回复给客户端，请求，回复在网络上的时间也是必须完整的等下去，而且由于tcp传输本身的特性，速率是逐步上升的，这样断断续续的发送接收十分影响tcp迅速达到线路性能最大值。

pipe (管线式)正是回避了上面的问题，他不需要等回复达到即可直接发送(事实上http1.1协议也从来没有讲过必须要等response到达后客户端才能发送下一个请求，只是为了方便应用层业务实现，一般的http库都是这样实现的，而现在看到的绝大多少http服务器都是默认支持pipe的)，这样发送与接收即可以分离开来(如下图)：

在事实情况下，发生可能会比这个图表现的更快，请求1，2，3，4很可能被放到一个tcp包里被一次性全部发出去(这种模式也给部分应用带来了麻烦，后面会讲到)。

对于pipe相对真实的情况如上图，多个请求会被打包在一起被发送，甚至有时是所有request发送完成后，服务器才开始回复第一个response。

而普通的keepalive的模式如上图，一条线代表一个请求，不仅一次只能发送一个，而且必须等待回复后才能发下一个。

下面看下实际测试中pipe的模式具体是什么模样的。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!