Universidad Católica del Maule. Arquitectura de computadores y redes. TIPOS DE PAQUETES EN INTERNET

Transcripción

1 TIPOS DE PAQUETES EN INTERNET Si pudiéramos observar los bits que viajan de un computador a otro, nos daríamos cuenta que cada protocolo es muy distinto de otro. Pero a la vez, nos daríamos cuenta que todos comparten una característica necesaria, todos transportan el mensaje del programa. Algunos protocolos incluyen la dirección origen, mientras otros requieren la del destino. El protocolo de Internet (IP) requiere que un paquete tenga tres elementos básicos: 1. origen. 2. destino. 3. datos Estos elementos ofrecen un nivel de autonomía al paquete. No importa donde está el paquete, se puede identificar de donde viene, donde va y como es de grande. La autonomía del paquete es una característica de Internet. Mientras el paquete esté vivo, los routers trasladan los datos a su destino cuando el paquete está activado sobre la red. La autonomía que tiene el paquete también conlleva una parte negativa. Mientras un paquete ofrece la forma de llegar a cualquier sitio desde cualquier parte, un programador con malas intenciones puede fácilmente de esta forma engañar la red. La red no requiere que la dirección de origen esté validada. Hacer aliasing o spoofing (enmascaramiento de la verdadera identidad asumiendo una distinta) de la dirección hardware es difícil, pero los programas pueden enmascarar otros ID. Se debe observar que kernels de linux recientes no permiten el spoofing. Definición de la estructura IP typedef unsigned int uint; typedef unsigned char uchar; struct ip_packet { uint version: 4; //version de 4 bits uint header_len: 4; // tamaño de cabecera uint serve_type: 8; // como servir el paquete uint packet_len: 16; // tamaño total del paquete uint ID:16; //ID del paquete uint _reserver: 1; // siempre cero uint dont_frag: 1; // bandera para permitir la fragmentación uint more_frags: 1; // bandera para continúan más fragmentos uint frag_offset: 13; // ayudar a la recomposición uint time_to_live: 8; // número de saltos de router permitidos uint protocol: 8; //ICMP, UDP, TCP uint hdr_chksum: 16; //suma de comprobación de la cabecera uint Ipv4_source: 32 //direcci on IP del origen Preparado por Paulo A. González G. 40

2 }; uint Ipv4_dest: 32; //dirección IP del destino uchar options[]; //hasta 40 bytes uchar data[]; //datos del mensaje hasta 64 KB. Si se observa, el paquete incluye más campos de los que se mencionaron anteriormente. IP usa estos campos adicionales para controlar el paquete. Por ejemplo, el campo dont_frag especifica a la red que en lugar de desmenuzar el mensaje en trozos deberá aceptar el mensaje completamente o rechazarlo. Campo versión: Este campo, es el número de versión del protocolo IP. Muchos de estos valores están reservados o sin asignar, por ejemplo IPv4 coloca un 4 en este campo. Campo header_len: este campo indica al receptor la longitud de la cabecera usando palabras de 32 bits. Desde el valor 0 que está reservado, y que no tiene significado, hasta el tamaño mayor de 15 palabras o 60 bytes. La única situación en la que se debe rellegar este campo es cuando se usa socket raw. Como todas las cabeceras IP tienen al menos 20 bytes, el valor mínimo de este campo es 5. Campo serve_type: Este campo indica cómo administrar el paquete. Tiene dos subcampos. El subcampo precedence y un subcampo de tipo de servicio (TOS). Normalmente establecerá TOS con la llamada del sistema setsockpt(). TOS tiene cuatro opciones: retardo mínimo, rendimiento máximo, fiabilidad máxima y costo mínimo. Si no se selecciona ningún servicio especial significa una administración normal. Campo ID: éste le da a cada paquete un ID único. Con un campo de sólo 16 bits, puede uno imaginarse que se alcanzan rápidamente los números usados con anterioridad. Sin embargo el subsistema IP reusa un ID por medio de la hora del sistema, el paquete que se envión previamente del mismo valor, ya haya caducado. El ID ayuda a recomponer paquetes fragmentados. Si se decide administrar la cabecera (IP_HDRINCL), debe administrar los ID también. Si se decide manipular la cabecera hay que recordar que el programa que se usa no es el único que puede enviar mensajes. El subsistema IP sigue la pista de los ID. Hay que tener precaución para reducir la probabilidad de seleccionar un ID que el subsistema pueda usar o haya usado. Campo frag_offset y flags dont_frag y more_flags Estas banderas controlan cómo fragmentar los paquetes o si se fragmentan. Cuando un paquete extenso viaja por la red y se encuentra con un segmento de red reducido ( o simplemente uno que no pueda soportar el tamaño de trama del paquete), el router puede intentar dividir el paquete en trozos más pequeños (fragmentación). Un paquete fragmentado permanece fragmentado hasta que llega al destino. Puesto que cada fragmento tiene su propia cabecera IP, la sobrecarga fija disminuye el rendimiento dela red. Preparado por Paulo A. González G. 41

