TCP - 12 simple ideas to explain the Transmission Control Protocol

TCP has been at the core of internet communication for the last 40 years and in this video I'm going to show you why [Music] hello everyone this is Ed harmush welcome to another lesson in the TCP and UDP Master Class this lesson is the Keystone lesson in this lesson we're going to show you exactly how TCP works now in the last lesson we unpack TCP as it compares to UDP we talk through all the different things that TCP is said to be able to do if you want a definition of what each of these things are I would recommend you check out the last lesson in this lesson we're going to show you exactly how TCP does all these things that's going to let us explore the TCP header in more detail now I have broken up all the main ideas you need to understand about TCP into 12 simple distinct ideas if you can follow me through these 12 ideas then you'll be able to say that you understand TCP better than most discussing these 12 ideas will have us explore some of the fields inside the TCP header specifically we're going to be looking at these three Fields the sequence number the acknowledgment number and the window or the window slides and these four Flags the ARs and f blacks to illustrate all these we're going to be simulating a TCP connection between Alice and Bach the setup for this is that Alice and Bob are computers that are running software some sort of application and that application has just given to TCP a bunch of bytes a bunch of data that needs to be sent to the other side and with that as our starting point let's get into the first idea of TCP which is to define the sequence number and acknowledgment number the sequence number is a number that is going to be used to track the bytes that are set and the acknowledgment number is a number that is going to use to track the bytes that are received so let me show you how that works let's say Alice shoots a packet over to Bob she's going to add to that packet a sequence number of 101 that's going to exist inside the TCP header of that packet in order to confirm reception of that packet Bob is going to send another packet with an acknowledgment number of 102. the only way Bob could have sent 102 is if Bob had received 101. if Alice has started with something like 501 then Bob would have had to send 502 to confirm reception of this particular packet upon receiving this acknowledgment this tells Alice that Bob definitely received his first packet which will now allow Alice to send the next packet which is going to be labeled with sequence 102. then Bob to confirm receiving this packet will send another acknowledgment this time including the number 103 in the acknowledgment number field this will prove to Alice that this packet was received and Alice will continue sending another packet this time labeling it with sequence 103 which will allow Bob to confirm reception of that packet by acknowledging it with a acknowledgment number of 104. so that is the basic premise behind the sequence number and the acknowledgment number notice that the sequence number is tracking what is sent and the acknowledgment number is tracking what is received idea number two about TCP is going to further refine our understanding of sequence number and acknowledgmentary numbers you see sequence number and acknowledgment numbers are not actually a measure of packet set they're actually a measure of bytes sent or received so these numbers that we use over here aren't technically accurate I was just using those numbers to simplify the definition of sequence numbers tracking what is sent and acknowledgment numbers tracking was received more accurately would be numbers like this Alice's first packet it's going to include a sequence number in this case 1001 and it's going to include 200 bytes of data included in that segment upon receiving this packet Bob will confirm reception of that packet by sending acknowledgment number 1201. 1201 is what's going to acknowledge receiving the 200 bytes starting from sequence number 1001. once Alice gets this she can then send the next segment this segment is going to start at sequence number 1201 and also include 200 bytes and as you can imagine Bob will then confirm reception of this by sending acknowledgment number 1401. this will now prompt Alice to send the next segment this next segment is going to start as Bob expected at sequence number 1401 this particular segment only includes 100 bytes which means Bob to acknowledge receiving those 100 bytes will send an acknowledgment number of 150 1. understanding the way the sequence number acknowledge your numbers work is actually very important and a critical component of TCP so I want to focus on this just a little bit further this will help us later on when we're trying to understand idea 7 9 and 11 later on in this video notice that if you add the sequence number to the number of bytes that'll tell you the acknowledgment number required to acknowledge reception of that segment 1001 plus 200 equals 1201 and that's what Bob used to confirm reception of this segment notice that is also the starting sequence number that the sender is going to use for the next data packet again 1001 plus 200 is going to equal 1201. you'll see this again in the next exchange between Alice and Bob notice 1201 plus 200 is going to equal 1401 which is the acknowledgment number Bob used to confirm reception of this segment and the sequence number that Alice is going to use for the next data packet now let's explore that exchange a little bit further because I really want to drive this point home inside this segment sent by Alice is 200 bytes of data and to represent them we'll use these rectangles every one of these rectangles represents a single byte so these would be the first five bytes in the set of 200 and these would be the last five bytes in the set of 200. the first byte in that set is going to be labeled with the sequence number that was inside the TCP header and every byte that follows can be identified as an addition to that sequence number meaning the second byte in that packet is by 1202 and the third byte in that packet is by 1203 and the 199th byte in that packet is byte 13.99 and the 200th byte in that packet is byte 1400. when Bob then sends act 1401 what he's saying is I have received everything before byte 1401. or said another way Bob is saying I am now ready for the next byte that you send me and that bite should be starting with sequence 1401. and that indeed is the sequence number that Alice is going to use for the next data packet that she sets so you see TCP actually tracks everything sent on a byte byte basis and it's going to use sequence numbers to track the bytes that are sent and acknowledgment numbers to attract the bytes that are received that takes care of unpacking the definition and operation of sequence number and acknowledgment number idea number three about TCP has to do with how TCP handles situations where packets are dropped on The Wire between Alice and Bob the way it works is every time TCP sends something it's going to keep a copy of what was sent in cash or a duration known as the re-transmission timeout then if an acknowledgment is not received for the segment that was sent this segment is simply going to be reset here's how that works let's say Alice sends a segment to Bob starting with sequence number 1501 and including 200 bytes as she sends this she's going to keep a copy of that packet in cash and start the re-transmission timeout if Bob receives this packet Bob will send an acknowledgment of Acts 1701 and if Alice receives that acknowledgment then she can simply delete what she had in cash because she knows that Bob received it she no longer has to keep track of those bites since Bob definitely got it on the other side that'll then prompt Alice to send the next set of packets and let's just say something happens on the wire with this packet and doesn't actually make it to Bob well once again Alice kept a copy of that packet in cash and started that re-transmission timeout and since Bob never received this packet Bob can never actually send an acknowledgment which means inevitably this timer is going to expire and once it does Alice will realize that she hasn't received an acknowledgment for this set of bytes so she'll go ahead and re-transmit that packet she can do this because she kept a copy of that packet in cash this packet notice is identical to the packet that was sent earlier it's starting from sequence number 1701 and includes the same 200 bytes and let's just say for the sake of this example that this packet actually makes it through and above Bob Bob is going to return with an acknowledgment of 1901 and this tells Alice that those 200 bytes have been received and therefore she can erase this information from Cache knowing that those 200 bytes actually made it over to pop so that is how TCP handles situations where packets are dropped on The Wire now the cool part about how this works is that it works if packets are dropped in either direction we simulated this packet being dropped sent from Alice to Bob let's just say that packet actually made it through and Bob's acknowledgment is what was dropped on the other direction well in the end the same situation would occur Alice said something and never received an acknowledgment for what she sent so she's simply going to retransmit Bob having received both of these segments will know that they both start from sequence number 1701 and both include 200 bytes so Bob will know that this is actually a duplicate of what was sent before and since Bob knows that this is a duplicate of what was sent before Bob isn't going to try and keep two copies of the same set of bytes Instead This sort of Clues Bob in to something must have happened to the acknowledgment he had sent earlier and he'll simply respond by sending the exact same acknowledgment act 19 at 1. so you can see that this system of re-transmission timeout and keeping the packet in cash handles packets being dropped in either direction that takes care of discussing idea number three about TCP idea number four has to do with how often the receiver has to acknowledge what is received initially with TCP the receiver was sending an acknowledgment for every single segment received the issue with that is that effectively doubles the amount of packets that need to be put on the wire meaning if Alice sent 100 packets to Bob Bob would have to send 100 acknowledgments for each of those packets to reduce that burden and optimization was added to TCP known as delayed acknowledgment which allows the receiver to acknowledge every other receipt packet here's how that works Alice is going to shoot off a packet to Bob this packet includes 200 bytes and starts with sequence number 1001. then Alice is going to shoot off another packet debug now having received both of these packets Bob is going to acknowledge both of them by sending this acknowledgment number acknowledgment number 1401 says I have received everything before 1401 which includes the 400 bytes that was just sent by Alice notice that the acknowledgment number is cumulative this single acknowledgment is going to acknowledge both of these packets and really everything before 14 who won upon receiving this acknowledgment Alice will then send the next two packets in the sequence both of these are 100 byte packets for this example and Bob will confirm receiving both of those with a single acknowledgment acknowledging 1601 which is going to include these two packets again if we take the last sequence number sent by Alice and add the number of bytes that will get us the next acknowledgment number that Bob is going to use to confirm reception of these two packets what happens if Alice has an odd number of packets that she's going to send and she sent two here and Bob acknowledged she sent two here and Bob acknowledged what if this is the last 200 bytes that you need to send Bob will never receive a second packet and therefore never send that last acknowledgment but lucky for us the folks that created the delayed acknowledgment RFC accounted for the situation and they said that a acknowledgment is going to be sent every other packet or no more than 500 milliseconds from the last packet this way if there's an odd number of packets the acknowledgments will still come Bob after waiting the 500 milliseconds for a potential second packet we'll then send this acknowledgment number confirming he received these 200 bytes so that is idea number four known as delayed acknowledgments idea number five is related but sort of from the other perspective so I actually want to show them both to you on the same screen to clearly identify how they are different from each other idea number four was a governance on how often the receiver Bob in this case was sending acknowledgments whereas idea number five has to do with how much data the sender can send before it must wait to receive an acknowledgment number idea number five has to do with the window size the window size sets a limit on how much data can be sent before the sender has to stop and wait for an acknowledgment the window size is something set by the receiver so in our example Bob is the receiver and Bob sets his received window size of 500 bytes which means Alice can only send 500 bytes at a time before she has to stop and wait for an acknowledgment from Bob now how Alice knows that Bob had set a window size of 500 is something we'll talk about in idea number six but for now simply take it as fact that Alice knows the window size for this connection is 500. in any case Alice sends off the first packet and this first packet includes 200 bytes which means Alice can now send only another 300 bytes before she has to stop and wait for it acknowledgment so Alice then sends the next segment which also includes another 200 bytes it's going to reduce how many more bytes Alice can send to 100 and now if Alice has another 200 byte packet that she means to send she cannot because the window size wouldn't account for it she can however send a 100 byte packet which would reduce her remaining window size down to zero where she'll finally have to stop and wait to receive an acknowledgment from Bob the concept of a window size is sometimes referred to as bytes in flight notice 500 bytes is how many bytes can exist on the wire in the path between Alice and Bob before they get acknowledged by the other side that is the idea behind bison flight in any case upon receiving these 500 bytes Bob is going to confirm receiving those 500 bytes by sending a single acknowledgment number in this case acknowledgment 1501 remember acknowledgments are accumulative so 1501 would confirm the reception of all 500 of these bytes that is going to now reset Alice's window size back to the max which is 500 and now Alice can continue sending data to Bob so again her first next packet is 200 bytes reducing her window size to 300 another 200 bytes reduces it to 100 and then finally another 100 byte receives this to zero and now she has to stop and again wait for another acknowledgment from Bob which is going to show up with acknowledgment 2001. that is the idea behind the window size understand how it's different from idea number four and delayed acknowledgments the window size is referring to how much data the sender can send whereas delayed acknowledgments has to do with how often the receiver is sending acknowledgments now normally Bob would indeed be trying to send an acknowledgment after every second packet but for the sake of this illustration and showing you idea number five I skipped that part of TCP which brings us back to a question that we asked earlier Bob set his receive window at 500 bytes but how did Alice know what that receive window was that has to do with idea number six idea number six is that the window size is actually sent in every single segment remember that the window size is actually a field in the TCP header so every TCP segment sent between Alice and Bob includes a window size field which means these acknowledgments sent by Bob also included the window size that Bob intended to use but how did Alice know that the window size was 500 before this first acknowledgment sent from Bob that should be a clue that something had to happen before data was sent between Alice and Bob in order to establish the initial window sites but more on that later for Now understand that the window sites have actually set in every single segment the additional benefit to the window size being sent in every single segment is it can actually be updated throughout the life of the connection this is how TCP does what is known as low control so let me show you let's just say that at this point in the conversation Bob is receiving too much data too quickly Bob still wants to confirm having received those 500 bytes but wants to slow down how much data Alice is sending at a time but what Bob can do is send act 1501 to confirm receiving these 500 bytes but then also send the window size which exists in each segment of zero this is instantly going to reduce Alice's send window size to zero and force her to stop sending data until Bob sends another acknowledgment number Bob can use this time to process the data he just received from Alice or more than likely process all the other data he might be receiving from other people connecting to Bob at this exact same time then once Bob has caught up you could say He can then send another acknowledgment indicating he is now ready for more data notice the acknowledgment number is the same well that makes sense because Bob hasn't received any more data in between those two acknowledgment numbers and notice Bob now increases the window size to 600 maybe he's cleared out a lot of information in the backlog and is ready for more data upon receiving this acknowledgment number and window size update to 600 Alice can now send 600 bytes of data before she has to stop and wait for another acknowledgment so Alice can now continue sending data to Bob she'll send 200 bytes then another 200 bytes then another 200 bytes and Bob will confirm receiving those 600 bytes by sending act 2101 notice in addition Bob changed the window size now to 500. that's the benefit of the window size being set in every single segment is the receiver can fine tune the window so that he's always receiving at the optimal rate that is idea number six and that is how TCP does what's known as flow control okay we're at the halfway point do you fully understand ideas one through six that we just covered make sure you do because everything we cover going forward is just going to build upon what we've already learned with that said to understand idea number seven I want to pull back a sequence of exchanges that we looked at earlier in this video so far in this lesson we've been looking at Alice as the sender and Bob as the receiver specifically we've been looking at Alice's sequence numbers tracking what she has sent in Bob's acknowledgment numbers tracking what he has received but TCP is actually bi-directional which means both parties can send data to each other which means both parties actually have a sequence number and both parties actually have an acknowledgment number so it's not just that Alice uses a sequence number to track what she has sent and Bob using an acknowledgment to tracking what he has received it's also that Bob has his own sequence number independent from Alice to track what Bob sends to Alice and Alice has her own acknowledgment number to track what she has received from pop with idea that number seven in mind let me show you what the exchange would look like Alice is going to start by sending this packet this packet starts with sequence number 1001 and includes 200 bytes notice Alice has an acknowledgment that she is including in this packet and how she knows to start at 3001 will be answered in the next idea in any case to acknowledge receiving this segment Bob is going to respond with this acknowledgment act 1201 is going to confirm the reception of the 200 bytes starting with sequence number 1001. but notice in this segment Bob is also including 300 bytes of his own that he is trying to send to Alice and if we apply what we learned before sequence number 3001 plus 300 equals 3301 and that'll be both the next sequence number that Bob starts with or the acknowledgment number that Alice use to confirm receiving these 300 bytes in our illustration Bob is going to send the next packet and notice that it's going to start at 3301 just as we deduced this packet also includes 300 bytes so if you do 3301 plus 300 that gets us 36.01 and that indeed will be how Alice will acknowledge receiving these 600 bytes her next segment is going to include acknowledgment 3601 but it's also going to include 200 bytes of data and her sequence number is going to start at 1201 which is both what Bob has been acknowledging and is expecting as the next sequence number and the result if we add 1001 Plus 200. so with this one segment Alice is both acknowledging what she just received from Bob and sending another 200 bytes what comes next is something from Alice in this example and notice it's going to start at sequence number 1401 which is that which you would get if you added 1201 plus 200 and this is also going to include another 200 bytes so if we did 1401 plus 200 we should expect sequence number 1601 is the next thing that Al sends or acknowledgment 1601 is the next acknowledgment that Bob will set and that's what we have here notice in this acknowledgment Bob is sending zero bytes remember we talked about delayed acknowledgment back in idea number four well Bob just received two segments and now has to send an acknowledgment to confirm having received these two sentence that is why you have a zero byte acknowledgment and this happens with TCP all the time next Alice is going to send another data packet another 200 bytes and as expected that's going to start with sequence number 1601. that is the idea behind number seven a TCP is bi-directional both parties can send data therefore both parties have their own independent secret sequence numbers that is used to track what they sent now I do want to point out a couple of things notice here Bob is sending two segments in a row with the exact same acknowledgment that makes sense because in between these two segments Alice hasn't sent any new data so in either case of these two segments the last received byte was 1200 and Bob is confirming that he is now ready for 1201 you'll notice the same thing occur over here when Alice is acknowledging 3601 twice in a row because again she hasn't received anything new from Bob understanding how sequence numbers and acknowledgment numbers track with each other is very important if you're going to be doing any sort of TCP troubleshooting you have to have this skill so I'm going to highlight the conversation from Only One Direction here you're looking at the numbers of Alice's sequence number and Bob's acknowledgment numbers and what you'll notice is that these are actually the exact same sequence of acknowledgment numbers we've looked at in ideas one through six now all we've done is also added Bob's side of the conversation to our illustration and Bob just like Alice had his own sequence numbers that he's using to track what he has sent and Alice is using her own acknowledgment numbers to track what she has received that is the concept behind idea number seven now there's still a question that we haven't answered how did Alice know to start at acknowledgment 3001 well that actually brings us to idea number eight idea number eight has to do with the starting sequence number also known as the initial sequence number or the ISN and the way it works in TCP is each sender is going to randomly choose their own sequence number so for this illustration Alice choose an Isn of 1000 and Bob chose an Isn of 3000. but how do they know each other's starting point if they each picked it independently these initial sequence numbers have to be shared before data can actually be exchanged between Bob and Alex that's what brings us to how TCP connections are established and what's known as the three-way handshake the core purpose of the three-way handshake is to exchange these initial sequence numbers and that's what actually brings us to idea number nine which is how this conversation even started every TCP conversation starts with what's known as a three-way handshake but inside a three-way handshake four different events are occurring and I want to start by highlighting each of those four events in our example Alice is going to initiate this TCP connection but it could happen in the other direction as well so Alice is going to start by sending a synchronized request to Bob this is where Alice Picks a initial sequence number randomly and shares it with Bob in our illustration she's sharing a sequence number of x Bob is then going to confirm receiving that synchronized request by sending an acknowledgment number of X plus one this is how Alice knows that Bob definitely received her initial sin because Bob can only send X plus one if he received X but of course as we just covered TCP is bi-directional so Bob also needs to pick an initial sequence number and share that with Alice and that's what happens next Bob picks an initial sequence number in this case Y and sends a synchronized request to Alice and Alice predictably will respond with an acknowledgment saying she has received Bob's synchronized request by responding with Y Plus 1. again the only way for Alice to send y plus 1 is if she had received y so that's how Bob knows that Alice had indeed received why now notice these two middle events are both sent from Bob to Alice in the fields that each of these events use inside the TCP header don't actually overlap so both of those actually end up happening in the exact same packet and that is where you get a three-way handshake of sin synac and an act it's actually a sin and an act in One Direction and a sin and an act in the other direction so now that we've mapped out the four events that occur in the three-way handshake I want to show you how the actual sequence numbers and acknowledgment numbers are going to look like on a TCP header for the simulated conversation we're having between Alice and pop it's going to start with Alice's sin packet that looks like this she's going to include a sequence number of 1000 that is the randomly selected initial sequence number that she picked for this conversation she's going to include that right here we know that this is an initial sequence number because the sin flag is turned on she's also going to include an acknowledgment number because it's built into the TCP header it has to be there but notice she's simply going to include all zeros since the acknowledgment flag is turned off this acknowledgment field can actually be ignored it's an irrelevant value which makes sense because at this point she has no idea the Isn that Bob is going to pick upon receiving this Bob is going to send his sin Act and the sin act will look like this the acknowledgment field will include 1001 this is where Bob is acknowledging receiving Alice's sequence number plus one notice the acknowledgment flag is also turned on now this field is actually relevant and should be paid attention to Bob is also going to include his own initial sequence number he randomly chose 3000 for this connection and we know it's an initial sequence number because the sin flag is turned on upon receiving this guy Alice is then going to confirm receiving it by sending this segment this segment has sequence number 1001 which is exactly what Bob was expecting next and Alice is going to include an acknowledgment number of 3001 this time with the ACT flag turned on indicating this field is now relevant and this is how Bob knows that Alice definitely received his sin request because she is sending y plus 1 or 3001. so that is what the TCP header would look like in a TCP through handshake but now I want to draw your attention to another field in the TCP header specifically the window size field remember I told you the receiver sets the window size in each connection well since TCP is bi-directional both Alice and Bob are technically the receiver at some point in the connection and in these initial packets they are each sending what they want to start with as their initial window size it doesn't have to be the same between the sin and the ACT both sent by Alice it can totally be different but this is how they both know the starting window size values and then they can adjust them dynamically as they need to throughout the rest of the connection now before we move on to the next idea there's something else I want to draw your attention to insofar as these sequence numbers and acknowledgment numbers earlier in this lesson I told you you can always add the sequence number plus the number of bytes to see the next sequence number sent by the same sender but notice over here 1000 plus 0 doesn't equal 1001. so what's actually going on well the whole way that TCP Works to acknowledge receiving something is by essentially sending what was received plus one and so Bob in order to acknowledge receiving this synchronize has to send the synchronize plus one that is why Bob is sending a thousand and one and that is why Alice is starting with a thousand and one now this is sometimes referred to as the Phantom bite because even though no data bytes have been sent in that packet it did bump the sequence number four Once this Phantom bite phenomenon is actually going to happen one more time within the TCP connection and we'll explain it when we get to idea 11. but for now I just want to drop it in your head as a teaser with that said that takes care of covering the TCP through a handshake and our idea number nine so if we bring back the rest of the data exchange that we've been looking at between Alice and Bob we have the three-way handshake that absolutely started this exchange of data between Alice and Bob now since our illustration is now accounting for Flags I do want to mention in every data exchange packet following the ACT flag is turned on and that makes sense because in all cases the acknowledgment flag is indicating that the acknowledgment field is important and it's acknowledging the last packet received by either sender what you'll notice is in a TCP connection the only segment sent without the ack flag turned on is the initial sin by the initiator of the TCP connection in this case Alice and that makes sense because at this point Alice has no idea what Bob's initial sequence number is going to be so this field is entirely irrelevant in any case at this point I have shown you how a connection starts with the three-way handshake and I've also shown you the middle portion of the connection which is the data exchange portion of the connection between Alice and Bob all that's left to do is to show you how a connection ends that actually brings us to idea number 10. idea number 10 is that there are two ways for TCP to close a connection and to properly show them to you we're going to again use the TCP header the first way the TCP can close a connection is what I'm going to call the graceful method the graceful method uses Finn or finished plaques and the second way is what I'm going to call the ungraceful method and the ungraceful method uses the r or the reset flag idea number 10 is that TCP has two ways to close a TCP connection in idea 11 and 12 will explore each of those ways in more detail idea number 11 is what I refer to as the graceful connection closing this is what happens when everything went well meaning Alice and Bob started a conversation successfully exchange data successfully and once they have both sent and received exactly what they meant to send and receive they can now close the conversation and go about their day there are four things that actually occur inside a graceful connection closing sequence I'm going to show them each to you 'll notice that this will follow a similar sequence to the three-way handshake now it doesn't matter who initiates this in our example it's going to be Alice but it can absolutely be initiated from either party in any case this is how it works one side will send to the other in our example Alice is sending to Bob that she has finished sending data she'll include her last sequence number of x Bob will then acknowledge receiving that thin black by acknowledging X plus one this number plus one Bob will then have to close the connection from his side so Bob will then send a finished flag of his own and also include his last sequence number of Y and predictably Alice will confirm receiving that by sending an acknowledgment of Y Plus 1. so the four-way closure is a fin and ack in one side and a fin and act in the other side and just like in the three-way handshake these two events sometimes occur in the same packet but not always and you'll see what I mean shortly now let me actually show you what this would look like to close out the simulated connection that we are using between Alice and Bob Alice is going to start by sending a thin segment and in that fin segment Alice is going to include her final sequence number of 1601. notice that is the sequence number that Bob was expecting her to send next Bob will then respond by sending an ack of 1602 notice it's going to be X Plus 1. Alice's X in this case was 1601 and therefore Bob is going to acknowledge receiving 1601 and the thin Flag by sending 1602. then Bob's going to close the connection from his side he's going to say I have finished sending data my final sequence number is going to be 3601 and then Alice will confirm receiving that by acknowledging with 3602. now some of you might be asking yourself how come Bob didn't just include the thin flag there well Bob absolutely could have but I intentionally illustrate it this way to show you an important point about how TCP closes connections you see these four events don't have to happen sequentially it's very possible that Alice might finish sending data well before Bob might finish sending data or vice versa for example what if this segment right over here which included 200 bytes was Alice asking for another file and possibly the last file she meant to get from Bob maybe the 200 bytes included something like give me file a.jpg once Bob acknowledged it if that's the last file that Alice was going to ask for for above she can go ahead and send her fin right now she is done sending data there are no more files that she needs to request but of course Bob has to actually send the file before he is done with his side of the communication so you see it's very common for TCP connection closures to happen many packets apart and that is why I intentionally Illustrated them as four different packets of course if Bob has more to send at this point that's going to change the sequence and acknowledgment numbers for our final Fin and ax so let's continue the conversation and then I'll show you how these will be updated so again we can use what we've used before sequence number plus number of bytes equals the next sequence number that's going to be sent notice here 3601 plus 0 that equals 3601 and that's going to be the next data segment that Bob is going to send this particular segment has 100 bytes so if we do 100 plus 3601 we would get 3701 which is the secret number for the next thing Bob sends and at this point Alice has received two data packets from Bob so she now has to send her acknowledgment to tell Bob that those packets have been received notice that even though Alice finished sending data that doesn't preclude her from sending acknowledgments Bob still wants reliability to everything he has to set so Alice still has to follow all the rules for acknowledgments that we covered before her act 3801 is confirming the reception of these 200 bytes now for the sake of the illustration and for the fact that I don't have much more screen real estate let's just say that this is the last thing that Bob meant to send to Alice well now Bob is done sending traffic to Alice and now Bob can go through his side of the connection closing sequence so Bob's fin is going to include his last sequence number of 3801 and notice that is exactly what Alice was expecting to see next from Bach 3801 Bob's acknowledgment number is 1602 notice it hasn't changed since Alice sent her last packet that needed to be acknowledged no new data has arrived from Alice therefore Bob's acknowledgment number has stayed the same upon receiving this bin Alice will respond with this notice the acknowledgment number is Bob's final sequence number plus one as we just discussed and our sequence number is still 1602 because again she hasn't sent anything new since she closed her connection so that is how TCP closes a connection when everything went right when the data exchange went according to plan earlier when we talked about the three-way handshake I told you about this Phantom byte and some of you might have recognized the Phantom bite happen in this screen right now notice Alice sent this packet over here which included zero bytes and if we follow the rules that we talked about earlier sequence number plus number of bytes should equal the next sequence number that she sent but even though this was Zero bytes it did bump the sequence number four at one this is crucial because this is how Bob is able to acknowledge having received that bin okay so why do we even do this Phantom byte thing well to answer that I want to point you to these two acknowledgments sent by Bob if we didn't bump the sequence number forward and therefore the correlating acknowledgment number four on thin flags and also sin flags from the three-way handshake you'd have a situation where both of these acknowledgments would end up looking identical notice if we didn't bump the sequence number forward this would be act 1601 still which is the same as it was before and Alice would have no way of knowing whether Bob is simply resending this acknowledgment or actually acknowledging the new significant segment that she just sent that is why the thin flags and also the sin Flags bump to sequence number four even though those segments don't actually carry any data and so that wraps up our discussion on idea number 11 which was the graceful connection closure mechanism using thin Flags which brings us to idea number 12 the last idea in this lesson and that is what I call the ungraceful connection closing mechanism if idea 11 is how a TCP connection closes when everything went right idea 12 is what happens when something went wrong this is what I'm calling the ungraceful connection closing mechanism and it happens with a simple one-way message which includes the reset black consider a situation where something weird happened with the sequence numbers and the acknowledgment numbers or possibly one of these two TCP speakers received something that they weren't expecting well in those cases TCP needs a way to ejection seat out of that particular connection and that's where the reset flag comes into play the way it works is any party can send a reset flag to the other and that indicates that something went wrong and the connection needs to close it doesn't matter which party sends the reset as soon as a reset is sent that party will forget everything about the TCP connection and as soon as somebody receives the reset that party will also forget everything about that particular TCP connection the rules of sequence numbers and acknowledgments still have to apply though so if in our example Alice decides to send the reset at this point her reset is going to include the sequence number that Bob is expecting as soon as she sends this she is now going to delete everything she knows about that TCP connection and Bob as soon as he receives it is also going to delete everything he knows about the DSP connection notice the reset does not need to be acknowledged but for the sake of thoroughness I'm going to show you what the reset would look like if Bob had sent it here instead of Alice and as expected it's going to follow the same rules for sequence numbers and acknowledgment numbers that we discussed throughout this lesson Bob's last sequence number was 63601 and didn't include any new data therefore the next package he's going to send is also going to start at 3601 and since it includes this reset flag the connection is instantly terminated notice again it does not have to be acknowledged it's simply a quick exit from this particular TCP conversation if Alice and Bob still need to exchange data with each other then they'll start a new TCP conversation and the entire process will start all over that is idea number 12. [Music] so that's it that's the core of TCP in 12 distinct ideas and if you followed me through each of those 12 ideas then you can say you understand TCP better than most but what's next Where Do We Go From Here well there's three places we can go first at the end of the last video where I compare TCP and UDP I teased some additional topics that we could cover regarding TCP TCP is actually a pretty fascinating protocol and there is so much more to it than merely what we covered in the last two videos if you want me to finish this series and create the full TCP masterclass then I need you to help me blow up these videos I'll set a reasonable goal if we hit 100K views in the next six months then I'll commit to creating the full TCP master class and who knows maybe that could also lead into a series on quick second if you enjoyed how I teach in this video and I want a comprehensive series to understand computer networking and there's no better place than my networking fundamental series you can check that out here finally third and announcing for the first time officially I've decided to turn my networking fundamental series into a full networking course this is going to be the premiere vendor agnostic job agnostic computer networking course it's going to be wrapped around the Practical understanding of computer networking that the entire tech industry is expecting you to have right now whether you're aiming for software developed or network engineering or cyber security any job in Tech it all requires you to understand computer networking let's face it everything is connected to the internet these days and understanding how that works will be what sets you apart professionally there'll be more details about the full course in the first comment of this video otherwise that is all I have for you in this video I hope you got a lot out of this TCP Deep dive thank you for watching and we'll see you in the next video foreign [Music]

Channel: Practical Networking

Views: 119,104

Keywords: transmission control protocol, tcp handshake, tcp analysis, how tcp works, acknowledgement number, fin flag, reset, three way handshake, 3-way handshake, tcp, tcp explained, tcp simply explained, phantom byte, sequence number, tcp flags, syn ack, syn syn ack ack, syn synack ack, synack, syn, ack, fin, rst, tcp reset, fin flags, tcp connections, tcp handshake in detail, tcp handshake process, tcp deep dive, tcp masterclass, tcp explained in detail

Id: JFch3ctY6nE

Length: 44min 5sec (2645 seconds)

Published: Mon Feb 06 2023