Professional Documents
Culture Documents
Aplicacin
Presentacin
Sesin Transporte
Red
Datos Fsica
Capa de transporte
Es el centro neurlgico de la jerarqua de protocolos Su tarea: proporcionar transporte confiable, econmico e independiente de las redes
Servicios
Utiliza los servicios del nivel de red para proveer un servicio eficiente y confiable a sus clientes, que normalmente son los procesos en el nivel de aplicacin. El hardware y software dentro del nivel de transporte se llaman la entidad de transporte. Puede estar en el kernel, en un proceso de usuario, en una tarjeta, etc.
Servicios
Hay los mismos dos tipos de servicio que en el nivel de red:
orientado a la conexin sin conexin.
Son muy semejantes a los del nivel de red. Las direcciones y el control de flujo son semejantes tambin .
En qu difieren?
El nivel de red es una parte de la subred y los usuarios no tienen ningn control sobre ella. El nivel de transporte permite que los usuarios puedan mejorar el servicio del nivel de red (que puede perder paquetes, puede tener ruteadores que bajan a veces, etc.). .
En qu difieren?
El nivel de transporte permite que tengamos un servicio ms confiable que el nivel de red. Las primitivas del nivel de transporte pueden ser independiente de las primitivas del nivel de red. Las aplicaciones pueden usar estas primitivas y funcionar en cualquier tipo de red
Servicios
Entidad De Trpte
Entidad D trpte.
Primitivas
El servicio de transporte orientado a la conexin es confiable. El nivel de transporte puede proveer tambin un servicio de datagrama, pero no es confiable. Como muchos programadores usan las primitivas del servicio de transporte, deben ser convenientes y fciles de usar. Ejemplo: Las entidades de transporte se comunican con TPDUs (Transport Protocol Data Units).
Ejemplo de primitivas
Primitiva TPDU mandado
LISTEN
CONNECT SEND RECEIVE DISCONNECT
ninguno
CONNECTION REQ DATA ninguno DISCONNECTION REQ
Primitivas TCP
Primitiva SOCKET BIND LISTEN ACCEPT CONNECT Significado Crear nuevo punto de comunicacin Ligar el socket con una direccin local Alocar cola para llamadas Bloquear hasta que una solicitud llegue Bloquear y establecer la conexin
SEND
Mandar datos
Elementos de protocolos
Direccionamiento Establecimiento de conexin Liberacin de conexin Control de flujo y buffers Multiplexado Recuperacin de cadas
Continuar
Conexin
El problema principal en el establecimiento de una conexin es que la subred puede perder, almacenar, y duplicar los paquetes. En el caso peor un cliente podra abrir una conexin para una transaccin, y despus la subred podra duplicar todos.
Conexin
Para eliminar los paquetes duplicados atrasados, se puede limitar el tiempo de vida mximo de un paquete en la subred (por ejemplo, usando un contador de saltos). Con un lmite de los tiempos de vida de los paquetes y sus acuses de recibo, podemos usar cualquier protocolo de ventana deslizante para intercambiar paquetes entre dos hosts y detectar los paquetes duplicados.
Conexin
Un problema es que se necesita un mtodo para elegir los nmeros de secuencia que puede tolerar una cada (es decir, hay que asegurar que dos TPDUs con el mismo nmero de secuencia pueden existir a la vez). Cada host tiene un reloj; no se necesitan sincronizar los relojes de los hosts distintos. Un reloj es un contador binario que se incrementa en intervalos uniformes. El nmero de bits en el contador tiene que ser igual a o mayor del nmero de bits en los nmeros de secuencia. Un reloj contina corriendo aun cuando su host se baja. Un host usa los k bits ms bajos del contador como el valor inicial de su nmero de secuencia. Los nmeros de secuencia son suficiente grandes que no pueden repetir dentro de la vida de un paquete.
Conexin
Despus de una cada, un host no sabe donde est en la secuencia. Puede esperar el tiempo de vida mximo de un paquete antes de transmitir otra vez. Este tiempo puede ser en general demasiado grande Un mtodo es controlar la taza de TPDUs mandados por tick para garantizar que no se pueden duplicar nmeros de secuencia. La taza no puede ser demasiado grande ni demasiado pequea.
Conexin
Otro problema es establecer la conexin e intercambiar los valores iniciales de los nmeros de secuencia. Un paquete duplicado atrasado puede causar una falla en este establecimiento. La solucin es un three-way handshake:
Host 1 manda un CONNECT REQUEST con su nmero de secuencia. Host 2 manda un acuse de recibo con el nmero de 1 y su nmero propio. Finalmente host 1 manda un acuse de recibo con la eleccin de host
Conexin
Conexin normal
Host 1
Host 2
CR (seq=x)
Solicitud duplicada
Host 1 CR (seq=x) Host 2
RECHAZO (ACK=y)
RECHAZO (ACK=y)
Desconexin
La desconexin asimtrica puede perder datos. La desconexin simtrica permite que cada lado pueda liberar una direccin de la conexin a la vez. La desconexin simtrica sufre del problema de los dos ejrcitos. Hay dos ejrcitos pequeos y separados que quieren atacar un ejrcito ms grande. Si tienen un medio de comunicacin mala, cmo pueden sincronizar un ataque?
Desconexin
En general, no es posible tener un protocolo perfecto en este caso. En nuestro caso tenemos hosts que quieren desconectar en vez de atacar, pero el problema es el mismo.
Desconexin
Se usa el protocolo siguiente:
El primer lado manda un DISCONNECT REQUEST (DR) e inicia un reloj. El recipiente entonces manda un DR e inicia un reloj. Cuando lo recibe, el transmisor original libera la conexin y manda un ACK. El recipiente lo recibe y libera la conexin tambin.
Si hay un timeout en el receptor, libera la conexin. Si hay un timeout en el transmisor, manda el DR otra vez (hasta N intentos)
Desconexin
Desconexin normal
Host 1 T=n DR T=m Host 2
DR
Liberar conexin
ACK
Libera conexin
Prdida de ACK
Host 1 T=n DR T=m Host 2
DR
Liberar conexin ACK
Libera conexin
DR
T=n
Nveces,Liberar conexin
Libera conexin
Control de flujo
Si la subred no es confiable, el transmisor tiene que almacenar los TPDUs mandados, como en el nivel de enlace. El receptor puede decidir cunto espacio en buffers quiere dedicar a sus conexiones, porque sabe si no acepta un paquete el transmisor lo reenviar. En el caso de trfico de bajo ancho de banda y en rfagas, es mejor que se dedican los buffers dinmicamente. Pero con flujos constantes de alto ancho de banda, es mejor si el receptor reserva una ventana completa de buffers para permitir la velocidad mxima de datos.
Control de flujo
La asignacin dinmica de buffers corresponde al uso de ventanas de tamaos variables. El transmisor pide algn nmero de buffers, y el receptor contesta con el nmero disponible. Durante la conexin el receptor puede cambiar este nmero. Para evitar bloqueos indefinidos debido a acuses de recibo perdidos, los hosts deben intercambiar a veces paquetes de control con los estados de los buffers. El transmisor tambin tiene que controlar el tamao de la ventana teniendo en cuenta la capacidad de la subred. Si la subred puede manejar c TPDUs/seg y el tiempo para mandar un paquete y recibir su acuse es r, la ventana debiera tener un tamao de cr. Con este tamao la conexin normalmente est llena. El transmisor puede medir y monitorear estos parmetros
Multiplexado
A veces el nivel de transporte tiene que multiplexar las conexiones. Por ejemplo, si la subred cobra el uso de un circuito virtual por tiempo, puede ser demasiado caro para una organizacin tener muchos circuitos abiertos a la vez. Por lo tanto se usa la multiplexacin hacia arriba, con ms de una conexin de transporte en una sola conexin de red. Otra razn para usar la multiplexacin es si la subred impone un control de ventana deslizante. Si un usuario necesita ms capacidad que es disponible con la ventana, se puede dividir la conexin de transporte entre unas conexiones de red. Esto el la multiplexacin hacia abajo.
Recuperacin de cadas
Si una parte de la subred se cae durante una conexin, el nivel de transporte puede establecer una conexin nueva y recuperar de la situacin. El problema es ms difcil si uno de los dos hosts se cae. Por ejemplo, considera un host que est mandando un archivo a otro usando un protocolo de parar-y-esperar. El receptor se cae y se rebootea rpidamente, pero ha perdido su posicin. Le puede informar al transmisor sobre el problema. El transmisor puede estar en dos estados: S1, con un TPDU pendiente sin acuse, o S0, con ningn TPDU pendiente. Tiene que decidir si debiera retransmitir el TPDU ms reciente.
Recuperacin de cadas
El problema es que el transmisor no sabe si el receptor ha escrito el contenido de la ltima TPDU. Por ejemplo, si el transmisor retransmite solamente cuando est en S1, tenemos el siguiente problema: El receptor recibi el paquete, gener un acuse, y se cay sin escribir. El transmisor est en S0 y no retransmitir el paquete.
Recuperacin de cadas
Si usamos una estrategia donde el receptor escribe antes de generar el acuse, tenemos un problema nuevo. En este caso el receptor escribe pero se cae antes de generar el acuse. El transmisor est en S1 y retransmitir el paquete, que es un error. Protocolos ms complejos no ayudan cuando tenemos eventos distintos come estos. En general se puede recuperar de las cadas solamente si hay suficiente estado preservado.
El protocolo TCP
El fin de TCP es proveer un flujo de bytes confiable de extremo a extremo sobre una interred no confiable. TCP puede adaptarse dinmicamente a las propiedades de la interred y manejar fallas de muchas clases. La entidad de transporte de TCP puede estar en un proceso de usuario o en el kernel. Parte un flujo de bytes en trozos y los manda como datagramas de IP.
El protocolo TCP
Para obtener servicio de TCP, el transmisor y el receptor tienen que crear los puntos terminales de la conexin (los sockets).
o La direccin de un socket es la direccin de IP del host y un nmero de 16 bits que es local al host (la puerta). o Se identifica una conexin con las direcciones de socket de cada extremo; se puede usar un socket para conexiones mltiples a la vez. o Los nmeros de puerta bajo 256 son puertas bien conocidas para servicios comunes (como FTP).
El protocolo TCP
El protocolo TCP
Las conexiones de TCP son punto-a-punto y full dplex. No preservan los lmites de mensajes. Cuando una aplicacin manda datos a TCP, este puede mandarlos inmediatamente o almacenarlos (para acumular ms). Una aplicacin puede solicitar que TCP mande los datos inmediatamente a travs del flag de PUSH (empujar).
El protocolo TCP
TCP tambin apoya los datos urgentes. TCP manda datos con el flag URGENT inmediatamente. En el destino TCP interrumpe la aplicacin (le manda una seal), que permite que la aplicacin pueda encontrar los datos urgentes.
Implementacin
Cada byte en una conexin de TCP tiene su propio nmero de secuencia de 32 bits. En TCP se mandan datos en segmentos. Un segmento tiene un encabezamiento de 20 bytes (ms opciones) y datos de cero o ms bytes. Hay dos lmites en el tamao de segmentos: el tamao mximo de un paquete de IP (64K bytes) y la unidad de transferencia mxima (MTU, maximum transfer unit) de cada red.
Implementacin
Si un segmento es demasiado grande para una red, los ruteadores lo puede dividir en segmentos nuevos (cada segmento nuevo aade un overhead de 40 bytes). TCP usa un protocolo de ventana deslizante. Cuando un transmisor manda un segmento, inicia un reloj. El destino responde con un segmento que contiene un acuse de recibo con un nmero de acuse igual al prximo nmero de secuencia que espera. Si el reloj termina antes de que llegue el acuse, el transmisor manda el segmento de nuevo.
Implementacin
Problemas: Se puede generar un acuse para un fragmento de un segmento, pero se puede perder el resto. Los segmentos pueden llegar fuera de orden. Con fragmentacin y retransmisin, es posible que fragmentos de una transmisin y una retransmisin lleguen a la vez. La red puede tener congestin.
Cabecera TCP
Cabecera TCP
La puerta de la fuente y del destino identifican la conexin. El nmero de secuencia y el nmero de acuse de recibo son normales. El ltimo especifica el prximo byte esperado. La longitud (4 bits) indica el nmero de palabras de 32 bits en el encabezamiento, ya que el campo de opciones tiene una longitud variable.
Cabecera TCP
TCP usa una ventana de tamao variable. Este campo indica cuantos bytes se pueden mandar despus del byte de acuse. El valor cero es legal; uno puede dar la permisin transmitir de nuevo con un segmento con el mismo nmero de acuse y una ventana ms de cero. El checksum provee ms confiabilidad. Las opciones permiten que los hosts puedan especificar el segmento mximo que estn listos para aceptar (tienen que poder recibir segmentos de 556 bytes), usar una ventana mayor que 64K bytes, y usar repetir selectivamente en vez de repetir n.
Administracin de conexiones
TCP usa el three-way handshake para establecer una conexin. Si un segmento de solicitud de conexin llega y no hay un proceso esperando, TCP contesta con un paquete con el bit de RST establecido. Dos hosts pueden tratar de establecer una conexin entre los mismos sockets simultneamente. Resulta en una sola conexin.
Administracin de conexiones
Se usa un reloj para asignar los nmeros iniciales de secuencia. Despus de una cada un host tiene que esperar el tiempo de vida mximo de un paquete (120 segs). Para desconectar un sentido de la conexin, TCP manda un paquete de FIN y entonces espera un acuse. Para evitar el problema de los dos ejrcitos el transmisor desconecta despus de dos tiempos mximos de vida de un paquete.
Administracin de conexiones
HOST 1 SYN (seq=x) HOST 2
SYN (seq=x+1,ACK=y+1)
Poltica de transmisin
Cuando la ventana tiene un tamao de cero, el transmisor no puede mandar segmentos, con dos excepciones. Se pueden mandar los datos urgentes y se pueden mandar un segmento de 1 byte para causar que el receptor genere un acuse nuevo con la ventana. Este ltimo es para evitar el bloqueo indefinido. Los transmisores no tienen que mandar datos inmediatamente y los receptores no tienen que mandar acuses inmediatamente. Se puede usar esta flexibilidad para mejorar el rendimiento.
Poltica de transmisin
Por ejemplo, considere una conexin de TELNET. Cada carcter tipiado genera un paquete de IP de 41 bytes, seguido por un acuse de 40 bytes, seguido por una actualizacin de la ventana de 40 bytes cuando la aplicacin lee el carcter, seguido por 41 bytes cuando la aplicacin hace un eco del carcter, y finalmente 40 y 40 ms. Una optimizacin es demorar los acuses y las actualizaciones de ventana por 500 msegs para usar Piggybacking.
Poltica de transmisin
Una segunda optimizacin para minimizar los segmentos con solamente un byte de informacin es el algoritmo de Nagle. En esto se almacena los datos hasta que llegue el ltimo acuse o haya suficiente datos para llenar la mitad de la ventana o un segmento mximo.
Trans. 2K 2K [SEQ=0]
Recpt. vaco 2K
ACK=2048, WIN=2048
2K [SEQ=2048]
Transmisor bloqueado
ACK=4096, WIN=0 ACK=4096,, WIN=2048
lleno
2K
1K [SEQ=4096]
1k
2K
Poltica de transmisin
Otro problema es el sndrome tonto de ventana. En esto la ventana del receptor est llena. La aplicacin en el receptor lee un byte, que causa que el receptor manda una actualizacin del tamao de ventana al transmisor. El transmisor manda un byte y la ventana est llena otra vez.
Poltica de transmisin
La solucin de Clarke es no mandar una actualizacin de ventana hasta que el receptor pueda manejar el segmento mximo de la conexin o el buffer est medio vaci, cualquier es menor. Tambin el transmisor no manda segmentos pequeos (si posible). Debiera esperar hasta que haya suficiente espacio en la ventana para un segmento completo o el buffer del receptor est medio vaco (segn su estimacin de su tamao).
Control de congestin
TCP trata de manejar la congestin usando la conservacin del nmero de paquetes. La idea es no inyectar un paquete nuevo en la red hasta un paquete antiguo es entregado. TCP trata de hacer esto manipulando dinmicamente el tamao de la ventana. El primer paso es detectar la congestin. Antes era difcil ya que el timeout de un paquete perdido poda haber causado por ruido en la lnea o congestin en un ruteador. Ahora la mayora de los timeouts son debidos a la congestin.
Control de congestin
Hay dos problemas distintos que tenemos que solucionar: la capacidad de la red y la capacidad del recipiente. Para manejar cada uno, el transmisor mantiene dos ventanas. Una ventana se negocia con el recipiente, y su tamao es basado en el tamao del buffer del recipiente. La otra ventana es la ventana de congestin. El transmisor solamente puede mandar el mnimo de las dos ventanas.
Control de congestin
Cuando se establece una conexin, el transmisor inicializa la ventana de congestin al tamao del segmento mximo de la conexin. Si puede mandar un segmento mximo sin un timeout, se dobla el tamao de la ventana y se mandan dos segmentos mximos. Este aumento contina hasta que hay un timeout. Se llama la salida lenta, pero no es lenta, sino exponencial.
Control de congestin
Para controlar la congestin hay un tercer parmetro, el umbral, que al principio tiene un valor de 64K. Cuando hay un timeout, se establece el valor del umbral a la mitad de la ventana corriente de congestin, y se establece la ventana de congestin a un segmento mximo. Otra vez se usa la salida lenta, pero despus de llegar al umbral la ventana crece solamente por un segmento mximo a la vez (es decir, linealmente) hasta la ventana del receptor.
Control de congestin
Administracin de relojes
TCP usa un reloj de retransmisin para determinar si debiera retransmitir un segmento. Por cunto tiempo debiera durar el intervalo de timeout? El problema en establecer un valor para este timeout es que la varianza en tiempos de ida y vuelta es mucho mayor que en el nivel de enlace. El promedio y varianza pueden cambiar rpidamente mientras que la congestin crece y desparece. Si el timeout es demasiado largo el rendimiento sufre, pero si es demasiado corto hay retransmisiones innecesarias.
Administracin de relojes
Se usa un algoritmo debido a Jacobson. TCP mantiene un variable RTT para cada conexin con una estimacin del tiempo de ida y vuelta. Si el prximo segmento toma M segundos, se actualiza RTT segn RTT = alpha RTT + (1alpha)M. Un valor tpico para alpha es 7/8. Dado RTT hay que elegir todava un timeout de retransmisin. TCP normalmente usa beta RTT, donde beta debiera ser proporcional (ms o menos) a la desviacin estndar. Se usa la desviacin promedia D, donde D = alpha D + (1alpha)|RTT - M|. alpha puede ser distinta a la previa.
Administracin de relojes
Finalmente, el timeout normalmente es RTT+4D. Un problema en la estimacin de RTT es lo que pasa cuando se retransmite un segmento. Cuando el acuse llega, no es claro si refiere al primer segmento mandado o a la retransmisin. El algoritmo de Karn es no actualizar RTT con los acuses de segmentos retransmitidos. En vez de eso, se dobla el timeout con cada timeout hasta que los segmentos llegan sin timeout.
Administracin de relojes
TCP mantiene tambin un reloj de persistencia. El transmisor lo usa para prevenir el bloqueo indefinido en el caso donde el transmisor cree que la ventana del receptor es cero y la actualizacin del receptor fue perdido. Algunas implementaciones usan un reloj de keepalive (mantener vida) para determinar si el otro lado todava est all, y si no, desconectar. Una desventaja es que puede matar una conexin debido a una falla temporal de la red.
Rendimiento
En general entender el rendimiento de redes es ms arte que ciencia. La teora no ayuda mucho. Fuentes de problemas de rendimiento: Congestin. Desequilibrios entre recursos. Por ejemplo, una lnea gigabit conectada a un PC. Sobrecarga sncrona. Un TPDU malo mandado en un broadcast puede producir miles de mensajes de error (una tormenta de broadcast. UDP sufra de este problema. Otro ejemplo: Despus de una falla de electricidad todas las mquinas que estn rebooteando pueden sobrecargar el servidor de RARP.
Rendimiento
Fuentes de problemas de rendimiento:
Ajustamiento malo. Si suficiente memoria no es dedicada a buffers, o el algoritmo de planificacin no da una prioridad suficiente alta al procesamiento de TPDUs, o los timeouts son demasiado cortos o largos, se pueden perder paquetes. Redes gigabit. En estos el producto de ancho de banda por retraso, que es la capacidad del canal entre transmisor y receptor, es muy grande (por ejemplo, 5 megabytes en una conexin transcontinental). Se necesitan ventanas grandes en los receptores. Jitter. Las aplicaciones de audio y video demandan una varianza muy pequea en la desviacin estndar del tiempo de transmisin.
Rendimiento
Medicin de rendimiento de redes: Asegurar que la muestra es suficientemente grande para pruebas estadsticas. Usar muestras representativas, con horas y das distintos. Tener cuidado en el uso de un reloj de grano grueso. Con repeticiones de mediciones se puede usar tal reloj para lograr una precisin ms alta. Evitar condiciones extraas (por ejemplo, respaldos durante pruebas ). Es mejor usar una red desocupada y generar la carga t mismo.
Rendimiento
Medicin de rendimiento de redes:
El uso de cachs de archivos o buffers en el nivel de transporte pueden cambiar las mediciones. Entender exactamente lo que ests midiendo. Por ejemplo, las diferencias en los drivers de red entre dos mquinas distintas pueden ser la fuente de rendimientos distintos. Tener cuidado en extrapolar los resultados; no son necesariamente lineales.