How TCP Works - The Handshake

In this series of videos, we will examine how the Transport Control Protocol works using Wireshark.
Taking ownership of TCP can help engineers get to the root cause of performance problems faster.
Like/Share/Subscribe for more Wireshark content!
== Links n' Things ==
▶Getting Started with Wireshark - bit.ly/udemywireshark
▶Getting Started with Nmap - bit.ly/udemynmap
== Live Wireshark Training ==
▶TCP/IP Deep Dive Analysis with Wireshark - bit.ly/virtualwireshark
== Private Wireshark Training ==
Let's get in touch - packetpioneer.com/product/pri...

[@tbs1199]

Great video Chris. Please make more of these. Many people need the fundamentals to understand the root causes of application latency.

[@ChrisGreer]

I'll do my best to keep them coming. Thanks for the comment!

[@MultiRam73]

@@ChrisGreer great thanks. Can't thank you enough.

[@tj8870]

This is real TCP understanding. Much respect to this man for actually breaking down all the information with a real world example so we can understand the thinking process.

[@ChrisGreer]

Thanks for the comment TJ!

[@MultiRam73]

Chris, for over 5 years i had not been able to understand this. You walked us through, literally in a hand holding way. Great language and simple things detailed, removing jargon. Admire and thank you so much

[@ChrisGreer]

Thanks for the comment Ram!

[@johnvardy9559]

im still dont understand,do yoi recommend anythig?

[@illyam689]

@@johnvardy9559 go back and watch the video again, this is the best source you can find

[@illyam689]

I agree, Chris has IMPRESSIVE teaching skills. We need more teachers like him

[@ranjanadissanayaka5390]

I'm learning TCP /UDP for my CCNA . And I've watched this video at least 3 times. Each time I understand a bit more than the last time. A great video and a great help in understanding the concept. Thank you.

[@krishnareddy9037]

Thanks for the videos Chris, I started watching your videos from couple of days. These are really helpful.

[@ronlee4983]

Im new to network security ,Really love your videos, giving good explanation and examples on TCP communication Thank you

[@subhamthemusicalguy8851]

Thank you so much for making this Tcp series

[@vizanques]

thanks Chris, your english is so easily understandable, this is for sure a differential. greetings from brazil!

[@universalponcho]

This dudes explanations are absolutely amazing!

[@asankakodikara2544]

Oh wow. Thank you for the amazing explanation!

[@megapode2648]

Thank you, what a great inside, this helps me better at my job

[@sauravsahu6243]

great video Chris, thanks a lot for sharing knowledge !

[@MrHawk407]

This is the best video i came through. Good Job Chris, expecting more videos. Thank you buddy.

[@ChrisGreer]

Thank you Sivasakthi! More soon.

[@samirshaikh52]

Excellent Video Chris. I've started watching your videos and they are really helpful in real world cases. Great Job!

[@ChrisGreer]

Thanks Samir! I appreciate the feedback. I will keep on making these short videos.

[@yukeyang5735]

Great video. Clarifying details of TCP.

[@lubarsil]

Great. Could you sort this playlist by date, please? Thanks!

[@mrbigglesworth_Official]

Great video best tutor and explanation I have found. Very clear and informative straight to the point. Nicely broken down

[@ChrisGreer]

Thanks for the comment!

[@tdbarke]

Excellent Videos , explained complex topics in very simple manner and easy to understand.

[@omegamooon]

Excellent explanation Chris. Thanks a lot

[@rahulraghavendrahs6989]

Awesome!! Please do many more videos like these

[@user-lx3tb6gv8o]

The first tag is 0x02, which is specified in RFC 793 as the maximum segment size option. It's followed by 0x04 bytes of data which are themselves the maximum TCP segment of 0x05b4, or 1460 bytes.

[@waleedrajab2720]

thanks ,, its was so helpful

[@ric636]

only ppl that master the topic with theoretical knowledge and consistent practical experience have Your level of clarity! Your passion is really inspirational Chris! 👋💯

[@ChrisGreer]

Wow, thank you!

[@polliluiz]

Awesome my friend. Keep up this excellent job.

[@MrBitviper]

thanks for the informative video chris.. much appreciated

[@balajimudaliar5715]

Thanks a lot for the explanation.

[@migueldellicarpini4437]

Great video! Thanks for sharing

