Slow performance occurs when you copy data to a TCP server by using a Windows Sockets API program

Posted 2022-12-05 HyperWang

原文位置：https://support.microsoft.com/en-us/kb/823764

转载部分内容，详细的见原文。

Symptoms

When you run a program that uses the Windows Sockets API, you may experience slow performance when you copy data to a TCP server.

If you make a network trace with a network sniffer such as Microsoft Network Monitor, the TCP server sends a TCP ACK segment to the last TCP segment in a TCP data stream in the delayed acknowledgement timer (also known as the delayed ACK timer). By default, for Windows operating systems, the value for this timer is 200 milliseconds (ms). A typical data flow for sending 64 kilobytes (KB) of data looks similar to the following sequence:

Client->Server 1460 bytes
Client->Server 1460 bytes
Server->Client ACK
Client->Server 1460 bytes
Client->Server 1460 bytes
Server->Client ACK
....
Client->Server 1460 bytes
Client->Server 1460 bytes
Server->Client ACK-PUSH
Client->Server 1296 bytes
-> delayed ACK 200 ms

Cause

This problem occurs because of the architectural behavior of the Windows Sockets API and Afd.sys. This problem occurs if all the following conditions are true:

• The Windows Sockets program uses non-blocking sockets.
• A single send call or WSASend call fills the whole underlying socket send buffer.

setsockopt( sock, SOL_SOCKET, 32768, (char *) &val, sizeof( int ) );

Later, when the program sends data, it issues a send call or a WSASend call and sends 64 KB of data during each send:

send(socket, pWrBuffer, 65536, 0);

In this scenario, each time the program issues a send call of 64 KB of data, the program returns a SOCKET_ERROR error code if the underlying 32-KB socket buffer is completely filled. After it calls the WSAGetLastError function, the program receives the WSAEWOULDBLOCK error code. Most programs use the Windows Sockets select function to check the status of the socket. In this scenario, the select function does not report the socket as writable until the client receives the outstanding TCP ACK segment. By default in a Windows environment, this may take as long as 200 ms because of the delayed acknowledgement algorithm.

• The remote TCP server acknowledges all the TCP segments before the client sends the last TCP segment with the push bit set.

  Workaround

  Method 3: Modify the TCP/IP Settings on the TCP Server
  On a server that runs Windows XP or Windows Server 2003, follow these steps:

  1. Start Registry Editor.
  2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Interfaces\\<Interface GUID>

1. On the Edit menu, point to New, and then click DWORD Value.
2. Name the new value TcpAckFrequency, and assign it a value of 1.
3. Quit Registry Editor.
4. Restart Windows for this change to take effect.