TCP y UDP

Comunicación TCP

Entrega confiable de TCP:

La diferencia clave entre TCP y UDP es la confiabilidad. La confiabilidad de la comunicación TCP se obtiene con el uso de sesiones orientadas a la conexión. Antes de que un host que utiliza TCP envíe datos a otro host, TCP inicia un proceso para crear una conexión con el destino. Esta conexión con estado permite hacer un seguimiento de una sesión o un stream de comunicación entre los hosts. Este proceso asegura que cada host tenga conocimiento del stream de comunicación y se prepare para este. Una conversación TCP requiere que se establezca una sesión entre hosts en ambas direcciones.

Una vez que se establece una sesión y que comienza la transferencia de datos, el destino envía acuses de recibo al origen por los segmentos que recibe. Estos acuses de recibo forman la base de la confiabilidad dentro de la sesión TCP. Cuando el origen recibe un acuse de recibo, reconoce que los datos se entregaron correctamente y puede dejar de rastrearlos. Si el origen no recibe el acuse de recibo dentro de un tiempo predeterminado, retransmite esos datos al destino.

Parte de la carga adicional que genera el uso de TCP es el tráfico de red generado por los acuses de recibo y las retransmisiones. El establecimiento de las sesiones genera sobrecarga en forma de segmentos adicionales que se intercambian. Hay también sobrecarga en los hosts indivuduales creada por la necesidad de mantener un registro de los segmentos que esperan un acuse de recibo y por el proceso de retransmisión.

Procesos del servidor TCP:

Los procesos de las aplicaciones se ejecutan en los servidores. Un único servidor puede ejecutar varios procesos de aplicaciones al mismo tiempo. Estos procesos esperan hasta que el cliente inicia comunicación con una solicitud de información u otros servicios.

Cada proceso de aplicación que se ejecuta en el servidor se configura para utilizar un número de puerto, ya sea predeterminado o de forma manual por el administrador del sistema. Un servidor individual no puede tener dos servicios asignados al mismo número de puerto dentro de los mismos servicios de la capa de transporte. Un host que ejecuta una aplicación de servidor Web y una de transferencia de archivos no puede configurar ambas para utilizar el mismo puerto (por ejemplo, el puerto TCP 8.080). Una aplicación de servidor activa asignada a un puerto específico se considera abierta, lo que significa que la capa de transporte acepta y procesa los segmentos dirigidos a ese puerto. Toda solicitud entrante de un cliente direccionada al socket correcto es aceptada y los datos se envían a la aplicación del servidor. Pueden existir varios puertos simultáneos abiertos en un servidor, uno para cada aplicación de servidor activa. Es común que un servidor proporcione más de un servicio al mismo tiempo, como un servidor Web y un servidor FTP.

Una manera de mejorar la seguridad en un servidor es restringir el acceso al servidor únicamente a aquellos puertos relacionados con los servicios y las aplicaciones a los que deben poder acceder los solicitantes autorizados.

Observe las figuras 1 a 5 para ver la asignación típica de puertos de origen y de destino en las operaciones TCP de cliente y servidor.

Figura 1

Figura 2

Figura 3

Figura 4

Figura 5

Establecimiento y finalización de la conexión TCP:

En algunas culturas, cuando dos personas se conocen, generalmente se saludan dándose la mano. Ambas culturas entienden el acto de darse la mano como señal de un saludo amigable. Las conexiones en la red son similares. El primer enlace solicita la sincronización. El segundo enlace acusa recibo de la solicitud de sincronización inicial y sincroniza los parámetros de conexión en la dirección opuesta. El tercer segmento de enlace es un acuse de recibo que se utiliza para informarle al destino que ambos lados están de acuerdo en que se estableció una conexión.

Cuando dos hosts se comunican utilizando TCP, se establece una conexión antes de que puedan intercambiarse los datos. Luego de que se completa la comunicación, se cierran las sesiones y la conexión finaliza. Los mecanismos de conexión y sesión habilitan la función de confiabilidad de TCP. Vea en la figura los pasos para establecer y terminar una conexión del TCP.

