Wireshark Tutorial // Fixing SLOW APPLICATIONS

packet heads welcome back to my channel so today we're going to talk about how to spotlight tcp delays even in trace files that have a lot of different simultaneous conversations so stick around so in this channel we focus on wireshark tcp and how to analyze application and network problems as in this video a lot of times i'll share the trace with you and you can follow right along so go ahead and click the link in the description down below so you can download the trace file and you can follow right along while you're down there if you don't mind clicking subscribe or like if you enjoy this content okay so spotting tcp delays a lot of times when i share a trace file with you it's a nicely filtered trace it's just a single tcp connection but the reality is that when we're capturing problems on a network a lot of times we have larger trace files or files that have a lot of different simultaneous tcp connections happening in tandem so how can we find the ones that are slow or that one sole application response or that one spot where things get hung up that's what i wanted to show you today in this trace file so let's go ahead and open up wireshark and let's dig so a lot of times what happens in trace files when people are trying to find slowness what they'll do is they'll set up a delta time column and what that does is it shows us the amount of time between packets and here you can see in this profile i have a delta time displayed column now what i have seen some do is they'll come up to delta and they'll sort on that column then they'll hit the green down arrow and that will jump them to the bottom of the trace and this will show the packet with the most delay to the one previous and it sounds simple you might think okay great we found a packet that has 1.167 seconds between it and the one before we found the problem but really when we have a lot of applications a lot of protocols a lot of connections going on in the same trace file this number that we see is not in context it's possible that that measurement 1.167 seconds has nothing to do with the conversation that this packet is in now since i don't have a display filter the packet that came before this packet could have been anything an art packet icmp udp anything that has nothing to do with this packet itself what i want to do is i want to set up a new column and it's going to be a tcp time column that shows me this time measurement in context to the conversation let me show you what i mean let's grab any tcp packet and we're going to come down to our tcp details while i'm at it i'm just going to resort my frame number just to put everything back in order really doesn't matter as long as you grab any of the tcp packets here you're going to be fine let's grab one of those and we're going to expand tcp we're going to come down to time stamps i'm going to expand that and then below that i see time since previous frame in this tcp stream i'm going to right click that i'm going to go apply as column now because this is a little bit wordy up here and it takes up a lot of space what i'm going to do is right click it and i'm just going to say edit column now up on top i can remove the title and i can change it to tcp delta then i can squeeze this back together a little bit so now what this does is it gives me three different timers if you will i have my running total of time i have my delta time which is delta time displayed and then i have tcp delta so let's do this let's go ahead and sort the tcp delta column now and then i'm going to come up to the green arrow and then that will let me see the worst examples in the trace file so now check out what we have we have 19 seconds we have 20 seconds we have several 9.998996 seconds just above that so i have several packets where there were genuine delays now we didn't see this in the delta time because remember if we're unfiltered if we're just opening up any trace file that delta time won't show us the time in context to the conversation it just shows us from this packet to the one above it regardless of what that one above it was so here my eye this is what my eye does just to give you a little trick something that i look for is what is the direction of delay is the source the client or is the source the server now in this case with just a glance i can see 192.168.10 that was my machine going out and talking to a bunch of different systems but if i look for the ones where the server is the source those are the ones that my eye is going to zero in on now the reason for that there's several just to make it brief a lot of times the client side can have delays simply because the client is not reacting for example if i go out to a website and i'm going to need to punch in my username and password well i can go out to that site those things can be quick but then the time it takes for the user to punch in their username and password that can just take time so chris then my password enter whatever that amount of time is that can be client think time or client wait time so it's not unusual on the client to see these larger delays simply because the client isn't doing anything so be careful about shooting the messenger i'm not saying the client is never involved but it's not uncommon to see the bulk of the delays to be on the client side however on the server side those are the ones that i want to take a closer look at and here i can see a pattern too in this trace file notice that that's almost 10 exact seconds and i see it several times so what i want to do is come in here and i'm going to grab one of those packets coming from the server and now let's put this packet back in context i'm going to right click it and i'm going to say conversation filter tcp okay what we want to be sure to do at this time is sort our number column to put these packets back in order so now let's take a look at what we see here here we have our handshake we have our sin synax synthetic comes back 163 milliseconds later that gives me my benchmark network round trip time since i'm capturing client-side and here i can see that round trip time again here i see that round trip time again now as i'm coming down here i see packet 787 this is the server it sent some stuff to me the client comes and says it's packet 792 this is an empty acknowledgment there's no data there's no payload there's no segment data that's being transmitted from client back to server simply an empty ack and then after this ack we wait 10 seconds for the server to say the next thing now this is a tls handshake this is encrypted traffic so we don't know exactly what was contained within this application data in fact if we come down here we can usually see just a bunch of codes and things in there but what we do know is that this server was taking 10 seconds to get back to us so right there this is not a client-side problem the client wasn't the one waiting our network round trip is about 163 milliseconds around that i can see it waiver just a little bit but i'm having this persistent thing where this server is responding after 10 full seconds see now what i can do is i can start to move my analysis i know it's possible that we could set up some client-side key logging and we can decrypt this however i'm sure at this moment that i don't have to beat up on my clients i don't have to beat up on the network i know that i can trace that issue to the server side now there's a whole lot more that i could show you just with this trace file but the point of this video was to show you how you can quickly spotlight tcp delays even in larger unfiltered trace files just add a tcp delta time column and then sort that column and then that can help to pinpoint those tcp delays that you'll be looking for now remember don't over blame the client it's possible the client was just typing in a password so be sure not to shoot that side of the conversation well i hope you enjoyed this video on how to spotlight tcp delays in wireshark don't forget to subscribe and thanks for stopping by the channel so

Channel: Chris Greer

Views: 25,604

Keywords: wireshark, wireshark tutorial, wireshark beginners, slow applications, wireshark course, wireshark training, packet capture, tcp analysis, intro to wireshark, getting started with wireshark, wireshark tips, app analysis

Id: DDMOY3RTfGw

Length: 8min 42sec (522 seconds)

Published: Mon Dec 14 2020