Nivel de Transporte: Introducción, UDP y TCP
Transcripción
Nivel de Transporte: Introducción, UDP y TCP
TEMA 1: Introducción a las Redes de Telecomunicaciones Redes de Ordenadores 1. 2. 3. 4. 5. Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. Nivel de Transporte: Introducción, UDP y TCP 1.1. ¿Qué es una Red de Telecomunicaciones? Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) FUENTE Sistema Origen Transmisor Sistemas de Transm Receptor DESTINO Sistema Destino 2 Objetivos ‣ Conceptos y principios del nivel de transporte TEMA 1: Introducción a las Redes de Telecomunicaciones > > > > ‣ 1. 2. 3. 4. 5. Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. Multiplexación Transporte fiable Control de flujo Control de congestion Estudio del nivel de transporte en Internet > Protocolos TCP y UDP 1.1. ¿Qué es una Red de Telecomunicaciones? Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) FUENTE Sistema Origen Transmisor Sistemas de Transmisión Receptor DESTINO Sistema Destino 2 Funciones del nivel de transporte ‣ ‣ Comunicación lógica entre aplicaciones Protocolo en los extremos (end-to-end) TEMA 1: Introducción Transporte a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. > > ‣ Red Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. Enlace Red Enlace Red segmentación reensamblado Enlace Red 2 niveles de transporte en Internet 1.1. ¿Qué es una Red de Telecomunicaciones? > > TCP UDP Canal lógico Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) FUENTE Sistema Origen Transmisor Sistemas de Transmisión Enlace Red Enlace Transporte Red Receptor DESTINO Enlace Sistema Destino 2 Red y transporte ‣ Nivel de red Comunicación lógica entre hosts Nivel de transporte Comunicación lógica entre procesos TEMA 1: Introducción a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. ‣ > Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. mejora y utiliza la comunicación entre hosts App 1 App 1 1.1. ¿Qué es una Red de Telecomunicaciones? Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) Transporte Red Red FUENTE Enlace Sistema Origen Transmisor Sistemas de Transmisión Enlace Transporte Red Receptor Sistema Destino Enlace Red Red Enlace Enlace DESTINO 2 Transporte en Internet ‣ Entrega fiable y en orden (TCP) TEMA 1: Introducción a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. > > > ‣ Transporte Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. control de congestión control de flujo establecimiento de conexión Red Enlace Red Enlace Red Entrega no fiable, sin garantias de orden (UDP) Enlace Red 1.1. ¿Qué es una Red de Telecomunicaciones? > ‣ Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) best-effort igual que IP En los dos casos FUENTE > > Transmisor Sistemas de Transmisión retardo no garantizado ancho de banda no garantizado Sistema Origen Receptor Red Enlace Enlace Transporte DESTINO Red Sistema Destino 2 Enlace Funciones TCP/UDP ‣ Función común Multiplexación/demultiplexación de aplicaciones TEMA 1: Introducción a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. ‣ Funciones sólo UDP > ‣ Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. Envio no orientado a conexión 1.1. ¿Qué es una Red de Telecomunicaciones? Funciones sólo TCP > > > Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) Manejo de conexiones Transporte fiable de datos Control de flujo y de congestión FUENTE Sistema Origen Transmisor Sistemas de Transmisión Receptor DESTINO Sistema Destino 2 Multiplexación y demultiplexación ‣ Un host con varias aplicaciones/programas/ procesos corriendo TEMA 1: Introducción a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. > El nivel de red envía los paquetes al nivel de red del ordenador destino > El nivel de transporte arbitra la comunicación entre diferentes aplicaciones un nivel de red, un nivel de transporte, varias aplicaciones > Aplicación 1 Aplicación 2 Aplicación 3 Aplicación 4 1.1. ¿Qué es una Red de Telecomunicaciones? Transporte Red Transporte Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) Emisor: ‣ recoger datos de distintas fuentes ‣ encapsular con información del origen FUENTE Sistema Origen Transmisor Sistemas de Transmisión Receptor Red DESTINO Sistema Destino 2 Receptor: ‣ entregar a la aplicación (socket) correcta Multiplexación y demultiplexación ‣ El host recibe datagramas IP TEMA 1: Introducción a las Redes de Telecomunicaciones > > > 1. 2. 3. 4. 5. Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. Cada datagrama IP lleva una dirección IP de origen y de destino Cada datagrama IP lleva un segmento del nivel de transporte Cada segmento del niel de transporte lleva un puerto origen y destino (puerto: identificador de proceso/aplicación) Cabecera IP ... puerto origen puerto destino cabecera de transporte 1.1. ¿Qué es una Red de Telecomunicaciones? ‣ El nivel de transporte usa las direcciones IP y los puertos para decidir a quien entrega los datos Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) FUENTE Sistema Origen Transmisor Sistemas de Transmisión Receptor Datos aplicación DESTINO Sistema Destino 2 Segmento del nivel de transporte Demultiplexación no orientada a conexión Cuando UDP recibe un paquete... ‣ Se extraen de la cabecera proceso 1 IP la dirección IP destino y de la cabecera UDP el puerto destino 80 sockets ‣ Se entregan los datos al S1 socket identificado por la tupla TEMA 1: Introducción a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. proceso 2 6881 S2 1.1. ¿Qué es una Red de Telecomunicaciones? Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) (dirIP destino, puerto destino) ‣ Paquetes provenientes de diferentes direcciónes origen y puertos origen se entregan al mismo socket FUENTE Sistema Origen Transmisor Sistemas de Transmisión Receptor DESTINO Sistema Destino 2 UDP 1234 S3 Demultiplexación no orientada a conexión ‣ Ejemplo TEMA 1: Introducción a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. SP: source port DP: destination port Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. P2 P1 P1 P3 SP: 6428 DP: 9157 SP: 6428 DP: 5775 1.1. ¿Qué es una Red de Telecomunicaciones? client IP: A SP: 9157 DP: 6428 FUENTE ‣ SP: 5775 DP: 6428 Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) server IP: C Transmisor Sistemas de Transmi Receptor Client IP:B DESTINO La dirección origen y puerto origen permiten responder al cliente Sistema Origen Sistema Destino 2 / 11 Demultiplexación orientada a conexión ‣ ‣ Cuando TCP recibe un paquete puede pertenecer a varias conexiones establecidas Varios sockets con el mismo puerto... TEMA 1: Introducción a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. 80 23421 CNX establecida S4 TCP S12y3 23421 CNX establecida 1.1. ¿Qué es una Red de Telecomunicaciones? TCP ‣ proceso 3 proceso 2 proceso 1 S5 TCP Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) FUENTE Transmisor Sistemas de Transmisión Receptor DESTINO Se entrega al socket identificado por la 4-tupla Sistema Origen Sistema Destino (dirIP origen, puerto origen, dirIP destino, puerto destino) 2 Demultiplexación orientada a conexión ‣ Ejemplo TEMA 1: Introducción a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. P1 P4 P5 client IP: A 1 SP: 9157 DP: 80 S-IP: A D-IP:C P2 P6 1.1. ¿Qué es una Red de Telecomunicaciones? SP: source port S-IP: source IP DP: destination port D-IP: destination IP Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. SP: 5775 DP: 80 S-IP: B D-IP:C Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) FUENTE Sistema Origen Transmisor Sistemas de Transmisión server IP: C Receptor P1P3 SP: 9157 DP: 80 DESTINO Sistema Destino 2 S-IP: B D-IP:C Client IP:B Demultiplexación orientada a conexión ‣ Otro ejemplo TEMA 1: Introducción a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. P1 P2 P4 1.1. ¿Qué es una Red de Telecomunicaciones? client IP: A 1 SP: source port S-IP: source IP DP: destination port D-IP: destination IP Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. SP: 9157 DP: 80 S-IP: A D-IP:C SP: 5775 DP: 80 S-IP: B D-IP:C Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) FUENTE Sistema Origen Transmisor Sistemas de Transmisión server IP: C Receptor P1P3 SP: 9157 DP: 80 DESTINO Sistema Destino 2 S-IP: B D-IP:C Client IP:B UDP: User Datagram Protocol ‣ ‣ UDP: User Datagram Protocol (RFC-768) Proporciona un servicio de transporte para aplicaciones sobre IP de tipo Best-Effort TEMA 1: Introducción a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. > > > > ‣ Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. Sin garantizar la entrega Sin garantizar el orden de entrega Mucho menos con tiempo o con ancho de banda garantizado Lo único que añade a IP es la multiplexación de aplicaciones y detección de errores 1.1. ¿Qué es una Red de Telecomunicaciones? Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) No orientado a conexión > > No hay establecimiento Cada datagrama se trata independientemente (protocolo sin estado) FUENTE Sistema Origen Transmisor Sistemas de Transmisión Receptor DESTINO Sistema Destino 2 UDP ¿Por qué un protocolo como UDP? ‣ Es rapido: no hay establecimiento aunque no garantice el retardo no añade retardos innecesarios ‣ Es simple: no hay estado de conexión ni en el emisor ni en el receptor ‣ Poco overhead la cabecera UDP ocupa lo mínimo posible ‣ Es eficiente: no hay control de congestión puede usar todo el ancho de banda que consigas TEMA 1: Introducción a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. 1.1. ¿Qué es una Red de Telecomunicaciones? Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) FUENTE Sistema Origen Transmisor Sistemas de Transmisión Receptor DESTINO Sistema Destino 2 UDP: detalles 32 bits Formato del paquete ‣ puerto origen ‣ puerto destino ‣ longitud del segmento UDP TEMA 1: Introducción a las Redes de Telecomunicaciones > ‣ 8 - 65535 bytes checksum sólo 8 bytes de cabecera ! Cabecera IP ... Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. segmento UDP 1. 2. 3. 4. 5. puerto origen longitud Datos aplicación 1.1. ¿Qué es una Red de Telecomunicaciones? Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) FUENTE Sistema Origen Transmisor Sistemas de Transmisión Receptor puerto destino checksum DESTINO Sistema Destino 2 UDP: checksum ‣ 32 bits Cálculo del checksum TEMA 1: Introducción a las Redes de Telecomunicaciones > > 1. 2. 3. 4. 5. dirección IP origen dirección IP destino Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. Se trata el segmento como serie de valores de 16 bits Suma binaria en complemento a 1 + pseudo-cabecera con algunos campos de la cabecera IP (para proteger errores en las direcciones y el protocolo) 0s proto puerto origen longitud longitud UDP puerto destino checksum Datos aplicación 1.1. ¿Qué es una Red de Telecomunicaciones? + ‣ segmento UDP Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) Detecta errores en todo el segmento UDP (aunque no todos) Si UDP detecta errores en un paquete recibido no lo entrega FUENTE ‣ Sistema Origen Transmisor Sistemas de Transmisión Receptor DESTINO Sistema Destino 2 UDP En que se usa UDP ? ‣ Aplicaciones de streaming multimedia (audio/ video en tiempo real o audio/videoconferencia) TEMA 1: Introducción a las Redes de Telecomunicaciones 1. 2. 3. 4. 5. > ‣ Modelo Genérico. Clasificación de las Redes de Telecomunicaciones. Estructura de Internet. Retardos en Redes de Telecomunicaciones. Modelo de Referencia TCP/IP. tolerantes a las pérdidas y sensibles al ancho de banda Mensajes de DNS 1.1. ¿Qué es una Red de Telecomunicaciones? > ‣ Es una Infraestructura. Proporciona comunicación entre múltiples entidades. De una manera eficiente. Usando distintas tecnologías (eléctricas, electrónicas, electromagnéticas, ópticas,…) SNMP (monitorización de red) > ‣ bajo retardo y poco overhead poco overhead y protocolo sencillo Juegos en red > FUENTE Sistema Origen mínimo retardo posible Transmisor Sistemas de Transmisión Receptor DESTINO Sistema Destino 2 Transporte fiable ‣ ¿Se puede conseguir un transporte fiable sobre un nivel de datagramas de entrega no fiable? t_envia(datos) t_recibe(datos) Nivel de Transporte r_envia(datos) r_recibe(datos) Nivel de Red Entrega no garantizada se pueden perder datos Protocolo de transporte fiable ‣ Descripción con máquinas de estados finitos. Notación Otro estado Un estado Una transición Evento que causa la transición Acciones que provoca la transición ‣ Ejemplo: protocolo de transporte sobre un nivel de red fiable Receptor r_recibe(p) t_envia(datos) Emisor datos= extrae(p) Espera llamada de app 10 octubre 2005 Espera llegada de datos p= paquete(datos) r_envia(p) t_recibe(datos) red fiable: r_envia(p) siempre causa un r_recibe(p) Transporte-2 4 /24 Errores de bit )P ‣ nivel de red puede cambiar bits (probabilidad de error) Cambios necesarios en el protocolo de transporte > > > Detección de errores + Uso de checksum Comunicación de fallos al emisor + ACK (acknowledgement): avisar al emisor de los paquetes que recibimos + NACK (negative acknowledgement): avisar al emisor de los paquetes que no recibimos Reenvío de paquetes Protocolo de transporte fiable ‣ Para un canal con errores de bits Emisor t_envia(datos) p= paquete(datos) r_envia(p) Espera llamada de app r_recv(datos) == NACK r_envia(p) Espera ACK o NACK Receptor r_recv(datos) == ACK nada r_recibe(p) con error r_envia(NACK) ‣ ‣ Espera llegada de datos r_recibe(p) sin error datos= extrae(p) t_recibe(datos) r_envia(ACK) Más conocido como Stop-and-Wait ¿Tiene algun problema este protocolo? Problemas con stop-and-wait ‣ ‣ ‣ ¿Qué pasa si hay un error en la transmisión del ACK o NACK? ¿Qué pasa si el canal puede perder paquetes? Soluciones complican el protocolo > > > ‣ Detección de errores para ACK y NACK? Checksums que permitan no solo detectar sino corregir errores? Reenviar los datos si no entiendo el ACK/NACK ?? + Nuevo problema: paquetes duplicados Los protocolos más usados utilizan contra esto numeros de secuencia del paquete Protocolo con número de secuencia ‣ Cada paquete de datos lleva un numero de secuencia 0 o 1 > > Si llega el que esperamos mandamos ACK y lo entregamos Si llega el que no esperamos mandamos ACK pero no son datos nuevos r_recibe(datos) sin error y seq 0 datos= extrae(p) t_recibe(datos) r_envia(ACK) r_recibe(datos) con error r_recibe(datos) con error r_envia(NACK) r_envia(NACK) r_recibe(datos) sin error y seq 1 r_envia(ACK) Espera paquete 0 Espera paquete 1 r_recibe(datos) sin error y seq 0 r_recibe(datos) sin error y seq 1 datos= extrae(p) t_recibe(datos) r_envia(ACK) r_envia(ACK) Protocolo con número de secuencia ‣ Estados del emisor t_envia(datos) p= paquete(datos,0) r_envia(p) r_recibe(datos) con error o ack 1 r_envia(p) Espera datos app 0 Espera ACK 0 r_recibe(datos) sin error y ack 0 r_recibe(datos) sin error y ack 1 Espera datos app 1 Espera ACK 1 r_recibe(datos) con error o ack 0 r_envia(p) t_envia(datos) p= paquete(datos,1) r_envia(p) Protocolo con número de secuencia ‣ Podemos eliminar los NACKs > > > ‣ En lugar de un ACK enviamos ACK y la secuencia del siguiente paquete que esperamos recibir En lugar de un NACK enviamos ACK y la secuencia del siguiente paquete que esperamos recibir El emisor sabe que tiene que reenviar si recibe el ACK del paquete que no espera Problema pendiente: ¿Qué pasa si se pierde un paquete? s0 s1 s0 s0 ack1 ack0 ack0 ack1 Pérdidas de paquetes ‣ ‣ Si se pierde un paquete el emisor se queda bloqueado en un estado Para romper el bloqueo usamos un temporizador en el emisor > > ‣ Al enviar un paquete de datos ponemos en marcha un temporizador Si transcurrido un tiempo, no se ha recibido ACK (TIMEOUT), reenviamos el paquete El receptor no se modifica Protocolo con timeout ‣ Emisor con retransmisión por timeout t_envia(datos) p= paquete(datos,0) r_envia(p) inicia_temp() timeout Espera datos app 0 Espera ACK 0 para_temp() para_temp() Espera datos app 1 Espera ACK 1 r_envia(p) inicia_temp() t_envia(datos) r_recibe(datos) con error o ack 0 r_envia(p) inicia_temp() r_recibe(datos) sin error y ack 0 r_recibe(datos) sin error y ack 1 timeout r_recibe(datos) con error o ack 1 p= paquete(datos,1) r_envia(p) inicia_temp() Ejemplos Emisor r_send(paq0) r_recv(ack0) r_send(paq1) r_recv(ack1) r_send(paq0) Emisor r_send(paq0) Receptor paq0 ack0 r_recv(ack0) r_recv(paq0) r_send(paq1) r_send(ack0) Receptor paq0 ack0 r_recv(paq0) r_send(ack0) paq1 perdido paq1 ack1 paq0 ack0 r_recv(paq1) r_send(ack1) timeout r_send(paq1) paq1 r_recv(paq0) r_recv(ack1) r_send(ack0) r_send(paq0) ack1 paq0 ack0 r_recv(paq1) r_send(ack1) r_recv(paq0) r_send(ack0) Operación normal Pérdida de paquete 1 Ejemplos Emisor r_send(paq0) r_recv(ack0) r_send(paq1) Emisor Receptor paq0 ack0 r_recv(ack0) r_recv(paq0) r_send(paq1) r_send(ack0) r_recv(paq1) r_send(ack1) perdido r_recv(ack1) r_send(paq0) paq0 ack0 paq1 ack1 timeout r_send(paq1) ack1 paq0 r_recv(ack1) r_recv(paq1) r_send(paq0) r_send(ack1) r_recv(ack1) ack0 r_recv(paq0) r_send(ack0) Pérdida de ACK r_recv(paq0) r_send(ack0) paq1 paq1 ack1 timeout r_send(paq1) r_send(paq0) Receptor paq1 paq0 ack1 r_recv(paq1) r_send(ack1) r_recv(paq1) (detecto duplicado) r_send(ack1) ignorado ack0 Timeout prematuro 1 Prestaciones ‣ ‣ El protocolo anterior es fiable pero es muy poco eficiente Ejemplo: Enlace de 1Gbps con un retardo de 15ms (4500Km), paquetes de 1000 bytes A que velocidad puedo enviar? RoundTripTime =30ms tam 8000bits v= = = 266Kbps RoundTripTime .03s 0.026% !! :-( Protocolos más eficientes ‣ Para aumentar la eficiencia, se envían varios paquetes mientras llega el ACK Varios paquetes en la red por confirmar > > > Se usan más números de secuencia que 0 y 1 Emisor y receptor necesitarán buffer para varios paquetes Varias políticas para reaccionar a los errores Emisor Receptor + Go-Back N paq 0 + Selective reject paq 1 ack 0 paq 2 paq 3 Go back-N ‣ ‣ ‣ ‣ ‣ Se utiliza número de secuencia en el paquete Se permite una ventana de N paquetes sin confirmar Cada ACK confirma todos los paquetes anteriores (cumulative ACK) Cada paquete inicia su propio timeout Si caduca el timeout de un paquete se retransmiten todos los siguientes Go back-N ‣ Ventana deslizante enviados no ACKed transmitidos ACKed se pueden enviar Ventana de N paquetes Llega este ACK no se pueden enviar Timeout del primer paquete pueden enviarse nuevos paquetes La ventana se desliza hacia mayores números de secuencia Volvemos a enviar Go back-N Ventana de 4 paquetes ... Emisor paq 0 paq 1 paq 2 paq 3 paq 4 paq 5 timeout paq 2 paq 2 paq 3 paq 4 paq 5 Receptor ack 0 ack 1 ack 1 ack 1 ack 1 ack 2 ack 3 ack 4 Selective Reject ‣ El receptor confirma (ACK) individualmente cada paquete > Mantiene en buffer los paquetes recibidos a la espera de reconstruir la secuencia y pasarlos al nivel de aplicación Ventana ‣ Se reenvian los paquetes no confirmados por timeout > ‣ paquetes recibidos que no pueden pasarse todavía al nivel de aplicacion Timeout individual por cada paquete Ventana de N paquetes que pueden enviarse sin recibir ACK Selective Reject ‣ Ventana deslizante del emisor enviados no ACKed transmitidos ACKed ‣ confirmados se pueden ACKed enviar Ventana de N paquetes no se pueden enviar Ventana deslizante del receptor esperados confirmados y entregados recibidos y confirmados en espera de poder entregarse aceptables Ventana de N paquetes no aceptables fuera de la ventana Selective reject Ventana de 4 paquetes Emisor paq 0 paq 1 paq 2 paq 3 paq 4 paq 5 Receptor ack 0 ack 1 ack 3 ack 4 ack 5 timeout paq 2 ack 2 ... paq 5 El problema del selective reject ‣ ‣ Número de secuencia finito Ejemplo > > ‣ ‣ ‣ seq= {0,1,2,3} N=3 El receptor no puede notar la diferencia entre los dos escenarios Y entrega datos duplicados como buenos Que relación debe haber entre #secuencia y N? 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 paq duplicado entregado !!! 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 paq correcto entregado TCP ‣ ‣ Protocolo de transporte de Internet (RFC 793) Transporte fiable > > ‣ Orientado a conexión > > ‣ Entrega garantizada Entrega en orden Stream bidireccional (como si fuera un fichero) entre los dos extremos No mantiene las fronteras de los mensajes Con control de flujo y congestión TCP ‣ Interfaz con el nivel de aplicación > > > Tras establecer una conexión proporciona un stream bidireccional entre sockets Sin fronteras entre mensajes 2 buffers por conexión + + Escribir en el socket pone los datos en buffer de envio Buffer de recepción para esperar el read() TCP TCP connexión connexión connexión IP connexión connexión IP IP IP connexión TCP ‣ Demultiplexación de datos que llegan a TCP: > Se identifica al socket destino por la tupla ( IP origen, puerto origen, IP destino, puerto destino ) > ‣ La tabla de tuplas (ip,puerto,ip,puerto) con sus sockets de un nivel TCP es la tabla de conexiónes. La conexión sólo existe en los extremos TCP write(datos) puertos A1 A2 A3 TCP connexión connexión connexión IPB, puertoB1, IPA, puertoA1 : cnx1 IPB, puertoB3, IPA, puertoA2 : cnx2 IPX, puertoP , IPA, puertoA3 : cnx3 host IPA read(datos) puertos B1 B3 Tabla de conexiones Paquete a IPB puertoB3 TCP connexión connexión IPA, puertoA1, IPB, puertoB1 : cnx1 IPA, puertoA2, IPB, puertoB3 : cnx2 ... recibido paquete host IPB TCP ‣ Los buffers aislan a TCP de las operaciónes del usuario. > > ‣ Para realizar esto TCP necesitara un conjunto de mensajes para comunicarse con el TCP del otro lado > > > ‣ TCP hará lo posible por enviar los datos cuando pueda TCP colocara los datos en el buffer de recepción cuando lleguen Mensajes de establecimiento y cierre de conexión Mensajes de datos Mensajes con ACKs Veamos los mensajes del protocolo TCP TCP > ‣ 20 hasta 60 bytes según las opciones Datos del nivel de aplicación Cabecera IP ... 20 bytes obligatorios ‣ Segmento TCP Cabecera de tamaño variable Cabecera TCP ‣ 32 bits puerto origen puerto destino numero secuencia numero ack HL nada flags ventena recep. checksum urgent data ptr opciones Datos aplicación TCP Contenido ‣ Datos de multiplexación > > Puerto origen Puerto destino Cabecera IP ... puerto origen puerto destino numero secuencia numero ack HL nada flags ventena recep. checksum urgent data ptr opciones Datos aplicación TCP Contenido ‣ Datos para transporte fiable > Número de secuencia > Número de ACK Checksum Cabecera + datos de applicación + algunos datos de IP (pseudo cabecera como en UDP) > ‣ En un mismo paquete podemos mandar datos y confirmar datos del sentido contrario Cabecera IP ... puerto origen puerto destino numero secuencia numero ack HL nada flags ventena recep. checksum urgent data ptr opciones Datos aplicación TCP Contenido ‣ FLAGs: diferentes tipos de paquetes del protocolo > > > > > > URG ACK PSH RST SYN FIN urgente acknowledgement push reset syn fin Cabecera IP ... puerto origen puerto destino numero secuencia numero ack HL nada flags ventena recep. checksum urgent data ptr opciones Datos aplicación TCP Contenido ‣ Control de flujo > ‣ ‣ Datos urgentes HL (header length) > > ‣ ventana de recepción Tamaño de la cabecera (en palabras de 4 bytes) 4 bits de de 5 a 15 palabras de 20 a 60 bytes Opciones extras Cabecera IP ... puerto origen puerto destino numero secuencia numero ack HL nada flags ventena recep. checksum urgent data ptr opciones Datos aplicación TCP ‣ ‣ Permiten especificar operaciones y tipos de paquetes que se han ido añadiendo posteriormente al protocolo Las opciones se colocan seguidas. 2 formatos > > ‣ opciones de 1 byte opciones de varios bytes tipo tipo longitud variable Opciones básicas > > > 00000000 Fin-de-la-lista de opciones No-operacion (para rellenar) 00000001 Maximum segment size 00000010 00000100 max seg size Permite descubrir el tamaño máximo de segmento en una conexión TCP: envío de datos ‣ ‣ 0 No hay separación de paquetes. Los bytes a enviar se colocan en el buffer y forman una corriente de bytes sin fronteras de paquetes El número de secuencia y el numero de ACK hacen referencia al byte concreto 17 51 Buffer Datos de aplicacion a enviar al otro extremo... y no tienen fronteras de mensajes... seq # =17 on a enviar al otro extremo... y n o tienen fronteras de mensajes Segmentos TCP seq # =51 TCP: envío de datos ‣ Secuencia y ACK: campos de 32 bits > > ‣ El campo ACK > > ‣ 4 Gb de datos para dar la vuelta La secuencia no empieza de 0 sino que se genera al azar al principio de cada conexión y para cada sentido es valido si esta activado el flag ACK indica la próxima secuencia que el receptor espera recibir cumulative ACK: Go back N a nivel de byte Si una conexión está transmitiendo en ambos sentidos los ACKs de un sentido van en los paquetes de datos del opuesto piggyback Ejemplo ‣ Paquetes de un telnet desde 10.1.1.253 a 10.1.1.22 Cliente el usuario pulsa la letra ‘c’ conexión establecida seq=6 ack=16 datos=’c’ seq=16 ack=7 datos=’c’ el cliente del usuario confirma la recepción Servidor seq=7 ack=17 nodatos el servidor recibe la letra ‘c’ y se la envia al usuario para que aparezca en pantalla Ejemplo ‣ ‣ Paquetes de un telnet desde 10.1.1.253 a 10.1.1.22 Usando tcpdump para ver los paquetes Tiempo 1124031783.543465 1124031783.544283 1124031783.544303 1124031783.652335 1124031783.653109 1124031783.653123 1124031783.798259 1124031783.798918 1124031783.798932 secuencia 10.1.1.253.48129 > 10.1.1.22.23: 10.1.1.22.23 > 10.1.1.253.48129: 10.1.1.253.48129 > 10.1.1.22.23: 10.1.1.253.48129 > 10.1.1.22.23: 10.1.1.22.23 > 10.1.1.253.48129: 10.1.1.253.48129 > 10.1.1.22.23: 10.1.1.253.48129 > 10.1.1.22.23: 10.1.1.22.23 > 10.1.1.253.48129: 10.1.1.253.48129 > 10.1.1.22.23: Origen { ip, puerto } Destino { ip, puerto } P P . P P . P P . ack paquete sin datos 6:7(1) ack 16 win 1460 16:17(1) ack 7 win 5792 ack 17 win 1460 7:8(1) ack 17 win 1460 17:18(1) ack 8 win 5792 ack 18 win 1460 8:10(2) ack 18 win 1460 18:20(2) ack 10 win 5792 ack 20 win 1460 Datos urgentes ‣ Si URG está activado. > El paquete lleva datos urgentes. > Canal de datos Out-of-band El puntero urgente indica donde acaban los datos urgentes > > ‣ Los datos normales se entregan normalmente en el buffer para la aplicación Los datos urgentes se entregan aparte No se usa mucho En sockets los datos urgentes hay que pedirlos con setsockopt Cabecera IP ... puerto origen puerto destino numero secuencia numero ack HL nada flags ventena recep. checksum urgent data ptr opciones Datos urgentes Datos normales TCP: transporte fiable ‣ TCP utiliza una ventana deslizante > > ‣ Los paquetes TCP llevan > > > ‣ Número de secuencia: el primer byte enviado en el segmento ACK: el próximo byte que espera recibir el receptor Número de secuencia de los datos. Si no llevan datos, el campo número de secuencia indica el proximo numero de secuencia que se enviará Próximo número de secuencia que espera recibir su emisor. Es válido si el byte ACK está activado Los números de secuencia son independientes en ambos sentidos Transmisiones simultáneas en los dos sentidos Cada extremo funciona como un emisor y un receptor independientes TCP: emisor ‣ Eventos en el emisor Llegan datos desde el nivel de aplicacion ‣ crear segmento nuevo ‣ sec # el siguiente de la stream ‣ iniciar temporizador si no hay uno iniciado timeout ‣ retransmitir el segmento que causó el timeout ‣ reiniciar timeout recibido ACK ‣ Si confirme un segmento nuevo > actualizar ventana EcumulativE ACK > reiniciar timeout si quedan segmentos por confirmar Ejemplos Emisor Emisor sendbase=92 8bytes Receptor 20bytes sec=92 datos 8B ack 100 sec =92 sec dat os =10 sec=92 datos 8B ack 100 timeout sendbase=92 8bytes Receptor timeout sec sendbase=120 sendbase=100 0 d ato s2 0B =92 sendbase=100 8B dat os 8 0 2 1 k B ac 0 12 k c a sendbase=120 pérdida de ACK 0 10 k c a timeout prematuro Ejemplos Emisor Emisor sendbase=92 8bytes 20bytes timeout sendbase=120 timeout cancelado Receptor sec =92 sec sendbase=92 8bytes =10 dat 20bytes os 8 sec =92 sec =10 ack 120 ACK acumulado ack 100 sendbase=100 timeout datos pendientes dat os 8B 0 d ato s2 0B 00 1 k ac 20 1 k ac B 0 d ato s 20 B Receptor sec =10 0 d ato s2 0B reinicio timeout TCP: varias retransmisiones ‣ El timeout se dobla cada vez que caduca y se envía de nuevo el paquete Exponential backoff Emisor Receptor TCP: receptor ‣ Eventos del receptor > Llega segmento en orden con el numero de secuencia esperado No hay ACKs pendientes de enviar Acción: Delayed ACK, espera hasta 500ms al siguiente paquete, si no llega manda ACK último ACK enviado último byte recibido > Llega segmento en orden con el numero de secuencia esperado Hay un delayed ACK pendiente último ACK enviado último byte recibido Acción: envía inmediatamente ACK (al ser acumulado confirma los dos) TCP: receptor ‣ Eventos del receptor > Llega segmento fuera de orden generando hueco último ACK enviado último byte recibido > Acción: envía inmediatamente ACK causando ACK duplicado ACK # Llega segmento rellenando hueco último ACK enviado Acción: envía inmediatamente ACK ACK # > Llega segmento ya reconocido Acción: ignorar TCP: Fast retransmit ‣ El timeout normalmente es relativamente largo > > ‣ Si se pierde un paquete de datos se genera hueco y se detendrá la transmisión durante un timeout Normalmente el emisor envía varios paquetes seguidos El receptor no puede hacer un NACK pero está generando ACKs duplicados !! Emisor ack 100 ack 200 ack 200 ack 200 ack 200 ack 200 timeout Receptor TCP: Fast retransmit ‣ Fast retransmit > > Si el emisor recibe 3 ACKs con el mismo numero de ACK supondrá que se ha perdido el paquete que llevaba ese numero de secuencia Reenvia el paquete inmediatamente sin esperar a que caduque el timeout 3 dup ACKs !!! = fast retransmit recibidos todos timeout cancelado Emisor ack 100 ack 200 ack 200 ack 200 ack 200 ack 200 ack 700 Receptor TCP: timeout ‣ ¿Qué timeout se debe usar? > > > > > Suficiente para que el paquete llegue a su destino y el ACK vuelva. A este tiempo se le denomina tiempo de ida y vuelta o Round Trip Time (RTT) El RTT depende de muchos factores + velocidad de la red + tiempos de respuesta del destino RTT + tiempos de espera en routers Muy variable, incl entre origen y destino fijos timeout < RTT retransmisiones innecesarias timeout >> RTT reacción lenta ante las pérdidas TCP: timeout ‣ ‣ Solución: estimar el RTT y adaptar el timeout al valor de RTT estimado Estimando el RTT > Se toma una muestra SampleRTT por cada vez que se envía un segmento hasta que llega su correspondiente ACK + Se ignora la muestra si el segmento se retransmite + Se mide con delayed acks (overestimation) + Sólo se puede medir una muestra a la vez (1 solo timer) y normalmente con precisión de 500ms SampleRTT1 SampleRTT2 Descartado por retransmisión SampleRTT3 TCP: estimación RTT ‣ El valor medido SampleRTT varía queremos un RTT estimado suave > Utilizamos el promedio de varias muestras Exponential weighted moving average EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT > > La influencia de muestras pasadas decrece exponencialmente Típicamente: α= 0.125 TCP: estimación de RTT ‣ Ejemplo 24 octubre 2005 Transporte-4 15 /17 TCP: estimación de RTT ‣ Eligiendo el timeout > EstimatedRTT mas un márgen de seguridad + + A mayor variación de EstimatedRTT mayor debe ser el margen de seguridad Estimamos la variación de EstimatedRTT con DevRTT = (1-β)*DevRTT + β*|SampleRTT-EstimatedRTT| (typically, β = 0.25) ‣ Se toma como timeout TimeoutInterval = EstimatedRTT + 4*DevRTT TCP: Control de flujo ‣ ‣ El receptor de TCP tiene un buffer en el que TCP va colocando los datos que llegan. > Estos datos se le entregan al nivel de aplicación al hacer un read() sobre el socket > La aplicación puede ser lenta al leer los datos. Qué pasa si los datos llegan y no hay buffer? > Hace falta un mecanismo que ajuste la velocidad de los datos que llegan a la velocidad a la que lee la aplicación Este es el problema del control de flujo. > Es un problema general de los protocolos de comunicaciones > Normalmente se resuelve haciendo que el receptor sea capaz de enviar indicaciones al emisor de que su buffer se esta llenando para que este reduzca la velocidad de envío read() buffer de recepción TCP: Control de flujo ‣ TCP informa al emisor de cuanto buffer tiene libre en cada paquete que le envía !! > > > Cabecera IP ... puerto origen puerto destino numero secuencia numero ack HL nada flags ventena recep. checksum urgent data ptr Esa es la función del campo ventana de recepción de la cabecera En cada paquete el receptor anuncia cuantos datos es capaz de recibir Este valor se utiliza como máximo numero de bytes que se pueden tener en la red sin recibir ACK. Máximo de la ventana deslizante ventana anunciada buffer de recepción opciones Datos aplicación Ejemplo ‣ De una transferencia de página web 1124207801.184011 1124207825.463815 1124207825.464062 1124207825.466289 1124207825.466784 1124207825.466915 1124207825.511610 1124207825.512278 1124207825.512382 1124207825.512503 1124207825.512626 1124207825.711709 1124207825.712371 1124207825.712474 1124207825.712595 1124207825.712723 1124207825.712842 1124207825.911783 ‣ IP IP IP IP IP IP IP IP IP IP IP IP IP IP IP IP IP IP 130.206.169.177.53611 > 130.206.166.105.80: 130.206.169.177.53611 > 130.206.166.105.80: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.169.177.53611 > 130.206.166.105.80: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.169.177.53611 > 130.206.166.105.80: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.166.105.80 > 130.206.169.177.53611: 130.206.169.177.53611 > 130.206.166.105.80: . P . P . P . . . . P . . . . . P . ack 1 win 65535 1:39(38) ack 1 win 65535 ack 39 win 24616 1:291(290) ack 39 win 24616 291:1739(1448) ack 39 win 24616 1739:3187(1448) ack 39 win 24616 ack 3187 win 63422 3187:4635(1448) ack 39 win 24616 4635:6083(1448) ack 39 win 24616 6083:7531(1448) ack 39 win 24616 7531:8979(1448) ack 39 win 24616 ack 8979 win 57630 8979:10427(1448) ack 39 win 24616 10427:11875(1448) ack 39 win 24616 11875:13323(1448) ack 39 win 24616 13323:14771(1448) ack 39 win 24616 14771:16219(1448) ack 39 win 24616 ack 16219 win 50390 Conforme recibo datos se va llenando el buffer TCP: Control de flujo ‣ El campo para anunciar ventana sólo tiene 16 bits > > ‣ Solo puede anunciar 65KBytes !!! (el numero de secuencia direcciona 4GB) Podían ser suficientes en los primeros tiempos de TCP... Consecuencias > > no hay que preocuparse del overlflow de numero de secuencia si hay que preocuparse por las velocidad de transferencia RTT La máxima velocidad de transferencia es: ventanamax v= RT T En el ejemplo de 1Gbps y 30 ms 65535bytes v= ≈ 17.5Mbps 30ms Al menos llegamos al 17% TCP: conexiones ‣ ‣ ‣ Hasta ahora hemos visto los mecanismos de transporte fiable y control de flujo entre un emisor y un receptor TCP. TCP es orientado a conexión Previamente comunicarse datos entre un emisor y un receptor deben negociar un establecimiento de conexión. > TCP inicializa sus variables para la conexión y crea los buffers > > Esto se hace mediante los paquetes que utilizan los flags SYN, FIN y RST Protocolo para establecer la conexión > Protocolo para liberar la conexión TCP: establecimiento de conexión ‣ Mecanismo: Three way handshake > Lado cliente (socket que hace connect) envía un paquete sin datos con el flag SYN Establece el numero de secuencia inicial > Lado servidor (socket que hace accept) responde con un paquete sin datos con ACK y SYN > Establece el numero de secuencia inicial Lado cliente reconoce este paquete con un ACK Este paquete ya puede llevar datos > Al recibir el ACK el servidor puede enviar ya datos > Los SYNs gastan un número de secuencia para poder confirmarse con ACKs SYN ACK+SYN ACK Ejemplo ‣ Otra conexión web... Los SYNs usan un número de secuencia para poder ser confirmados IP ...177.53656 > ...105.80: S 3482203897:3482203897(0) win 65535 SYN IP ...105.80 > ...177.53656: S 3356369201:3356369201(0) ack 3482203898 win 24616 IP ...177.53656 > ...105.80: . ack 3356369202 win 65535 ACK SYN +ACK IP ...177.53656 > ...105.80: P 3482203898:3482204138(240) ack 3356369202 win 65535 IP ...105.80 > ...177.53656: . ack 3482204138 win 24616 IP ...105.80 > ...177.53656: P 3356369202:3356369502(300) ack 3482204138 win 24616 IP ...105.80 > ...177.53656: . 3356369502:3356370950(1448) ack 3482204138 win 24616 IP ...105.80 > ...177.53656: P 3356370950:3356372398(1448) ack 3482204138 win 24616 Aqui empieza la transferencia Paquete 4 Cierre de la conexión FIN ‣ Cualquiera de los dos extremos puede iniciarlo > > > Envia un paquete sin datos con el flag FIN. Consume tambien un numero de secuencia El otro extremo, confirma enviando un ACK e indica que cierra tambien con otro FIN. Este segundo FIN puede ir en el mismo paquete o en otro. El extremo original confirma con un ACK ACK+FIN ACK FIN ACK FIN ACK Cierre de la conexión &LHUUHGH&RQH[LyQ ‣ Medio cierre > > El cierre de cada sentido de la conexión es en realidad independiente Un extremo puede cerrar la conexión indicando que no enviara mas datos pero puede seguir recibiendo lo que le envian FIN ACK datos ACKs FIN ACK close(s) Ejemplo ‣ El final de una conexión web... El servidor está enviando datos El cliente decide cerrar y manda un FIN ... IP 130.206.166.105.80 > 130.206.169.177.53701: IP 130.206.166.105.80 > 130.206.169.177.53701: IP 130.206.169.177.53701 > 130.206.166.105.80: IP 130.206.169.177.53701 > 130.206.166.105.80: IP 130.206.166.105.80 > 130.206.169.177.53701: IP 130.206.166.105.80 > 130.206.169.177.53701: IP 130.206.169.177.53701 > 130.206.166.105.80: P P . F . F . 80314174:80315622(1448) ack 4067364561 win 24616 80315622:80316551(929) ack 4067364561 win 24616 ack 80316551 win 65535 4067364561:4067364561(0) ack 80316551 win 65535 ack 4067364562 win 24616 80316551:80316551(0) ack 4067364562 win 24616 ack 80316552 win 65535 El servidor cierra su sentido TCP: abortar una conexión ‣ Paquete Reset (RST) > > > > > Se envía cuando TCP recibe un paquete que es inconsistente con su estado de la conexión recibir datos sin tener conexión abierta Le dice al otro extremo que esa conexión no existe y que destruya toda la información de ese estado de conexión También se usa para decir que no hay nadie escuchando un puerto También se puede usar por el nivel de aplicación para cerrar una conexión de forma rápida El otro extremo no hace falta que conteste nada datos RST TCP: establecmimiento de conexión ‣ ¿Qué pasa si se pierden paquetes del establecimiento o del cierre? > > ‣ Retransmision de SYNs > ‣ Tienen un número de secuencia así que se pueden retransmitir. Es como si fueran un byte de datos. Se utiliza retransmisión por timeout Problema: al comenzar la conexión no ha habido tiempo de hacer estimaciones del RTT. La mayoría de las implementaciones utilizan un timeout inicial de 6 segundos. Si falla el timeout se pone a 24 segundos y se va doblando Retransmision de FINs > Problema: el sistema operativo no puede deshacerse del estado de la conexión inmediatamente. Tiene que mantenerlo un tiempo por si acaso hacen falta retransmisiones TCP estados TCP Estados del servidor TCP Estados del cliente TCP: establecimiento de conexión ‣ Casos especiales: apertura simultánea > Si dos clientes inician simultaneamente una conexión entre ellos > Nótese que los dos tienen que usar puertos conocidos por el otro Se usa muy poco > connect() SYN SYN connect() ACK+SYN conexión establecida ACK+SYN ACK ACK conexión establecida TCP: establecimiento de conexión ‣ Casos especiales: cierre simultáneo > > Los dos extremos deciden cerrar a la vez Los dos extremos deben esperar en TIME_WAIT para poder retransmitir el FIN close() FIN FIN close() ACK TIME_WAIT ACK TIME_WAIT ¿Por qué se pierden los paquetes? ‣ Varias causas > Errores de transmisión. Modifican bits aleatorios de los paquetes. Los niveles que hacen detección de errores se ven obligados a descartar el paquete al no estar seguros de entregarlo correctamente > Independiente del tráfico Desbordamiento de buffer Un router que debe reenviar un paquete se encuentra con que todos sus recursos de memoria (por ejemplo en la cola de paquetes esperando la salida están ocupados). Debe descartar el paquete por falta de recursos Dependiente de la carga de la red Para R3 R1 R2 R3 R4 R1 R2 R3 R4 Congestión de red ¿Qué es? ‣ Demasiadas fuentes enviando demasiado trafico para que la red pueda manejarlo ‣ No es lo mismo que el control de flujo > > ‣ Efectos: > > ‣ Relacionado con que el receptor pueda manejar el tráfico La congestión puede darse aunque todos los receptores sean capaces de aceptar el trafico que se está enviando Pérdidas de paquetes (debido a desbordamiento de colas de routers) Tiempos de espera elevados (debido a tiempos de espera en colas altos) Es uno de los problemas más importantes de redes Escenario 1 ‣ ‣ Dos emisores y dos receptores Un router común (supongamos que con buffer infinito) > Nunca ocurren retransmisiones > Las dos fuentes envian a una media de λin La capacidad del router es C > ‣ Como se comporta el sistema?? Escenario 1 ‣ Entrada y salida. Cuanto throughput obtenemos del sistema? retardo λout para cada λin aceptable (mitad de capacidad para cada uno) !out C/2 !in ‣ ‣ ‣ !in C/2 C/2 Pero el retardo aumenta indefinidamente Cada vez tiene más paquetes que procesar Recursos infinitos no garantizan un buen funcionamiento 31 octubre 2005 Transporte-6 6 /18 Escenario 2 ‣ Igual que el anterior pero ahora el router tiene recursos finitos. > > > Los paquetes no esperan indefinidamente (retardo limitado) Si se transmite a mucha velocidad algunos paquetes se perderan y el nivel de transporte los retransmitirá Tráfico λ’in = λin + retransmisiones Escenario 2 ‣ λin = λout (goodput) Envío perfecto (no hay retransmisiones hasta que alcancemos R/2) > λout !out !out Retransmisión implica λ’in !out ‣ R/2 R/3 R/4 R/2 !'in Perfecto no retransmisiones ‣ R/2 !'in Retransmisiones sólo por desbordamiento R/2 Retransmisiones por timeout prematuro Coste de la congestión > > !'in Más trabajo (retransmisiones) para el mismo resultado (goodput) Retransmisiones innecesarias: capacidad perdida Control de congestión ‣ Problema: cuando la red está saturada por alta carga proveniente de muchas fuentes se pierden paquetes, se cursa menos tráfico útil y aumenta el retardo de los paquetes que llegan a su destino Los protocolos de transporte reaccionan aumentando las retransmisiones causando más carga y más congestión Control de congestión Dos enfoques para control de congestión ‣ Control de congestión extremo a extremo > > > > No hay indicación explicita de la congestión Los extremos estiman la congestión basandose en sus propias observaciones de la red + Perdidas observadas + Retardo observado Los extremos reacciónan a la congestión reduciendo la carga: disminuyendo retransmisiones, tasa de envíos, aumentando timeouts... Esta es la filosofía que utiliza TCP Control de congestión Dos enfoques para control de congestión ‣ Control de congestión asistido por la red > Los routers informan de la congestión a los extremos de la comunicación + Modificando un bit para indicar congestión: SNA, DECnet, TCP/IP ECN (RFC2481), ATM + Indicando la tasa máxima a la que puede enviar ATM ABR Control de congestión en Internet ‣Internet ‣ se basa en un nivel de red simple que no asiste en la detección de la congestión TCP utiliza control de congestión extremo a extremo > Como inferimos que hay congestión en la red? + Perdidas? + Retardo? > Qué hacemos para evitarlo? + Reducir la tasa de envío? Cómo? + ‣ Aumentar el timeout? Si hay errores bajar la tasa de transferencia? TCP: Control de congestión ‣ Usa control de congestión extremo a extremo > > > > La ventana deslizante de transporte fiable tenia un limite máximo impuesto por el control de flujo igual a la ventana anunciada por el receptor Se utiliza otra ventana de congestión que limita los datos que se pueden enviar a la red dependiendo de la percepción que tiene TCP de la congestión La ventana anunciada depende del receptor La ventana de congestión se reduce ante la congestión limitando la tasa a la que enviamos CongWin v= RT T Ventana = min { ventana anunciada, ventana de congestión } confirmados enviados se pueden enviar no se pueden enviar TCP: Control de congestión ‣ ¿Cómo percibe TCP la congestión? > Perdida de paquetes = congestión + + ‣ Ajustando la ventana de congestión > Congestion avoidance (evitación de congestion) > Slow start Fast recovery Timeout > > ‣ Evento de timeout 3 ACKs duplicados (Fast retransmit) MSS: maximun segment size > > Aun cuando TCP utiliza secuencias y ACKs por bytes individuales cuando tiene mucho que enviar utiliza un máximo tamaño de segmento, que llamaremos MSS En la siguiente clase veremos como se elige el MSS TCP: Congestion avoidance ‣ Tras detectar congestión TCP entra en una fase de evitación de congestión (congestion avoidance) > Si la ventana de congestión tiene un valor de N MSS > En congestion avoidance se abre 1 MSS cada vez que enviamos con exito toda la ventana CongWin=4 MSS La ventana sube linealmente > Buscando encontrar el punto de equilibrio sin aumentar demasiado la congestión CongWin=5 MSS Enviado por RTT tiempo TCP: Congestion avoidance ‣ Si en esta situación se produce una pérdida > > De un sólo paquete, lo que provoca 3 ACKs duplicados. Se interpreta como congestión ligera La ventana se reduce inmediatamente a la mitad A la vez que se hace fast retrasmit del paquete perdido Esto se conoce como fast recovery (originalmente se reducía a 1MSS) > > Buscando reducir notablemente la tasa de transmisión y colaborar en que la congestión no crezca Si se siguen recibiendo ACKs la ventana sigue creciendo linealmente Enviado por RTT CongWin=8 MSS CongWin=4 MSS tiempo TCP: Congestion avoidance ‣ ‣ Se puede ver que la tasa se va ajustando alrededor del punto de congestión > si hay muchos errores la tasa baja y se tarda más en recuperarla > si hay pocos errores el crecimiento lineal es capaz de llegar mas a mas velocidad > Este mecanismo se suele llamar AIMD Additive Increase Multiplicative Decrease Y cómo empieza la conexión?? > Con CongWin = 1 MSS Enviado por RTT 1 pérdida 1 pérdida 1 pérdida tiempo TCP: Slow Start ‣ En el principio CongWin=1 MSS pero... > Crecer linealmente es demasiado precavido, no tenemos motivos para pensar que hay congestión > Se utiliza un enfoque más agresivo, crecimiento exponencial > Slow Start: cada vez que transmitimos una ventana con éxito la ventana se dobla CongWin =1 MSS CongWin =2 MSS CongWin =4 MSS CongWin =8 MSS tiempo TCP: Slow Start ‣ El slow start se mantiene hasta que se produce una pérdida (o bien se alcanza la ventan de control de flujo) haciendo entrar en congestion avoidance > Si la perdida se detecta por ACKs duplicados... + ‣ Fast retransmit + fast recovery CongWin = CongWin/2 Y si se produce un timeout? slow start congestion avoidance tiempo TCP: pérdidas y congestión ‣ Pérdida detectada por ACK duplicados > > ‣ Congestión “ligera”: hay perdidas pero siguen llegando paquetes Acciones: + Retransmitir el paquete perdido (Fast retransmit) + Bajar la ventana de congestion para reducir la tasa + Pasar a congestion avoidance (si no estabas) Pérdida detectada por timeout > > Congestión “grave”. Probablemente hemos perdido toda la ventana. Si el timeout ha caducado llevamos un rato parados sin transmitir. Tasa =0 Acciones: + Poner la ventana de congestión a 1MSS + Pasar a slow start + Recordar a cuanto estaba la ventana de congestión al producirse el error (poner la variable threshold=CongWin/2) TCP: slow start ‣ Despues de una perdida por timeout > > el slow start no espera a otra pérdida para entrar en congestion avoidance. Pasa a congestion avoidance en cuanto llega al humbral de la mitad de la ventana de congestion al producirse el timeout slow start pérdidas y timeout congestion avoidance tiempo TCP: control de congestión En resumen ‣ Cuando CongWin está por debajo de Threshold. Slow start. La ventana crece exponencialmente ‣ Cuando CongWin está por encima de Threshold. Congestion avoidance. La ventana crece linealmente ‣ Cuando ocurre un triple ACK duplicado. Threshold se pone a CongWin/2 y CongWin a Threshold ‣ Cuando ocurre un timeout. Threshold se pone a CongWin/2 y CongWin se pone a 1MSS TCP: control de congestión ‣ Eventos en el emisor Evento Estado Acción Notas Recibe ACK para datos no confirmados Slow Start (SS) CongWin = CongWin + MSS, If (CongWin > Threshold) set state to “Congestion Avoidance” CongWin se dobla por cada RTT Recibe ACK para datos no confirmados Congestion Avoidance (CA) CongWin = CongWin+MSS * (MSS/CongWin) Additive increase, CongWin aumenta 1 MSS por cada RTT Perdida detectada por triple ACK duplicado SS or CA Threshold = CongWin/2, CongWin = Threshold, Set state to “Congestion Avoidance” Fast recovery+multiplicative decrease. CongWin nunca baja a menos de 1MSS Timeout SS or CA Threshold = CongWin/2, CongWin = 1 MSS, Set state to “Slow Start” vuelve a slow start ACK duplicado SS or CA Incrementar contador de ACKs duplicados para ese segmento CongWin y Threshold no cambian TCP: evolución de la conexión ‣ Ejemplo, una conexión TCP muchas perdidas slo w slow pérdida sta rt n o i t s ge n e o c c n a d avoi star t La ventana de control de flujo impone el máximo ion t s e cong ance avoid pérdida TCP: eficiencia de la conexión ‣ ‣ Sigue el límite de AdvertisedWindow/RTT Esto es para una conexión que este siempre enviando > > ‣ Tenga siempre datos en el buffer de emisión La aplicación del receptor lea los datos suficientemente rápido como para que el emisor siempre anuncie la ventana máxima Cómo podemos transmitir a mayor velocidad? > > > Mejorando TCP para que permita ventanas mayores Usando más de una conexión TCP?? UDP tiene control de flujo?? TCP: equidad (fairness) ‣ Equidad para TCP > Si N conexiones TCP comparten un enlace la capacidad del enlace R debería repartirse entre todas por igual R/N Cuello de botella capacidad R Más sobre equidad ‣ ¿Qué pasa con UDP? > > > ‣ Las aplicaciones multimedia suelen usar UDP para evitar el control de congestión. Envían a tasa constante y no quieren que esta se vea reducida Son capaces de tolerar pérdidas Sin embargo > > > Es dificil garantizar la equidad en ese ambiente TCP+UDP El control de congestión de TCP es justo si compite con otros TCPs Esto es un área de investigación activa + UDP que sea TCP friendly? + Envio de multimedia sobre TCP? Más sobre equidad ‣ Las aplicaciones pueden abrir más de una conexión TCP entre dos hosts > > > ‣ Así podrían superar la limitación de la ventana de control de flujo de 65KB Los navegadores web hacen esto Parte de la mejora de transferencia de los sistemas P2P viene de este efecto !! Sin embargo > > Esto también dificulta el problema de la equidad en TCP Si en un enlace de capacidad R hay 9 conexiónes TCP + Puedo abrir una conexión y conseguir un reparto de R/10 + O puedo abrir 11 y conseguir R/2 !!! TCP: últimos detalles ‣ ‣ Hemos estudiado el control de congestión y el transporte fiable, cuando las aplicaciones envían datos constantemente Algunos problemas cuando las aplicaciones leen y escriben de forma poco eficiente > > Enviando pocos bytes, el algoritmo de Nagle El problema de la ventana tonta (silly window sindrome) TCP: algoritmo de Nagle ‣ ‣ El problema de escribir despacio Aplicación de acceso remoto > > ‣ El usuario escribe a razon de una letra cada muchos milisegundos. El servidor hace echo de todo lo que le llega El nivel TCP envía paquetes de 41 bytes para enviar una letra Demasiado overhead sobre todo si no estamos en una LAN cliente servidor l s l s \n \n para enviar 6 bytes hemos enviado a la red 246 bytes TCP: algoritmo de Nagle ‣ cliente servidor Algoritmo de Nagle > > > Si una conexión tiene datos enviados sin confirmar no puede enviar segmentos pequeños (menores que MSS) hasta que reciba el ACK de los que envió Los datos se van acumulando en un paquete que se envía al llegar el ACK Algoritmo self-clocking en una LAN no tiene efecto porque las confirmaciones llegan muy deprisa ‘l’ ‘s’ ‘‘ ‘-’ ‘l’ ‘l’ ‘l’ ‘s -l’ ‘\n’ ‘s -l’ ‘\n’ TCP: persist timer ‣ El problema de leer despacio > > > ‣ Si la aplicación receptora lee muy despacio el buffer se puede llenar. El receptor aununcia ventana 0 Cuando la ventana vuelve a aumentar el receptor debe anunciar mayor ventana. Si no tiene datos que enviar lo hace en un paquete simple de ACK Que ocurre si este ACK se pierde? + El emisor no puede enviar mas datos porque la ventana esta a cero + El receptor no sabe que su ACK se ha perdido Para evitar esto TCP envía periódicamente window probes con 1 byte de datos > Tambien usan exponential backoff (hasta 60s) pero nunca caducan TCP: silly window ‣ Qué pasa si la aplicación lee los datos muy despacio? > El emisor se ve forzado a enviar byte a byte. A pesar de que la aplicación tardara un tiempo en estar interesado en ese byte ! win 500 win 0 1byte win 1 ‣ Soluciones > > Delayed ACK : este es uno de los motivos No se anuncia ventana hasta que haya un minimo tamaño en el buffer, 1MSS win 0 1byte win 1 win 0 TCP: detalles ‣ Para que sirve el flag PUSH ?? > ‣ Originalmente para indicar a TCP que debe entregar esos datos inmediatamente a la aplicación. La aplicación emisora podía notificar a TCP en que punto debía entregar. Hoy en día las aplicaciones no tienen esa opción y TCP pone el flag PUSH a 1 cuando vacía el buffer del emisor Los sistemas derivados de BSD nunca retrasan la entrega de datos a las aplicaciones Si los dos extremos no envían nada. TCP envia paquetes para mantener la conexión activa??? > NO, Hay una opción KEEPALIVE que hace enviar periódicamente paquetes para confirmar que el otro extremo sigue ahí. Pero es objeto de gran polémica Si tengo un telnet, pierdo la red y la recupero un tiempo después, por qué debería perder la conexión?