Case Study: Network Resiliency Test Using Stateful Traffic

What is HTTP?
HTTP is a client-server protocol by which two machines can communicate over a TCP/IP connection. An HTTP server is a program that sits listening on a machine's port for HTTP requests. An HTTP client (we will be using the terms HTTP client and web client interchangeably) opens a TCP/IP connection to the server via a socket, transmits a request for a document, then waits for a reply from the server. Once the request-reply sequence is completed, the socket is closed. So the HTTP protocol is a transactional one. The lifetime of a connection corresponds to a single request-reply sequence. (a transaction) HTTP is the protocol used for document exchange in the World-Wide-Web. Everything that happens on the web, happens over HTTP transactions. TCP/IP networking and HTTP are the two essential components that make the web work.

How it works?
The Hypertext Transfer Protocol (HTTP) is actually quite simple. The web browser (or client) makes a request of a webpage to the server, and the webserver passes the page back to the browser. More cleverly, it also passes back any images, sounds or other media items back to the browser too.
The web browser is also particularly clever in the way it displays what it retrieves.

Various versions of HTTP
HTTP 1.0

• Now Obsolete
• Each transaction requires new TCP session
• Server closes the session s
• Slow

HTTP 1.1

• Current
• Multiple Transaction in a single TCP session
• Client closes the sessions
• Fast and better bandwidth management

HTTP 1.0 Packet Flow


HTTP 1.1 Packet Flow

• Http 1.1 uses multiple transaction with in the same TCP connection. Here, we have 2 transactions with thesame TCP sessions.
• Client closes the connection. Notice the FIN/ACK is being sent by webclient

Topology



Objective

• To test resiliency of TCP session over the network when there is an induced network failure
• Record resiliency values when HTTP timers are modified

Configuration Walkthrough
Emulating 2 hosts on either end of the network. Following are the traffic pattern;
30.0.0.2 ----HTTP Traffic ----> 40.0.0.2
30.0.0.6 ----Stateless Traffic ----> 40.0.0.6

• 
  
• 

network configuration

TCP configuration

• 
  
• 

Web client configuration 01

• 
  
• 

Web client configuration 02

• 
  
• 

Web client configuration 03

• 
  
• 

Web server configuration 01

• 
  
• 

Web server configuration 02

• 
  
• 

Web server configuration 03

• 
  
• Case Study 1: Standard Configuration

• Run HTTP traffic with default values timers. i.e. HTTP client command timeout 60sec in line with Internet Explorer defaults
• Flap the network between R1 and R2 to collect resiliency time

• Note: Increase the HTTP keep-alive timeout interval on the Web server or the proxy server. There is no setting in Microsoft Internet Information Services (IIS) to control the keep-alive timeout other than the Windows registry KeepAliveTime value. But with some Web servers and some proxy servers, you can specify a connection expiration time. If you can specify a connection expiration time in the Web server or the proxy server, increase the keep-alive timeout interval. See your Web server documentation for the correct setting name and value. The default keep-alive timeout value for Internet Explorer is one minute (60 seconds). Therefore, you must use an HTTP keep-alive timeout interval on the Web server or the proxy server that is greater than one minute. http://support.microsoft.com/kb/831167
• 
  
• Baseline Results
• 
  

Throughput reach 10mbps

• 
  
• 

Transactions, sessions objective reached

• 
  
• 

SYN and SYN/ACK = to 1

• 
  
• 

No frame loss on the stateless traffic

• 
  
• FLAP the Network!!!
• 
  
• 

TCP connection drop to ZERO as expected

• 
  

Stateless traffic packet loss duration logs at about 6.5ms of packet loss

After the HTTP command timeout values = 60sec sessions comesback again

• 
  
• Conclusion
• §

• Network resiliency tests are more accurate using stateless traffic generation and capture the accurate value via Packet Loss Duration method.
• Using Stateful TCP protocol is not the best way as the resiliency is dependant on many parameters like TCP timeouts and Application layer protocol time outs (In this case HTTP)
• Although Stateful protocols can be tweaked to achieve closer resiliency values (in this case, Command Timeouts), they are not real world scenarios.
• Ref: http://support.microsoft.com/kb/831167 for default Internet explorer time out values

• 
  

• 
  

• §

Courtesy of Bala