Http-Burst: Improving HTTP Efficiency in the Era of Bandwidth Hungry Web Applications

Http-Burst: Improving HTTP Efficiency in the Era of Bandwidth Hungry Web Applications

Martin Lévesque
Corresponding author: Martin Lévesque, email: School of Information Sciences
University of Pittsburgh
Pittsburgh, PA, USA

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.

I Introduction

The Hypertext Transfer Protocol (HTTP) [1], 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[5], 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 [6]. 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 [7]. 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 [8]. 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 [9]. Since 1995 up to now, the number of inlined objects per webpage has significantly increased, as depicted in Fig. [10], from few objects to more than 100 objects in 2014. In [9], 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.

Fig. 1: Evolution of the average page size and number of objects from 1995 to 2014 [10].

In this paper, we propose the BURST method, which is somewhat a variant of the GETALL method proposed in [9]. 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, 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 [11]. 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.

(a) Desktop.
(b) Mobile.
Fig. 2: HTTP average object size per content type (June 2015) [11].

If we look more specifically on the webpages generated for desktops (Fig. 1(a))), the two average largest content type sizes are originating from images and scripts (e.g., Javascript files). On the mobile counterpart (Fig. 1(b))), the average content sizes are reduced, mainly according to the images, scripts, and fonts sizes.

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.

Fig. 3: Average page size and number of objects from 2010 to 2015 [11].

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.

(a) HTTP requests per page.
(b) Transmitted MB per page (including all objects).
Fig. 4: HTTP requests and transmitted KB per page (June 2015) [11].

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.

(a) Images per page.
(b) Images size per page (including all images).
Fig. 5: Number and total size of images per page (June 2015) [11].

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 [1]. 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: 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.

Fig. 6: HTTP example execution of one HTML file containing four images using the GET method ().

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 .

Iii-B Delay

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.

Iv HTTP-Burst

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.

Fig. 7: HTTP-Burst example execution of one HTML file containing four images using the BURST method ().
Fig. 8: HTTP-Burst example execution of one HTML file containing four images using the BURST method ().

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 .

Fig. 9: Maximum efficiency, .

Iv-B Delay

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 section, we experimentally demonstrate the potential of the proposed BURST method for HTTP. We made a proof-of-concept (POC), using HTTP GET requests. The source code we used is available online222POC source code: The scenario we investigate is as follows. We configured a virtual private server (VPS) with lighttpd333lighttpd:, which is a light and efficient HTTP server. The VPS has 1 GB random access memory (RAM), and does not experience any external requests except the ones received for this given experience. The experiment we consider consists of measuring the total request duration of retrieving an HTML document and its embedded objects. The HTML document contains a font of 44 KB, a CSS file of 120 KB, a javascript (jquery) file of 84 KB, and a variable number of images (). Each request originates from a client located in Pittsburgh, PA, USA, and the VPS server is located in Dallas, Texas, USA.

Fig. 10 compares HTTP using GET requests and the proposed HTTP-Burst protocol, with , which is the maximum allowed number of parallel connections. We vary the number of images, where the number of objects corresponds to the number of images, CSS, javascript, and font files. For each given number of images, we process the request 10 times, and we record the mean and standard deviation. On Fig. 10, we thus plot the mean and the standard deviation to illustrate the fluctuations. For each request, the total request duration is recorded, which corresponds to the time duration from the HTML request sending to the reception of all retrieved objects. We observe that for HTTP, the request duration grows from 0.5 second to approximately 2.5 seconds. With HTTP-Burst, however, similar request duration are experienced for low number of objects. For larger number of objects (more than 30), HTTP-Burst outperforms the performance of the regular HTTP protocol. For instance, with HTTP-Burst and , even with 150 objects, the request duration is approximately as low as 1.2 seconds, compared to 2.5 seconds with HTTP GET requests. With HTTP-Burst and , the total request duration is worse compared with for low number of objects. However, as the number of objects increases, HTTP-Burst with still outperforms the regular HTTP protocol using GET requests. In terms of percentage improvement with the largest number of objects, 150, and HTTP-Burst with and , improvements of and are obtained, respectively.

Fig. 10: Experimental measurements of the total request duration.

Vi Conclusions

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.


  • [1] 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.
  • [2] N. Niclausse, Z. Liu, and P. Nain, “A New Efficient Caching Policy for the World Wide Web,” 1997.
  • [3] 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.
  • [4] M. Abrams, C. R. Standridge, G. Abdulla, S. Williams, and E. A. Fox, “Caching Proxies: Limitations and Potentials,” 1995.
  • [5] 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.
  • [6] B. D. Davison, “A Web Caching Primer,” Internet Computing, IEEE, vol. 5, no. 4, pp. 38–45, 2001.
  • [7] 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.
  • [8] 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.
  • [9] V. N. Padmanabhan and J. C. Mogul, “Improving HTTP Latency,” Computer Networks and ISDN Systems, vol. 28, no. 1, pp. 25–35, 1995.
  • [10] Average Web Page Breaks 1600K. [Online]. Available:
  • [11] Http Archive Stats. [Online]. Available:
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
Add comment
Loading ...
This is a comment super asjknd jkasnjk adsnkj
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test description