logo

Retransmissão TCP

A retransmissão TCP significa reenviar pela rede os pacotes que foram perdidos ou danificados. Aqui, a retransmissão é um mecanismo usado por protocolos como TCP para fornecer comunicação confiável. Aqui, comunicação confiável significa que o protocolo garante a entrega do pacote mesmo que o pacote de dados tenha sido perdido ou danificado.

exemplos de autômatos do DFA

As redes não são confiáveis ​​e não garantem o atraso ou a retransmissão dos pacotes perdidos ou danificados. A rede que utiliza uma combinação de reconhecimento e retransmissão de pacotes danificados ou perdidos oferece confiabilidade.

Mecanismo de retransmissão

Aqui, a retransmissão significa que os pacotes de dados foram perdidos, o que leva à falta de confirmação. Essa falta de confirmação aciona o tempo limite do temporizador, o que leva à retransmissão de pacotes de dados. Aqui, o cronômetro significa que, se nenhuma confirmação for recebida antes que o cronômetro expire, o pacote de dados será retransmitido.

Vamos considerar os seguintes cenários de retransmissão.

Cenário 1: Quando o pacote de dados é perdido ou errado.

Retransmissão TCP

Neste cenário, o pacote é enviado ao receptor, mas nenhuma confirmação é recebida dentro desse período de tempo limite. Quando o período de tempo limite expirar, o pacote será reenviado novamente. Quando o pacote é retransmitido, a confirmação é recebida. Uma vez recebida a confirmação, a retransmissão não ocorrerá novamente.

Cenário 2: Quando o pacote é recebido, mas a confirmação é perdida.

Retransmissão TCP

Neste cenário, o pacote é recebido do outro lado, mas a confirmação é perdida, ou seja, o ACK não é recebido do lado do remetente. Assim que o período de tempo limite expirar, o pacote será reenviado. Existem duas cópias dos pacotes do outro lado; embora o pacote seja recebido corretamente, a confirmação não é recebida, então o remetente retransmite o pacote. Neste caso a retransmissão poderia ter sido evitada, mas devido à perda do ACK o pacote é retransmitido.

Cenário 3: Quando ocorre o tempo limite inicial.

Retransmissão TCP

Nesse cenário, o pacote é enviado, mas devido ao atraso na confirmação ou ao tempo limite ter ocorrido antes do tempo limite real, o pacote é retransmitido. Neste caso, o pacote foi enviado novamente desnecessariamente devido ao atraso na confirmação ou o tempo limite foi definido antes do tempo limite real.

Nos cenários acima, o primeiro cenário não pode ser evitado, mas os outros dois cenários podem ser evitados. Vamos ver como podemos evitar essas situações.

Quanto tempo o remetente deve esperar?

O remetente define o período de tempo limite para um ACK. O período de tempo limite pode ser de dois tipos:

    Muito curto:Se o período de tempo limite for muito curto, as retransmissões serão desperdiçadas.Demasiado longo:Se o período de tempo limite for muito longo, haverá um atraso excessivo quando o pacote for perdido.

Para superar as duas situações acima, TCP define o tempo limite em função do RTT (tempo de ida e volta), onde o tempo de ida e volta é o tempo necessário para o pacote viajar da origem ao destino e depois voltar novamente.

Como podemos obter o RTT?

O RTT pode variar dependendo das características da rede, ou seja, se a rede estiver congestionada significa que o RTT está muito alto. Podemos estimar o RTT simplesmente observando os ACKs.

Vamos ver como podemos medir o RTT.

Usaremos o algoritmo original para medir o RTT.

Passo 1: Primeiro, medimos o AmostraRTT para cada segmento ou par ACK. Quando o remetente envia o pacote, sabemos o cronômetro em que o pacote é enviado e também sabemos o cronômetro em que a confirmação é recebida. Calcule o tempo entre esses dois, e isso se torna o AmostraRTT .

Passo 2: Não colheremos apenas uma amostra. Continuaremos coletando diferentes amostras e calculando a média ponderada dessas amostras, e isso se torna o EstRTT (Estimated RTT).

onde, α+ β = 1

Ubuntu build essencial

α está entre 0,8 e 0,9

β está entre 0,1 e 0,2

Etapa 3: O tempo limite é definido com base no EstRTT.

tempo limite = 2 * EstRTT.

O tempo limite está definido para ser o dobro do RTT estimado. É assim que o fator de tempo limite real é calculado.

Uma falha nesta abordagem

Há uma falha no algoritmo original. Vamos considerar dois cenários.

Cenário 1.

java pgm
Retransmissão TCP

O diagrama acima mostra que o remetente envia os dados, o que é considerado uma transmissão original. Dentro do período de tempo limite, nenhuma confirmação é recebida. Assim, o remetente retransmite os dados. Após retransmitir os dados, a confirmação é recebida. Vamos supor que a confirmação seja recebida para a transmissão original e não para a retransmissão. Como obtivemos o reconhecimento da transmissão original, então AmostraRTT é calculado entre o momento da transmissão original e o momento em que a confirmação é recebida. Mas na verdade, o AmostraRTT deveria ter ocorrido entre o momento da retransmissão e o momento da confirmação.

Cenário 2.

Retransmissão TCP

O diagrama acima mostra que o remetente envia o pacote de dados original para o qual também obtemos a confirmação. Mas a confirmação é recebida após a retransmissão dos dados. Se assumirmos que o reconhecimento pertence à retransmissão, então AmostraRTT é calculado entre o momento da retransmissão e o momento da confirmação.

