Wireshark Tip 3: Graph HTTP Response Times

hi this is Laura Chappell and this is Wireshark tip 3 now if you want to follow along with the Wireshark tip series you can follow me on twitter at Laura Chappell in this tip I'm going to show you how to graph HTTP dot time that's HTTP response time which is a new feature that came out with Wireshark 1.10 so I've opened up a trace file called HTTP - Wireshark download pcap ng and you can see in this trace file we have a get request - to download the page called download HTML now if you didn't look back at tip number one you might want to do that because I'm going to change this setting for TCP I actually want to see the response code right here in the packet in which it actually occurs rather than way down here the response code is actually right here in frame number 6 here I can actually see it down on the packet bytes pane so to make that change I'm going to select the TCP header right mouse-click protocol preferences and uncheck allow sub dissector to reassemble TCP streams now we can see the response code in the info column so here's the new field that came out with Wireshark 1.10 and you can find the new field when you expand the HTTP header section in the detail window so as I go down to the bottom we will see HTTP response 1 of 1 and there is our HTTP time field and you can see when you highlight that line that down on the status bar Wireshark tells us the display filter syntax and display filters are what we use in our graphs so I'll be using that to graph my HTTP response times we can also right mouse click on that line and add it as a column which is a great thing to do for HTTP analysis all right mouse click and choose apply as column and now I have a new column that says time since request I can click on it twice to sort from high to low and then go to the top of the list to see the highest response codes and we can see that there are some pretty bad response times I mean I would expect to see times faster than this 202 almost 203 milliseconds just for the server to come back and say okay when I made a request for a simple Gipp file so now I'm going to build a graph that will show me where I have spikes in the HTTP response times I'll go up to statistics and i/o graph and of course the default I uh graph is to show us all of the traffic and I really don't care about that so I'm going to turn off graph number one in graph number two I will simply enter in the filter HTTP dot time and then turn on that graph and this shows me that there's a spike in time right up towards the beginning of the trace file I can move that down a little bit out of the way and we can also apply this to other trace files and and remember that this is summarized for the one second interval so we may want to move in just a little further to see a more granular view of response time delays so here we can see we have a number of delays that are showing up at the beginning of this trace file and then four seconds into the trace file we start seeing some more delays I'm going to leave this graph window open don't close the i/o graph window when you move from trace file to trace file Wireshark will automatically recreate this graph based on the next trace file you open so I'll open up trace file that I know has got some pretty serious delays the trace file is called HTTP - Facebook and this is one of the trace files that you can get from the Wireshark book.com website so here is and I can already see in my time since request column I've got a pretty high number in here but I'm going to toggle over to my graph and then looking through the graph I can see the points where I have some higher delays in this graph and we can see that it's applied the graph to HTTP - Facebook dot pcap ng remember that you can always sort any column that you add so if I go to the top here I can see this packet right here frame number 11 oh I didn't mean to move that let me move that back I move my source column frame number 11 shows up with a tremendously high delay here three point four seconds before the server turned around and said 200 okay let me give you a warning here on graphing this information when I first started showing you this this process in Wireshark I mentioned that I set my TCP reassembly off let me take you to that first trace file I had open I was HTTP - Wireshark download and we can see in this trace father since an ack-ack and there's the get request there's the ACK and there's the 200 okay notice the time value it's a little over 44 milliseconds I will turn on that TCP reassembly setting which is the default for Wireshark I'm going to bring it down a little bit so it goes up there so I'll go back to the default setting in Wireshark to allow sub dissector to reassemble TCP streams now this will change the results that I get in my graphs so it's important that you turn off that setting if the setting is on this is what I'll see I'll see the get request I'll see the ACK and then I see TCP segment of a reassembled protocol data unit or PD you this is actually the packet that contains the 200 okay that's the packet that contains my response code though my 200 response code and that's the packet that I would like to have time-stamped as the response packet but instead because I have reassembly enabled here I can see that Wireshark shows me TCP segment reassembled protocol data unit it keeps going keeps going ACK and everything and then the last packet of the download for that item that page is the one that is time-stamped so that would give me an artificially high TC or HTTP response time if I left that setting that way so make sure when you're analyzing HTTP traffic that you have your TCP preference setting for allow sub dissector to reassemble TCP streams off and that will give you an accurate HTTP round-trip time if you'd like to follow along with this Wireshark tip series as I release the tips on Twitter you can follow me at Laura Chapel for more Wireshark tips and training visit Chapel eucom

Channel: Laura Chappell

Views: 20,608

Rating: 4.909091 out of 5

Keywords: Wireshark (Software), Http, troubleshooting, how-to

Id: FMRI6ua2MjE

Length: 7min 12sec (432 seconds)

Published: Sat Jul 20 2013