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.