我用BoostASIO库编写了一个小程序，通过TCP将文件从服务器传输到一个或多个客户机。
在测试过程中，我发现传输速度非常慢，大约为10kib/s。Nagle的算法已经被禁用。如果我通过filezilla将同一个文件从同一个服务器传输到同一个客户机，我会得到大约280kib/s，所以很明显是出了什么问题。
到目前为止，我的方法是将每个文件分成1024字节的小数据包，向客户机发送一个片段（每个片段=1个异步写调用），然后等待客户机的响应。我需要对数据进行分段，以便客户端能够跟踪下载进度和速度。回想起来，我认为这是相当幼稚的，因为服务器必须在每个片段之后等待客户机的响应。为了检查这是否是瓶颈，我将片段大小增加了两次，得到了以下结果：
a) Fragment Size: 1024bytes
Transfer Speed: ~10KiB/s
b) Fragment Size: 8192bytes
Transfer Speed: ~80KiB/s
c) Fragment Size: 20000bytes
Transfer Speed: ~195KiB/s
结果不言而喻，但我不知道现在该怎么办。
我不太熟悉如何在内部处理数据传输，但如果我没有弄错的话，我的所有数据基本上都添加到流中了？如果是这样的话，我是否需要担心我一次要向该流写入多少数据？如果我使用多个带小片段的写调用，而不是一个带大片段的写调用，这有什么区别吗？有什么指导方针吗？
最佳答案
只需将数据流式传输到客户机，而不需要人工打包。重新启用Nagling，这不是需要禁用它的场景。禁用它会导致很小的效率低下。
典型的写缓冲区大小为4KB及以上。
客户端可以一个接一个地向网络发出读取调用。每次成功读取后，客户机都会对当前进度有一个非常准确的新估计。通常，对于接收到的每个网络包，都会有一个后续的读调用。如果传入速率非常高，那么多个数据包往往合并为一个读取。那不是美联社的问题。
如果是这样的话，我是否需要担心我一次向该流写入了多少数据？
不，只要一直保持一个写呼叫。