Transcription

1 1 Analysis of HTTPè1.1 Performance on a Wireless Network Stephen Cheng Kevin Lai Mary Baker fstephenc, laik, Techical Report: CSL-TR February 1999 Computer Systems Laboratory Departments of Electrical Engineering and Computer Science Stanford University Stanford, California This research is supported by a gift from NTT Mobile Communications Network, Inc. èntt DoCoMoè, a graduate fellowship from the USENIX Association, and a Sloan Foundation Faculty Fellowship. Abstract We compare the performance of HTTPè1.0 and 1.1 on a high latency, low bandwidth wireless network. HTTPè1.0 is known to have low throughput and consume excessive network and server resources on today's graphics-intensive web pages. A high latency, low bandwidth network only magniæes these problems. HTTPè1.1 was developed to remedy these problems. We show that on a Ricochet wireless network, HTTPè1.1 doubles throughput over HTTPè1.0 and decreases the number of packets sent by 60è.

2 Copyright 1999 Stephen Cheng, Kevin Lai, and Mary Baker 2

3 3 I. Introduction In the past few years, there has been an explosion in the popularity of the World Wide Web. The convenience of having information immediately available is indispensable. Users are able to connect to computers in all parts of the globe from their home or oæce. However, as the number of Web users has increased, so have the number of problems. One problem is the performance and impact on the network of HTTPè1.0, the underlying protocol for transferring Web pages. HTTPè1.1 was developed to address this problem. It aims to 1è reduce traæc on the network by only opening one persistent network connection instead of many short-lived ones, 2è improve throughput by pipelining requests, and 3è improve caching. HTTPè1.1 is backward compatible with HTTPè1.0 and is gaining wider acceptance as Netscape and Microsoft build support for it into their browsers. The interest in the World Wide Web is only a small part of the overall trend towards greater connectivity that has permeated society. At the same time as the Web has allowed people to contact data all over the world, metropolitan area wireless and cellular networks have allowed people to remain in contact wherever they go. However, the high latency and low bandwidth of these networks have limited the freedom of users in accessing data on the Web. These networks often have high latency because they use latency-increasing link level error recovery techniques and packets often have to traverse multiple wireless hops before entering the wired part of the Internet. Many of the networking problems which are addressed by HTTPè1.1 are magniæed in a high latency network such as a wireless link. Reducing the numberofpackets sent and mitigating the eæect of latency through pipelining would beneæt a wireless network even more than its wired counterpart. We investigate the eæects of HTTPè1.1 on a Metricom Ricochet wireless network and compare it with the eæects on an Ethernet network. II. HTTP In this section we discuss the major problems of HTTPè1.0 and how HTTPè1.1 solves those problems. A. Problems with HTTPè1.0 The primary problem with HTTPè1.0 is that it opens a separate connection for each object on a page ë4ë. Each image on a page is usually a diæerent object and therefore HTTPè1.0 usually has to open many connections for each page. Opening many connections for a page has a number of detrimental eæects on throughput and the network load. First, each connection requires a certain amount of time for setup and shutdown. This decreases the throughput experienced by the user. In addition, the packets used for setup and shutdown don't contain application data, thereby unnecessarily increasing network load. Second, each connection consumes state in the HTTP server. HTTP uses TCP for its transport protocol. TCP speciæes that a connection must remain in a waiting state for four minutes after it is closed. Thus, a server may be littered with many ports in this state. In many TCP implementations, the more ports a server has open, the longer it takes the server to determine which application a packet is destined for. We didn't measure the eæect of excessive state on the HTTP server because it would be the same regardless of whether we were using a wired or wireless network. Another detrimental eæect is that TCP cannot utilize the full bandwidth of the network. Most HTTPè1.0 connections are very short, since most HTTP objects are small. TCP has a slow start mechanism which gradually increases the sending rate in order to probe the network for the best throughput rate without causing congestion. However, a short-lived connection may never reach its full throughput potential. This causes the throughput experienced by the user to be unnecessarily low. Another problem is that HTTPè1.0 has poor throughput on high latency connections because it is a strict requestèresponse protocol. This means it requests an object and then waits until it has received the object before requesting the next object. As a consequence, HTTPè1.0 requires at least two network round trips for each retrieved object, which greatly decreases throughput on high latency networks such as the Metricom Ricochet. The ænal problem is that HTTPè1.0 usually causes high internal fragmentation ènot the same as IP fragmentationè. This is because most HTTP objects are small and HTTPè1.0 uses a separate connection

