Diego Andres PatiĂąo Jefferson Andres Colmenares
PROTOCOLO TCP Y PROTOCOLO UDP Protocolo TCP TCP es un protocolo transporte orientado por conexión que envía datos como un flujo de bytes sin estructura. Usando los números de secuencia y los mensajes de reconocimiento, el TCP puede proporcionar un nodo de envío con la información de entrega sobre los paquetes transmitidos a un nodo de destino. Donde los datos se han perdido adentro transitan de la fuente al destino, el TCP puede retransmitir los datos hasta que o se alcance una condición del descanso o hasta que se haya alcanzado la entrega exitosa. TCP también puede reconocer mensajes duplicados y los descartará adecuadamente. Si el ordenador de envío está transmitiendo demasiado rápido para la computadora de recepción, el TCP puede emplear los mecanismos de control de flujo para reducir la Transferencia de datos. La poder TCP también comunica la información de entrega a los protocolos de la capa superiores y a las aplicaciones que soporta. Todas estas características hacen TCP un Reliable Transport Protocol de punta a punta. El TCP se especifica en el RFC 793
El protocolo TCP ha sido proyectado para proporcionar un flujo fiable de byte, desde la fuente hasta el destino, sobre una red no fiable. Mientras que el
protocolo IP, inferior al protocolo TCP, proporciona un servicio de tipo besteffort, es decir, “hace lo mejor” para entregar los datagramas entre dos servidores en comunicación, no logra garantizar que los paquetes alcancen efectivamente un destino y que se respete el orden de entrega y la integridad de los datos. Por tanto, el protocolo TCP beneficiándose del servicio del IP, proporciona un servicio fiable de transferencia de datos entre los procesos. Sus principales funciones son: Reconstruir el flujo originariamente transmitido en el caso de fenómenos de pérdida, duplicación o entrega fuera de secuencia de las unidades informativas y de congestión. Adoptar técnicas para el control de flujo y congestión.
Con el control de flujo, el TCP previene que el emisor de una comunicación envíe mensajes superiores a la capacidad actual del buffer del destino, mientras que con el control de congestión, limita la cantidad de datos introducidos en la red de manera que se evita sobrecargar a los encaminadores y la consiguiente pérdida de paquetes. Además, el TCP efectúa la multiplexación de más flujos informativos de usuario sobre la misma conexión de transporte y soporta transmisiones full-duplex. La conexión TCP es de tipo point-to-point, es decir, entre un único receptor y un único emisor. Por lo tanto, el llamado multicasting no es realizable con el TCP. Se dice que: “Para el TCP, dos
servidores son una compañía, tres son multitud” El servicio ofrecido por el TCP se llama byte-oriented en cuanto los niveles superiores escriben o leen de los byte de la conexión TCP, pero el mismo TCP no transmite los byte uno cada vez, sino que los organiza en un paquete llamado segmento (figura 4.2). La cantidad de datos que pueden ser
modalidades de las creaciones de las conexiones son significativas y no despreciables dado que esta fase podría aportar un posterior retardo a la transmisión. Con el fin de establecer una conexión, el TCP usa un procedimiento denominado “three way handshake”, según el cual los dos servidores se intercambian paquetes .
El Protocolo UDP El grupo de protocolos de Internet también maneja un protocolo de transporte sin conexiones, el UDP (User Data Protocol, protocolo de datos de usuario). El UDP ofrece a las aplicaciones un mecanismo para enviar datagramas IP en bruto encapsulados sin tener que establecer una conexión. extraídos e insertados en segmentos vienen limitados por la dimensión máxima del segmento (MSS, Maximum Segment Size) que depende de la implementación del TCP relativa al determinado sistema operativo (valores usuales son 1500, 536, 512 byte)
La gestión de la conexión TCP
Sabemos ya que el TCP es un protocolo orientado a conexión; esto implica que una conexión entre emisor y destinatario deba ser instaurada antes de iniciar un intercambio de datos. Las
Muchas aplicaciones cliente-servidor que tienen una solicitud y una respuesta usan el UDP en lugar de tomarse la molestia de establecer y luego liberar una conexión. El UDP se describe en el RFC 768. Un segmento UDP consiste en una cabecera de 8 bytes seguida de los datos. La cabecera se muestra a continuación. Los dos puertos sirven para lo mismo que en el TCP: para identificar los puntos terminales de las máquinas origen y destino. El campo de longitud UDP incluye la cabecera de 8 bytes y los datos. La suma de comprobación UDP incluye la misma pseudocabecera de formato, la cabecera UDP, y los datos, rellenados con una cantidad par de bytes de ser necesario. Esta suma es opcional, y se almacena como 0 si no se calcula. Inutilizarla seria absurdo, a menos que la cantidad de los datos no importe, por ejemplo, voz digitalizada.
UDP no admite numeración de los datagramas, factor que, sumado a que tampoco utiliza señales de confirmación de entrega, hace que la garantía de que un paquete llegue a su destino sea mucho menor que si se usa TCP. Esto también origina que los datagramas pueden llegar duplicados y/o desordenados a su destino. Por estos motivos el control de envío de datagramas, si existe, debe ser implementado por las aplicaciones que usan UDP como medio de transporte de datos, al igual que el reeensamble de los mensajes entrantes.
Es por ello un protocolo del tipo besteffort (máximo esfuerzo), porque hace lo que puede para transmitir los datagramas hacia la aplicación, pero no puede garantizar que la aplicación los reciba. Tampoco utiliza mecanismos de detección de errores. Cuando se detecta un error en un datagrama, en lugar de entregarlo a la aplicación destino, se descarta. Cuando una aplicación envía datos a través de UDP, éstos llegan al otro extremo como una unidad. Por ejemplo, si una aplicación escribe 5 veces en el puerto UDP, la aplicación al otro extremo hará 5 lecturas del puerto UDP. Además, el
tamaño de cada escritura será igual que el tamaño de las lectura.
REFERENCIAS [1] Proyecto FONDEF D00I1026. redesopticas.reuna.cl [2] J. Heinanen. “RFC-2597: Grupo PHB de envíos garantizados”, pp. 1-7. Junio 1999. Fecha de Consulta: Marzo 2004. Dirección Web: www.ietf.org/rfc/rfc2597.txt [3] C. Henry. “Documento de Diseño de la red óptica IP, FONDEF D00I1026”, pp. 1-5. Agosto 2002. Fecha de Consulta: Marzo 2004. Dirección Web: redesopticas.reuna.cl/proyecto/docs/resproy 02.pdf
[4] Cisco Systems. “Catalyst 3550 Multilayer Switch Software Configuration Guide”. Octubre 2004. Fecha de Consulta: Marzo 2004. Dirección Web: www.cisco.com/en/US/products/hw/switches /ps646/products_configuration_guide_book09186a00 800c9e12.html
[5] Cisco Systems. “Software Configuration Guide, For Cisco 3600 Series and Cisco 2600 Series Routers”. Diciembre 2004. Fecha de Consulta: Marzo 2004.Dirección Web: www.cisco.com/en/US/products/hw/routers/ ps259/products_configuration_guide_chapter09186a 008007e61b.html