我在一家ISP公司工作。我们正在为客户开发速度测试仪，但遇到了TCP速度测试的一些问题。
一个客户端的总持续时间为102秒，传输100 MB，数据包大小为8192. 100.000.000 / 8192 = 12.202数据包。如果客户端每隔一个数据包发送一个ACK，这个数据似乎很多时候只是发送ACK。假设客户端发送6000个ACK并且RTT是15ms - 那就是6000 * 7.5 = 45.000ms = 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
这有效吗？
答案 0 :(得分：4)
这里的问题是RTT太大，以至于不使用整个带宽。您可能希望增加TCP窗口大小，这可以基于每个插槽进行测试，以及system-wide。
作为客户，如果速度测试程序通知我系统设置欠佳，并为我提供纠正它们的选项，我认为这是一项很棒的服务。
如果TCP窗口设置正确，RTT在TCP速度测试中无关紧要，除非您丢失了大量数据包（但毕竟这是您想要检测到的数据包）。
答案 1 :(得分：4)
TCP利用窗口流控制，通常在发送下一帧之前不等待ACK。 ACK与数据帧同时进行，不需要任何额外的挂钟时间。任何最近的TCP实现都可以在没有速度损失的情况下处理这样的RTT和比特率。
所以正确的计算是1号。
另外，您确定您的网络从客户的PC到测试服务器的确有8192 MTU吗？很可能存在具有1500 MTU的以太网段，并且您的8192字节发送缓冲区正被TCP堆栈拆分为标准的1500字节TCP段。
最后，有1024字节（千字节）和1024千字节（兆字节）。