Just so I am clear on this, am I correct in a trace file, the Window size in the TCP section relates to the senders recieve window size
So for example, I done a trace between client and server
Client -> Server Window Size 64240
Server -> Client Window Size 26883
So in the above, client has a 64k Recieve Window size and Server has a 26k Recieve Window size
Also, are the Window size negiotated at the TCP 3 way hand shake.
Window size will be announced in each package. When a packet is received, the packet is stored in the receive buffer. And when the receiver then sends a packet to the sender, for example an ACK, this ACK contains the current size of the buffer. It depends on the situation, but usually you can see that the buffer has shrunk by the size of the received segment. The first packets where the Window Sizes are advertised are the SYN packets.
But maybe you mean the Window Scaling Factor. This value is only advertised in the SYN packets.
so this is the packet I am referring to, this was collected on my laptop (source) connecting to a website.
Wireshark packet capture (https://ibb.co/yV4ZL5J)
Am I correct in thiking, the source (192.168.10.122) is saying this packet I have sent to the destination, the TCP Windows on the destination will be full.
Unfortunately exactly here comes the 3-way handshake into play, because we need to know the window scaling factor (WS). If you have captured the 3-way handshake Wireshark will display Window size correct. - And it says: I send you this data, but keep in mind I can receive only 508 Bytes anymore; - The reason for window full can good spotted mostly in the tcp trace graph.
But if Wireshark, don´t have seen the 3-way handshake it will display only the advertised window size value. But this value needs to be multiplied with the WS which was advertised in the 3-way handshake.
So, have you captured the 3-way handshake for this session?
Asked: 2023-11-21 14:47:29 +0000
Seen: 481 times
Last updated: Nov 22 '23