Nos dois cenários acima, existe a ambigüidade de não saber se o reconhecimento é para a transmissão original ou para a retransmissão.

Conclusão do algoritmo acima.

  • Aqui, ACK não significa confirmar uma transmissão, mas na verdade, confirma o recebimento dos dados.
  • Se considerarmos o primeiro cenário, a retransmissão é feita para o pacote perdido. Neste caso, estamos assumindo que ACK pertence à transmissão original devido à qual o SampleRTT está se tornando muito grande.
  • Se considerarmos o segundo cenário, dois pacotes iguais são enviados, portanto ocorre duplicidade neste caso. Neste caso, estamos assumindo que ACK pertence à retransmissão devido à qual o SampleRTT está ficando muito pequeno.

Para superar os problemas acima, uma solução simples é dada pelo algoritmo Karn/Partridge. Este algoritmo forneceu uma solução simples que coleta as amostras enviadas de uma só vez e não considera as amostras no momento da retransmissão para o cálculo do RTT estimado.

Algoritmo Karn/Perdiz

Nos dois cenários acima, ocorre retransmissão e consideramos o RTT de amostra. Mas este algoritmo não considera o Sample RTT ao retransmitir. Já que a retransmissão ocorreu, significa que algo acontece neste tempo de ida e volta ou pode ocorrer algum congestionamento em uma rede. Para superar este problema, este algoritmo duplica o tempo limite após cada retransmissão. Este algoritmo é implementado na rede TCP.

Limitação

Não considera a variação no RTT.

    Se a variação for pequena, o EstimatedRTT será preciso. Se a variação for grande, o EstimatedRTT não será preciso.

Para superar a limitação acima, foi desenvolvido o algoritmo Jacobson/Karels que introduz o fator de variância no RTT.

Algoritmo Jacobson/Karels

Este algoritmo foi desenvolvido para superar a limitação do Karn/Perdiz algoritmo. Ele calcula a diferença entre SampleRTT e EstimatedRTT e aumenta o RTT com base na diferença.

Java 8

Cálculos para RTT médio

  • Primeiro, calculamos o fator de diferença.

Diff = AmostraRTT - EstimadoRTT

  • Agora calculamos o EstimatedRTT, que será calculado da mesma forma que fizemos acima.

EstRTT = EstRTT + (δ*Diferença)

  • Agora, calculamos a média do fator de diferença.

Dev = Dev + δ ( |Diff| - Dev)

Aqui, Dev é um fator de desvio e δ é um fator entre 0 e 1. O Desenvolvedor é uma estimativa da variação do EstRTT .

  • Consideraremos a variação ao calcular o valor do tempo limite.
Tempo limite = µ * EstRTT + ɸ * Dev

Onde, µ =1 e ɸ =4

Retransmissão rápida

A estratégia baseada em tempo limite para retransmissão é ineficiente. O TCP é um tipo de protocolo de janela deslizante, portanto, sempre que ocorre a retransmissão, ele começa a enviá-la a partir do pacote perdido.

o que é uri
Retransmissão TCP

Suponha que eu transmita os pacotes 0, 1, 2 e 3. Como o pacote 0 e o pacote 1 são recebidos do outro lado, o pacote 2 é perdido na rede. Recebi a confirmação do pacote 0 e do pacote 1, então envio mais dois pacotes, ou seja, pacote 4 e pacote 5. Quando os pacotes 3, 4 e 5 forem enviados, receberei a confirmação do pacote 1 como confirmações TCP são cumulativos, portanto, ele reconhece até o pacote que recebeu em ordem. Não recebi a confirmação dos pacotes 2, 3,4 e 5 dentro do período de tempo limite, então retransmiti os pacotes 2, 3, 4 e 5. Como o pacote 2 foi perdido, mas outros pacotes, ou seja, 3, 4 ,5 são recebidos do outro lado, eles ainda são retransmitidos devido a esse mecanismo de tempo limite.

Como essa ineficiência de tempo limite pode ser removida?

A melhor solução sob uma janela deslizante:

Suponha que n pacotes foram perdidos, mas ainda assim os pacotes n+1, n+2 e assim por diante foram recebidos. O receptor está continuamente recebendo os pacotes e enviando os pacotes ACK, informando que o receptor ainda está aguardando o enésimo pacote. O receptor está enviando confirmações repetidas ou duplicadas. No caso acima, o ACK do pacote 1 é enviado três vezes, pois o pacote 2 foi perdido. Este pacote ACK duplicado é uma indicação de que o enésimo pacote está faltando, mas os pacotes posteriores são recebidos.

A situação acima pode ser resolvida das seguintes maneiras:

  • O remetente pode interpretar os 'ACKs duplicados' como uma dica antecipada de que o enésimo pacote foi perdido, para que o remetente possa fazer a retransmissão o mais cedo possível, ou seja, o remetente não deve esperar até que o tempo limite ocorra.
  • O remetente pode implementar uma estratégia de transmissão rápida em TCP. Em uma estratégia de transmissão rápida, o remetente deve considerar os ACKs triplos duplicados como um gatilho e retransmiti-los.

O TCP usa três ACKs duplicados como gatilho e então executa a retransmissão. No caso acima, quando três ACKs do pacote 1 são recebidos, o remetente deve enviar o pacote perdido, ou seja, o pacote 2, sem esperar que o período de tempo limite ocorra.