How TCP Works - The Receive Window

[Music] hello this is Chris from packet pioneer and I just wanted to take a minute talk to you about the TCP window now before I get deep into the weeds here I'm gonna just talk to you about how the fact that there's two types of TCP windows one is a receive window and one is a send window so in this video we're gonna talk about the receive window what this value means and the TCP header and how we can use it to troubleshoot well go into the send window in another video now the TCP window I just have a TCP connection here just one in Wireshark I'm gonna select the first packet and if I open up the TCP header values I wouldn't come down here to the window size value now this is a two byte field in the TCP header and here we see that it's ffff 65 535 basically what this is is it's a receive buffer in whoever is sending this so 192 168 1.1 this is the center of this packet he's telling the other side that I have 65 535 of receive window available what that means is that the opposite side if it is sending data back to this sender whoever sent this if it's sending data back in that direction only 65 535 bytes can be sent before this guy receives the acknowledgments meaning don't send me any more than this that's all I can handle unacknowledged okay now if we look at the other side we notice that the the server comes back and he says ok I got a window size value of 58 40 so this is a much lower window size now in thinking of receive buffers typically servers are the ones sending data to us as clients right we're in many cases we're not uploading data to them especially when it comes to the web and pulling things off of a web page so 5840 now this just means I don't expect I get a whole lot of data from you mister client so I'm just going to keep that resource small now if we go to the TCP the last packet to the three-way handshake we come down we can see that the window size value is 64 240 so this time the client has adjusted it slightly but we notice that this value now appears in Wireshark calculate a window size well windows size value 64 240 that's the number it's telling us but this calculator window size is a whole lot bigger as we can see here so what's going on well if you took a look on the the YouTube channel here for the TCP handshake you'll notice that we talked about the TCP options and if you come up to you the syn we just look at that real quick for this connection and this connection is actually using something called window scaling so the sender of this packet he's saying okay my window scale when you see this number up here actually take that number and multiply it by four that's gonna be my true actual window size now the reason why it does that is because this is a hard number in terms of the amount of space that's allocated to it in the TCP header so in order to make it more make more throughput on like long connections or connection with a lot of latency maybe high bandwidth high latency connections I'm gonna want the sender to put a whole lot more data on there during large data transfers so the only way that I can increase my window size value without actually breaking the TCP header is to use this TCP option called window scaling so now what these server understands is that any value that the client sends for the window size value actually take that number and multiply it by four and that'll actually be the calculated window size so this is the true window size that the client is advertising okay so that's also another reason why it's important to catch the handshakes when we're analyzing a tcp because this is only sent once it's only sent in the handshake and we will never see it again okay so now if we go down further in the connection if we take a look at the data in flight and then we take a look at the acknowledgments we come down to this acknowledgment we can see that the client is advertising a 64 240 window but the true calculate window size is down here below Wireshark helps us out now this is a good time to tell you this is not a number that's actually a part of the packet itself instead this is a value that works is helping us out with just so we can we can understand the true window sighs okay so again this means this number means that whoever sent this 1.1 has 256 and 960 bytes in its TCP receive window so that is all the data that the sender can send before acknowledgments come back now this number isn't going to be static it could be that the receive buffer on the client fills up a little bit maybe the application isn't processing data out of it as fast as data is coming in or maybe it's busy doing some other process but it's possible that this number can begin to drop in fact in this trace file I have an event here and I'm actually going to scroll down you can see these black lines over here on the on the right now these these look ugly right dewbacks previous segments not captured retransmissions and ugliness like that but the thing I'd like to draw your eye to is actually down here just jumped over it there let me just change this out just a little bit there now notice this window folds 0 windows if now basically what this means if I go up a couple more packets data was in flight from the server but if we take a look at the packets coming from the client these are these are empty packets they don't actually have any data in them these are just acknowledgments coming back from the client if I take a look at one of those check out the window size value ok 2920 multiply that by 4 we can see 11 6 80 that's the true window size so the server still has room so it puts a couple more packets on the wire and then we take a look at the next acknowledgment 2190 so the window is dropping 87 60 in fact this is a great if you're doing troubleshooting on window sizes this is a great column to add to your profile in fact I'm going to do that just because we're doing a video about window size so we can see here this is our window size so the server a couple more packets our window sizes 58 40 a couple more packets window sizes 29 20 couple more full packets and that's why Wireshark is saying hey you're buff for your receive buffer in the client was twenty nine twenty we saw two more packets come in and that is the actual mathematical maximum that the server could send the TCP window is now full on the client so now what happens well the server stops the server can't send anything else why because there's the receive buffer on the client side is full and in fact the client says that if I take a look at packet 364 it comes back and says hey thanks for that packet but don't send any more because I'm down to zero if I look at the window size zero calculated window size zero this guy is full on the receive buffer side so now an interesting thing occurs the server can't send any more data so what it's going to do is a little bit of time basically what the server does is it waits a little bit of time that says hey are you still out there are we still talking do you still have a zero window client comes back says yep I'm still zero I can't send any more data to me so basically the server doubles the amount of time so now we're just at almost one point two seconds and he says okay he's still there we still keeping this thing alive or you still full the client says yep I'm still zero window the application hasn't processed things out I'm my TCP receive window is full don't send anything else so the server we can see here it doubles the amount of time again just about and it checks in again it's still zero checks in again still zero and these are full seconds people right so server checks in full window checks in now again a full window now about 115 milliseconds later something happens on the client the receive window gets cleared out so now it goes up to 37 60 and then it further updates its window to the sender so now the client is telling us I've got room for more so fire away so now the server it turns around says great here's some more try right and then it's off to the races okay so if we think about it although I saw retransmissions up above in this trace file this really was the root cause of why things were slow for this client I came in 3.6 seconds into the trace file that's where I hit these window fools and 36 seconds later I saw things go that take off again so really I lost 33 seconds or so just with the client in a zero window condition so hopefully this helps you understand a bit more about tcp windows and how they work and thanks for stopping by you feel free to comment and subscribe down below and I will see you on another video

Channel: Chris Greer

Views: 48,708

Keywords: Wireshark, TCP/IP, TCP, Protocol, TCP Handshake, wireshark training, wireshark tutorial, packet analysis, packet capture, tcp analysis, tcp connections, tutorial, how tcp works, tcp receive window, tcp explained, wireshark analysis

Id: Qpkr_12RQ7k

Length: 9min 35sec (575 seconds)

Published: Mon Nov 06 2017