[@temisegun8631]

nice and clear explanation, thank you so much for this chris

[@ChrisGreer]

You are welcome - thanks for stopping by!

[@suhailmunshi2876]

I was troubled to understand it literally for 3 days. Finally, i got it because of you, you made my life easier i hope God will make yours. Thankyou Chris.

[@ChrisGreer]

Thanks for the comment!

[@haji-koto9765]

Thank you bro I needed this a lot and this video was perfect

[@jhc4090]

Thank you so much for making these videos!

[@mryes8184]

Keep creating vids man! Will watch them all, ain't lying

[@ChrisGreer]

You bet! I will keep them coming. Have more coming out very soon.

[@5190csyt]

Thanks for your video, that's really helpful for me!

[@ChrisGreer]

You are welcome! Very happy that it helped you.

[@zeeshanahmad3989]

sir i love the way you explain . and i hope you'll still continue upadating this playlist. really looking forward to watching more of your videos on this topic

[@ChrisGreer]

Hi Zeeshan - gonna keep at it! Also I have my bit.ly/wiresharktcp course on Pluralsight which goes through all of this with hands-on examples. Check it out!

[@vjd5865]

Great stuff!

[@upelister]

Thanks for great explanation.

[@amirahmed1404]

You are the MAN Chris. Thanks a lot for this great explanation 👍

[@ChrisGreer]

Thanks for the comment Amir!

[@NickSmith-hv9zi]

Would be helpful to include in the video the data transfer completion. Meaning how does Wireshark interprets a completion of a transmission.

[@anshukhanna6041]

Thanks chris...I am a big fan of yours.Please post more basic videos and case studies.Great help!

[@ChrisGreer]

Thanks Anshu! i'll keep them coming. thank you for the comment.

[@Ipadstands]

thanks the video was excellent !

[@prateekchaturvedi1995]

All your videos are awesome as it gives In depth analysis about the packet level information which is very important in today's industry..I hope you start uploading the videos again on this channel..

[@ChrisGreer]

Thanks for the comment Prateek. I'm in my studio shooting some new stuff now! So stay tuned and subscribed.

[@trendyniro]

Thank you for educating us chris!

[@ChrisGreer]

Glad to hear the videos help!

[@amiramiri4517]

clearly explained. god bless you, thanks!

[@ChrisGreer]

Thanks for the comment!

[@anthonykahwati5999]

Thank you!

[@aleemsyed3595]

Very good detailed explanation.. Really appreciate it.

[@ChrisGreer]

Thanks for the comment Aleem!

[@emr0088]

Hi, just wondering if there are any application or data in a servers from a previously established tcp connection that can affect or influence the client to initiate a new three way handshake towards another destination ip of the server rather than the originally established one? Can natting affect this?

[@frankmadrid1846]

THANK YOU 🙏🏽

[@Vpy2023]

thanks for all the great videos. Can you show instances where a single tcp session is used for multiple http requests ? How do we identify the underlying tcp session in all these http request?

[@shynggyskassen942]

Thank you so much !!!

[@AmeenHamed]

Thank you man for sharing this stuff

[@ChrisGreer]

Thank you for the comment!

[@tusharnaik4710]

Nice video chris

[@armankassis319]

Great video....Thanks

[@Zager-recap]

Amazing Thanks

[@sareng2005]

Thank you this video show a great example of wireshark. I am glad how you explain everything in detail. I like and subscribe!! Take care==S

[@TamazghaLandOfGod]

Thank you Chris 🙏

[@ChrisGreer]

My pleasure!

[@mohamedmusaid]

Awesome video :)

[@flomax_actual]

Great Video Chris. I look forward to diving deeper into your material. - Kyle Sullivan

[@ChrisGreer]

Awesome, thank you!

[@JitenPalaparthi]

Wonderful video in 2022 as well. Basics prevail

[@m.adnankhan8245]

Thank you so much for these wonderful videos :)

[@ChrisGreer]

Glad you like them!

[@creakffm]

4:32 so set TcpMaxConnectRetransmissions in Registry for windows 10 client to "1" ? or is 2 better

[@PeterTeehan]

