I want to use wireshark (preferably tshark) as a sniffer for web server performance symbiotic simulation analysis. The countables of interest are:
For those I don't need the details, only counters (quantities). These need to be stored in the same file, with some text readable format, because another application will be reading and producing output from them. Does anyone know of a way to do that? |
Here is a way to count the tcp flags and HTTP get requests: $ tshark -r Clmt_04.pcap -qz "io,stat,0,COUNT(tcp.flags)tcp.flags==0x12" -z "io,stat,0,COUNT(http.request.method)http.request.method=="GET"" =================================================================== IO Statistics Column #0: COUNT(http.request.method)http.request.method==GET | Column #0 Time | COUNT 000.000- 115 =================================================================== =================================================================== IO Statistics Column #0: COUNT(tcp.flags)tcp.flags==0x12 | Column #0 Time | COUNT 000.000- 74 =================================================================== a.
(19 Dec '11, 10:52)
adonies
a
(19 Dec '11, 12:59)
joke
With this value, I get a count of tcp.flags(0x02) 41.478 in my capture file, while the http.request.method(GET) is at 33.280.
(20 Dec '11, 14:20)
adonies
So I'm assuming the traffic you're capturing has only the test sequences, so there aren't other TCP connections being requested, possibly for protocols other than HTTP or for HTTP where the first request isn't a GET. If so, what happens if you look instead for SYN+ACK from the server? If the initial SYN doesn't get responded to by the server, you'll get an initial SYN but you won't get a TCP connection and thus won't get a GET request.
(22 Dec '11, 15:17)
Guy Harris ♦♦
|
io,stat $ tshark -i 3 -qz "io,stat,120,COUNT(tcp.flags)tcp.flags==0x02" -z "io,stat,120,COUNT(http.request.method)http.request.method=="GET"" > io-stat.txt =================================================================== io-stat.txt =================================================================== IO Statistics Interval: 120.000 secs Column #0: COUNT(http.request.method)http.request.method==GET | Column #0 Time | COUNT 000.000-120.000 0 120.000-240.000 151 ===================================================================
io,stat
(20 Dec '11, 14:36)
adonies
1
To stop the capture after a timeout, use tshark's -a flag with duration:
(20 Dec '11, 15:15)
helloworld
io,stat
(20 Dec '11, 22:19)
joke
output to capture file
(20 Dec '11, 22:21)
joke
|
If your webserver tells you it served 33.280 objects and wireshark tells you it saw 33.280 http requests then all requests that were on the wire did get a response. Now your client tells you it requested 33.528 objects. So in 248 cases it was not able to get the request on the wire. Combine that with the fact that you saw 41.478 TCP/SYN packets, then you can imagine that there was a problem opening TCP sessions to the server. This can be either because the server was too busy to handle all the incoming connections, but this seems illogical as all HTTP requests were properly answered. It could also be that the webserver has a configured limit on the amount of concurrent sessions it can handle and you hit that limit. This would explain the SYN retransmissions and when it fails to get a TCP connection at all, the missing requests. BTW It's better to use the capture filter "tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420" to capture the GET requests, as this filter will work even when there are TCP options in the packet (it looks at the TCP header length and skips the proper amount of bytes to get to the TCP payload). Capture filter "tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420"
(22 Dec '11, 07:44)
joke
Is there a procedure in the TCP protocol spec for TCP/SYN retransmission?
(22 Dec '11, 12:46)
adonies
The TCP spec doesn't give a detailed procedure for retransmission; different implementations can use different retransmission timers and different count values for when it's time to give up.
(22 Dec '11, 15:20)
Guy Harris ♦♦
|
Thank you joke, helloworld, SYNbit and Guy Harris for your answers. I think I got the problem under control now. |