- Introduction
- Creating the Session
- Downloading the Data
- Persistent Connections and Pipelining
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Persistent Connections and Pipelining
The scenario described in the preceding section was somewhat over-simplified; three additional parameters influence the delay introduced by HTTP:
- Parallel sessions. Web browsers can open multiple parallel TCP sessions to the same web server, thus reducing the impact of the propagation delay. (Obviously, serialization delay is not reduced.)
- Persistent connections. The TCP session between the client and the server could be used for multiple requests. If either end doesn't support persistent connections, a new TCP session has to be created for every request.
- Pipelining. Web browsers are allowed to send multiple requests back-to-back, further reducing the propagation delay (see Figure 3).
)
Parallel Sessions
Parallel sessions are server-independent; whether to use them is a decision made solely by the browser. By default, most popular browsers (including Internet Explorer and Firefox) use two parallel sessions toward each web server. As the web designers, programmers, and server administrators cannot influence this setting, we won't discuss it any further. However, you can increase the number of parallel sessions if you download auxiliary page components (for example, images and stylesheets) from a different hostname (even though it points to the same physical server).
Persistent Connections
Persistent connections are supported by all modern web browsers and servers, but they might not be operational. For example, if you set the KeepAlive setting of the Apache server to Off, the server will close the HTTP session after each request, resulting in additional RTT relay for each page component. The HTTP Keep-Alives Enabled setting in IIS's website properties has the same function.
Persistent connections work well if the web server can indicate actual content length in the HTTP header, enabling the web client to determine when the current request has completed. This might not be possible if the server-side script generates dynamic content and disables output buffering; the only solution in this case is termination of the TCP session at the end of the HTTP response. New versions of the Apache server correctly handle dynamic content generation with HTTP chunked encoding, and IIS tries hard to calculate correct content-length even for ASP scripts. (You also can enable HTTP chunked encoding with IIS.)
Some web servers might decide to limit the number of HTTP requests accepted over each HTTP session. Widely used web servers (Apache and IIS) have large defaults, but other web servers might not be as considerate; for example, by default the Lotus Domino web server closes the HTTP session after five requests. When loading a web page with 50 components (unfortunately not unheard of), this behavior introduces several seconds of delay for the transatlantic visitor, just due to TCP session setup times.
Pipelining
A web browser supporting pipelining sends multiple HTTP requests back-to-back and properly handles the back-to-back response received from a web server. Although this technology significantly reduces the impact of the propagation delay, it's not supported by Internet Explorer and is disabled by default on Firefox (and is thus unusable from the perspective of the web administrator).
Takeaway point: Persistent connections improve website performance and should be used whenever possible.