Performance Mechanisms for Partial Content Delivery
The Content-Length header in the web server’s response specifies the total response size, and by default the browser renders the content only after it is received in its entirety. When a web request results ina large response size (e.g., a high-resolution image, a large table in response to a database query, etc.), it may take significant time for the client to receive the full content. During this time, the browser will not display any partially-received content. Thus, even though the browser and the web server are actively communicating, the user may feel that the web server is unresponsive. To enhance the user experience, it is desirable to render partial content when possible. For example, the initial rows of image pixels or the first few query results could be displayed.To support this type of continuous content rendering, HTTP/1.1 supports the concept of chunk-based transfer, specified with the header Transfer-Encoding: chunked. This header is infrequently used in HTTP requests, but it is commonly used in HTTP responses.
The content is sent as a series of chunks, as shown in Listing 4. The size of the chunk is specified as a hexadecimal value on a line by itself, followed by the chunk data, followed by an empty line. The final chunk is sent with size 0 to indicate the end of the chunk transfer.When the web server sends both the Content-Length and Transfer-Encoding: chunked headers, the former is ignored. Such a response is typically generated by application programs invoked by the web server to generate dynamic content.
Listing4: An example of a chunk based response
The HTTP/1.1 protocol also provides another mechanism to support partial content delivery where the client can make requests for specific segments of a particular resource by specifying a range of bytes. For example, in response to the request headerRange: bytes=0-199, the web server would send only first 200 bytes of the requested resource. Similarly, the request headerRange: bytes=200-299 fetches the 100 bytes data of starting from the offset 200. An example of the partial response to such a request is shown in Listing 5. Note that the status response code is 206 Partial Content instead of the usual 200 OK. The response header Content-Range: bytes 200-299/873indicates the specific range of 100 bytes of data being sent, out of a total size of 873 bytes. This partial response is particularly very useful if the network connection fails while downloading a large file, because the client can resume the download from the point of failure rather than starting from the beginning.
Listing 5: The response header for partial contents
Experimenting with Partial Content Delivery
A simple way to experience chunked transfer is to create a PHP program that introduces artificial delays to emulate network latency, as shown in Listing 6. Store this code in a file named chunk-xfer.php in the document root on the web server. When the URL http://10.1.1.1/chunk-xfer.php is accessed, the image will be rendered incrementally. Figure 10 shows three snapshots as the image is partially rendered with chunk transfer encoding. The PHP code uses chunks of size 1000 bytes (hex 3E8). To verify this, analyze the response packets with Wireshark capture.
Listing 6: PHP code to demonstrate the use of Transfer-Encoding: chunked
Figure 10: An image being displayed with chunk transfer encoding
To use the Range request header, use the curl tool10 to make the request for partial chunks. On the web server, create a simple page (e.g., mypage.html) of size N bytes. For concreteness, suppose N = 500. To access this file in three chunks, issue the following commands (in any order) from the client terminal:
i. curl –H “Range: bytes=0-199” –o chunk1.html
ii. curl –H “Range: bytes=200-399” –o chunk2.html
iii. curl –H “Range: bytes=400-” –o chunk3.html
The three chunks can be combined into a single document with the following command:
cat chunk1.html chunk2.html chunk3.html > response.html
Verify that the file response.html has precisely the same content as mypage.html.
We have discussed three different performance mechanisms that are supported by the HTTP protocol to improve the performance of web applications and enable better user experiences. The mechanism of multiple persistent connections is used by default in all modern web browsers. The HTTP/2 protocol makes use of only one persistent connection, yet it achieves better performance than HTTP/1.1 for reasons we will discuss in subsequent articles. The mechanism of caching contents saves bandwidth and network latency, especially when web pagescontain large multimedia content. The mechanism of transfer chunk encoding provides a more engaging user experience by rendering content as it is received. Further, large content can be downloaded in chunks so that, in case of a network failure, the download can be resumed from the point of last failure. As all these performance mechanisms are used to deal with issues of poor network latency, which we will measure and discuss in detail in the next article.
 RFC 1945, “Hyper Text Transfer Protocol – HTTP/1.0”, Network Working Group, Informational, Berners-Lee(MIT), Fielding (UC Irvine), Frystyk (MIT), May 1996.
 RFC 2068, “Hypertext Transfer Protocol – HTTP/1.1”, Proposed Standard, Fielding (UC Irvine), Gettys, Mogul (DEC), Frystyk, Berners-Lee (MIT), Jan 1997.
 RFC 2616, “Hyper Text Transfer Protocol – HTTP/1.1”, Network Working Group, Request for Comments 2616. Fielding (UC Irvine), Gettys (Compaq), Mogul (Compaq), Frystyk (MIT), Masinter (Xerox), Leach (Microsot), Berners-Lee (MIT), June 1999.
 RFC 7540, “Hypertext Transfer Protocol Version 2 (HTTP/2)”, IETF, Proposed Standard, Belshe (Bitgo), Peon (Google), Thmoson (Mozilla), May 2015.
 Wireshark – The Network Protocol Analyzer, https://www.wireshark.org/#learnWS”https://www.wireshark.org/#learnWS, Accessed Aug 2017.
 Kurose, Ross, “Computer Networks: A Top Down Approach” 7th edition, Pearson Education Inc, 2016.
 Apache Web Server https://httpd.apache.org/docs/2.4, accessed July 2017.
 https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en, Accessed August 2017.
 http://httparchive.org/trends.php, accessed August 2017.
 https://www.mnot.net/cache_docs/, accessed August 2017.
 http://acc.digital/experiential-learning/, The first article on experiential learning of Networking Technologies, Jun 30, 2017, ACCS India.
 On Ubuntu, this utility can be installed as follows: sudo apt -get install curl.