pbenito
asked on
What is a TCP Window Update?
I'm writing a web service client and I'm getting a lot of TCP Window Update packets in my Wireshark capture. What are they and are they bad?
Thanks!
Thanks!
Can you post the packet? Most likely its just chatter to the MS update server, but I am not sure.
ASKER
Frame 3881 (60 bytes on wire, 60 bytes captured)
Transmission Control Protocol, Src Port: http (80), Dst Port: tapestry (1922), Seq: 1, Ack: 2778606, Len: 0
Source port: http (80)
Destination port: tapestry (1922)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 2778606 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
Window size: 65535
Checksum: 0x91ac [correct]
[SEQ/ACK analysis]
[TCP Analysis Flags]
[This is a tcp window update]
Transmission Control Protocol, Src Port: http (80), Dst Port: tapestry (1922), Seq: 1, Ack: 2778606, Len: 0
Source port: http (80)
Destination port: tapestry (1922)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 2778606 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
Window size: 65535
Checksum: 0x91ac [correct]
[SEQ/ACK analysis]
[TCP Analysis Flags]
[This is a tcp window update]
I believe that is web traffic.
ASKER
What does it mean?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Do you see TCP ZeroWindow and/or TCP Zero_WindowProbe?
It means one side of the communications receive buffer was full and could not receive anymore data. It thens sends a zero window, the other side then sends a zero window probe to see if the window is still in the zero window state. Then zero window updates are sent to renegotiate the window size.
It means one side of the communications receive buffer was full and could not receive anymore data. It thens sends a zero window, the other side then sends a zero window probe to see if the window is still in the zero window state. Then zero window updates are sent to renegotiate the window size.
ASKER
Thanks!
The tcp window specifies how much data can be in transit.
One way of looking at it is a method to let the "sender" know how much buffer space is available at the "receivers" end so that the sender does not send more data than the receiver can handle.
Window updates are usually performed as part of "normal" packet that contains data. Every time a tcp packet goes back from the receiving end it includes it's current window size/buffer space available so essentially every tcp packet is also a window update (although it is not marked as such).
However, on a (mostly) unidirectional connection (ie, data only flows in one direction) the receiver has no "normal" outgoing packets. It will still have to let the sender know of it's window size, because otherwise the sender will eventually think that the receivers buffers are full.
These updates are called window updates and are essentially a tcp packet that has no data and is sent with no other purpose than to let the sender know that the space available in the receivers buffer has increased.
Depending on your implementation they may anything from completely legit to a slight waste of bandwidth. Likely the former.
One way of looking at it is a method to let the "sender" know how much buffer space is available at the "receivers" end so that the sender does not send more data than the receiver can handle.
Window updates are usually performed as part of "normal" packet that contains data. Every time a tcp packet goes back from the receiving end it includes it's current window size/buffer space available so essentially every tcp packet is also a window update (although it is not marked as such).
However, on a (mostly) unidirectional connection (ie, data only flows in one direction) the receiver has no "normal" outgoing packets. It will still have to let the sender know of it's window size, because otherwise the sender will eventually think that the receivers buffers are full.
These updates are called window updates and are essentially a tcp packet that has no data and is sent with no other purpose than to let the sender know that the space available in the receivers buffer has increased.
Depending on your implementation they may anything from completely legit to a slight waste of bandwidth. Likely the former.