Los hosts hacen un seguimiento de cada segmento de datos dentro de una sesión e intercambian información sobre qué datos se reciben mediante la información del encabezado TCP. TCP es un protocolo full-duplex, en el que cada conexión representa dos streams de comunicación unidireccionales, o sesiones. Para establecer la conexión los hosts realizan un protocolo de enlace de tres vías. Los bits de control en el encabezado TCP indican el progreso y estado de la conexión. Enlace de tres vías:

• Establece que el dispositivo de destino se presente en la red

• Verifica que el dispositivo de destino tenga un servicio activo y que acepte solicitudes en el número de puerto de destino que el cliente de origen intenta utilizar para la sesión

• Informa al dispositivo de destino que el cliente de origen intenta establecer una sesión de comunicación en dicho número de puerto

En las conexiones TCP, el cliente del host establece la conexión con el servidor. Los tres pasos en el establecimiento de una conexión TCP son:

Paso 1. El cliente de origen solicita una sesión de comunicación de cliente a servidor con el servidor.

Paso 2. El servidor acusa recibo de la sesión de comunicación de cliente a servidor y solicita una sesión de comunicación de servidor a cliente.

Paso 3. El cliente de origen acusa recibo de la sesión de comunicación de servidor a cliente.

En las ilustraciones se pueden ver el establecimiento de la conexión TCP:

Figura 1

Figura 2

Figura 3

Para comprender el proceso de enlace de tres vías, observe los diversos valores que intercambian ambos hosts. Dentro del encabezado del segmento TCP, existen seis campos de 1 bit que contienen información de control utilizada para gestionar los procesos de TCP. Estos campos son los siguientes:

• URG: campo indicador urgente importante

• ACK: campo de acuse de recibo importante

• PSH: función de empuje

• RST: restablecer la conexión

• SYN: sincronizar números de secuencia

• FIN: no hay más datos del emisor

Los campos ACK y SYN son importantes para el análisis del protocolo de enlace de tres vías.

Análisis del protocolo TCP de enlace de tres vías: 

Mediante el resultado del software de análisis de protocolos, como los resultados de Wireshark, se puede examinar la operación del protocolo TCP de enlace de tres vías:

Paso 1: El cliente de origen solicita una sesión de comunicación de cliente a servidor con el servidor.

Un cliente TCP inicia un protocolo de enlace de tres vías al enviar un segmento con el indicador de control de sincronizar números de secuencia (SYN) establecido, lo que indica un valor inicial en el campo de número de secuencia en el encabezado. Este valor inicial para el número de secuencia, conocido como número de secuencia inicial (ISN), se elige de manera aleatoria y se utiliza para comenzar a rastrear el flujo de datos de esta sesión desde el cliente hasta el servidor. El ISN en el encabezado de cada segmento se incrementa en uno por cada byte de datos enviados desde el cliente hacia el servidor mientras continúa la conversación de datos.

Paso 2: El servidor reconoce la sesión de comunicación de cliente a servidor y solicita una sesión de comunicación de servidor a cliente.

El servidor TCP debe dar acuse de recibo del segmento SYN del cliente para establecer la sesión de cliente a servidor. Para hacerlo, el servidor envía un segmento al cliente con el indicador de acuse de recibo (ACK) establecido que indica que el número de acuse de recibo es significativo. Con este señalizador establecido en el segmento, el cliente interpreta esto como acuse de recibo de que el servidor ha recibido el SYN del cliente TCP.

El valor del campo de número de acuse de recibo es igual al ISN más 1. Esto establece una sesión del cliente al servidor. El indicador ACK permanece establecido para mantener el equilibrio de la sesión. Recuerde que la conversación entre el cliente y el servidor son, en realidad, dos sesiones unidireccionales: una del cliente al servidor y otra del servidor al cliente. En este segundo paso del protocolo de enlace de tres vías, el servidor debe iniciar la respuesta al cliente. Para comenzar esta sesión, el servidor utiliza el señalizador SYN de la misma manera en que lo hizo el cliente. Establece el señalizador de control SYN en el encabezado para establecer una sesión del servidor al cliente. El señalizador SYN indica que el valor inicial del campo de número de secuencia se encuentra en el encabezado. Este valor se utiliza para hacer un seguimiento del flujo de datos en esta sesión del servidor al cliente.