3 El bit don_frag indica al router o host que no divida el paquete. Si establece este bit y el paquete es demasiado grande para un segmento de red reducido, el router descarta el paquete y devuelve un paquete de error (ICMP). El bit more_frags indica al destino que existen más trozos del paquete fragmentado. El último fragmento establece este bit a 0. (un paquete no fragmentado tiene este bit a 0). Si se configura la cabecera manualmente, se deberá establecer este bit a 0. EL campo frag_offset indica a qué zona del paquete pertenece el fragmento. Puesto que los fragmentos de los paquetes pueden viajar a través de diferentes rutas en la red, pueden llegar a su destino en momentos diferentes. El destino tiene que recomponer el paquete y usa el offset para colocar el fragmento en su localización correcta. El campo frag_offset es de sólo 13 bits de largo, demasiado pequeño para un paquete que puede llegar a ser de 64 BK. El offset se multiplica por 8 para colocar la posición del byte real en el paquete. Esto significa que cada fragmento (excepto el último) debe ser un múltiplo de 8. El subsistema IP administra completamente la fragmentación y recomposición del paquete, no hay que preocuparse de ello. Con estos campos y el ID del paquete, el subsistema IP puede fragmentar y recomponer el paquete. Si el subsistema no puede conseguir todos los trozos dentro de un tiempo específico, descarta el paquete y devuelve un error al origen. Campo time_to_live Este campo contaba originalmente con el número de segundos que un paquete podía permanecer en la red durante su tránsito. Después el significado cambió al número de saltos de router. Un salto es la transición a través de un host o router (nodo) donde el nodo traslada activamente un paquete de una red a otra. Este campo de 8 bits permite hasta 255 saltos de router antes de ser descartado. Cuando un router o host de reenvío obtiene el paquete, resta este campo en uno. Si el campo es igual a cero antes de la llegada al destino, el nodo descarta el paquete y envía un error al origen. El campo TTL evita que existan paquetes dando vueltas indefinidamente en la red. Campo protocol Cada paquete de Internet tiene un valor de protocolo asignado, ICMP (IPPROTO_ICMP o 1), UDP (IPPROTO_UDP p 17) y TCP (IPPROTO_TCP o 6) poseen cada uno un código- el protocolo indica al sistema cómo tratar el paquete entrante. Puede establecer este valor con la opción SOCK_RAW en la llamada del sistema socket(). El valor de protocolo es el último parámetro de la llamada. El archivo de cabecera netinet/in.h contiene muchos más valores. Preparado por Paulo A. González G. 42

