Home > 2issue > Experiential Learning of Networking Technologies- HTTP Protocol Mechanisms for High Performance Applications

Experiential Learning of Networking Technologies- HTTP Protocol Mechanisms for High Performance Applications

Experimenting with Non-persistent and Persistent Connections

 

To gain hands-on experience with persistent connections, we will configure the Apache web server to understand how web servers support such connections. The Apache web server’s configuration directives (which specify how the web server will process web requests) are typically defined in the file/etc/apache2/apache2.conf on an Ubuntu Linux installation. These directives have the format “Name-of-directive Value”. The directive Keep Alive On, which is the default configuration at the time of installation3, tells the web server to allow persistent connections. To configure Apache to use non-persistent connections, edit the configuration file by changing this directive to Keep Alive Off. The two directives discussed below are applicable only for persistent connections (i.e., when the directive Keep Alive On is set). The directive Keep Alive Timeout N specifies the maximum number of seconds N that the web server can wait on a persistent connection for subsequent web requests to arrive before closing the TCP connection.

The default value of N is 5. Similarly, the directive Max Keep Alive Requests M specifies that the web server can serve a maximum of M HTTP requests on a single TCP connection. On the first request served by the server, its response header will contain the value Keep-Alive: max=M, timeout=N. In subsequent requests, the value of the max field will keep decreasing by one. In the last request, the web server will set the response header to Connection: Close.

For our first set of experiments, create a web page named pictures.html with several embedded URLs such, as images. The source code for this page is shown in Listing 1. Deploy this page on the webserver myweb.com (i.e. 10.1.1.1) in its document root (typically in the directory /var/www/html). Choose ten image files img-01.jpg, img-02.jpg,…, img-10.jpg which are embedded in the web page pictures.html and place these within the document root in a folder called img.

Listing 1: A simple HTML web page with embedded images

<!DOCTYPE html>
<html> <body>
<h1>Image Gallery</h1>
<img src=”img/img-01.jpg” />
<img src=”img/img-02.jpg” />
<img src=”img/img-03.jpg” />
<img src=”img/img-04.jpg” />
<img src=”img/img-05.jpg” />
<img src=”img/img-06.jpg” />
<img src=”img/img-07.jpg” />
<img src=”img/img-08.jpg” />
<img src=”img/img-09.jpg” />
<img src=”img/img-10.jpg” />
</body></html>

To study non-persistent connections, first ensure that the Apache web server configuration file has the directive Keep Alive Off. Next, start the Wireshark program 4 either on the client machine or on the web server and select the appropriate network interface (e.g.,eth0 or enp0s5). Since we are interested in observing the number of TCP connections that are established when the web page is served, define the capture filter to capture only TCP SYN packets from the client browser to the web server (e.g., tcp[tcp-flags] & tcp-syn != 0 and dst myweb.com and port 80)5 .This capture filter will only show those SYN packets that are sent by browser client to the web server. Access the web page http:/myweb.com/pictures.html in the client browser (as shown in Figure 3), and stop the Wireshark capture after the page is fully rendered. Since the web page contains 10 embedded images, a total of 11 URLs are accessed whenever the page is rendered. Since the connection is non-persistent, we observe 11 SYN packets as shown in Figure 4.

 

 

 

 

 

 

 

 

Figure 3: Web page with 10 embedded images

 

 

 

 

 

 

 

 

 

 

 

Figure 4: Capture of 11 TCP SYN packets for the page with 10 embedded images

Now restore the following directives in the Apache the web server configuration file to their default values: Keep Alive On, Max Keep Alive Requests 100, and Keep Alive Timeout 5. Restart the web server6 and start a new Wireshark capture with the same capture filter as before. In the Firefox browser, set the number of concurrent persistent connections to 3 (as shown in Figure 2) and reload the web page http://myweb.com/pictures.html. This time, observe that the Wireshark capture only shows 3 SYN packets being sent from client browser to the web server(as shown in Figure 5) to service the 11 accessed URLs7.