Paso 3: El cliente de origen reconoce la sesión de comunicación de servidor a cliente.

Por último, el cliente TCP responde con un segmento que contiene un ACK que actúa como respuesta al SYN de TCP enviado por el servidor. No existen datos de usuario en este segmento. El valor del campo de número de acuse de recibo contiene uno más que el ISN recibido del servidor. Una vez que se establecen ambas sesiones entre el cliente y el servidor, todos los segmentos adicionales que se intercambian en esta comunicación tendrán establecido el indicador ACK.

Se puede añadir seguridad a la red de datos de la siguiente manera:

• Denegar el establecimiento de sesiones del TCP

• Permitir sólo sesiones que se establezcan para servicios específicos

• Permitir sólo tráfico como parte de sesiones ya establecidas

Estas medidas de seguridad se pueden implementar para todas las sesiones TCP o solo para las sesiones seleccionadas.

Análisis de terminación de sesión TCP:

Para cerrar una conexión, se debe establecer el indicador de control finalizar (FIN) en el encabezado del segmento. Para finalizar todas las sesiones TCP de una vía, se utiliza un enlace de dos vías, que consta de un segmento FIN y un segmento ACK. Por lo tanto, para terminar una única conversación que admite TCP, se requieren cuatro intercambios para finalizar ambas sesiones, como se muestra en la figuras 1-4.

Figura 1

Figura 2

Figura 3

Figura 4

Nota: en esta explicación, los términos “cliente” y “servidor” se utilizan como referencia con fines de simplificación, pero el proceso de finalización lo pueden iniciar dos hosts cualesquiera que tengan una sesión abierta:

Paso 1: cuando el cliente no tiene más datos para enviar en el stream, envía un segmento con el indicador FIN establecido.

Paso 2: el servidor envía un ACK para acusar recibo del FIN y terminar la sesión de cliente a servidor.

Paso 3: el servidor envía un FIN al cliente para terminar la sesión de servidor a cliente.

Paso 4: el cliente responde con un ACK para dar acuse de recibo del FIN desde el servidor.

Cuando el cliente no tiene más datos que transferir, establece el indicador FIN en el encabezado de un segmento. A continuación, el extremo servidor de la conexión envía un segmento normal que contiene datos con el indicador ACK establecido utilizando el número de acuse de recibo, lo que confirma que se recibieron todos los bytes de datos. Cuando se dio acuse de recibo de todos los segmentos, la sesión se cierra.

La sesión en la otra dirección se cierra con el mismo proceso. El receptor indica que no existen más datos para enviar estableciendo el señalizador FIN en el encabezado del segmento enviado al origen. Un acuse de recibo devuelto confirma que todos los bytes de datos se recibieron y que la sesión, a su vez, finalizó.

También es posible terminar la conexión por medio de un enlace de tres vías. Cuando el cliente no posee más datos para enviar, envía un señalizador FIN al servidor. Si el servidor tampoco tiene más datos para enviar, puede responder con los señalizadores FIN y ACK, combinando dos pasos en uno. A continuación, el cliente responde con un ACK.

Figura 1

Figura 2

Confiabilidad y control del flujo

Confiabilidad de TCP (entrega ordenada):

Reordenamiento de segmentos

Cuando los servicios envían datos mediante el TCP, los segmentos pueden llegar a su destino en desorden. Para que el receptor comprenda el mensaje original, los datos en estos segmentos se reensamblan en el orden original. Para lograr esto, se asignan números de secuencia en el encabezado de cada paquete.

Durante la configuración de la sesión, se establece un número de secuencia inicial (ISN). Este ISN representa el valor inicial para los bytes para esta sesión que se transmite a la aplicación receptora. A medida que se transmiten los datos durante la sesión, el número de secuencia se incrementa en el número de bytes que se han transmitido. Este seguimiento de bytes de datos permite identificar y dar acuse de recibo de cada segmento de manera exclusiva. Se pueden identificar segmentos perdidos.

Los números de secuencia de segmento habilitan la confiabilidad al indicar cómo rearmar y reordenar los segmentos recibidos, como se muestra en la ilustración.

