我正在使用Microsoft RPC（通过TCP）作为通信方法的客户端 - 服务器软件。我们有时会将文件从客户端传输到服务器。这在本地网络中工作正常。不幸的是，当我们具有高延迟时，即使是非常宽的带宽也不能提供合适的传输速度。
基于WireShark日志，RPC层发送一堆片段，然后在发送更多内容之前等待来自服务器的ACK，这会导致延迟占据传输时间。我正在寻找一种方法告诉RPC在暂停之前发送更多数据包。
这个问题似乎与TCP窗口太小有关，但是这里可能有一个特定于RPC的片段窗口，因为Wireshark没有显示TCP级窗口已满。使用小窗口的iPerf连接测试确实提供了这些警告，并且速度与RPC传输类似。使用更大的窗口大小，即使在合理的（40毫秒）延迟时间内，iPerf传输也比RPC快三倍。
我确实在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：
我的结论是，RPC层使用的是一个愚蠢的低TCP窗口，或者它限制了一些内部逻辑一次发送的片段包的数量。无论哪种方式，我需要让它在ACK之间发送更多。有没有办法做到这一点？
我当然可以通过多个同时连接传输文件，但这看起来更像是解决方案而不是解决方案。
PS。我知道RPC并不是真正设计用于文件传输，但这是一个遗留应用程序，RPC管道处理身份验证等等，所以保持文件传输最好，至少目前是这样。
PPS。我想如果这个问题的答案是一个配置选项，这将更适合SuperUser，但API设置将是理想的，这就是我在这里发布的原因。
答案 0 :(得分：1)
我终于找到了控制它的方法。此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代理。这可能有一些严重的警告，但速度增加十倍也无可畏惧。
但是，在每个连接的基础上设置这些会更好。