TCP速度測試器算法問題

Question

我在ISP公司工作。我們正在爲我們的客戶開發速度測試儀，但遇到了有關TCP速度測試的一些問題。

一個客戶端總共持續了102秒，傳輸100 MB的數據包大小爲8192. 100.000.000/8192 = 12.202個數據包。如果客戶端每隔一個數據包就發送一個ACK，這似乎很多時候只是發送ACK。假設客戶端發送6000個ACK並且RTT爲15ms--這對於ACK來說是6000 * 7.5 = 45.000ms = 45秒？

如果我用這個計算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 

是不是有效？

Answer 1

這裏的問題是RTT太大，所以不能使用整個帶寬。您可能需要增加TCP窗口大小，以便進行測試，並且可以在每個插座上完成，以及system-wide。

作爲一個客戶，如果一個速度測試程序告訴我次優系統設置併爲我提供一個糾正它們的選項，我認爲它是一項很棒的服務。

如果TCP窗口設置是正確的，那麼在TCP速度測試中RTT應該不重要，除非丟失了大量數據包（但畢竟這是您首先要檢測的內容）。

Answer 2

TCP利用窗口流量控制，通常在發送下一幀之前不等待ACK。 ACK與數據幀同時進行，不需要額外的掛鐘時間。任何最近的TCP實現都可以在不丟失速度的情況下處理這種RTT和比特率。

所以，正確的計算是1號。

此外，你確保你的網絡真有8192 MTU從客戶的PC到測試服務器？很可能在某處存在1500 MTU的以太網段，並且您的8192字節發送緩衝區正在被TCP堆棧拆分爲標準的1500字節TCP段。

最後，有千字節的1024字節和兆字節的1024千字節。