La diferencia entre la perforación TCP y la perforación UDP

Dirección de publicación original: /blog/978887

¿Por qué los perforadores P2P mencionados en Internet se basan básicamente en UDP? ¿Es imposible hacer un agujero con TCP? ¿O es difícil lograr la perforación de pozos TCP?

Supongamos que hay un cliente de intranet A y un cliente de intranet B, y que hay un servidor público S.

Si A y B quieren comunicarse vía UDP, deben atravesar las rutas NAT de ambos lados.

Supongamos NAT-A y NAT-B.

A envía un paquete de datos a la red pública S, B envía un paquete de datos a la red pública S y luego S obtiene las IP públicas de A y B respectivamente.

S también establece sesiones con A y B respectivamente. Los paquetes de datos enviados desde S a NAT-A serán reenviados directamente a A por NAT-A.

Los paquetes enviados desde S a NAT-B serán reenviados directamente por NAT-B a B, y cualquier paquete que no sea el enviado por S se descartará.

Entonces: ahora A y B pueden comunicarse con S en full dúplex respectivamente, pero A y B no pueden comunicarse directamente entre sí todavía.

Solución:

Así es como funciona la "perforación".

Pero TCP y UDP son algo diferentes en cómo perforan agujeros. Esto se debe a la API de Berkeley Sockets (especificación de socket estándar):

Los sockets UDP permiten vincular varios sockets al mismo puerto local, mientras que los sockets TCP no están permitidos.

Significado: si A B quiere conectarse a S, primero debe crear un socket localmente

para conectarse al socket en S. La creación del socket necesariamente lo vincula a un puerto local (incluso si la aplicación no escribe en el puerto, en realidad escribe en el puerto, al menos Java escribe en el puerto), digamos 8888, por lo que si el puerto no está vinculado al puerto local, entonces el socket está vinculado al puerto local. Si el socket está vinculado al puerto local, entonces el socket está vinculado al puerto local.

El siguiente paso es perforar agujeros, lo que requiere que A y B envíen paquetes de datos a la IP pública de cada uno, pero

El problema es: debido a que el dispositivo NAT determina la sesión en función en el número de puerto, por lo que si es un socket UDP, A y B pueden crear sockets por separado y luego vincular el socket a 8888, y la perforación del orificio será exitosa. Pero si se trata de un socket TCP

, no puede crear otro socket y vincularlo al 8888, por lo que la perforación no tendrá éxito. .