Chris Greer, a noted Network Analyst , wrote Five super TCP diagnostic articles for Accedian!
TCP Series #1: How to diagnose TCP Connection setup issues?
TCP Series #2: How to close TCP sessions and diagnose disconnections?
TCP Series #3: How to analyze TCP retransmission & duplicate ACKs?
Number 4 - Below - TCP Receive Window
TCP Series #5: How to analyze TCP window problems?
Click on the TCP Series above and read each one of these dives onto the TCP World!
TCP Series Number 4 is the fourth article in a series of articles covering TCP core concepts to effectively troubleshoot performance problems impacting applications and network performance success.
This article discusses the concept of the TCP receive window.
The maximum number of bytes allowed are - 65,535 bytes
After considering how the TCP retransmission mechanism works (TCP #3), we will now examine TCP receive windows and how they can impact performance.
Why should you care about TCP windowing? Because it drives the speed of data transfers and hence the experience of your users accessing the applications, as described in these two other articles:
What’s the impact of TCP events on application performance?
The 5 factors which slow down data transfers and how to identify them
What is a TCP Receive Window?
Simply put, it is a TCP receive buffer for incoming data that has not been processed yet by the application.
The size of the TCP Receive Window is communicated to the connection partner using the window size value field of the TCP header. This field tells the link partner how much data can be sent on the wire before an acknowledgment is received. If the receiver is not able to process the data as fast as it arrives, gradually the receive buffer will fill and the TCP window will be reduced in the acknowledgment packets. This will alert the sender that it needs to reduce the amount of data sent or allow the receiver time to clear the buffer.
Want to read the entire and awesome Diagnostic review - Click Here!
In the above diagram, the client and server are advertising their window size values as they communicate. Each TCP header will display the most recent window value, which can grow or shrink as the connection progresses. In this example, the client has a TCP receive window of 65,535 bytes, and the server has 5,840. For many applications, since clients tend to receive data rather than send it, clients often have a larger allocated window size. After the handshake, the client sends an HTTP GET request to the server, which is quickly processed. Two response packets from the server arrive at the client, which sends an acknowledgment along with an updated window size. The client was able to process the data packets out of the TCP buffer as fast as they came in, so the window size was not reduced.
The client still has a full window available for receiving data – 65,535 bytes.