UDP vs protocolos TCP [cerrado]

TCP y UDP son protocolos en la parte superior de la capa IP. De esto estoy seguro de que eres consciente. TCP y UDP difieren en las estrategias que utilizan para llevar datos a la aplicación.

TCP es un protocolo orientado a la conexión. Cuando los dos lados se conectan, intercambian un número de secuencia y comienzan a contar los bytes enviados de un lado a otro. Todos los bytes enviados de ida y vuelta se cuentan dentro del número de secuencia. Entonces, un lado puede decir "Creo que te envié los bytes 20-40 en el último paquete, ¿puedes confirmar que recibiste esos bytes en ese paquete?" Esto permite a cada lado saber si los datos no fueron recibidos o se recibió fuera de orden, y las partes del protocolo especifican cómo cada lado rectifica la situación (es decir, con re-solicitudes de ciertos paquetes). También hay tiempos de espera que determinan si la conexión se ha interrumpido. Si una conexión se pierde de esta manera, se debe volver a negociar una nueva sesión y el conteo secuencial comienza de nuevo (pero no necesariamente desde el byte 0, se requiere cierta cantidad de aleatoriedad para evitar algunos ataques). En la práctica, esto significa que una conexión como esta no puede recuperarse una vez que se interrumpe, debe restablecer la conexión. También hay características de control de flujo que garantizan que los datos no se envíen demasiado rápido para que un lado los procese. TCP es muy útil cuando los datos deben pasar absolutamente a pesar de los retrasos.

UDP es diferente. No hay conexión, no hay números secuenciales, no hay tiempos de espera. Los paquetes se envían entre los dos lados sin otra información necesaria. Como no hay conexión, los paquetes se pueden enviar en cualquier momento. Tampoco hay garantía de que los datos lleguen. Si envías un paquete, puede que no llegue y nunca lo sabrías. Por lo general, los datos se envían con sumas de comprobación, números de secuencia y similares a los datos que envía, si es necesario para un enlace más seguro. Debido a la falta de tiempos de espera y reintentos, es mucho más rápido que TCP. Normalmente, UDP se utiliza para situaciones en las que la velocidad es más importante que la obtención de todos los datos.

Cuando los datos se envían a través de UDP, ocurrirá una de dos cosas: un paquete llegará a su destino en un tiempo moderadamente corto o no lo hará. Se notificará al remitente que el paquete se inició en su viaje, haya llegado o no a su destino. Si el paquete no se entrega con éxito, el receptor nunca sabrá de su existencia. Es importante tener en cuenta que si bien UDP generalmente enviará paquetes de manera razonablemente oportuna, no hay garantía de que los paquetes lleguen a su destino en el orden en que se enviaron. La mayoría de las veces lo harán, pero algunos equipos de red pueden dividir arbitrariamente los paquetes que los atraviesan entre varios enlaces diferentes, algunos de los cuales pueden ser un poco más rápidos que otros.

TCP, a diferencia de UDP, establece una conexión entre dos partes e intenta garantizar que toda la información suministrada por cada lado sea recibida por el otro, en el orden en que se transmitió; garantiza que cada byte se entregará en secuencia o que la conexión se declarará inválida. La forma más sencilla de pensar en TCP es que los nodos envíen mensajes con el siguiente formato:

  I have received information up to but not including your byte #1253, ...
  ... and my data, starting at byte #4381, is "QUACK".

Cada nodo envía un mensaje del formato anterior cuando tiene datos que el otro nodo no ha reconocido o cuando ha recibido datos que aún no ha reconocido. Una cosa muy buena acerca de TCP es que no importa demasiado si se pierde un reconocimiento. Si los datos se reciben con éxito pero el transmisor no lo sabe, la próxima vez que decida transmitirlos, el transmisor incluirá datos redundantes, pero el receptor simplemente ignorará esos datos redundantes y reconocerá todos los datos útiles que recibió.

Algunas cosas a tener en cuenta sobre TCP:

1. Un dispositivo que transmite información esperará un reconocimiento e intentará la retransmisión si no recibe uno. Si no logra obtener un reconocimiento de manera persistente, decidirá que la conexión está muerta, pero la otra parte de la conexión nunca podrá saberlo.
2. TCP generalmente solo envía paquetes cuando al menos una parte de la comunicación tiene "algo que decir". Si ninguno de los nodos tiene algo que decir, una conexión TCP podría permanecer inactiva durante horas o días sin que fluya ningún dato.
3. Algunas implementaciones de TCP, si no fluyen datos durante un período prolongado de tipo (a menudo en algún lugar entre un minuto y una hora), reenviarán su último byte de datos en lo que se llama un paquete "keepalive", "fingiendo" que no No recibas un reconocimiento por ello. En la cadena normal de eventos, el receptor sabrá que ya recibió ese byte y, por lo tanto, lo descartará, pero también sabrá que el transmisor probablemente está esperando un acuse de recibo. Si el transmisor que envió el mensaje "keepalive" no recibe una respuesta, sabrá que la otra parte de la conexión ha desaparecido.
4. Un dispositivo que transmite a través de TCP sabrá que todos sus datos se han entregado con éxito. Un dispositivo que recibe TCP no sabrá cuándo ha recibido todos los datos que se han enviado hasta la fecha, a menos que reciba un paquete con un indicador "FIN", lo que indica que no habrá más datos.

Compara TCP con una conversación telefónica. Usted habla con alguien y él responde a lo que usted dice. Discute y verifica si el otro entendió lo que estaba preguntando.

Compare UDP con dejar un mensaje en el correo de voz. No sabe si se recibió, ni si su solicitud fue aprobada / ejecutada.