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