4

Несколько дней назад я сменил провайдера (на T-mobile, потому что это единственная возможность). Стабильные скорости: загрузка 150 Мбит / с, загрузка ~ 34 Мбит / с.

Я попытался загрузить один файл размером 2 ГБ в VPS (используя SFTP), и через несколько секунд я заметил странную проблему с падением скорости загрузки. Это означает: около 20 МБ загружается с полной скоростью, а после этого всего ~ 5 Мбит / с.

Сначала я думал, что это проблема с текущим VPS, но затем я протестировал загрузку на другие серверы с тем же эффектом. Однако загрузка на такие сервисы, как YouTube, GoogleDrive, OneDrive и т.д., Всегда идет на полной скорости (34 Мбит / с) без каких-либо проблем.

Я больше тестировал эту проблему, используя сценарии загрузки php (вместо SFTP), VPN, и это всегда приводило к падению скорости загрузки (через очень короткое время). Я думал, что этот провайдер ограничивает скорость загрузки до "неизвестных" адресов, но затем я заказал сервер Arubacloud, и скорость загрузки по SFTP была просто отличной.

После этого я настроил OpenVPN на этом VPS и подключился к нему со своего ноутбука. Скорости загрузки на этот сервер Арубы все еще были хорошими, но не для других. Всякий раз, когда я пытался загрузить файл на другой VPS, это приводило к максимальной скорости загрузки. 5Mb/ с. Я был очень смущен и дважды проверил, действительно ли используется VPN.

Я не нашел логического объяснения, почему это происходит, и я начал тестировать его на виртуальных машинах с настроенным "Сетевым адаптером NAT" (поэтому мой IP-адрес хоста был общим). Я был удивлен, увидев, что загрузка файлов на все VPS, которые я тестировал ранее, идет на полной скорости, без каких-либо падений скорости, без использования VPN ...

Я думал, что это проблема с некоторым программным обеспечением / сервисом, работающим на моем ноутбуке. Я загрузил Windows 10 в безопасном режиме с сетью. Те же проблемы Я установил чистую копию Windows 10 на другой жесткий диск - те же проблемы со скоростью загрузки ... Конечно, та же проблема присутствует, когда я использую проводное соединение (Ethernet). Я также проверил подключение к 2 различным маршрутизаторам (мой основной маршрутизатор и маршрутизатор LTE от Huawei).

Когда я изменил виртуальную машину Windows XP на использование "мостового" соединения (вместо NAT) - возникали те же проблемы, поэтому, скорее всего, это не проблема Windows 10.

Я очень смущен и не знаю, как определить причины этих проблем. Буду очень признателен за любые советы и рекомендации по тестированию.

Обновление 27.05.2018 17:10

Просто чтобы дать больше деталей. Я сделал больше тестов: я использовал SIM-карту от LTE-роутера в своем смартфоне и использовал подключение к Интернету через "мобильную точку доступа". Та же проблема возникает.

Я также проверил на ноутбуке моей мамы. Та же проблема сохраняется.

Это влияет не только на передачу Filezilla (SFTP), но и на обычную загрузку файлов по HTTP/HTTPS, отправку файлов через Riot Messenger (клиент Matrix) и т.д. Я также тестировал VPN, настроенный для использования порта 443.

Так что это на самом деле проблема провайдера, но что-то должно спровоцировать это. Напоминаю: когда я использую виртуальную машину с сетевым адаптером "NAT" - я могу загружать файлы с полной скоростью, без уменьшения.

Конечно, я тестировал проводное (Ethernet) соединение более 1 раза. На самом деле это не должно иметь значения, потому что я получаю скорость загрузки ~ 600 Мбит / с со своего NAS через Wi-Fi AC.

Обновление 28.05.2018 00:15

Я обнаружил что-то интересное:

netsh int tcp show global:
Receive Window Auto-Tuning Level    : normal

Когда я отключаю автонастройку окна с помощью « netsh int tcp set global autotuninglevel = disabled » - скорость загрузки все время низкая (без повышения полной скорости при запуске). Установка его на « экспериментальный » имеет те же эффекты, что и « нормальный » по умолчанию: примерно 10-40 МБ загружаются с полной скоростью, а затем он резко уменьшается до 2-5 Мбит / с.

Кто-нибудь знает, что это может значить?

Обновление 28.05.2018 23:55

Вчера я установил Windows 8.1 на другой жесткий диск. Похоже, что скорость загрузки не уменьшается. Автонастройка работает отлично.

