O mais próximo que temos de um serviço de snippeting de captura de pacotes é provavelmente o CloudShark.
As reconfigurações são interessantes e podem ser uma causa da lentidão percebida nas máquinas do OS X. Para explicar por que, precisamos detalhar um pouco como as velocidades são selecionadas. Isso é baseado em TCP Deslizando Janelas , com uma ordem lateral de produto de atraso de largura de banda .
O rendimento absoluto de uma determinada conexão de rede é determinado por alguns fatores:
- A velocidade com que os pacotes podem transmitir.
- Quanto tempo os pacotes demoram para chegar aonde estão indo.
- Quantos dados a parte de envio está disposta a deixar em aberto (não confirmados).
Uma conexão de 1 GbE abrangendo os EUA tem cerca de 80 ms de latência unidirecional. Como os agradecimentos são um fator aqui, temos que contar o tempo de retorno deles. Então, faça esse tempo de ida e volta de 160 ms. Uma conexão de 1 GbE pode ter 20 MB de dados 'pendentes' nesses 160ms (1024Gb x 0,16 segundos) se estiver transmitindo em velocidade total.
Quando uma conexão TCP é negociada, um dos parâmetros em que ambos os lados são handshake é o tamanho da janela TCP. Esse é o terceiro ponto: quantos dados a parte de envio está disposta a deixar não processados versus os tamanhos de buffer da parte receptora para receber dados. Conforme os dados são transmitidos, ambas as partes emitem atualizações sobre o tamanho de uma janela que estão dispostas a tolerar. Para redes rápidas e limpas, isso pode ficar muito grande.
Mas, se a conexão for redefinida por algum motivo, o processo será iniciado novamente com os tamanhos originais da janela. Se a janela estiver cheia, o lado de envio irá parar de enviar até que os ACKs voltem a ela. Você começa a entender por que a redefinição de conexão pode causar problemas de desempenho.
Há outro lado disso que eu quero mencionar, como eu já vi isso causar esse tipo de problema antes. Você não mencionou que viu, mas se olhar, poderá vê-los. Retransmite.
Uma das adições ao TCP da especificação inicial é Reconhecimentos seletivos . Isto entra em jogo se houver quedas de pacotes, não redefinições de conexão. Sem SACKs, Se essa conexão de 1Gb, RTT de 160ms que eu mencionei antes tiver uma queda de pacotes, a parte receptora ficará lá e soltará 20MB de dados no chão antes que a parte de envio reenvie tudo do pacote descartado para frente. Esse tipo de comportamento foi bom para o tipo de redes que tivemos em 1989, mas as atuais são muito mais rápidas e mais largas. Os SACKs permitem que o recebedor diga: "Eu já vi o timestamp 123 e o 125-137", o que permite que o remetente apenas retransmita o segmento 124 ausente e continue com o restante dele.
Eu tenho definitivamente visto casos em que a falta de suporte ao SACK em uma conexão resulta em transferências simplesmente terríveis. Quando conseguimos ativá-los nos dois lados, a performance subiu para o máximo teórico.
A pista para este problema é encontrada no handshake inicial do TCP 3-way. Você deve ver SACK no cabeçalho Options em ambos os lados. Se as máquinas OSX não estiverem emitindo, mas o Windows, você tem uma grande pista para o seu problema.