How TCP really works: Top 3 things you need to know!
You mentioned TCP and the reason why we do that is because so many applications critical things that are running across our networks use it. We did promise you though 3 core things you need to learn about TCP If you're going to be doing TCP analysis you've got to master these 3 things. I mean it's it's important to highlight right You do this day in and day out So this is not theoretical classroom stuff but you're sharing it with us but you're sharing a lot of your real world experience. What we just walked through are the 3 things that you need to know about TCP and
these are important concepts to really master and show you what really matters and what helps me do my analysis. Everyone it's David Bombal back with the amazing Chris Greer. Chris is the person I talk to always when I want to know how Wireshark really works. Chris great to have you back on the show. Great to be back David thanks for having me back. Now Chris we I mentioned Wireshark there but it's actually the protocols that you're analyzing that's important and I know you really like TCP and I'm hoping you're going to tell us like some of the most important things to know about TCP. Yeah you said it well David. Sometimes we're talking about the analyzer
itself that is Wireshark but a lot of times we're talking about what Wireshark helps us to analyze and that's going to be protocols on the network. You mentioned TCP and a reason why we do that is because so many applications critical things that are running across our networks use it. I've got to say this because this comes up a lot whenever I talk about TCP and it happened on our previous short which I put on my channel people say TCP is dead. It's been replaced by QUIC and
UDP. What's your answer to that? No. I don't think that's quite true at least just yet. Now over the web yes QUIC is starting to have more and more of a foothold each passing day Uh QUIC runs over UDP and a lot of the mechanics of TCP still live on within QUIC I know we've talked about that previously on your channel. Yeah .But TCP itself is still alive and well. It's still delivering enterprise applications. It's still delivering a lot of important uh systems and structures. So it is here and I think it's going to be here for a very long time. And AI is going to replace us right with packet analysis. AI is going to help us just like it's doing everything else. So even
myself I'm starting to use more AI tools in my analysis. But that doesn't mean that we still don't have to know what's going on. Uh for me the expression I I try to share in my courses when I'm teaching Wireshark is try not to automate what you don't understand. Yeah. So if you don't
quite know how something works be careful about just running the AI to do the work for you because that's where once something breaks and you have to troubleshoot it that's when we'll be in trouble. So Chris that's enough talking I'm going to hand it to you show us your top 3 tips or the top 3 things that are most important to know about TCP. Yeah let's focus on that Uh and I think this is it's important It's something I'm passionate about so let's get to the packets. All right we all came here for packets. We are packet people including you David. So let's get into it. So here I'm just going to open up my little screen and uh I was just doing an analysis for another client. So
you're live real time seeing what I was looking at at least with the profile that I'm using I'm actually going to do a little bit of cleanup here so people can see uh some of the things that I'm going to adjust for this specific analysis. Uh if I take a look at time of day was interesting for me So I'm just going to come up here I'm just going to say second since previous Cap or I'm sorry second since first captured packet what that does is it just resets my timer. First packet is zero and then as things go on I can see how the packets hit the analysis point. I'm going to leave that alone. People know I love delta time. So uh we can just uh link in a video here to show how to add that uh source destination we are alive and strong there protocol got DNS and TCP people TCP length so if you don't have that in your Wireshark right now all you got to do just click on packet 4 which we have shared this pcap in the description down below so go get it Uh if you expand TCP I'm going to come down here to TCP segment length and you can take that literally physically drag it and drop it up to your column header up here and boom you've got the same thing that I do. Now you might also in your copy of Wireshark also have a length that's
already there. All you got to do right click that column header and you can just click and click um any column headers that you see up here. By the way QUIC side point everybody. A question I usually get when I'm showing all this is "How can I get mine to look like that Chris? Can you share your profile?" We did that as well. There's a link in the description down below where you can
import my TCP plane profile and you can get all of my coloring rules. You can get my buttons up top and all the stuff that I got configured here for Wireshark. So we'll share that as well. That's great. I got IPTTL as well. That's something I like to use uh to if you don't have that. Let's go down to the IP header going to come down to uh the time to live again drag drop boom and that'll give you IPTTL for me for now I was just looking at a pcap where VLAN ID mattered I'm just going to take and I'm going to remove that for now cuz guess what I've got a real job David And I got to get back to that after this recording believe it or not. I mean it's it's important to highlight
right. You do this day in and day out. So this is not theoretical classroom stuff but you're sharing it with us but you're sharing a lot of your real world experience. You just watch my brain work through yeah the packet list and just try to reset some column things back to what uh might be a bit more simple as we're approaching this pcap and if you notice David check out the website that we're hitting. Some dodgy website there. Yeah sketchy now there's a reason I wanted to do this David and that was uh to show well I'm in the United States and your uh website is hosted well the actual site is in in Europe so let's just see what we hit did I cross the pond Uh what can we learn and uh how can we use TCP to do that. We did promise you though 3 core things you need to learn about TCP if you're going to be doing TCP analysis you've got to master these 3 things. Okay the first one is the handshake. Now we've talked at length about this on previous videos about the handshake We've
gone in and we've ripped it apart Uh I'm not going to do that level of detail now but there's a huge reason why you got to know a handshake and you got to be able to read it quickly. So you're going to watch in real time how I dissect a handshake. Then I'm going to back up and uh talk to you about why I look at some of those things. So first just with my eyes in order to establish a TCP connection I
first got to have an address that I go hit to get that DNS, DNS up above. So first thing my machine did is I did two DNS queries. One was for an A record the other is for an HTTPS record Let's just focus here on the A one because that's going to give me my address that you see down below So I hit DNS server Hey give me a davidbombal.com, what's the IP for that DNS server comes back
DNS server says it's 217.160.0.69 There you go I actually want to show you something really cool David you want to see something that's super fun. Chris that's a rhetorical question right. Oh I'd hope so. And I I hope all of your audience was like "Yes let's see something cool." So I can set a filter for a value that is within a packet even if that filter looks for packets other than the one I'm clicked on Okay that was a mouthful Let me back up and show you what I mean Packet 3 And if I come down into packet 3 what I'm looking for here in DNS I'm going to come down here to answers And I want that IP address. Bam. That's the address that the DNS server responded. Yep.
Now in the future we're going to do more deep dive on DNS but for now all I got to look for down here is see DNS.A down there down at the bottom I know it's kind of like small and stuff but what I want to do is I want to pull that address out of this DNS record and apply it as a TCP conversation or or rather look at all conversations coming to to and from that IP that DNS responded. So this is what I'm going to do. I'm going to say "Show me IP.adder adder Okay I want everything to and from the address I'm going to do a dollar sign curly brace DNS a close curly brace What that filter does is it's going to rip this value DNS.A out of the packet that I am clicked on and apply it as the value It's basically going to fill in this value with that IP address Okay so let's see it happen Bam So now the DNS is gone because I'm not interested in DNS traffic right I just wanted the value that the DNS packet had So I ripped that field out and I added it to a filter that was filtered on a different conversation Does that make sense Yeah No it does Cool Now just in case you don't have this I'm actually going to share this profile so you will when I do I'm going to say plus I'm going to add this cuz I this is a filter I want to have around So I'm just going to say um how about extract IP DNS maybe underscore DNS DNS There we go I'm just going to leave that for right now everybody And I'm just going to say okay And it's going to be up here on the top right So now in the future whenever you're looking at DNS you come to one that has an IP address in it. You just come up here and you click that and boom you're going to have a filter for that that
conversation. All right back to TCP Handshake is the first one you should look at. So the very first thing my eyeballs do I'm looking at a SYN Now a SYN packet is initiated most often by a client A client connects to a server. So in this case 4.22 that's a client side server side this is David's uh IP external facing and I send that SYN out. Now in other videos we've talked at length about what kind of stuff gets exchanged options all the things. We're not going to for the
sake of time we're not going to do that this time but my eyes are just going to scan down just to see. Okay there's my window size. Got some options going. Now there's 3 options I really want to watch for every single time. One is MSS, one is window scale, one is sack permitted. Those are I call them the big three. Those really establish uh modern options into the TCP conversation TCP not all TCP is the same. Not all two, not all TCP stacks are equal. So when they first establish a connection they first establish parameters between the two and then they decide what kinds of things they're going to use. So I'm advertising to you David 1460 MSS window scale of six which gives
me a multiplier that basically allows this window size to be much larger. That window size is a receive TCP buffer. So I'm saying hey David if you send me a bunch of data I'm going to be able to catch it cuz I'm going to give you a bunch of space to work with. Then sack permitted selective acknowledgement just in case we see any missing uh gaps or spaces in the data flow uh we can use selective acknowledgement to allow data to keep on being sent while we are recovering from previous packets that went missing. So Chris I just want to clarify right. The reason we need
this SYN is we need to agree a bunch of stuff I could have a very old client. You could have a very modern server and that's why we need this negotiation because you need to find out what I support I need to know what you can what you support is Is that does that kind of make sense? Yes. But let's also use a a different word than negotiate. Let's let's drift away from that for a minute. Let's use advertise.Okay. Right. So client hey I want to talk to you server and this is what
I'd like to use. Server comes back saying okay cool this is what I'd like to use right and we both have to support sack we both have to support window scale I mean check out David look at your window scale it's double the size or it's the multiplier y is a it's a double uh factor this is a scale factor which goes into this multiplier which then allows you to have a big like just the receive buffer is going to be huge so I know we went to some detail but all of these concepts are things you can uh learn much more about on my channel I deep dive and dissect every single one of these fields. When to use it, why to use it, how to understand it. But but these parameters within a handshake are things that you want to learn the reason. So you like me when I'm scanning through
now I go boom and I just look through. Okay. Boom. All right I I just analyze the handshake Your your brain starts to do it because you understand where to look and what what matters Right now a big thing that I'm going to focus on in the handshake is my delta time between the SYN and SYN ACK. Now SYN So I send out my SYN which means synchronize. We'll get to what it synchronizes in just a minute Send that out to the server Server turns around 130 milliseconds later I get a SYN ACK. Now as a client I'm starting a stopwatch and stopping a stopwatch. This now gives me my network round trip time. Okay. And in the handshake Wireshark actually if I come down to sequence and acknowledgement analysis
that IRTT that you see at the very bottom that value is basically the three packets of handshakes in SYN, SYN ACK and it's these delta times added together. So that then gives me my initial roundtrip time of my network. So right now David I just put that on a pegboard of truth I mentally tuck that away I got 130 milliseconds between me and your server. What do you think? It's a long time. Yeah that's a little bit of of network that we have between us. Now is that bad. Well if your server was on the
same floor as me if we were on the same building then yeah we got some problems right. But we have a whole ocean between us. So I start to factor that in. Another thing that I do with the SYN ACK is I also look at the ingress IPTTL and the reason there is I can see this value is 54 I'm just going to show you where that comes from in the IP header Come down to TTL 54 What this means is uh this is as I am receiving it So when this value started this TTL it's likely that this began at 64 on year end. The reason why there's three common values that TTLs begin at 64 128 and 255 That's
what these numbers typically start with. You see that on my direction. I started at 64. Your machine likely started at 64 as well. And it as it was decremented across the internet as it came toward me then I caught it at 54. That means it was decremented 10 times. That means 10 routers or
Layer 3 switches decremented that value on its way to me. So now that gives me a bit of a context as far as how many routers I passed through. Does that make sense? Yeah. Every every hop make lessens it by one. Right? That's exactly it. If we ever hit zero packet gets dropped. Yeah. Right. And the reason why I know that this isn't 255 is cuz man we we would have gone through 200 routers. Yeah The way I
know it's probably not 128 decrementing down to 54. Well that's a whole lot of routers too. So 10 makes sense. So I'll just mentally note that. So I got 130 milliseconds or network round trip time. Likely my server is the endpoint that I'm communicating with anyway is 10 hops away. And then I finally wrap that up. So those pieces of the handshake are very critical you're doing TCP you should
be able to do what I just did in minutes. SYN, SYN ACK, the IRTT. Look at your network round trip time. Look at your ingress IPTTL and your SYN ACK and look at your your TCP options. Make sure that you have MSS. Make sure you have a window scale. Make sure you have selective acknowledgement for most
cases. Generally speaking those are the three that you want to see. No it's great I mean it's it's a lot of information Chris you said you're going to throw show us three things. This is only the SYN part right? Yeah. This is just in the handshake. This is the SYN SYN ACK ACK that you see. So explain what SYN is and explain what SYN ACK is and explain what an ACK is? All right. Very good. Thank you for that question. And that actually gets us you just led us into the second thing you need to learn about TCP sequence numbers. Okay. Great. Part of the reason why this is called SYN is because we are
synchronizing sequence numbers. Okay. So if we go back into the SYN and I don't mean to be moving too quickly everybody but I just want to keep it to the three things you got to study more. So in the SYN just click on that first packet and you're going to come down to sequence number raw. So this is a value that the client calculates comes up with. Don't worry too much about how just it's a high numbered hard to guess number that it selects. Okay. Okay. And and there's a whole calculation goes
into that. Let's leave that to the side. But for right now big weird unique number I send that to you David and I say "Hey David I'm going to start counting at this number. What this number is does not matter. You just need to know where I'm starting to count from. Yeah. Okay. This is the whole reason why it's called SYN I am sending this value to you. You in turn add one to it. You use basically the when you when I send you a SYN when you have a SYN flag in a packet the whole system acts like one byte was sent It's called a ghost byte or a phantom byte pick one It's just a a false one.
And what you do is you add one to this value and you echo that number back to me. So what I'm going to do is uh what I'm going to look for here is I've got 7859 I want to see 7860 I just added one to this value. I want to see that in your SYN ACK field 7860. Nice. You just plus one it and sent it back. And I said cool David heard me. David heard my SYN. He added one and he echoed it back in the ACK number. And that means I know what your starting number is. And you know that
I know that correct. You at the same time sent me a totally different sequence number. These two numbers right here are different. They don't intersect. They don't add, multiply, subtract, divide. There's absolutely no mathematics between them. You just told me "Hey Chris I'm starting here." So what I do is I say "David cool. So 3112 I'm going to send 3113 back to you." Yeah in the
in the form of my ACK numbers. Let's see if that happens 3113. I advanced 1 to 7860. So now I have moved forward 1 in my sequence number direction You have now moved forward 1 in your sequence number direction. We just synchronized sequence numbers. So there's two things we just learned. One we learned more about the first thing we need to master and that's the handshake. The whole point the reason why it's called a SYN is because it we're synchronizing sequence numbers. The second thing that we're starting to learn is sequence numbers themselves. Sequence numbers basically in the RSC for TCP it says every single byte has an associated sequence number. What this allows
me to do is when I send you traffic David every byte that I send increments that sequence number. That way through feedback from you I can see what went missing and what was successfully received. Question. One number in the sequence number is that one byte of data? That's correct. Okay. Just to to make it obvious if if I increase the sequence number by 5 that means 5 bytes of data being sent. That's correct. Okay. Now you should see 5 bytes of data being sent. Yeah. Right In fact while we're at it I like that question. Let's go to packet 8 here. The client is sending 1448. Right. So
we're starting at 7860. We're going to add 1448 and that will be the number that gets ACK back to us. So it's TCP length, Segment length is the number of bytes that are being sent. That's the payload. That's why I like TCP length up here because I can see which packets have payload and which ones do not. Now uh as you can imagine some of this math gets a little crazy. Yep. Yep. Because here's a payload and here's a sequence number raw and all that stuff. That's why Wireshark does us a favor It does us a solid we say it zeros out these sequence and acknowledgement numbers and it does that with an relative sequence number. So I'm going to go back up to pack my my SYN. You can see my sequence
number my raw value. Yeah. right above that is sequence number zero. So what Wireshark is saying is in context to this conversation relatively. Let's just start this sequence number over at zero because you humans can't count worth beans. Yeah terrible counters. I'm a computer I can count. That's not hard for me I don't care if I start counting from some crazy high value I can do that easier than you. So the masters of Wireshark did us a big favor just by saying you know let's just zero this number out and act as if it was zero. That way when you count you're counting up the number of bytes relative to this conversation. Does that make sense? Yeah. So much easier to read. Oh
much much much easier. Now that said they do keep the raw value there just so we know what it is just so in case that's valuable to us. Okay but if we come down here to packet 8. So here my sequence number has advanced by one in this direction. The ACK number also advanced by 1. All of that happened in the handshake. So here I'm on sequence 1 I'm sending 1448 in this direction 1 + 1448 = 1449 My next starting sequence number in this direction will be 1449. I'm going to move forward to 1449 in
conjunction with the number of bytes that I sent. And it's important to highlight right the even though it says they both start at zero right But the numbers are actually got nothing to do with each other because the real numbers are these crazy numbers. Good call David. That's exactly right. That's exactly right. It's the two true raw values are the ones that truly move data. But just
for our analysis that's what these relative numbers are just to make it simpler. Correct. Now if you notice here packet 9 I've got another loaded packet. This is a T TLS client hello which by the way we'll talk about you doing TLS1.2 in just a second Um there's 345 bytes in this packet
So let's come down here and see what the math is. So my sequence number is 1449. So we see why we're there right. Why are we at 1449. We started at one and you added what's 1448 .Yeah in the packet above. That's correct. So now I move forward to that point. I'm starting sequence number 1449. This time I'm adding 345 to it. That's my payload. The next starting sequence number that I should expect in this direction is 1794. Wireshark's doing the math for us. Sequence plus length equals next starting sequence number. Nice. At the same time David if both of these packets get to you this is the value
1794 that I should see you reply as an ACK number. Yeah it's the next sequence number that you expect Okay so let's see if that happened. Packet 10. Sure enough ACK number 1794 David got both those packets. So now I no longer have to figuratively keep back a copy of that 1794 bytes right I can now move forward like okay David got it Hey boys you can dump that out of the send bin. We don't
need to keep that data anymore. We can just move on right. We can move forward in our our stream. So I don't have to retransmit I I'm happy And I come over here with my eyes 131 milliseconds is how long that took. That loosely or very very close I shouldn't say loosely. This very closely uh represents our network round trip time. Yeah So I'm I'm not surprised there. All right. How we doing so far? That's great. So can you just go through it again Chris just to reiterate. So we
start at zero but you sent one byte right And then the next time you sent 1448 and then the third time you said you sent 345 and that's how we got to that total amount added together then the server acknowledged that plus one because it's next piece of data that it's that it's expecting Is that correct? Good review. Exactly. And so and you just went through basically the the things that we want to know about TCP. So in our handshake we synchronize sequence numbers. Okay I send you a high number value you send me a high number value. Yep I + one and U plus one. To start us off. Yeah Yep. That's that's why it's called SYN. Then our our relative both of our relatives go up by one because we just plus one it in each direction. So now my starting sequence number is one. Remember Wireshark's zeroing that out for me. Now now I have my connection established. Now I can start
moving forward with my sequence number Packet 8 is the first one with real data in it. Sequence number plus length equals next sequence number. Nice. Next sequence number plus length equals next sequence number. Now these two packets went out back to back I I had such a I had so much to say to you in this
client hello that I had to bust that apart into two packets. Yeah. So that's why there was two going out. Now those two float along and they go across the Atlantic Ocean and then they land and then boom they get processed by your uh TCP stack. Your TCP stack goes "Oh cool. Great. So this is a packet
with 44 uh 1448 and then 345. Let's add all that up and send Chris back a 1794 as an ACK number. If you didn't I'm setting a stopwatch in each of those packets. As I send this out once I send it I start a stopwatch. And if I don't hear an ACK number that acknowledges this data within that period of time
when that stopwatch expires I'll retransmit again. That's another conversation we can have like the mechanics of that with TCP and how that's also important to understand. But for now I just want you to know this has to get acknowledged otherwise I'll retransmit. All right. So then
you pick up and uh just to kind of wrap up this part of the conversation then you start to send and if we take a look at your sequence number uh if you look at packet 11 so your sequence number is one. You haven't sent me anything yet right. The handshake doesn't count. It's just a ghost byte or phantom byte and you've ACK but you haven't sent anything else. This is your first actual piece of data. Yeah. Now something else that my eyes do everybody with TCP packet 11 is this 27 milliseconds. That is basically application response time. This is David's server saying great I got your stuff. This is how long it took for him to actually begin to respond. Trash server. Not really It happens I mean 27 milliseconds I I'm not super worried about that I. No one picks up the
phone and calls me for 27 milliseconds. Now if it happened a 100 times then yeah that's what you called me for. But so far not super worried about that. You start at one send me a loaded packet you move forward in your sequence number you send me a loaded packet you move forward in your sequence number you send me a loaded packet then you pause. That was your server. Hello. Those three packets that came over from you your next expected sequence number in this direction is 4097 I take that value I take all that stuff and I send you back 4097 I'm telling you David I got you In fact Wireshark gives us a visual. You see this little check mark over here by packet 13. Yeah. When I've clicked on 14 Wireshark says you're good all the way through packet 13. Thumbs up. That's nice. What we just walked through are the three things that you need to know about TCP. And these are important
concepts to really master. The handshake we talked about that. We talked about the sequence numbers. And we actually already talked about the third thing and that's acknowledgement numbers. If you can master those three things David you are going to be fine in your TCP analysis. Of course there's more to learn. But everything else builds on that foundation. So I wonder this this I've seen this
multiple times. Let's say you send me a thousand right. So your sequence number is a thousand. Do I ACK a 1000 or do I ACK a 1001. You send me back an act for the next sequence number that you expect to receive. So you're actually one more than the actual data that I sent you. So if I send you if I'm starting off in sequence number one and I send you a1000 you're going to ACK back 1001. Yeah. You're you're literally adding sequence number plus payload and that's the next sequence number that you expect me to start at. That's great. So hopefully that answers your question. I love that the way you answered that right at the end makes a lot of sense So it's the next number that I expect you to start at. Yeah. Great. Correct. This is the next one like I'm good all the way up
to here. This is the next place I expect you to start. Yeah that's great. And you know based like you said it earlier that I've received all the previous data. So I've you you can dump that and start at the next piece of data. Correct. Once your acknowledgement number goes forward it shouldn't ever go back down. Okay. Right. Once you advance once I say "Hey David 1 2 3 4 5 6 7 8 9 10."
What What's the biggest number you heard me say. 10. Okay I I don't ever have to repeat one through 10 again Yeah Like you got everything before that. We're good Okay 11 12 13 14. Like I don't have to You're never going to back down and say three. Yeah. And if you did either that's an ACK that came in out of sequence or I got to do some deeper analysis and figure out like why why are things getting switched around here. So that's brilliant Chris on your channel right you go through this
stuff in a lot more detail as you said. So do you have a playlist or something where people can start on your channel. Yeah I have a how TCP works playlist and we can link that as well. And when you uh check that out what I try to do David is just bite-size videos just somewhere between 5 to 10 minutes. And I literally go through each one of these little things that you've seen And um over time I'm just refreshing that just adding more content to it giving you more pcaps to look through Uh because I I really think that each one of these things is important. However I understand the overwhelming feeling that it can bring. Especially when you're first looking at this
it's like what matters I think that can be a barrier of entry into Wireshark Uh it can make us feel like man why get it started I don't understand all this stuff and Chris is just ripping through it too fast. So that's my goal on my channel is to give you examples scenarios pcaps around these different values and show you what really matters and what helps me do my analysis. So yeah so I definitely invite people to check that out um over on my channel how TCP works that playlist. So for everyone who's watching please go and sub show the love Chris is the person I always talk to when I really want to know how Wireshark works and protocols like TCP and UDP. Chris thanks so much for sharing. Thanks for having me David and hopefully I'll see you again.
2025-04-25 04:21
