如何提高高延迟网络上的 RPC 数据吞吐量
How to improve RPC data throughput over high latency network
我正在开发使用 Microsoft RPC（通过 TCP）作为通信方法的客户端-服务器软件。我们有时会将文件从客户端传输到服务器。这在本地网络中运行良好。不幸的是，当我们有高延迟时，即使是非常宽的带宽也无法提供像样的传输速度。
基于 WireShark 日志，RPC 层发送一堆片段，然后在发送更多片段之前等待来自服务器的 ACK，这导致延迟主导传输时间。我正在寻找一种方法来告诉 RPC 在暂停之前发送更多数据包。
这个问题似乎与太小的 TCP window 基本相同，但这里可能有一个特定于 RPC 的片段 window，因为 Wireshark 不显示 TCP-级别 window 已满。带有小 window 的 iPerf 连接测试确实会给出这些警告，并且速度类似于 RPC 传输。对于更大的 windows 大小，iPerf 传输比 RPC 快三倍，即使延迟合理（40 毫秒）也是如此。
我确实在 Microsoft 的站点（https://msdn.microsoft.com/en-us/library/gg604601.aspx) and in an RPC document (http://pubs.opengroup.org/onlinepubs/9629399/chap12.htm 搜索 window_size）找到了一些关于 RPC 片段 window 的提及，但这些似乎只涉及无连接 (UDP) RPC。此外，他们提到了一条 RPC "fack" 消息，我在日志中只观察到常规 TCP 级别 ACK:s。
我的结论是，要么 RPC 层使用了低得愚蠢的 TCP window，要么它通过某些内部逻辑限制了它一次发送的片段包的数量。无论哪种方式，我都需要让它在 ACK 之间发送更多。有什么办法吗？
我当然可以通过多个同时连接传输文件，但这看起来更像是一种变通方法而不是解决方案。
PS。我知道 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 代理。这可能有严重的警告，但十倍的速度提升也不容小觑。
不过，在每个连接的基础上设置这些会好得多。
我正在开发使用 Microsoft RPC（通过 TCP）作为通信方法的客户端-服务器软件。我们有时会将文件从客户端传输到服务器。这在本地网络中运行良好。不幸的是，当我们有高延迟时，即使是非常宽的带宽也无法提供像样的传输速度。
基于 WireShark 日志，RPC 层发送一堆片段，然后在发送更多片段之前等待来自服务器的 ACK，这导致延迟主导传输时间。我正在寻找一种方法来告诉 RPC 在暂停之前发送更多数据包。
这个问题似乎与太小的 TCP window 基本相同，但这里可能有一个特定于 RPC 的片段 window，因为 Wireshark 不显示 TCP-级别 window 已满。带有小 window 的 iPerf 连接测试确实会给出这些警告，并且速度类似于 RPC 传输。对于更大的 windows 大小，iPerf 传输比 RPC 快三倍，即使延迟合理（40 毫秒）也是如此。
我确实在 Microsoft 的站点（https://msdn.microsoft.com/en-us/library/gg604601.aspx) and in an RPC document (http://pubs.opengroup.org/onlinepubs/9629399/chap12.htm 搜索 window_size）找到了一些关于 RPC 片段 window 的提及，但这些似乎只涉及无连接 (UDP) RPC。此外，他们提到了一条 RPC "fack" 消息，我在日志中只观察到常规 TCP 级别 ACK:s。
我的结论是，要么 RPC 层使用了低得愚蠢的 TCP window，要么它通过某些内部逻辑限制了它一次发送的片段包的数量。无论哪种方式，我都需要让它在 ACK 之间发送更多。有什么办法吗？
我当然可以通过多个同时连接传输文件，但这看起来更像是一种变通方法而不是解决方案。
PS。我知道 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 代理。这可能有严重的警告，但十倍的速度提升也不容小觑。
不过，在每个连接的基础上设置这些会好得多。