When dealing with web performance monitoring or optimization, it is important to learn the fundamentals of the HTTP protocol. The web as we know is built on top of this protocol, which has a large impact on performance of a webpage. Understanding how HTTP works and what each component in an HTTP transaction means, is key to interpreting the data collected by any monitoring service. This post describes the basics of HTTP and is the first of a series on how to diagnose performance problems.
HTTP data rides above the TCP protocol, which guarantees reliability of delivery, and breaks down large data requests and responses into network-manageable chunks. TCP is a “connection” oriented protocol, which means when a client starts a dialogue with a server the TCP protocol will open a connection, over which the HTTP data will be reliably transferred, and when the dialogue is complete that connection should be closed. All of the data in the HTTP protocol is expressed in human-readable ASCII text.
A simple HTTP transaction is one where the client makes a single request for HTTP content.
Persistent connections allow the browser / HTTP client to utilize the same connection for different object requests to the same hostname. The HTTP 1.1 protocol supports persistent connections natively, and does not require any specific HTTP header information. For HTTP 1.0, persistent connections are controlled via the Keep-Alive HTTP header.
The HTTP 1.1 protocol provides browsers with the ability to open multiple connections and perform HTTP requests in parallel. (This is also supported by HTTP1.0 with Keep-Alive but with a slightly different implementation.)
In this example the browser loads an HTML page from hostname.com that contains two image requests to hostname.com and two requests to adserver.com
Once the first request is completed, the subsequent requests are performed in parallel:
Here is a list of the default maximum number of connections per host that can be open in parallel by various browsers. The limits increase over time as newer browsers are released. The more parallel connections, the faster the webpage renders however studies have shown that there might be limits to it – having it at 10 would not necessarily yield better results.
To learn more about this topic, we highly recommend “HTTP: The Definitive Guide” by David Gourley and Brian Totty.
Also watch this video Packet Flight.