Running the Network Response Time Test
For our test, let’s examine the network response time to http://www.digg.com. The Nmap command line would have all of the prerequisites we detailed above:
#nmap -sS -P0 -n -p80 -d3 www.digg.com
As expected, this network response time test completes relatively quickly. Because of the inclusion of the level three debug mode, the resulting output is extensive:
[root@localhost ~]# nmap -sS -P0 -n -p80 -d3 www.digg.comStarting Nmap 4.22SOC2 ( http://insecure.org ) at 2007-09-23 19:07 EDT
Fetchfile found /usr/local/share/nmap/nmap-services
The max # of sockets we are using is: 0
--------------- Timing report ---------------
hostgroups: min 1, max 100000
rtt-timeouts: init 1000, min 100, max 10000
max-scan-delay: TCP 1000, UDP 1000
parallelism: min 0, max 0
max-retries: 10, host-timeout: 0
---------------------------------------------
Initiating SYN Stealth Scan at 19:07
Scanning 64.191.203.30 [1 port]
Pcap filter: dst host 192.168.1.9 and (icmp or (tcp and (src host 64.191.203.30)))
Packet capture filter (device eth0): dst host 192.168.1.9 and (icmp or (tcp and (src host 64.191.203.30)))
SENT (0.5820s) TCP 192.168.1.9:33148 > 64.191.203.30:80 S ttl=47 id=3024 iplen=44 seq=3109141542 win=4096
**TIMING STATS**: IP, probes active / freshportsleft / retry_stack / outstanding / retranwait / onbench,
cwnd / ccthresh / delay, timeout / srtt / rttvar /
Groupstats (1/1 incomplete): 1/*/*/*/*/* 10.00/50/* 1000000/-1/-1
64.191.203.30: 1/0/0/1/0/0 10.00/50/0 1000000/-1/-1
RCVD (0.6700s) TCP 64.191.203.30:80 > 192.168.1.9:33148 SA ttl=243 id=44149 iplen=44 seq=756273420 win=8190 ack=3109141543
Discovered open port 80/tcp on 64.191.203.30
Changing ping technique for 64.191.203.30 to TCP
Completed SYN Stealth Scan at 19:07, 0.11s elapsed (1 total ports)
Host 64.191.203.30 appears to be up ... good.
Interesting ports on 64.191.203.30:
PORT STATE SERVICE REASON
80/tcp open http syn-ack
Final times for host: srtt: 89463 rttvar: 89463 to: 447315
Read from /usr/local/share/nmap: nmap-services.
Nmap finished: 1 IP address (1 host up) scanned in 0.684 seconds
Raw packets sent: 1 (44B) | Rcvd: 1 (46B)
The important line of output appears near the end:
Final times for host: srtt: 89463 rttvar: 89463 to: 447315
This shows that Nmap considers a smoothed round trip time to this host to be approximately 89.463 milliseconds. The rttvar timeout value is usually calculated as five times this amount, or 447.315 milliseconds (the rttvar value isn’t very useful for scans involving a single open port).
The response time information taken from a trace file during the Nmap scan is nearly identical to Nmap’s output:
No. Time Source Dest Protocol Info
1 0.000000 Nmap digg.com TCP 33148 > 80 [SYN] Seq=0 Len=0 MSS=1460
2 0.088872 digg.com Nmap TCP 80 > 33148 [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1460
3 0.000306 Nmap digg.com TCP 33148 > 80 [RST] Seq=1 Len=0
The trace file shows a network response time of 88.872 milliseconds, closely matching the results from Nmap’s srtt timing value.
Important note for Windows users:
The test shown above was completed in Linux, and it shows that Nmap’s results are very accurate when compared to the trace file results from the operating system. However, running this test in Windows shows that Nmap’s values are slightly less accurate.
The same test to www.digg.com in Windows provided this value in the Nmap output:
Final times for host: srtt: 78000 rttvar: 78000 to: 390000
The trace file results from the Windows workstation are shown here:
No. Del Time Source Dest Protocol Info
1 0.000000 Nmap digg.com TCP 61150 > 80 [SYN] Seq=0 Len=0 MSS=1460
2 0.090967 digg.com Nmap TCP 80 > 61150 [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1460
Something doesn’t seem quite right here. The trace file results show a network response time of 90.967 milliseconds, but Nmap shows a network response time of 78.000 milliseconds.
Although Nmap’s network response time values in Windows are still close, they’re not as accurate as Linux. If you’re a Windows user, your actual network response time values may be a bit higher than what Nmap is reporting. You wanted another reason to build a Linux desktop, didn’t you?
Final Thoughts
Nmap’s built-in timing metrics provide a quick, easy, and accurate source of network response time information. When a “mean time to innocence” is needed, Nmap’s network response time information is much more precise than an ICMP timestamp, and the ability to focus on a specific port number provides a more accurate representation of the end-user’s response time experience.