Chris, I think this may be the best material I've ever come across for understanding some of the specific elements of TCP. The time you spent on the receive window confirmed the detail I have in my notes, but the congestion window explanation has always been somewhat elusive online! I have some pretty concise notes, but to see the concepts played out visually in a steady way, and also in context with the capture files, was simply great to watch. Didn't feel like an hour and 20mins. Some great tips too when analysing in Wireshark. Great work - this is how TCP should be taught.
Awesome stuff, both parts. I've worked as an F5 support engineer for a couple years prior to watching this, and I took a ton away from watching these two sessions. Thanks alot man!
Hello Chris, Many thanks for uploading this content. I'm networking core and I'm surely one of those layer 3 heads. I normally joke about doing stuff at layer 3.5 to my application colleagues. Your presentation changed a bit of my perception on troubleshooting with wireshark. I see I still having so much to cover on my studies and I appreciate very much your effort to provide such quality material.
Chris, awesome as always. When I started looking deeper into protocol analysis, of course with your help, I started understanding network and other technologies much better, it all started to make so much more sense. Thank you for those sessions, master! PS please do more, boy do i enjoy those
This is an awesome talk I am new to wireshark and packets but watching your talk on D.Bombal right before this talk made the topic understandable and approachable.
Excellent video to get interested in the guts of TCP. This has me very interested in testing my network and servers now to see if there are any optimizations or bottlenecks now.
Greetings NetSkills! For this session I decided not to share them for the general public. But, several of my videos have shared trace files that you can follow along on. Thanks for the comment.
Hi Chris, Your videos are really helpful and awesome explanations. I really start to enjoy packet analysing. Is there any place I can get different captures with issue description to analyse and later verify my analysed report is correct? thank you for the great videos again
Thanks Chris It's a wonderful explanation 1 doubt: how did you calculate the number of packets that came before ack "referring timestamp 41:00 to 43:00 in this video"?
Hi Chris, very nice lecture this is becoming my favorite channel of all time :D. I'm a beginner in TCP/IP and the discussion got a little too complex to me at the end so I got lost a bit please clear this up if you can: In the last part 'TCP MSS Problem' if I understand correctly the MSS which was agreed by the server&client during the handshake was reduced mid communication because of some router which was in between them? Did I get that right? And if so, how is that possible, isn't the MSS something which is only agreed upon during the 3 way handshake and then set in stone for the remaining of the connection? How can some intermediary router change that?
Hey Paul - Changing the TCP MSS is an option on some routers. Cisco for example allows us to do it for every SYN that goes by. Try searching Google for whatever router manufacturer you are using. The feature is generally called TCP MSS clamping.
I had the exact same issue in my network as described in your last packet capture. A packet capture on client side was showing that a 1460 byte packet got lost somewhere on the way. Problem was the network in between was managed by a not so cooperative vendor and the server was in control of a different organisation, so getting a server capture or adjusting mss on a network node in between wasn't an option. What I did to resolve the scenario was to decrease the mtu on the client pc itself so that the MSS would stay low to 1398 bytes, which was the MSS value that was working as I observed on a different application. The application did run this time but we're still seeing some chunks of 1398 byte packet get dropped as well which is retransmitted back to the client after a while (without mss adjustment, the retransmitted Packets are 1398 bytes as well), so slowness in opening the application is still there. Would you have any idea what could be causing this? Thanks so much for the guidance anyway Chris! Priceless lectures!
Some time passed since this video was published but I`ll try to ask anyway :) First... After many years at IT in different roles (System\Network\Security\Managment) I have to say that this is great and clear explanation of TCP and I learned new stuff. Now the question regarding the last case study about LDAP. Actually what happend is some FW between the Client and the File Server just dropped packets (from server to the client) because their MSS exceeded what it alterded in the original SYN,SYN-ACK,ACK packets exchange? I get it right ?
Hello, thanks for the comment. Close.... A router at the client end was not altering outbound syns to reflect an MSS of 1432 rather than 1460. So the server was sending packets that were too large, thinking that the true MSS was 1460
I will definitely go to next sharkfest. Do you have any session or recommendation on detailed SACK analysis ? I also would like to know if you have anything to figure out mtu issues.
Chris, great content as always. I have a scenario where receiver advertised it’s receive window of 211 no window scaling and next packet sender still sends 1460 bytes why would it do that knowing the receiver window size is low. Sender continues to do that why would it do that?
Hi Chris, This is really helpful. I got one question. In one capture, I can see MSS is set as 1460 (as per SYN, SYN/ACK) but later I can see TCP segment length (from client)much higher than 1460 (as high as 7K, 14K, 30K etc). How to explain that? The capture is on the client side with iperf. The client and servers are back to back connected.
Hey thanks for the comment. That is because you are capturing on the client before the NIC segments the data. That is a very common thing, the kernel stack can offload TCP segmentation down to the NIC, so that the packet driver level, we see really large frames, but if these same frames were captured on the wire, they would be segmented according to the link-partner MSS or smaller.
They are different concepts, but related - when a receiving TCP stack is sent data, it should ack that data as soon as possible. Depending on the stack, this may be after receiving one, two, or more segments of data. The RX window is the amount of data that can be received at once. It is basically a receive buffer and limits the amount of outstanding data a sender can put out on the wire. I hope that helps.
Hey Chris, Thank you for the informative videos! Quick question.. Do you know what "4 "NOP" in a row, router may have removed some options" warning/error code means? Thank you for any help :)
For case study, MSS problem i was confused with the explaination, since it was saying the outbound router of the client side was replaced and missed the config, but the talking at the end is saying the server is getting 1432 mss advertised by the client, and but the trace we actually referring to the client side capture rigth? So the server side is thinking client is doing 1460, but client side router is only doing 1432, and passed mss size to client, so when server tried 1460, no go, being dropped by client side router.
Hello, great question. Yes that is correct. The outbound router on the client side was not adjusting the MSS in the outbound SYN. So when it arrived at the server, it was 1460. But the outbound router on the server side was adjusting the SYN MSS in the opposite direction. So the client knows to not send anything larger than 1432, but the server never got the message, so it sends 1460's in an attempt to use the full MSS of the client. Hope that helps. Thanks for the comment!
Thank you for this incredible and very clear explanation Chris, you rock! BTW, at 36:23 Chris has mentioned about Simon's talk about different TCP congestion algorithms, it's available at: ua-cam.com/video/2coqZ07-Yhw/v-deo.html
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Chris, I think this may be the best material I've ever come across for understanding some of the specific elements of TCP. The time you spent on the receive window confirmed the detail I have in my notes, but the congestion window explanation has always been somewhat elusive online! I have some pretty concise notes, but to see the concepts played out visually in a steady way, and also in context with the capture files, was simply great to watch. Didn't feel like an hour and 20mins. Some great tips too when analysing in Wireshark. Great work - this is how TCP should be taught.
Thanks so much for the comment! I appreciate the feedback and will do my best to keep the content coming. Thank you.
Im 40 years old.. just got interested into this stuff and working on my ccna and i wish you were my teacher..thank you for your great videos
Man your way of explaining things is just absolutely amazing! Great video!
Awesome stuff, both parts. I've worked as an F5 support engineer for a couple years prior to watching this, and I took a ton away from watching these two sessions. Thanks alot man!
Thanks for the comment Matt!! I'll keep making it!
Hello Chris,
Many thanks for uploading this content.
I'm networking core and I'm surely one of those layer 3 heads. I normally joke about doing stuff at layer 3.5 to my application colleagues. Your presentation changed a bit of my perception on troubleshooting with wireshark.
I see I still having so much to cover on my studies and I appreciate very much your effort to provide such quality material.
Thanks Cleber - I will do my best to keep it up. I appreciate the comment. Make sure to subscribe!
Chris, awesome as always. When I started looking deeper into protocol analysis, of course with your help, I started understanding network and other technologies much better, it all started to make so much more sense. Thank you for those sessions, master!
PS please do more, boy do i enjoy those
Thanks for watching!
This is an awesome talk I am new to wireshark and packets but watching your talk on D.Bombal right before this talk made the topic understandable and approachable.
You are the best and no one can beat you... Keep up the good job...
Thank you so much 😀
As a fresher starting as a Support engineer this was amazing session on TCP, hope to see more!
Thanks Bijay!
These are the best two TCP videos I've seen. Studying for the CCNP ROUTE and chapter one is diving into TCP. This really helped tie things together.
Thanks for the comment Xander. Hope you ace that test.
Chris .... You did mindblowing lecture ... Your selfless thought by sharing what you learned are commendable ....
Thank you for the comment!
These two videos took my understanding of TCP to a whole new level. Thank you.
Glad you like the content! Thanks for the comment.
This guy does awesome job at explaining!
Thanks for the comment!
Been looking out for the second part for a while. Thank you, sir. This is very informative and brought in a very good way. You rock!
Excellent video to get interested in the guts of TCP. This has me very interested in testing my network and servers now to see if there are any optimizations or bottlenecks now.
Thanks for the comment!
Chris, this is like getting enlightened, thank you
Great great vedio, this is the best course about the usage for wireshark I have even seen even 4 years pass. Thank you😊
Thank you!!
Very Well explained case files.. you made me fan of you
thanks man, real nice tutorial, i love the way you started from scratch and gave a solid base. thanks again
Thanks for the comment!
Hi Chris, you are an excellent presenter, and I learn a lot from your videos. Well done.
You are awesome man, learnt so much from this. Great explanation.
Thanks for watching! Glad it helped.
TCP training at its best...
Awesome. Very well explained. Great Job, Chris!!
Chris, As usual this is fantastic Thank you
Such good stuff!! Thanks Chris. Indebted!
Glad you enjoyed it!
Excellent Sir..... Worth 🥰🥰🥰
Thank you for the comment!
Watched this video for the 7th time and can see this for 7 more time :)
Thanks for the great session.
Havent seen such detailed explanation of TCP. This is awesome stuff Chris. Do you write books as well.
Thank you! This was very very clear an simple, just like it should be :)
Awesome! Thanks for the comment - I'm really glad you liked it.
What an amazing content this is. You rock Chris.
Thanks for the comment!
You're amazing! Thank you for the wonderful content!
You are most welcome!
Another[part-2] awesome video... Thank you very much; many of the basic concepts are cleared now; Do you have a part 3?
At this point no - but I do offer remote training on Wireshark and TCP. Please contact me at www.packetpioneer.com/contact for details.
Hi, Chris! Great explanation! Thanks! I just wonder, could you share your traffic dumps so we could repeat all your moves.
Greetings NetSkills! For this session I decided not to share them for the general public. But, several of my videos have shared trace files that you can follow along on. Thanks for the comment.
Great job! Thanks!
65535 - that's how many "aha" moments I got watching your video. Awesome stuff Chris!!
Hi Chris, Your videos are really helpful and awesome explanations. I really start to enjoy packet analysing. Is there any place I can get different captures with issue description to analyse and later verify my analysed report is correct? thank you for the great videos again
I am working on more "here is a problem, find the solution" videos! Stay tuned and subscribed for these.
@@ChrisGreer great. looking forward to it :)
Thanks Chris
It's a wonderful explanation
1 doubt: how did you calculate the number of packets that came before ack "referring timestamp 41:00 to 43:00 in this video"?
He counts them until he comes across a delay if you look at the delta time.
real good stuff, I must leave a comment and click a like!
Hi Chris, very nice lecture this is becoming my favorite channel of all time :D.
I'm a beginner in TCP/IP and the discussion got a little too complex to me at the end so I got lost a bit please clear this up if you can:
In the last part 'TCP MSS Problem' if I understand correctly the MSS which was agreed by the server&client during the handshake was reduced mid communication because of some router which was in between them? Did I get that right? And if so, how is that possible, isn't the MSS something which is only agreed upon during the 3 way handshake and then set in stone for the remaining of the connection? How can some intermediary router change that?
Hey Paul - Changing the TCP MSS is an option on some routers. Cisco for example allows us to do it for every SYN that goes by. Try searching Google for whatever router manufacturer you are using. The feature is generally called TCP MSS clamping.
@@ChrisGreer thank you!
Thank you for the great information.
I had the exact same issue in my network as described in your last packet capture. A packet capture on client side was showing that a 1460 byte packet got lost somewhere on the way. Problem was the network in between was managed by a not so cooperative vendor and the server was in control of a different organisation, so getting a server capture or adjusting mss on a network node in between wasn't an option. What I did to resolve the scenario was to decrease the mtu on the client pc itself so that the MSS would stay low to 1398 bytes, which was the MSS value that was working as I observed on a different application. The application did run this time but we're still seeing some chunks of 1398 byte packet get dropped as well which is retransmitted back to the client after a while (without mss adjustment, the retransmitted Packets are 1398 bytes as well), so slowness in opening the application is still there. Would you have any idea what could be causing this? Thanks so much for the guidance anyway Chris! Priceless lectures!
Chris, well explained as always. Can you please upload the packet capture ?
Some time passed since this video was published but I`ll try to ask anyway :)
First... After many years at IT in different roles (System\Network\Security\Managment) I have to say that this is great and clear explanation of TCP and I learned new stuff.
Now the question regarding the last case study about LDAP. Actually what happend is some FW between the Client and the File Server just dropped packets (from server to the client) because their MSS exceeded what it alterded in the original SYN,SYN-ACK,ACK packets exchange? I get it right ?
Hello, thanks for the comment. Close.... A router at the client end was not altering outbound syns to reflect an MSS of 1432 rather than 1460. So the server was sending packets that were too large, thinking that the true MSS was 1460
Awesome training! Can I please get these wireshark files as I need to give training in my office!
You are a god
I will definitely go to next sharkfest. Do you have any session or recommendation on detailed SACK analysis ? I also would like to know if you have anything to figure out mtu issues.
Hello Nanis - not off the top of my head, but SACK analysis would be a great session title. Maybe I'll do that for Sharkfest US 2019
Chris Greer awesome sounds good
Interested to attend 2019 session. who sponsors the whole expenses of the trip/program. I think, individual(candidate) has to bear
Thanks for these great videos, I'll bet the slow application was a tape drive.
Another fantastic session !!
Chris , will there be Sharkfest 2019 session? & most importantly will we be able to hear from you this year ?
Yes! I will post it on my channel soon.
@@ChrisGreerLooking forward for more interesting discussion. You truly are an expert !.
Chris, great content as always. I have a scenario where receiver advertised it’s receive window of 211 no window scaling and next packet sender still sends 1460 bytes why would it do that knowing the receiver window size is low. Sender continues to do that why would it do that?
Any chance we missed the TCP handshake in the pcap?
Hi Chris,
This is really helpful. I got one question. In one capture, I can see MSS is set as 1460 (as per SYN, SYN/ACK) but later I can see TCP segment length (from client)much higher than 1460 (as high as 7K, 14K, 30K etc). How to explain that? The capture is on the client side with iperf. The client and servers are back to back connected.
Hey thanks for the comment. That is because you are capturing on the client before the NIC segments the data. That is a very common thing, the kernel stack can offload TCP segmentation down to the NIC, so that the packet driver level, we see really large frames, but if these same frames were captured on the wire, they would be segmented according to the link-partner MSS or smaller.
Got it. Thanks a lot..
Hi Chris, Is there a relation b/w receive window and ACK?
They are different concepts, but related - when a receiving TCP stack is sent data, it should ack that data as soon as possible. Depending on the stack, this may be after receiving one, two, or more segments of data. The RX window is the amount of data that can be received at once. It is basically a receive buffer and limits the amount of outstanding data a sender can put out on the wire. I hope that helps.
Hey Chris,
Thank you for the informative videos! Quick question.. Do you know what "4 "NOP" in a row, router may have removed some options" warning/error code means? Thank you for any help :)
That's just padding
Awesome session. Thanks Chris Greer !!
Do you recommend any authentic book on TCP that should be on our bookshelf and the one that we can consult any time? Please mention. Thanks
I constantly refer to TCP/IP Illustrated Volume 1 - Second Edition. I think that book should be on the shelf of every network engineer.
@@ChrisGreer thanks you chris
if the server side bucket is filling up and server side app is the cause how can we say client is hanging us up
In that case the server would be hanging us up if its RX window was filling.
Great session. can you please do a session on "your way of filters".
ua-cam.com/video/68t07-KOH9Y/v-deo.html Here you go.
Awesome!
Any resources on how to start catching packets (for almost beginners)? Thank you.
Hello @all: is there a possibility to get the Trace Files?
thank you!
Hello Chris, may I ask for the pcap traces for window size
For case study, MSS problem i was confused with the explaination, since it was saying the outbound router of the client side was replaced and missed the config, but the talking at the end is saying the server is getting 1432 mss advertised by the client, and but the trace we actually referring to the client side capture rigth? So the server side is thinking client is doing 1460, but client side router is only doing 1432, and passed mss size to client, so when server tried 1460, no go, being dropped by client side router.
Hello, great question. Yes that is correct. The outbound router on the client side was not adjusting the MSS in the outbound SYN. So when it arrived at the server, it was 1460. But the outbound router on the server side was adjusting the SYN MSS in the opposite direction. So the client knows to not send anything larger than 1432, but the server never got the message, so it sends 1460's in an attempt to use the full MSS of the client.
Hope that helps. Thanks for the comment!
Great!
Love it !!!!!
Awesome.....
Another banger
So if server is only sending mss of 1432 instead of 1460 the remaining 28 packets will go in next round trip. Will client send sack for them?
51:30 TCP Timestamps
Thank you very nuch
You are welcome
Can i get this pcapng file ?
I want to star every s i n g l e Wednesday like 0:06
liked it
Thank you for this incredible and very clear explanation Chris, you rock!
BTW, at 36:23 Chris has mentioned about Simon's talk about different TCP congestion algorithms, it's available at:
ua-cam.com/video/2coqZ07-Yhw/v-deo.html
Thanks for the comment Edson! I really appreciate the feedback.
ua-cam.com/video/8RI9wtmcpeY/v-deo.html - this is probably the one that Chris referred to in the video
No part 3? 🥺🥺
Check out my course at bit.ly/wiresharktcp - that is where all the fun bits are.
@@ChrisGreer 🙏
Please please show subtitles in spanish or english I am from Colombia this video is viewing in all world
Ok I just fixed that. Thank you!
I am spending my valentine with TCP
que grande el pibardÚ
That guy who keep cough should just get out ...
agreed. Today the whole audience probably would have gotten up and walked out!
So freaking slow over over