For Developers‎ > ‎Design Documents‎ > ‎Network Stack‎ > ‎

HTTP Pipelining

Objective

Speed up Chrome's network stack by enabling HTTP Pipelining. Pipelining issues multiple requests over a single connection without waiting for a response.

Risks

  • Broken servers. Servers may ignore pipelined requests or corrupt the responses.
  • Broken proxies. May cause the same problems. Some users are behind "transparent proxies," where the requests are proxied even though the user has not explicitly specified a proxy in their system configuration.
  • Front of queue blocking. The first request in a pipeline may block other requests in the pipeline. The net result of pipelining may be slower page loads.

Mitigation

Response headers must have the following properties:
  • HTTP/1.1
  • Determinable content length, either through explicit Content-Length or chunked encoding
  • A keep-alive connection (implicit with HTTP/1.1)
  • No authentication
Pipelining does not begin until these criteria have been met for an origin (host and port pair). If at any point one of these fail, the origin is black-listed in the client. If an origin has successfully pipelined before, it is remembered and pipelining begins immediately on next use.

Experimentation

Manual Opt-in

Pipelining is available on all platforms in about:flags starting with Chrome 18. It is disabled by default.

Proxy Compatibility Field Trial

1% of canary channel users who've opted in to reporting usage statistics will be used for a field trial. The field trial runs in the background. Once per session it will issue a few test requests to 70.32.157.91 or 70.32.157.92. These servers are owned and operated by Google. They run a simple HTTP pipelining test server. The stats are recorded in Chrome and reported to Google using the existing Chrome histogram system.

In the future, more users will be included in this field trial.
Comments