Playing with Firefox and CWND has given me a hankering to make cool graphs.
No really.
The mozilla bug that spurred Firefox's new connection sorting by CWND had an associated blog post with some nice graphs in it.
Those graphs got me to thinking that I have no way of making nice graphs for SPDY Book (now in beta!). Hence the hankering for graphs.
Wireshark has some graphing tools under its Statistics menu. It even has Time-Sequence graphs (under TCP Stream Graph) that seem very close to what is in the Firefox post. But no matter what I try, I cannot get the graph to zoom into particular sections of traffic (at least that is how it was for me under Ubuntu).
That led me to investigate
tcptrace
which boast all manner of graphs, including the Time-Sequence graphs that I desire (via a -S
command-line option). Best of all, it runs against the tcpdump
data that I dumped into a file yesterday.Running the command yields:
➜ 30 git:(master) tcptrace -S -n 03-ducksong_ff.pcapIt takes me a while, but eventually, I realize that these are the 5 tubes opened by Firefox when it accessed the test page.
1 arg remaining, starting with '03-ducksong_ff.pcap'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004
6911 packets seen, 6911 TCP packets traced
elapsed wallclock time: 0:00:00.209689, 32958 pkts/sec analyzed
trace file elapsed time: 0:00:43.906356
TCP connection info:
1: 192.168.0.4:55906 - 64.22.125.164:80 (a2b) 8> 5< (complete)
2: 192.168.0.4:55907 - 64.22.125.164:80 (c2d) 7> 5< (complete)
3: 192.168.0.4:55908 - 64.22.125.164:80 (e2f) 6> 4< (complete)
4: 192.168.0.4:55909 - 64.22.125.164:80 (g2h) 1794> 2550<
5: 192.168.0.4:55910 - 64.22.125.164:80 (i2j) 1034> 1498< (complete)
The numbers in the last two columns (ignoring the complete column) are the number of packets that are sent in each direction. I am most interested in the largest connection that, by virtue of Firefox CWND sorting, should have been the tube that handled subsequent requests.
That ought to be the connection labelled
g2h
. I think the graph in which I am interested is the server response, not the client request side, so I want the h2g xplot output file:➜ 30 git:(master) ✗ ls -lRunning xplot against that file, I see:
total 21108
-rw-r--r-- 1 cstrom cstrom 6415796 2011-06-30 23:18 01-ducksong_chrome.pcap
-rw-r--r-- 1 cstrom cstrom 6409982 2011-06-30 23:18 02-ducksong_ff.pcap
-rw-r--r-- 1 cstrom cstrom 6420473 2011-06-30 23:18 03-ducksong_ff.pcap
-rw-r--r-- 1 cstrom cstrom 2124 2011-07-01 23:45 a2b_tsg.xpl
-rw-r--r-- 1 cstrom cstrom 2405 2011-07-01 23:45 b2a_tsg.xpl
-rw-r--r-- 1 cstrom cstrom 1888 2011-07-01 23:45 c2d_tsg.xpl
-rw-r--r-- 1 cstrom cstrom 2185 2011-07-01 23:45 d2c_tsg.xpl
-rw-r--r-- 1 cstrom cstrom 1609 2011-07-01 23:45 e2f_tsg.xpl
-rw-r--r-- 1 cstrom cstrom 1744 2011-07-01 23:45 f2e_tsg.xpl
-rw-r--r-- 1 cstrom cstrom 654658 2011-07-01 23:45 g2h_tsg.xpl
-rw-r--r-- 1 cstrom cstrom 809240 2011-07-01 23:45 h2g_tsg.xpl
-rw-r--r-- 1 cstrom cstrom 383019 2011-07-01 23:45 i2j_tsg.xpl
-rw-r--r-- 1 cstrom cstrom 473634 2011-07-01 23:45 j2i_tsg.xpl
Ooh! That looks about right. The bulk of the graph is the request for the large file that warms the tube (increasing the CWND). The last little bit on the right is the request for the small image.
Zooming, I see the request for the small image itself:
Nice! I expected a straighter line than that, but the time between the first segment and the last is about right. That will do for today. I think these graphs will server quite nicely for my purposes in SPDY Book.
Day #62
No comments:
Post a Comment