Prof. Wílmer Pereira
Transporte: Servicios y Protocolos
Protocolo transporte InterfazTransporte Red
Medio Físico
FísicaEnlaceRedTransporteAplicación
Protocolo Comunicación horizontal
Servicio Comunicación vertical
Modelo de Capas Imperante
Transporte corre en máquina del destino u origen independiente de la red sea o no confiable
Emisor Receptor
Ensamblado de paquetes
Desensamblado de paquetesPaquete
Trama
Secuencias de bits
Segmento
Arquitectura de la red
Los segmentos en transporte ofrecen servicios orientado conexión o no orientado conexión
Capa Transporte
Multiplexado (hacia o hacia abajo)
Control de Flujo no punto a punto como en capa 2 sino con la subred => direccionamiento y manejo de almacenamiento de la red
Control de Errores
Independiente de la subred (conmutadores)
Direccionamiento
Puerto como identificación de cada conexión
Puertos bajos reservados (/etc/services) y los altos
disponibles para aplicaciones cliente/servidor
En algunas librerías se usan servidores de nombre
(RPC, RMI, CORBA …) que corre sobre puerto bien
conocido
Manejo concurrente de los procesos para compartir el
puerto bien conocido
Establecimiento de la Conexión
Ante pérdidas hay retransmisiones => duplicados que se resuelven con
numeración => pero aun haber duplicados retardados (contador de saltos
o secuencias largas
Acuerdo de tres vías:
Aplica a los servicios y protocolos orientado a conexión
Desconexión del enlace
Puede ser simétrico (ambas conexiones se desconectan separadamente)
En el asimétrico al solicitar uno de los entes fin de la conexion se detiene inmediatamente
A tres vías:
Control de Flujo y Buffers Transporte usa algoritmo de ventanas deslizantes pero la diferencia
es la cantidad de conexiones y la latencia de la red
Si la red no es confiable emisor debe llevar ventana (buffers). Si la red es confiable es posible que los buffers los maneje el receptor
Si el tráfico es de bajo AB, buffers en el emisor Si el tráfico es de alto AB, buffers en el receptor
Reservación dinámica de buffers Ventana de tamaño variable
Cuando el problema no son los buffers aún está la red como limitante => estimar con carga cantidad de buffers
Recuperación ante caidas
El problema es que se pierde Servidor al levantarse el estado de las conexiones anuncia que se cayó ...
pero ...
?Qué sucede si envía confirmación y antes de salvar en disco se cae ...?
Hacerlo al reves no funciona tampoco ... Duplicado
No hay solución óptima y la unica posibilidad es que capa aplicación resuelva disponiendo de suficiente información ...
Protocolos de Transporte
Encabezado de apenas 8 bytes con el mínimo de información
No realiza control flujo, ni retransmisiones y un mínimo chequeo de errores (checksum)
Ideal para servicios de respuesta corta (DNS) o tráfico en tiempo real donde no tiene sentido retransmitir
Orientado Conexión: TCPNo Orientado Conexión: UDP
UDP
Orientado Conexión: TCP
En linux el proceso inetd escucha por todos los servicios. Cuando llega por primera vez requerimiento a puerto, levanta el servidor
Todas las conexiones son full duplex y punto a punto. TCP no soporta no soporta broadcast ni multidifusión
Los segmentos se arman según tráfico o a demanda de la aplicación (PUSH). También ofrece datos urgentes (Ctrl-C)
Protocolo confiable con retransmision, control de flujo variable,reordenamiento de paquetes y control de errores
TCP: Establecimiento de Conexión
Protocolo a tres vías con bits de SYN y ACK
Protocolo a dos vías con bit de FIN. Lo normal es la desconexión simétrica, es decir cuatro segmentos (aunque pueden ser tres por el piggyback)
Se usan temporizadores para evitar esperas de desconexión infinita
Liberación de Conexión
TCP: Autómata de Estado Finito
Línea punteada son las transiciones de estado del servidor.La línea gruesa es la trayectoria del cliente. Las líneas delgadas son eventos poco comunes
TCP: Política de Transmisión
telnet envía, si no hay configuración especial, caracter por caracter
Algoritmo de Nagle (84): al llegar un byte envía pero el emisor acumula hasta recibir el ACK del receptor. Así es mas eficiente … … pero … cuando se trata del ratón hay que desactivarlo …
Pero está el síndrome de la ventana tonta y lo resuelve el algoritmo de Clark: no actualizar ventana para un byte o pocos bytes
TCP: Algoritmos de Transmisión
Los algoritmos de Clark y Nagel son complementarios. La meta es que el emisor no envíe segmentos pequeños (Nagel)y que el receptor no pida segmentos pequeños (Clark)
También TCP controla congestión y reconfigura dinámicamente el tamaño de los temporizadores
TCP: Control de Congestion
La congestion nace del trafico excesivo de transporte => controlar la emision
Las perdidas son ocasionadas por:• Ruido en la linea (sin embargo es poco comun en troncales de fibra...)• Descarte por congestion
Para las perdidas por congestion se tiene una ventana de congestion ademas de la ventana de emision (se envia por la de menor tamano)
La ventana de congestion aumenta exponencialmente si llegan ACK's pero siempre es menor que la ventana de recepcion. Sin embargo tiene un umbral donde despues crece linealmente.
TCP: Temporizadores
Temporizador de transmision: Se calcula el tamano gracias al RTT (round trip time) [Jacobson] pero otro propone duplicar el tiempo ante perdidas [Karn]
Temporizador de persistencia: para evitar bloqueo si se pierde notificacion de ventana de recepcion disponible. Al vencer emisor pregunta a receptor
Temporizador de seguir con vida: verifica si el receptor esta activo y en caso contrario cierra la conexion
Temporizador TIMED WAIT: al cierre de la conexion para asegurarse que al cierre todos los paquetes hayan desaparecido