El proceso TCP receptor coloca los datos del segmento en un búfer de recepción. Los segmentos se colocan en el orden de número de secuencia correcto y se pasan a la capa de aplicación cuando se rearman. Todos los segmentos que llegan con números de secuencia no contiguos se mantienen para su posterior procesamiento. A continuación, cuando llegan los segmentos con bytes faltantes, tales segmentos se procesan en orden.

Confiabilidad de TCP (reconocimiento y tamaño de la ventana):

Confirmación de recepción de segmentos

Una de las funciones de TCP es garantizar que cada segmento llegue a destino. Los servicios de TCP en el host de destino envían un acuse de recibo de los datos que recibe la aplicación de origen.

El número de secuencia (SEQ) y el número de acuse de recibo (ACK) se utilizan juntos para confirmar la recepción de los bytes de datos contenidos en los segmentos transmitidos. El número de SEQ indica la cantidad relativa de bytes que se transmitieron en esta sesión, incluso los bytes en el segmento actual. TCP utiliza el número de ACK reenviado al origen para indicar el próximo byte que el receptor espera recibir. Esto se llama acuse de recibo de expectativa.

Se le informa al origen que el destino recibió todos los bytes de este stream de datos, hasta el byte especificado por el número de ACK, pero sin incluirlo. Se espera que el host emisor envíe un segmento que utiliza un número de secuencia que es igual al número de ACK.

Recuerde que cada conexión son realmente dos sesiones de una vía. Los números de SEQ y ACK se intercambian en ambas direcciones.

En el ejemplo de la figura, el host de la izquierda envía datos al host de la derecha. Envía un segmento que contiene 10 bytes de datos para esta sesión y un número de secuencia igual a 1 en el encabezado.

El host receptor recibe el segmento en la capa 4 y determina que el número de secuencia es 1 y que tiene 10 bytes de datos. Luego el host envía un segmento de vuelta al host de la izquierda para acusar recibo de estos datos. En este segmento, el host establece el número de ACK en 11 para indicar que el siguiente byte de datos que espera recibir en esta sesión es el byte número 11. Cuando el host emisor recibe este acuse de recibo, puede enviar el próximo segmento que contiene datos para esta sesión a partir del byte 11.

En este ejemplo, si el host emisor tuviera que esperar el acuse de recibo de cada uno de los 10 bytes, la red tendría mucha sobrecarga. Para reducir la sobrecarga de estos acuses de recibo, pueden enviarse varios segmentos de datos y dar acuse de recibo de estos con un único mensaje de TCP en la dirección opuesta. Este acuse de recibo contiene un número de ACK que se basa en la cantidad total de bytes recibidos en la sesión. Por ejemplo, si se comienza con un número de secuencia 2000, si se reciben 10 segmentos de 1000 bytes cada uno, se devolverá al origen un número de ACK igual a 12 001.

La cantidad de datos que un origen puede transmitir antes de recibir un acuse de recibo se denomina “tamaño de la ventana”, que es un campo en el encabezado TCP que permite administrar datos perdidos y controlar el flujo.

Confiabilidad de TCP (pérdida y retransmisión de datos):

Manejo de segmentos perdidos

La pérdida de datos se produce en ocasiones, sin importar qué tan bien diseñada esté la red; por lo tanto, TCP proporciona métodos para administrar estas pérdidas de segmentos. Entre estos está un mecanismo para retransmitir segmentos con datos sin acuse de recibo.

Un servicio de host de destino que utiliza TCP generalmente sólo da acuse de recibo de datos para bytes de secuencia continuos. Si faltan uno o más segmentos, solo se hace acuse de recibo de los datos en la primera secuencia contigua de bytes. Por ejemplo, si se reciben segmentos con números de secuencia de 1500 a 3000 y de 3400 a 3500, el número de ACK sería 3001. Esto se debe a que hay segmentos con números de SEQ de 3001 a 3399 que no se recibieron.

Cuando el TCP en el host de origen no recibe un acuse de recibo después de una cantidad de tiempo predeterminada, este vuelve al último número de ACK recibido y vuelve a transmitir los datos desde ese punto en adelante. La solicitud de comentarios (RFC) no especifica el proceso de retransmisión, pero se deja a criterio de la implementación particular del TCP.

