Delaying connection termination

One final problem is that some TCP servers do not close their connections in a graceful fashion. TCP connections are full-duplex - data flows along a connection in both directions. Under normal conditions, each ``half'' of the connection may only be closed by the sending side (by sending a FIN packet). Our algorithms implicitly assume this is true, since it is necessary that the target host respond with acknowledgments until the testing period is complete. While most TCP-based servers follow this termination protocol, we've found that some Web servers simply terminate the entire connection by sending a RST packet - sometimes called an abortive release. Once the connection has been reset, the sender discards any related state so any further probing is useless and our measurement algorithms will fail.

To ensure that our algorithms have sufficient time to execute, we've developed two ad hoc techniques for delaying premature connection termination. First, we ensure that the data sent during the data seeding phase contains a valid HTTP request. Some Web servers (and even some ``smart'' firewalls and load balancers) will reset the connection as soon as the HTTP parser fails. Second, we use TCP's flow control protocol to prevent the target from actually delivering its HTTP response back to the source. TCP receivers implement flow control by advertising the number of bytes they have available for buffering new data (called the receiver window). A TCP sender is forbidden from sending more data than the receiver claims it can buffer. By setting the source's receiver window to zero bytes we can keep the HTTP response ``trapped'' at the target host until we have completed our measurements. The target will not reset the connection until its response has been sent, so this technique allows us to inter-operate with such ``ill-behaved'' servers.