延迟10ms的TCP ACK响应

我正在编写一个客户端应用程序，该应用程序应该从服务器接收文件。通讯使用了一个通过TCP设计的非常简单的专有协议：服务器发送一块16KB的数据，等待来自客户端的简单响应，然后进入下一个块;这完成，直到文件完全传输。延迟10ms的TCP ACK响应

服务器在Windows上运行。如果我在Windows上运行我的客户端（通过Cygwin），我实现了70Mbits/s的吞吐量。但是，如果我在Linux上运行它，我能够获得的最大吞吐量是5Mbits/s（两个测试使用相同的100Mb以太网链路）。

对我收集的tcpdump跟踪进行了一些调查后，我发现Linux需要大约10ms来回答每个TCP ACK。我试过在每次调用recv（）后都禁用了sockoption TCP_QUICKACK，但没有成功。我还没有发现任何其他可以改变这种行为的TCP选项（在bsd套接字下或甚至在Linux下）。

任何人都可以帮助我弄清楚发生了什么？

我的客户端是用C++编写的，使用BSD套接字。 TCP_NODELAY sockoption被设置。
我的Linux内核是2.6.19
专有协议和服务器不是我的，所以我无法以任何方式更改它们。

下面是我分析的tcpdump跟踪的一个示例。这是一个块传输。服务器IP为10.200.252.1，客户端为10.200.252.2。与**开头的行是TCP ACK数据包与10ms的延迟：

5184 28.060969 10.200.252.1   10.200.252.2   TCP  1510 search-agent > 58358 [ACK] Seq=4736738 Ack=1741 Win=66048 Len=1444 TSval=2951472 TSecr=2921060 
    5185 28.060978 10.200.252.1   10.200.252.2   TCP  1510 search-agent > 58358 [ACK] Seq=4738182 Ack=1741 Win=66048 Len=1444 TSval=2951472 TSecr=2921060 
    5186 28.060981 10.200.252.1   10.200.252.2   TCP  1510 search-agent > 58358 [ACK] Seq=4739626 Ack=1741 Win=66048 Len=1444 TSval=2951472 TSecr=2921060 
    5187 28.060987 10.200.252.1   10.200.252.2   TCP  1510 search-agent > 58358 [ACK] Seq=4741070 Ack=1741 Win=66048 Len=1444 TSval=2951472 TSecr=2921060 
    5188 28.060990 10.200.252.1   10.200.252.2   TCP  1510 search-agent > 58358 [ACK] Seq=4742514 Ack=1741 Win=66048 Len=1444 TSval=2951472 TSecr=2921060 
    5189 28.060994 10.200.252.1   10.200.252.2   TCP  1510 search-agent > 58358 [ACK] Seq=4743958 Ack=1741 Win=66048 Len=1444 TSval=2951472 TSecr=2921060 
    5190 28.060997 10.200.252.1   10.200.252.2   TCP  1510 search-agent > 58358 [ACK] Seq=4745402 Ack=1741 Win=66048 Len=1444 TSval=2951472 TSecr=2921060 
    5191 28.061000 10.200.252.1   10.200.252.2   TCP  1510 search-agent > 58358 [ACK] Seq=4746846 Ack=1741 Win=66048 Len=1444 TSval=2951472 TSecr=2921060 
    5192 28.061003 10.200.252.1   10.200.252.2   TCP  1510 search-agent > 58358 [ACK] Seq=4748290 Ack=1741 Win=66048 Len=1444 TSval=2951472 TSecr=2921060 
    5193 28.061007 10.200.252.1   10.200.252.2   TCP  1510 search-agent > 58358 [ACK] Seq=4749734 Ack=1741 Win=66048 Len=1444 TSval=2951472 TSecr=2921060 
    5194 28.061038 10.200.252.1   10.200.252.2   TCP  1510 search-agent > 58358 [ACK] Seq=4751178 Ack=1741 Win=66048 Len=1444 TSval=2951472 TSecr=2921060 
    5195 28.061042 10.200.252.1   10.200.252.2   TCP  572 search-agent > 58358 [PSH, ACK] Seq=4752622 Ack=1741 Win=66048 Len=506 TSval=2951472 TSecr=2921060 
**5196 28.068422 10.200.252.2   10.200.252.1   TCP  66  58358 > search-agent [ACK] Seq=1741 Ack=4742514 Win=64512 Len=0 TSval=2921061 TSecr=2951472 
**5197 28.078479 10.200.252.2   10.200.252.1   TCP  66  58358 > search-agent [ACK] Seq=1741 Ack=4753128 Win=64512 Len=0 TSval=2921062 TSecr=2951472 
    5198 28.082418 10.200.252.2   10.200.252.1   TCP  70  58358 > search-agent [PSH, ACK] Seq=1741 Ack=4753128 Win=64512 Len=4 TSval=2921062 TSecr=2951472 
    5199 28.082675 10.200.252.2   10.200.252.1   TCP  68  58358 > search-agent [PSH, ACK] Seq=1745 Ack=4753128 Win=64512 Len=2 TSval=2921062 TSecr=2951472 
    5200 28.082714 10.200.252.1   10.200.252.2   TCP  66  search-agent > 58358 [ACK] Seq=4753128 Ack=1747 Win=66048 Len=0 TSval=2951474

来源

2013-07-24 krusty

摆脱分块和应用的ACK干脆。如果必须的话，只需在文件末尾有一个最后一个。 TCP已经做了分块和确认，并且你正在把它搞疯了，例如它必须确认ACK。没有必要这么复杂。这是一个流媒体协议：像一个一样使用它。

来源

2013-07-24 22:29:59 EJP

该协议不是我的改变。我必须使用它 – krusty

即使它会大大提高所有平台的吞吐量？ – EJP

不幸的是。我无法访问服务器或协议。 – krusty

延迟10ms的TCP ACK响应

回答

相关问题