Eu percebo que esta resposta é simplificada, e não tão explícita quanto gostaria, então se você tiver perguntas sobre um passo, por favor, pergunte!
Rolando um pouco depois de abrir este arquivo no Wireshark, vemos alguns quadros em cores diferentes. Parece muito ruim, certo? Bem, não é tão ruim assim. Espere, vamos chegar lá.
Verificando o pacote SYN (frame 37), vemos SACK e Window Scaling nas opções TCP. Boa. Mesma coisa na escala SYN / ACK (frame 38), SACK e Windows. Impressionante. Não vejo nada de estranho em relação ao SACK.
Uma estimativa do RTT descarregado é o tempo entre o pacote SYN e o primeiro ACK (frame 39). São cerca de 9,3 ms, o que corresponde às suas descobertas. Observe que o tempo entre SYN / ACK e ACK (quadros 38 e 39) é muito menor do que entre SYN e SYN / ACK (37 e 38). Isso significa que esse arquivo de captura é levado para o receptor e, para ver por que isso não é ideal, teremos que voltar para a escola.
Entre o remetente e o receptor, há uma parte do caminho da rede que é a menor, o que limita a largura de banda. A estimativa de RTT que recebemos do handshake nos fornece uma estimativa da duração desse caminho de rede. Uma medida de quantos pacotes podemos encaixar neste tubo é a Capacidade de tubulação ou o produto de retardo de largura de banda - PC [ bits] = R [bits / s] * RTT [s], onde R é a menor largura de banda. A capacidade do tubo é então uma medida de volume.
Imagine uma mangueira de jardim. Seu volume medido é definido pelo seu comprimento e sua largura da mesma maneira, certo? Para obter o máximo de água, é necessário que ele seja completamente preenchido com água, caso contrário, haverá lacunas de ar que limitam o fluxo de água. Caso consigamos preenchê-lo completamente, ele pode transbordar. Podemos usar um balde para não molharmos o chão e se o balde transbordar que não afeta o fluxo de água.
Acontece que é exatamente o mesmo no caminho da rede. Precisamos encher o tubo ... Em outras palavras, a capacidade do tubo é o menor número de bytes em vôo (a quantidade de água que temos no tubo + balde) entre o emissor e o receptor que utiliza a menor largura de banda (não causa lacunas de ar). Então, se os bytes em vôo > PC, então estamos bem!
Olhando para o traço TCP Estatísticas - > TCP StreamGraph - > Gráfico de Seqüência de Tempo (tcptrace) podemos ver os bytes no eixo Y e o tempo no eixo X. A derivada dessa curva é de bytes / segundo ou taxa de transferência. Observe como a "linha" preta é plana, o que significa que a taxa de transferência é estável! Ele é interrompido por linhas azuis algumas vezes (esses são os intervalos de SACK nos ACKs duplicados), mas como pode ser visto, ele não afeta o throughput.
Veja como a linha sólida cinza inferior direita (zoom em um pouco, as ACKs) está realmente próxima dos segmentos TCP pretos? O tempo entre o segmento TCP e o ACK é o RTT, aqui está quase 0! Isso significa que não há muitos segmentos em vôo que passaram por esse ponto de captura. Isso, por sua vez, significa que não podemos usar isso para estimar os bytes em vôo, e é por isso que uma captura de pacotes do lado do remetente é muito melhor.
Os pacotes aqui são naturalmente perdidos antes do ponto de captura. Cada segmento de dados que estava em andamento no momento da perda aciona um ACK duplicado. Portanto, podemos usar o número de ACKs duplicados para estimar os bytes em vôo no momento da perda de pacotes. Aqui vemos cerca de 9, 16 e 23 segmentos. Cada segmento tem 1448 bytes de dados, o que nos dá um byte entre 13k e 33k. O throughput aqui era de mais de 3 Mbit / s (do gráfico IO ) e com o RTT medimos antes de obtermos uma capacidade de tubo menor que 3e6 [bits / s] * 10e-3 [s] / 8 bytes = 3750 bytes ou menos de 3 segmentos.
Como os bytes em vôo no momento dessas perdas não são realmente os mesmos (difícil dizer aqui com tão poucas amostras), não posso dizer se são perdas aleatórias (que são ruins, más) ou que ocorrem perdas porque um queue / bucket estourou, mas eles estão ocorrendo quando bytes em flight > A taxa de transferência do PC não é afetada.
Sua resposta parece indicar que eles eram de fato aleatórios, mas não tantos para causar baixa produtividade.
