Outline. HTTP/TCP Interactions. TCP Timers. TCP Timers Retransmission Timer Slow-Start Restart TIME_WAIT State

Transcription

1 HTTP/TCP Interactions Outline TCP Timers Retransmission Timer Slow-Start Restart TIME_WAIT State HTTP/TCP Layering Aborted HTTP transfers Nagle s algorithm Delayed ACKs Multiplexing Multiple Connections Server Overheads So Far HTTP runs over TCP TCP: defined in the`80s with other applications in mind FTP, telnet HTTP 1.0 poor use of TCP for short responses 1 connection for request TCP always in slow start HTTP 1.1 Use of persistent connections w/o pipelining Timers for: TCP Timers 1. Retransmission of lost packets 2. Repeating the slow start phase After inactivity period 3. Reclaiming state from a terminated connection 4. Control transmission of delay ack How do these timers affect Web Performance?

2 Retransmission Timer (RTO) Time required for TCP sender to detect packet loss Except when done via 3-duplicate ack 1. Delay in establishing a TCP connection 2. Delay in the middle of a WEB transfer Delay for New Connection TCP 3-way handshake SYN -> SYN-ACK -> ACK With no loss request after 1RTT Loss of SYN or SYN-ACK Loss detected only by timeout Initial window is 1!!! What is the initial RTO value? 3sec!!! What happen to RTO after a retransmission It doubles!!! What happen with multiple losses? No much effect for non-interactive applications Devastating for Web performance server SYN SYN SYN SYN client T 2T 4T SYN-ACK Delay for New Connection Causes Congestion at critical links Access links, peering points Web servers discarding SYN when the incoming queue is full (Remedy) Stop and Reload Abort connection and start a new one Sends a new SYN before the 3 sec Effects? Delay in the Middle of a WEB Transfer Long retransmission timeout are less likely RTT estimation refines RTO values 3-duplicate ack reduce timeout events but, do we ever get to this stage? Most Web-transfers (8-12KB) never get past slowstart There might not be enough ack to trigger retransmission server SYN client SYN-ACK ACK Richiesta RTO Risposta-1 Risposta-2 ACK-Dup Risposta-1

3 Slow-Start Restart Persistent connections avoid slow-start What happen when sending a request after an idle period? 1. Connect 2. Download page, Congestion window grows substantially 3. Read the page for 10 seconds in the meantime network congestion occurs 4. Request another page The large congestion window allows too many packets into the network 5. More congestion!!! Slow-Start Restart TCP requires sender to repeat slow-start after a period of inactivity To avoid overloading the network Treat a session re-starting as a new session How long the idle period? 1 RTO since idle and all previous data acked Order of few RTTs Pros: Slow-Start Restart Good for overall network health Cons: Avoid sudden burst of packets Reduces performance gain of persistent connections Reduce Slow-Start Restart Penalty 1. Disable Slow-Start At server own risk! 2. Use a Larger Slow-Start Timeout 3. Gradually Decrease the Congestion Window 4. Pacing the transmission of packets 5. A combination of the above

4 The TIME_WAIT State TCP connections state consume memory OS need to reclaim resources as soon as possible but TCP need to maintain state during connection closing for a period of time The TIME_WAIT State Connection Termination: 2 pair of FIN-ACK between sender a receiver Maintain state after termination to handle special cases: FIN and/or ACK losses Duplicate packets arriving after closing What if new connection with same IP/ports exists? The TIME_WAIT State One of the hosts need to remember that the previous connection existed to avoid reuse same IP/ports The one that sent the first FIN TIME_WAIT long enough that no packets exists in the network 2 MSL (Maximum Segment Lifetime) 4 minutes MSL=2minutes, 1 in some implementations Potential large numbers of connections in the TIME_WAIT state Potential limit the number of connections between two hosts Effect of TIME_WAIT on WEB Servers No persistent connection: Server closes the connection after response Persistent connection: eventually either the client or the server close it Web has incentive to close Web servers cannot maintain a persistent connection for each client Web clients not so Web servers closing the connection suffer the burden of TIME_WAIT state Few seconds connection and 4 minutes TIME_WAIT state

5 Reducing TIME_WAIT Overhead High performance Web Servers need to reduce the burden of TIME_WAIT state Solutions: 1. Lowering the system resources needed Memory required: being able to send last ACK and avoid reusing IP/ports numbers OS overhead to check for expired timers 2. Shifting the burden to the clients Modify TCP Use RST, FIN recipient entering TIME_WAIT state Modify HTTP Response header asking the client to close the connection but in practice: Server OS reduces TIME_WAIT to 5 seconds HTTP/TCP Layering 3 examples of function implemented at transport layer effecting (in negative way) Web performance: 1. Aborted HTTP transfers 2. Nagle s algorithm 3. Delayed ACKs Aborted HTTP Transfers Abort HTTP transfer Clicking on STOP Clicking on a link HTTP has no abort mechanism Other protocols have one, e.g., Telnet ctrl-c Abort would complicate handling of pipelined requests Aborting a request means terminating the TCP connection Effect of Abort Operations Clicking on a link Terminates the connection and open a new one Even in case of persistent connections HTTP request has side effects Increment a variable Trigger a script that purchase a product Have the request been completed? Web server may maintain state with this information

6 Effect of Abort Operations Pipelined requests Abort one request terminates all requests Problem with Proxies pipelining different users requests User-level abort do not immediately stops the transfer Problem with Proxies having high speed connection to server and low speed connection to clients Motivation Nagle s Algorithm Reduce the number of small packets by delaying data transmission Small=fewer bytes than 1 MSS Deals with interactive applications as Telnet and Rlogin need to transmit user keystrokes and short responses A packet/keystroke=1byte data+40 bytes overhead Solution Nagle s Algorithm TCP does not send small packets until all outstanding ACKs are received Ensures that at most one small packet is transmitted per RTT Effective when it is needed: interactive applications over a connection with a long RTT Nagle s Alg. and Persistent Connection Response header and body written using two system calls First packet containing header is transmitted before second system call Body is sent later after an RTT Before only if additional data is written in the send buffer Same problem in case of single system call for entire message Message transmitted as multiple full-size messagges+a small final packet

7 Nagle s Alg. And Persistent Connection Solution? Disable Nagle Algorithm But what if several write are used for writing header/response? Delayed ACKs Motivation Reduce the amount of ACKs traffic To reduce overhead (each ACK requires 40byte) Solution Piggybacking the ACK on an outgoing data packet, but sends an ACK for every other full size data packet delay an ACK no more than 500ms Delayed ACKs and Web traffic Delayed ACKs and Nagle s Algorithm Separate response header and body packet cwnd=2 (assume Nagle alg. disabled) Server Server Transmission delayed till ACK arrives Client Delayed ACK Timeout Client Delayed ACK Timeout