How TCP really works // Three-way handshake // TCP/IP Deep Dive

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 hey everyone it's david bumble back with chris had a lot of 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 going to show us today because i'm quite excited about

this topic yeah so we had a lot of 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 uh 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 kind of stuff that you want me to

ask chris on future videos you know stuff that you want to see we want to create a whole bunch of videos including a series on tcp so see this is 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 is it true that you're going to 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 we really encourage you to do that because i think all of us we learn by doing we retain better when we actually have our hands on it so we encourage everybody to do that that's great so you take 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 because uh how many of us 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 it's always your fault come on right ah it's slow it's the network oh it's step not connecting properly it's the network it's the network i think it's kind of 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 is saying i'm sorry my network's slow today exactly have you ever had that experience yeah exactly it's always it's 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 is not healthy if i see re-transmissions out of orders window problems those kinds of things or especially with three transmissions okay now i can go down to the network why is the network dropping traffic

why are things not being passed properly what kind of hiccups are we having and getting data through so that's why david we're going to 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 cyber security 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'd 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 want to 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 yeah i hope you're going to 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 going to spend some time on the handshake only we're going

to 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 sin akak because that's what most people know it for you we passed that question on our cna good sin sinaka wonderful why is it called sin what's happening in that handshake really why was that term selected what is an act what are we acting let's get to it so if we take a look at this pcapp and again uh everybody go get it go download it and the one you're going

to make sure that you're on is tcp handshake and i threw my name on there just so 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 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 going to focus in on let's go ahead and get into that handshake i'm going to take a look at packet number one this is just the first packet in the 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 going to go ahead and move my detail up a little bit move my hex over just to see head check to see if i have any clear

text over here of course you know in the sin i'm not going to see any data but i just wanted to see what we have over there i'm just going to move this back okay so in my detail if i i'm going to skip over layer 2 layer 3 which would be ethernet ip i'm just going to go straight to layer 4. now first thing i can see the client is sending it's it's starting from this high number source port we call this the client-side ephemeral port usually this is a pretty big number like you

see here right away when i just see that when i 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 54 846 the server's on 80. port 80 is going to be a common number it's going to 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 sins go out sin sin well then i would see stream zero then 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 sin 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 sin to you david i'm telling you hey i'm going to start counting the data in my direction from this number it's called the isn

initial sequence number just randomly selected yeah well how is it chosen yeah it it's it is a somewhat random thing um their operating systems at least historically uh they'll typically start in a certain range i mean i i can't spout that off the top of my head and go hey well you know this must be a max system or something like that but a lot of times you'll see them start in certain ranges the idea here is it just has to be unique right it just and it's a number that's randomly generated it's a high

number it's very unlikely i'm going to see this again on a different connection very near in the in the future right that number i i offer that to you and then wireshark just does me a solid it just says hey uh let's just zero this number out because we talked a bit about this in a previous video how wireshark goes you know what uh you 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 yeah 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 ephemeral port goes by different names i can't remember the the ranges or the top of my head but it's it's a high number isn't it and then like the uh 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 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 got to use 54 846 if i want to start a new connection to you well then i can either increment it by one depending on the operating system it might be again be random i could jump up to 55 900 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 um a place to stick that data that the application can use so there's there's something that happens in the handshake and this is where we're going to start to deviate from the the the simplicity of cincinnati this is what's actually going on under the hood you notice my next sequence number is one yeah what this means is that wireshark is telling me

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 tcp segment length stream index the port numbers are a part of the protocol so is the sequence number but this is just extra info uh that wireshark's helping me out with but it says sequence number one so what happens when i send you a sin okay you're going to be the server all right david i'll be the client

i send you a sin hey mr server here's my starting sequence number and i also 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 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 going to do is you're going to increment the sequence number by one and then you're going

to send me back an acknowledgement number plus one so let's do this let's just remember this 7413 right here okay take a look at our synack i'm just going to come down and take a look at the now the acknowledgement number in the synack so 74 14. okay i'm gonna do that again let me go back up to my sin 7413 here and then you come back and you say ack but plus one all right so what does that do now the relative act 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 this synaptis 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 he he we're synchronized as far as i'm concerned you just act my sin i'm now good i'm now perceiving that

