Um misterioso problema de velocidade de upload com o novo ISP (afetando o Win10 1607 e mais recente)


4

Alguns dias atrás eu mudei meu ISP (para T-mobile, porque atualmente é a única possibilidade). As velocidades estáveis ​​são: download de 150Mb / s, upload de ~ 34Mb / s.

Eu tentei carregar um único arquivo de 2GB para o meu VPS (usando SFTP) e notei um problema estranho com a velocidade de upload cai depois de alguns segundos. Isso significa que, para cerca de 20MB, ele é enviado com a velocidade máxima e, depois disso, apenas ~ 5Mb / s.

Como primeiro eu pensei que é um problema com o atual VPS, mas depois eu testei o upload para outros servidores com o mesmo efeito. No entanto, o upload para serviços como: YouTube, GoogleDrive, OneDrive, etc. sempre vai com a velocidade máxima (34Mb / s) sem problemas.

Eu estava testando este problema mais, usando scripts de upload php (em vez de SFTP), VPNs e sempre resultou em quedas de velocidade de upload (após um curto período de tempo). Eu pensei que este ISP limita a velocidade de upload para endereços "desconhecidos", mas então eu pedi um servidor Arubacloud e a velocidade de upload pelo SFTP estava ótima.

Depois disso, configurei o OpenVPN naquele VPS e conectei-o a partir do meu laptop. As velocidades de upload para este servidor da Aruba ainda estavam boas, mas não para outras. Sempre que eu tentei fazer upload de arquivos para o meu outro VPS, resultou em velocidade de upload no max. 5Mb / s. Fiquei muito confuso e duplamente verificado se a VPN é realmente usada.

Não encontrei nenhuma explicação lógica para isso e comecei a testá-lo em máquinas virtuais com o "adaptador de rede NAT" configurado (assim, meu endereço IP de host foi compartilhado). Fiquei surpreso ao ver que o upload de arquivos para todos os VPS que eu testei antes vai com a velocidade máxima, sem quedas de velocidade, sem usar qualquer VPN ...

Eu pensei que é um problema com algum software / serviço em execução no meu laptop. Eu inicializei o Windows 10 no modo de segurança com rede. Os mesmos problemas. Eu instalei uma cópia limpa do Windows 10 em outro disco rígido - os mesmos problemas de velocidade de upload ... É claro que o mesmo problema está presente quando uso uma conexão com fio (Ethernet). Também testei a conexão a dois roteadores diferentes (meu roteador principal e o roteador LTE da Huawei).

Quando mudei uma Máquina Virtual do Windows XP para usar uma conexão "Bridged" (em vez de NAT) - os mesmos problemas estavam acontecendo, portanto, provavelmente não é um problema do Windows 10.

Estou muito confuso e não sei como detectar o que causa esses problemas. Eu ficaria muito grato por quaisquer dicas e recomendações de teste.

Atualização 27.05.2018 17:10

Só para dar mais detalhes. Fiz mais testes: usei o cartão SIM do roteador LTE no smartphone e compartilhei a conexão à Internet pelo "hotspot móvel". O mesmo problema ocorre.

Eu também testei no laptop da minha mãe. O mesmo problema persiste.

Ele não afeta somente as transferências Filezilla (SFTP), mas o upload normal de arquivos por HTTP / HTTPS, o envio de arquivos pelo Riot Messenger (Matrix Client), etc. Eu também testei com uma VPN configurada para usar a porta 443.

Então, esse é realmente o problema do ISP, mas algo deve acioná-lo. Só para lembrar: Quando eu uso uma máquina virtual com adaptador de rede "NAT" - eu posso fazer upload de arquivos com velocidade total, sem diminuir.

É claro que testei a conexão com fio (Ethernet) mais de uma vez. Na verdade, não importa, porque eu recebo velocidades de upload de ~ 600Mb / s do meu NAS por Wi-Fi AC.

Atualização 28.05.2018 00:15

Eu detectei algo interessante:

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

Quando desativo o Autoajuste do Windows por " netsh int tcp defina global autotuninglevel = disabled " - as velocidades de upload são baixas durante todo o tempo (sem aumento de velocidade total no início). Configurando-o para " experimental " tem os mesmos efeitos que o padrão " normal ", isto é: cerca de 10-40MiB são carregados com a velocidade máxima, e então ele diminui drasticamente para 2-5Mb / s.

Alguém sabe o que isso pode significar?

Atualização 28.05.2018 23:55

Ontem eu instalei o Windows 8.1 em outro disco rígido. Parece que a velocidade de upload não está diminuindo. O auto-ajuste funciona bem.

Eu testei todas as versões possíveis do Windows 10 (instaladas no mesmo laptop) e obtive os seguintes resultados de teste:

  • A última versão onde o auto-ajuste funciona bem é: 1511 (10586).

  • A versão onde os problemas começaram é: 1607 (Atualização de aniversário).

Em 1511, ele funciona bem com os drivers padrão de Wi-Fi / Ethernet e também com os drivers mais novos possíveis.

