La retransmisión TCP significa reenviar los paquetes a través de la red que se han perdido o dañado. Aquí, la retransmisión es un mecanismo utilizado por protocolos como tcp para proporcionar una comunicación confiable. Aquí, comunicación confiable significa que el protocolo garantiza la entrega del paquete incluso si el paquete de datos se ha perdido o dañado.
convertir cadena a char java
Las redes no son confiables y no garantizan el retraso o la retransmisión de los paquetes perdidos o dañados. La red que utiliza una combinación de reconocimiento y retransmisión de paquetes dañados o perdidos ofrece confiabilidad.
Mecanismo de retransmisión
En este caso, la retransmisión significa que los paquetes de datos se han perdido, lo que provoca una falta de acuse de recibo. Esta falta de reconocimiento activa un temporizador de tiempo de espera, lo que conduce a la retransmisión de paquetes de datos. Aquí, el temporizador significa que si no se recibe ningún acuse de recibo antes de que expire el temporizador, el paquete de datos se retransmite.
Consideremos los siguientes escenarios de retransmisión.
Escenario 1: Cuando el paquete de datos se pierde o es erróneo.
En este escenario, el paquete se envía al receptor, pero no se recibe ningún acuse de recibo dentro de ese período de tiempo de espera. Cuando expira el período de tiempo de espera, el paquete se reenvía nuevamente. Cuando se retransmite el paquete, se recibe el acuse de recibo. Una vez recibido el acuse de recibo, la retransmisión no se volverá a producir.
Escenario 2: Cuando se recibe el paquete pero se pierde el acuse de recibo.
En este escenario, el paquete se recibe en el otro lado, pero se pierde el acuse de recibo, es decir, el ACK no se recibe en el lado del remitente. Una vez que expira el período de tiempo de espera, el paquete se reenvía. Hay dos copias de los paquetes en el otro lado; aunque el paquete se recibe correctamente, no se recibe el acuse de recibo, por lo que el remitente retransmite el paquete. En este caso, se podría haber evitado la retransmisión, pero debido a la pérdida del ACK, el paquete se retransmite.
Escenario 3: Cuando ocurre el tiempo de espera anticipado.
En este escenario, el paquete se envía, pero debido al retraso en el reconocimiento o al tiempo de espera antes del tiempo de espera real, el paquete se retransmite. En este caso, el paquete se ha vuelto a enviar innecesariamente debido al retraso en el acuse de recibo o el tiempo de espera se ha establecido antes del tiempo de espera real.
En los escenarios anteriores, el primer escenario no se puede evitar, pero sí los otros dos. Veamos cómo podemos evitar estas situaciones.
¿Cuánto tiempo debe esperar el remitente?
El remitente establece el período de tiempo de espera para un ACK. El período de tiempo de espera puede ser de dos tipos:
Para superar las dos situaciones anteriores, tcp establece el tiempo de espera en función del RTT (tiempo de ida y vuelta), donde el tiempo de ida y vuelta es el tiempo necesario para que el paquete viaje desde el origen al destino y luego regrese.
¿Cómo podemos obtener el RTT?
poda ab
El RTT puede variar dependiendo de las características de la red, es decir, si la red está congestionada, significa que el RTT es muy alto. Podemos estimar el RTT simplemente observando los ACK.
Veamos cómo podemos medir el RTT.
Usaremos el algoritmo original para medir el RTT.
Paso 1: Primero, medimos el RTT de muestra para cada segmento o par ACK. Cuando el remitente envía el paquete, conocemos el temporizador en el que se envía el paquete y también sabemos el temporizador en el que se recibe el acuse de recibo. Calcule el tiempo entre estos dos, y eso se convierte en el RTT de muestra .
Paso 2: No tomaremos una sola muestra. Seguiremos tomando diferentes muestras y calcularemos el promedio ponderado de estas muestras, y esto se convierte en el EstRTT (RTT estimado).
donde, α+ β = 1
α se encuentra entre 0,8 y 0,9
β se encuentra entre 0,1 y 0,2
Paso 3: El tiempo de espera se establece según EstRTT.
tiempo de espera = 2 * EstRTT.
El tiempo de espera será el doble del RTT estimado. Así es como se calcula el factor de tiempo de espera real.
cómo convertir una cadena en un int
Un defecto en este enfoque
Hay un error en el algoritmo original. Consideremos dos escenarios.
Escenario 1.
El diagrama anterior muestra que el remitente envía los datos, lo que se dice que es una transmisión original. Dentro del período de tiempo de espera, no se recibe ningún acuse de recibo. Entonces, el remitente retransmite los datos. Después de retransmitir los datos, se recibe el acuse de recibo. Supongamos que se recibe acuse de recibo de la transmisión original, no de la retransmisión. Dado que recibimos el acuse de recibo de la transmisión original, entonces RTT de muestra se calcula entre el momento de la transmisión original y el momento en que se recibe el acuse de recibo. Pero en realidad, el RTT de muestra debería haber sido entre el momento de la retransmisión y el momento del acuse de recibo.
Escenario 2.
El diagrama anterior muestra que el remitente envía el paquete de datos original del cual también recibimos el acuse de recibo. Pero el acuse de recibo se recibe después de retransmitir los datos. Si asumimos que el reconocimiento pertenece a la retransmisión, entonces RTT de muestra se calcula entre el momento de la retransmisión y el momento del acuse de recibo.
En los dos escenarios anteriores, existe la ambigüedad de no saber si el acuse de recibo es para la transmisión original o para la retransmisión.
Conclusión del algoritmo anterior.
- Aquí, ACK no significa acusar recibo de una transmisión, sino que, en realidad, acusa recibo de los datos.
- Si consideramos el primer escenario, la retransmisión se realiza por el paquete perdido. En este caso, asumimos que ACK pertenece a la transmisión original, por lo que SampleRTT resulta ser muy grande.
- Si consideramos el segundo escenario, se envían dos paquetes iguales, por lo que en este caso se produce duplicidad. En este caso, asumimos que ACK pertenece a la retransmisión por lo que el SampleRTT se está volviendo muy pequeño.
Para superar los problemas anteriores, el algoritmo de Karn/Partridge proporciona una solución sencilla. Este algoritmo proporcionó una solución simple que recopila las muestras enviadas al mismo tiempo y no considera las muestras en el momento de la retransmisión para calcular el RTT estimado.
Algoritmo de Karn/Perdiz
En los dos escenarios anteriores, se produce la retransmisión y hemos considerado el RTT de muestra. Pero este algoritmo no considera el RTT de muestra al retransmitir. Ya que se ha producido la retransmisión, lo que significa que algo sucede en este tiempo de ida y vuelta o puede ocurrir alguna congestión en una red. Para superar este problema, este algoritmo duplica el tiempo de espera después de cada retransmisión. Este algoritmo se implementa en la red TCP.
Limitación
No considera la variación en RTT.
Para superar la limitación anterior, se desarrolló el algoritmo de Jacobson/Karels que introduce el factor de varianza en RTT.
Algoritmo de Jacobson/Karels
Este algoritmo fue desarrollado para superar la limitación de la Karn/Perdiz algoritmo. Calcula la diferencia entre SampleRTT y EstimadoRTT, y aumenta el RTT en función de la diferencia.
Cálculos para el RTT promedio
- Primero, calculamos el factor de diferencia.
Dif = RTT de muestra - RTT estimado
operadores java
- Ahora calculamos el RTT estimado, que se calculará de la misma manera que lo hicimos anteriormente.
EstRTT = EstRTT + (δ*Dif)
- Ahora calculamos el promedio del factor de diferencia.
Desv = Desv + δ ( |Diff| - Desv)
Aquí, Dev es un factor de desviación y δ es un factor entre 0 y 1. desarrollador es una estimación de la varianza de la EstRTT .
árboles extendidos
- Consideraremos la variación al calcular el valor del tiempo de espera.
Dónde, µ =1 y ɸ =4
Retransmisión rápida
La estrategia de retransmisión basada en el tiempo de espera es ineficiente. TCP es un tipo de protocolo de ventana deslizante, por lo que cada vez que se produce la retransmisión, comienza a enviarlo desde el paquete perdido en adelante.
Supongamos que transmito los paquetes 0, 1, 2 y 3. Dado que el paquete 0 y el paquete 1 se reciben en el otro lado, el paquete 2 se pierde en una red. Recibí el acuse de recibo del paquete 0 y el paquete 1, por lo que envío dos paquetes más, es decir, el paquete 4 y el paquete 5. Cuando se envíen los paquetes 3, 4 y 5, recibiré el acuse de recibo del paquete 1 como acuse de recibo TCP. son acumulativos, por lo que reconoce hasta el paquete que ha recibido en orden. No he recibido el acuse de recibo de los paquetes 2, 3, 4 y 5 dentro del período de tiempo de espera, por lo que retransmito los paquetes 2, 3, 4 y 5. Dado que el paquete 2 se pierde, pero otros paquetes, es decir, 3, 4 ,5 se reciben en el otro lado, aún se retransmiten debido a este mecanismo de tiempo de espera.
¿Cómo se puede eliminar esta ineficiencia del tiempo de espera?
La mejor solución bajo una ventana corredera:
Supongamos que se ha perdido n paquetes, pero aun así se han recibido los paquetes n+1, n+2, etc. El receptor recibe continuamente los paquetes y envía los paquetes ACK, indicando que el receptor todavía está esperando el enésimo paquete. El receptor envía acuses de recibo repetidos o duplicados. En el caso anterior, el ACK del paquete 1 se envía tres veces porque el paquete 2 se perdió. Este paquete ACK duplicado es una indicación de que falta el enésimo paquete, pero se reciben los paquetes posteriores.
La situación anterior se puede solucionar de las siguientes formas:
- El remitente puede tomar los 'ACK duplicados' como un indicio temprano de que el enésimo paquete se ha perdido para que pueda realizar la retransmisión lo antes posible, es decir, el remitente no debe esperar hasta que se agote el tiempo de espera.
- El remitente puede implementar una estrategia de transmisión rápida en TCP. En una estrategia de transmisión rápida, el remitente debe considerar los ACK triples duplicados como un disparador y retransmitirlo.
TCP utiliza tres ACK duplicados como disparador y luego realiza la retransmisión. En el caso anterior, cuando se reciben tres ACK del paquete 1, el remitente debe enviar el paquete perdido, es decir, el paquete 2, sin esperar a que transcurra el período de tiempo de espera.