Transporte

Transporte:
Servicios y Protocolos
Prof. Wílmer Pereira
Modelo de Capas Imperante
Transporte corre en máquina del destino u origen
independiente de la red sea o no confiable
Protocolo transporte
Interfaz
Transporte
Red
Aplicación
Transporte
Red
Enlace
Física
Medio Físico
Protocolo
Comunicación horizontal
Servicio
Comunicación vertical
Arquitectura de la red
Los segmentos en transporte ofrecen servicios
orientado conexión o no orientado conexión
Emisor
Ensamblado
de
paquetes
Receptor
Segmento
Paquete
Trama
Secuencias de bits
Desensamblado
de
paquetes
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
Aplica a los servicios y protocolos orientado a conexión
Ante pérdidas hay retransmisiones => duplicados que se resuelven con
numeración => pero aun haber duplicados retardados (se soluciona con un contador
de salto o números de secuencia largos)
Acuerdo de tres vías:
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 (aquí se pueden perder datos)
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 por ráfagas, buffers en el emisor
Si el tráfico es de alto AB continuo, 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
el estado de las conexiones
Servidor al levantarse
anuncia que se cayó ...
pero ...
?Qué sucede si envía confirmación y antes de salvar en disco se cae ...?
Hacer la confirmación despues de salvar en el disco ...
si se cae antes de enviar la confirmación
tampoco funciona ...
La única solución es que aplicación resuelva
Duplicado
Protocolos de Transporte
Orientado Conexión: TCP
No Orientado Conexión: UDP
UDP
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: TCP
Protocolo confiable con retransmision, control de flujo variable,
reordenamiento de paquetes y control de errores
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)
Campos del encabezado
Tamaño de la ventana = 0 implica que no se trasnsmiten más datos
Entre las opciones están paquetes más grandes. Util cuando hay
alta velocidad de transferencia y alta latencia (satélite)
Otra opción es aumentar el tamaño de la ventana y cambiar el algoritmo
de ventana deslizante de retroceso n a repetición selectiva (usando NACK)
Campos sin utilizar muestra lo bien concebido del algoritmo ...
TCP: Establecimiento de Conexión
Protocolo a tres vías con bits de SYN y ACK
Liberación de Conexión en TCP
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
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 
De hecho 162 bytes por caracter ...
Algoritmo de Nagle (84): al llegar un byte envía pero
el emisor acumula hasta recibir el ACK del receptor. Así es más eficiente …
… pero … cuando se trata del ratón hay que desactivarlo …
Pero está el síndrome de la ventana tonta (libera y ocupa inmediatamente).
Lo resuelve el algoritmo de Clark: no actualizar ventana para pocos bytes
TCP: Algoritmos de Transmisión
SINDROME DE LA
VENTANA TONTA
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 congestión nace del trafico excesivo de transporte => controlar la emisión
Las pérdidas (y por ende vencimiento de temporizadores) se debe a:
• Ruido en la línea (sin embargo es poco comun en troncales de fibra...)
• Descarte por congestión
Para las pérdidas por congestión, en el emisor, se tiene una ventana de
congestión además de la ventana de emisión (se envia por la de menor tamaño)
• La ventana de congestión empieza con el tamaño del segmento,
aumenta exponencialmente si llegan ACK's pero siempre es menor que la
ventana de recepción. Sin embargo tiene un umbral de crecimiento lineal.
TCP: Temporizadores
Si un temporizador es muy corto se retransmite
demasiado y si es muy largo sufre el desempeño
Temporizador de transmisión: Se calcula el tamaño gracias al RTT
(round trip time) con un factor de amortiguación [Jacobson]
pero otro propone no actualizar RTT, sólo duplicar el tiempo ante
pérdidas hasta que no haya retransmisiones [Karn]
Temporizador de persistencia: para evitar bloqueo si se pierde notificación
de ventana de recepción disponible. Al vencer emisor pregunta a receptor
Temporizador de seguir con vida: verifica si el receptor está activo y
en caso contrario cierra la conexión
Temporizador TIMED WAIT: al cierre de la conexión para asegurarse
que al cierre todos los paquetes hayan desaparecido