Velocidades de Upload do TCP Devagar para a Internet sobre o LFN

Question

Eu tenho duas VMs do Linux separadas por uma conexão WAN de 50 mbps. Existem cerca de 70ms de RTT neste link WAN, por isso tem alguma latência. Eu testei meu throughput de upload para a Internet de cada uma dessas VMs. A configuração básica é que o Site A tem uma conexão com a Internet e também uma conexão WAN ao Site B. O Site B usa a conexão com a Internet no Site A.

Tenho notado que o Site B faz um upload um pouco mais lento para a Internet do que o Site A. Eu estava usando apenas alguns desses sites de teste de velocidade da Internet para testar minhas velocidades de upload. Eu usei o mesmo site de teste de velocidade da Internet e servidor de cada site para fazer o teste. Eu também executei os testes muitas e muitas vezes.

Eu corri alguns bonés do Wireshark para ver o que estava acontecendo. Presumi que o servidor da Internet não estava abrindo uma janela TCP ampla o suficiente para contabilizar meus 70ms de latência adicional do Site B. No entanto, a janela TCP está totalmente aberta e é realmente meu servidor no Site B que para de transmitir, aguardando ACKs para entrar antes de enviar mais dados.

Eu olhei para um monte de coisas: timestamps TCP, SACKs e Window Scaling estão todos habilitados. Eu aumentei meus buffers da seguinte forma:

net.core.rmem_max = 67108864 
net.core.wmem_max = 67108864 
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_congestion_control=cubic

Também aumentei o tamanho da fila de transmissão da seguinte forma:

ifconfig eth0 txqueuelen 10000

Por fim, desabilitei o descarregamento do segmento de software TCP na VM (não há TOE de hardware no meu servidor).

Ainda assim, o Wireshark me mostra que não recebo mais do que 11.000 bytes em vôo. Eu tenho alguns pacotes perdidos perto do início da transferência, mas quando as coisas realmente acontecem, eu esperaria que mais dados fluíssem em vôo.

Alguém pode lançar alguma luz sobre por que o remetente está retendo dados quando tão poucos dados estão realmente em vôo?

    

Answer 1

O que eu vejo no seu rastreamento de pacotes é o controle de congestionamento reagindo à perda de pacotes.

O cliente começa enviando 9 segmentos iniciais seguidos de início lento, onde envia mais dois segmentos cada vez que recebe um pacote ACK.

O algoritmo de início lento continua até que o primeiro ACK duplicado do servidor indique que um pacote foi perdido. Isso acontece em um ponto em que há 20820 bytes em vôo. Depois disso, o cliente aumentará a janela de congestionamento mais lentamente.

O segundo caso de congestionamento ocorre apenas meio segundo na transmissão. Depois disso, o número de bytes em vôo aumenta em torno de 15K e atinge 68012 bytes em trânsito no momento em que ocorre o terceiro caso de congestionamento, que é de 6 segundos na transmissão.

Há cerca de 54KB em vôo após o terceiro caso de congestionamento. Isso cresce até atingir 94384 bytes em vôo, e o quarto caso de congestionamento acontece, isto é, 10 segundos na transmissão.

Existem vários outros casos de congestionamento durante o resto do rastreamento. A transmissão pode ter sido capaz de aumentar a velocidade, se não tiver ocorrido na perda de pacotes com a mesma freqüência. Tendo experimentado a primeira perda de pacotes tão cedo como o fez, levaria muito tempo a atingir a velocidade máxima.

Então, o que você precisa descobrir é por que os pacotes são perdidos tão cedo durante a conexão TCP. Acontece que o pacote perdido neste ponto é um dos 9 pacotes enviados de volta ao início no início da conexão. Isso indica que o cliente está configurado com uma configuração initcwnd muito alta. A julgar pela captura de um pacote que você forneceu, uma configuração razoável seria 4 .

A configuração initcwnd é especificada separadamente para cada entrada da tabela de roteamento. Eles podem ser visualizados e alterados usando o comando ip route .