超高性能管线式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的模式详细是什么边幅的。

（编辑：湖南网）

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