我正在开发使用 Microsoft RPC(通过 TCP)作为通信方法的客户端-服务器软件。我们有时会将文件从客户端传输到服务器。这在本地网络中运行良好。不幸的是，当我们有高延迟时，即使是非常宽的带宽也无法提供像样的传输速度。
基于 WireShark 日志，RPC 层发送一堆片段，然后在发送更多片段之前等待来自服务器的 ACK，这会导致延迟主导传输时间。我正在寻找一种方法来告诉 RPC 在暂停之前发送更多数据包。
这个问题似乎与 TCP 窗口太小本质上是一样的，但这里可能有一个特定于 RPC 的片段窗口在起作用，因为 Wireshark 不会显示 TCP 级窗口已满。使用小窗口的 iPerf 连接测试确实会给出这些警告，并且速度类似于 RPC 传输。对于更大的窗口大小，iPerf 传输比 RPC 快三倍，即使延迟合理(40 毫秒)也是如此。
我确实在 Microsoft 的站点 (https://msdn.microsoft.com/en-us/library/gg604601.aspx) 和 RPC 文档(http://pubs.opengroup.org/onlinepubs/9629399/chap12.htm 搜索 window_size)中找到了一些关于 RPC 片段窗口的提及，但这些似乎只涉及无连接 (UDP) RPC。此外，他们提到了一个 RPC“fack”消息，我在日志中只观察到常规 TCP 级别的 ACK:s。
我的结论是，要么 RPC 层使用了一个愚蠢的低 TCP 窗口，要么它通过某种内部逻辑限制了它一次发送的片段包的数量。无论哪种方式，我都需要让它在 ACK 之间发送更多。有什么方法可以做到这一点吗？
我当然可以通过多个同时连接传输文件，但这看起来更像是一种变通方法而不是解决方案。
附言。我知道 RPC 并不是真正为文件传输而设计的，但这是一个遗留应用程序，RPC 管道处理身份验证和诸如此类的事情，因此最好将文件传输保留在那里，至少目前如此。
PPS。我想如果这个问题的答案是一个配置选项，这将更适合 SuperUser，但 API 设置将是理想的，这就是我在这里发布这个的原因。
最佳答案
我终于找到了控制它的方法。此 Microsoft 文档页面:Configuring Computers for RPC over HTTP包含设置 Windows RPC 使用的注册表设置，至少在与 RPC over HTTP 结合使用时是这样。
两个最相关的设置是:
HKLM\Software\Microsoft\Rpc\ClientReceiveWindow: DWORD
在客户端机器上提高这个值(一些 MB:s，以字节为单位)使得下载到客户端的速度更快。
HKLM\Software\Microsoft\Rpc\InProxyReceiveWindow: DWORD
在服务器机器上将其设置得更高可以使上传速度更快。
这些选项的缺点是它们是全局的。第一个将影响客户端计算机上的所有 RPC 客户端，而后者将影响服务器上的所有 RPC over HTTP 代理。这可能有严重的警告，但速度提高十倍也不容小觑。
不过，在每个连接的基础上设置这些会好得多。
关于windows - 如何提高高延迟网络上的 RPC 数据吞吐量，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34723960/