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
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.
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.
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.
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.
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
only ppl that master the topic with theoretical knowledge and consistent practical experience have Your level of clarity! Your passion is really inspirational Chris! 👋💯
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..
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?
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!
@@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!
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.
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!
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
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
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?
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 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
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?
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?
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!
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 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.
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.
@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!
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.
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.
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.
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.
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
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!
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 Chris, your english is so easily understandable, this is for sure a differential. greetings from brazil!
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!
This dudes explanations are absolutely amazing!
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.
Im new to network security ,Really love your videos, giving good explanation and examples on TCP communication
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.
This is the best video i came through. Good Job Chris, expecting more videos. Thank you buddy.
Thank you Sivasakthi! More soon.
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!
Keep creating vids man! Will watch them all, ain't lying
You bet! I will keep them coming. Have more coming out very soon.
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.
Thanks!
Thank you!
Great.
Could you sort this playlist by date, please?
Thanks!
Very good detailed explanation.. Really appreciate it.
Thanks for the comment Aleem!
Thanks for the videos Chris, I started watching your videos from couple of days. These are really helpful.
Would be helpful to include in the video the data transfer completion. Meaning how does Wireshark interprets a completion of a transmission.
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
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.
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.
Great video best tutor and explanation I have found. Very clear and informative straight to the point. Nicely broken down
Thanks for the comment!
Chris can you please do a video on the analysis of IPV6 packet?
Great idea for a future video, thanks!
4:32 so set TcpMaxConnectRetransmissions in Registry for windows 10 client to "1" ? or is 2 better
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!
Excellent Videos , explained complex topics in very simple manner and easy to understand.
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.
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!
Thank you so much for making this Tcp series
You are the MAN Chris. Thanks a lot for this great explanation 👍
Thanks for the comment Amir!
Excellent explanation Chris. Thanks a lot
Really great video 👍👍
Thank you 👍
great video Chris, thanks a lot for sharing knowledge !
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.
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
Hi Chris. I couldn't find the Pcap file that you've been using in your system. can you help me with that?
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
Thank you bro
I needed this a lot and this video was perfect
thanks for the informative video chris.. much appreciated
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?
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!
Awesome my friend. Keep up this excellent job.
Where can I find this on my personal Pc?
Hi. I can't find the pcap file that you have been using in your system.
Great video. Clarifying details of TCP.
Thank you, what a great inside, this helps me better at my job
Great Video Chris. I look forward to diving deeper into your material. - Kyle Sullivan
Awesome, thank you!
Wonderful video in 2022 as well. Basics prevail
Thanks for great explanation.
Thank you so much for making these videos!
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
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?
nice and clear explanation, thank you so much for this chris
You are welcome - thanks for stopping by!
Thanks a lot for the explanation.
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
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?
Is there a separate video for Flags?
No not yet. But it is covered in this video starting at 4:17.
Thank you for educating us chris!
Glad to hear the videos help!
Oh wow. Thank you for the amazing explanation!
Great video! Thanks for sharing
Awesome!! Please do many more videos like these
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.
Great video Chris, thank you :)
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!
Can you make a tutorial for wireshark !
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.
Thanks for your video, that's really helpful for me!
You are welcome! Very happy that it helped you.
thanks ,, its was so helpful
thanks the video was excellent !
There's a lot we can learn from TCP. We should all acknowledge the syns of our past.
Yessir!
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.
Amazing Thanks
Thank you!
clearly explained. god bless you, thanks!
Thanks for the comment!
Thank you man for sharing this stuff
Thank you for the comment!
Thank you Chris 🙏
My pleasure!
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.
What happens if some bits are wrong due to connection errors? How to detect them and fix them?
Thank you so much for these wonderful videos :)
Glad you like them!
Nice video chris
@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!
Chris I love your videos. Can you make video on https packet analysis?
Hello Abraham - That is coming soon. Stay tuned!
excellent sir
Keep watching! Thank you.
Wonderful and to the point....now onto offsets ;-)
Thanks! Yes - more to come.
Thank you so much !!!
Great Content
Thank you!
THANK YOU 🙏🏽
im confused, what does he mean by these 'windows'....
I'm guessing you mean the TCP Window values - these are explained in other videos in this series. Check them out!
@@ChrisGreer I appreciate the answer!
Great video....Thanks
Awesome video :)
Great stuff!
i searched for *wireshark how to be the one creepy dude in the coffee shop* think i got the right video
Thanks man
You're welcome!
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.
Mr. Greer, How may I email you for specific questions? Do you have an email address?
Sure! Pop me a message - packetpioneer.com/contact/
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.
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.
Awsome😊