you're there and we can we can chat now there's more going on beneath this 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 sin act that you sent me if i come up here let me take a look at my delta time my delta time is the amount of 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 want to make sure you do in wireshark just going to come up to wireshark preferences if you're in a windows system we're going to go to edit preferences let me jump there real quick and i'd like to show you if i go to columns all i got to do is i just got to add a column let me just go delta and then for the good viewers you just come over here to type and then we're going to come up to delta time displayed and then once we have that i just

like to as a style thing i just like to move this up next to the running time that i have there i'm going to 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 serve 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 iptl at 255 because this number 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 that's it's very unlikely it's it's most likely that you started at 255 and what are the numbers that we started normally sorry for the people who didn't watch the other video no problem 64 128 and 255 are the most common starting ttl values in fact let's test that theory my machine when i sent out the sin 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 your 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 sin you or 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 quick yes he has a very basic question just to step back why do we need some numbers because that's how tcp is reliable right one of our test questions is often is it's connection oriented it's reliable it's for sure um it 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 act back to me you're going to 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 that my brain does not want to 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 synack now he doesn't just act me let me come back down to that synack he hasn't just plus one my sin but he also gives me his ack 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 say 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 rand number 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 going to be 1 that's

relative right that's wireshark saying hey you're sending a ghost bite with your sin right that that false one that you you send back to me and now let's see let's just remember this 5106 okay there's our value let's just kind of commit that to memory 5106. all right so what i would expect is in the final packet see i now save 50 107. i added one to your sequence number and notice too my sequence number i'm now at 74 14. 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 because they're just so big this is the whole point wireshark's like ah 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 act one i know that's a successful handshake i sent you my my sequence number u plus one act it at the same time you sent me your sequence number i plus one acted we're synchronized and the synchronization is so that we well part of

it is to know what the initial sequence numbers are yeah so we exchange that excellent that's exactly it so that when i send you data you can increment your my the the sequence number that you see of 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 are completely they're completely isolated to our direction or rather they're they're uh 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 177 96 number and in your direction we're using this 205 805 yeah number and or does it i'm going to ask you all the basic questions that people may have is the first one always a sin is the second one always a synac and is the third one always an ack is it like always like that that's a great question and the answer is yes uh we can't start for example on this get this is the application sending

data now let's actually do this um there's an actual payload sitting in here right tcp 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 we establish sin synack over there the data

sent was 501 bytes or something is that right um yes so does this sequence number jump from did i read that right it jumps from 1 to 502 is that right because 501 bytes per cent is that 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 i like i like where you just went with that i'm just going to collapse my ip just that it causes so much confusion because

the big numbers and you know how 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 packet four now if we take a look at packet four here we have there's my sequence number and 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 ccp is 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 because i just sent you 501 bytes in on my side i basically

jump 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 acknowledgement 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 sun

buffer until you get you act 502 once you've act 502 i can say great okay 501 get out of 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 because you've got to buffer that and to like acknowledge it yeah absolutely yeah imagine if uh and we'll get into this in other trace files imagine if i don't hear this acknowledgement what do i do then well then i gotta i gotta basically have to wait for a timer to

expire uh i'm like you know what david i put that 501 bytes out there uh i'm gonna a timer will expire on this data and then i will re-transmit 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 going to say okay so then so 502 has been acknowledged so on the client side seeing that we're 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 some other data has been so 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 one the 501 that we sent before right but that remember that the get the the data that was being requested and it honestly doesn't matter the application this was 501 bytes that the client sent to the server that was acknowledged and now the server

is responding with 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 number in this direction will be 5 35. and you've kept it the you kept the ack at 502. yeah sorry go on good job that's exactly where i was going 502. it's exactly the spot i didn't send you any more data you're repeating that acknowledgement

number now it's not a duplicate ack or you know that's a whole different situation basically you you're just acknowledging that i haven't sent you anything new yeah your sequence number went up but your act number stayed the same that's great and so if you go to the packet seven we should see perhaps that that increases now here yeah exactly so yeah this is this is why uh you hit on a good point david so this is from client two server my sequence number is now 502 but now my acknowledgement number is 535. so now i

am acting 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 in this is an empty act you can see on packet number seven let's have everybody join me there tcp segment length is zero that i call this an empty hack the purpose of this packet is only for you to 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 i can see payload length and not overall packet length or frame length if i'm looking at it including the ip header and the ethernet frame if i only want to 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 do you how do you feel about sequence numbers yeah i wanted to sorry chris i'm trying to push home this point because we started with a client so if you scroll down is there where's the next one that the client's 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 we should have gone the is that yeah there we go so um so 502 we got 439 bytes