4 Campo options IP puede pasar varias opciones con cada paquete. Estas opciones incluyen información de ruteo, marcas de tiempo medidas de seguridad, registro de enrutamiento y alarmas de caminos. Este campo puede llegar a ser de hasta 40 bytes de longitud. Debido que estas opciones dependen del sistema nunca se debe tocar estas opciones directamente. Campo data El mensaje se incluye en esta parte y puede alcanzar hasta bytes (menos 60 btes del tamaño de la cabecera). Esta sección de datos incluye cualquier información de cabecera que los protocolos de las capas superiores necesitan. Por ejemplo ICMP necesita 4 bytes, UDP necesita 8 bytes y TCP necesita de 20 a 60 bytes. Análisis de varios paquetes IP ofrece varios servicios que se clasifican desde muy rápidos a muy fiables. Todos estos se apoyan en la capa más baja, el paquete básico IP- pero cada capa se ha desarrollado para resolver problemas específicos. Para seleccionar el tipo de paquete se debe conocer lo que se transmite. Los tipos de paquetes que probablemente sean más de interés son: TCP. UDP. ICMP. RAW El conocer las ventajas y desventajas de cada tipo puede ayudar a la hora de elegir el más apropiado para cada aplicación. Ventajas de cada tipo de paquete: RAW ICMP UDP TCP Sobrecarga fija (bytes) [4] [8] [20-60] Tamaño del mensaje (bytes) Ilimitado Fiabilidad Baja Baja Baja Alta Tipo de mensaje Datagrama Datagrama Datagrama Flujo Rendimiento Alto Alto Medio Bajo Integridad de los datos Baja Baja Media Alta Fragmentación Si Si Si Baja Preparado por Paulo A. González G. 43

5 Cuestiones relacionadas con los paquetes Sobrecarga fija En la sobrecarga fija de protocolo se incluyen dos cosas: El tamaño de la cabecera en bytes La cantidad de interacción que el protocolo requiere. Una sobrecarga alta fija de paquete puede reducir el rendimiento, porque la red tiene que gastar más tiempo en trasladar cabeceras y menos tiempo de lectura de datos. Un protocolo robusto en sincronización e intercambio de señales incrementa la interacción de sobrecarga fija. Esto es más costoso en la red WAN debido a la propagación de retardos. Tamaño de mensaje de protocolo Para calcular el rendimiento de la red, se necesita conocer el tamaño del paquete y la sobrecarga fija del protocolo. El tamaño de transmisión le da el tamaño máximo de un mensaje enviado. Todos menos TCP usan un único mensaje, esta limitación es debida normalmente a las limitaciones del paquete IP (65535 bytes). La cantidad de datos que el programa transmite por paquete es el tamaño de transmisión menos las cabeceras. Fiabilidad de protocolo Parte del problema con las redes es la posibilidad de perder mensajes. Un mensaje se puede corromper o desechar cuando se traslada de un host o router a otro, o si galla o se rompe el propio host o router. En cada caso, un mensaje se puede simplemente perder, y el programa tendrá que repetirlo. Es probable que se quiera asegurar que el destino procesa los paquetes en orden correcto. Por ejemplo, se puede componer un mensaje que no cabe bien en un paquete, si el segundo paquete llega antes que el primero, el receptor debe conocer cómo identificar y corregir el problema. Sin embargo, el orden no es importante cuando cada mensaje es independiente y autocontrolado. La fiabilidad del paquete indica la certeza de seguridad de llegada de los mensajes y su orden. Baja fiabilidad significa que el protocolo no puede garantizar que el paquete alcance el destino o que los paquetes estén en orden. Tipos de mensaje de protocolo Algunos mensajes son autocontrolados e independientes de otros mensajes. Fotos, documentos, mensajes de , etc. Son algunos ejemplos que se pueden adaptar al tamaño del paquete. Otros se aparecen más a un flujo de corriente como sesiones Telnet, canales abierto de http, documentos, fotos o archivos grandes. El tipo de mensajes define qué estilo se adapta mejor a cada protocolo. Preparado por Paulo A. González G. 44

