TcpClient 带宽估计答案

【问题标题】：TcpClient bandwidth estimationTcpClient 带宽估计
【发布时间】：2010-12-16 07:04:06
【问题描述】：

我想使用 TcpClient 创建带宽估算工具。我遇到的问题是，我想在预定义的时间内执行测量（而不是预定义要传输的缓冲区数据长度）。如果我使用循环（重复传输小块数据），会不会降低性能（手动分片与自动分片）？

【问题讨论】：

【解决方案1】：

这取决于您是否禁用 Nagle 算法。如果你这样做了，那么是的，你自己会分裂事物。如果你不这样做，你不太可能实现你的目标 - 因为当你认为数据可能实际上被写入时......除非连接的另一端发回一个 final "确认”当然。

我建议您使用一个较小的样本来计算粗略的速度，然后在此基础上创建一个更大的样本，预测需要多长时间。无论如何，您都需要测量时间 - 这不像您要达到准确预定义的时间 - 所以它不应该有太大的区别。无论如何，您始终可以在一定程度上调整大小 - 我预计您最终会发送大量数据包，除非它是一个非常慢的网络，所以如果您决定中途只发送 200K 而不是 300K，应该没什么区别。

当然，这可能听起来像您最初的建议 - 但我只是在谈论每次调用发送“相当大”的数据块......比如说 16K。（无论如何，比数据包的大小要大得多。）这不会对碎片产生太大影响，但仍然可以让您在进行过程中进行一些调整。我不建议你发送极小的数据包。

【讨论】：

请原谅我的提问，但我不太明白。如果我错了纠正我。如果我确实禁用了 nagle 算法，我必须通过重复发送小块数据来手动分割我的数据。如果我不禁用 nagle 算法，我的数据将自动分片。如果我不禁用 nagle 算法，我不太可能实现我的目标（带宽估计？），因为当我认为已收到发送的数据时，它可能实际上并未收到。这里有点困惑。
@publicENEMY：我应该澄清一下......如果你可以让连接的另一端在收到所有内容时给你一些价值 - 有效地使“ack”在应用程序级别可见 - 然后它没关系……就发送端的计算能力而言，效率略低，但与网络时序相比不太可能显着。
这里我认为 tcp 是可靠的（保证接收到正确的数据）。是说如果我禁用nagle，就不能保证接收到发送的数据？
@publicENEMY：可靠的是，当流启动时，您将正确且有序地获取数据。但是仅仅因为 TcpClient 上的“写入”已经返回并不意味着数据已经到达另一端。（事实上，不管你是否禁用 Nagle 算法都是如此。只是没有 Nagle，每个“写入”都会立即发送数据包。）
感谢 Jon Skeet 的澄清。非常感谢。