Skip to main content
Loading Explore guides…
TCP Concepts · Acedra
Home
Explore
Computer Science
TCP Concepts
Sign in to save
Chat
If YouTube asks you to sign in, open the video on YouTube.
Watch on YouTube
Reload player
Transcript
144 segments
Copy
Hide video
0:00
- I'll say this, Chris, I mean, in the CCNA, as an example, they teach a little bit about TCP. It doesn't go deep as perhaps we would like for the real world. So I'm really looking forward to you showing us how this actually works in the real world. ♪ Woo ♪ (upbeat music) (person scatting)
0:22
Hey, everyone, it's David Bombal back was Chris. Had a lotta great feedback from our previous videos. Chris welcome. - Hey, it's great to be back here with you, David. Thank you for having me back. - Yeah, so what are you gonna show us today? Because I'm quite excited about this topic. - Yeah, so we had a lotta comments, like you mentioned for the last couple of videos. So I thought what we could do is just back up a minute and take a look at some TCP concepts,
0:43
learn some core TCP things that will help us to be better troubleshooters, better analysts, and even better hackers if that's what we're getting into. - Let's get straight into it, and then I'll ask you a bunch of questions. Now, for everyone who's watching, please put in the comments below the kinda stuff that you want me to ask Chris on future videos, you know, stuff that you wanna see. We wanna create a whole bunch of videos, including a series on TCP. So see this as like the first video
1:07
in the TCP deep dive series, but let us know, you know, questions that you've got, and Chris is it true that you're gonna give us the trace files and I can put them below, is that right? - Yeah, absolutely. You can hit the link in the description down below and you can follow right along. I think that makes it a bit more interactive, and I really encourage you to do that because I think all of us, we learn by doing, we retain better when we're actually have our hands on it.
1:32
So we encourage everybody to do that. - That's great. So you took it away. Chris, show us your trace file and let's start with the beginnings of TCP. - So I think this is a great place to start, David, okay, let's go from the networking background, right? You come from the networking background. I do as well. How often were you blamed for network problems? - It's always your fault, come on. - Right, "Oh, it's slow. It's the network. Oh, not connecting properly. It's the network.
1:57
It's the network." I think it's kinda funny because sometimes we'll even make a phone call to our bank or we're setting up a flight, or, you know, pre-pandemic, or whatever it was and you're on the phone, and there's like this hold, and the poor operator's saying, "I'm sorry, my network's slow today." - Exactly. - Have you ever had that experience? - Yeah, exactly you guilty until proven otherwise? - Absolutely, so, okay, so right there,
2:20
if we're in the network space or even if we're just growing in our knowledge of protocols, TCP should be a big part of that. And the reason why I took that down the it's not the network conversation is because being a consultant, being a troubleshooter, that's what I do, a lot of times people call me because they're having network issues or it's the network people, and they're calling me, and they're saying, "Hey, I'm getting blamed for this. So what's going on?"
2:45
But then I look at the trace file and I start with the transport layer. Why? Because I can then take the OSI model and I can break it in half. If I start looking at TCP and TCP looks healthy, I don't see delays, I don't see any weird TCP indicators at that layer, well, then I can go up and I can take a look at the application. But if TCP's not healthy, if I see retransmissions, out of orders, window problems, blah, blah, blah, blah, those kinds of things, especially with retransmissions, okay,
3:14
now I can go down to the network. Why is the network dropping traffic? Why are things not being pathed properly? What kind of hiccups are we having in getting data through? So that's why, David, we're gonna start here at the transport layer, specifically with TCP. This is why it's such an important thing to understand for troubleshooters, for network analysts, even cybersecurity professionals. - I'll say this, Chris, I mean, in the CCNA, as an example, they teach a little bit about TCP.
3:42
It doesn't go deep as perhaps we would like for the real world. So I'm really looking forward to, you know, you showing us how this actually works in the real world, and I wanna quiz you on like all these different flags and things, so, yeah, looking forward to it. - Fantastic. Okay so good. So let me ask you this, David, when it comes to the TCP handshake, is that something that you would be quizzed about on your CCNA? - Yes. So I hope you're gonna explain the three-way handshake
4:09
in proper detail with a proper Wireshark capture. - Absolutely, so let's do it. So here, I've got a trace file open and we're just gonna spend some time on the handshake. We're gonna spend enough time to go into the detail to really understand what the handshake is doing. What's the purpose behind it? It's way more than SYN, SYN-ACK, ACK. - That's (crosstalk) most people know it for, yeah? - We pass that question on our CCNA good. SYN SYN-ACK ACK wonderful. Why is it called SYN?
4:34
What's happening in that handshake, really, why was that term selected? What is an ACK? What are we ACKing? Let's get to it. So if we take a look at this PCAP, and again, everybody go get it, go down, download it, and then one you're gonna make sure that you're on is the TCP handshake, and I threw my name on there to see you knew that it was me. Here, this first packet that's going on, this is only a 15-packet trace file, right? So this is not a big one.
5:00
This isn't just some long, huge TCP thread, and really, the way that I captured this is I just opened up a browser and I went out to this website that's open, it's a website that's designed to be just over HTTP. I wanted to make sure this wasn't encrypted. It's just a very simple conversation over TCP, but what we're gonna focus in on, let's go and get into that handshake. I'm gonna take a look at packet number one. And this is just the first packet in the trace.
5:25
This is the first time that this station reaches out and establishes or tries to establish a connection over TCP. Let's see what's going on in this packet. I'm gonna go ahead and move my detail up a little bit. Move my hex over, just to head check to see if I have any clear text over here. Of course, you know, in the SYN, I'm not gonna see any data, but I just wanted to see what we have over there. I'm just gonna move this back. Okay, so in my detail, I'm gonna skip over layer two,
5:53
layer three, which would be ethernet, IP, I'm just gonna go straight to layer four. Now, first thing, I can see it's starting from this high number source port. We call this the client side of femoral port. Usually, this is a pretty big number like you see here. Right away, I wouldn't even need to see this up here. Usually, when I can see that information right here, I'm going to destination port 80. I'm coming from this high number port, right there,
6:23
I know that, okay, client is sitting on 54846. The server's on 80, port 80's gonna be a common number. It's gonna be a well-known port number for that service. Okay great. The next thing that Wireshark does for us is it gives us something called a stream index. What that means is basically it's the four tuple for this conversation. What's a four tuple? Two IPs and two port numbers. That gives me a unique TCP conversation. So Wireshark says, "Hey, this is number one."
6:53
Or in this case, it starts at zero. But the first TCP stream that I see in this trace file, this is zero, and this is all just one. If I saw a new four tuple immediately after this, let's just say, David, I saw two SYNs go out, SYN, SYN. Well, then I would see stream zero within stream one. Okay, moving down. Let's go ahead and talk about this sequence number thing. Okay, so here's sequence number zero, relative sequence number. The reason why this is called a SYN is
7:24
because in the handshake, I have to exchange, if you will or synchronize the sequence numbers of the two sides. So this raw sequence number that you see here, this big, scary looking number, this is a very important number to TCP, all right? So when I send my SYN to you, David, I'm telling you, "Hey, I'm gonna start counting the data in my direction from this number," it's called the ISN, initial sequence number. - Just randomly selected, yeah, or how's is it chosen?
7:54
- Yeah, it is a somewhat random thing. Operating systems, at least historically, they'll typically start in a certain range, I mean, I can't spout that off the top of my head and go, "Hey, well, you know, this must be a Mac system or something like that." But a lotta times you'll see them start in certain ranges. The idea here is it just has to be unique, right, and it's a number that's randomly generated. It's a high number. It's very unlikely I'm gonna see this again
8:22
on a different connection very near in the future, right? That number, I offer that to you, and then Wireshark just does me a solid, it just says, "Hey, let's just zero this number out," because we talked a bit about this in a previous video how Wireshark goes, "You know what? You humans have a hard time counting with big numbers. Why don't we go ahead and just zero this out for the purposes of this connection," so that's why we see sequence number zero,
8:49
relative sequence number, good with me so far? - Ya, I wanted to ask you some questions. So let's start with the port numbers. So the source port is like a random port number or ephemeral port goes by different names. I can't remember the ranges of the top of my head, but it's a high number, isn't it? And then like the greater than 1023 or 1024, depending on which operating system you're using. I think, Chris, that's the thing. I mean, you've got a lot of experience doing this
9:12
in the real world, different operating systems handle the port numbers and like you said, the sequence numbers differently, don't they? - Yeah, they do. And really when it comes down to it, something just when we're getting started with this, just to remember that as long as this isn't the same, right? So if I start a connection to you, David, I gotta use 54846. If I wanna start a new connection to you, well, then I can either increment it by one, depending on the operating system,
9:40
it might, again, be random. I could jump up to 55900 or something like that. But the point is, as long as it's unique then when you are communicating data back to me, my machine knows what to do with it, right? That port now gives me a place to stick that data that the application can use. So there's something that happens in the handshake, and this is where we're going to start to deviate from the simplicity of SYN, SYN-ACK, ACK. This is what's actually going on under the hood.
10:10
You notice my next sequence number is one? - [David] Yeah. What this means is this is a Wireshark value, anytime you see these hard brackets here, that's Wireshark giving me information. This is not actually a part of the protocol itself. This is Wireshark doing me a solid, you see it up here. It needs to be segment length, stream index. The port numbers are a part of the protocol, so is the sequence number, but this is just extra info that Wireshark's helping me out with,
10:37
but it says sequence number one. So what happens when I send you a SYN, okay, you're gonna be the server, all right, David, I'll be the client, I send you a SYN, "Hey, Mr. Server, here's my starting sequence number." And there's an action that you're gonna take when you respond, you're going to add one to the sequence number and respond plus one. What that does is it allows me to know that you heard me. Yeah, in the handshake, it's called a ghost byte. It's not a real byte of data.
11:07
It's not a true actual byte that I needed to send. But what you're gonna do is you're going to increment the sequence number by one, and then you're gonna send me back an acknowledgment number, plus one. So let's do this. Let's just remember this 7413 right here, okay? Take a look at our SYN-ACK, I'm just gonna come down.
11:26
Now, the acknowledgment number in the SYN-ACK. So 7414. Okay, I'm gonna do that again. And let me go back up to my SYN. 7413 here, and then you come back and you say ACK, but plus one. All right, so what does that do? Now, the relative ACK number is a little easier to use. You're just taking the zero I sent you, the quote-unquote zero from the Wireshark perspective, and you just added one to it. So what do I know now? If I'm a client, first of all, this SYN-ACK just gave me
11:56
a bunch of information. David exists. I can route to David. David heard me, right? He's got space available on port 80. He's got resource to accept a new connection. He went ahead and added one to the sequence number I sent him. So we're synchronized, as far as I'm concerned, you just ACKed my SYN. I'm now good. I'm now perceiving that you're there and we can chat. Now, there's more going on beneath us, but I'd like to stick on this for a moment just because it's so important.
12:29
So you can see the amount of things I've learned. What else have we learned from the SYN-ACK that you sent me? If I come up here, let me take a look at my delta time. My delta time, I have this set up in Wireshark, it's the amount of time between packets. All right, now, that's something that's pretty simple to set up. This is something you'd wanna make sure you do in Wireshark. I'm gonna come up to Wireshark, Preferences. If you're on a Windows system, we're gonna go to Edit Preferences.
12:54
Lemme jump there real quick, and I'd like to show you, if I go to Columns, all I gotta do is I just gotta add a column,
13:02
lemme just go Delta, and then for the good viewers, you just come over here to type, and then we're gonna come up to Delta time displayed. And then once we have that, as a style thing, I just like to move this up next to the running time that I have there. I'm gonna remove this because I already have one, but basically Delta time is a great column to have when you're doing this analysis. So now what I know David is you in time are 20 milliseconds away from me. So that's nice to know, you agree?
13:34
- Yeah, yeah. It's not a server on the other side of the world. - Exactly, yeah, and in fact, I can take this 20, and what else can I learn about David? Well, I can come down here to IP. I can expand this out, and I can go to TTL, and I can go, "Whoa okay 238." Now, we talked about this in a previous video, but right now I know David, he probably started his TTL, his IP TTL at 255 because this number never goes up. So it's likely he began at 255. Now, I can, you know, look at the math
14:07
on how far away you are, right? You're probably 17 hops away from me. Another possibility is that this started off on a completely different other number, but it's very unlikely. It's most likely that you started at 255 and that's that packet. - What are the numbers that we start at normally? Sorry, for the people who didn't watch the other video. - No problem. 64, 128, and 2 55 are the most common starting TTL values.
14:30
In fact, let's test that theory. My machine, when I sent out the SYN to you, let's go to packet one, my starting TTL was 64. As that packet goes to you, it gets decremented. You receive it, and then you start with a full count TTL, and then on its way back to me, it gets decremented. So we're two packets in, you've synced my SYN.
14:54
You've acknowledged my sequence number. You're 20 milliseconds away. You're probably 17 hops away. Look how much I've learned about you so far, David. - Here's a very basic question just to step back. Why do we need SYN numbers? - Because that's how TCP is reliable, right? One of our test questions, often is it's connection oriented, it's reliable. It's for sure. It ensures reliable transmission of data. The thing about the sequence numbers is that's how I determine did you get everything
15:26
that I sent you? If I send you 100 bytes that will reflect on the number that you ACK back to me, you're gonna add 100 to the sequence number. The sequence number goes up in conjunction with the amount of bytes that I send you. One sequence, number one byte. It's just scary because it begins at such a high number, right, if I come back down to TCP, it's just a scary looking number. I'm not gonna lie, eh, my brain does not wanna wrap itself around this huge value.
15:54
So that's why Wireshark says, "You know what? Hey, David and Chris, let's just chill out. Chris, let's just act like you started at zero. David, let's act like you started at zero, and then as you both start to send data, we'll increment this." That's why relative is so nice. Okay, David responds SYN-ACK, now, he doesn't just ACK me, let me come back down to that SYN-ACK, he doesn't just plus one my SYN, but he also gives me, or, I'm sorry, his sequence number.
16:26
Now, does this sequence number, David, look anything like this one? - No, I didn't count the digits, but another big number. - Another big scary-looking number. Exactly. They're not even in the same ballpark, right? So it could be you're a server and you're starting in a different range of values. The random number that you came up with is just in a whole different world than mine is. The value itself doesn't really matter. You're just informing me what your starting value will be.
16:55
So you send this big number to me. Your next expected sequence number in this direction is gonna be one, that's relative, right? That's Wireshark saying, "Hey, you're sending a ghost byte with your SYN, right?" That false one that you send back to me. And now let's just remember this, 5106. Okay, there's our value. Let's just kinda commit that to memory, 5106. All right, so what I would expect is in the final packet, see, I now say 5107. I added one to your sequence number
17:30
and notice too, my sequence number, I'm now at 7414. Okay, so now I'm gonna do everyone a favor and myself a favor, you as well, hopefully, David, I'm just gonna stop using these raw values. 'Cause, they're just so big. This is the whole point. Wireshark's like, "Nah, let's get rid of these." I'm at one, you're at one. Now we've reached the end of our handshake. Anytime I come up here in Wireshark and I see sequence one, ACK one, I know that's a successful handshake.
17:56
I sent you my sequence number. You plus one ACKed it, at the same time, you sent me your sequence number. I plus one ACKed it. We're synchronized. - And the synchronization is, well, part of it is to know what the initial sequence numbers are, yep, so we exchanged that. - Excellent. That's exactly it. So that when I send you data, you can increment the sequence number that you see me start with, you increment it, and act the number back to me. - Yeah.
18:27
- I take your sequence number when you send me data and I do the same. Our sequence numbers, they're completely isolated to our direction, or rather they're direction dependent. What I mean is that I'll never add, multiply, subtract, divide these values. These values will never intersect. They'll never be some mathematical equation. It's just in my direction, we're using this 17796 number, and in your direction we're using this 205805 number. - Yeah. And I'm gonna ask you all the basic questions
19:02
that people may have, is the first one always a SYN? Is the second one always a SYN-ACK? and is a third one always an ACK? Is it like always like that? - That's a great question. And the answer's yes, we can't start, for example, on this GET, this is the application sending data. Now, let's actually do this. There's an actual payload sitting in here, right? TSP payload, 501 bytes. And there's actual data sitting inside this TCP segment. So I can't just put this 500 bytes out there on the Wire
19:32
and just hope, David, you know what to do with it simultaneous to processing it, and, you know, preparing the response. I first have to set up the connection. So your question was a good one. We have to establish that connection using this three-way handshake for every connection that we S we establish, SYN SYN-ACK ACK. - Over there, the data sent was 501 bytes or something, is that right? - Yes. - So does this sequence number, did I read that right, it jumps from one to 502, is that right?
20:03
Because 501 bites per cent, is that correct? - Good question. Actually, you know what? I think it's a good idea, we'll stay on the sequence numbers for right now, and I'll get to the TCP options in a minute. So I like where you just went with that. I'm just gonna collapse my IP. - It's just that it causes so much confusion 'cause of the big numbers and, you know, how do they increment exactly? And I think you said "One byte is one number relatively," is that right? - It is.
20:29
So let's all go down to the packet four. Now, if we take a look at packet four, here we have, there's my sequence number, now, I'm not gonna use this big, scary one anymore, okay? So my sequence number is one and, David, I have a 501 byte payload here. TCP does not care what the payload is. It does not matter to TCP. It's just data. It's whatever that application up there, that application could be anything. The application opened the hatch through 501 bytes down,
20:55
TCP caught it, and now TCP's like, "Look, my job is getting this over reliably to the other side." So I've got 501 bytes of payload here. So what I do is I say, "Here you go, David, sequence number one," I'm starting here at this value. The next expected sequence number in this direction, me to you, the next place I'm going to begin in this direction is at 502, 'cause I just sent you 501 bytes. On my side, I basically jumped forward to 502. If there's any more data that comes down the hatch
21:25
from the application, I'll send it to you with a sequence number of 502. Let's see what you do back to me. 25 milliseconds later, I hear back from the server and let's check out the acknowledgment number, 502. What do I learn?
21:42
My data got there. - 501 bytes of data. - Basically, when I send you data, David, I'm going to basically hold back a copy of that data, if you will. In my send buffer, I can't clear this 501 bytes out of that send buffer until you ACKed 502. Once you've ACKed 502, I can say, "Great, okay, 501, get outta here. Now we can make some more room for some more data in here," okay? - That's why an unreliable link or something can slow the whole process down 'cause you've gotta buffer that
22:12
and to like acknowledge it, yeah? - Absolutely. Yeah, and we'll get into this in other trace files, imagine if I don't hear this acknowledgment. - Yeah. - What do I do then? Well, then I basically have to wait for a timer to expire. I'm like, "You know what, David, I put that 501 bytes out there.
22:32
A timer will expire on this data, and then I will retransmit." But right there, imagine the information that we would learn, our handshake worked, but that GET didn't. So now where on our network are we losing that packet? - I was gonna say, okay, so then, so 502 has been acknowledged. So on the client side, seeing that we doing the client side at the moment, the next packet that he sends, can you look at the next one, will it be like some other number? So there it's 534 bytes, is that correct,
23:00
that's been received from upper layers? - Good job, yeah. No, this is our next packet, packet six, and here we can see that the payload is 534. And now that number sounds similar to the 501 that we sent before, right? But remember that the GET, the data that was being requested, and it honestly doesn't matter the application, this is 501 bytes that the client sent to the server, that was acknowledged and now the server is responding, this is the actual application response.
23:28
So the application opens the hatch and said, "Here you go. Here's the response for Chris, here's 534 bytes. Get it across to him." So you say, "Okay," starting at sequence number one, you send your 534 to me. And your next expected sequence in this direction will be 535. - And you kept the ACK at 502, yeah? Sorry, go on. - Good job. That's exactly where I was going, 502. That's exactly the spot. I didn't send you any more data. You're repeating that acknowledgment number.
23:59
Now, it's not a duplicate ACK, you know, that's a whole different situation, basically, you're just acknowledging that I haven't sent you anything new. - Yeah. - Your sequence number went up, but your ACK number stayed the same. - That's great, and so if you go to the packet seven, we should see perhaps that that increases now, yeah? - Yeah, exactly. So, yeah, you hit on a good point, David. So this is from client to server. My sequence number is now 502, but now my acknowledgment number is 535.
24:31
So now I am ACKing the 534 that you sent in your direction. On my side, my sequence number is 502, on your side, we've incremented that to 535. All right, we've both have sent data in each direction. Now, you hit on a good point, though.
24:50
this is an empty ACK. You can see on packet number seven, let's have everybody join me there, TCP segment length is zero, I call this an empty ACK. The purpose of this packet is only or for me to acknowledge your data. I'm not sending anything new. So that's why, and the viewers, if you'd like to, this might be a good thing you can do on your Wireshark profile. You can just right-click TCP Segment Length and add this as a column. One of the reasons why I like to do that is
25:18
because now I have TCP segment length here. Now we can see payload length, and not overall packet length or frame length, if I'm looking at it, well, including the IP header and the ethernet frame, if I only wanna see the data payload and how much data is there, that's where I like to have that as a column. Let me back up, how we feeling, David, how you feel about sequence numbers? - Yeah, sorry, Chris, I'm trying to push home this point because we started with a client.
25:44
So if you scroll down, where's the next one that the client sending to the server? Because we were at 502 and, hopefully, at some point we'll see the client send some data to the server. Yeah, there we go so. So 502, we got 439 bytes from the upper layers.
26:06
So the next sequence number is 502 plus 439, is that right? - That's correct, and that's a good spot. So in this direction from clients, so from me to you, let's take a look at our next GET, it's 439 bytes. I start at 502 because that's where I'm at, right? My sequence number has moved to 502 and I haven't sent you anything else in this direction until this point. Now I add 439, 439 more bytes I'm putting out on the Wire. The next place I expect to start in this direction is 941.
26:38
It's 502 plus 439 equals 941. At the same time, I expect 941 to come back from you because that tells me you got my data. So this is why. And actually, I just posted this video on my YouTube channel about sequence number analysis. And I go through a bit more practical use cases on how to use sequence numbers, and how they increment. Getting practice of how these sequence numbers work is key to really understanding TCP. This is why TCP is so much more than a handshake.
27:09
It's so much more than just SYN, SYN-ACK, ACK. It's a whole lot going on, and these sequence numbers synchronizing is really why we call it SYN, SYN-ACK, ACK, and it's a key part of how the protocol works. - So if you go to 12, we should see that ACK, is that right? Sorry, I just wanna wrap this up 'cause I took you on a tangent here. - It's okay. Tangents are not a problem. They're good. All right so. Yep. So I sent you 439 and if I come down to 12,
27:37
there's my 941 at the same time in the opposite direction. You know, a few other packets were sent. So my starting sequence number is 1726. And then, you know, you see the, okay, come in and, you know, this is an empty packet, but the next one, you to me, 1726, I'm gonna add 500. And the next expected sequence numbers is 2226.
28:01
Now, Wireshark does something kinda cool for us. Let's have everybody click packet 12. So this is the ACK coming from David back to me. And this is empty right, there's nothing in here. This is just an acknowledgment. The cool thing that Wireshark does, if you notice on packet 12, so he's ACKing 941, my other packet got there, check our little check box. You see that next to packet 11? Oops. You see our little check mark there? That's a visual way where Wireshark says, "Okay,
28:30
packet 12 is ACKing the data in packet 11." So just with my eyes, I can go up there and I don't have to do a lot of this math in there, like Wireshark saying, "Don't worry about it. I got the math for you. Packet 12 is acting packet 11. So we're good. There's no need to retransmit it." Now, I can clear that data outta my TCP send buffer, and then I can carry on with life. Sequence and acknowledgment number's a huge thing that is important to really understand when using TCP.
28:59
And it also can really help us get to the root if we have missing data, if we have retransmissions, we're gonna be building out this conversation. This TCP series is gonna go into this, but having a good understanding of how sequence numbers work is key to understanding retransmissions, out of orders, and other TCP errors that we can see. Let me go ahead and back up to our handshake. We're not done yet, but first I wanna check in with David, we doing good on sequence numbers?
29:23
- Yeah, so just to summarize, you and I both pick a number, let's assume you the client like we did in this example, I'm the server, you and I both picked some number. And then we do the SYN, SYN-ACK, ACK just basically to tell each other what our starting numbers are. And then for every byte we send, the sequence number goes up by one. Wireshark makes it easy by just starting at zero, relative numbers, the numbers are totally independent of each other, it's like two separate streams,
29:50
you mustn't confuse one or the other, and I think that's what gets confusing. 'Cause, you look at all those numbers and I find it difficult, like, "Okay, so which side am I looking at, and you know, which numbers are relating to which," you gotta kinda separated in your mind, is that true, Chris?
30:02
'Cause, you do this stuff all the time in the real world, how do you, you know, get your head around all these numbers, and data, and stuff. Is it just practice or, you know, are there any quick tips? - Oh, that's a good point and in absolute truth, it can be hard to wrap your head around all these numbers. And I think that's where people can get confused. It's easy to get confused about TCP. Practice is a big one, just looking at these flows and really what you and I just did,
30:27
step through them one packet at a time, and watch how these numbers increment. I'm not gonna lie to you though, David, I'm kinda old school. When someone sends me a PCAP file and I realized that I gotta go down to the TCP road, and I gotta do my TCP in-depth analysis, I'm not joking, I get out of a big piece of paper, and I write "Client," and I write "Server" on the other, and I literally will sometimes have to trace out manually those sequence numbers just to keep my head straight.
30:57
Sometimes, yeah, it gets pretty deep, especially when you're doing multi-point analysis. Sometimes I'm not just looking at a single PCAP from a client, right here, just with a glance, David, the roundtrip delay that we're having, the initial starting RTT we call it, round trip time, 20 milliseconds, just by glancing at this, I can tell you we're capturing client side, right? The SYN goes out, 20 milliseconds later we get a SYN-ACK back, and then, boom, the ACK happens only 59 microseconds later.
31:26
So that's how I can tell what side I've captured on. Sometimes I'm dealing with multi-point captures, a capture that was taken on the client, one that was taken on a firewall or somewhere on the network path, and then on the server. So that's why sometimes I'll have to a big piece of paper, draw out all my capture points, take a look at the sequence numbers, and then track them through the system. For the more intermediate, advanced people
31:50
that are watching right now, a nice thing, just so you know, 'cause I have been asked this several times on my channel and I've seen it on the industry, this sequence number raw, like what's the practical use of having it? The nice thing is that this number will live through a NAT or even a port address translation in most cases. Like, let's just say, David, that me, the client, I'm going through a NAT on my way to you. - Yeah. And I have a dual point capture.
32:18
So my IP changes or even my port could change. How do I say, okay, this was the SYN that Chris sent and this was the SYN that David received, one of the ways we can do that is by setting a filter for the sequence number. Okay, but yeah, practice, and just writing it out, and going through slowly, like we're doing, getting practice with it. I still have more to say about the handshake. Hope you're ready for more, David. - Yeah, of course, no, this is great.
32:42
Let's go deep, and, I mean, I'll just say this, anyone who's watching, you know, give us feedback. I'm trynna get Chris to give us all the detail that you don't get in CCNA courses or other materials so, and make it real world, so, Chris, you know, share your stories. It's great to hear the real world story. - For sure, oh yeah, no worries. TCP was written a long time ago, right? The RFC you're talking about RFC 793, 793, and it came out, I believe September, 1981. It's been 40 years.
33:15
- A long time, yeah. - Lemme ask you this, David, when they were sitting down and, you know, the standards masters, the people that are amazingly brilliant, I mean, think about it, they introduced to the world and we're still using it 40 years later. That's incredible. But do you think that they conceived of a 10 gigabit connection across the Atlantic Ocean? - No, I mean, in those days it's what, dial up and really old stuff. So, I mean, the speeds are very, very slow.
33:44
X.25 had TCP at layer two, didn't it, so same kind of idea at layer two, just to try and make the dodgy links work. - Yeah. At that time you're doing literally shoestring, duct tape, and, you know, you're not thinking about the speeds and feeds that we have today. So TCP was good for a while, through the 80s, through the early 90s, there were some adjustments, a few tweaks here and there on how the core protocol works. But this is what started to happen,
34:12
TCP, because of some of the values that are baked into the header, basically, we needed more, we needed more out of it. So I wanted to show you, in the next section we're gonna go through, which is gonna be the window size, and also some of the TCP options, this is where TCP has migrated and changed quite a bit from the original standard that it started out at. So far, everything that we've said is exactly the same as the original standard, but now we're gonna start getting into the stuff
34:42
that is more modern TCP. Let's go ahead and talk, okay, so just briefly, okay, everybody joined me back at packet one, So we're on header links, okay, so within TCP, the header itself, when I first send you the SYN, I basically have to make some more space in my TCP header to then be able to send you TCP options, optional features that we may or may not be able to use on this connection. I can see that down below. You see that, David, at the bottom? - [David] Yeah.
35:16
- I've got 24 bytes of options. If I don't have this header length at 44 bytes, basically, I don't have enough room, top to bottom of my header, to be able to send you those options. So that's why this is an important value just to be aware of. Usually, you only see this in the handshake that the header length is this big because you only exchange options in the SYN, SYN-ACK. Once these SYN, SYN-ACKs are done, these options, are exchanged and now we're using this connection.
35:47
And that's something that I really want people to take away from this, capture the handshake, make sure you get the handshake when you're analyzing TCP. If you don't, then we don't have the TCP options that were exchanged only in the handshake. And they're really important for fully understanding the flow. Now, this header length, this is a bit of a side point, but this is a finite value. See, we only have four bits to work with, okay? So the header length can only grow to a certain point.
36:15
That's why, right now, one of the reasons why we've needed to move to a new protocol like QUIC is that we're starting to run out of the maximum space that the header length can be. That means that we don't have a whole lot more room for options anymore. Like, I can't come up with a new Chris option that makes TCP do some cool, new, awesome thing because we're running out of space. TCP is starting to reach a bit of a limit, and this is fuel for another video, David,
36:47
but this another reason why we're starting to see more of a move toward QUIC, because it doesn't have some of these limitations. That's all I'll say about that for right now. I definitely wanna move into flags 'cause this is something, if you are a pentester, if you're blue team, if you're a network engineer, if you're an application developer, whoever you are out there in the world, TCP flags are an important thing to understand. Let's go ahead and get into it. The flags field.
37:15
When I'm learning or talking about TCP, I like to just see the hex as well. So this is telling me up here, this is just the overall flag part, it's the flag part of the header, and this is just telling me that this is a SYN. The reason, if I take a look at all these zeros, this means that all these other flags are false. So false, false, false, false, false, one. So there's the SYN bit is set. That means that this TCP station or whoever's sending this TCP SYN out is telling you,
37:45
or me to you, David, I'm saying this is a SYN. It's not a SYN-ACK. I'm not yet using the acknowledgment number. Because if you notice up here, you can see on the original SYN, my acknowledgment numbers are zero. You haven't sent me any data yet. You haven't sent me your starting sequence number. I have no information on you, David, at all. In the SYN, I don't even have the ACK bit set. This is just basically space. It's just all zeros over there in the header.
38:11
There's nothing going on in the ACK number, so SYN, that's it. That's common to see in the first packet of a TCP handshake. - Yeah, it makes sense. - Yeah, I don't need any of these other things. Now, there are some other uses obviously for these other flags. Lemme just go over real briefly. You're rarely gonna see reserved. I don't even know if I've ever seen that in the wild. Nounce, I don't even think I've seen it in the wild. One time I've seen
38:36
the congestion window reduced practically used, very rare. You'll often see this be zero. ECN-echo, explicit congestion notification, echo, not set, again, not something you're gonna see often. Urgent you're not gonna see often. So as you're learning TCP, just for now, let's just skip over these first five. These bottom ones are where you're gonna be spending most of your analysis time. ACK, PUSH, reset, SYN, and FIN. - I think that's what's great about what you sharing, Chris,
39:06
because you do this all the time, you know, it's one thing to learn at a book, and a book can teach you all these flags, but what I really like about what you're doing here is you're making it real. So let's focus on the important stuff like you're doing. - Oh, for sure. I mean, the one time that I had to do some deep troubleshooting on the congestion with a reduced aspect of TCP, you know, I got out that Stevens book, the "TCP/IP Illustrated, Part 2," and I had to dig into the protocol.
39:32
So just for the viewers, as you reach the boundaries of what you're comfortable with TCP, that's why we have that reference material, right? That's when it's nice to have a book, that one header value you rarely see, or if you're just learning a new aspect, myself, I'm a student of it too, so don't be afraid to have those manuals around, but absolutely, these bottom ones are where you gonna see the most action. So let's do this. Let's come down to packet two and now let's notice here.
39:56
So this is also a SYN, but this time the ACK bit is set now and forevermore throughout the lifetime of this TCP connection, we will always see the ACK bit set. I will always be using the acknowledgment number, that's now useful. So the only packet in a TCP thread that does not have the ACK bit is the very first SYN, after that, ACK is always set, that is, unless there's a few one-off scenarios, if I'm dealing with a reset that doesn't have the ACK bit set,
40:27
or there's some very, very niche-y things, but most of the time, David, you're gonna see ACK bit set for every packet. The nice thing about understanding these is that we can start to set filters. We can start to go, "Hmm, I wonder how many SYNs I have in my trace file." Well, all I gotta do, I can just come down here to the TCP header, I just right-click this guy, and if I select the SYN bit, you see down here on the lower left tcp.flags.syn, it's down here, - Yep.
40:58
- Wireshark is telling me, "Hey, if you wanna filter for that bit, this is your syntax." It's kinda a cheat sheet. It's a built-in cheat sheet. If I ever wanna filter on that, tcp.flags.syn, so now I can come up here to my display filter, tcp.flags.syn==, let's make it a one.
41:19
Cool. I have two packets that met that filter, SYN and SYN-ACK. Both of them have that SYN bit set, okay?
41:28
All right, so flags, now, as we go forward in our series
41:35
with TCP, deep dive into TCP, we're gonna be covering some of these other flags. We're gonna be covering FIN. We're gonna be talking about what is a PUSH bit. What's a reset? How does that work? But for now, since we're focused on the handshake, I'm just gonna keep moving and just leave it to the SYN, SYN-ACK, that sound good? Window. The dreaded TCP window, ah, how's that weird? - Yeah, hope you're gonna explain this, yep. When I first start, lemme come back up to my first packet
42:01
of SYN, all I'm doing, Dave, is I'm just giving you my starting TCP receive window value.
42:10
What is a receive window? It's basically a receive buffer. I'm just telling you, David, "Don't send me, at once, any more than 65535.
42:21
If you have a gig to send me, you can send me 65535, but you have to wait until I ACK that data. You get those ACKs, you can send me this next block." This is why window size historically has been a bit of a limiter when it comes to throughput, and how much throughput a TCP can can take advantage of on the network. A lot more to say here, but I just want you to keep it simple. I am just telling you how much you can send me at once, how much data I can receive at once.
42:55
Now, notice there's another value here. Okay, so, or that's my TCP receive window, but there's another thing here, calculated window size. All right, so now we're starting to cook with some gas. It didn't take long for, I should say, the network
43:15
to outgrow TCP 'cause, okay, right now you're in the UK. I'm in California. If I told you to send me a one gig file with all the latency between me and you, but you can only do it at 65535, do you think that would take a little bit of time? - It's going to take a while. - Problem is is we have to eat the round trip for every single 65k you send. All of that latency is what's gonna destroy our throughput. If I told you, "Hey, David, I've got a one gig received buffer
43:48
and you've got a one gig file, fire away. Like, I've got this huge swimming pool behind me. I like to use water analogies when I'm talking about these things, 'cause water through a hose is kinda easy to understand, if you have a swimming pool to send me and I'm on the other end of a 100 foot garden hose, but I only have a little shot glass, (chuckles) teeny little glass (David laughs) to receive data into. - Good analogy. - You gotta send me the whole swimming pool one shot glass at a time.
44:16
David, how long does that take? - It's gonna take us a long time, yeah, very long time. It's crazy. - Andyou have to wait. You can't send me anymore. You send a shot glass down that hose, I catch it, I catch the water, and then I say, "All right, David, got it. Send me the next one." And I dump that shot glass into my swimming pool. And then you send me the next shot glass. Literally, this is what we're trying to do. Obviously, the choke point here is my shot glass.
44:40
It's just too small so. - And if you lose any of that, then you've gotta resend it. - Yeah. - Yeah. (crosstalk) - If I lose a drop, then I say, "David, hold up. I lost that one little drop. You gotta send that back over." Right, so that's the idea behind a window. Now, didn't take long for that to become a throughput limiter. It wasn't bad. See, if you and I were on the same network switch, let's just say, there's no latency. We literally are attached to the same network switch.
45:08
We have microseconds of delay between me and you. The window size is not as big of a deal because you start sending me that 65k and I'm already beginning to receive it before you're even done sending it. So I can give you immediate feedback like "David, thanks, David, like, keep sending, keep sending, keep sending." So that window size doesn't become much of a limiter until we add latency, and we're on the other side of the pond from each other. - So does it always start at 65,335?
45:38
- No it doesn't.
45:40
That's operating system or rather stack dependent, whatever TCP stack that the operating system is using. We'll have a starting window size value. Now, keep in mind, there's a bit of a caveat here and we're definitely getting into the weeds here. I'm saying my starting value is 65535. One of the reasons why I have to use that value, I can't go any bigger than that is because here's the thing. How many bytes do I have highlighted over here? Two bytes.
46:10
The TCP header is now limited to those two bytes. I can't grow beyond 65535 with the original TCP spec.
46:21
I cannot tell you a larger number. This is why. And we're gonna go ahead and we're gonna do this now because it makes sense to put it here. If I come down into Options, notice one of the things that I tell you, David, if I come down to window scale, ooh, this is an option that came around later. We ran into a bottleneck with 65535 bytes. We needed more out of TCP, but we were limited by the header space. So the window scale option was introduced into TCP. Now, what is this?
46:53
Basically, Wireshark does the messy math for us, basically, if I'm saying, "Okay, windows scale is the option. The length of this option is three, blah, blah, blah, blah, shift count is six, basically, sorry, for the math, everyone, but two to the sixth power, okay, we're at 64," Wireshark does up that math for you, basically, Wireshark is saying "Multiply by 64." I'm offering this to you in the handshake. I'm saying, "David, when you see my window size, take that value and multiply it by 64,"
47:26
and that will then be my calculated window size. Now you can take 65535 and multiply it by 64. That's my true window size. But I only tell you that in the SYN. Here's the thing, though, check this out, there's our window scale, all right? I'm telling you, "David, I wanna use the window scale option" because this 65535 thing is for the 80s, like, that's so long ago, like I wanna actually move some data. I wanna throw away the shot glass and I'll bring out like a gallon jug,
47:56
and then you can start to send me water at a much higher rate, or I forget the gallon jug, I got a huge 10 gallon barrel over here. - Yeah. - So if you send me 10 gallons of water at once, I'm gonna catch it all without missing a drop. I'll dump that into my pool and you can it get going with the next 10 gallons. I can only use this, though if you know what a window scale is, what if I'm talking to maybe a TCP stack on an old printer from the early 90s, and it has no idea
48:24
what a window scale is, or, much more realistic example f or you, you've ever heard of an IoT device.
48:32
My doorbell, my smart ceiling, my this, my that.
48:38
A lot of those have a very low end, low power TCP stack on 'em, they don't have to use a lotta these heavier features that clients, typical clients and servers do. So I challenge this to the audience, when you're looking at TCP handshake, specifically with IoT devices, check out the window scale, not just you to that device, but also the device back to you. Let's see what David did. Let's go to packet two. Let's come down to David's options that he sent me, you're saying window size 565535.
49:10
Wonderful.
49:12
Window scale is nine. Okay.
49:16
So, David, you've got some real buffer that you can use. - It's the server, it's the server, isn't it, so it must've. - Yeah, exactly. So shift count nine two to the ninth power. You're telling me, "Not only can we use window scaling, but when you see my window size, go ahead and multiply that guy up, multiply it by 512," and that's my true window. So what just happened? I told you, "Hey, David, I got the shot glass, but if you want, you know, we can do some heavy lifting here.
49:50
I've got a 10 gallon barrel over on my end. So although it looks like I have a shot glass, go ahead and send me the 10 gallon barrel. Just multiply it." Now you came back and you told me "Awesome. We can use these barrels, you know, these glasses aren't doing the work we need to do here. I got a 20 gallon barrel." Here's the thing about servers, and you said it well, and this is what you commonly will see, well, servers,
50:14
a lotta times they have a bit more resource on their end to do some heavy lifting. In many cases, I'm not sending data to a server. In many cases, though, you're gonna see this on a server where it's got a larger shift count. It can do this multiplication. But if you think about it, again, I'm asking for your data in your swimming pool, David, you send it across to me and I'm catching it as a client. A lotta times we're asking for data, sending data up. I mean, yeah, I can send data to a server.
50:42
I can upload things, absolutely. But as clients, a lotta times we're asking for data. So it's not unusual to see the client have a pretty large window that we actually take advantage of. I'm not gonna send you 20 gallons to your barrel, right? But what do we learn here? In our handshake, we have options. In this case, I offered a window scale to you and you responded with a window scale back. This means, David, we can use TCP window scaling. If you did not respond with a window scale,
51:11
then I don't get to use this option. So what does this mean? Guess what, sometimes I'll have my clients send me a PCAP or maybe the good viewers out there, you've seen a PCAP.
51:23
I'm doing this at random, everybody. Lemme come down. I'm just gonna pick packet eight and let's take a look at the window size. The window size is 131. This is from server. So, David, you to me, you're saying "Window size, 131. Don't send me anything larger than 131 bytes." - Okay, it does make sense, 'cause we went from 65,000, doesn't it? - Right, yeah, exactly. Because we got the handshake, Wireshark can calculate the true window size for us. So yeah, David's saying "131,"
51:54
but we have his multiplication factor. We can multiply this by 512 and the true window size that David is advertising a 67k. The reason why I show this to you, and for the viewers out there, is sometimes I'll get people, they'll send me a PCAP and they'll go, "Oh, Chris, look at this window size coming off of this server, it's 131 bytes. This must be the reason for my bottleneck." And I go, "Well, did we get the handshake? Do we know what the multiplier is? 'Cause odds are beyond likely
52:22
that that server is not genuinely dealing with 131 byte receive window." Instead, we're using window scaling. And when we don't capture the handshake, if I started capturing right here, David, on packet eight, we wouldn't know what the multiplier is. So Wireshark, it would have 131 here and it would go, - Yeah. "I dunno how to multiply this, so this could be true," (chuckles) right? Questions on that. Lemme back up to the handshake. - You tell me your window size and I tell you my window size,
52:58
and that's the maximum amount,
53:01
or that your buffet can handle, sorry. Does that scale, as like during a session, do we start with a small window size and then it grows, or how does that work? - That's a good question. Yes. So that's also operating system dependent. A lotta times window sizes are dynamic and they will grow, depending on the application and how much perceived data that I have coming in. So for example, if I do a GET on web, typically a web application, you know, okay,
53:26
I'm bringing data in, a lotta times what you'll see the TCP stack do is it will grow this window size. This is not this finite number that's always static. In fact, let's do this. Let's go to our calculator window size. We're gonna right-click this, and we're gonna add it as a column.
53:44
And what I wanna do is I'm gonna come over here. Now, this isn't a very long trace file that we're dealing with, but you can see, okay, I sent you 65535. You sent me back 65535. And then in the third packet of the handshake, this is the first time that you actually see me use or Wireshark use this calculator window size. Let's look at the third packet. You see my window is now 2052. Well, we know that's not true. We've exchanged the window scale. So now Wireshark knows how to multiply this.
54:19
And you as well know this, David, because you're the server. You heard me tell you, you know how to multiply it by 64. Now my calculated, my actual window size is 131328. This is another reason why I always right-click and I use calculator window size, not the true window because the true window is so low, and it's not the real number. The real number is this one. Let's just head check something here. Let's come down. So let's see what this number does
54:46
and this PCAP isn't super good at teaching this aspect. We definitely will be getting to this on a future video with a PCAP that we'll be troubleshooting with. But notice here it drops a little bit, 13816, and then it drops down to 129856, Then it comes back up and then it drops a little bit. You see, this number is always gonna vary a little bit. It's always gonna kinda float. What I don't want to see, though, David, is basically, if I come down to packet seven,
55:14
you see how we do drop just a little bit? - [David] Yeah. - So what I told you is, "Okay, I've got a 10 gallon bucket." Well, let's just say you sent me a 16 ounce glass of water, and that comes dripping into my bucket. Now, I'm able to dump that into my swimming pool. Let's just say, due to the stack and the interaction of the application, you sent me 16 ounces, let's just say I dump 10 ounces into the pool, and there's six ounces sitting in the bottom of my bucket,
55:44
the amount of space I have leftover just reduced by a little bit, right? 16 ounces came in. I threw 10 ounces to the application, but there's six ounces left. So my buffer just reduced by just a little bit. That's why this number goes down. I'm telling you, "David, now I've got enough room for nine gallons and 12 ounces." I still have room. So you can still keep sending, but there is a little bit of data that's pulled in the bottom of my bucket. Don't worry, I'll deal with it on my side.
56:14
I'm a client. I'm gonna get that stuff to the server. Not long after that, more data comes in from you.
56:20
Again, you can see, I went down to 129856.
56:24
So that just tells me there's a little bit of water in the bottom of the 10 gallon bucket that I haven't yet dumped to the application, but right after I caught it and sent you this ACK, because I don't worry too much about getting this to the application, while figuring out the ACK number and getting you the ACK, I wanna make sure that you're not gonna retransmit unnecessarily. So I got you the ACK, and then right after that, you can see that my window size went back up.
56:52
So what happened here is I took my 10 gallon bucket, I dumped it to the application, into the pool, and now I'm back up to my full window again, all right? So it's not uncommon to kinda see these numbers float a little bit like this. And I don't think anybody out there should worry too much. If you do see, you know, a little bit of float around a common point, it could also be, after we really get cooking and moving data, I might figure it out and go, you know what, 131,
57:19
we gotta increase this thing. Let's go up to a meg, two megs, you know, a gig. It could be all the way up to a gig of received space that I have, but this value absolutely can increase. And again, that's just stack and OS dependent.
57:36
David, this is the thing to really watch out for, what I don't wanna see is to have this number drop, drop, drop, drop, drop, drop, drop drop, and then go down to zero. If this number goes to zero, that means my 10 gallon bucket is full. I haven't yet dumped it to the pool for whatever reason, that's a whole nother conversation, but I got a stuck buffer. Data's there. Hey, David, stop sending, and you have to sit there and just go, "Hmm, lemme know when got more space,
58:05
Chris," (chuckles) that's called the zero window. - And that's the thing you're looking for, yeah? - That's something you never wanna see. If I see zero windows, then I go, "Ooh, okay. The receiver of the data is stuck." That data is stuck in that buffer, and it's not clearing that buffer as fast as data's coming in. I'm gonna pause on windows because I think, you know, maybe for a future session for another video, we can go into some specific TCP window problems.
58:33
And I can show you guys some PCAPs that I have that really spotlight this being a choke point, and when to look for it when we're looking for slow applications or slow downloads. I will tell you that when anybody says the word slow, like, "Hey, Chris, I was trying to download this file, and it was really slow," window size is always something I'll keep my pulse on. And in fact, there's even graphs within Wireshark that let me grab this out over time and show me if it ever dips.
58:57
David, before we end up, there's something I absolutely wanted to make sure you knew as well, so let's go ahead and take the options. And so we've already talked about our window scale. Also, in the TCP handshake, we advertise our MSS, our maximum segment size. You can see here in the SYN from a client to server, it's 1460, and in the opposite direction, it's 1440. All that means is, don't send me a segment with any more payload than this, right?
59:28
So this is an advertisement of how much I can receive at once in a single segment. We'll definitely be talking about that in a future video, these numbers do not have to match. They do not have to agree. They're not negotiated. This is simply an advertisement. "Don't send me anything larger than 1460. Hey David, you're receiving 1440. So let's just go with that." We exchange that. Also SACK. So in the SYN, So I tell you, "I can do selective acknowledgment."
59:57
We're gonna get into that as well in another video. But if I do not advertise that I can do SACK and then you come back and say, "Great, I can do SACK as well," if one of the two of us does not support SACK, then we don't get to use it. - [David] Yeah. - Again, why it's so important in the handshake. - Chris, I think we must continue this series. I think we only scratching the surface, is that right? - Absolutely, yeah, yeah. - For everyone watching, please, you know, put your questions below,
1:00:25
you know, questions relating to TCP, and I can ask Chris to answer those questions in the next video. I wanna have many videos in the series if you're okay with that, and I wanna thank you for sharing. - Absolutely. That'd be a great time. And like I said, we have a lot to get to, but don't worry, TCP, it looks overwhelming, but we're gonna be going through it and really showing you most of all, how you can use these features, these values, and Wireshark
1:00:53
to be able to be a better troubleshooter and a better analyst. So thank you so much for having me, David. It's been a good time. - Thanks, Chris, cheers. ♪ Woo ♪ (upbeat music) (person scatting)
Here to help you learn
Sign in to keep a private conversation with your course tutor.
Ask me anything about the material…
Sign in to chat