4 4 for each object. For example, an object slightly larger than a packet will cause one full-size packet and one small packet to be sent because we can't pack data from another object in with the last bit of data from the ærst object. High internal fragmentation causes the many small packets to be sent. Small packets are wasteful of network resources because packets have a æxed cost of certain network resources regardless of the size of the packet. For example, routers have to spend some amount of CPU time to process a packet regardless of size. For a small packet, this CPU time cannot be amortized over many bytes, and therefore the router isn't working at optimal eæciency. Another example is the bytes used by packet headers. HTTP packets are also TCP packets and therefore have a header of 40 bytes per packet. The smaller the packet size, the greater the relative cost of the header in bandwidth. B. HTTPè1.1 HTTPè1.1 was developed to address these problems. It is backward-compatible with HTTPè1.0 but manages connections diæerently. Instead of making a separate connection for each Web object, an HTTPè1.1 client makes a single persistent connection with the server, which it leaves open for subsequent retrievals, thus solving the above problems: 1. The client doesn't need to waste time or packets setting up multiple connections. 2. The server doesn't need to maintain state for those extra connections. 3. The single HTTPè1.1 connection transfers more data than each of the HTTPè1.0 connection and therefore can more eæectively use slow start to fully utilize the network's bandwidth. 4. HTTPè1.1 pipelines its requests, enabling the client to issue multiple requests before receiving any responses from the server. 5. Since the client uses pipelined requests over one connection, diæerent objects sent from the server can be packed into a fewer number of packets, resulting in lower internal fragmentation. Having a single persistent, pipelined connection allows the HTTPè1.1 to reach a throughput approaching the bandwidth of the network while only sending the minimal numberofpackets. III. Experiment Setup In this section, we discuss the hardware and software we used to run the experiments. We used a relatively simple networking setup. We had two Pentium computers, tnt.stanford.edu and detcord.stanford.edu, running RedHat Linux 5.0 èkernel version è. Each machine had a wired and wireless connections and two IP addresses. The wireless connection employed Metricom Ricochet SE radios èfirmware version Pè, and the wired connection was a 10-base-T Ethernet network. The Ethernet network has an Maximum Transmission Unit èmtuè of 1500 bytes, a bandwidth of 10Mbès, and an average round trip time èrttè of 4 ms. The Ricochet network has an MTU of 1152 bytes. We used the Ricochet network so that the radios talk peer to peer. In this conæguration, the Ricochet network has a bandwidth of 60Kbès and an average RTT of 170ms. This is not the conæguration seen by most Ricochet users èsee section VIè, but it provides the maximum possible performance for the Ricochet network and avoids the error introduced by sharing bandwidth with other users during the tests. We spent most of our time conæguring our software. We used Apache ë1ë as our web server and the libwww robot èrelease 5.1lè from the W3 Consortium ë2ë as our client. The Apache server was not compiled with any special options, other than those required to get it running on RedHat 5.0. However, in the runtime conæguration æles, we placed in an option to make it emulate an HTTPè1.0 only server. We set the special environment variable "downgrade-1.0" to true regardless of the browser. Thus, we had to start up the server twice: once to gather HTTPè1.0 data and once to gather HTTPè1.1 data. We decided to force the server into HTTPè1.0 mode rather than the robot because we were unable to get the robot to perform correctly in the mandatory HTTPè1.0 mode. We set up a sample web page which was basically a copy of a Microsoft web page. It was meant to simulate current web pages which are graphically intense. The HTML æle itself was approximately 25KB and it contained 30 in-line images varying from under 100 bytes to about 10KB. The total amount of data ètext and imagesè was about 69KB. The robot was run in non-interactive mode, saving the images in order to simulate a GUI browser. In addition, the quiet mode was turned on so that the output would not slow down the time measurements.