from the upper layers um so the next sequence number is 502 plus 439 is that right that's correct that's a good spot so in this direction from client 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 9

41. it's 502 plus 439 equals 9.41 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 some 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 cincinnati it's

a whole lot going on and these sequence numbers synchronizing is really why we call it cincinnakak and it's a key part of how the protocol works so we if you go to 12 we should see that is that right sorry i just want to wrap this up because i i took you on a on a tangent here it's okay tangents are not a problem they're good all right so uh yep so i send you 439 and if i come down to 12 there's my 941 at the same time in the opposite direction we've 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 that's you know this is an empty packet but the next one you to me 1726 i'm going to add 500 and the next expected sequence numbers is 22.26 now wireshark does something kind of 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 acknowledgement the cool thing that wireshark does if

you notice on packet 12 so he's acting 941 my other packet got there check out my our little check box you see that next to packet 11 oops is there a little check mark there that's a visual way where wireshark says okay packet 12 is acting 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 why are sharks 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 re-transmit it now i can clear that data out of my tcp send buffer and then i can carry on with life sequence and acknowledgement numbers a huge thing that is important to really understand we're using tcp and it also can really help us get to the root if we have missing data if we have re-transmissions we're going to be building out this conversation this tcp series is going to go into this but understanding having a good understanding of how sequence numbers work is key to understanding re-transmissions 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 want to check in with david are we doing good on sequence numbers yeah so just to summarize you and i both pick a number let's assume you're the client like we used in this example i'm the server you and i both pick some number and then we do the cinsona ack to 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 y-shock 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 with the other i think that's what gets confusing because you look at all those numbers and you get i find it difficult like okay so which side am i looking at and you know which numbers are relating to which you got to kind of separate it in your mind is that true chris and then how would how in the real world because you do this stuff all

the time in the real world how do you you know get your head with all around all these numbers and data and stuff is it just practice or you know are there any quick tips oh that's a that's a a good point and an 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 pack at

a time pack it at a time and watch how these numbers increment i'm not gonna lie to you though david i'm i'm kind of old school when someone sends me a pcap file and i realize 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 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 right here just with a glance david the round trip delay that we're having the initial starting um 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 sin goes out 20 milliseconds later we get a syn act back and then boom the act 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 get a piece a big piece of paper draw all my capture points take a look at the sequence numbers and then track them through the system for for the more intermediate advanced people that are watching right now a nice thing just so you know because i have been asked this several times on my channel and and i've seen it on the industry the

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 if i let's just say david that you're on the other 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 sin that chris sent and this was the sin that david received one of the ways we

can do that is by setting a filter for the sequence number okay but yeah uh 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 now this is great let's go deep and i mean i'll just say this anyone who's watching um you know give us feedback i'm trying to 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 your stories it's great to hear the real world stories for sure um yeah no worries tcp was written a long time ago right the rfc uh you're talking about rrc 793 793 and it came out i believe september 1981. it's been 40 years long time yeah let me ask you this david when they were sitting down in you know the standards masters the people that are amazingly brilliant i mean think about it they put this thing into introduce this 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 were very very slow x25 had tcp at layer 2 didn't it so same kind of idea layer 2 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 started to basically there we needed more we needed more out of it so i wanted to show you uh in the next section we're going to go through which is going to 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 going to start getting into the stuff that is more modern tcp let's go ahead and talk about uh okay so just briefly i'm okay everybody join me back at packet one uh so we're on header length okay so uh within tcp the header itself uh when i first send you the sin 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 yeah i got 24 bytes of options if i don't have this header length of 44 bytes basically i don't have enough room top to bottom in 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 sin synoc once

once these sin synax 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 you 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 uh one of the reasons why we've needed to move to a new protocol like quick is that we're starting to run out of the maximum space that the header length can be that means that we 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 just we're running out of space tcp is starting to reach a bit of a limit so that's why

and this is fuel for another video david but this another reason why we're starting to see more of a move toward quick because it doesn't have some of these limitations that's all i'll say about that for right now um i definitely want to move into flags because this is something if you are a pen tester 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 uh tcp flags are an important thing to understand let's go ahead and get into it the flags field if

i i like to just 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 this flag part of the header and this is just telling me that this is a sin 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 one so there's the sin bit is set that means that this tcp station or whoever's sending this tcp sin out is telling

