Http-Burst: Improving HTTP Efficiency in the Era of Bandwidth Hungry Web Applications
The Hypertext Transfer Protocol (HTTP), a key building block of the World Wide Web, has succeeded to enable information exchange worldwide. Since its first version in 1996, HTTP/1.0, the average number of inlined objects and average total bytes per webpage have been increasing significantly for desktops and mobiles, from 1-10 objects in 1996 to more than 100 objects in June 2014. Even if the retrieving of inlined objects can be parallelized as a given Hypertext Markup Language (HTML) document is streamed, a maximum number of connections is allocated, and thus as the number of inlined objects increases, the overall webpage load duration grows, and the HTTP servers loading also gets higher. To overcome this issue, we propose a new HTTP method called BURST, which allows to retrieve the missing inlined objects of a webpage efficiently by requesting sets of web objects. We experimentally demonstrate the potential via a proof-of-concept demonstration, by comparing the regular HTTP to proposed HTTP-Burst using a virtual private server and real HTTP client and server over the Internet. The results indicate a latency reduction of webpage load duration compared to HTTP as high as 52 % under the considered configurations.
The Hypertext Transfer Protocol (HTTP) , which first version was established in 1996, is a key building block protocol in the Internet. HTTP works on a request-responce manner, where the GET, POST, PUT, and DELETE are the most commonly used methods. The most frequent method from an end-user standpoint is the GET method, which retrieves a web document from an HTTP server. A typical document type is the HyperText Markup Language (HTML), which contains HTML elements as well as reference to external objects, the so-called inlined objects. Each of those inlined objects are retrieved via successive GET requests, typically in parallel as the HTML document is obtained.
Several different optimization techniques have been proposed to improve the HTTP performance, from the client, network, and server viewpoints in order to minimize the request latency. To avoid fetching two times the same exact document, the end-user can store locally the document, which is possible by using a local cache. Proxy web caches are also widely used, where an intermediate node between the clients and server stores frequently used documents [2, 3, 4]. Caching can also be done on the server side, mainly to decrease the request computation duration especially when complex calculations or database queries are executed. Web caching on the server side is frequently done by saving content in memory for fast lookup . A typical performance metric used in web caching is the hit rate, which corresponds to the ratio of the number of requests using the cache over the number of requests.
Other improvement techniques focused on the exchanged HTTP messages. For instance, the HTTP data can be compressed to reduce the transmitted bytes . Further, it is worth noting that HTTP works by maintaining Transmission Control Protocol (TCP) connections. HTTP 1.1, as opposed to HTTP 1.0, introduced the persistent connections (HTTP Keep-alive), allowing to make multiple HTTP requests/responses over the lifetime of a given connection. This mechanism significantly reduces the overhead, as verified in . It thus improves the transport layer communications for the HTTP traffic.
All of these techniques improve the request-response latency. It is worth nothing that the HTTP request-response latency performance highly depends on the number of inlined objects (e.g., images, fonts, etc.) to retrieve . Since 1995 up to now, the number of inlined objects per webpage has significantly increased, as depicted in Fig. , from few objects to more than 100 objects in 2014. In , the authors measured this issue in the early HTTP version and proposed new methods, GETALL and GETLIST. GETALL, as opposed to the GET method, requests to retrieve a given document and its inlined objects for improved efficiency.
In this paper, we propose the BURST method, which is somewhat a variant of the GETALL method proposed in . However, rather than requesting the document and all inlined objects, the proposed extension first requests the document and then the missing inlined objects, and it allows to have multiple BURST requests to be sent in parallel to decrease latency.
This paper is structured as follows. In Section II, we overview the HTTP traffic trends to motivate the proposed method. In Section III, we describe the overall HTTP protocol and propose an extension in Section IV. In Section V, we investigate experimentally the proposed method and compare it to the regular HTTP protocol. Section VI finally draws some conclusions.
Ii HTTP Traffic Trends
In this section, we overview the trends of the traffic generated by HTTP-based web applications. In 1996, httparchive.org was founded, aiming at keeping snapshots of the websites evolution by archiving the different versions of webpages over time. More interestingly for the scope of this paper, statistics can be generated of the HTTP-based Internet traffic . We are interested to look at the traffic, in average, generated by a webpage. Fig. 2 depicts the total average size in June 2015 of an accessed webpage, namely 2.1 MB (Fig. 1(a))) from desktops and 1.18 MB (Fig. 1(b))) from mobile devices. Note that it does not take into account the scenario of a webpage where a given client has cached objects from previous requests, but illustrates the scenario where a user first access a given website/webpage without saved objects. Further, Fig. 2 illustrates the average data size for the main downloaded object types while loading a page.
One could however wonder how did the total webpage size has evolved since 1995 and beyond. In Fig. 2, one can observe that the average webpage size has been growing since 1995 until now, and will more likely continue to grow given this trend. More specifically, the average webpage size has been growing significant since 2010, perhaps related to the economic growth that followed the economic crisis of 2008.
It is worth noting that an HTTP page load, which we will briefly overwiew in the next section, basically consists of an HTML document request, followed by successive object file requests for images, scripts, etc. Fig. 4 depicts the averages total number of requests and total bytes a webpage is creating. Approximately 75 % of webpage loads require between 1 and 125 HTTP requests, which is quite significant, given that each given HTTP request further generates overhead from the IP and TCP layers, as well as increasing server loading.
If we look in Fig. 4(b)) at the content type generating the largest amount of traffic, the images, we observe that 85 % of webpages contain between 1 and 80 images.
If we multiply the ratios to the number of requests in Fig. 3(a)), approximately 91 requests are generated per webpage load. In the following, we overview HTTP to outline the consequence of having such a growing amount of requests.
Iii Hypertext Transfer Protocol (HTTP)
The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed and collaborative information systems, which is one of the most widely used protocol in the Internet . HTTP has a variety of request methods, including GET, HEAD, POST, and DELETE. The GET method is the most widely used method, which role is to retrieve a specified resource, while the POST method is used to for instance in web forms to submit data entities. Fig. 6 depicts an HTTP GET example of a script request (file.php) containing four images. In the example, a maximum of two files can be transferred in parallel. Note that the number of parallel connections vary depending on the web browser, from 6 in Chrome and Firefox up to 13 in Internet Explorer 11 111Browserscope web browsers profiling: http://www.browserscope.org/?category=network.. For each given request, TCP acknowledgement (ACK) packets are generated for confirmation. Therefore, as the number of objects in requested webpages increases, the experienced overhead grows.
Iii-a Maximum Efficiency
As we illustrated in the previous section, the number of objects per webpage is significantly increasing over time since 1995. Let us consider objects (scripts, images, videos, etc.) included in a given webpage. Each object size corresponds to (in bytes) such that . An HTTP request for a given object thus totals the following minimum amount of bytes:
where and corresponds to the Internet Protocol (IP) and Transmission Control Protocol (TCP) header sizes, the size of the HTTP request excluding the payload of bytes, and corresponds to the TCP ACK packet generated from the HTTP server to a given client. For instance, the IPv4 and TCP headers correspond to 20 bytes each. is counted twice due to the request and response messages. Note that, on the top of this, the link layer (e.g., Ethernet) also adds extra overhead which we do not take into account for improved readability. Therefore, the maximum efficiency is given by:
Thus, as the number of objects increases, the overhead data size increases. For instance, if the average object size corresponds to 200 bytes with , then the maximum efficiency is .
In terms of delay, the number of objects has a major impact on the webpage load time, which corresponds to:
where and correspond to the delay between the client and server, and inversely. corresponds to the processing delay at the server to process object . Note that this delay is correct if a single connection is used, which is usually not the case. If the browser uses connections, then the delay corresponds to:
It is clear that the webpage load time grows as the number of objects increases. To overcome this shortcoming, we propose HTTP-Burst in the following section.
For improved efficiency, we propose to transfer all missing objects, not stored in a local cache, in a single request as a burst using a new BURST method, as illustrated in Fig 7. In such a scheme, when the GET method has been completed and the HTTP client has completely received the HTML content, one or many BURST requests are sent each containing a set of objects to retrieve from the HTTP server, for example to retrieve four images, img1.jpg, …, img4.jpg with a single connection () as in Fig 7. Then, the HTTP server transmits all requested files in concatenated HTTP messages. As we can see, a significantly lower number of requests is being exchanged between the client and server, compared to using successive GET requests (Fig 6). Fig. 8 depicts the same example, but with two connections, . When two connections are used, the two BURST requests are sent to retrieve the object files. Therefore, each BURST requests for two objects.
Iv-a Maximum Efficiency
To compare with HTTP, the maximum efficiency using the BURST method is given by:
Thus, the efficiency is clearly improved, as the TCP/IP overheads are counted maximally times instead of . Fig. 9 depicts the maximum efficiency with a fixed payload of 1400 bytes. The efficiency is similar for both only when the number of objects corresponds to .
In terms of delay, it is definitely improved since few two-way communications exchanges are done:
where is the BURST connection identifier, .
Further, as the number of requests is reduced, processing only HTTP request instead of definitely reduces the server load.
V Experimental Results
In this paper, we first overviewed the HTTP traffic trends. The average webpage size and number of objects per webpage have continuously increased since 1995. In 2015, the average number of objects per webpage for desktops has reached 200 objects. Even if objects can be retrieved with parallel TCP connections, the increasing number of objects causes significant overhead both from the network and server viewpoints. To overcome this issue, we proposed HTTP-Burst, which, instead of sending HTTP requests for all objects, retrieves webpage objects as bursts via the proposed BURST method, where objects are grouped for improved efficiency. We experimentally investigated the proposed scheme by comparing it to using sucessive HTTP GET requests. The results shown a reduction of as much as 52 % of the total request duration under the considered configurations, thus illustrating the potential of the proposed protocol extension. In future work, we will look at the principal overhead causes and experiment the scheme under different conditions.
-  R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, “Hypertext Transfer Protocol–HTTP/1.1,” 1999, RFC 2616.
-  N. Niclausse, Z. Liu, and P. Nain, “A New Efficient Caching Policy for the World Wide Web,” 1997.
-  P. Cao, J. Zhang, and K. Beach, “Active Cache: Caching Dynamic Contents on the Web,” Distributed Systems Engineering, vol. 6, no. 1, p. 43, 1999.
-  M. Abrams, C. R. Standridge, G. Abdulla, S. Williams, and E. A. Fox, “Caching Proxies: Limitations and Potentials,” 1995.
-  S. Sivasubramanian, G. Pierre, M. van Steen, and G. Alonso, “Analysis of Caching and Replication Strategies for Web Applications,” Internet Computing, IEEE, vol. 11, no. 1, pp. 60–66, 2007.
-  B. D. Davison, “A Web Caching Primer,” Internet Computing, IEEE, vol. 5, no. 4, pp. 38–45, 2001.
-  Z. Liu, Y. Saifullah, M. Greis, and S. Sreemanthula, “HTTP Compression Techniques,” in Wireless Communications and Networking Conference, 2005 IEEE, vol. 4. IEEE, 2005, pp. 2495–2500.
-  H. F. Nielsen, J. Gettys, A. Baird-Smith, E. Prud’hommeaux, H. W. Lie, and C. Lilley, “Network Performance Effects of HTTP/1.1, CSS1, and PNG,” in ACM SIGCOMM Computer Communication Review, vol. 27, no. 4. ACM, 1997, pp. 155–166.
-  V. N. Padmanabhan and J. C. Mogul, “Improving HTTP Latency,” Computer Networks and ISDN Systems, vol. 28, no. 1, pp. 25–35, 1995.
-  Average Web Page Breaks 1600K. [Online]. Available: http://www.websiteoptimization.com/speed/tweak/average-web-page/
-  Http Archive Stats. [Online]. Available: http://httparchive.org/interesting.php