5 5 HTTPè1.0 Wired HTTPè1.1 Wired HTTPè1.0 Wireless HTTPè1.1 Wireless Throughput èkbèsè 247.6è4.7è 462.4è18.9è 17.2è15.5è 36.9è12.4è Total Packets è0.4è 95.9 è4.2è è2.5è è5.5è Packet Size èbytesè è0.6è è1.0è è3.2è è5.5è TABLE I Performance of HTTPè1.0 and 1.1 on Ethernet and Ricochet. This table lists the mean and percent standard deviation for ten runs. To time the duration of the connections, we simply took the time elapsed value printed out by the robot. Because the time given by the robot includes the time taken to start up the robot and exit the program, these times are not the exact times between when the ærst SYN request was sent and the last ACK received. However, the overhead of the robot is small compared to the network events were measuring, so we ignored this source of error. A more serious source of error is the fact that the robot makes one TCP connection per request and one request at a time in HTTPè1.0 mode. We were unable to do parallel connections to mimic browsers like Netscape èwhich typically uses four parallel connectionsè. In HTTPè1.1 mode, the robot makes one TCP connection for all requests using the persistent connection protocol and pipelining. We did not use the persistent cache because we are simply measuring the eæects on the transfer of TCP packets, not necessarily overall web performance. We gathered the data using the robot's quiet mode output and using tcpdump on the server side. We started the Apache server èin HTTPè1.0 modeè and then tcpdump on tnt. On detcord, we started the robot with the IP address of the server's wired interface. We then ran the again, this time with the IP address of the server's wireless interface. Then we killed the the server and restarted it with the edited conæguration æle allowing normal HTTPè1.1 operation. The tests were repeated to get measurements for the HTTPè1.1 speciæcation on both on the wired and wireless interfaces. We ran the test æve times for each of the four diæerent setups. IV. Experimental Results In this section we discuss the results of our experiments. We used tcpdump to dump the packet traces to a æle and tcptrace ë3ë to analyze them. A. Quantiæed Beneæts of HTTPè1.1 Table I shows the mean and standard deviation over ten runs of various metrics which quantify the beneæts of HTTPè1.1 over HTTPè1.0 over a wireless network. The standard deviation is given as a percentage of the mean. We also give the results over a wired network for comparison. The ærst metric we are interested in is throughput. Throughput gives a ærst order approximation of the delay experienced by the user. HTTPè1.1 approximately doubles throughput over HTTPè1.0 on both the wired and wireless interfaces. HTTPè1.1 throughput is improved for many of the reasons mentioned in section II-B: no time is spent setting up extra connections, the longer connection time enables TCP to more fully utilize the network's bandwidth, pipelining of requests reduces the overall delay, and the lower internal fragmentation reduces bandwidth spent on headers. The second metric is total packets sent into the network. We list this in the table as ëtotal Packets". This metric measures the network resources consumed by HTTP, thus indicating how well the network would scale to many users. We found that HTTPè1.1 decreased the number of packets sent by a factor of 3.8 on the wired network and 2.4 on the wireless network. This would represent a signiæcant increase in the number of hosts which could use the network. There are several reasons why HTTPè1.1 sends so many fewer packets than HTTPè1.0. As discussed in section II-B, HTTPè1.1 doesn't waste packets setting up connections because it only sets up one connection. Another reason is that HTTPè1.1 packets achieve amuch lower internal fragmentation by sending fewer, but

6 6 HTTPè1.0 Wired HTTPè1.1 Wired HTTPè1.0 Wireless HTTPè1.1 Wireless Number of runs Total time 2.91 è4.7è 1.14 è0.6è è7.9è è0.0è Packets èclient to serverè è0.7è 25.5 è2.8è è0.8è 62 è0.0è Packets èserver to clientè è0.3è 64 è0.0è è0.3è 92 è0.0è Total packets è0.4è 89.5 è0.0è 417 è0.4è 154 è0.0è Payload Bytes è0.7è è0.0è è0.4è è0.0è Total Bytes è0.6è è0.0è è0.4è è0.0è TABLE II Performance of HTTPè1.0 and 1.1 on Ethernet and Ricochet, excluding runs where there were retransmissions. This table lists the mean and percent standard deviation for runs which didn't have retransmissions. larger packets than HTTPè1.0. In table I we can see that the average packet size of HTTPè1.1 is almost three times larger for the wired network and twice as larger for the wireless. B. Inconsistencies and Sources of Error In this section, we discuss inconsistencies and sources of error in our data. The most signiæcant source of error is that the throughput improvement described in section IV is greater than the actual improvement we would expect in browser performance. This is because èas noted beforeè we were unable to get our client to open more than one TCP connection simultaneously èas current browsers doè. We expect that this technique of opening multiple TCP connections simultaneously would give large performance improvements on the wired network. This is because short lived HTTPè1.0 TCP connections are never able to increase their windows to the point where they are able to fully utilize the 10Mbès of bandwidth. This might even boost the throughput of HTTPè1.0 over that of HTTPè1.1. On the other hand, we expect that this technique would give little performance improvement on the wireless network because even short TCP connections are able to open their TCP windows to the point where they can use the 60 Kbès maximum bandwidth of the Ricochet èsee section IIIè. One inconsistency in data is the is the diæerence in total packets sent using HTTPè1.1 on the wired èmean of 95.9 packetsè compared to the wireless networks èmean of packetsè. At ærst glance, one would think that there should be no diæerence because the actual HTML and picture data sent ineach case is the same. There are several sources for this diæerence. One is retransmissions. If packets have to be retransmitted on the wireless network, this could account for the extra packets. In order to measure this eæect, we recalculated our metrics using only those connections which experienced no retransmissions. The results are summarized in Table II. In this table we list the number of runs we could use to compute each column, since it might be diæerent from the ten runs we used in Table I. We can see that when we factor our retransmissions, there is less diæerence è89.5 and 154è in the total packets sent into the network. Another source for this diæerence is the diæerent MTUs for the diæerent networks èmentioned in section IIIè. As mentioned in section II-B, HTTPè1.1 reduces internal fragmentation by ælling up packets with more data. However, since the maximum packet size 1500 bytes for Ethernet is 1500 bytes and 1152 bytes for Ricochet, it needs to send more packets over Ricochet. V. Related Work Nielsen, et. al., ë5ë describe the performance improvements of HTTPè1.1 over HTTPè1.0 on a variety of network technologies, but none of them are wireless. They do measure the performance of HTTPè1.1 on a high latency, low bandwidth network èa modemè, but do not measure the performance of HTTPè1.0 for comparison.

