Reconocer ACK, NACK y REX en la comunicación de red

ACK, NACK, REX pueden escucharse y encontrarse con frecuencia durante las entrevistas o la comunicación en red. Hoy, presentaré ACK, NACK y REX en detalle.

Conoce a ACK, NACK, REX

1. ACK: Acuse de recibo, es una especie de retroalimentación positiva, el receptor responde al remitente después de recibir los datos.
2. NACK: Acuse de recibo negativo, que es un tipo de retroalimentación negativa, el receptor notifica al remitente solo cuando no se reciben los datos.
3. REX: Retransmisión, retransmisión, cuando el remitente se entera de que los datos se han perdido, vuelve a enviar un dato.

Entonces, ¿qué problemas pueden resolvernos ACK, NACK y REX? Presentemos las funciones de ACK, NACK y REX en la comunicación de red y los problemas que pueden resolver.

Use ACK, NACK y REX para resolver problemas comunes
1: determine si el paquete de datos del receptor se ha perdido:
número, coloque un número de secuencia (número de secuencia) para cada paquete, y el receptor encuentra que el número de secuencia salta/falla, usted puede juzgar la pérdida del paquete de datos.
Es por eso que se define un campo de número de serie en el encabezado del paquete del protocolo TCP (marcado en rojo en la figura):

Envíame un mensaje privado para recibir los últimos y más completos materiales de aprendizaje y mejora de audio y video de C++ , incluidos ( C/C++ , Linux , FFmpeg , webRTC , rtmp , hls , rtsp , ffplay , srs ) 

Para expandir, veamos la definición del encabezado del paquete del protocolo UDP:
 

Se puede ver que el encabezado UDP no utiliza ningún campo para identificar el número de secuencia (Seq number) Se puede ver que UDP es un protocolo de transporte que no se preocupa en absoluto por la pérdida de paquetes.

2: Determinar si el paquete de datos del remitente se ha perdido

Hay varias soluciones comunes, aquí hay una breve introducción de la siguiente manera

1. Protocolo de parada en espera
El remitente solo envía un paquete a la vez e inicia un temporizador al mismo tiempo. Si el temporizador expira y aún no se recibe el ACK del paquete, el paquete se considera perdido y se retransmite. Si se recibe un ACK, el temporizador se reinicia y se envía el siguiente paquete. También habrá problemas, tales como: el juicio de pérdida de paquetes y la eficiencia de transmisión son muy bajos.

El receptor suele adoptar el modo de acuse de recibo acumulativo, es decir, no tiene que enviar ACK para cada paquete uno por uno, sino que después de recibir varios paquetes en sucesión, envía ACK al número de secuencia del último paquete que llega en secuencia, indicando que este paquete y todos los paquetes anteriores se reciben correctamente.

Darse cuenta:

Desventajas del Modo de Confirmación de Acumulación: En una red con desorden severo, la eficiencia es muy baja, y algunos paquetes que han sido entregados pero no en orden también deben ser retransmitidos. Esquema de mejora: Retransmisión selectiva (Nota: se implementa el protocolo KCP/SRT): Para paquetes secuenciales, enviar acuse de recibo acumulativo; para paquetes omitidos, enviar ACK; el remitente solo retransmite los paquetes de datos realmente perdidos.

2. Protocolo ARQ continuo y Protocolo de ventana deslizante
El remitente mantiene una ventana de envío de cierto tamaño, y todos los paquetes dentro de la ventana de envío pueden enviarse continuamente sin esperar la confirmación ACK de la otra parte.

El receptor suele adoptar el modo de acuse de recibo acumulativo, es decir, no tiene que enviar ACK para cada paquete uno por uno, sino que después de recibir varios paquetes en sucesión, envía ACK al número de secuencia del último paquete que llega en secuencia, indicando que este paquete y todos los paquetes anteriores se reciben correctamente.

Desventajas del Modo de Confirmación de Acumulación: En una red con desorden severo, la eficiencia es muy baja, y algunos paquetes que han sido entregados pero no en orden también deben ser retransmitidos.

Esquema de mejora: Retransmisión selectiva (Nota: se implementa el protocolo KCP/SRT): Para paquetes secuenciales, enviar acuse de recibo acumulativo; para paquetes omitidos, enviar ACK; el remitente solo retransmite los paquetes de datos realmente perdidos.

