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.
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
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!
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.
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
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?
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?
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.
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...
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. th-cam.com/video/OU-A2EmVrKQ/w-d-xo.html
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.
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..
only ppl that master the topic with theoretical knowledge and consistent practical experience have Your level of clarity! Your passion is really inspirational Chris! 👋💯
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 have play list with TCP but you didn't follow NTP in them 😂😂 Could you put port 123 in TCP playlist. So we come to know which one need to see after this video and so on. 😊🙏
I just looked at the playlist - yikes you are correct. It was pretty out of order. I have some new/old videos on common topics so I just resorted it and featured the new and fresh content. Thanks for the suggestion.
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
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
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.
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.
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?
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!
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.
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? th-cam.com/video/LNeZZZ_oslI/w-d-xo.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.
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!
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.
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!
@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!
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.
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.
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.
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.
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.
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
Great.
Could you sort this playlist by date, please?
Thanks!
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. th-cam.com/video/BWILgDt6jz0/w-d-xo.html
thanks the video was excellent !
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?
Thank you Chris 🙏
My pleasure!
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.
Would be helpful to include in the video the data transfer completion. Meaning how does Wireshark interprets a completion of a transmission.
Chris can you please do a video on the analysis of IPV6 packet?
Great idea for a future video, thanks!
thanks Chris, your english is so easily understandable, this is for sure a differential. greetings from brazil!
Im new to network security ,Really love your videos, giving good explanation and examples on TCP communication
Thank you
excellent sir
Keep watching! Thank you.
Wonderful and to the point....now onto offsets ;-)
Thanks! Yes - more to come.
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...
This dudes explanations are absolutely amazing!
This is the best video i came through. Good Job Chris, expecting more videos. Thank you buddy.
Thank you Sivasakthi! More soon.
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. th-cam.com/video/OU-A2EmVrKQ/w-d-xo.html
@@ChrisGreer thanks Chris
great video Chris, thanks a lot for sharing knowledge !
Amazing Thanks
no such thing as hs about it, nonerx
i searched for *wireshark how to be the one creepy dude in the coffee shop* think i got the right video
Very good detailed explanation.. Really appreciate it.
Thanks for the comment Aleem!
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
4:32 so set TcpMaxConnectRetransmissions in Registry for windows 10 client to "1" ? or is 2 better
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?
Hi Chris. I couldn't find the Pcap file that you've been using in your system. can you help me with that?
Thanks for the videos Chris, I started watching your videos from couple of days. These are really helpful.
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 - th-cam.com/video/oxyp4deHZXM/w-d-xo.html check it out!
Thank you, what a great inside, this helps me better at my job
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.
You are the MAN Chris. Thanks a lot for this great explanation 👍
Thanks for the comment Amir!
Great video best tutor and explanation I have found. Very clear and informative straight to the point. Nicely broken down
Thanks for the comment!
dude, add some numbers before the video names. it is hard to followup your playlists. give some video orders to follow up with!
Thank you so much for making this Tcp series
Hi. I can't find the pcap file that you have been using in your system.
Great video! Thanks for sharing
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!
Awesome my friend. Keep up this excellent job.
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.
Chris I love your videos. Can you make video on https packet analysis?
Hello Abraham - That is coming soon. Stay tuned!
What happens if some bits are wrong due to connection errors? How to detect them and fix them?
Really great video 👍👍
Thank you 👍
Oh wow. Thank you for the amazing explanation!
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.
Excellent Videos , explained complex topics in very simple manner and easy to understand.
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!
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.
Awsome😊
Keep creating vids man! Will watch them all, ain't lying
You bet! I will keep them coming. Have more coming out very soon.
You have play list with TCP but you didn't follow NTP in them 😂😂
Could you put port 123 in TCP playlist.
So we come to know which one need to see after this video and so on. 😊🙏
I just looked at the playlist - yikes you are correct. It was pretty out of order. I have some new/old videos on common topics so I just resorted it and featured the new and fresh content. Thanks for the suggestion.
Excellent explanation Chris. Thanks a lot
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 so much for making these videos!
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
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.
thanks ,, its was so helpful
Lee Gary Williams Steven Jones Nancy
Great video Chris, thank you :)
Can you make a tutorial for wireshark !
Mr. Greer, How may I email you for specific questions? Do you have an email address?
Sure! Pop me a message - packetpioneer.com/contact/
Where can I find this on my personal Pc?
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.
Thanks a lot for the explanation.
Thank you!
Johnson Sharon Lewis Joseph Anderson Brenda
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.
Nice video 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?
Thank you bro
I needed this a lot and this video was perfect
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.
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!
How different is it with IPv6?
Thanks for your video, that's really helpful for me!
You are welcome! Very happy that it helped you.
thanks for the informative video chris.. much appreciated
Great video. Clarifying details of TCP.
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.
Wonderful video in 2022 as well. Basics prevail
There's a lot we can learn from TCP. We should all acknowledge the syns of our past.
Yessir!
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? th-cam.com/video/LNeZZZ_oslI/w-d-xo.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.
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!
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!
Great Video Chris. I look forward to diving deeper into your material. - Kyle Sullivan
Awesome, thank you!
Great!!
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!
nice and clear explanation, thank you so much for this chris
You are welcome - thanks for stopping by!
Awesome!! Please do many more videos like these
Is there a separate video for Flags?
No not yet. But it is covered in this video starting at 4:17.
@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!
Awesome video :)
Thank you so much !!!
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.
THANK YOU 🙏🏽
Thanks for great explanation.
Thank you man for sharing this stuff
Thank you for the comment!
Video 1