我在 ISP 公司工作。我们正在为我们的客户开发速度测试器，但在 TCP 速度测试方面遇到了一些问题。
一个客户端的总持续时间为 102 秒，传输 100 MB 数据包大小为 8192。100.000.000/8192 = 12.202 个数据包。如果客户端每隔一个数据包发送一个 ACK，这似乎需要很多时间来传输 ACK。假设客户端发送 6000 个 ACK，RTT 为 15 毫秒 - 即 6000 * 7.5 = 45.000 毫秒 = 45 秒仅用于 ACK？
如果我对 Mbit/s 使用此计算:
(((sizeof_download_in_bytes / durationinseconds) /1000) /1000) * 8 = Mbp/s
我将得到以 Mbp/s 为单位的结果，但是发送方和客户端之间的 TTL 越高，Mbp/s 速度就会变得越低。
为了模拟用户离服务器更近，在Mbp/s上去掉最终结果中的ACK响应时间是否“合法”？这就像模拟最终用户靠近服务器一样？
所以我会向最终用户显示此计算:
(((sizeof_download_in_bytes / (durationinseconds - 45sec)) /1000)/1000) * 8 = Mbp/s
这有效吗？
最佳答案
这里的问题是 RTT 太大，以至于没有使用整个带宽。您可能想要增加 TCP 窗口大小，这可以在每个套接字的基础上完成以进行测试，以及 system-wide .
作为客户，如果速度测试程序能够通知我系统设置不理想并为我提供更正选项，我会认为这是一项很棒的服务。
如果 TCP 窗口设置正确，RTT 在 TCP 速度测试中应该无关紧要，除非您丢失了大量数据包(但毕竟这是您首先要检测的)。
关于c# - TCP speed tester 算法题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4923084/