3. Retransmisión rápida
En el protocolo de transmisión que usa el mecanismo ACK, el remitente generalmente espera hasta que el ACK de un paquete de datos se agote antes de retransmitir el paquete de datos, lo que no es lo suficientemente oportuno. Retransmisión rápida: si el receptor recibe un paquete de datos con un salto de número de secuencia, envía inmediatamente un ACK (acuse de recibo repetido) del último paquete de datos consecutivo al remitente. Si el remitente recibe 3 acuses de recibo repetidos consecutivos, considera que el siguiente paquete del ACK se ha perdido e inmediatamente retransmite el paquete perdido.

4. El
receptor NACK informa periódicamente al remitente de todos los números de secuencia de paquetes no recibidos a través de un mensaje de retroalimentación para su retransmisión. Las mejoras provocadas: se reduce la ocupación de frecuencia y ancho de banda de los paquetes de retroalimentación, y se puede notificar al remitente para que retransmita los paquetes perdidos en el momento oportuno.

3. ¿Cuál es la regla de cálculo para el tiempo de espera de retransmisión?

RTO: tiempo de espera de retransmisión, que es el parámetro más importante utilizado por el remitente para juzgar la pérdida de paquetes y realizar la retransmisión.

Obviamente, debe ser un valor que varíe con el RTT (tiempo de ida y vuelta) de transmisión de la red. Idealmente, el valor de RTO no es menor que RTT (el tiempo más corto desde la llegada del ACK enviado desde el paquete al otro). parte), la situación real En este caso, el RTT cambia con mucha frecuencia, y el RTT de cada transmisión puede ser diferente. Si RTO = RTT se configura de manera grosera, definitivamente conducirá a una retransmisión excesiva.

Por lo tanto, el método de cálculo de RTO adoptado por el protocolo TCP es:

En función de varias mediciones de RTT, se proporciona una estimación de RTT suavizada: SRTT (Tiempo de ida y vuelta suavizado)
RTO = SRTT + un determinado coeficiente (umbral para evitar fluctuaciones)
Además, el nivel del sistema establece el límite inferior de RTO en 100 ms o 200 ms, evitando valores atípicos
Además, para el RTO de los paquetes retransmitidos, agregue un algoritmo de retroceso, por ejemplo, para cada retransmisión, RTO = 2 RTO para reducir la retransmisión frecuente de un paquete
. demostró a través de experimentos que el efecto de usar 1,5 veces el coeficiente de retroceso de RTO es mejor que el efecto de 2 veces.

4. ¿Cuánto tiempo deben almacenarse en búfer los paquetes del remitente?

Para lograr la retransmisión, el remitente debe almacenar en caché localmente el paquete de datos enviado.Cuando se requiere la retransmisión, el paquete de datos se puede recuperar de la cola de caché para la retransmisión. Para el protocolo de transmisión del modelo ACK (como TCP), puede eliminar el caché después de recibir el ACK de la otra parte.Si es el protocolo de transmisión del modelo NACK, ¿cómo actualizar y borrar la cola del caché?

Basado en el intervalo de tiempo de RTT y NACK
Suponiendo que el RTT (tiempo de ida y vuelta de la red) actual es rtt ms, y el intervalo de tiempo de retroalimentación de NACK es x ms, entonces el tiempo mínimo de supervivencia de un paquete en la cola del búfer de envío debe ser:

tiempo de caché = 2 * rtt + x

Suponiendo que el paquete de retroalimentación NACK recibido dentro de este tiempo no indique que el paquete de datos se haya perdido, se puede eliminar. Por supuesto, similar al problema involucrado en RTO, rtt cambia con frecuencia, por lo que no es seguro confiar simplemente en este valor teórico para eliminar el caché, y se recomienda agregar una cierta cantidad de redundancia.

Basado en escenarios comerciales
Para escenarios de comunicación de audio y video en tiempo real, existen ciertos requisitos de demora, por lo tanto, no es necesario retransmitir datos que excedan 1 s. O, asumiendo que el GOP del video es de 2 segundos, entonces es suficiente mantener los paquetes de datos durante un máximo de 2 segundos en la cola del búfer.

5. ¿Con qué frecuencia envía el receptor una solicitud de nack?
Suponiendo que el receptor envía una solicitud NACK inmediatamente después de encontrar que el número de secuencia salta en el paquete, dado que los paquetes UDP pueden llegar desordenados, este esquema dará lugar a demasiadas solicitudes de retransmisión no válidas.