6 El protocolo http podría perfectamente usar UDP para la transferencia de mensajes en vez de TCP. El cliente envía la consulta de un documento específico, y el servidor responde con el archivo. Efectivamente, no se efectúa ninguna conversación entre el cliente y el servidor. Rendimiento de protocolo El aspecto más notable de la transmisión de datos es el rendimiento de la red. Al conseguir el valor máximo los usuarios se muestran felices. Para obtener el mejor funcionamiento se necesita conocer el rendimiento. Si las cabeceras son grandes y los datos pequeños, el resultado es un rendimiento bajo. La demanda de un acuse de recibo para cada mensaje reduce drásticamente el rendimiento. Por defecto, alta fiabilidad e integridad implican un bajo rendimiento y viceversa. Integridad de los datos de protocolo La tecnología del funcionamiento en red tiene actualmente bastantes medidas de seguridad para la integridad de los datos. Algunas interfaces de red incluyen una suma de comprobación o verificación por redundancia cíclica (CRC) en cada mensaje de bajo nivel. También incluyen tecnología hardware especial que puede filtrar el ruido y obtener el mensaje auténtico. Adicionalmente cada protocolo incluye medidas para detectar errores en los datos. Estos errores pueden o no ser importantes para el programador. La importancia de integridad de datos depende de los propios datos. Es decir, algunos requieren un seguimiento con mucho cuidado, mientras que datos menos importantes son menos críticos. A continuación se puede apreciar una breve descripción de algunos tipos de datos: Fallo intolerable: Datos críticos de vida. Cualquier cosa que pueda afectar a la salud o vida privada o pública. Por ejemplo señales de vida, o señales vitales del equipo médico y comandos de lanzamiento de misiles. Crítico: datos importantes y responsables. Datos que si están fuera de secuencia o defectuosos pueden causar daño a la propiedad o seguridad. Por ejemplo, transacciones financieras, tarjetas de crédito, número PIN, firmas digitales, dinero electrónico, secretos comerciales, actualizaciones de escáner de virus y actualizaciones de productos. Importante: datos que necesitan un funcionamiento correcto. Cualquier pérdida puede causar un mal funcionamiento. Por ejemplo descargas FTP, páginas web, direcciones de servidor o router y conexiones Telnet. Informativo: datos que pueden tener menos del 100% de fiabilidad para un funcionamiento correcto. Por ejemplo , publicidad y paginas web. Temporal: Datos que están asociados a la fecha y hora. Al menos que el programa usa esta información dentro de un tiempo específico se reduce su importancia. Por ejemplo, datos climáticos, datos de supervisión y datos horarios. Preparado por Paulo A. González G. 45

7 Desechable: datos que pueden degenerarse sin perder su utilidad. Son normalmente video y sonido. Por ejemplo películas, archivos de sonido, fotos y spam. Previamente a la elección del tipo de paquete o protocolo, se tienen que clasificar los datos de acuerdo a esta lista. También se tiene que incluir a las restricciones adicionales (o externas) del programa. Fragmentación de protocolo Mensajes grandes en redes lentas pueden frustrar mucho a un usuario. Todas las redes definen un tamaño de trama máximo para que esos mensajes grandes no saturen la red. Se recuerda que los router pueden dividir o fragmentar los mensajes grandes que atraviesan una red estrecha. Cada protocolo tiene una probabilidad distinta de fragmentación. Puesto que la recomposición de mensajes fragmentados es función de IP, la reagrupación se puede realizar de forma transparente a los protocolos de la capa superior. Sin embargo, existen ocasiones en las que se requiere que el mensaje esté completo. Esto es particularmente importante para el rendimiento de la red. Cuando los router dividen el paquete en trozos pequeños el router pierde tiempo en dividir el mensaje y los paquetes resultantes incrementan la sobrecarga fija. Al bloquear la fragmentación, la red descarta el paquete y devuelve un mensaje de error (paquete demasiado grande) al programa. TIPOS DE PAQUETE El paquete RAW Un paquete raw tiene acceso directo al paquete y la cabecera IP. Se usa en la programación de protocolos especiales o a medida. Sus atributos están listados en la siguiente tabla: Tamaño del mensaje (bytes) (65515 máxima carga útil de datos). Sobrecarga fija (bytes) De 20 a 60. Fiabilidad Baja (la red puede descartar o reconfigurar los paquetes). Tipo de mensaje Datagrama. Rendimiento Alto (baja sobrecarga fija del sistema). Integridad de los datos Baja (el sistema no valida el mensaje). Fragmentación Si. Preparado por Paulo A. González G. 46

