Daren Matthews

Browsers can setup two or more TCP connections to an HTTP server to facilitate parallel downloads. As the browser parses the Web page it is aware of which objects it needs to download.

Rather than send the requests in series over a single connection, the requests are sent over parallel connections to enable faster downloading of the Web page. Another technique used by browsers to improve the performance is “HTTP pipelining”.

• Without pipelining, the client first sends a request to the server and waits for a reply before sending the next request. If there are two parallel connections, then a maximum of two requests are sent to the server concurrently.
• With pipelining, the browser sends the requests in batches instead of waiting for the server to respond to each individual object before sending the next request. Pipelining is used with a single HTTP connection or with multiple HTTP connections.

HTTP “pipelining” can be used by browsers to make multiple http requests for separate TCP connections to a web server. Depending on network latencies and bandwidth limitations, this can result in a significant delay before the next request is seen by the server:

HTTP/1.1 allows multiple HTTP requests to be written out to a socket together without waiting for the corresponding responses. The requestor waits for the responses to arrive in the order in which they were requested. The act of pipelining the requests can result in a dramatic improvement in page loading times, especially over high latency connections.

You may think that setting “network.http.pipelining.maxrequests” value to a very high number, to make multiple http requests would be advantageous but there are some browser limitations. For example Firefox is limited to send 8 requests at once.

Connection Jumping:
This is when the browser establishes the second, or subsequent, TCP connections for the parallel or pipelining downloads, it does not remember if the server requires authentication.

Therefore, the browser sends multiple GET requests over the second, or additional, TCP connections, without the authentication header. The server rejects the requests with the 401 Unauthorized messages.

When the browser receives the “401 Unauthorized” message on the second connection, it is aware that the server requires authentication. The browser initiates the authentication process. Yet, instead of keeping the authentication requests for all the previously requested objects on the second connection, some of the requests jump over the first and are authenticated:

1. The client authenticated with the server and the client request for the index.html Web page. It parses the Web page and initiates a second connection for parallel download:

2. The client the pipelines the requests to download objects 1.jpg, 2.jpg, and 3.jpg on the second connection. However, because the server requires authentication, the requests for those objects are all rejected:

3. The client sends the authentication request to the server. Instead of keeping the requests on the second connection, some of the requests have jumped over to the first, and an already authenticated, connection:

Some problems may arise as a result of this connection jumping behavior:

• If an authentication request appears on an already authenticated connection, the server can reset the state of the connection and force it to go through the entire authentication process again.
• The browser has effectively turned this into a per-request authentication even though the server can support per-connection authentication.

Note: Connection jumping is specific behavior to Internet Explorer, unless you are using Internet Explorer 8 with Windows 7.

Considerations:

• BETTER USER EXPERIENCE: If the bandwidth permits it can have a positive effect on the user experience and speed up browsing significantly.
• MORE TRAFFIC ON NETWORK: Be aware that setting this value in a corporate website policy will result in an increased load on your network.
• NETWORK ROUTING: Out-of-order delivery may occur when sequenced packets arrive out of order. This could be due to different paths taken by the packets or from packets being dropped and resent.
• CAUTION:  Being able to increase this setting also affects internet browsing – be careful that you dont have your IP banned from any websites!
• RIVERBED STEELHEAD WAN: If you use Riverbed Steelhead WAN Accelerators navigate to the Strip Auth Header section in “HTTP Authentication Optimization” and examine this if you have any problems with per-object or per-session authentication.
• SWITCH FABRIC: Avoid Head-of-line blocking (HOL blocking) which is a performance-limiting phenomenon occurring when a line of packets is held-up by the first packet, as is the case with multiple requests in HTTP pipelining (see “ON THE NETWORK” below):

ON THE NETWORK:
For a Cisco based network you can try to mitigate HOL blocking:

Head-of-line blocking example: The 1st and 3rd input flows are competing to send packets to the same output interface. In this case if the switching fabric decides to transfer the packet from the 3rd input flow, the 1st input flow cannot be processed in the same clock cycle. Note that the 1st input flow is blocking a packet for output interface 3, which is available for processing.
(image source: WikiPedia)

– Try to overcome the limitation by using Virtual Output Queues (only switches with input buffering can suffer HOL blocking). With sufficient internal bandwidth, input buffering is unnecessary; all buffering is handled at outputs and HOL blocking is avoided;

A quick web search reveals that:
– The Cisco Nexus 5500 platform implements virtual output queues (VOQs) on all ingress interfaces.
– The Cisco ACE management class map supports virtual output queuing (VoQ)
– The Cisco® MDS 9000 Family supports virtual output queues for each output port
– I am sure that there are others and other vendors supporting VOQs.

ON THE SERVER:
There is the concept of per-request and per-connection authentication with HTTP authentication. A server configured with per-request authentication requires the client to authenticate every single request before the server delivers the object to the client.

If there are 100 objects (for example, .jpg images), it performs authentication 100 times with per-request authentication. With per-connection authentication, if the client only opens a single connection to the server, then the client only needs to authenticate with the server once and no further authentication is required.

When the browser first connects to the HTTP server and the server requires authentication, the server responds with a “401 Unauthorized message”:

In the body of the message, the server indicates what kind of authentication scheme it supports in the “WWW-Authenticate: Negotiate” line:

• – If the server supports more than one authentication schemes there will be multiple WWW-Authenticate lines in the body of the message.
• – If a server supports both Kerberos and NTLM, the following appears in the message body:WWW-Authenticate: NegotiateWWW-Authenticate: NTLM
• – When the browser receives the Negotiate keyword in the WWW-Authenticate line, it first tries Kerberos authentication. If Kerberos authentication fails, it falls back to NTLM authentication.
  – Read this post which describes Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO): http://darenmatthews.com/blog/?p=1485

Web servers permitting per-request or per-connection authentication is software dependant. Microsoft’s IIS server default is per-connection authentication when using NTLM authentication and per-request authentication when using Kerberos authentication.

SETTING UP PIPELINING ON THE BROWSER:
Firefox browser:

Open a new tab (Ctrl+T) and type “about:config” (without the quotes) in the address bar.

In the “Filter:” search box, type “network.http” (without the quotes.)

Examine the “network.http.keep-alive” setting and make sure it’s set to “true”. If “false,” then double-click and change to true.
Also look check that “network.http.version” is set to “1.1″

In the “Filter:” search box, type “pipelining” (without the quotes.)

Find “network.http.pipelining” then Right-click on the line and click on “toggle” – ensure that the value is set to “true” (or double-click to toggle values.)
If you use a proxy, find “network.http.proxy.pipelining” Right-click on the line, and click “toggle”.  Ensure that it is set to “true”. (Or if you are unsure of whether you use a proxy set it to “true” anyway).
Find “network.http.pipelining.maxrequests” Right-click on that line, click on “modify” and set the value to 8. You can set it anywhere between 1 and 8. If you notice problems try decreasing this value.

Other values to explore:
Creation of a new value “nglayout.initialpaint.delay” with the value to “0”. – To display the information on the webpage sooner. nglayout.initialpaint.delay may make your page load more slowly especially on slower internet connections.