You are on page 1of 75

Capa de Transporte

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)

ACK (seq=Y, ACK=x)

DATA (seq=x, ACK=y)

Solicitud duplicada
Host 1 CR (seq=x) Host 2

ACK (seq=Y, ACK=x)

RECHAZO (ACK=y)

Solicitud y ACK duplicados


Host 1 CR (seq=x) Host 2

ACK (seq=Y, ACK=x) DATA (seq=x,ACK=z)

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)

Finalmente libera la conexin.

Este protocolo puede fallar si ninguna transmisin del transmisor llega

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

Respuesta perdida y prdida deDRs


Host 1 T=n DR T=m DR Host 2

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.

Protocolos de Transporte en Internet


TCP (Transmission Control Protocol) orientado a la conexin
RFC 793, 1122, 1323

UDP (User Datagram Protocol) sin conexin

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 (flags)


URG. Indica que el segmento contiene datos urgentes. ACK. Indica que hay un nmero de acuse en el campo de acuse. PSH (Push). El receptor no debiera almacenar los datos antes de entregarlos. RST (Reset). Hay un problema en la conexin. SYN. Se usa para establecer las conexiones. Una solicitud de conexin tiene SYN = 1 y ACK = 0, mientras que la aceptacin de una conexin tiene SYN = 1 y ACK = 1. FIN. Indica que el transmisor no tiene ms datos a mandar. La desconexin es simtrica.

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=y, ACK=x+1)

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.

Diseo de mejor rendimiento


La velocidad de CPU es ms importante que la de la red. En casi todas las redes el overhead del sistema operativo y los protocolos es mayor que el tiempo en el alambre. Ejemplos: En un Ethernet el tiempo mnimo para la comunicacin de un RPC (llamada a procedimiento remoto) es 102 microsegundos, pero la realidad es ms cerca a 1500 microsegundos. En una red gigabit, el problema es la transferencia de datos del buffer al proceso de cliente. Reducir el nmero de paquetes para reducir el overhead de software. Cada TPDU implica algn procesamiento, ms el costo de una interrupcin. Con paquetes mayores hay una reduccin en el nmero de paquetes.

Diseo de mejor rendimiento


Minimizar los cambios de contexto. Como las interrupciones pueden disminuir el rendimiento drsticamente. Podemos tener, por ejemplo, 4 cambios de contexto entre procesos de usuario, el kernel, y el administrador de red para entregar datos recibidos.

Diseo de mejor rendimiento


Minimizar la duplicacin. Durante el procesamiento de un paquete en los niveles distintos frecuentemente se duplica algunas veces. Por ejemplo, si una mquina de 50 MIPS hace tres copias de cada palabra y necesita 5 instrucciones por copia, vamos a necesitar 75 nanosegundos por byte. Entonces la mquina no puede manejar ms de 107 Mbps, y probablemente no esto, porque hay otro overhead del protocolo, las instrucciones que refieren a la memoria son mucho ms lentas, etc.

Diseo de mejor rendimiento


Puedes comprar ms ancho de banda pero no retraso menor. La velocidad de luz es un lmite inevitable.
Evitar la congestin es mejor que recuperar de la congestin. Cuando hay congestin en la red se pierden paquetes, se malgasta ancho de banda, se introducen retrasos, etc. Evitar los timeouts. Los timeouts implican operaciones duplicadas. Es mejor que los relojes son conservativos.

Procesamiento rpido de TPDUs


La clave en el procesamiento rpido de TPDUs es identificar y acelerar el caso normal (transferencia de datos en un sentido). En el caso normal del transmisor, los encabezamientos de TPDUs seguidos son casi los mismos. La entidad de transporte mantiene un encabezamiento de prototipo que copia a un buffer. Entonces sobreescribe los campos que cambian.

Procesamiento rpido de TPDUs


En el receptor el primer paso es identificar la conexin a que pertenece el TPDU (por ejemplo, usando una tabla de hash y las direcciones de socket). Una optimizacin aqu es mantener un puntero al ltimo registro usado y probarlo primer; da una taza de ciertos de 90%. Si el TPDU es uno normal, se llama un procedimiento de camino rpido. Copia los datos a usuario y calcula el checksum a la vez (eliminando un pase adicional). En general el esquema de chequear si el encabezamiento es lo esperado y tener un procedimiento para manejarlo se llama la prediccin de encabezamiento. Con estas y otras optimizaciones es posible que TCP corra con una velocidad de 90% de una copia local de memoria a memoria.

Procesamiento rpido de TPDUs


Otro rea para optimizacin es la administracin de relojes. La mayora de los relojes nunca expiran. Una posibilidad es manejar los relojes como una lista; cada entrada contiene un contador que indica cuantos ticks despus su predecesor expira. Entonces se decrementa la entrada en la cabeza a cero. Un esquema ms eficiente (sin el costo alto de insertar y eliminar) es usar una rueda de reloj. Hay que saber el intervalo mximo de un timeout. Se usa un array circular donde cada tick corresponde a una entrada. Las entradas son punteros a los relojes por el tiempo indicado.

You might also like