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.
only ppl that master the topic with theoretical knowledge and consistent practical experience have Your level of clarity! Your passion is really inspirational 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.
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, 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
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!
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!
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
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.
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?
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.
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.
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...
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.
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
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. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-BWILgDt6jz0.html
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.
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.
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..
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.
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
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.
