- 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) 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, 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 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. 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. 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, 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?" 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, 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. 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 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? 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. 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. 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, 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, 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." 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 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? - 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 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, 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 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, 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. 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, 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. 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. 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 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. 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. 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, 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? - 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 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. 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. 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 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. 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. 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. 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 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. 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. - 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 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 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? 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. 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, 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 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? 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 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. 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, 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. 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. 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. 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. 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 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. 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. 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. 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. 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, 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. 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, 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. 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? - 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, 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? '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, 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. 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. 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 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. 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. 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. - 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. 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, 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 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. - 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. 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. 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, 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. 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, 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. 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 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, 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. 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. 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, 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. - 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. Cool. I have two packets that met
that filter, SYN and SYN-ACK. Both of them have that SYN bit set, okay? All right, so flags, now, as
we go forward in our series 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 of SYN, all I'm doing, Dave, is I'm just giving you my starting
TCP receive window value. 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. 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. 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 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 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. 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. 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. 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? - No it doesn't. 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. The TCP header is now
limited to those two bytes. I can't grow beyond 65535
with the original TCP spec. 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? 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," 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, 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 what a window scale is, or,
much more realistic example f or you, you've ever
heard of an IoT device. My doorbell, my smart
ceiling, my this, my that. 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. Wonderful. Window scale is nine. Okay. 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. 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, 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. 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, 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. 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," 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 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, and that's the maximum amount, 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, 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. 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. 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 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, 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, 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. I'm a client. I'm gonna get that stuff to the server. Not long after that, more
data comes in from you. Again, you can see, I went down to 129856. 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. 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, 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. 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, 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. 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. 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? 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." 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, 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 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)
