The topic of Window Update packets surfaced at ask.wireshark.org recently.
'Is it normal to see tcp window update packet (tcp.analysis.flags as a filter) for EVERY get/post request from a client workstation on the same LAN?'
The answer is... maybe. First let's talk about the infamous Window Update designation in Wireshark.
As TCP data packets arrive, their data is placed in the TCP receive buffer space until an application pulls that data out. If the data is sluggish at pulling the data out, the TCP receive buffer size begins to decrease. This is seen in every ACK packet sent by the host that is receiving data.
Wireshark doesn't alert you to the shrinking TCP window size or any window size problems until a host gets down to a window size of zero. Then Wireshark screams that there is a Window Zero condition.
After an application picks up data from the TCP receive buffer there is more space available and the sender increases their window size field value. THIS is what triggers Wireshark to mark the packet as a Window Update packet. It's a good thing.
The Wireshark Expert Infos window Chats tab is where the Window Update notices are displayed. They've moved from the more alarming Warnings or even Notes section to this boring location.
How can you quickly find if you have Window Update packets in your trace file? Apply a display filter for expert.message=="Window update" (watch the capitalization here). It's a simple and elegant color filter.
If you have the Wireshark Network Analysis book, check out Chapter 13, Wireshark's Expert System, for a definition of all the TCP expert notifications.
Now waht about seeing a TCP Window Update packet for EVERY GET/POST request from a client workstation on the same LAN? Well - it simply means that the HTTP application is pulling the data out of at the time a GET/POST is issued. Is that a problem? Nope. Is it normal? Nope - but hey - it's not a Window Zero issue and there's still buffer space available!
Enjoy!
Laura
