1. Introducción a TURN
El nombre completo de TURN es Traversal usando relés alrededor de NAT, que es una extensión de STUN/RFC5389, que agrega principalmente la función de relé. Si el terminal está detrás de NAT, puede ser imposible que el terminal se comunique directamente con su par (peer) bajo ciertas circunstancias. En este momento, el servidor en la red pública debe usarse como retransmisión para reenviar los mensajes entrantes y salientes. datos. . El protocolo de reenvío se define como TURN. TURN se diferencia de otros protocolos de retransmisión en que permite que los clientes se comuniquen con múltiples pares diferentes utilizando la misma dirección de retransmisión.
El cliente que utiliza el protocolo TURN debe poder comunicarse con el par a través de la dirección de retransmisión y poder conocer la dirección IP y el puerto de cada par (para ser precisos, debe ser la dirección de reflejo del servidor del par). Cómo se logran estas acciones está fuera del alcance del protocolo TURN. Una de las formas disponibles es que el cliente informe la información del par a través del correo electrónico, y otra forma es que el cliente utilice algunos protocolos específicos, como "introducción" o "cita", consulte RFC5128 para obtener más detalles.
Si se utiliza TURN en el protocolo ICE, la dirección de retransmisión se utilizará como candidata y ICE evaluará entre múltiples candidatos y seleccionará la dirección de comunicación más adecuada. Generalmente, los relés tienen la prioridad más baja. El protocolo TURN está diseñado como parte del protocolo ICE (Establecimiento de conectividad interactiva), y se recomienda enfáticamente que los usuarios usen ICE en sus programas, pero también puede ejecutarse independientemente de ICE. Vale la pena mencionar que el protocolo TURN en sí mismo es una extensión de STUN, por lo que la mayoría de los paquetes TURN son del tipo STUN Como extensión de STUN, TURN agrega nuevos métodos y atributos.
2. Descripción general de la operación
En una situación típica, el cliente TURN está conectado a la red interna y llega a la red pública a través de uno o más NAT. El servidor TURN está configurado en la red pública. Diferentes clientes usan el servidor TURN como un relé para comunicarse con otros pares. Como se muestra a continuación:
Peer A
Server-Reflexive +---------+
Transport Address | |
192.0.2.150:32102 | |
| /| |
TURN | / ^| Peer A |
Client’s Server | / || |
Host Transport Transport | // || |
Address Address | // |+---------+
10.1.1.2:49721 192.0.2.15:3478 |+-+ // Peer A
| | ||N| / Host Transport
| +-+ | ||A|/ Address
| | | | v|T| 192.168.100.2:49582
| | | | /+-+
+---------+| | | |+---------+ / +---------+
| || |N| || | // | |
| TURN |v | | v| TURN |/ | |
| Client |----|A|----------| Server |------------------| Peer B |
| | | |^ | |^ ^| |
| | |T|| | || || |
+---------+ | || +---------+| |+---------+
| || | |
| || | |
+-+| | |
| | |
| | |
Client’s | Peer B
Server-Reflexive Relayed Transport
Transport Address Transport Address Address
192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191 En la figura anterior, el cliente TURN de la izquierda es un cliente detrás de NAT (la dirección de intranet es 10.1.1.2:49721). Después de conectarse al servidor TURN en la red pública (puerto predeterminado 3478), el servidor obtendrá una dirección de reflexión del Cliente (Reflexive Transport Address, es decir, la IP de la red pública y el puerto asignado por NAT) 192.0.2.1:7000. En este momento, el Cliente creará o administrará la ASIGNACIÓN a través del comando TURN. La asignación es una estructura de datos en el servidor, incluida la información de la dirección de retransmisión. Luego, el servidor asignará una dirección de retransmisión al Cliente, que en la figura es 192.0.2.15:50000. Si los otros dos pares desean comunicarse con el Cliente a través del protocolo TURN, pueden enviar y recibir datos directamente a la dirección de retransmisión. El servidor TURN Los datos enviados a la dirección de retransmisión especificada se reenviarán al Cliente correspondiente, aquí está su dirección de reflejo.
Cada asignación en el servidor corresponde a un solo cliente y solo hay una dirección de retransmisión, por lo que cuando un paquete de datos llega a una dirección de retransmisión, el servidor siempre sabe a dónde debe reenviarse. Pero vale la pena mencionar que un Cliente puede tener varias asignaciones en un Servidor al mismo tiempo, lo que no contradice las reglas anteriores.
3. Transmisión
En el protocolo, la conexión entre el servidor TURN y el par se basa en UDP, pero el servidor y el cliente pueden transmitir mensajes STUN a través de otras conexiones, como TCP/UDP/TLS-over-TCP.Cliente Al transmitir datos a través de relés , si se usa TCP, también se convertirá a UDP en el lado del servidor, por lo que se recomienda que el cliente use UDP para la transmisión. En cuanto a por qué se admite TCP, es porque algunos firewalls bloquearán completamente los datos UDP. Para el Datos TCP del protocolo de enlace de tres vías, no hay aislamiento.
4. Asignaciones
Para obtener una asignación de retransmisión en el lado del servidor, el cliente debe usar la transacción de asignación. El cliente envía una solicitud de asignación (Solicitud de asignación) al servidor, y luego el servidor devuelve una respuesta de asignación exitosa, que incluye la dirección asignada. El cliente puede describir en el campo de atributos el tipo de asignación que desea (como el ciclo de vida). Dado que los datos de retransmisión logran una transmisión segura, el servidor requerirá la autenticación del cliente, principalmente utilizando el mecanismo de credenciales a largo plazo de STUN.
Una vez que se asigna la dirección de transporte de retransmisión, el cliente debe mantenerla viva. El método habitual es enviar una solicitud de actualización (Solicitud de actualización) al servidor. Este es un método estándar en TURN. La frecuencia de actualización depende de la duración de la asignación. ., el valor predeterminado es 10 minutos. El cliente también puede especificar una vida útil más larga en la solicitud de actualización, y el servidor devolverá un tiempo realmente asignado. Cuando el cliente quiere comunicarse con el dedo medio, puede enviar una actualización con una vida útil de 0 preguntar.
Tanto el servidor como el cliente almacenan información de 5 tuplas (5-TUPLE). Por ejemplo, para el cliente, la 5 tupla incluye la dirección/puerto local del cliente, la dirección/puerto del servidor y el protocolo de transmisión; el servidor es similar , simplemente cambie la dirección del cliente a su dirección de reflejo, porque eso es lo que ve el servidor. Tanto el servidor como el cliente llevan información de 5-TUPLE en la solicitud de asignación, y también se usa en la transmisión de información posterior, por lo que cada uno sabe qué asignación corresponde a qué transferencia.
TURN TURN Peer Peer
client server A B
|-- Allocate request --------------->| | |
| | | |
|<--------------- Allocate failure --| | |
| (401 Unauthorized) | | |
| | | |
|-- Allocate request --------------->| | |
| | | |
|<---------- Allocate success resp --| | |
| (192.0.2.15:50000) | | |
// // // //
| | | |
|-- Refresh request ---------------->| | |
| | | |
|<----------- Refresh success resp --| | |
| | | |
Como se muestra en la figura anterior, el cliente primero envía una solicitud de asignación sin información de verificación, por lo que el servidor STUN devolverá una respuesta de error y el cliente volverá a solicitar después de recibir el error y agregará la información de verificación requerida para realizar una asignación exitosa.
5. Enviar mecanismo
Hay dos métodos entre el cliente y el par para intercambiar información de la aplicación a través del servidor TURN, el primero es usar los métodos Enviar y Datos (método), el segundo es usar canales (channels), ambos métodos le dicen al servidor cuál El par debe recibir el datos, y el servidor le dice al cliente de qué par provienen los datos.
El mecanismo de envío usa las instrucciones de envío y datos (indicación). La instrucción de envío se usa para enviar datos del cliente al servidor, y la instrucción de datos se usa para enviar datos del servidor al cliente. Cuando se usa la instrucción de envío, el El cliente envía una indicación de envío al servidor, que contiene:
•XOR-PEER-ADDRESS属性,指定对等端的(服务器反射)地址.
•DATA属性,包含要传给对等端的信息.
Cuando el servidor recibe la indicación de envío, analizará los datos de la parte de DATOS y los reenviará al punto final correspondiente en formato UDP, y usará la dirección de retransmisión del cliente como la dirección de origen al encapsular el paquete de datos. enviado por el par a la dirección de retransmisión también será reenviado al cliente por el servidor. Vale la pena mencionar que Enviar / Indicación de datos no admite verificación, porque el mecanismo de verificación a largo plazo no admite la verificación de indicación, por lo que en Para evitar un ataque, TURN requiere que el cliente instale un permiso para el par antes de enviar una indicación al par. Como se muestra en la figura a continuación, el cliente no tiene permiso para el par B, lo que hace que su paquete de indicación sea descartado por el servidor Para pares Lo mismo es cierto para B:
TURN TURN Peer Peer
client server A B
| | | |
|-- CreatePermission req (Peer A) -->| | |
|<-- CreatePermission success resp --| | |
| | | |
|--- Send ind (Peer A)-------------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<-------------- Data ind (Peer A) --| | |
| | | |
| | | |
|--- Send ind (Peer B)-------------->| | |
| | dropped | |
| | | |
| |<== data ==================|
| dropped | | |
| | | | TURN admite dos formas de crear permisos, una es enviar una solicitud CreatePermission
6. Mecanismo de canales (Canales)
Para algunas aplicaciones, como VOIP (Voz sobre IP), la información de formato de 36 bytes adicional en la Indicación de envío/datos aumentará la presión del ancho de banda entre el cliente y el servidor. Para mejorar esta situación, TURN proporciona un segundo método A para permitir que el cliente y el par intercambien datos. Este método utiliza otro formato de paquete de datos, a saber, el mensaje ChannelData, el mensaje de datos del canal. El mensaje ChannelData no utiliza el encabezado STUN, pero utiliza un encabezado de 4 bytes, que contiene un valor del número de canal. (número de canal) Cada número de canal en uso está vinculado a un par específico, es decir, como un token de la dirección del par.
Para vincular un canal a un par, el cliente primero envía una solicitud de enlace de canal (ChannelBind Request) al servidor y especifica un número de canal no vinculado y la información de dirección del par. Después de la vinculación, tanto el cliente como el servidor pueden enviar y reenviar datos a través del mensaje ChannelData. El enlace del canal dura 10 minutos de forma predeterminada, y la duración se puede actualizar volviendo a enviar la solicitud ChannelBind. A diferencia de la asignación, no hay forma de eliminar directamente el enlace, solo esperar a que se agote el tiempo automáticamente.
TURN TURN Peer Peer
client server A B
| | | |
|-- ChannelBind req ---------------->| | |
| (Peer A to 0x4001) | | |
| | | |
|<---------- ChannelBind succ resp --| | |
| | | |
|-- [0x4001] data ------------------>| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
|--- Send ind (Peer A)-------------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | | En la figura anterior, 0x4001 es el número de canal, es decir, los primeros 2 bytes en el encabezado del mensaje ChannelData, cabe mencionar que la selección del número de canal tiene los siguientes requisitos:
•0x0000-0x3FFF : 这一段的值不能用来作为信道号
•0x4000-0x7FFF : 这一段是可以作为信道号的值,一共有16383种不同值在目前来看是足够用的
•0x8000-0xFFFF : 这一段是保留值,留给以后使用 7. Ejemplos
Como se mencionó en el capítulo anterior, debido a que RFC es un protocolo estándar, a menudo tiene buena compatibilidad y escalabilidad en la implementación. Las aplicaciones P2P de código abierto existentes se pueden conectar fácilmente a ellos si están diseñadas de acuerdo con el estándar. Entre ellos, el famoso es PJSIP. PJSIP es una biblioteca de comunicación multimedia de código abierto que implementa muchos protocolos estándar, como SIP, SDP, RTP, STUN, TURN e ICE. Por supuesto, también podemos implementarlo nosotros mismos. Por ejemplo, TurnServer en GitHub es uno de ellos. que admite TURN La implementación del servidor. El siguiente es un breve análisis del paquete de datos TURN en el entorno LAN. Primero, existen las siguientes condiciones de la máquina:
•TurnServer运行在192.168.1.110,使用默认端口3478,采用用户名和密码验证,其中用户名为pannzh,密码123456
•TurnClient运行在192.168.1.106,为了方便,令peer也在192.168.1.106运行,端口为59593 Aquí se usa wireshark para capturar y analizar paquetes. Primero, TurnClient envía una solicitud de asignación:
1.png
Se puede ver que la primera solicitud fue rechazada por el servidor, porque este último requería información de verificación de nonce, y la devolución del servidor contenía información de nonce, además de los atributos ERROR-CODE, SOFTWARE y FINGERPRINT.
2.png
En la siguiente solicitud, el cliente agrega el nonce recibido y atributos como USERNAME y REALM, y lo envía nuevamente a TurnServer:
3.png
El servidor recibe la solicitud de asignación correcta, por lo que devuelve la respuesta de éxito, y puede ver que la devolución tiene el tiempo de vida predeterminado de 1800 segundos, XOR-MAPPED-ADDRESS y XOR-RELAY-ADDRESS y otros atributos:
4.png
Como se mencionó anteriormente, si desea comunicarse con el par, primero debe crear un permiso, por lo que el Cliente envía una solicitud CreatePermission al servidor, que lleva la información del par:
5.png
Si el servidor pasa la verificación, devolverá una respuesta de éxito y luego el Cliente puede comunicarse con el Peer a través de los dos métodos mencionados anteriormente, como el método Enviar indicación a continuación:
6.png
Al enviar una indicación al TurnServer para informar al receptor de los datos y el contenido de los datos, el TurnServer puede reenviarlos, enviando así indirectamente DATOS al par.Desde la perspectiva del par, es una dirección de retransmisión 192.168.1.110 :65315 recibidos del cliente Paquetes UDP a la dirección de destino 192.168.1.106:59593 (es decir, la dirección del par).
Introducción al protocolo de giro del webrtc P2P original - libro breve
★La tarjeta de presentación al final del artículo puede recibir materiales de aprendizaje de desarrollo de audio y video de forma gratuita, incluidos (FFmpeg, webRTC, rtmp, hls, rtsp, ffplay, srs) y hojas de ruta de aprendizaje de audio y video, etc.
¡vea abajo!