Para una implementación de TCP típica, un host puede transmitir un segmento, colocar una copia del segmento en una cola de retransmisión e iniciar un temporizador. Cuando se recibe el acuse de recibo de los datos, se elimina el segmento de la cola. Si no se recibe el acuse de recibo antes de que el temporizador venza, el segmento es retransmitido.

En la actualidad, los hosts pueden emplear también una característica optativa llamada “acuses de recibo selectivos” (SACK). Si ambos hosts admiten los SACK, es posible que el destino acuse recibo de los bytes de segmentos discontinuos, y el host solo necesitará volver a transmitir los datos perdidos.

Control del flujo de TCP (tamaño de la ventana y acuses de recibo):

Control de flujo

TCP también proporciona mecanismos para el control del flujo. El control del flujo permite mantener la confiabilidad de la transmisión de TCP mediante el ajuste de la velocidad del flujo de datos entre el origen y el destino para una sesión dada. El control del flujo se logra limitando la cantidad de segmentos de datos que se envían al mismo tiempo y solicitando acuses de recibo antes de enviar más segmentos.

Para lograr el control del flujo, lo primero que determina TCP es la cantidad de segmentos de datos que puede aceptar el dispositivo de destino. El encabezado TCP incluye un campo de 16 bits llamado “tamaño de la ventana”. Esta es la cantidad de bytes que el dispositivo de destino de una sesión TCP puede aceptar y procesar al mismo tiempo. El tamaño inicial de la ventana se acuerda durante el inicio de sesión entre el origen y el destino por medio del protocolo de enlace de tres vías. Una vez acordado el tamaño, el dispositivo de origen debe limitar la cantidad de segmentos de datos enviados al dispositivo de destino sobre la base del tamaño de la ventana. El dispositivo de origen puede continuar enviando más datos para la sesión solo cuando obtiene un acuse de recibo de los segmentos de datos recibidos.

Durante el retraso en la recepción del acuse de recibo, el emisor no envía ningún otro segmento. En los períodos en los que la red está congestionada o los recursos del host receptor están exigidos, la demora puede aumentar. A medida que aumenta esta demora, disminuye la tasa de transmisión efectiva de los datos para esta sesión. La disminución de velocidad en la transmisión de datos de cada sesión ayuda a reducir el conflicto de recursos en la red y en el dispositivo de destino cuando se ejecutan varias sesiones.

Ver la figura para obtener una representación simplificada del tamaño de la ventana y los acuses de recibo. En este ejemplo, el tamaño de la ventana inicial para una sesión TCP representada se establece en 3000 bytes. Cuando el emisor transmite 3000 bytes, espera por un acuse de recibo de los mismos antes de transmitir más segmentos para esta sesión. Una vez que el emisor obtiene este acuse de recibo del receptor, puede transmitir 3000 bytes adicionales.

TCP utiliza tamaños de ventana para tratar de aumentar la velocidad de transmisión hasta el flujo máximo que la red y el dispositivo de destino pueden admitir y, al mismo tiempo, minimizar las pérdidas y las retransmisiones.

Control del flujo de TCP (prevención de congestiones):

Reducción del tamaño de la ventana

Otra forma de controlar el flujo de datos es utilizar tamaños de ventana dinámicos. Cuando los recursos de la red son limitados, TCP puede reducir el tamaño de la ventana para lograr que los segmentos recibidos sean reconocidos con mayor frecuencia. Esto reduce de forma efectiva la velocidad de transmisión porque el origen espera que se de acuse de recibo de los datos con más frecuencia.

El host receptor envía el valor del tamaño de la ventana al host emisor para indicar la cantidad de bytes que puede recibir. Si el destino necesita disminuir la velocidad de comunicación debido, por ejemplo, a una memoria de búfer limitada, puede enviar un valor más pequeño del tamaño de la ventana al origen como parte del acuse de recibo.

Como se muestra en la ilustración, si un host receptor está congestionado, puede responder al host emisor con un segmento que especifique un tamaño reducido de la ventana. En esta ilustración, se muestra que se produjo la pérdida de uno de los segmentos. El receptor cambió el campo de la ventana en el encabezado TCP de los segmentos devueltos en esta conversación de 3000 a 1500. Esto hizo que el emisor redujera el tamaño de la ventana a 1500.