Chris thank you for this video. I troubleshoot a lot of Teams issues. We use Wireshark PCAP a lot to understand what is going on with connections. For instance, audio or Teams performance issues. We can pinpoint down to which firewall is causing all the drama. Whether they are on an updated version of TLS or even a certificate has expired and so on. Some of the other information you showcased in this video I never understood. Which is why I am saying thank you and have earned a sub!

[@ChrisGreer]

Awesome Peter! Thank you for the feedback!

[@PeterTeehan]

@@ChrisGreer The fact I see you using Zoom is heartbreaking haha

[@ChrisGreer]

@@PeterTeehan Haha... It's a thing. I would love to use Teams for stuff but I run into so many problems with it that I spend more time fixing issues rather than teaching classes. No good when you have an audience to teach!

[@PeterTeehan]

@@ChrisGreer I work for a vendor but I am MSFT Support Engineer for Teams. If you ever want to do a deep dive let me know.

[@theycallmeken]

Wonderful and to the point....now onto offsets ;-)

[@ChrisGreer]

Thanks! Yes - more to come.

[@overacupofcoffee8451]

Thank you for the awesome explanation. I have a query on NOP? What is the use of it? I have seen this in almost all TCP captures

[@ChrisGreer]

Hey, great question. I have a video about it - kzbin.info/www/bejne/pancoWeamq2Njq8 check it out!

[@pranav7114]

Really great video 👍👍

[@ChrisGreer]

Thank you 👍

[@Lovingstoryteller]

Hi Cris, Could I know why in the ACK calculated window size with multiply by 4 (which is client window scaling factor) even though server SYN/ACK said scaling factor is 1 ? Shouldn't client accept the window size advertised by Server? ( I am unsure it shows client can accept (the bucket size ) four times like server window size? thank you

[@ChrisGreer]

Hi Chama - for the scale factor in the handshake, this is not a negotiated value. It is simply an advertisement of what the sender is capable of.

[@janiyatin]

Great Video Chris!! Helps me a lot in understanding the concepts. Is there any way that you can do some videos about the flavors of TCP, like Tahoe and Reno? Thanks :)

[@ChrisGreer]

Hey - did you check out my Congestion Control Explained video yet? kzbin.info/www/bejne/gn_Ii42QlNSmoqs I go into how it works and show a few of the flavors. Since Reno and Tahoe are so old I probably won't be doing a specific video about them at this point.

[@juanjoseaguero6539]

Great!!

[@nikhilbejjarapu7610]

Hi Chris. I couldn't find the Pcap file that you've been using in your system. can you help me with that?

[@shashankvs6345]

excellent sir

[@ChrisGreer]

Keep watching! Thank you.

[@michaelruiz9499]

Thanks man

[@ChrisGreer]

You're welcome!

[@benjaminsafari7449]

I want to see if I get what a sequence number is. First handshake will tell the receiving machine what sequence the number will come in; if the sequence starts with 7 then the next packet will have sequence number 8, them 9, then 10, and so on, right?

[@ChrisGreer]

Hello, thanks for the comment! You can check out my TCP sequence number video which goes into that. kzbin.info/www/bejne/eIisfZp6qZudsJI

[@akintolamichael6107]

Great Content

[@ChrisGreer]

Thank you!

[@AungKoKo]

Thanks!

[@ChrisGreer]

Thank you!

[@train4905]

Awsome😊

[@Cricklox_552]

Hi. I can't find the pcap file that you have been using in your system.

[@pgonza77]

Where can I find this on my personal Pc?

[@karananand20]

In the first Syn packet, the window size was 8192 and scaling factor was 4 and in the syn, ack packet from receiver, it advertises the windows as 4380, now when the sender again sends the ack , why window changes from 8192*4 to 4380*4? can you explain?

[@Dennis19901]

My best bet is that it tries to match the receiver. Not sure if this is some TCP quirk or that this is determined by some TCP field. I don't particularly see the use of this as the window size advertises the remaining read buffer size. There shouldn't be a problem if one end has a larger buffer then the other.

[@nadimpathan7912]

does client will receive 8192 bytes ones considering mss is 1460 bytes only? anyone can help me to understand? mss is 1460 only then how client would receive 8192 bytes at ones?

[@aham3687]

Chris I love your videos. Can you make video on https packet analysis?

[@ChrisGreer]

Hello Abraham - That is coming soon. Stay tuned!

[@creakffm]

