How TCP Works - The Handshake

[Music] hello everyone welcome to this video my name is chris greer with packet pioneer just wanted to take a minute to shoot a video about tcp now something i do get a lot of questions about is how does tcp work what are some of the functions that it does what are sequence and acknowledgement numbers how do read transmissions work so i thought it might be nice to start a video series about tcp and i'm going to call it tcp fundamentals not sure exactly how many videos in this series there will be but we'll go ahead and get started and one of the most core things we need to understand or the one of the core things the fundamental things that it's important to understand about tcp is how tcp connections are initiated so in this video we're going to tackle the tcp handshake and take a look at what we can learn from that whole process all right so let's go ahead and get started so the first thing i'm going to do in this trace file is i'm going to go down and find the initial packet of the tcp three-way handshake and that is a tcp syn so let's go ahead and scroll down and find the tcp syn here we go and that has been selected already in my packet summary up there so i can see that my source ip100145 is trying to connect to that destination server there and the port that i'm trying to hit is port 80. okay so the two following packets i can see that those are arps so rather than dig into arp right now what i want to do is just filter those out so the one of the first things you want to do when you're doing tcp connection analysis and you just want to filter on a single tcp connection let's go ahead and right click and we're going to come down to conversation filter and the conversation filter that i want to set is not ethernet not ipv4 because that would be show me all tcp connections between these two ip addresses i actually want to come down to tcp so i want to set a tcp level filter for this connection so what that does is it isolates it nice and cleanly for me and shows me just the packets that are involved in this connection as we can see up top the first three packets that are involved here are the tcp handshake so the client is initiating a syn that's a tcp synchronized packet to our our server on port 80. so let's go ahead and take a look at that sin and see what we can learn we're going to bring up our packet details and we're going to come down to the tcp part of the header and let's go ahead and talk through this so our source port there's our client side ephemeral port destination port port 80. now stream index now wireshark will assign each tcp connection that it sees in the trace file a stream index number it'll start at zero and then it'll go up to however many connections there are in the trace file so i can see that this is the second one that it saw in this trace file if i wanted to i could just choose to filter on this tcp stream and use that index number that's one way i could filter for it down below i can see my sequence number is zero so initially when a connection is being established this sequence number in wireshark i'm using relative sequence numbers but in reality if i select that part of the header and i look down below at my hexadecimal this is really a four byte value so this is a long confusing number in reality wireshark is just trying to make it easier on me as a human being i do a whole lot better starting things at zero then i do a hundred million blah blah blah however whatever that number would be just a long complex number to begin with so as a human being i'm a lot better with starting at zero that's why i use relative sequence numbers which is the default setting in wireshark okay so but the function here is i am communicating that number to my link partner i'm telling you hey mr server this is the sequence number that i am beginning with so go ahead and track everything that i sent you starting from this sequence number this is our zero point now if i come down here header length let's go to flags this is another important part of our tcp handshake we have reserve congestion window echo i'm going to cover these in a different specific video on how we use those and what we do right now i'd like you to come down to the sin this is the only bit that is set for the tcp flags so that means sin true that's the function of this packet is to synchronize that sequence number and a handful of other things if we come down to window size this is where i am advertising the size of my tcp receive buffer i'm telling my link partner i can receive 8192 bytes at once unacknowledged that's the amount that i can receive at once now calculated window size if in my tcp options i'm using window scaling that means that i actually can multiply this number 8192 i can use a multiplier to make that window size a whole lot bigger because if i select window size value i can see down below if i look at the hexadecimal down below this is a two byte field so just the the decimal number the biggest number that i can get that i can actually have for a tcp buffer just using this field is 65 535 that's all we can get over two bytes so in order to get more than that in order to have a tcp receive buffer that's larger than 65 535 i have to use that tcp option of having a window scale now that's something that was added to the original tcp spec in the tcp options rfc and that allows us to receive a whole lot more data at once allowing us to take advantage of a higher latency higher bandwidth wan connections typically longer connections where we want to have a lot more data on the pipe okay and that's again something else that we're going to cover in our tcp fundamentals later on all right let's go ahead and take a look at our options let's expand this so here we can see the mss maximum segment size is 14.60 i'm telling my link partner hey that's the amount of bytes you can put in a tcp segment and i'm okay with that now along the path from the source to the destination it is possible that a network infrastructure device maybe to make room for wan acceleration or some other type of thing in the middle uh it's possible that a router even could change this it could say hey you know 1460 i need some of that headroom so let's go ahead and kick this down to 14.48 and then we'll use that as our maximum segment size okay now we have the window scale so this is showing us a window scale 2 so that's going to tell me to multiply by 4. i'm telling my link partner take my window size multiply it by 4 and that's the real deal so you're going to see that as we move a little bit farther forward in our tcp connection you'll see how that'll impact our calculated window size also tcp sac so selective acknowledgement i'm letting my link partner know this is something that i can do so go ahead and let me know if you can do it and this is a great function in tcp certainly something we'll be covering in our tcp fundamentals all right so there's our sin this is advertising some of our capabilities some of the things we want to do with this connection and of course it's sending our starting sequence number to our link partner now there's one other small thing we want to mention that happens with the tcp syn if i scroll up just a little bit you can see that this packet if i come over here to the tcp length this shows me that there's no encapsulated data so there's actually nothing being sent in this in from a data perspective but if i come up here and i start talking about the tcp syn ack we're going to notice if we come down to the acknowledgement number right here we can see that the syn ack in the opposite direction is actually acknowledging an acknowledgement number one so what this is is it's actually was something that we call a ghost bite so in the handshake process each side will acknowledge one you could you could call it a ghost bite it's not an actual real bite of data but the two sins will act as if there is a ghost bite so again the the sin is just sending with with no data but the syn act comes back and it acts this ghost bite and then you can notice which we'll talk about in just a minute that the acknowledgment from the client back to the server acknowledges a ghost byte or it behaves as if there was a byte sent in the synack so that's something to know as we see these ign acknowledgement numbers and sequence numbers start to increment okay so in the opposite direction here we see the synack all right so let's go ahead and take a look at the header values uh besides what we just talked about the acknowledgement number here in this opposite direction so here we see that this is coming from this is coming from uh port 80. it's going to 54 43 so it's responding back to that same port number that the client started sending from that high number client-side ephemeral port and if you come down in the opposite direction here's our synack so here we can see the syn bit is set and the acknowledgement bit is set so this is acting that ghost bite so to speak so it's acting and it's also opening its own sin so it too the server is sending a starting sequence number that's that four byte long value that wireshark will set to zero for us just to make it easy to see and uh it's acting the ghost bite that was sent or not sent that's the wrong way to say it but you know what i mean it's behaving as if uh uh it's acknowledging one byte okay so if keep moving our window size value from the server here's 43.80 that's the starting number and if we come down and take a look at the options we can see that the maximum segment size is 1460 1460 these two are good to go the window scale now the server is saying window scale multiply by one so shift count zero multiplier one so basically what that means is we're going to take this window size value and multiply it by one so in other words this the window side isn't really it is using window scaling but it's not using a value that will increase this number giving us a calculated window size so um if we keep going here's our tcp sac so both sides are permitting it so we'll go ahead and use ccp sac so here's our syn acknowledgement now the final packet in the three-way handshake here's our acknowledgement it's coming from the client and we come down we can see that the sequence number is one the reason being again that that ghost byte that the server was acknowledging in the synack that's the number that we will start from that tells us that things are working and starting up properly also the acknowledgement number we're sending back to the server that we again were behaving as if there was a byte sent just to get that number going also here's our acknowledgement we do not send a synbit in the final act here the third packet of the three-way handshake there's no syn bit set this is just a simple ack we can see the window size and with that scale factor that was initially sent in the sin from the client the true window size is 17 520 the window size scaling factor is four and just a note for you it's really important to capture the tcp handshakes and this is one reason why if we did not capture the tcp handshake for this connection we would not know what the true scaling factor is we would have no idea that the true window is 17520 we would think that the window size value is 43.80 from the client so that's another reason why it's so important to catch tcp handshakes if possible because we can actually calculate the true window which wireshark will do for us as we can see the tcp options are gone those are only exchanged during the sins and now we are ready to start exchanging data now something else that's very useful in capturing a tcp handshake is we can get the initial round trip times so if we come back up and take a look at the delta times between these packets up up on top here here we can see this in and we can see that 74 milliseconds almost 75 milliseconds later we see a syntax now for uh this trace file this is actually captured client side so we can see that the initial round trip time is 74. if we were capturing on the server or near the server we shouldn't capture on the server i don't want to get in trouble with anybody if we're capturing near the server uh then we would actually see this value between the synack and the ack right so the scene would come in from the client we would immediately see a synap go out and then we would see an ack come back from the client and there's our that's where we would see our 74 milliseconds now if we're somewhere in the middle let's just say we're not on client or server side well then what we can do is we can actually add these two numbers together add the delta time between this in sin and synack and also add the delta time between the synac and the ack and that will give us our initial network round trip time regardless if we're in the dead center of those two endpoints so that's just a little trick to keep in mind okay so i hope this video was useful to you in capturing and interpreting and learning more about the tcp handshake process we look forward to digging further into tcp and further videos thanks for stopping by and everyone have a great day

Channel: Chris Greer

Views: 196,609

Keywords: Wireshark, TCP/IP, TCP, Transport, Protocol, Packet, TCP Handshake, wireshark training, wireshark tutorial, packet analysis, packet capture, tcp analysis, tcp connections, how TCP works, transport control protocol, wireshark tutorial 2020, wireshark analysis, free wireshark tutorial, free wireshark training, free tcp training, network troubleshooting, tcp three way handshake explained, three way handshake tcp, transmission control protocol, chris greer, wireshark

Id: HCHFX5O1IaQ

Length: 13min 58sec (838 seconds)

Published: Mon Jul 24 2017