Después de un período de transmisión sin pérdidas de datos ni recursos limitados, el receptor comienza a aumentar el campo de la ventana, lo que reduce la sobrecarga en la red, ya que se deben enviar menos acuses de recibo. El tamaño de la ventana sigue aumentando hasta que se produce la pérdida de datos, lo que provoca que disminuya el tamaño de la ventana.

Este aumento y disminución dinámicos del tamaño de la ventana es un proceso continuo en TCP. En redes altamente eficaces, los tamaños de la ventana pueden ser muy grandes, porque no se pierden datos. En redes en las que la infraestructura subyacente está bajo presión, es probable que el tamaño de la ventana se mantenga pequeño.

Comunicación UDP

Comparación de baja sobrecarga y confiabilidad de UDP:

UDP es un protocolo simple que proporciona las funciones básicas de la capa de transporte. Tiene una sobrecarga mucho menor que TCP, ya que no está orientado a la conexión y no proporciona los mecanismos sofisticados de retransmisión, secuenciación y control del flujo que ofrecen confiabilidad.

Esto no significa que las aplicaciones que utiliza UDP sean siempre poco confiables ni que UDP sea un protocolo inferior. Solo quiere decir que estas funciones no las proporciona el protocolo de la capa de transporte, y se deben implementar aparte, si fuera necesario.

Pese a que es relativamente baja la cantidad total de tráfico UDP que puede encontrarse en una red típica, los protocolos clave de la capa de aplicación que utilizan UDP incluyen lo siguiente:

• Sistema de nombres de dominio (DNS)

• Protocolo simple de administración de red (SNMP, Simple Network Management Protocol)

• Protocolo de configuración dinámica de host (DHCP)

• Protocolo de información de enrutamiento (RIP)

• Protocolo de transferencia de archivos trivial (TFTP)

• Telefonía IP o voz sobre IP (VoIP)

• Juegos en línea

Algunas aplicaciones, como los juegos en línea o VoIP, pueden tolerar cierta pérdida de datos. Si estas aplicaciones utilizaran TCP, experimentarían largas demoras, ya que TCP detecta la pérdida de datos y los retransmite. Estas demoras serían más perjudiciales para el rendimiento de la aplicación que las pequeñas pérdidas de datos. Algunas aplicaciones, como DNS, simplemente reintentan el envío de la solicitud si no reciben ninguna respuesta; por lo tanto, no necesitan que TCP garantice la entrega de mensajes.

La baja sobrecarga del UDP es deseada por dichas aplicaciones.

Reensamblaje de datagramas de UDP:

Ya que UDP opera sin conexión, las sesiones no se establecen antes de que se lleve a cabo la comunicación, como sucede con TCP. Se dice que UDP está basado en las transacciones; es decir, cuando una aplicación tiene datos para enviar, simplemente los envía.

Muchas aplicaciones que utilizan UDP envían pequeñas cantidades de datos que pueden ajustarse en un segmento. Sin embargo, algunas aplicaciones envían cantidades de datos más grandes que deben dividirse en varios segmentos. La PDU del UDP se conoce como un “datagrama”, aunque los términos “segmento” y “datagrama” se utilizan algunas veces de forma intercambiable para describir una PDU de la capa de transporte.

Cuando se envían datagramas múltiples a un destino, pueden tomar diferentes rutas y llegar en el orden equivocado. UDP no realiza un seguimiento de los números de secuencia de la manera en que lo hace TCP. UDP no tiene forma de reordenar datagramas en el orden en que se transmiten, como se muestra en la ilustración.

Por lo tanto, UDP simplemente reensambla los datos en el orden en que se recibieron y los envía a la aplicación. Si la secuencia de datos es importante para la aplicación, esta debe identificar la secuencia adecuada y determinar cómo se deben procesar los datos.

Procesos y solicitudes del servidor UDP:

Al igual que las aplicaciones basadas en TCP, a las aplicaciones de servidor basadas en UDP se les asignan números de puerto bien conocidos o registrados. Cuando estas aplicaciones o estos procesos se ejecutan en un servidor, aceptan los datos que coinciden con el número de puerto asignado. Cuando UDP recibe un datagrama destinado a uno de esos puertos, envía los datos de aplicación a la aplicación adecuada en base a su número de puerto.