7 7 VI. Future Work In this section, we discuss possible future experiments related to this research. One experiment would be measuring the same metrics, but using a client that supported multiple simultaneous open connections. This would accurately simulate the behavior of current browsers. Another experiment would be to conægure the wireless Ricochet network so that multiple wireless hops separate the client and the server. This is the conæguration seen by most users of the Ricochet network. In addition, the eæect of congestion on HTTPè1.1 as not been thoroughly studied. We would like to study this as well as how these eæects change on wireless networks. We would most likely have to use a network simulator to accurately measure these eæects. A network simulator would also allow us to measure the performance of HTTPè1.1 on wireless networks other than Ricochet. This would allow us to test hypotheses we might have about the performance of HTTPè1.1 on networks other than Ricochet. For example have the hypothesis that the throughput of HTTPè1.1 would scale with greater network bandwidth. The average throughput of HTTPè1.1 on Ricochet that we measured was 36.9Kbès, which approaches the maximum bandwidth of 60Kbès of the Ricochet network. This suggests that the throughput of HTTPè1.1 would scale with greater network bandwidth. VII. Acknowledgements We'd like to thank NTT DoCoMo for funding this research. VIII. Conclusion Our study has shown that on a wireless network, HTTPè1.1 doubles the throughput of HTTPè1.0, while reducing the number of packets sent by 60è. We believe this signiæcantly improves the performance seen by the user and increases the scalability of the wireless network. In the future, wide area wirless networks are likely to remain high latency because of the inherent interference wireless networks must overcome. In addition, for these wireless networks to remain inexpensive, there will have to be many wireless routers without a wired connection to the Internet, thus causing packets to traverse several high latency wireless hops. Similarly, satellite-based wireless networks are likely to have high latency. However, these wireless networks will have greatly increased bandwidth because of more eæcient use of the spectrum and the allocation of more parts of the spectrum. In such an environment, we believe that HTTPè1.1 will have even greater beneæts than we have measured. References ë1ë Apache ë2ë libwww robot ë3ë tcptrace ë4ë Jeærey C. Mogul. The case for persistent-connection http. Technical Report Western Research Laboratory Research Report 95è4, Digital Equipment Corporation, ë5ë Henrik Frystyk Nielsen, Henrik Frystyk, Jim Gettys, Anselm Baird-Smith, Eric Prudhommeaux, Hakon Wium Lie, and Chris Lilley. Network performance eæects of httpè1.1, css1, and png. In Proceedings of SIGCOMM,

1 First Midterm for ECE374 03/24/11 Solution!! Note: In all written assignments, please show as much of your work as you can. Even if you get a wrong answer, you can get partial credit if you show your

Lab VI Capturing and monitoring the network traffic 1. Goals To gain general knowledge about the network analyzers and to understand their utility To learn how to use network traffic analyzer tools (Wireshark)

3. MONITORING AND TESTING THE ETHERNET NETWORK 3.1 Introduction The following parameters are covered by the Ethernet performance metrics: Latency (delay) the amount of time required for a frame to travel

TCP PERFORMANCE IN MOBILE-IP Foo Chun Choong Department of Electrical Engineering, National University of Singapore ABSTRACT The throughput performance of TCP in Mobile-IP [1] was investigated. Compared

Burst Testing Emerging high-speed protocols in mobility and access networks, combined with qualityof-service demands from business customers for services such as cloud computing, place increased performance

The Data Replication Bottleneck: Overcoming Out of Order and Lost Packets across the WAN By Jim Metzler, Cofounder, Webtorials Editorial/Analyst Division Background and Goal Many papers have been written

