Вопрос об алгоритме тестера скорости TCP

Question

Я работаю в интернет-провайдере.Мы разрабатываем тестер скорости для наших клиентов, но сталкиваемся с некоторыми проблемами, связанными с тестированием скорости TCP.

Один клиент имел общую длительность 102 секунды, передавая 100 МБ с размером пакета 8192. 100.000.000 /8192 = 12,202 пакета.Если клиент отправляет ACK, каждый второй пакет, который кажется довольно продолжительным, просто передает ACK.Скажем, клиент отправляет 6000 ACK, а RTT составляет 15 мс - это 6000 * 7,5 = 45.000 мс = 45 секунд только для ACK?

Если я использую этот расчет для Мбит / с:

(((sizeof_download_in_bytes / durationinseconds) /1000) /1000) * 8 = Mbp/s

Я получу результат в Мбит / с, но чем выше TTL между отправителем и клиентом, тем ниже будет скорость Мбит / с.

Чтобы смоделировать, что пользователь ближе ксервер, было бы «законно» удалить время ответа ACK в конечном результате в Мбит / с?Это было бы похоже на симуляцию того, что конечный пользователь находится близко к серверу?

Таким образом, я бы отобразил этот расчет для конечного пользователя:

(((sizeof_download_in_bytes / (durationinseconds - 45sec)) /1000)/1000) * 8 = Mbp/s 

Это действительно?

Answer 1

TCP использует управление потоком окон и обычно не ожидает ACK перед отправкой следующего кадра. ACK идут одновременно с фреймами данных и не требуют дополнительного времени на настенных часах. Любая недавняя реализация TCP может обрабатывать такие RTT и битрейт без потери скорости.

Так что правильный расчет - это номер 1.

Кроме того, вы уверены, что ваша сеть действительно имеет 8192 MTU от ПК клиента до вашего тестового сервера? Весьма вероятно, что где-то существует сегмент Ethernet с 1500 MTU, и ваши буферы отправки 8192 байта разделяются по стеку TCP на стандартные сегменты TCP 1500 байт.

И, наконец, 1024 байта в килобайтах и ​​1024 килобайта в мегабайтах.

Answer 2

Проблема здесь в том, что RTT слишком велик, так что используется не вся полоса пропускания. Возможно, вы захотите увеличить размер окна TCP, что можно сделать для каждого сокета в целях тестирования, а также для всей системы .

Как клиент, я бы посчитал отличным сервисом, если бы программа скоростного тестирования уведомляла меня о неоптимальных настройках системы и предлагала мне возможность их исправить.

Если настройки окна TCP правильные, RTT не должен иметь значения в тесте скорости TCP, если только вы не теряете значительное количество пакетов (но в конце концов это то, что вы хотите обнаружить в первую очередь).