Procesos de cliente UDP:

Como en TCP, la comunicación cliente/servidor la inicia una aplicación cliente que solicita datos de un proceso de servidor. El proceso de cliente UDP selecciona al azar un número de puerto del rango de números de puerto dinámicos y lo utiliza como puerto de origen para la conversación. Por lo general, el puerto de destino es el número de puerto bien conocido o registrado que se asigna al proceso de servidor.

Los números de puerto de origen seleccionados al azar colaboran con la seguridad. Si existe un patrón predecible para la selección del puerto de destino, un intruso puede simular el acceso a un cliente de manera más sencilla intentando conectarse al número de puerto que tenga mayor posibilidad de estar abierto.

Dado que no se crean sesiones con UDP, no bien los datos están listos para enviarse y los puertos están identificados, UDP puede formar los datagramas y pasarlos a la capa de red para direccionarlos y enviarlos a la red.

Una vez que el cliente selecciona los puertos de origen y de destino, este mismo par de puertos se utiliza en el encabezado de todos los datagramas que se utilizan en la transacción. Para la devolución de datos del servidor al cliente, se invierten los números de puerto de origen y destino en el encabezado del datagrama.

Procesos de cliente UDP:

Figura 1

Figura 2 

Figura 3

Figura 4 

Figura 5

TCP o UDP: esa es la cuestión

Aplicaciones que utilizan TCP:

Muchas aplicaciones requieren confiabilidad y otros servicios que proporciona TCP. Estas son aplicaciones que pueden tolerar cierto grado de demora o pérdida de rendimiento debido a la sobrecarga que impone TCP.

Esto hace que TCP sea más adecuado para las aplicaciones que necesitan transporte confiable y que pueden tolerar cierta demora. TCP es un excelente ejemplo de cómo las diferentes capas del suite de protocolos TCP/IP tienen funciones específicas. Debido a que el protocolo de la capa de transporte TCP maneja todas las tareas asociadas con la segmentación del stream de datos, la confiabilidad, el control del flujo y el reordenamiento de segmentos, este libera a la aplicación de la tarea de administrar cualquiera de estas tareas. La aplicación simplemente puede enviar el stream de datos a la capa de transporte y utilizar los servicios de TCP.

Como se muestra en la ilustración, algunos ejemplos de aplicaciones bien conocidas que utilizan TCP incluyen las siguientes:

• Protocolo de transferencia de hipertexto (HTTP)

• Protocolo de transferencia de archivos (FTP)

• Protocolo simple de transferencia de correo (SMTP)

• Telnet

Aplicaciones que utilizan TCP:

Existen tres tipos de aplicaciones que son las más adecuadas para UDP:

• Aplicaciones que pueden tolerar cierta pérdida de datos, pero requieren retrasos cortos o que no haya retrasos

• Aplicaciones con transacciones de solicitud y respuesta simples

• Comunicaciones unidireccionales donde no se requiere confiabilidad o donde la aplicación la pueda administrar

Muchas aplicaciones de video y multimedia, como VoIP y la televisión por protocolo de Internet (IPTV), utilizan UDP. Estas aplicaciones pueden tolerar cierta pérdida de datos con un efecto mínimo o imperceptible. Los mecanismos de confiabilidad de TCP presentan cierto grado de demora que se puede percibir en la calidad de sonido o video que se recibe.

Otros tipos de aplicaciones adecuadas para UDP son las que utilizan transacciones de solicitud y respuesta simples. Esto se da cuando un host envía una solicitud y existe la posibilidad de que reciba una respuesta o no. Estos tipos de aplicaciones incluyen las siguientes:

• DHCP

• DNS: también puede utilizar TCP

• SNMP

• TFTP

Algunas aplicaciones se ocupan de la confiabilidad por sí mismas. Estas aplicaciones no necesitan los servicios de TCP y pueden utilizar mejor UDP como protocolo de capa de transporte. TFTP es un ejemplo de este tipo de protocolo. TFTP tiene sus propios mecanismos para el control del flujo, la detección de errores, los acuses de recibo y la recuperación de errores. Este protocolo no necesita depender de TCP para esos servicios.

Funcionamiento TCP y UDP