我用boost asio库编写了一个小程序，通过TCP将文件从服务器传输到一个或多个客户端。
在测试过程中，我发现转移非常慢，大约10KiB / s。 Nagle的算法已被禁用。如果我通过FileZilla将同一个文件从同一个服务器传输到同一个客户端，我的速度大约为280KiB / s，所以显然有些错误。
到目前为止，我的方法是将每个文件分段为1024字节的较小数据包，将一个片段（每个片段= 1 async_write-call）发送到客户端并等待客户端的响应。我需要对数据进行分段以允许客户端跟踪下载进度和速度。回想起来，我认为这是相当天真的，因为服务器必须在每个片段之后等待客户端的响应。为了检查这是否是瓶颈，我将片段大小增加了两倍，给出了以下结果：
a) Fragment Size: 1024bytes
Transfer Speed: ~10KiB/s
b) Fragment Size: 8192bytes
Transfer Speed: ~80KiB/s
c) Fragment Size: 20000bytes
Transfer Speed: ~195KiB/s
结果不言而喻，但我不确定现在该做什么。
我不太熟悉如何在内部实际处理数据传输，但如果我没有弄错，我的所有数据基本上都会添加到流中？如果是这种情况，我是否需要担心我一次写入该流的数据量？是否使用带有小片段的多个写调用而不是使用大片段进行一次写调用是否会有所不同？对此有什么指导吗？
答案 0 :(得分：1)
只需将数据流式传输到客户端，无需人工打包。重新启用nagling，这不是要求禁用它的场景。如果禁用它会导致效率低下。
典型的写缓冲区大小为4KB及以上。
客户端可以一个接一个地向网络发出读取呼叫。在每次成功阅读后，客户将对当前进度进行新估计，这是非常准确的。通常，对于接收的每个网络分组，将存在一个随后的读取呼叫。如果传入速率非常高，则多个数据包倾向于合并为一次读取。那不是问题。
如果是这种情况，我是否需要担心我一次写入该流的数据量？
没有。只需保持一个优秀的写入通话。