DOC PREVIEW
CMU CS 15744 - The Case for Persistent-Connection HTTP

This preview shows page 1-2-3-4-5 out of 15 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

The Case for Persistent-Connection HTTPJeffrey C. MogulDigital Equipment Corporation Western Research Laboratory250 University Avenue, Palo Alto, CA 94301mogul @wrl.dec.comAbstractThe success of the World-Wide Web is largely due tothe simplicity, hence ease of implementation, of the Hy-pertext Transfer Protocol (HTTP). HTTP, however,makes inefficient use of network and server resources,and adds unnecessary latencies, by creating a new TCPconnection for each request. Modifications to HTTPhave been proposed that would transport multiple re-quests over each TCP connection. These modificationshave led to debate over their actual impact on users, onservers, and on the network. This paper reports theresults of log-driven simulations of several variants ofthe proposed modifications, which demonstrate thevalue of persistent connections.1. IntroductionPeople use the World Wide Web because it gives quickand easy access to a tremendous variety of information inremote locations. Users do not like to wait for their results;they tend to avoid or complain about Web pages that take along time to retrieve. Users care about Web latency.Perceived latency comes from several sources.Web ser-vers can take a long time to process a request, especially ifthey are overloaded or have slow disks. Web clients canadd delay if they do not quickly parse the retrieved data anddisplay it for the user. Latency caused by client or serverslowness can in principle be solved simply by buying afaster computer, or faster disks, or more memory.The main contributor to Web latency, however, is net-work communication. The Web is useful precisely becauseit provides remote access, and transmission of data across adistance takes time.Some of this delay depends onbandwidth; you can reduce this delay by buying a higher-bandwidth link. But much of the latency seen by Webusers comes from propagation delay, and you cannot im-prove propagation delay (past a certain point) no matterhow much money you have. While caching can help, manyWeb access are “compulsory misses.”If we cannot increase the speed of light, we should atleast minimize the number of network round-trips requiredfor an interaction.The Hypertext Transfer ProtocolPermission to make digital/hard copies of all or part of this material with-out fee is granted provided that the copies are not made or distributedfor profit or commercial advantage, the ACM copyrightkervernotice, the title of the publication and Its date appear, and notice is giventhat copyright is by permission of the Association for Computing Machinery,Inc. (ACM). To copy otherwise: to republish, to post on servers or toredistribute to lists, requires prior specific permission and/or a fee.SIGCOMM ’95 Cambridge, MA USA01995 ACM 0-89791 -711-1 195/0008 $350(HTTP) [3], as it is currently used in the Web, incurs manymore round trips than necessary (see section 2).Several researchers have proposed modifying HTTP toeliminate unnecessary network round-trips [21, 27]. Somepeople have questioned the impact of these proposals onnetwork, server, and client performance. This paper reportson simulation experiments, driven by traces collected froman extremely busy Web server, that support the proposedHTTP modifications. According to these simulations, themodifications will improve user’s perceived performance,network loading, and server resource utilization.The paper begins with an overview of HTTP (section 2)and an analysis of its flaws (section 3). Section 4 describesthe proposed HTTP modifications, and section 5 describessome of the potential design issues of the modifiedprotocol. Section 7 describes the design of the simulationexperiments, and section 8 describes the results.2. Overview of the HTTP protocolThe HTTP protocol [1, 3] is layered over a reliablebidirectional byte stream, normally TCP [23]. Each HTTPinteraction consists of a request sent from the client to theserver, followed by a response sent from the server to theclient. Request and response parameters are expressed in asimple ASCII format (although HITP may convey non-ASCII data).An HTTP request includes several elements: a methodsuch as GET, PUT, POST, etc.; a Uniform ResourceLocator (URL); a set of Hypertext Request (HTRQ)headers, with which the client specifies things such as thekinds of documents it is willing to accept, authenticationinformation, etc; and an optional Data field, used with cer-tain methods (such as PUT).The server parses the request, and takes action accordingto the specified method. It then sends a response to theclient, including (1) a status code to indicate if the requestsucceeded, or if not, why not; (2) a set of object headers,meta-information about the “object” returned by the serv-er; and (3) a Data field, containing the file requested, or theoutput generated by a server-side script.URLS may refer to numerous document types, but theprimary format is the Hypertext Markup Language(HIWIL) [2]. HTML supports the use of hyperlinks (linksto other documents). HTML also supports the use of in-lined images, URLS referring to digitized images (usuallyin the Graphics interchange Format (GIF) [7] or JPEG for-mat), which should be displayed along with the text of theHTML file by the user’s browser. For example, if anHTML page includes a corporate logo and a photograph of299the company’s president, this would be encoded as twoinlined images.The browser would therefore make threeHTTP requests to retrieve the HTML page and the twoimages.3. Analysis of HTTP’s inefficienciesI now analyze the way that the interaction betweenHTTP clients and servers appears on the network, with em-phasis on how this affects latency.Figure 3-1 depicts the exchanges at the beginning of atypical interaction, the retrieval of an HTML documentwith at least one uncached inlined image. In this figure,time runs down the page, and long diagonal arrows showpackets sent from client to server or vice versa. Thesearrows are marked with TCP packet types; note that mostof the packets carry acknowledgements, but the packetsmarked ACK carryonly an acknowledgement and no newdata. FIN and SYN packets in this example never carrydata, although in principle they sometimes could.ClientServer----0 RTT -----Client opensF=lSYNTCP connection---..1 RTT -----SYNClient sendsACKHTTP requestDATfor HTML1Server readsACKfrom disk--i!:iifiil~;~+TCP connectionSYN---- 3 RTT -----Client sendsHTTP requestfor image~:D=+I!Server readsfrom disk----4 RTT -----Image beginsEDAT7rto