5:50 so i higher TCP receivw window size ( buffer ) is better in Online Gaming like Fortnite? i recomented no Scaling Size so round 6xxxx Window Size Smaller

[@rajkaransinghgill2082]

Chris can you please do a video on the analysis of IPV6 packet?

[@ChrisGreer]

Great idea for a future video, thanks!

[@andreffrosa]

During my network course at the university, we learned that the acknowledged sequence number was not the last sequence number received contiguously but rather the next sequence number that is being expected by the receiver next. Therefore, having an ACK of 1 in the SYN/ACK makes more sense than the ghost byte explanation since the receiver is telling "I'm expecting the first byte next". And it behaves like this throughout the whole connection. One of our assignments was even to build our own TCP clone on top of UDP and the ACKs worked like this too: Always sending in the ACK the SEQ that is being expected next rather than the one that was contigously received last. What are your thoughs on this?

[@ChrisGreer]

Thanks for the comment Andre. I guess that is one way to explain it. But the reason I don't like that explanation is that it doesn't take SACK into consideration. If I send you 5 packets of 100 bytes each and packet 2 is lost, your ack number will be 100. But you will also carry a SACK block for sequence numbers 200-500. So yes, the ACK number is indicating where the gap begins, but that's when we have to peek at the SACK block to see how much was lost. Also - the Ghost Byte is a huge part of synchronization, so it is important to understand why that happens in the handshake. Thanks!

[@sreejithjinachandran7322]

Can you make a tutorial for wireshark !

[@manjunathag4173]

I have a question, Let say i established a connection with FTP server and i need to download 2 GB data, So in this case how my PC or server based on what criteria it decide how much data to transfer in Transport and network layer?

[@ChrisGreer]

It really just depends on the TCP stack in use by the operating system. So what kind of OS is the FTP server installed on? What version? These things all play into how TCP will handle the transfer.

[@osmanmohamud2307]

Hi Chris, it was a bit hard for me to follow along. May be I'm biting more than I can chew as I am just starting to learn this stuff. Which of your videos would you recommend to watch first? No IT or networking background, just starting out from scratch

[@ChrisGreer]

Hello Osman - Protocol analysis is a deep topic so it's all good! Just keep going with it. I would suggest watching my Wireshark Masterclass series. Here is a link to lesson number 1. kzbin.info/www/bejne/hYaQcmV7orulgbM

[@osmanmohamud2307]

@@ChrisGreer thanks Chris

[@woodiewoodie6916]

when i try to follow a stream through wireshark it shows me a encrypted text not the names

[@pratiksharma5471]

Seems like you were interacting with the server over HTTPS. Which would encrypt all of the TCP conversations.

[@rajkaransinghgill2082]

At 6:05 , if our buffer size itself is 65535 then how is it possible to increase the size using options? where will we store the extra data that exceeds our buffer size ?

[@ChrisGreer]

If we are using the window scale option, then the advertised window size is just a variable at that point. The number itself is not to true buffer size - it is just an integer that is going to be multiplied by the window scale to arrive at the true window size.

[@lonnguyenvan6562]

What happens if some bits are wrong due to connection errors? How to detect them and fix them?

[@gshaurav]

Hi, Liked your way of presentation and videos. I just wanted to add that, there is no such thing as tcp mss negotiation as you mentioned that whichever side will have lower mss, that mss will be used by client and server both. Mss is independent in both direction. Let me know if my understanding is wrong.

[@ChrisGreer]

Thanks for the comment Gaurav - You are 100% correct - I've mentioned this in other comments below as well. I was in error on using the word negotiation. the MSS is not negotiated. That said - I have seen many stacks where both sides respect and utilize the lower of the two values, but even then, it is not a negotiation. Thanks again for the comment!

[@ManozKarmacharya]

How different is it with IPv6?

[@ashenchanaka5537]

Great Work Chris, Regarding the MSS, It doesn't have to be the same on both end points I guess. It can be different values on each direction Reference : en.wikipedia.org/wiki/Maximum_segment_size

[@ChrisGreer]

You are correct Ashen - the MSS does not have to be the same in both directions. however, I find that many TCP implementations will use the lower value, even though the standard says that it can be independent.

[@danimoosakhan]

So basically ack number is one number higher than the previous packet seq number?

[@Dennis19901]