8 Linux ofrece la opción de funcionar con capas distintas en la pila IP. El mensaje TCP/IP más básico es el mensaje IP Raw. No tiene información aparte de la más básica. Se puede usar el paquete IP para crear la capa más básica y así crear los propios protocolos a medida. Para acceder al paquete IP hay que seleccionar SOCK_RAW en la llamada del sistema socket(). Por seguridad, se debe tener privilegios de root para ejecutar un programa socket raw. El socket raw permite trabajar con las bases del paquete IP. Se puede configurar el socket para que funcione con dos niveles de detalle: El tratamiento de cabecera y datos. Sólo de datos. El tratamiento de los datos es parecido a la transmisión de datos UDP sin soporte de puertos. El tratamiento de la cabecera permite establecer directamente los campos cabecera. Con el uso de este mensaje se obtiene ventajas y desventajas. Al ser un mensaje datagrama no ofrece garantía de llegada o de la integridad de los datos, sin embargo se puede enviar o recibir mensajes casi a la velocidad de la red. Gestión de mensajes de error y control IP (ICMP) El protocolo de mensajes de control en internet (ICMP) es una de las capas construidas encima del paquete básico IP. Todos los computadores conectados a internet (host, clientes, servidores, router, etc) usan ICMP para el control o los mensajes de error. Se usan para el envío de mensajes de error o de control. Algunos programas de usuario también implantan este protocolo, como por ejemplo ping. Los atributos de ICMP se presentan en la siguiente tabla: Tamaño del mensaje (bytes) (65511 máxima carga útil de datos). Sobrecarga fija (bytes) De 24 a 64. Fiabilidad Baja (la red puede descartar o reconfigurar los paquetes). Tipo de mensaje Datagrama. Rendimiento Alto (baja sobrecarga fija del sistema). Integridad de los datos Baja (el sistema no valida el mensaje). Fragmentación Si. (pero es improbable) Si se implanta IC>MP en el programa se puede reusar el socket opara enviar mensajes a host distintos sin volver a abrit el socket. Los mensajes se pueden enviar usando la llamada del sistema SENDMSG() o SENDTO(). Estas llamadas necesitan una dirección de destino. Con un socket individual se pueden enviar mensajes a tantos puntos como se desee. Preparado por Paulo A. González G. 47

