Keyboard shortcuts

Press ← or β†’ to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

🏠 Back to Blog

Chapter 11

HTTP Pipelining

HTTP Pipelining is a technique used in the HTTP protocol to allow multiple requests to be sent by the client without waiting for a response from the server. The server can respond to these requests in any order, and the client can process the requests as they arrive. HTTP pipelining adoption has remained very limited despite it’s many benefits. This is because of several drawbacks:

  1. A single slow response blocks all requests behind it
  2. When processing requests in parallel, servers must buffer all responses behind the current response. This could lead to resource exhaustion on the server as buffers grow larger and larger.
  3. A failed response may terminate the TCP connection, causing the client to retransmit the request. This could lead to duplicate request processing on the server.
  4. Intermediary devices in the network hop path can cause issues, and compatibility with Intermediary devices is hard to detect. One way around this is to use a secure tunnel, which prevents intermediary devices from reading/modifying the connection.

Head of Line Blocking

Head of Line blocking can be caused by HTTP pipelining. With HTTP Pipelining, the server processes requests in the order they are received. If a particular request takes a long time to process, the responses for other requests will be blocked.

Headers

  • Headers remain unmodified and are always sent as plain text to remain compatible with previous versions of HTTP. Headers were introduced in HTTP 1.0. Headers typically add 500-800 bytes to the total payload. However, cookies can make them dramatically larger. RFC 2616 does not define a limit on the size of HTTP headers. However, many servers and proxies will try to enforce either an 8 KB or 16 KB limit.
  • The growing list of headers is not bad in and of itself. However, the fact that all HTTP headers are transferred in plain text (without compression) can lead to high overhead costs for each and every request.
  • In the example below, we can see that our headers make up 157 bytes of the payload, while the content itself only takes up 15 bytes.
$ curl --trace-ascii - -d'{"msg":"hello"}' http://www.igvita.com/api

== Info:   Trying 173.230.151.99:80...
== Info: Connected to www.igvita.com (173.230.151.99) port 80 (#0)
=> Send header, 157 bytes (0x9d)
0000: POST /api HTTP/1.1
0014: Host: www.igvita.com
002a: User-Agent: Mozilla/5.0 Gecko
0049: Accept: */*
0056: Content-Length: 15
006a: Content-Type: application/x-www-form-urlencoded
009b: 
=> Send data, 15 bytes (0xf)
0000: {"msg":"hello"}

Concatination and Spriting

  • Concatination is the ability for HTTP 1.x to bundle multiple JavaScript or CSS files into a single resource
  • Spriting is the ability for multiple images to be combined into a larger, composite image and sent via a single response.