Let's say I have a capture from a typical web server. The capture contains a lot of HTTP requests and responses. Is it possible to create a filter to display only HTTP traffic with a response time higher than X seconds? By "response time" I mean the amount of time from the client completes the HTTP request to the server starts (or possibly finishes) serving the HTTP response. asked 04 Jul '11, 15:21  aatoga |
2 Answers:
A while ago I have started to work on a field that would measure the time between the request and the first packet of the response, the typical server time (not including network transport). However, this is more complicated than expected due to HTTP pipelining. I hope to find some time in the future to work on this again. In the mean time, the TCP timestamps are your best bet. You have to enable TCP timestamps in the TCP protocol preferences, but the you could use something like: For this to work, you need to disable reassembly (so that the first response packet is listed instead of the last packet of the response). This must be done in the TCP protocol preferences too (deselect "allow subdissector to reassemble tcp streams". answered 06 Jul '11, 00:45  SYN-bit ♦♦ |
You could start of with writing down what would be needed to "see" these times:
You could combine both filters to this: http and (http.request.method == "GET" || http.response.code == 200) and see GET's en OK's, you could then right-click a GET > set Time Reference and see how much time it took to the concerning OK, but that seems tedious... Maybe this works better: frame.time_delta_displayed > 1 and (http.request.method == "GET" || http.response.code == 200) This would result in displaying all GET's and OK's and see if there is a time delta bigger then 1 sec between them Your time display format should be "seconds since previous displayed packet" and you would still have to manually connect the dots...eg does this GET belong to this OK? Marc answered 05 Jul '11, 05:15  Marc edited 06 Jul '11, 00:38 SYN-bit ♦♦ |
Thanks, this helped med a lot. Turns out I was using an ancient version of Wireshark (<1.0), so I must admit I was not aware of the tcp.time_* fields and the "Calculate conversation timestamps" option. Actually, in many cases the delta between e.g. a SYN and a SYN ACK is useful as well, so I don't need to look all the way up to the HTTP level. Your tip does the trick for me :)