STUN, TURN y ICE para WebRTC
En un entorno de red de Internet real, la mayoría de los hosts de las computadoras están ubicados detrás de un firewall o NAT, y solo unos pocos hosts pueden acceder directamente a Internet.
Generalmente, esperamos que dos hosts ubicados en diferentes redes internas puedan comunicarse directamente, la llamada comunicación P2P, evitando otros servidores públicos para reducir los retrasos en la comunicación en tiempo real.
Dado que los hosts pueden estar detrás de un firewall o NAT, antes de iniciar una comunicación P2P debemos probar si pueden comunicarse entre sí y cómo.
Esta técnica a menudo se conoce como NAT transversal y la cubrimos brevemente en NAT Traversal para WebRTC.
Si no sabes nada sobre el recorrido NAT, te recomendamos que lo revises primero.
Los protagonistas de hoy son STUN, TURN e ICE, que son diferentes soluciones técnicas para lograr la penetración NAT.
STUN se definió originalmente en RFC3489 como una solución transversal NAT completa. El nombre completo en inglés es Simple Traversal of UDP Through NAT, que significa simplemente usar UDP para penetrar NAT.
La nueva revisión RFC5389 describe el protocolo STUN como una herramienta para atravesar NAT, en lugar de una solución completa. En la nueva revisión RFC5389, el protocolo STUN se describe como una herramienta para penetrar NAT en lugar de una solución completa.
STUN es un modo cliente/servidor típico. El cliente inicia una solicitud y el servidor responde. El puerto predeterminado es 3478: RFC3489 y RFC5389.
RFC3489 sobre el muro vía UDP. Los servidores actuales tienen más restricciones en UDP, lo que resulta en una menor tasa de éxito para este modo de penetración de muros.
RFC5389 es una versión actualizada de RFC3489, pero tiene un significado diferente. Es una serie de ataques de penetración de muros combinados con penetración de muros TCP.
Todos los mensajes STUN contienen un encabezado de mensaje de 20 bytes (8 bits por byte, 160 bits en total***), un tipo de mensaje de 2 bytes (o 16 bits),
p>
Una longitud de mensaje de 2 bytes (sin incluir la longitud del encabezado del mensaje) y una ID de transacción de 16 bytes (la ID de transacción de solicitud y la ID de transacción de respuesta son las mismas).
Después del encabezado del mensaje está el cuerpo del mensaje. El cuerpo del mensaje puede contener 0 o más atributos. Cada atributo está codificado en TLV, incluido el tipo de atributo de 16 bits, la longitud del atributo de 16 bits y el valor del atributo de longitud variable. .
No entraré en protocolos de interacción de mensajes más específicos porque mi objetivo es aprender y utilizar WebRTC, y todavía no estoy en el punto en el que pueda descubrir todos los detalles de WebRTC.
STUN puede penetrar tres de los cuatro tipos principales de NAT: NAT de cono completo, NAT de cono restringido y NAT de cono restringido por puerto, mientras que la NAT simétrica no puede.
Como se mencionó anteriormente, la NAT simétrica no se puede atravesar exitosamente usando STUN, por lo que ahora se requiere TURN.
El propósito del protocolo TURN es resolver el problema de la imposibilidad de atravesar la NAT simétrica.
TURN (Recorrido mediante retransmisión NAT) es un protocolo de transferencia de datos. Permite atravesar NAT vía TCP o UDP.
TURN también es un protocolo cliente/servidor y también utiliza el mismo formato de mensaje que STUN.
Sin embargo, el punto final que implementa el cliente TURN debe interactuar con el servidor TURN antes de que pueda comenzar la comunicación y requiere que el servidor TURN genere un "puerto de retransmisión", una dirección de reenvío de retransmisión.
En este punto, el servidor TURN crea un par, el punto final remoto, y comienza a retransmitir.
El punto final del cliente TURN debe interactuar con el servidor TURN antes de que pueda comenzar la comunicación y pedirle al servidor TURN que genere un "puerto de retransmisión", es decir, una dirección de retransmisión. Para decirlo sin rodeos, creo que el protocolo TURN se parece más a un protocolo de reenvío de retransmisión que a una comunicación P2P real (no sé si el autor lo entiende correctamente)
ICE (establecimiento de conexión interactiva): ICE definición Un método transversal en lugar de un protocolo.
Ahora que podemos usar STUN o TURN para atravesar NAT, ¿cuándo usamos STUN y cuándo usamos TURN? Eso es lo que hace ICE.
En términos más generales, ICE es más como un administrador de penetración NAT. Los usuarios solo necesitan decirle a ICE que quieren atravesar la pared, eso es asunto de ICE.
ICE integra STUN y TURN. ICE facilita que los puntos finales se comuniquen detrás de dos NAT. ICE usa STUN para perforar agujeros y TURN para retransmitir si falla la perforación.
Las siguientes son las tareas principales de ICE:
1. La recopilación de direcciones de candidatos también se denomina recopilación de candidatos.
El llamado Candidato es una dirección compuesta por IP y puerto. Hay tres tipos de Candidato:
2. Ordenar los pares de direcciones candidatas
Después de que ICE recopila las direcciones candidatas, los dos dispositivos pares tienen varias direcciones candidatas de sí mismos y de cada uno, y Emparéjelos para formar pares de direcciones candidatas.
Cada pareja de candidatos tiene una prioridad correspondiente, y ICE necesita priorizar cada pareja de candidatos.
3. Detección de conectividad de direcciones de candidatos
ICE realiza la detección de envío y recepción en los pares de candidatos ordenados. El envío y la detección se realizan al mismo tiempo. Si la información se envía, puede. Si la información recibida y enviada es la misma, indica que la conectividad es a través de
"Explicación detallada de la tecnología P2P (4)": Tecnología P2P.