Una solución más razonable es enviar una solicitud NACK en un intervalo de tiempo específico (por ejemplo, WebRTC usa 10 ms) y transportar todos los números de secuencia de pérdida de paquetes durante este período a la vez.

6. ¿Qué paquetes perdidos se colocan en la cola de solicitudes de nack?

La cola para las solicitudes de retransmisión en el extremo receptor también debe tener un cierto mecanismo.No todos los paquetes perdidos deben requerir retransmisión, como por ejemplo:

El audio actual se ha reproducido hasta el punto de tiempo donde la marca de tiempo es x. De hecho, todos los paquetes de audio perdidos con marca de tiempo < x no deben retransmitirse, y lo mismo ocurre con el video.

Como servidor de tránsito SFU, no tiene el concepto de tiempo de reproducción, por lo que el método 1 no es aplicable, pero puede consultar la lógica del caché del remitente. Suponiendo que el GOP es 2 s, luego compare la marca de tiempo del paquete más reciente, el el tiempo perdido del paquete es de 2 s antes de los datos, no es necesario solicitar la retransmisión.

Además, como servidor de tránsito de SFU, puede encontrar las siguientes situaciones, es decir, el paquete de datos recibido de la solicitud NACK del cliente ya no está en su propia lista de paquetes en caché:

SFU Como receptor del enlace ascendente del cliente, descubre que la pérdida de paquetes es la misma que la del receptor ordinario y envía activamente  NACK solicitudes a la fuente a intervalos regulares; a su vez, SFU como remitente del enlace descendente del cliente,  NACK después de recibir la solicitud, si no se encuentra  cached list, márquelo. , una vez recibida la retransmisión desde la fuente, se reenviará al enlace de bajada lo antes posible.

7. ¿Cómo evitar solicitudes frecuentes de nack para un determinado paquete?
En cuanto a la implementación de WebRTC, existen las siguientes estrategias de prevención:

Cuando un paquete perdido se retransmite mediante una solicitud NACK al menos N veces (por ejemplo: 10 veces) y aún no se recibe con éxito, debería darse por vencido (probablemente el remitente no tiene un búfer para este paquete)

Teniendo en cuenta el tiempo de respuesta de la solicitud de retransmisión en el remitente y la red RTT, el receptor debe asegurarse de no enviar con frecuencia solicitudes de retransmisión NACK para el mismo paquete de datos dentro de un cierto período de tiempo. (Por ejemplo, el período de tiempo seleccionado por WebRTC es 5 + RTT * 1.5), es decir, la solicitud NACK del mismo paquete de datos no se enviará repetidamente durante este período de tiempo.

Cuando hay demasiados paquetes de datos en la lista de solicitudes de nack (por ejemplo: más de 1000), debe considerar limpiarlos (la red es demasiado débil). Para video, envíe una solicitud de IDR directamente y vuelva a solicitar un nuevo GOP datos.

8: ¿Prioridad de los paquetes de retransmisión? ¿Es necesario retransmitir los paquetes FEC?
Teniendo en cuenta que la pérdida de paquetes -> la retransmisión ya ha retrasado la hora de llegada de los paquetes de datos, la prioridad de los paquetes retransmitidos debe ser mayor que la de los paquetes de datos ordinarios. Por supuesto, también debe haber una estrategia para disminuir gradualmente la prioridad de acuerdo con el número. de retransmisiones.

Los paquetes FEC no son necesarios y tienen poca importancia. El propósito de FEC es reducir los paquetes redundantes agregados por la retransmisión. Perderlos no tiene un efecto fatal. Solo necesitamos retransmitir paquetes de datos con mayor valor.

9: ¿Cómo se define el paquete NACK del protocolo RTCP?
El encabezado del mensaje de retroalimentación RTCP se define de la siguiente manera, FMT y PT determinan el tipo de mensaje, y FCI es la carga útil específica de este tipo de mensaje:

 El formato  del mensaje de NACK retroalimentación  especificado por el protocolo  es el siguiente (se puede adjuntar más de uno y su longitud se indica en el campo de longitud del encabezado):PT= 205FMT=1FCIFCI
 

El diseño aquí es ingenioso, puede soportar la pérdida de paquetes de múltiples paquetes consecutivos a la vez:

• PID (identificador de paquete), que es el número de serie del paquete RTP perdido
• BLP (Bitmao of Lost Packets), que indica la pérdida de los próximos 16 paquetes por enmascaramiento