Я протестировал все возможные версии Windows 10 (установленные на том же ноутбуке) и получил следующие результаты:

  • Последняя версия, где автонастройка работает нормально: 1511 (10586).

  • Версия, где начались проблемы: 1607 (Anniversary Update).

На 1511 он работает нормально с драйверами Wi-Fi/Ethernet по умолчанию, а также с новейшими возможными драйверами.

Я попытался установить те же настройки TCP в новейшей версии Win10, используя программное обеспечение под названием "TCP Optimizer". К сожалению, это не помогает.

Вот настройки оптимизатора TCP для указанных версий Windows:

Win 8.1 (работает нормально): https://i.imgur.com/A8mLlrO.png и https://i.imgur.com/8KyNPam.png

Win 10 (работает нормально): https://i.imgur.com/XbMSxTF.png и https://i.imgur.com/9la5Ydy.png

Win 10 1511 (работает нормально): https://i.imgur.com/ta8sFlc.png и https://i.imgur.com/WuDm937.png

Win 10 1607 (проблемы): https://i.imgur.com/kVyaNfG.png и https://i.imgur.com/F4YLLEU.png

Win 10 1703 (проблемы): https://i.imgur.com/hO2iQF6.png и https://i.imgur.com/FNo0oyk.png

Win 10 1709 (проблемы) https://i.imgur.com/LAPcuAa.png и https://i.imgur.com/smy5v5R.png

К сожалению, установка тех же параметров (вручную, а не с помощью функции "импорт") не помогает. Может быть, кто-то знает, что изменилось в Anniversary Update, что может вызвать эти проблемы?

Обновление 31.05.2018 16:05

Единственное решение этой проблемы, которое я обнаружил, - использование виртуальной машины Linux, которая использует сетевой адаптер "NAT" (совместно использует IP-адрес хоста) + Kitty в Windows. Есть мои заметки, надеюсь, это будет достаточно понятно:

Virtual Machine Local IP: 192.168.32.132
apt-get install sshpass autossh screen
nano /etc/ssh/sshd_config:
Port 777
service ssh restart

Kitty settings:
Name - > LinuxVM-Tunnel-SpeedFix (port 777 if 22 doesn't work)
Connection -> keepalives -> 30
Connection -> Data -> Autologin username/password
SSH -> Tunnels:
- Source port: 7771 Destination: localhost:8881 | Server1
- Source port: 7772 Destination: localhost:8882 | Server2
- Source port: 7773 Destination: localhost:8883 | Unused
- Source port: 7774 Destination: localhost:8884 | Unused

Connection -> Data login/pass
Connection -> Data -> Command:
screen -X -S VMTunnel1 quit; screen -X -S VMTunnel2 quit; screen -X -S VMTunnel3 quit; screen -X -S VMTunnel4 quit; screen -S VMTunnel1 -dm sshpass -p 'MyPassword' autossh -oStrictHostKeyChecking=no -L 8881:127.0.0.1:22 root@server1.example.com; screen -S VMTunnel2 -dm sshpass -p 'MyPassword' autossh -oStrictHostKeyChecking=no -L 8882:127.0.0.1:22 root@server2.example.com;

Filezilla:
Profile: LinuxVM-server1.example.com | 127.0.0.1 | 7771
Profile: LinuxVM-server2.example.com | 127.0.0.1 | 7772

В общем, когда виртуальная машина, работающая на моем ноутбуке, туннелирует трафик между моим ноутбуком и выбранными серверами, я получаю полную скорость загрузки (34 Мбит / с). Он перестает работать, когда я меняю сетевой адаптер виртуальной машины на "Мост", поэтому он должен быть на "NAT".

2 ответа2

0

Помните, что скорость интернет-провайдера в мегабитах в секунду [Мегабит в секунду], в то время как в большинстве приложений [FTP включен] скорость в мегабитах в секунду [Мегабайт в секунду], и, поскольку 1 МБ = 8 МБ, ваши «5 МБ / с» фактически 40Mb / s.
Начальный пик может быть интерпретирован как заполнение локальных буферов.

В терминах «время» вы должны быть в состоянии загрузить 2 ГиБ примерно за 7 минут, если время сопоставимо, ваше соединение в порядке.

0

Мне удалось решить эту проблему на стороне сервера.

Похоже, что обновление Ubuntu Server 16.04 до 18.04 исправило эту проблему для всех моих VPS.

Таким образом, в основном Windows 10 1607+ имеет проблемы с Ubuntu 16.04 / Debian 9 (и, возможно, старше). После обновления ОС сервера проблема исчезла. Это объясняет, почему даже VPN не помогли решить эту проблему. Жаль, что я заметил это так поздно, сэкономил бы много времени.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .