El nivel de transporte

• 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 aplicación. 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.
• Hay los mismos dos tipos de servicio que en el nivel de red: orientado a la conexión o sin conexión. Son muy semejantes a los del nivel de red. Las direcciones y el control de flujo son semejantes también.
• Por lo tanto, ¿por qué tenemos un nivel de transporte? ¿Por qué no solamente el nivel de red? La razón es que el nivel de red es una parte de la subred y los usuarios no tienen ningún 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.).
• El nivel de transporte permite que tengamos un servicio más confiable que el nivel de red. También, 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.

Primitivas del servicio de transporte

• El servicio de transporte orientado a la conexión es confiable, como los pipes en Unix.
• El nivel de transporte puede proveer también un servicio no confiable de datagrama, pero eso no es muy interesante.
• Porque muchos programadores usan las primitivas del servicio de transporte, deben ser convenientes y fáciles de usar.
• Ejemplo: Las entidades de transporte se comunican con TPDUs (Transport Protocol Data Units). Un conjunto de primitivas:

  Primitiva	TPDU mandado
  LISTEN	ninguno
  CONNECT	CONNECTION REQ
  SEND	DATA
  RECEIVE	ninguno
  DISCONNECT	DISCONNECTION REQ

  El cliente hace un CONNECT. Cuando el CONNECTION REQUEST (solicitud de conexión) llega, la entidad de transporte del servidor confirma que el servidor está bloqueado en un LISTEN. Entonces manda un TPDU de CONNECTION ACCEPTED al cliente. Los partidos pueden comunicarse con SEND y RECEIVE, que son confiables. Para desconectar es posible que solamente un partido tiene que mandar un DISCONNECT (caso asimétrico) o ambos (caso simétrico).
• Primitivas de sockets de Berkeley:

  Primitiva	Significado
  SOCKET	Crear nuevo punto de comunicación
  BIND	Ligar el socket con una dirección local
  LISTEN	Alocar cola para llamadas
  ACCEPT	Bloquear hasta que una solicitud llegue
  CONNECT	Bloquear y establecer la conexión
  SEND	Mandar datos
  RECEIVE	Recibir datos
  CLOSE	Cerrar la conexión

  BIND permite la asignación de una dirección explicita (por ejemplo, una dirección bien conocida) con un socket. El servidor llama a las cuatro primeras primitivas en orden. El cliente llama a SOCKET y entonces CONNECT. La desconexión es simétrico.

Protocolos de transporte

• Los protocolos de transporte se parecen los protocolos de enlace. Ambos manejan el control de errores, el control de flujo, la secuencia de paquetes, etc. Pero hay diferencias:
  • En el nivel de transporte, se necesita una manera para especificar la dirección del destino. En el nivel de enlace hay solamente el enlace.
  • En el nivel de enlace es fácil establecer la conexión; el host en el otro extremo del enlace está siempre allí. En el nivel de transporte este proceso es mucho más difícil.
  • En el nivel de transporte, se pueden almacenar paquetes dentro de la subred. Los paquetes pueden llegan cuando no son esperados.
  • El nivel de transporte requiere otro enfoque para manejar los buffers, ya que hay mucho más que conexiones que en el nivel de enlace.
• Cuando una aplicación quiere establecer una conexión con otra aplicación, necesita dar la dirección. Esta dirección es una dirección del nivel de transporte, y se llama un TSAP (Transport Service Access Point). Las direcciones del nivel de red se llaman NSAPs (Network Service Access Points). ¿Cómo sabe una aplicación la dirección del destino?
  • Algunos servicios han existido desde años y tienen direcciones bien conocidos. Para evitar que todos los servicios tienen que correr todo el tiempo (algunos se usan rara vez), puede ser un servidor de procesos que escucha a muchas direcciones a la vez y crea instancias de servicios cuando sea necesario.
  • Para otros servicios se necesitan un servidor de nombres. Esto tiene un TSAP bien conocido y mantiene una lista de nombres (strings) y direcciones. Los servidores tienen que registrarse con el servidor de nombres.
• Dado una dirección TSAP, todavía se necesita una dirección de NSAP. Con una estructura jerárquica para los TSAPs, la dirección NSAP es una parte de la dirección TSAP. Por ejemplo, en la Internet un TSAP es un par que consiste en la dirección de IP (NSAP) y la puerta.

Establecimiento de una conexión