Ack says "This is how many bytes I have received from you". If the Ack is 100 and the receiver receives another 100 bytes, they will Ack 200 the next time. An empty packet counts as 1 (for example connection handshake packets or just empty confirmation packets). Do note that the Ack is every increasing. You can see it as "this is the amount of total bytes I have received from you", usually stating at a random number.

[@enriquerodriguez9723]

@@Dennis19901 this is almost correct. The acknowledgement number says "I have received ACK-1 bytes so far, I am now expecting byte number ACK.". So if the sender received and ACK number 101, it tells the server the receiver has received 100 bytes and is now expecting byte 101 to be sent.

[@krishnareddy9037]

Is there a separate video for Flags?

[@ChrisGreer]

No not yet. But it is covered in this video starting at 4:17.

[@stelluspereira]

Sorry for my ignorance, question: why we should not capture traffic at server?

[@ChrisGreer]

Hello Stellus - We can capture traffic at the server end, but it is a best practice to start on the client end, just because the traffic volume is so much less. Also - we don't want to install Wireshark physically on the server, best is on a tap or span as close as possible.

[@stelluspereira]

Thankyou Sir, Typically for debugging performance issues, I capture through command line only specific IP address packet on the server & simultaneously capture from client to match and debug

[@ChrisGreer]

@@stelluspereira I think that is a great approach. I often do the same myself. It's just a tough thing for beginners - so I usually have them start at the client.

[@stelluspereira]

@@ChrisGreer Thankyou Once again Sir, Do you know any options in wireshark or other tools to identify 'dirty'/'bad performing' devices (I meant creating errors devices ) suppose you have a network TAPs ( ingress/egress traffic from various segments Taps) to combine(2 more more) & pin point 'problem' devices (doing lots of re-transmission) & not responding within a 'resonable' time etc

[@ChrisGreer]

@@stelluspereira I think the one that I would recommend that I use is the IOTA by Profitap. you can check them out here - www.profitap.com

[@vkhanna25041986]

@Chris Greer : MSS technically is not negotiated right? That is my understanding.... In your videos you mention, MSS is negoitated to a common value, which i think is wrong. any thoughts? Each device sends the other the MSS that it wants to use for the connection, if it wishes to use a non-default value. When receiving the SYN, the server records the MSS value that the client sent, and will never send a segment larger than that value to the client. The client does the same for the server. The client and server MSS values are independent, so a connection can be established where the client can receive larger segments than the server or vice-versa.

[@ChrisGreer]

Hello Kannan, and thanks for the comment. You are correct - I accidentally said the word "negotiated" when I shot this video. I I have been meaning to edit that word out. Although I have seen TCP stacks which will use the lower of the two values for both sending and receiving, the word negotiated is not the correct word. In my MSS and MTU video I made sure to say it right. :-)

[@vkhanna25041986]

@@ChrisGreer Thanks Chris for your prompt response. I think they set the lower value to adjust the MSS in accordance with the interface MTU. Again thanks for your videos and prompt response, CheerS!

[@LimitedWard]

There's a lot we can learn from TCP. We should all acknowledge the syns of our past.

[@ChrisGreer]

Yessir!

[@karma-cf8fd]

i searched for *wireshark how to be the one creepy dude in the coffee shop* think i got the right video

[@hector2099]

Mr. Greer, How may I email you for specific questions? Do you have an email address?

[@ChrisGreer]

Sure! Pop me a message - packetpioneer.com/contact/

[@r.a.chadwick4689]

You said about the actual SEQ number "that's a long complex number".. you should not use the word COMPLEX in this context, it i just a long integer (in hex of course in the data representation). Not a complex number... re square root of neg 1 etc...

[@bradbland9307]

you talked about particular packets but did not at all explain the 3 way handshake...why is it syn then syn ack then ack?....is it always like that ?...are all 3 considered the handshake? we learned nothing about the tcp handshake.

[@ChrisGreer]

Hello Brad. SYN stands for synchronize. The two sides need to sync (or exchange) sequence numbers and communicate options that will be in use for the life of the connection. This is why both sides send a SYN (along with the initial sequence number and options) to the link partner. The ACK component will increment the received sequence number by one, which is an indication that the receiver successfully received the initial sequence number from the sender. This then moves the two endpoints into a connected state, which allows it to start sending data. Hope this helps better understand the three-way process.