you or me to you david i'm saying this is a sin it's not a synack i'm not using the acknowledgement number because if you notice up here you can see on the original sin my acknowledgement 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 sin i don't even have the act bit set i have no this is just basically space it's just all zeros over there in the header there's nothing going on in the act number

so sin 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 uh things now there are some other uses obviously for the for these other flags let me just go over real briefly you're rarely gonna see reserve i don't even know if i've ever seen that in the wild no wants i don't even think i've seen it in the wild one time i've seen the congestion would have reduced practically used very rare you'll often see this be zero ec echo

explicit congestion notification echo not sent again not something you're going to see often urgent you're not going to see often so as you're learning tcp just for now let's just skip over these first five these bottom ones are you're going to be spending most of your analysis time ack push reset sin infant 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 in a book and a book can teach you all these flags but what i really like about what you're doing

is you're making it real so let's focus on the important stuff like you're doing oh for sure i mean when the one time that i had to do some deep troubleshooting on the congestion would have reduced aspect of tcp you know i got out that stevens book the tcp illustrated part two and i was just i had to dig into the protocol so uh just for the viewers uh as you reach the boundaries of what you're comfortable with 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 those manuals around but absolutely these bottom ones are where you're going to 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 act bit is set now in forevermore throughout the lifetime of this tcp connection we will always see the ack bit set i will always be using the acknowledgement

number that's now useful so the only packet in a tcp thread that does not have the act pit is the very first sin 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 act bit set or there's some very very niche things but most of the time david you're going to see backpit 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 got to 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.sin it's down here wireshark is telling me hey if you want to filter for that bit this is your syntax it's kind of a cheat sheet it's a built-in cheat sheet if i ever want to filter on that tcp dot flags dot sin so now i can come up here to my display filter tcp dot flags

dot sin equals equals let's make it a one cool i have two packets that met that filter sin and synac both of them have that send bit set okay all right so flags now um as we go forward in our series with tcp deep dive into tcp we're going to be covering some of these other flags we're going to be covering fin we're going to be talking about uh what is a push bit uh what's a reset how does that work but for now since we're focused on the handshake i'm just going to keep moving

and just leave it to this in synac that sound good window the dreaded tcp window uh how are you going to explain this yep when i first start let me come back up to my first packet of sim 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 65 535 if you have a gig to send me you can send me 65 535 but you have to wait until

i act that data you get those acts you can send me this next block this is by why windows size historically has been a bit of a limiter when it comes to throughput and how much throughput 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 that's a receive or that's my tcp receive window

but there's another thing here calculated window size all right so now we're really now we're starting to cook with some gas it didn't take long for tcp to basically i should say the network to outgrow tcp because 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 65 535. 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 receive buffer and you've got a one gig file fire away like i've got this huge swimming pool behind me i i like to use water analogies when i'm talking about these things because water through a hose is kind of 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 or a teeny little glass to receive data into you got to send me the whole swimming pool one shot glass at a time david how long does that take it's going to take us a long time yeah very long time it's crazy and you have to wait you can't send me any more 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 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 class it's just too small so and if you lose any of that then you got to reset it yeah yeah if i lose a drop then i say david hold up i lost that one little drop you got to send that back over right so so that's the idea behind a window now it didn't take long for that to become a throughput limiter it wasn't bad see if you and i uh

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 have latency and we're on the other side of the

pawn from each other so does it always start at 65 335 no it doesn't um this is that's operating system or rather stack dependent whatever tcp stack that the operating system is using will have a starting window size value now keep in mind there's a bit of a caveat here and this is we're going to get into a little bit more of a we're definitely getting into the weeds here i'm saying my starting value is 65 535 one of the reasons why i have to use that value i can't go any bigger than that is

because here's the 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 65 535 with the original tcp spec i cannot tell you a larger number this is why and we're going to go ahead and go this is why we're going to 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 this is an option

that came around later we ran into a bottleneck with 65 535 bytes we needed more out of tcp but we were limited by the header space so the windows scale option was introduced into tcp now what is this basically let's just wireshark does the messy math for us basically if i'm saying okay window scale is the option the length of this option is three 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 all that math for you basically wireshark is

saying multiply by 64. i'm offering this to you in the handshake i'm saying david [Music] 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 65 535 and multiply it by 64. that's my true window size but i only tell you that in the sin here's the thing though check this out there's our window scale all right i'm telling you david i want to i want to use the window scale option because this 65 535 thing is for the

