Table of Contents
1 Pipeline and Persistent Connection — From rfc2616
1.1 Pipeline
支持持久鏈接 (Persistent Connection) 的客戶端能夠選擇 Pipeline，即同時發送多個請求而無需等待 Server 迴應。而 Server 在接收到這些請求時候必須按照請求的順序來回復。這裏須要注意的是， Pipeline 只能用在持久性連接上，若是 Client 在鏈接是否持久還未可知的時候就去 Pipeline ， Client 本身須要作好重試的準備，且在重試的時候，必須等到確認鏈接的持久性以後再去從新 Pipeline。此外，若是在全部請求都返回以前 server 就關掉了鏈接， Client 也須要從新發送請求 （是否須要重全部請求？？） css
非冪等方法（如 POST等） 不該該被 Pipeline。 java
1.2 Persistent Connection
HTTP/1.1 默認使用持久性鏈接，如非特殊狀況， Client 應該假設 Server 使用持久性鏈接，即使 server 返出錯也應該如此。若是 server 不支持持久性鏈接，server應該在 Http Response 的 Header 中包括 token: "Close" ，而若是 Clinet 不想維護這種鏈接，Client 也能夠用在 Request 的 Header 值聲明 "Close" 。 sql
2 Http Pipeline and libCurl
This contents is from the curl/lib/README.pipelining file. bash
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. app
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. curl
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. ide
Details: post
- 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.