A distância física afeta a velocidade do download?


22

Acabei de discutir com um colega meu e pensei em entrar em contato com os especialistas. Aqui está o cenário. Estávamos usando um site que mede a velocidade da sua conexão. Testamos usando um servidor que está longe de nós (estamos na Malásia e o servidor nos EUA). Foi em torno de 2 Mbps. Então tentamos com um servidor em Cingapura e foi muito mais rápido (cerca de 15 Mbps). Meu colega acreditava que é por causa da distância física, enquanto eu acho que não importa. Pelo que entendi, depois de fazer o handshake inicial e o fluxo de dados ter iniciado, não importa onde o servidor está localizado e o resultado deve ser quase o mesmo. Estou faltando alguma coisa aqui? Como isso realmente funciona?


2
Você pode confirmar isso sozinho. Faça ping no servidor para adquirir latência. Em seguida, 2 Mbps * Latência == Janela. Você pode confirmar o tamanho real da janela com o wireshark. Mas vamos supor que você não tenha a janela dimensionada, então é 64kB / 2Mbps = 256ms, então eu prevejo que seu servidor esteja a 256ms de distância.
ytti

2
O @ytti está descrevendo indiretamente o BDP (produto de retardo de largura de banda) que se traduz em redes longas (de retardo), gordas (largura de banda), sendo mais difícil manter a integridade e reduzir o consumo potencial. Consulte en.wikipedia.org/wiki/Bandwidth-delay_product .
generalnetworkerror

2
@ytti, Windows Vista e posterior têm a escala de janela por padrão ... nós precisamos saber o que OS Navid está usando para o teste
Mike Pennington

De acordo com este suporte.microsoft.com/kb/934430, a escala (fator 8) é padrão no Vista, mas apenas para não-HTTP. Eu não sou usuário do Windows, então não posso verificar.
ytti

2
@ytti, não sei se isso é relevante. Eu corro Vista, e eu estou olhando para uma fungada da minha conexão HTTP para que o apoio página, eo TCP SYN diz: "Escala Janela: 2 (multiplique por um factor de 4)"
Mike Pennington

Respostas:


23

Meu colega acreditava que é por causa da distância física, enquanto eu acho que não importa. Pelo que entendi, depois de fazer o handshake inicial e o fluxo de dados ter iniciado, não importa onde o servidor está localizado e o resultado deve ser quase o mesmo. Estou faltando alguma coisa aqui? Como isso realmente funciona?

Vocês dois estavam certos em algum momento da história, mas sua compreensão está correta ... hoje :). Existem alguns fatores que mudaram entre a resposta mais antiga que seu amigo deu e os recursos que temos hoje.

  • Escala de janela TCP
  • Ajuste do buffer do host

A diferença nos resultados que você viu pode ter sido afetada por:

  • Perda de pacotes
  • Transferências TCP paralelas

Escala de janela TCP: O efeito de atraso de largura de banda

Como seu amigo mencionou, implementações mais antigas do TCP sofreram com os limites impostos pelo tamanho original da janela de recebimento de 16 bits no cabeçalho do TCP (ref RFC 793: Seção 3.1 ); O RWIN controla a quantidade de dados não reconhecidos que podem estar aguardando em um único soquete TCP. O RWIN de 16 bits valoriza caminhos de Internet limitados com produtos com alto atraso de largura de banda (e muitas das conexões de Internet de alta largura de banda atuais seriam limitadas por um valor de 16 bits).

Para valores altos de RTT, é útil ter um RWIN muito grande. Por exemplo, se o seu caminho RTT da Malásia para os EUA for de cerca de 200 ms, o TCP RWIN original o limitaria a 2,6 Mbps.

Rendimento máximo = Rcv_Win / RTT

* Taxa de transferência máxima = 65535 * 8 / 0,200 *

Rendimento máximo = 2,6 Mbps

A RFC 1323 definiu algumas "Opções TCP" para superar essas limitações; uma dessas opções de TCP é "redimensionamento de janelas". Ele introduz um fator de escala, que multiplica o valor RWIN original, para obter o valor total da janela de recebimento; o uso de opções de dimensionamento de janela permite um RWIN máximo de 1073725440 bytes. Aplicando os mesmos cálculos:

Rendimento máximo = Rcv_Win / RTT

* Taxa de transferência máxima = 1073725440 * 8 / 0,200 *

Rendimento máximo = 42,96Gbps

Lembre-se de que o TCP aumenta o RWIN gradualmente durante a transferência, desde que a perda de pacotes não seja um problema. Para ver taxas de transferência realmente grandes em uma conexão de alto atraso, é necessário transferir um arquivo grande (para que o TCP tenha tempo de aumentar a janela) e a perda de pacotes não pode ser um problema para a conexão.

Perda de pacotes

Os circuitos da Internet no Oceano Pacífico às vezes ficam bastante congestionados. Parte da minha família mora em Taiwan, e costumamos ter problemas quando usamos o Google Talk com eles. Frequentemente vejo perda de pacotes acima de 0,5% quando sigo a linha DSL dos EUA; se você estiver vendo algo como uma perda de 0,5% no servidor "mais lento", isso limitaria muito facilmente a taxa de transferência em um único soquete TCP.