9 Las ventajas y desventajas de un paquete ICMP son esencialmente las mismas que en IP raw. Sin embargo el paquete incluye una suma de comprobación para la validación de los datos. También la probabilidad de que la red pueda fragmentar un paquete ICMP es muy pequeña. Esto se debe a la naturaleza de los mensajes ICMP, se usan para indicar los estados, los errores y el control. El mensaje no será muy grande. Aunque se puede usar ICMP en los mensajes propios, se usa habitualmente para mensajes de error y de control. Todos los mensajes del funcionamiento en red viajan por la red dentro de un mensaje ICMP. El paquete tiene una cabecera que incluye los códigos de error, y la parte de los datos puede contener un mensaje más específico describiendo el error. Como parte del protocolo IP, ICMP obtiene una cabecera IP y añade su propia cabecera. Definición de la estructura ICMP typedef unsigned char ui8; typedef unsigned short int ui16; struct ICMP_header { ui8 type; //tipo de error ui8 code; // código de error ui16 checksum; // suma de comprobación del mensaje uchar msg[]; //descripción de datos adicionales }; El tipo y código definen qué error se produjo. Msg puede ser cualquier información adicional para buscar detalladamente lo que salió mal. Protocolo de datagrama de usuario UDP El protocolo de datagrama de usuario se usa principalmente en las comunicaciones son conexión (mensajes independientes). Este puede enviar mensajes diferentes a destinos sin volver a crear los socket y actualmente es el protocolo sin conexión más común. Los atributos se pueden apreciar en la siguiente tabla: Tamaño del mensaje (bytes) (65507 máxima carga útil de datos). Sobrecarga fija (bytes) De 28 a 68. Fiabilidad Baja. Tipo de mensaje De un solo uso. Rendimiento Medio. Integridad de los datos Medio. Fragmentación Si. Preparado por Paulo A. González G. 48

10 Cada capa superior de la pila IP fija más su atención en los datos y menos en la red. UDP oculta algunos detalles de los mensajes de error y de cómo el kernel transmite los mensajes. También recompone un mensaje fragmentado. Un mensaje que se envía a través de UDP es como un mensaje , el destino, origen y datos es toda la información que necesita. El kernel toma el mensaje y lo pone en la red pero no verifica su llegada. Al igual que el paquete ICMP puede enviar a múltiples destinos desde un socket individual, usando distintas llamadas del sistema send(). No obstante sin la verificación se pueden alcanzar rendimientos máximos. Sin verificar la llegada, la red puede peder la fiabilidad de los datos. La red puede perder paquetes o fragmentarlos o corromper el mensaje. Los programas que usan UDP, bien siguen la pista de los mensajes o no les importa si se pierden o quedan corrompidos. La razón principal es su tolerancia a la pérdida de paquetes. Si la cama web falla para actualizar todos los pixeles, es improbable que el usuario lo advierta o le importa. Otro posible uso es un servicio horario exacto. Debido que la hora exacta es temporal, un host puede descartar un par de instantes de reloj sin pérdida de integridad. UDP ofrece la ventaja de mayor velocidad. Además se puede incrementar su fiabilidad de las siguientes formas: Dividir paquetes grandes. Se toma cada mensaje y se divide en porciones asignándole un número. El equipo del otro extremo recompone el mensaje. Recordar que más sobrecarga fija y menos envío de datos reducen el rendimiento. Seguir la pista de cada paquete. Se asigna un número único a cada paquete. Se fuerza al equipo homólogo a mandar un acuse de recibo de cada paquete porque sin acuse de recibo el programa reenvía el último paquete. Si el equipo homólogo no obtiene el paquete esperado, solicita un reenvío con el último número de mensaje o envía un mensaje de reanudación. Añadir una suma de comprobación. Se verifican los datos de cada paquete con una suma de datos. Una CRC es más fiable que una suma de comprobación, pero la suma de comprobación es más fácil de calcular. Si el equipo homólogo descubre que los datos están corruptos, le indica al programa que reenvíe el mensaje. Usar tiempos de espera. Se puede asumir que un tiempo de espera expirado implica que ha fallado. El origen puede retransmitir el mensaje y el receptor pueden enviar n recordatorio al emisor. UDP confía en las características y servicios de IP. Cada paquete de datagrama UDP recibe una cabecera UDP e IP. Preparado por Paulo A. González G. 49

11 Definición de la estructura UDP typedef unsigned char ui8; typedef unsigned short int ui16; struct UDP_header{ ui16 src_port; //número de puerto del origen ui16 dst_port; // número de puerto del destino ui16 length; // tamaño del mensaje ui16 checksum; // suma de comprobación del mensaje uchar data[]; //datos del mensaje }; UDP crea un receptáculo de red virtual para cada mensaje en forma de puertos. Con el puerto, IP puede repartir rápidamente los mensajes al propietario correcto. Aunque no se defina un puerto con bind(), el subsistema IP crea uno temporal para el programa. Protocolo para el control de la transmisión (TCP) El protocolo para el control de la transmisión es el protocolo de socket usado de forma más habitual en internet. Se pueden usar red() y write(), y se requiere volver a crear un socket para cada conexión. Los atributos se aprecian en la siguiente tabla Tamaño del mensaje (bytes) Ilimitado Sobrecarga fija (bytes) De 40 a 120. Fiabilidad Alta (recibo de datos comprobados). Tipo de mensaje Flujo Rendimiento Bajo (comparado con otros protocolos). Integridad de los datos Alta (incluye suma de comprobación). Fragmentación Improbable. Para conseguir una mayor fiabilidad se requiere la garantía de que el destino obtenga el mensaje exacto que el emisor envió. UDP tiene la velocidad pero no tiene la fiabilidad que necesitan muchos programas. TCP resuelve el problema de la fiabilidad. La red sin embargo tiene varios problemas que la hacen poco fiable. Estos problemas no son una limitación. De hecho son inherentes al diseño de la red. Intenet tienes tres obstáculos: 1. conexiones dinámicas. 2. pérdida de datos. 3. caminos reducidos. Conexiones dinámicas Un host envía un mensaje a otro host. Este mensaje viaja a través de las redes, atravesando varios routers. Cada mensaje enviado puede usar un camino distinto. Los Preparado por Paulo A. González G. 50

12 segmentos de red (conexiones entre computadores) a menudo aparecen y desaparecen cuando los servidores se inician y se apagan. La potencia de internet es su capacidad para adaptarse a los cambios y al ruteo o encaminamiento de la información. La adaptabilidad es una de las fuerzas impulsivas detrás de internet. El computador puede usar una consulta y la red intenta posibles vías para completar la orden. Desafortunadamente esta ventaja implica que el cambio entre el computado y el servidor o equipo homólogo puede cambiar alargando o acortando la distancia. Si el camino se alarga, el tiempo de propagación se incrementa. Esto significa que el programa puede enviar mensajes sucesivos y muchos llegarán a distinto tiempo, muchas veces desordenado. TCP garantiza que el destino ha recibido correctamente el último mensaje antes de enviar el siguiente. Se puede comparar esto a una serie de mensajes enumerados (así funciona TCP). El programa puede enviar 10 mensajes sucesivos. TCP toma cada mensaje, le adjunta un número único y lo envía. El destino acepta el mensaje y responde con acuse de recibo. Una vez recibido el acuse de recibo, TCP permite al programa enviar el siguiente mensaje. TCP usa una técnica mejor que el protocolo enviar-esperar (ACK/NACK) el cual es muy lento. En lugar de eso usa una ventana dividida, mide cuándo y con qué frecuencia responder con un ACK (acuse de recibo). Las conexiones lentas o malas pueden incrementar los mensajes de acuse de recibo. Conexiones rápidas y con menos pérdidas permiten que se envíen más mensajes antes de la recepción de acuse de recibo. Es parte del algoritmo de Nagle. Pérdida de datos Cuando el destino obtiene el mensaje, determina la integridad de los datos. Los datos pueden viajar a lo largo de caminos de comunicación poco óptimos, que pueden desechar o corromper los bits del mensaje. Se debe recordar que la red envía cada mensaje de bit en bit. TCP envía cn el mensaje una suma de comprobación para verificar los datos. TCP es la última capa que puede detectar y remediar datos erróneos. Si el destino detecta cualquier error, envía al emisor un error, solicitando una retransmisión al programa. Asimismo, si el computador no obtiene un acuse de recibo dentro de un tiempo determinado, el subsistema TCP reenvía automáticamente el mensaje sin la intervención del programa. Caminos reducidos Hablando de un mensaje individual enviado a un host particular, supongamos que el mensaje es demasiado grande para los segmentos que intervienen en el camino. Los problemas que el paquete encuentra cuando pasa a través de la red son las distancias tecnológicas y las portadoras de transmisión. Algunos computadores en red permiten paquetes extensos, otros colocan límites en el tamaño. Preparado por Paulo A. González G. 51

13 UDP intenta enviar el mensaje tan grande como pueda, esto puede ser un problema con los caminos reducidos de datos. Los algoritmos IP se adelantan a que los router puedan fragmentar los datos. De igual modo IP espera que recompongan el mensaje entrante. TCP por otra parte limita cada paquete a trozos pequeños. TCP divide mensajes grandes, antes de que la red tenga la oportunidad de tomarlos. TCP elige el tamaño en uno que la mayoría de las redes puedan dejarlo intacto. Por omisión TCP usa 536 bytes y negocia normalmente hasta Para incrementar ese tamaño manualmente hay que establecer la opción de socket TCP MSS (tamaño de segmento máximo). El receptor se puede encontrar que los paquetes del mensaje están desordenados. TCP los ordena antes de pasar el mensaje al programa. La solución a todos estos problemas de red es añadir sobrecarga de cabecera y protocolo al algoritmo TCP. Por supuesto, la sobrecarga fija añadida de todas las técnicas TCP reducen el rendimiento en forma notable. Definición de la cabecera TCP. TCP tuvo que añadir bastante información a su cabecera para soportar todas las características que ofrece. El tamaño en bytes de la cabecera TCP es unas tres veces el de la cabecera UDP. Definición de la estructura: typedef unsigned char ui8; typedef unsigned short int ui16; typedef unsigned int ui32; typedef unsigned int uint; struct TCP_header { ui16 src_port; // número de puerto del origen ui16 dst_port; // número de puerto del destino ui32 seq_num; // número de secuencia ui32 ack_num; //número de acuse de recibo uint data_off: 4; //offset de los datos uint _res: 6; // reservado uint urg_flag: 1; // urgente, mensaje fuera de banda uint ack_flag: 1; //campo de acuse de recibo válido uint psh_flag: 1; //colocar el mensaje a procesar inmediatamente uint rst_flag: 1; //reiniciar la conexión debido a errores uint syn_flag: 1; // abrir una conexión virtual (canal) uint fin_flag:1 ; //conexión cerrada ui16 window; //cuantos bytes se permiten recibir ui16 checksum; //suma de comprobación del mensaje Preparado por Paulo A. González G. 52

14 ui16 urg_pos; //ultimo byte de un mensaje urgente ui8 options[]; //opciones TCP ui8 _padding[]; //necesitado para alinear data[] uchar data[]; //datos del mensaje La cabecera puede tener un tamaño variable, así el campo data_off apunta hacia el principio de los datos. Para guardar el espacio de cabecera, este campo actúa como el header_len de IP, asignando el número de words de 32 bits que físicamente procede los datos. TCP usa algunos de los campos exclusivamente para la apertura de la conexión, control de flujo y cierre de la conexión. Durante una sesión de comunicación, algunas de las cabeceras están vacías. La cabecera TCP usa el mismo número de puerto encontrado en UDP. Pero seq_num y ack_num ofrecen seguimiento al flujo. Cuando envía un mensaje, el subsistema IP adjunta un número de secuencia (seq_num). El receptor responde que obtuvo el mensaje con un número de acuse de recibo (ack_num) que es superior en 1 al número de secuencia. Esta característica permite que los paquetes de acuse de recibo transporten también datos. Observación de las interacciones TCP Cuando se abre una conexión de generación de flujo, el programa y el servidor intercambian una serie de mensajes, los cuales aparecen relacionados y descritos a continuación: Intercambio de señales de tres direcciones: Envíos del cliente Envíos del servidor Descripción SYN = 1 (syn_flag) Consulta una conexión virtual (canal) ACK = 0 (ack_flag) Establece el número de secuencia. SYN = 1 (syn_flag) Permite y acusa recibo de una conexión virtual. ACK = 1 (ack_flag) SYN = 0 (syn_flag) ACK = 1 (ack_flag Establece la conexión virtual. Esto se llama intercambio de señales de tres direcciones. Durante la transferencia el cliente, y el servidor especifican el tamaño de buffer de sus buffers de recepción (ventanas). Por otra parte, el cierre de una conexión no es una tarea tan simple como puede parecer inicialmente, debido a que puede darse el caso de que existan datos en tránsito. Cuando el cliente cierra una conexión puede ocurrir la siguiente interacción: Preparado por Paulo A. González G. 53

15 Cierre de una conexión TCP Cliente Servidor Descripción FIN = 1 Transmite El cliente solicita cerrar. (fin_flag) datos Recibe datos ACK = 1 Transmite más El servidor vacía los canales. Recibe más ACK = 1 FIN = 1 Cierre aceptado. El servidor cierra y espera un ACK del cliente. ACK = 1 El cliente cierra su lado. El cierre de la conexión TCP hace imposible la reutilización del socket para otras conexiones. Por ejemplo, si se conecta a un servidor, la única forma de cortar la conexión es cerrando el canal, lo cual cierra también el socket. Si entonces se requiere conectar a otro servidor, se debe crear un socket nuevo. Los otros protocolos no tienen esta limitación. Preparado por Paulo A. González G. 54