Por que o TCP às vezes não reconhece os pacotes que recebe?

Question

Eu uso firefox para visitar um servidor da Web em execução em um computador na minha LAN. Percebo que às vezes o TCP não reconhece os pacotes que recebe. Por exemplo, nos seguintes pacotes capturados:

link

o 7º e o 9º pacotes são duplicados ACK, o navegador recebe pacotes TCP 6,8 e 10, mas a pilha TCP do navegador não reconhece os pacotes recebidos, por quê?

    

Answer 1

Isso acontece.

Você provavelmente está vendo TCP Delayed Acknowledgement , no qual o destinatário pode atrasar até 500 ms para enviar um pacote ACK combinado que reconhece vários pacotes que foram recebidos. Isso é bom para reduzir a sobrecarga quando você tem muitos pacotes e não se preocupa particularmente com a latência.

Isso pode aumentar a latência percebida e, portanto, esse recurso é o que você vê desabilitado em muitos "TCP Fixes" que pode encontrar para jogos: definindo TCP_ACKNOWLEDGE_DELAY como 0, o Windows enviará todos os ACKs imediatamente em vez de tentar agrupá-los . Isso tem o lado negativo de criar mais tráfego de rede, com poucos benefícios. Ele dá a aparência de reduzir a latência , mas os pacotes de dados não são enviados mais rapidamente.

    

Answer 2

Isso não acontece.

Ele apenas reconhece cada byte do fluxo, que é bem diferente. Por alguma razão, o TCP do receptor (aquele com o navegador rodando sobre ele) perde o segmento # 6. Como o receptor solicita imediatamente a sua retransmissão, deve tê-lo recebido com uma incompatibilidade de soma de verificação.

Todos os segmentos recebidos subseqüentemente (8, 10, 12) são segmentos fora de ordem e acionam acks duplicados, e o objetivo é solicitar a retransmissão do segmento nº 6. Como o caminho de comunicação entre receptor e remetente experimenta alguma latência, o remetente percebe isso um pouco tarde, reduz seu comprimento de canal (também conhecido como janela de congestionamento) e retransmite os dados contidos no segmento nº 6.

Em seguida, outra coisa interessante acontece no segmento # 15: o receptor não envia uma confirmação cumulativa acima de 8, 10, 12, mas reconhece apenas o segmento # 14, o que significa que descartou 8, 10 e 12, seja porque eles eram também sujeito a corrupção de dados ou porque é uma implementação TCP muito simples. Você pode habilitar a avaliação de soma de verificação TCP em wireshark, (falha aqui em cada segmento de saída devido ao sistema operacional deixar o campo de soma de verificação inválido para a placa ethernet avaliar) e confirma a primeira interpretação: erros de soma de verificação em 8, 10, 12. deve ser um link muito barulhento no caminho.