Fluxos TCP paralelos

Para sua informação, alguns sites de teste de velocidade usam fluxos TCP paralelos para aumentar a taxa de transferência ; isso pode estar afetando os resultados que você vê, porque os fluxos TCP paralelos aumentam drasticamente a taxa de transferência, caso você tenha alguma perda de pacote no caminho. Eu já vi quatro fluxos TCP paralelos saturar completamente um modem a cabo de 5 Mbps que sofreu perda de pacotes constante de 1%. Normalmente, 1% de perda diminuiria a taxa de transferência de um único fluxo TCP.

Material bônus: Ajuste do buffer do host

Muitas implementações antigas de SO tinham soquetes com buffers limitados; com sistemas operacionais mais antigos (como o Windows 2000), não importava se o TCP permitia que grandes quantidades de dados estivessem em andamento ... seus buffers de soquete não estavam ajustados para aproveitar o grande RWIN. Foram feitas muitas pesquisas para permitir alto desempenho nas transferências de TCP . Os sistemas operacionais modernos (para essa resposta, podemos chamar o Windows Vista e, mais tarde, "modernos") incluem melhores mecanismos de alocação de buffer em suas implementações de buffer de soquete.


4
Como uma observação lateral: existem muitos roteadores de estilo antigo que se limitam ao redimensionamento de janelas (há menos todos os dias, mas ainda existem muitos) e o redefinem para zero, diminuindo drasticamente a largura de banda. A probabilidade de atingir um desses roteadores quebrados aumenta com o número de saltos para o destino, embora a maioria dos provedores de infraestrutura de rede não deva ter esse problema atualmente.
21413 Chris Down

Roteadores são dispositivos L3. O dimensionamento da janela TCP é um processo L4. O roteador encaminha o pacote ou não e, exceto no uso de mecanismos de QoS, não há diferenciação entre TCP, UDP ou qualquer outro protocolo. Os roteadores certamente afetam a negociação inicial do MSS (.. ou o fazem se deixarem o ICMP inacessível), mas o algoritmo da janela deslizante é puramente uma função das pilhas nos sistemas finais.
Rnxrx

2
@rnxrx Eu concordo, seria principalmente o FW de ponta que ficaria irritado com as opções de TCP. Eu não ouvi falar da opção de dimensionamento da janela TCP do roteador desconcertante, mas não ficaria muito surpreso se alguém descobrisse o fornecedor / modelo que o fez, considerando que não é raro os roteadores de borda alterarem a opção TCP MSS em trânsito , não é um grande salto imaginar alguém se metendo nisso.
ytti 12/07/2013

3

Resposta curta: Sim, a distância afeta a largura de banda do fluxo único.

A internet desenvolveu meios de limitar esse efeito ... atraso no ACK, redimensionamento de janelas, outros protocolos :-) Mas a física ainda vence no final. Nesse caso, é muito mais provável que haja congestionamento geral da rede em tantos saltos - basta um único pacote descartado para matar um fluxo TCP.


1

Embora já existam excelentes respostas para isso, gostaria de acrescentar: não, a velocidade não é necessariamente afetada pela distância e sim, muitas vezes a velocidade é afetada pela distância .

Por que é que?

Fortemente simplificado, quanto maior a distância, mais "saltos" estão envolvidos no caminho pela Internet. A largura de banda máxima é determinada pelo salto mais lento e pelo tráfego simultâneo. Com o aumento da distância e uma distribuição um tanto aleatória das velocidades de salto, a probabilidade de obter velocidades gerais mais lentas está aumentando. Além disso, a física atrapalha e o aumento da latência também pode diminuir a velocidade do link.

Mas isso não deve ser tomado como garantido. A tecnologia nos permite construir uma conexão abrangente do planeta com praticamente qualquer largura de banda desejada. No entanto, largura de banda e distância são inimigas e aumentam drasticamente o custo da conexão, novamente tornando menos provável a existência apenas da conexão que você pode precisar no momento.

Claro, isso é simplificado demais, mas, na realidade, essa situação é o que você costuma encontrar. E, novamente, você não o faz quando há uma conexão surpreendentemente rápida ou um proxy de distribuição ao virar da esquina - mas quando tudo é instantâneo, raramente pensamos na velocidade da Internet ...


-1

De acordo com Andrew Martin, a resposta é sim

Gráficos


As respostas apenas para links não são recomendadas. Forneça detalhes que tornem essa resposta útil sem depender da página da web vinculada.
Teun Vink

Cara, não é uma ligação única resposta, é uma imagem com estatísticas
Jonathan

Eu não sou seu cara. Além disso, esta imagem não tem significado sem uma explicação sobre o eixo Y e como foi medido. E mesmo assim, você deve explicar como essa imagem é uma resposta para a pergunta.
Teun Vink

Não sei por que é difícil para você, mas os eixos X e Y são rotulados. "Velocidade média de download em Mbps"
Jonathan
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.