When troubleshooting or monitoring network devices, one traditional approach involves pinging the device. Unfortunately as you dig into ping, you will realize that it has many potiential issues that you may have forgotten or not be aware of. For example:
- Ping uses the ICMP protocol which may be blocked, spoofed, rerouted or treated with a lesser priority than TCP, skewing the response time or packet loss statistics.
- HTTP applications are not (or SHOULD not) be using ICMP for data transfers, so ICMP is a poor proxy for the actual application traffic. (HTTP uses TCP as a transport layer.)
- By default ICMP alows fragmentation, whereas TCP does not. On a brighter note, many pinging applications can change this ICMP fragmentation behavior, so its worth checking since many analysts will gloss over these settings.
- The default ping usually contains a very small data payload which will vary depending on the operating system or ping utility used, whereas HTTP packet sizes range from the smallest to a full size packet. This is an important point since the larger the packet, the longer it takes to transmit.
Due to the above potential issues, analysts prefer to use TCP or application level commands to determine a more accurate response time. One method used to accomplish this would be to capture packets from a real user, using the real application and on the real network. Anyone who has attempted this procedure can tell you that this approach has its own unique sets of challenges. For example, the analyst requires a thorough knowledge of protocol analysis and can be very time intensive. Another is that the typical "off the shelf" laptop cannot keep up with anywhere near typical network line speeds, resulting in dropped packets, and ineffective analysis.
Another realistic option is to have an application send a TCP connection request and measure the response time of its 3 way TCP handshake. A TCP 3 way handshake is required at the start of every TCP session. The same approach may be used for HTTP by sending commands and measuring the response time. This is one reason why the Application Infrastructure test in OptiView XG is so effective.
Another compelling point is the fact that the Application Infrastructure test doesn't need additional software installed on the HTTP server, nor do you need to modify firewall policies to allow test traffic through. During troubleshooting, the installation of software on a production server or modifying production firewalls next to impossible which makes this an important point to consider.
In this document you will be taken through how to set up a HTTP test that will measure HTTP and TCP response times from a production webserver without installing any additional software on the server.
As in all projects, preperation is the key to ensure a smooth implementation. For this exercise you will need the following information ready to make this go as smoothly as possible. The examples given are from devices on a test network; choose appropriate devices from your network.
- Determine a name to give this test.
- - In this case "test" was chosen
- Figure out the name or IP address of the HTTP server.
- - 10.44.10.52. (on our test network, yours will be different)
- Gather the URL of an image or other file on the webserver's webpage.
- - http://10.44.10.52/welcome.jpg which will retrieve this image from a webcam's http server:
To create your test, start by selecting Application Infrastructure from the Network Analysis menu on the OptiView XG user interface:
1. Click on New Application and enter the name you decided on earlier.
Enter the device name or enter its IP address.
Check "I want to configure tests manually".
2. For the purposes of our example, ensure the HTTP GET box is the only one checked
As you can see from the above options you can select various tests ranging from:
- ICMP: used to perform ping type tests
- TCP Connectivity: used to test TCP Ports
- Path Health: Performs a trace route (tracert) and Trace SwitchRoute test on the selected device and gathers routers and switch path information
- Interface Monitoring: Interface Monitoring allows you to monitor utilization and errors
- DNS Lookup: Performs a forward or reverse DNS lookup on the default DNS server and measures the response time
- HTTP GET: Performs a TCP port open request on the specified URL and measures the TCP response time from the server that is serving up the web page. It also requests the specified web page and measures the HTTP response time
3. This screen is critical to pay attention to dk - elipsis. Let's cover some points in detail to accommodate different environments.
- Test Name: The name displayed in the test tree on the left side of the screen as shown. The default name is HTTP GET but you should rename it to something more specific.
- OptiView Interface: Allows you to select which analyzer test port the HTTP GET request will be transmitted from. If you only have one port connected, you can leave the default interface. If multiple interfaces are connected, you can choose which interface to send the request through. Options include the Network Port, Management Port, or Wireless Port.
- Run this test: By default this is set to once every minute. If you set this test interval to manually, you must select Refresh to run the test.
- Save measurement history: Results will be trended and displayed in the History panel.
- HTTP Port number: This is the port the HTTP GET request will go through. You can select a port from the drop-down list or select User-defined ports with your own specific port number by selecting Add user-defined port.
- Website address: The Website address specifies the specific web page to be opened. It does not need to be specified for this test. Enter a valid URL in the correct form i.e. http://10.250.1.81/webpage.
4. Reviewing your results
This screen will display the status and results of your various tests.
Status: If the test was successful, the icon is green and red if the test fails.
Current Status: Reports how many devices are tested as well as how many tests have problems.
Response Time: Last response time recorded.
Last Tested: Records the last test run time.
Interval, History, Interface: Reflect your configuration test settings explained earlier.
These icons allow you to turn on/off the Results, History and Analysis panes:
Application Test | Results
This pane displays the destination ip address, URL and TCP port number used for this test.
The last HTTP response code is displayed
The total min/max/avg response time is reported.
The TCP min/max/avg response time is reported.
The HTTP min/max/avg response time is reported.
Response times are compared to the slow response time threshold which is configurable
Here is a sample if a packet capture of the OptiView XG performing a HTTP GET.
Packets 1 — 9 would be the Total Response time of 45ms
Packets 1 — 2 would be the TCP Port Open Time of 4ms
Packets 4 — 6 would be the HTTP Response Time of 17ms (42ms – 15ms)
Application Test | History
This pane is graphically showing the Total, TCP and HTTP response values over time. Use the magnifying glass to either zoom in (+) or zoom out (-).
This allows you to pinpoint when high instances of latency occurred and if it was TCP or HTTP related.
This report may be easier to read if you disable the Results and Analysis pane as illustrated below.
Application Test | Analysis
This pane is reporting how many times a specific response time is recorded.
This allows you to quickly determine what the distributions of the response times are.
In this example you can see a few response times that were over 1 second.
In conclusion, the HTTP Application Infrastructure test is an excellent way to measure and test various aspects of HTTP and TCP.