How TCP Works - The Handshake
HTML-код
- Опубликовано: 29 июн 2024
- 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...
Great video Chris. Please make more of these. Many people need the fundamentals to understand the root causes of application latency.
I'll do my best to keep them coming. Thanks for the comment!
@@ChrisGreer great thanks. Can't thank you enough.
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.
Thanks for the comment TJ!
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
Thanks for the comment Ram!
im still dont understand,do yoi recommend anythig?
@@johnvardy9559 go back and watch the video again, this is the best source you can find
I agree, Chris has IMPRESSIVE teaching skills. We need more teachers like him
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.
Thanks for the videos Chris, I started watching your videos from couple of days. These are really helpful.
thanks Chris, your english is so easily understandable, this is for sure a differential. greetings from brazil!
Thank you so much for making this Tcp series
great video Chris, thanks a lot for sharing knowledge !
Thank you, what a great inside, this helps me better at my job
This dudes explanations are absolutely amazing!
Oh wow. Thank you for the amazing explanation!
Im new to network security ,Really love your videos, giving good explanation and examples on TCP communication
Thank you
This is the best video i came through. Good Job Chris, expecting more videos. Thank you buddy.
Thank you Sivasakthi! More soon.
Great video. Clarifying details of TCP.
Excellent Video Chris. I've started watching your videos and they are really helpful in real world cases. Great Job!
Thanks Samir! I appreciate the feedback. I will keep on making these short videos.
Awesome!! Please do many more videos like these
Awesome my friend. Keep up this excellent job.
Excellent Videos , explained complex topics in very simple manner and easy to understand.
Excellent explanation Chris. Thanks a lot
Keep creating vids man! Will watch them all, ain't lying
You bet! I will keep them coming. Have more coming out very soon.
Great video! Thanks for sharing
thanks for the informative video chris.. much appreciated
Great video best tutor and explanation I have found. Very clear and informative straight to the point. Nicely broken down
Thanks for the comment!
Thank you bro
I needed this a lot and this video was perfect
nice and clear explanation, thank you so much for this chris
You are welcome - thanks for stopping by!
Thanks chris...I am a big fan of yours.Please post more basic videos and case studies.Great help!
Thanks Anshu! i'll keep them coming. thank you for the comment.
Thank you so much for making these videos!
Thanks a lot for the explanation.
Thanks for your video, that's really helpful for me!
You are welcome! Very happy that it helped you.
thanks ,, its was so helpful
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
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!
Great stuff!
Thank you for educating us chris!
Glad to hear the videos help!
thanks the video was excellent !
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
Great video Chris, thank you :)
You are the MAN Chris. Thanks a lot for this great explanation 👍
Thanks for the comment Amir!
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.
Great.
Could you sort this playlist by date, please?
Thanks!
Thanks for great explanation.
Wonderful video in 2022 as well. Basics prevail
Very good detailed explanation.. Really appreciate it.
Thanks for the comment Aleem!
clearly explained. god bless you, thanks!
Thanks for the comment!
only ppl that master the topic with theoretical knowledge and consistent practical experience have Your level of clarity! Your passion is really inspirational Chris! 👋💯
Wow, thank you!
Nice video chris
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.
Thanks for the comment!
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..
Thanks for the comment Prateek. I'm in my studio shooting some new stuff now! So stay tuned and subscribed.
Awesome video :)
Thank you!
Thank you so much for these wonderful videos :)
Glad you like them!
Great video....Thanks
Thank you man for sharing this stuff
Thank you for the comment!
Great Video Chris. I look forward to diving deeper into your material. - Kyle Sullivan
Awesome, thank you!
Thank you so much !!!
Really great video 👍👍
Thank you 👍
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
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.
Thank you Chris 🙏
My pleasure!
Wonderful and to the point....now onto offsets ;-)
Thanks! Yes - more to come.
Amazing Thanks
Would be helpful to include in the video the data transfer completion. Meaning how does Wireshark interprets a completion of a transmission.
THANK YOU 🙏🏽
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!
Awesome Peter! Thank you for the feedback!
@@ChrisGreer The fact I see you using Zoom is heartbreaking haha
@@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!
@@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.
Great!!
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?
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 :)
Hey - did you check out my Congestion Control Explained video yet? ruclips.net/video/LNeZZZ_oslI/видео.html
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.
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?
Hello, thanks for the comment! You can check out my TCP sequence number video which goes into that. ruclips.net/video/BWILgDt6jz0/видео.html
Great Content
Thank you!
excellent sir
Keep watching! Thank you.
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?
Thanks!
Thank you!
Thanks man
You're welcome!
Chris can you please do a video on the analysis of IPV6 packet?
Great idea for a future video, thanks!
Awsome😊
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
Hey, great question. I have a video about it - ruclips.net/video/oxyp4deHZXM/видео.html check it out!
Chris I love your videos. Can you make video on https packet analysis?
Hello Abraham - That is coming soon. Stay tuned!
4:32 so set TcpMaxConnectRetransmissions in Registry for windows 10 client to "1" ? or is 2 better
There's a lot we can learn from TCP. We should all acknowledge the syns of our past.
Yessir!
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?
Can you make a tutorial for wireshark !
Hi Chris. I couldn't find the Pcap file that you've been using in your system. can you help me with that?
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?
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.
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?
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!
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.
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!
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
Where can I find this on my personal Pc?
What happens if some bits are wrong due to connection errors? How to detect them and fix them?
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
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.
Hi. I can't find the pcap file that you have been using in your system.
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?
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.
i searched for *wireshark how to be the one creepy dude in the coffee shop* think i got the right video
when i try to follow a stream through wireshark it shows me a encrypted text not the names
Seems like you were interacting with the server over HTTPS. Which would encrypt all of the TCP conversations.
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 ?
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.
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
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. ruclips.net/video/OU-A2EmVrKQ/видео.html
@@ChrisGreer thanks Chris
How different is it with IPv6?
So basically ack number is one number higher than the previous packet seq number?
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.
@@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.
Sorry for my ignorance, question: why we should not capture traffic at server?
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.
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
@@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.
@@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
@@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
Is there a separate video for Flags?
No not yet. But it is covered in this video starting at 4:17.
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...
@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.
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. :-)
@@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!
Video 1