title: Windows TCP: Diagnosing TCP network bottlenecks
body: <p>I'm implementing a client server solution where the server constantly sends a stream of messages over TCP to the client.</p>
  
  <p>When I do some testing and connect the client and server directly in memory through code, I get very high throughput. When I use TCP over the network, I get a much lower throughput. This is not surprising. However, I'm having a hard time diagnosing and understanding where the bottleneck is.</p>
  
  <p>It seems that the client doesn't receive the messages as fast as the server produces them. The server is too fast. If I stop the server from sending anymore messages, I can see that actually the client still receives some messages from the server from several seconds (up to 20 seconds!) even though the server stops sending message (at the application level). 
  So I'm guessing that TCP is trying to be smart and is throttling the server message rate, causing the messages to be queued (on the server, interestingly).</p>
  
  <p>How can I actually verify that this is what is really happening? How can I detect this situation programmatically? Or with tools?
  I run under Windows XP and I found a Windows performance counter called "Output queue length" under the category "Network interface": "length of the output packet queue (in packets)".
  However this remains to 0 all the time (both server and client)...</p>
  
  <p>One more thing, I was expecting both the sender and receiver to have high CPU usage but it doesn't go that high. Again I'm guessing that it's because of the network side effects.
  Is there anyway to measure the overhead incurred by TCP processing (checksum and other stuff)?</p>
  
  <p>To give you an idea, the server sends about 1.5M bytes per second.</p>