• El problema principal en el establecimiento de una conexión es que la subred puede perder, almacenar, y duplicar los paquetes. En el caso peor un cliente podría abrir una conexión para una transacción, y después la subred podría duplicar todos.
• Para eliminar los paquetes duplicados atrasados, se puede limitar el tiempo de vida máximo de un paquete en la subred (por ejemplo, usando un contador de saltos). Con un límite 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.
• Un problema es que se necesita un método para elegir los números de secuencia que puede tolerar una caída (es decir, hay que asegurar que dos TPDUs con el mismo número 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 número de bits en el contador tiene que ser igual a o mayor del número de bits en los números de secuencia. Un reloj continúa corriendo aun cuando su host se baja.
• Un host usa los $k$ bits más bajos del contador como el valor inicial de su número de secuencia. Los números de secuencia son suficiente grandes que no pueden repetir dentro de la vida de un paquete.
• Después de una caída, un host no sabe donde está en la secuencia. Puede esperar el tiempo de vida máximo de un paquete antes de transmitir otra vez. Porque este tiempo puede ser en general demasiado grande, otro método es controlar la taza de TPDUs mandados por tick para garantizar que no se pueden duplicar números de secuencia. La taza no puede ser demasiado grande (un máximo de uno) ni demasiado pequeña.
• Otro problema es establecer la conexión y intercambiar los valores iniciales de los números de secuencia. Un paquete duplicado atrasado puede causar una falla en este establecimiento. La solución es un three-way handshake. Host 1 manda un CONNECT REQUEST con su número de secuencia. Host 2 manda un acuse de recibo con el número de 1 y su número propio. Finalmente host 1 manda un acuse de recibo con la elección de host 2.

  

Desconexión

• La desconexión asimétrica puede perder datos. La desconexión simétrica permite que cada lado pueda liberar una dirección de la conexión a la vez.
• La desconexión simétrica sufre del problema de los dos ejércitos. Hay dos ejércitos pequeños y separados que quieren atacar un ejército más grande. Si tienen un medio de comunicación mala, ¿cómo pueden sincronizar un ataque?
• 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.
• Se usa el protocolo siguiente: El primer lado manda un DISCONNECT REQUEST (DR) y inicia un reloj. El recipiente entonces manda un DR y inicia un reloj. Cuando lo recibe, el emisor original libera la conexión y manda un ACK. El recipiente lo recibe y libera la conexión también. Si hay un timeout en el receptor, libera la conexión. Si hay un timeout en el emisor, manda el DR otra vez (hasta N intentos) y finalmente libera la conexión. Este protocolo puede fallar si ninguna transmisión del emisor llega.

  

Control de flujo

• Si la subred no es confiable, el emisor tiene que almacenar los TPDUs mandados, como en el nivel de enlace. El receptor puede decidir cuánto espacio en buffers quiere dedicar a sus conexiones, porque sabe si no acepta un paquete el emisor lo reenviará.
• En el caso de tráfico de bajo ancho de banda y en ráfagas, es mejor que se dedican los buffers dinámicamente. Pero con flujos constantes de alto ancho de banda, es mejor si el receptor reserva una ventana completa de buffers para permitir la velocidad máxima de datos.
• La asignación dinámica de buffers corresponde al uso de ventanas de tamaños variables. El emisor pide algún número de buffers, y el receptor contesta con el número disponible. Durante la conexión el receptor puede cambiar este número. 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 emisor también tiene que controlar el tamaño 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 tamaño de $cr$. Con este tamaño la conexión normalmente está llena. El emisor puede medir y monitorear estos parámetros.

Multiplexación

• 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 organización tener muchos circuitos abiertos a la vez. Por lo tanto se usa la multiplexación hacia arriba, con más de una conexión de transporte en una sola conexión de red.
• Otra razón para usar la multiplexación es si la subred impone un control de ventana deslizante. Si un usuario necesita más capacidad que es disponible con la ventana, se puede dividir la conexión de transporte entre unas conexiones de red. Esto el la multiplexación hacia abajo.

Recuperación de caídas

• Si una parte de la subred se cae durante una conexión, el nivel de transporte puede establecer una conexión nueva y recuperar de la situación. El problema es más difícil 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 rápidamente, pero ha perdido su posición. Le puede informar al emisor sobre el problema. El emisor puede estar en dos estados: S1, con un TPDU pendiente sin acuse, o S0, con ningún TPDU pendiente. Tiene que decidir si debiera retransmitir el TPDU más reciente.
• El problema es que el emisor no sabe si el receptor ha escrito el contenido de la última TPDU. Por ejemplo, si el emisor retransmite solamente cuando está en S1, tenemos el siguiente problema: El receptor recibió el paquete, generó un acuse, y se cayó sin escribir. El emisor está en S0 y no retransmitirá el paquete.
• 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 emisor está en S1 y retransmitirá el paquete, que es un error. Protocolos más complejos no ayudan cuando tenemos eventos distintos come estos.
• En general se puede recuperar de las caídas solamente si hay suficiente estado preservado.

El protocolo de TCP

• El fin de TCP es proveer un flujo de bytes confiable de extremo a extremo sobre una internet no confiable. TCP puede adaptarse dinámicamente a las propiedades de la internet 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 mande como datagramas de IP.
• Para obtener servicio de TCP, el emisor y el receptor tienen que crear los puntos terminales de la conexión (los sockets).
  • La dirección de un socket es la dirección de IP del host y un número de 16 bits que es local al host (la puerta).
  • Se identifica una conexión con las direcciones de socket de cada extremo; se puede usar un socket para conexiones múltiples a la vez.
  • Los números de puerta bajo 256 son puertas bien conocidas para servicios comunes (como FTP).
• Las conexiones de TCP son punto-a-punto y full dúplex. No preservan los límites de mensajes.
• Cuando una aplicación manda datos a TCP, TCP puede mandarlos inmediatamente o almacenarlos (para acumular más). Una aplicación puede solicitar que TCP manda los datos inmediatamente a través del flag de PUSH (empujar).
• TCP también apoya los datos urgentes. TCP manda datos con el flag URGENT inmediatamente. En el destino TCP interrumpe la aplicación (la manda una señal), que permite que la aplicación pueda encontrar los datos urgentes.

Implementación del protocolo

• Cada byte en una conexión de TCP tiene su propio número de secuencia de 32 bits.
• En TCP se mandan datos en segmentos. Un segmento tiene un encabezamiento de 20 bytes (más opciones) y datos de cero o más bytes. Hay dos límites en el tamaño de segmentos: el tamaño máximo de un paquete de IP (64K bytes) y la unidad de transferencia máxima (MTU, maximum transfer unit) de cada red.
• Si un segmento es demasiado grande para una red, los ruteadores lo puede dividir en segmentos nuevos (cada segmento nuevo añade un overhead de 40 bytes).
• TCP usa un protocolo de ventana deslizante. Cuando un emisor manda un segmento, inicia un reloj. El destino responde con un segmento que contiene un acuse de recibo con un número de acuse igual al próximo número de secuencia que espera. Si el reloj termina antes de que llegue el acuse, el emisor manda el segmento de nuevo. 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 fragmentación y retransmisión, es posible que fragmentos de una transmisión y una retransmisión lleguen a la vez.
  • La red puede tener congestión.

El encabezamiento de TCP

• La puerta de la fuente y del destino identifican la conexión.
• El número de secuencia y el número de acuse de recibo son normales. El último especifica el próximo byte esperado.
• La longitud (4 bits) indica el número de palabras de 32 bits en el encabezamiento, ya que el campo de opciones tiene una longitud variable.
• Los flags:
  • URG. Indica que el segmento contiene datos urgentes. El puntero urgente punta al desplazamiento del número de secuencia corriente donde están los datos urgentes.
  • ACK. Indica que hay un número 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 conexión.
  • SYN. Se usa para establecer las conexiones. Una solicitud de conexión tiene SYN = 1 y ACK = 0, mientras que la aceptación de una conexión tiene SYN = 1 y ACK = 1.
  • FIN. Indica que el emisor no tiene más datos a mandar. La desconexión es simétrica.
• TCP usa una ventana de tamaño variable. Este campo indica cuantos bytes se pueden mandar después del byte de acuse. El valor cero es legal; uno puede dar la permisión transmitir de nuevo con un segmento con el mismo número de acuse y una ventana más de cero.
• El checksum provee más confiabilidad.
• Las opciones permiten que los hosts puedan especificar el segmento máximo que están 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$.

Administración de conexiones

• TCP usa el three-way handshake para establecer una conexión. Si un segmento de solicitud de conexión 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 conexión entre los mismos sockets simultáneamente. Resulta en una sola conexión.
• Se usa un reloj para asignar los números iniciales de secuencia. Después de una caída un host tiene que esperar el tiempo de vida máximo de un paquete (120 segs).
• Para desconectar un sentido de la conexión, TCP manda un paquete de FIN y entonces espera un acuse. Para evitar el problema de los dos ejércitos el emisor desconecta después de dos tiempos máximos de vida de un paquete.

Política de transmisión

• Cuando la ventana tiene un tamaño de cero, el emisor 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 emisores no tienen que mandar datos inmediatamente y los receptores no tienen que mandar acuses inmediatamente. Se puede usar esta flexibilidad para mejorar el rendimiento.
• Por ejemplo, considera una conexión de TELNET. Cada carácter tipiado genera un paquete de IP de 41 bytes, seguido por un acuse de 40 bytes, seguido por una actualización de la ventana de 40 bytes cuando la aplicación lee el carácter, seguido por 41 bytes cuando la aplicación hace un eco del carácter, y finalmente 40 y 40 más.
• Una optimización es demorar los acuses y las actualizaciones de ventana por 500 msegs para usar piggybacking.
• Una segunda optimización para minimizar los segmentos con solamente un byte de información 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 máximo.
• Otro problema es el síndrome tonto de ventana. En esto la ventana del receptor está llena. La aplicación en el receptor lee un byte, que causa que el receptor manda una actualización del tamaño de ventana al emisor. El emisor manda un byte y la ventana está llena otra vez. La solución de Clarke es no mandar una actualización de ventana hasta que el receptor pueda manejar el segmento máximo de la conexión o el buffer esté medio vació, cualquier es menor. También el emisor no manda segmentos pequeños (si posible). Debiera esperar hasta que haya suficiente espacio en la ventana para un segmento completo o el buffer del receptor esté medio vacío (según su estimación de su tamaño).

Control de congestión

• TCP trata de manejar la congestión usando la conservación del número 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 dinámicamente el tamaño de la ventana.
• El primer paso es detectar la congestión. Antes era difícil ya que el timeout de un paquete perdido podía haber causado por ruido en la línea o congestión en un ruteador. Ahora la mayoría de los timeouts son debidos a la congestión.
• Hay dos problemas distintos que tenemos que solucionar: la capacidad de la red y la capacidad del recipiente. Para manejar cada uno, el emisor mantiene dos ventanas. Una ventana se negocia con el recipiente, y su tamaño es basado en el tamaño del buffer del recipiente. La otra ventana es la ventana de congestión. El emisor solamente puede mandar el mínimo de las dos ventanas.
• Cuando se establece una conexión, el emisor inicializa la ventana de congestión al tamaño del segmento máximo de la conexión. Si puede mandar un segmento máximo sin un timeout, se dobla el tamaño de la ventana y se mandan dos segmentos máximos. Este aumento continúa hasta que hay un timeout. Se llama la salida lenta, pero no es lenta, sino exponencial.
• Para controlar la congestión hay un tercer parámetro, 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 congestión, y se establece la ventana de congestión a un segmento máximo. Otra vez se usa la salida lenta, pero después de llegar al umbral la ventana crece solamente por un segmento máximo a la vez (es decir, linealmente) hasta la ventana del receptor.

Administración de relojes

• TCP usa un reloj de retransmisión para determinar si debiera retransmitir un segmento. ¿Por cuánto 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 rápidamente mientras que la congestión crece y desparece. Si el timeout es demasiado largo el rendimiento sufre, pero si es demasiado corto hay retransmisiones innecesarias.
• Se usa un algoritmo debido a Jacobson. TCP mantiene un variable RTT para cada conexión con una estimación del tiempo de ida y vuelta. Si el próximo segmento toma $M$ segundos, se actualiza RTT según RTT = alpha RTT + (1-alpha)M. Un valor típico para $alpha$ es $7/8$.
• Dado RTT hay que elegir todavía un timeout de retransmisión. TCP normalmente usa $beta\; RTT$, donde $beta$ debiera ser proporcional (más o menos) a la desviación estándar. Se usa la desviación promedia $D$, donde D = alpha D + (1-alpha)|RTT - M|. $alpha$ puede ser distinta a la previa.
• Finalmente, el timeout normalmente es $$RTT+4D.
• Un problema en la estimación 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 retransmisión. 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.
• TCP mantiene también un reloj de persistencia. El emisor lo usa para prevenir el bloqueo indefinido en el caso donde el emisor cree que la ventana del receptor es cero y la actualización del receptor fue perdido.
• Algunas implementaciones usan un reloj de keepalive (mantener vida) para determinar si el otro lado todavía está allí, y si no, desconectar. Una desventaja es que puede matar una conexión debido a una falla temporal de la red.

Rendimiento

• En general entender el rendimiento de redes es más arte que ciencia. La teoría no ayuda mucho.
• Fuentes de problemas de rendimiento:
  • Congestión.
  • Desequilibrios entre recursos. Por ejemplo, una línea gigabit conectada a un PC.
  • Sobrecarga síncrona. Un TPDU malo mandado en un broadcast puede producir miles de mensajes de error (una tormenta de broadcast. UDP sufría de este problema. Otro ejemplo: Después de una falla de electricidad todas las máquinas que están rebooteando pueden sobrecargar el servidor de RARP.
  • Ajustamiento malo. Si suficiente memoria no es dedicada a buffers, o el algoritmo de planificación 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 emisor y receptor, es muy grande (por ejemplo, 5 megabytes en una conexión transcontinental). Se necesitan ventanas grandes en los receptores.
  • Jitter. Las aplicaciones de audio y video demandan una varianza muy pequeña en la desviación estándar del tiempo de transmisión.
• Medición de rendimiento de redes:
  • Asegurar que la muestra es suficientemente grande para pruebas estadísticas.
  • Usar muestras representativas, con horas y días distintos.
  • Tener cuidado en el uso de un reloj de grano grueso. Con repeticiones de mediciones se puede usar tal reloj para lograr una precisión más alta.
  • Evitar condiciones extrañas (por ejemplo, respaldos durante pruebas). Es mejor usar una red desocupada y generar la carga tú mismo.
  • El uso de cachés de archivos o buffers en el nivel de transporte pueden cambiar las mediciones.
  • Entender exactamente lo que estás midiendo. Por ejemplo, las diferencias en los drivers de red entre dos máquinas distintas pueden ser la fuente de rendimientos distintos.
  • Tener cuidado en extrapolar los resultados; no son necesariamente lineales.

Diseño para rendimiento mejor

• La velocidad de CPU es más 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 mínimo para la comunicación de un RPC (llamada a procedimiento remoto) es 102 microsegundos, pero la realidad es más cerca a 1500 microsegundos. En una red gigabit, el problema es la transferencia de datos del buffer al proceso de cliente.
• Reducir el número de paquetes para reducir el overhead de software. Cada TPDU implica algún procesamiento, más el costo de una interrupción. Con paquetes mayores hay una reducción en el número de paquetes.
• Minimizar los cambios de contexto. Como las interrupciones pueden disminuir el rendimiento drásticamente. Podemos tener, por ejemplo, 4 cambios de contexto entre procesos de usuario, el kernel, y el administrador de red para entregar datos recibidos.
• Minimizar la duplicación. Durante el procesamiento de un paquete en los niveles distintos frecuentemente se duplica algunas veces. Por ejemplo, si una máquina de 50 MIPS hace tres copias de cada palabra y necesita 5 instrucciones por copia, vamos a necesitar 75 nanosegundos por byte. Entonces la máquina no puede manejar más de 107 Mbps, y probablemente no esto, porque hay otro overhead del protocolo, las instrucciones que refieren a la memoria son mucho más lentas, etc.
• Puedes comprar más ancho de banda pero no retraso menor. La velocidad de luz es un límite inevitable.
• Evitar la congestión es mejor que recuperar de la congestión. Cuando hay congestión 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 rápido de TPDUs

• La clave en el procesamiento rápido de TPDUs es identificar y acelerar el caso normal (transferencia de datos en un sentido).
• En el caso normal del emisor, 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.
• En el receptor el primer paso es identificar la conexión a que pertenece el TPDU (por ejemplo, usando una tabla de hash y las direcciones de socket). Una optimización 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 rápido. 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 que es esperado y tener un procedimiento para manejarlo se llama la predicción 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.
• Otro área para optimización es la administración de relojes. La mayoría de los relojes nunca expiran. Una posibilidad es manejar los relojes como una lista; cada entrada contiene un contador que indica cuantos ticks después su predecesor expira. Entonces se decrementa la entrada en la cabeza a cero.
• Un esquema más eficiente (sin el costo alto de insertar y eliminar) es usar una rueda de reloj. Hay que saber el intervalo máximo 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.