Eu tentei definir as mesmas configurações de TCP na versão mais recente do Win10 usando um software chamado "TCP Optimizer". Infelizmente isso não ajuda.

Aqui estão as configurações do TCP Optimizer para as versões especificadas do Windows:

Win 8.1 (funciona bem): https://i.imgur.com/A8mLlrO.png e https://i.imgur.com/8KyNPam.png

Ganhe 10 (funciona bem): https://i.imgur.com/XbMSxTF.png e https://i.imgur.com/9la5Ydy.png

Ganhe 10 1511 (funciona bem): https://i.imgur.com/ta8sFlc.png e https://i.imgur.com/WuDm937.png

Ganhe 10 1607 (problemas): https://i.imgur.com/kVyaNfG.png e https://i.imgur.com/F4YLLEU.png

Ganhe 10 1703 (problemas): https://i.imgur.com/hO2iQF6.png e https://i.imgur.com/FNo0oyk.png

Ganhe 10 1709 (problemas) https://i.imgur.com/LAPcuAa.png e https://i.imgur.com/smy5v5R.png

Infelizmente, definir as mesmas opções (manualmente, não pelo recurso "importar") não ajuda. Talvez alguém saiba o que mudou na atualização de aniversário que poderia causar esses problemas?

Atualização 31.05.2018 16:05

A única solução para este problema que eu encontrei é usando uma máquina virtual Linux que usa o adaptador de rede "NAT" (compartilha o IP do host) + Kitty no Windows. Há minhas anotações, espero que seja compreensível o suficiente:

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

Então, basicamente, quando uma máquina virtual em execução no meu laptop canaliza o tráfego entre meu laptop e os servidores selecionados, recebo velocidades de upload completas (34Mb / s). Ele pára de funcionar quando eu mudo o Adaptador de Rede de Máquina Virtual para "Bridge", então ele deve estar em "NAT".

Respostas:


0

Lembre-se que velocidades de ISP em Mb / s [Megabit por segundo] enquanto a maioria das aplicações [FTP incluem] taxa velocidades em termos de MiB / s [Mebibyte por segundo], e desde 1 MiB = 8Mb seu '5MiB / s' é na verdade ' 40Mb / s '.
O pico inicial pode ser interperetewd como preenchimento de buffers locais.

Em termos de tempo, você deve ser capaz de fazer upload de 2 GiB em cerca de 7 minutos, se o tempo for comparável, sua conexão está bem.


Obrigado pela sua resposta. Quando o problema ocorre, posso ver como a velocidade diminui de 34Mbs para 5 ou menos no gerenciador de tarefas do Windows. Em seguida, leva cerca de 40 minutos para o arquivo 1.5GiB. Ao mesmo tempo, quando eu carrego o mesmo arquivo de um Vritual Machine que usa o adaptador de rede NAT - ele vai com velocidade total e leva apenas cerca de 5 minutos para carregá-lo.
Mona

Neste caso, eu diria que pode depender da configuração do seu cliente (pode haver um parâmetro como 'limite de velocidade de upload'), muito útil em conexões antigas (como ADSL) onde o uplink era realmente limitado
DDS

Não encontrei nenhum parâmetro de "limite de velocidade de upload" habilitado no Windows nem roteadores que eu usei. Além disso, se fosse o caso, eu não conseguiria obter a velocidade de upload completa para serviços como o YouTube, OneDrive. Como mencionei na minha pergunta, instalei um Windows 10 "fresco" em outro HDD e experimentei o mesmo problema.
Mona

Não é no Windows, é no software que você usa (suponho Filezilla ou similar). Você está testando sempre em ethernet ou você está em wifi. Se você testar em wi-fi, você simplesmente pode ser unluky e obter espectro 'ocupado', (do que você escreveu parece que você testou por fio apenas uma vez)
DDS

Eu atualizei minha pergunta com informações adicionais e novos testes que fiz. Basicamente, a velocidade de upload local (para o NAS ou outros dispositivos) é sempre em torno de 600Mb / s (Wi-Fi AC). O problema também acontece quando uso meu telefone como roteador e também afeta o laptop da minha mãe. Além disso, eu encontrei um servidor VPS que me dá uma velocidade de upload completa usando as mesmas configurações de software / ambiente. Portanto, é como o T-Mobile limita a velocidade apenas para endereços específicos e não o faz quando uso um laptop VirtualMachine -> NAT -> Host.
Mona

0

Consegui corrigir esse problema no lado do servidor.

Parece que atualizar o Ubuntu Server 16.04 para o 18.04 corrigiu esse problema para todos os meus VPS.

Então, basicamente, o Windows 10 1607+ tem problemas com o Ubuntu 16.04 / Debian 8 (e talvez mais antigos). Após a atualização do SO do servidor, o problema desapareceu. Isso explica por que mesmo as VPNs não ajudaram a resolver esse problema. Pena que eu notei isso tão tarde, teria economizado muito tempo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.