200 likes | 329 Views
This study investigates the performance issues arising from the interaction between Persistent HTTP (P-HTTP) and TCP implementations. It details initial experiments conducted on different workloads, revealing significant performance discrepancies. The research identifies problems such as the Short-Initial-Segment and Odd/Short-Final-Segment issues, which hinder performance due to TCP’s congestion control algorithms. Solutions like sending HTTP headers with initial data and disabling the Nagle algorithm are proposed. The paper concludes by critiquing the practical applicability of P-HTTP traffic analysis and its implications for large images.
E N D
Performance Interactions Between P-HTTP and TCP Implementations J. Heidemann ACM Computer Communication Review April 1997 김호중 CA Lab., KAIST
Contents • Introduction • Initial experiment • The performance problems • Related works • Conclusion • Critique
Introduction (1/2) • HTTP 1.0 • 1 HTTP request per each TCP connection • Several connections per a page • P-HTTP (Persistent-HTTP) • Multiple HTTP requests over a TCP connection • Advantages of HTTP 1.1 (RFC2068) • Saving CPU time, memory • Pipelining request without waiting each response • Reducing network congestion • Evolving HTTP
Introduction (2/2) • Problem : P-HTTP is not HTTP • HTTP : similar to FTP • P-HTTP : similar to SMTP or NNTP • SMTP : batch protocol • NNTP : interactive uses are usually in LAN
Initial Experiment (1/2) • Experimental framework • 10Mb/s Ethernet • Sun SPARC 20/71 • SunOS 4.1.3 with some TCP modification • 16KB default TCP window size • Slow-start enabled • Apache 1.1b4 • HTTP 1.0 with “Keep-Alive” on • No pipelining • 3 types of workload • 6651, 3883, 1866 bytes : yahoo’s title page (May 1996)
Initial Experiment (2/2) • Initial performance Protocol Server Retrieval time Std. variation HTTP 1.1b4 43 ms 4.0 ms P-HTTP 1.1b4 605 ms 10 ms P-HTTP 1.1b4 (1st fix) 195 ms 1.9 ms P-HTTP 1.1b4 (both fixes) 26 ms 8.8 ms
Short-Initial-Segment Problem (1/4) • Conflict between TCP’s slow-start algorithm and piggybacking • Slow-start algorithm • The connection opens its congestion window exponentially • Initial window size = 2 segments • Piggybacking • ACK on return traffic • RFC1122 : must ACK at >2 segments
Short-Initial-Segment Problem (2/4) Connection setup request ACK ACK HTTP header & 1st data segment Waiting … ACK timer expired ACK SERVER CLIENT TCP MSS(max. segment size) : 1460bytes for Ethernet 512 or 536bytes for wide area TCP connection HTTP header : 200~300bytes
Short-Initial-Segment Problem (4/4) • Solution • Send HTTP header with initial data • Problem of piggybacking • Unidirectional data traffic dominates Protocol Server Retrieval time Std. variation HTTP 1.1b4 43 ms 4.0 ms P-HTTP 1.1b4 605 ms 10 ms P-HTTP 1.1b4 (1st fix) 195 ms 1.9 ms P-HTTP 1.1b4 (both fixes) 26 ms 8.8 ms
Odd/Short-Final-Segment Problem (1/4) • Conflict between SWS avoidance algorithm and BSD TCP small message transfer • BSD TCP prevent sending until … • A full-size segment can be sent • We can send half of the client’s advertised window • We can send everything and… • Not expecting ACK • Nagle algorithm is disabled
Odd/Short-Final-Segment Problem (2/4) • Silly Window Syndrome (SWS) • Example • MSS : 200bytes, initial window : 1000bytes • Send 200bytes * 5 segments • Receive 1 segment and ACK • 800bytes pending, 200bytes available • Send 200bytes * 1 segment, … • Send 50bytes segment, followed by 150bytes segment • Receive 50bytes segment and ACK • 950byes pending, 50bytes available • Send 50bytes again? • Nagle’s algorithm
Odd/Short-Final-Segment Problem (4/4) • Solution • Disable Nagle’s algorithm • Nagle’s algorithm is for small, interactive packet Protocol Server Retrieval time Std. variation HTTP 1.1b4 43 ms 4.0 ms P-HTTP 1.1b4 605 ms 10 ms P-HTTP 1.1b4 (1st fix) 195 ms 1.9 ms P-HTTP 1.1b4 (both fixes) 26 ms 8.8 ms
Slow-Start Re-Start Problem (1/2) • Conservative congestion control • All data sent has been acknowledged + Nothing has been sent for a retransmission time-out period Reinitialize congestion window to 1 Slow-start again • time for browsing a page > time-out period
Slow-Start Re-Start Problem (2/2) • Solutions • Omitting to reset the congestion window • SunOS 4.1.3 • Bursty traffic can cause packet loss • Reinitiate the window after an idle period • Decay the window size over time • Still bursty traffic • Rate-based flow control • Hard to use for new connection : unknown network status
Other Problems • Inefficient I/O package • Disk file system cache (input stream buffer user buffer output buffer) network buffer network device • Memory-mapping the input file • Too small socket buffer • 2~16Kbytes • Can’t utilize the high-speed network
Related Works • Moldeklev and Gunningberg • Effect of MTU size to TCP transfer efficiency • Large-MTU network (ATM) • Crowcroft, Wakerman, Wang and Strovica • Relation of user- and TCP-level buffering • SunRPC traffic over TCP • Similar to HTTP request / P-HTTP response
Conclusion • P-HTTP over TCP • Short-initial-segment problem • Send HTTP header with initial data • Odd/short-final-segment problem • Disable SWS-avoidance algorithm • Slow-start re-start problem • Rate-based flow control
Critique • Good analysis • Evaluation • Is it realistic P-HTTP traffic? • Large images, many objects, … • Approaches • HTTP header with initial data • browser support needed • SWS-avoidance Disabled • No problem in real environments?