Почему расхождение между Speedtest и Wget?
Мой клиент жалуется на низкую скорость интернета. При измерении с помощью Speedtest.net скорости приемлемы. Периодические измеряемые загрузки составляют от 10% до 30% от номинальной скорости. Я не могу этого объяснить.
Немного предыстории. Проблемная связь находится на одном из тех солнечных Карибских островов, где быстрый интернет не является главным преимуществом. В последнее время скорость интернета стала приличной, до 200 Мбит / с. Но ping туда и обратно до (скажем) Амстердама составляет около 180 мс.
У клиента есть оптоволоконное соединение со скоростью 100 Мбит / с. При проведении спидтеста на машине Windows (speedtest.net) к ISP CO мы получаем 95 Мбит / с. При использовании того же теста скорости до Амстердама достигаем 60-70 Мбит / с. Вполне приемлемо.
Некоторое время назад я установил RasPi, который периодически получает файл с одного из моих серверов в Амстердаме. В центре обработки данных, который напрямую подключен к AMS-IX. Используя эту команду:
wget -O /dev/null --report-speed=bits http://aserv.example.net/~myuser/links/M77232917.txt
Файл .txt содержит 23 Мбайта чисел. (На самом деле это одно, но наибольшее число Мерсенна, 23e6 цифр)
Когда я загружаю этот файл в проблемную сеть, wget сообщает следующее:
dev/null 100%[====================================================================>] 22.81M 11.6Mb/s in 17s
2019-02-08 14:27:55 (11.2 Mb/s) - ‘/dev/null’ saved [23923322/23923322]
То есть в то же время speedtest.net сообщает о 60-70 Мбит / с.
Я знаю, что у Raspi есть свои ограничения. Но эта скорость сильно разнится. Один раз RasPi сообщает об этом 11 Мбит / с, в следующий раз 22 Мбит / с. Но иногда всего 1,5 Мбит / с.
Когда я провожу этот тест на действительно мощном ноутбуке, максимальные скорости несколько выше (до 30 Мбит / с), но также показывают те же минимумы. Таким образом, это указывает на ограничение RasPi на высокой стороне, но не на 10 Мбит / с на нижней стороне.
Я выдал точно такую же команду с сервера в Мюнхене, Германия, в центре обработки данных. Скорость 96 Мбит / с.
Затем от потребителя оптоволоконное соединение 100 Мбит / с в Нидерландах: 65 Мбит / с.
Затем у меня дома, у которого есть номинальная ADSL 10 Мбит / с. Speedtest показывает 10 Мбит / с. Wget дает 8,5 Мбит / с. Что равно в моей книге.
Это исключает любые ограничения на сервере, который действует как хост для загрузки файла.
Я не думаю, что кто-то сможет указать на причину медленного соединения на территории клиента. Но может ли кто-нибудь объяснить несоответствие между speedtest.net и wget?
Спидтест что-то игнорирует или измеряет только пики? Или на wget серьезно влияет долгое время пинга?
Я чувствую, что тест wget дает реальную эффективную скорость, а тест скорости в основном показывает заявленную скорость.
Интернет-провайдеры часто отдают приоритет трафику на speedtest.net, чтобы можно было похвастаться скоростью своего соединения, хотя на самом деле они не обеспечивают такой большой пропускной способности. Они прекрасно понимают, что большинство пользователей проверят этот сайт только для подтверждения.
Вы также должны помнить, что скорость передачи зависит как от клиента. и сервер. В современном мире большинство серверов тем или иным образом ограничены.
Наконец, бессмысленно ожидать стабильной пропускной способности для зарубежных соединений. Такого просто нет. Ему нужно пройти через бесконечное количество коммутаторов, волоконно-оптических линий и центров обработки данных, чтобы достичь конечного местоположения. И все, что нужно, это просто один движущаяся часть для замедления.
В дополнение к другим указанным причинам TCP-соединения не работают с большими файлами, когда продукт задержки полосы пропускания становится большим.
Как в противном случае быстрое соединение с островом.
Видеть Запись в Википедии о настройке TCP.
Таким образом, Speedtest может выгружать небольшой файл через соединение со скоростью 95 Мб / сек, но wget может получить только 10 МБ / с для файла размером 20 МБ.
wget дать хорошее практическое представление о скорости. Тесты Speedtest, вероятно, включают своего рода параллелизм, который может объяснить более высокие числа.
Я думаю, что для хорошего теста средней скорости время загрузки должно быть не менее 90-120 секунд (чтобы получить хорошее среднее значение)
Одна из причин может заключаться в том, что часто максимальная скорость не может быть достигнута только одним TCP-соединением.
Speedtest.net недавно представил режим одиночного подключения. Попробуйте это и посмотрите, имеет ли это значение.
Затем для загрузки используйте например ария2 с параметрами для использования нескольких соединений и сравнения. например aria2c -d /dev -o null --allow-overwrite=true --file-allocation=none --max-connection-per-server=8 --min-split-size=1M http://aserv.example.net/~myuser/links/M77232917.txt
Использовать Тест скорости Интернета Fast.com, это тест скорости на основе Netflix, что означает, что интернет-провайдеры не могут отличить его от самого Netflix.
Это более точный тест, чем любой другой тест в целом. Люди будут беспокоиться не о том, как быстро загружается веб-страница, а о том, как быстро буферизируется видео из-за увеличения пропускной способности, необходимой для отображения видео.
Интернет-провайдеры часто повышают скорость в зависимости от домена, к которому кто-то подключается, если это тест скорости или порт 8080. В то время как Netflix использует порт 80, более медленный порт, когда он получает приоритет.
Это только я или никто не заметил, что он сказал Мбит / с и список команд wget «МБ / с».
60 Мбит / с, а фактическое получение 11,2 Мбайт - это нормально.
Мбит / с и МБ / с - две разные скорости.
«Мегабит составляет 1/8 от мегабайта, а это означает, что для загрузки файла размером 1 МБ за 1 секунду вам потребуется соединение со скоростью 8 Мбит / с». Итак, 11mbx8 = 88mbps ... 11,2 МБ на самом деле хорошо для отчета о подключении 60-70 Мбит / с.
Люди, имеющие память, теряют ясность в этом. Вы никогда не получите 70 Мбит / с при максимальной скорости 70 Мбит / с