Http PipeLining

Pipeline and Persistent Connection — From rfc2616
Http Pipeline and libCurl

1 Pipeline and Persistent Connection — From rfc2616

1.1 Pipeline

支持持久连接 (Persistent Connection) 的客户端可以选择 Pipeline，即同时发送多个请求而无需等待 Server 回应。而 Server 在接收到这些请求时候必须按照请求的顺序来回复。这里需要注意的是， Pipeline 只能用在持久性链接上，如果 Client 在连接是否持久还未可知的时候就去 Pipeline ， Client 自己需要做好重试的准备，且在重试的时候，必须等到确认连接的持久性之后再去重新 Pipeline。此外，如果在所有请求都返回之前 server 就关掉了连接， Client 也需要重新发送请求 （是否需要重所有请求？？）

非幂等方法（如 POST等）不应该被 Pipeline。

1.2 Persistent Connection

HTTP/1.1 默认使用持久性连接，如非特殊情况， Client 应该假设 Server 使用持久性连接，即便 server 返出错也应该如此。如果 server 不支持持久性连接，server应该在 Http Response 的 Header 中包括 token: "Close" ，而如果 Clinet 不想维护这种连接，Client 也可以用在 Request 的 Header 值声明 "Close" 。

2 Http Pipeline and libCurl

This contents is from the curl/lib/README.pipelining file.

2.1 Background

Since pipelining implies that one or more requests are sent to a server before the previous response(s) have been received, we only support it for multi interface use.

2.2 Considerations

When using the multi interface, you create one easy handle for each transfer. Bascially any number of handles can be created, added and used with the multi interface - simultaneously. It is an interface designed to allow many simultaneous transfers while still using a single thread. Pipelining does not change any of these details.

2.3 API

We've added a new option to curl_multi_setopt() called CURLMOPT_PIPELINING that enables "attempted pipelining" and then all easy handles used on that handle will attempt to use an existing pipeline.

Details:

A pipeline is only created if a previous connection exists to the same IP address that the new request is being made to use.
Pipelines are only supported for HTTP(S) as no other currently supported protocol has features resemembling this, but we still name this feature plain 'pipelining' to possibly one day support it for other protocols as well.
HTTP Pipelining is for GET and HEAD requests only.
When a pipeline is in use, we must take precautions so that when used easy handles (i.e those who still wait for a response) are removed from the multi handle, we must deal with the outstanding response nicely.
Explicitly asking for pipelining handle X and handle Y won't be supported. It isn't easy for an app to do this association. The lib should probably still resolve the second one properly to make sure that they actually can be considered for pipelining. Also, asking for explicit pipelining on handle X may be tricky when handle X get a closed connection.

Table of Contents