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.
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.
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.
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:
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
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.
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.
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.
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
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.