To study the impact of the directive Timeout 5, refresh (or reload) the page multiple times within about 4 seconds after the previous rendering of the web page. Observe that no new SYN packets are captured by Wireshark, because refreshing the page is keeping the original TCP connection alive before the timeout expires. To see the impact of this timeout, refresh the web page after 6 seconds and note that Wireshark will indicate that all three TCP connections have been re-established.

 

 

 

 

 

 

 

 

 

 

Figure 5: Packet capture when persistent connections=3

To analyze the maximum number of HTTP requests that can be served on one TCP connection, edit the Apache configuration file and define the directive value as Max Keep Alive Requests 100. Restart the web server and the Wireshark capture, and reload/refresh the web page in the Firefox browser (which is still configured to use 3 concurrent persistent connections). The Wireshark capture will show the setup of 3 TCP connections. Repeatedly refresh this web page every 1 or 2 seconds, and observe that on the fourth refresh, the Wireshark capture will show the setup of 3 new TCP connections (as shown in Figure 6). In this capture, the first 3 connections are started at times00:00:00.000000s, 00:00:00.021872, and 00:00:00.022212. On the fourth successive refresh, the 3 new connections are started after about 7 seconds at times00:00:07.53047s, 00:00:07.55419s, and 00:00:07.55438s.

To understand this behavior, recall that each web page results in 11 URL accesses. Thus, the connection will be closed after serving 11 new web requests on a single TCP connection (because of the directive Max Keep Alive Requests 11), and a new TCP Connection will be established. The Firefox browser initially establishes 3 concurrent TCP connections, which suffices for the first three web accesses. After serving these 33 web requests (a total of 1+10 requests on each TCP connection), the three connections will be closed and three new connections will be established8.

 

 

 

 

 

 

 

 

 

 

Figure 6: Capture of new connections created when the Max Keep Alive Requests limit is reached

As mentioned earlier, the web server’s response headers contain a count-down of the number of requests that can be serviced with the current TCP connection. To observe this, restart the Wireshark capture with a filter to capture all packets that are exchanged between the client and the server (e.g.,host 10.1.1.101 and host myweb.com and port 80). Select any TCP packet, right click on it, and select Follow → TCP Stream as shown in Figure 7. This opens a window which shows all HTTP requests served on this TCP Connection. Observe that the value of the max field in the HTTP header Keep-Alive decreases for each subsequent request, and the last request has the response header Connection: Close. To develop a better understanding of persistent connections, repeat the experiment with this setup:
 
i. Create a simple web page with n embedded URLs.
ii. Configure the Firefox browser with the number of concurrent persistent connections to c.
iii. Configure the web server with Max Keep Alive Requests M.
iv. Configure Wireshark to record all TCP SYN packets from the client browser to the web server when the web page is loaded, and let this number be t.
 
Predict the relationship between the four values n, c, M and t and test your prediction empirically using the strategy presented here. Repeat this exercise with other browsers as well.

 

 

 

 

 

 

 

 

 

 

Figure 7 : Identify ingall HTTP Request on a TCP Connection

[3] The location of this configuration file may vary depending upon the installation setup.

[4] This will require sudo/root/privileges.

[5] These packets indicate the starting of a TCP Connection. A more detailed view on terminal window can be obtained with the tcpdump utility program: sudo tcpdump -n -i etho -ttttt ‘tcp[tcpflags] & tcp-syn !=0 and dst 10.1.1.1 and port 80’

[6] use the command: sudo service apache2 restart

[7] It is possible that these 11 request are not distributed as fairly among the 3TCP connections as shown here.

[8] It is possible that distribution of the 33 web requests across the three TCP connections is non-uniform. In this case, the three new connections may not be established at approximately the same time as shown here – there may be noticeable lags between creation times.

 

Leave a Comment:

Your email address will not be published. Required fields are marked *