How TCP Works - Duplicate Acknowledgments

hey welcome back thanks for stopping back by my channel today we're going to talk about tcp duplicate acknowledgements you don't have to look far in a tcp trace file to find some of these but sometimes we see one two or three of them and sometimes we see hundreds of them what do they mean what do we do about them how do we troubleshoot them well let's go ahead and dig into a trace [Music] so on this channel we talk about wireshark how tcp works really all things packet analysis and we like to get into the nitty-gritty of network problems and how to fix them so if you're new here go ahead and consider subscribing and thanks for stopping by so tcp duplicate acknowledgements absolutely a question that comes in and really what do they mean does it mean the sky is falling is my network being ripped apart at the seams are my applications falling from the sky well no in a lot of cases it's actually a healthy part of how tcp works it just means that tcp is recovering from something but before we dig into the trace file you can get the link to that trace that i'm going to use in the description down below first let's take a look at how duplicate acknowledgements really work all right so let's just imagine that we have a client a server they're just connected to a switch no latency between these two devices so the server sends out a couple of packets right sends out some data and as that data comes in the client begins to receive it now under normal conditions with no packet loss the client would usually send at least two acts in this scenario or maybe one but most cases we'll see two so it's going to act these two packets together it's going to say okay i'm good to here in one acknowledgement and then it's going to say great i got these two now i'm good to hear in the second acknowledgement either way the server knows that everything that it sent was received by the client but let's just imagine uh oh on the way one of these packets gets smashed the network drops it so now we have a missing block in our tcp sequence numbers so what will we do in this scenario well again as long as both sides are supporting selective acknowledgement which most modern stacks these days do what the client's going to do is it's going to say okay good i'm i'm good to this point i'm good to that sequence number so this is going to be the acknowledgement number that it uses in that first act that goes but then as the next packet comes in keep in mind we never receive this one the client's going to say wait a second there was a gap in sequence numbers so it's going to generate another ack and it's going to do so just for this block of sequence numbers that we receive it's going to use this same act number though it's going to say hey i'm good to here that's going to be in the actual tcp acknowledgement field that it sends but it's going to generate it's called a sac block so basically it's saying hey server i'm good to hear thumbs up and i also got these sequence numbers but that act that it sends the server is going to look like a dupac that's what wireshark is going to flag it as and the reason is because we use the same act number in that new acknowledgement now in this scenario we might only see one or two dukebacks and that's pretty common you'll see that in your trace files from time to time where things get a little sticky is when we add more latency between the client and server so let's take a look at that scenario all right so now we have 150 milliseconds of time between the client and the server so now the packet train that comes out from the server is going to have a whole lot more packets in it so now instead of just three or four so to speak it's going to have it could have hundreds out on the wire as long as we have a healthy tcp receive window on the client and we have a healthy congestion window or send window on the server we can have a lot of packets in this packet drain between these two endpoints all right so let's imagine that early on in our packet train one of these first packets goes missing okay so what's the client going to do well it's going to acknowledge hey i'm good to this point i've got these first two segments but it's going to sense that there was a gap in the sequence number because hey we lost a packet here so now what it's going to do is every ensuing acknowledgement until we see this gap field every ensuing acknowledgement it's going to send an act for every single one of these packets that it receives but every acknowledgement is going to be a do back the reason is because we're good to this point and as each new sequence arrives we're going to grow that selective acknowledgement block that's in our tcp options okay so in this case i could have hundreds of packets after that point of loss that means that i could have hundreds of do packs until i see a re-transmission again those two endpoints are just really far apart so sometimes it's fast on the recovery we only see a couple of dupaks because the client server real close the server got the message it sent the retransmission and now we're good to go but hey if we're talking to a server that's a long way away it can take time for our axe to get there and for it to generate that re-transmission and send it keep in mind when we see a gap in our data we're going to send dukebacks until that gap is filled so that can take some time and we can see hundreds of dukebacks but now let's go ahead and take a look at this in our trace file so you can go ahead and download the trace file again in the description down below and you'll notice in my copy of wireshark this time instead of using tcp plain which a lot of times you guys see me use and that's the profile that i have down here instead this time i'm using tcp analysis so under this profile i have a lot more columns here that help me out when i'm doing sequence number analysis sorry i can see sequence number i've got next sequence number i've got acknowledgement number calculated window size all of these come in really handy when i'm doing sequence number analysis so suggest a suggestion for you if you want to be able to do some of this analysis maybe a little faster okay so here we've got our handshake and just by taking a quick look at our options in our handshake if i just expand tcp there i can come down and i see that i do have sac permitted that's going out from the client to the server come back 21 milliseconds later i see sac permitted in the opposite direction so good to go we can use sac this means that when we do have a lost chunk of sequence numbers we'll probably see some dewbacks and some sac blocks all right so let's actually see this in play if i come down here to that first ugly line with red letters is packet number 57 and i can see here by my sequence number that i had a jump in sequence numbers that's why wireshark flagged this what i should have seen here if i was having continuous data i should have seen 24 845 in this direction i can see that here so the packet previous to this 23 397 if i add my segment length that was sent my next expected sequence number in this direction should be 24 845 it wasn't the next one that i actually received was 26 293 so i'm missing the data between 24 845 and 26 293. so i want to start to let the server know hey i'm good to this 24 and i'm good from 26 on but you got to go back and resend me that missing chunk server sent two packets two full size in this case packets in my direction and this is where if i turn around and take a look at that dupe act this first dupac dupac number one well first of all let's look at why this is a dupac well wireshark saw the act number 24845 and it went wait a second i've seen this number before in this direction if i come up here i've already seen this act number hey chris you're duplicating the act number that's why it's a dupac we've already seen this act number before but in this case you might be saying hey chris how about packet 56 how come that's not a dupac well we saw 24 845 but in this case we just saw an increase in our receive window you see my calculator window size on the receiver it was 28k and then it went up to 131. so whenever we see the same act number but the receive window grows by a little bit wireshark just says hey that's just a window update you're just letting us know that you have more space you maybe cleared out a little space in the receive window now you have more room in your receive buffer that's why that's not called technically a do back here however down here we got the same receive window and same act number dupac but in this case if we take a look at packet 59 we can come down to our options and this is where we can see our first sac block 26 293 to 27 741 so now we're gonna start to see instead of a single ack acting several packets because tcp can do that i don't i don't have to send an ax for every single packet tcp likes to be efficient so with one i can acknowledge several larger packets that came in the opposite direction two four in some cases six who knows so i the point is i don't have to send an act for every single segment that comes in however after a point of loss i'm gonna start to act every single packet all right so that's where you'll start to see more acts once we see a missing gap of sequence numbers so we have a dupak of 55. we're good to that sequence number but as 57 came in and 58 came in we sent two dukebacks all right and we're gonna start to see that sac block grow down there well the server hasn't yet gotten that information so the server was already sending a chunk of data in flight so we can see all these big packets boom boom boom boom boom boom you see our sequence numbers 29 30 32 this girl is all the way down to 62 493 the next expected one should be 63 941. now the client's going great that's awesome um okay so we're good to that solid point of 248.45 but hey mr server uh i went ahead and acknowledged the new stuff you sent but don't forget about this missing sequence numbers that missing sequence numbers is between the act number and the left edge that we see down here now that left edge is going to grow through these acts as the zac come in do back do back do back let's just see that left edge grow you see it grow down i'm sorry the right edge see how it grows that means we're acting new data as it came in while telling the server hey don't forget i need that missing data that's right there well the server hasn't yet gotten the hint it still hasn't sent it so packet 109. here's more data that came in the client thank you thanks for that new data by the way get the hint dupac27 i still haven't received that stuff that i'm missing so here we see the server pause for a second this is 17 milliseconds of delay and that's loosely what our network round trip time is if we go up to the handshake we can measure that but it's about that amount so we can assume that our acts have made it to the server and the server has begun to react to them in fact if we take a look at this we can see four packets one two three four came from the server and then the server sends a re-transmission so it probably already had this queued up for sending in its send buffer so it went ahead and send what it had to send and then as it received those dupacs it could begin to react and really it's called a triple double as soon as i receive three new packs then i can go okay i'm pretty sure that i'm pretty confident that those sequence numbers went missing let me generate a re-transmission and that can trigger a fast re-transmission so that's what we see here if we take a look at the sequence numbers 24845-26293 so this is exactly those sequence numbers that went missing so the server got the hint it went ahead and sent that missing data and it even did so while it was sending that new burst of data that from that opposite side now if we come down here to the client we still see dupacs and the reason if i go ahead and readjust my view here the reason why we still see do packs after getting that fast retransmission is because keep in mind before the retransmission we still had four packets come in prior to receiving those sequence numbers so the client is going to react to those four packets that came in and it's going to do so with dupac's right so keep in mind every when i lose some sequence numbers everything after that is going to have a dupac with a growing sac block as long as we're supporting sac but every single packet is going to have one of those until that data is replaced and that's retransmitted so these four packs correspond with these four data packets up here but notice what happens after this last dupac this dupac number 31 right after that one i'm good to 71 181 okay so if i select that packet that means i'm good all the way to here and if i select the packet after that i'm starting to acknowledge new data as it comes in and now i'm doing so with not every single packet but i've backed off now i can acknowledge two packets at a time so there's a little practice with duplicate acknowledgements hopefully that helps you understand better why in some cases you'll see one or two dupacs and then a re-transmission well in some cases you'll see hundreds of dupaks again really understand your latency how far apart are the client and server how far apart are those endpoints in terms of time how much data has gone in flight and how much time is there for acts to be sent back to the server before that retransmission is triggered so thanks for stopping by i hope you enjoyed learning a bit more about tcp and if you like this video go ahead and smash the like button down below i'll see you on another video

Channel: Chris Greer

Views: 21,925

Keywords: wireshark, tcp/ip, tutorial, acknowledgment, packet analysis, chris greer, troubleshooting, tcp, how tcp works, Wireshark, networking, TCP, Transport, Protocol, TCP Handshake, wireshark training, wireshark tutorial, packet capture, tcp analysis, tcp connections, network infrastructure, network protocols, tcp dup acks, tcp duplicate acknowledgement, tcp selective acknowledgement, tcp duplicate acks, free wireshark training, free tcp tutorial

Id: KWiHAMDbrng

Length: 14min 13sec (853 seconds)

Published: Mon Aug 03 2020