80s like that's so long ago like i i want to actually move some data i want to 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 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 going to catch it all without missing a drop i'll dump that into my pool and you can 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 uh maybe a tcp stack on an old printer from the early 90s and it's it's that has no idea what a window scale is or much more realistic example for you you've ever heard of an iot device my front my my doorbell my led like my smart ceiling my this my that a lot of those have a very low end low power tcp stack on them they're not really they don't have to use a lot of these heavier features that

clients typical clients and servers do so i challenge this to the audience when you're looking at tcp handshakes specifically with iot devices check out the windows 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 2. let's come down to david's options that he sent me all right you're saying window size 56535 wonderful windows scale is nine okay so david you've got some real buffer that you can service a server isn't it so it must have 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 this shot glass but if you want we can really get some 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 forget you know these 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 while servers they they have a lot and a lot of 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 going to 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 lot of times we're asking for data sending data up i mean i can send data to a server i can upload things absolutely but as clients a lot of 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 going to 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 windows scale to you and you responded with a windows scale back this means david we can use tcp window scaling if you did not respond with a windows 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 and you've come down to i'm

i'm doing this at random everybody let me come down i'm just going to pick packet 8 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 yeah it doesn't make sense because 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 is 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 because odds are beyond likely that that server is not genuinely dealing with a 131 byte receive window instead we're using windows scaling

and when we don't capture the the handshake if i started capturing right here david on packet 8 we wouldn't know what the multiplier is so wireshark would just say it would say it would have 131 here and it would go uh yeah i don't know how to multiply this so this could be true right questions on that um let me back up to the handshake while you're you tell me your window size and i tell you my window size and that's the maximum amount of data that i can send you or that your buffer can

handle sorry does that scale as like during a session does it 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 lot of times windows 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 okay i'm bringing data in a lot of times what you'll see the tcp stack do is it will

grow this 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 going to right click this we're going to add it as a column and what i want to do is i'm going to come over here now this isn't a very long trace file that we're dealing with but you can see how uh okay i sent you 65535 you sent me back 65 535 and then in the third packet of the handshake this is the first time that you actually see

me use or wireshark use this calculated window size let's look at the third packet you see my window is now 20 52. well you know that's not true we've exchanged the uh 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 131 328. this is another reason why i always right click and i use calculated window size not the true window because the true window

is so low and that's 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 this p cap 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 138 16 and then it drops down to 129 856 then it comes back up and then it drops a little bit you see this number is always going

to vary a little bit it's always going to kind of 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 yeah so what i told you is okay i've got a 10 gallon bucket well you sent me let's just say you sent me a 16-ounce glass of water and that comes dripping into my my bucket now the application the applica i'm able to dump that into my swimming pool let's just say due to the stack and the interaction

of the application i only dump 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 left over 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 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 9 gallons and 12 ounces i still have room so

you can still keep sending but there is a little bit of data that's pooled in the bottom of my bucket don't worry i'll deal with it on my side i'm the client i'm going to get that stuff to the server not long after that more data comes in from you i temporarily again you can see i went down to 129 856. so 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 it's really important for me to i don't worry too much about getting this to the application while figuring out the act number and getting you the ack i want to make sure that you're not going to re retransmit unnecessarily so i got you the ack and then right after that you can see that my app 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 kind of 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 out and go you know what 131 we got to 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 receive space that i have but this

value absolutely can increase and again that's just stack and os dependent what i never want to see david this is the thing to really watch out for what i don't want to see is to have this number 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 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 let me know when you got more space chris that's called a zero window and that's the thing you're looking for yeah that's something you never want to 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 being it's not uh clearing that buffer as fast as data's coming in i'm going to 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 chokepoint 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 graph 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 sin from the 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 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 are not negotiated this is simply an advertisement don't send me anything larger than 1460. hey david you you're receiving 1440 uh so let's just go with that did we exchange that also sack so in the handshake pat in the sin so i tell you i can do selective acknowledgement we're gonna get into that as well in another video but if i do not advertise that i can do sac and then you come back and say great i

can do sac as well if one of the two of us does not support sac then we don't get to use it yeah again why it's so important in the handshake chris i i i think we must continue this series i think there's a lot of stuff that 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 in the next video i want to have many videos in the series

if you're okay with that and i want to thank you for sharing absolutely that'd be a great time um and like i said we have a lot to get to but don't worry tcp it looks overwhelming but we're going to be going through it and really showing you most of all how you can use uh these 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