View Full Document

CMU CS 15744 - The Case for Persistent-Connection HTTP

Documents in this Course
Lecture

Lecture

25 pages

Lecture

Lecture

10 pages

Lecture

Lecture

10 pages

Lecture

Lecture

45 pages

Lecture

Lecture

48 pages

Lecture

Lecture

19 pages

Lecture

Lecture

97 pages

Lecture

Lecture

39 pages

Lecture

Lecture

49 pages

Lecture

Lecture

33 pages

Lecture

Lecture

21 pages

Lecture

Lecture

52 pages

Problem

Problem

9 pages

Lecture

Lecture

6 pages

03-BGP

03-BGP

13 pages

Lecture

Lecture

42 pages

lecture

lecture

54 pages

lecture

lecture

21 pages

Lecture

Lecture

18 pages

Lecture

Lecture

18 pages

Lecture

Lecture

58 pages

lecture

lecture

17 pages

lecture

lecture

46 pages

Lecture

Lecture

72 pages

Lecture

Lecture

44 pages

Lecture

Lecture

13 pages

Lecture

Lecture

22 pages

Lecture

Lecture

48 pages

lecture

lecture

73 pages

17-DNS

17-DNS

52 pages

Lecture

Lecture

10 pages

lecture

lecture

53 pages

lecture

lecture

51 pages

Wireless

Wireless

27 pages

lecture

lecture

14 pages

lecture

lecture

18 pages

Lecture

Lecture

16 pages

Lecture

Lecture

14 pages

lecture

lecture

16 pages

Lecture

Lecture

16 pages

Lecture

Lecture

37 pages

Lecture

Lecture

44 pages

Lecture

Lecture

11 pages

Lecture

Lecture

61 pages

Multicast

Multicast

61 pages

Lecture

Lecture

19 pages

Lecture

Lecture

8 pages

Lecture

Lecture

81 pages

Lecture

Lecture

9 pages

Lecture

Lecture

6 pages

Lecture

Lecture

63 pages

Lecture

Lecture

13 pages

Lecture

Lecture

63 pages

Lecture

Lecture

50 pages

lecture

lecture

35 pages

Lecture

Lecture

47 pages

Lecture

Lecture

29 pages

Lecture

Lecture

92 pages

Load more
Download The Case for Persistent-Connection HTTP
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view The Case for Persistent-Connection HTTP and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view The Case for Persistent-Connection HTTP 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?