我正在使用Microsoft RPC（通過TCP）作爲通信方法的客戶端服務器軟件上工作。我們有時會將文件從客戶端傳輸到服務器。這在本地網絡中正常工作。不幸的是，當我們有很高的延遲時間時，即使是非常寬的帶寬也不能提供良好的傳輸速度。如何提高高延遲網絡上的RPC數據吞吐量
基於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。
我的結論是RPC層使用的是一個愚蠢的低TCP窗口，或者它限制了它一次由某些內部邏輯發送的片段包的數量。無論哪種方式，我需要使它在ACK之間發送更多。有沒有辦法做到這一點？
我當然可以通過多個同時連接傳輸文件，但這似乎更像是一種解決方案而不是解決方案。
PS。我知道RPC並不是真正爲文件傳輸設計的，但這是一個遺留應用程序，RPC管道處理身份驗證和其他事情，所以保持文件傳輸將是最好的，至少現在是這樣。
PPS。我想，如果這個問題的答案是一個配置選項，這將更適合超級用戶，但API設置將是理想的，這就是爲什麼我在這裏發佈這個。