v. Test Node Selection Having a geographically diverse set of test nodes would be of little use if the Whiteboxes running the test did not have a suitable mechanism to determine which node was the best

Key Components of WAN Optimization Controller Functionality Introduction and Goals One of the key challenges facing IT organizations relative to application and service delivery is ensuring that the applications

Quantifying the Performance Degradation of IPv6 for TCP in Windows and Linux Networking Burjiz Soorty School of Computing and Mathematical Sciences Auckland University of Technology Auckland, New Zealand

Life of a Packet CS 640, 2015-01-22 Outline Recap: building blocks Application to application communication Process to process communication Host to host communication Announcements Syllabus Should have

MEASURING WORKLOAD PERFORMANCE IS THE INFRASTRUCTURE A PROBLEM? Ashutosh Shinde Performance Architect ashutosh_shinde@hotmail.com Validating if the workload generated by the load generating tools is applied

Transport Layer Protocols Version. Transport layer performs two main tasks for the application layer by using the network layer. It provides end to end communication between two applications, and implements

Improving Effective WAN Throughput for Large Data Flows By Peter Sevcik and Rebecca Wetzel November 2008 When you buy a broadband Wide Area Network (WAN) you want to put the entire bandwidth capacity to

TCP/IP: An overview Syed A. Rizvi TCP/IP The Internet uses TCP/IP protocol suite to establish a connection between two computers. TCP/IP suite includes two protocols (1) Transmission Control Protocol or

152 APPENDIX 1 USER LEVEL IMPLEMENTATION OF PPATPAN IN LINUX SYSTEM A1.1 INTRODUCTION PPATPAN is implemented in a test bed with five Linux system arranged in a multihop topology. The system is implemented

CS268 Exam Solutions General comments: ) If you would like a re-grade, submit in email a complete explanation of why your solution should be re-graded. Quote parts of your solution if necessary. In person

Lab Exercise TCP Objective To see the details of TCP (Transmission Control Protocol). TCP is the main transport layer protocol used in the Internet. The trace file is here: http://scisweb.ulster.ac.uk/~kevin/com320/labs/wireshark/trace-tcp.pcap

Laboratory 12 Applications Network Application Performance Analysis Objective The objective of this lab is to analyze the performance of an Internet application protocol and its relation to the underlying

Chapter 1 Review Questions R1. What is the difference between a host and an end system? List several different types of end systems. Is a Web server an end system? 1. There is no difference. Throughout

Large-Scale TCP Packet Flow Analysis for Common Protocols Using Apache Hadoop R. David Idol Department of Computer Science University of North Carolina at Chapel Hill david.idol@unc.edu http://www.cs.unc.edu/~mxrider

technical brief in HP Overview HP is a Web-based software application designed to install, configure, manage and troubleshoot network-connected devices. It includes a Web service, which allows multiple

The fundamentals of TCP/IP networking TCP/IP (Transmission Control Protocol / Internet Protocols) is a set of networking protocols that is used for communication on the Internet and on many other networks.

RFC 6349 Testing with TrueSpeed from JDSU Experience Your Network as Your Customers Do RFC 6349 is the new transmission control protocol (TCP) throughput test methodology that JDSU co-authored along with

Testing & Assuring Mobile End User Experience Before Production Neotys Agenda Introduction The challenges Best practices NeoLoad mobile capabilities Mobile devices are used more and more At Home In 2014,

A Research Study on Packet Sniffing Tool TCPDUMP ANSHUL GUPTA SURESH GYAN VIHAR UNIVERSITY, INDIA ABSTRACT Packet sniffer is a technique of monitoring every packet that crosses the network. By using this

Ethernet Babak Kia Adjunct Professor Boston University College of Engineering ENG SC757 - Advanced Microprocessor Design Ethernet Ethernet is a term used to refer to a diverse set of frame based networking

Mobile devices are proliferating, and their use to access applications is skyrocketing, while users are less accepting of application performance issues than ever before. Since mobile devices have limited

1 Homework 2 assignment for ECE374 Posted: 02/21/14 Due: 02/28/14 Note: In all written assignments, please show as much of your work as you can. Even if you get a wrong answer, you can get partial credit

Data Transfer Consider transferring an enormous file of L bytes from Host A to B using a MSS of 1460 bytes and a 66 byte header. What is the maximum value of L such that TCP sequence numbers are not exhausted?

TCP/IP Optimization for Wide Area Storage Networks Dr. Joseph L White Juniper Networks SNIA Legal Notice The material contained in this tutorial is copyrighted by the SNIA. Member companies and individuals

www.agileload.com There is no second thought about the exponential increase in importance and usage of mobile applications. Simultaneously better user experience will remain most important factor to attract