Objetivo - 1.04 Explicar las características y funcionalidad de los protocolos y tecnologías específicas para la capa de transporte

Comparar finalidad / contraste y la funcionalidad de MTU y MSS

MTU

La MTU es el tamaño máximo de una unidad de datos individual (por ejemplo, una trama) de las comunicaciones digitales. El tamaño de la MTU es inherentes a las propiedades de las interfaces de red físicas, normalmente medido en bytes. La MTU de Ethernet, por ejemplo, es de 1500 bytes. Algunos tipos de redes (como Token Ring) tienen mayor MTU, y algunos tipos tienen MTU menores, pero los valores son fijos para cada tecnología física.

Protocolos de red de nivel superior, como TCP / IP se pueden configurar con un tamaño máximo de paquete, un parámetro independiente de la capa física MTU sobre el que se ejecuta TCP / IP. Por desgracia, muchos dispositivos de red utilizan los términos indistintamente. En ambos routers de banda ancha domésticas y consolas de juegos habilitadas como Xbox Live, por ejemplo, el parámetro llamado MTU es de hecho el tamaño de los paquetes TCP máximo y no la MTU física.




En Microsoft Windows, el tamaño máximo de paquete de protocolos como TCP se puede configurar en el Registro. Si este valor es demasiado bajo, los flujos de tráfico de la red se dividen en un número relativamente grande de pequeños paquetes que afecta negativamente al rendimiento. Xbox Live, por ejemplo, requiere el valor de MTU (tamaño de paquete) por al menos 1365 bytes. Si el tamaño máximo de paquete TCP es demasiado alto, se superará la MTU física de la red y también degradará el rendimiento al exigir que cada paquete se divida en otros más pequeños (un proceso conocido como fragmentación). Microsoft Windows asigna por defecto a un tamaño máximo de paquete de 1500 bytes para conexiones de banda ancha y 576 bytes para conexiones de acceso telefónico.

Los problemas de rendimiento también pueden ocurrir si el TCP “MTU”, característica en el router de banda ancha doméstica, difiere de la configuración de los dispositivos individuales conectados a él.


TCP tamaño máximo de segmento (MSS)

MSS

Durante el establecimiento de sesión de conexión, dos pares, o los host, entablan negociaciones para determinar el tamaño del segmento IP de los paquetes que van a intercambiar durante su comunicación. El tamaño de segmento se basa en el valor de opción MSS (tamaño máximo de segmento) y se establece en los paquetes TCP SYN (sincronizar) que intercambian los pares durante la negociación de sesión. El valor del campo MSS que se configura viene determinado en gran medida por la unidad de transmisión máxima (MTU) de las interfaces de los pares están conectados directamente a.


Sobre TCP y MSS

El protocolo TCP está diseñado para limitar el tamaño de los segmentos de datos a un máximo de número de bytes. El propósito de esto es para limitar la necesidad de fragmentar los segmentos de datos para la transmisión en el nivel IP. El MSS TCP especifica el número máximo de bytes que el campo de datos de un paquete TCP, o segmento, pueden contener. Se refiere a la cantidad máxima de datos TCP en un único datagrama IP que el sistema local puede aceptar y volver a montar.

Un paquete TCP incluye datos para los encabezados, así como datos contenidos en el segmento. Si el valor de MSS es demasiado bajo, el resultado es un uso ineficiente del ancho de banda; se requieren más paquetes para transmitir los datos. Un valor de MSS que se establece demasiado alto podría resultar en un datagrama IP que es demasiado grande para enviarlo y que deben ser fragmentados.
Normalmente, un host basa su valor MSS en la unidad de transmisión máxima de su interfaz de salida tamaño (MTU). La MTU es el tamaño máximo de trama a lo largo de la trayectoria entre pares.

Un paquete es fragmentado cuando se supera el tamaño de MTU. Debido a la variación del tamaño de la MTU de las interfaces de equipos en el camino tomado por los paquetes TCP entre dos pares, algunos paquetes que están dentro del tamaño MSS negociado de los dos pares pueden ser fragmentados, pero en cambio se dejan caer y se envía un mensaje de error ICMP al host de origen del paquete.

Para disminuir la probabilidad de fragmentación y para proteger contra la pérdida de paquetes, se puede disminuir el TCP MSS.

Explicar el propósito y la funcionalidad de TCP

TCP

TCP es un subconjunto del conjunto de protocolos de Internet, que a menudo se llama TCP / IP, aunque la sigla TCP / IP hace referencia a sólo dos de los muchos protocolos en el conjunto de protocolos de Internet. Aún así, la mayoría de la gente se refiere a los protocolos de Internet como TCP / IP.

TCP es un protocolo orientado a la conexión que proporciona los controles de flujo y servicios de entrega de datos fiables. Estos servicios se ejecutan en los equipos host en cada extremo de una conexión, no en la propia red. Por lo tanto, TCP es un protocolo para la gestión de conexiones de extremo a extremo. Pueden existir conexiones de extremo a extremo a través de una serie de conexiones punto a punto, que a menudo son llamados circuitos virtuales. 


Terminología

-->

Conexiones	Dos ordenadores crean una conexión para intercambiar datos. Los sistemas se sincronizan entre sí para gestionar los flujos de paquetes y adaptarse a la congestión en la red.
Operaciones Full Duplex	Una conexión TCP es un par de circuitos virtuales (uno en cada dirección). Sólo los dos sistemas finales pueden utilizar la conexión.
Comprobación de Errors	Una técnica de suma de control se utiliza para verificar que los paquetes no están dañados.
Secuenciación	Los paquetes se numeran de forma que el destino puede reordenar los paquetes y determinar si un paquete no se encuentra.
Reconocimientos	Tras la recepción de uno o más paquetes, el receptor devuelve un acuse de recibo (llamado un "ACK") al remitente que indica que recibió los paquetes. Si los devuelven los paquetes “Acked”, el remitente puede retransmitir los paquetes (o terminar la conexión si se piensa que el receptor se ha caído).
Control de Flujo	Si el remitente está desbordando al receptor mediante una transmisión demasiada rápida, el receptor descarta los paquetes. ACK fallidos alertan al remitente para ralentizar o detener el envío.
Servicios de Recuperación de Paquetes	El receptor puede solicitar la retransmisión de un paquete. Además, si en la recepción de paquetes no se devuelven los paquetes “ACK”, el remitente volverá a enviar los paquetes.

Los servicios de entrega de datos fiables son fundamentales para aplicaciones tales como la transferencia de archivos, servicios de bases de datos, procesamiento de transacciones y otras aplicaciones de misión crítica en la que debe ser Entregado-Garantizado cada paquete.

Mientras que el TCP proporciona estos servicios fiables, depende de IP para los paquetes de entrega. IP se refiere a menudo como un servicio fiable o mejor esfuerzo. Si bien parece extraño para construir una red que no es fiable, los arquitectos del Internet original querían eliminar la mayor cantidad de servicios de la red en sí misma para apoyar la entrega rápida de paquetes en lugar de fiabilidad. Los routers no hacen un seguimiento de los paquetes o lo que sea para asegurar la entrega. Los routers solo envían paquetes.

El supuesto era que los sistemas finales serían relativamente dispositivos inteligentes con memoria y procesadores. Los dispositivos finales podrían manejar todas las funciones de fiabilidad en lugar de la red. Este fue en realidad un enfoque radical en el momento, pero las consecuencias han sido profundas. Esto significaba que los sistemas finales se convertirían en el foco de desarrollo de aplicaciones para Internet, no la red.

Por el contrario, la red telefónica implementa una arquitectura en la que los dispositivos finales (teléfonos) son tontos y la red es supuestamente “inteligente.” El único problema con este modelo es que no se pueden ejecutar aplicaciones en su teléfono que se aprovecha de la red . De hecho, usted es totalmente dependiente de la compañía de teléfonos para desplegar nuevas aplicaciones (llamada en espera e identificador de llamadas son ejemplos). En comparación con Internet, el sistema telefónico es un dinosaurio. Tengamos en cuenta que la interfaz de usuario para la Web es un navegador gráfico a todo color, mientras que la interfaz de la red telefónica es un teclado de 12 teclas!

Mientras que los sistemas finales proporcionan funciones de confiabilidad de TCP, no todas las aplicaciones las necesitan. Por ejemplo, no hay necesidad de recuperar los paquetes perdidos en una secuencia de vídeo en directo. En el momento en que se recuperan, el espectador ya ha visto el problema técnico apenas visible causado por el paquete faltante. Estas aplicaciones sólo necesitan velocidad. Así UDP fue creado para proporcionar una interfaz de aplicación a la red para aplicaciones en tiempo real que no necesitan servicios adicionales de TCP. UDP proporciona una conexión de puerto muy simple entre aplicaciones y el protocolo.


Apretón de manos de tres vías de TCP

Un apretón de manos de tres vías de TCP es un método de inicialización de una sesión de Protocolo de Control de Transmisión (TCP) entre dos hosts en una red TCP / IP. El apretón de manos establece una conexión lógica entre los hosts mediante la sincronización de los parámetros de envío TCP y recepción de paquetes y comunicantes entre los equipos.


Cómo funciona el TCP de tres vías del apretón de manos

Toda la comunicación TCP es orientada a la conexión. Una sesión TCP debe ser establecida antes de que los equipos intercambien datos. Los paquetes que se transfieren entre los hosts se contabilizan mediante la asignación de un número de secuencia a cada paquete. Un ACK, o acuse de recibo, se envía después de que se reciba cada paquete. Si no se recibe ACK para un paquete, se re-envía el paquete. El enlace de tres vías asegura que la solicitud inicial es reconocida, que los datos se envían, y que se reconocen los datos.

Estas son las tres etapas de un enlace de tres vías TCP:

•    El host que inicia el intrcambio envía un paquete TCP solicitar una nueva sesión. Este paquete contiene el número de secuencia del host para la conexión. El paquete incluye información tal como una etiqueta SYN (sincronización) y datos sobre el tamaño de la memoria intermedia de ventana en el host iniciador.

•   El host de destino envía un paquete TCP con su propio número de secuencia y un ACK de número de secuencia primer paquete del host.

•    El host emisor envía un ACK que contiene el número de secuencia de destino que ha recibido.

Nota: Un proceso de tres vías similar se utiliza para terminar una sesión TCP entre dos hosts. Utilizando el mismo tipo de apretón de manos para finalizar la conexión se asegura de que los hosts han completado sus transacciones y que todos los datos se anotaron.


Explicar el propósito y la funcionalidad de la UDP

UDP

UDP significa Protocolo de datagramas de usuario. UDP proporciona un sistema de entrega de paquetes no fiable construido en la parte superior del protocolo IP. Al igual que con IP, cada paquete es individual y se maneja por separado. Debido a esto, la cantidad de datos que puede ser enviada en un paquete UDP se limita a la cantidad que puede ser contenida en un solo paquete IP. Por lo tanto, un paquete UDP puede contener como máximo 65507 bytes (este es el 65535 bytes IP tamaño de paquete menos la cabecera IP mínimo de 20 bytes y menos la cabecera de UDP de 8 bytes).

Los paquetes UDP pueden llegar fuera de orden o no llegar. Ningún paquete tiene ningún conocimiento del paquete precedente o siguiente. El receptor no reconoce los paquetes, por lo que el emisor no sabe que la transmisión se ha realizado correctamente. UDP no tiene disposiciones para el control de flujo - paquetes pueden ser recibidos más rápido de lo que pueden ser utilizados. Llamamos a este tipo de comunicación como "sin conexión", porque los paquetes no tienen ninguna relación entre sí y porque no hay un estado mantenido.

La dirección IP de destino y número de puerto se encapsulan en cada paquete UDP. Estos dos números identifican de manera única el receptor y son utilizados por el sistema operativo subyacente para entregar el paquete a un proceso específico (aplicación). Cada paquete UDP también contiene la dirección IP y el puerto número del remitente.

Una manera de pensar UDP es por analogía con las comunicaciones a través de una carta. Usted escribe la carta (esto es los datos que está enviando); pone la carta dentro de un sobre (el paquete UDP); dirección en el sobre (utilizando una dirección IP y un número de puerto); ponersu dirección de remitente en el sobre (su dirección IP local y el número de puerto); y luego envía la carta.
Al igual que una carta de verdad, no hay manera de saber si se ha recibido un paquete UDP. Si envía una segunda carta un día después de la primera, la segunda puede ser recibida antes que la primera. O bien, el segundo puede que nunca se reciba.





Explicar el propósito y la funcionalidad de los puertos en general

Puertos de protocolo

En TCP y UDP, un puerto es un punto final a una conexión lógica y la forma en que un programa cliente especifica un programa concreto en un servidor o en un ordenador de una red. Hay 65.535 puertos disponibles por dirección IP y muchos de estos puertos están reservados para aplicacioones conocidas.

Un servidor ofrece sus servicios a través de puertos numerados; uno para cada servicio que está disponible en el servidor. Por ejemplo, si una máquina servidor se está ejecutando un servidor web y un servidor de protocolo de transferencia de archivos (FTP), el servidor Web sería típicamente disponibles en el puerto 80, y el servidor FTP estaría disponible en el puerto 21. Los clientes se conectan a un servicio en una dirección IP específica y en un número de puerto específico.

Una vez que un cliente se ha conectado a un servicio en un determinado puerto, se accede al servicio a través de un protocolo específico. Los protocolos son a menudo de texto y simplemente describen cómo el cliente y el servidor tendrán su conversación. Cada servidor Web en Internet cumple con el protocolo de transferencia de hipertexto (HTTP).




Explicar cómo se producen retransmisiones

Tiempo de espera de TCP y retransmisión

El Protocolo de Control de Transmisión proporciona un servicio de comunicación en un nivel intermedio entre un programa de aplicación y el protocolo de Internet. Proporciona conectividad host-to-host de la capa de transporte del modelo de Internet. Una aplicación no necesita conocer los mecanismos particulares para el envío de datos a través de un enlace a otro host, tales como la fragmentación del paquete requerido del medio de transmisión. En la capa de transporte, el protocolo se encarga de todos los "apretones de manos" y de transmisión de datos y presenta una abstracción de la conexión de red a la aplicación.

En los niveles inferiores de la pila de protocolos, debido a la congestión de red, el balanceo de la carga de tráfico, u otro comportamiento impredecible de la red, los paquetes IP se pueden perder, duplicar, o entregarse fuera de orden. TCP detecta estos problemas, solicita la retransmisión de los datos perdidos, reorganiza el orden de los datos, e incluso ayuda a minimizar la congestión de la red para reducir la ocurrencia de los otros problemas. Si los datos sigue sin ser entregados, su fuente es notificada de este fracaso. Una vez que el receptor TCP ha vuelto a montar la secuencia de octetos transmitidos originalmente, los pasa a la aplicación receptora. Por lo tanto, la comunicación TCP abstrae de la aplicación de los detalles de redes subyacentes.

TCP es un servicio de entrega de flujo fiable que garantice que todos los bytes recibidos serán idénticos con los bytes enviados y en el orden correcto. Dado que la transferencia de paquetes a través de muchas redes no es fiable, una técnica conocida como acuse de recibo positivo con retransmisión se utiliza para garantizar la fiabilidad de transferencias de paquetes. Esta técnica fundamental requiere que el receptor responda con un mensaje de reconocimiento, una vez recibe los datos. El emisor mantiene un registro de cada paquete que envía. El remitente también mantiene un contador de tiempo desde que se envió el paquete, y retransmite un paquete si el temporizador expira antes de que el mensaje haya sido reconocido. Se necesita el temporizador en caso de que un paquete se pierde o está dañado.

Mientras IP se encarga de la entrega real de los datos, TCP realiza un seguimiento de las unidades individuales de transmisión de datos, llamados segmentos, y donde un mensaje se divide para el enrutamiento eficiente a través de la red. Por ejemplo, cuando un archivo HTML se envía desde un servidor web, la capa de software TCP del servidor divide la secuencia de octetos del archivo en segmentos y los reenvía de forma individual a la capa de software IP (Capa de Internet). La capa de Internet encapsula cada segmento TCP en un paquete IP mediante la adición de una cabecera que incluye (entre otros datos) la dirección IP de destino. Cuando el programa cliente en el equipo de destino los recibe, la capa TCP (Transport Layer) vuelve a ensamblar los segmentos individuales y asegura que estaén ordenados correctamente y sin errores, y los transmite a la aplicación.




Explicar el propósito y el proceso de un restablecimiento

¿Cuáles son los paquetes TCP RST?

De acuerdo con RFC 793, se especifica una opción en la parte de Banderas de la cabecera TCP llamado Reset (o RST). El bit de reinicio está diseñado para permitir a una dispositivo abortar la conexión TCP con otro. Esto puede ocurrir por varias razones.

Si un dispositivo involucrado en una sesión TCP se da cuenta de que no está recibiendo reconocimientos (Ack) para cualquier cosa que envía, la conexión no está sincronizada, y el equipo debe enviar un reinicio. Esta es una conexión entreabierta, donde sólo un lado está implicado en la sesión TCP. Esto no podría funcionar por la propia definición del protocolo.

Los paquetes RST son una señal de que las conexiones TCP están entreabiertas. Una estación o el otro dejaron de enviar información o ACK por alguna razón. Hay momentos aceptables para paquetes RST, sin embargo, si hay un gran número de paquetes RST en una conversación, esto es definitivamente algo para solucionar. ¿De qué lado está enviando el RST? ¿Qué está causando que para enviar el RST? ¿Esto sucede de inmediato en la configuración de TCP, o se trata más adelante en la sesión? ¿hay alguna razón por la que la estación quiera abortar la sesión en medio de la transferencia de datos?


Describir las distintas opciones TCP

La longitud de este campo se determina por el campo de desplazamiento de datos. Las opciones tienen hasta tres campos: Option-Kind (1 byte), Option-Length (1 byte), Option-Data (variable). 

El campo Option-Kind indica el tipo de opción, y es el único campo que no es opcional. Dependiendo de qué tipo de opción que nos ocupa, se pueden establecer las siguientes dos campos: el campo Option-Length indica la longitud total de la opción, y el campo Opction-Data contiene el valor de la opción, si procede. Por ejemplo, un byte de Option-Kind de 0x01 indica que esta es una opción NO-OP y se utiliza sólo para el relleno, y no tiene una Option-Length o byte de Option-Data que le sigue. Un byte de Option-Kind de 0 es la opción Fin de Opciones, y es de un sólo byte. Un byte Optionn-Kind de 0x02 indica que esta es la opción tamaño máximo de segmento, y será seguido por un byte que especifica la longitud del campo de MSS (debe ser 0x04). Tenga en cuenta que esta longitud es la longitud total del campo de opciones dado, incluyendo bytes de Option-Length y Option-Kind. Así, mientras que el valor MSS se expresa típicamente en dos bytes, la longitud del campo será de 4 bytes (+2 bytes de tipo y longitud). En resumen, un campo de opción SMS con un valor de 0x05B4 se mostrará como (0x02 0x04 0x05B4) en la sección Opciones de TCP.

Algunas opciones sólo pueden enviarse cuando se establece el SYN

0 (8 bits) - Fin de la lista de opciones 

1 (8 bits) - ninguna operación (NOP, relleno). Esto puede ser utilizado para alinear los campos de opciones en los límites de 32 bits para un mejor rendimiento.

2,4, SS (32 bits) - tamaño máximo de segmento (ver tamaño máximo de segmento) 

3,3, S (24 bits) - Escala de ventana (escalado de ventanas para más detalles)

4,2 (16 bits) - Reconocimiento selectivo permitido. (Ver reconocimientos selectivos para más detalles)

5, N, BBBB, EEEE, ... (bits variables, N es o bien 10, 18, 26, o 34) - acuse de recibo selectivo (SACK). Estos dos primeros bytes son seguidos por una lista de 1-4 bloques siendo reconocidos selectivamente, especificado como 32 bits comienzan / punteros finales.

8,10, TTTT, EEEE (80 bits) - Marca de tiempo y eco de marca de tiempo anterior (ver marcas de tiempo TCP para más detalles)

(Las opciones restantes son históricos, obsoleto, experimental, aún no estandarizada, o no asignado)


Describir un error de suma de comprobación TCP

Comprobación TCP

El Protocolo de control de transmisión está diseñado para proporcionar la transferencia de datos fiable entre un par de dispositivos en una interconexión de redes IP. Gran parte de los esfuerzos necesarios para asegurar la entrega fiable de los segmentos de datos se centroaron en el problema de garantizar que los datos no se pierdan en el tránsito. Pero hay otro impedimento de fundamental importancia para la transmisión segura de datos: el riesgo de errores que se introduce en un segmento TCP durante su recorrido a través de la red interna.


La detección de errores de transmisión que utilizan sumas de comprobación

Si los datos se ponen donde tiene que ir, pero están dañados y no lo detectamos, esto es muy malo. Para proporcionar una protección básica contra los errores en la transmisión, TCP incluye un campo de suma de comprobación de 16 bits en su cabecera. La idea detrás de una suma de control es muy sencilla: tomar una cadena de bytes de datos y ponerlos a todos juntos. A continuación, enviar esta suma con el flujo de datos y que el receptor compruebe la suma. En TCP, un algoritmo especial se utiliza para calcular esta suma de comprobación por el dispositivo que envía el segmento; el mismo algoritmo es entonces empleado por el receptor para comprobar los datos que recibe y asegurarse de que no había errores.

El cálculo de suma de control utilizado por TCP es un poco diferente de un algoritmo de control regular. Una suma de control convencional se realiza sobre todos los bytes que la suma de control está destinada a proteger, y puede detectar la mayoría de los errores de bits en cualquiera de esos campos. Los diseñadores de TCP querían esta protección de errores de bit, pero también desea proteger contra otro tipo de problemas.


Describir cómo gestiona TCP la corrección de errores

Corrección de errores del TCP

Los números de secuencia permiten a los receptores descartar paquetes duplicados y reordenar la secuencia de paquetes. Los Acks permiten a los remitentes determinar cuándo retransmitir los paquetes perdidos.

Para asegurar la corrección, una comprobación del campo está incluido. Cuando se ejecuta TCP sobre IPv4, el método utilizado para calcular la suma de control se define en el RFC 793. La suma de comprobación TCP es una comprobación débil para los estándares modernos. Las capas de enlace de datos con altas tasas de error de bit pueden requerir capacidades adicionales de corrección / detección de errores de enlace. La suma de comprobación débil es parcialmente compensada por el uso común de un CRC o mejor comprobación de integridad en la capa 2, por debajo de TCP y IP, tal como se utiliza en PPP o la trama Ethernet. Sin embargo, esto no quiere decir que la suma de comprobación TCP 16 bits es redundante: notablemente, la introducción de errores en los paquetes entre saltos protegidas-CRC es común, pero la suma de comprobación TCP de extremo a extremo de 16 bits capta la mayor parte de estos errores simples.


Describe cómo se produce el proceso de control de flujo

Control de flujo

TCP utiliza un protocolo de control de flujo de extremo a extremo para evitar que el emisor envíe datos demasiado rápido para que el receptor TCP pueda recibir y procesar de forma fiable. Tener un mecanismo de control de flujo es esencial en un entorno donde las máquinas de diversas velocidades de red se comunican. Por ejemplo, si un PC envía datos a un teléfono inteligente que está procesando lentamente los datos recibidos, el teléfono inteligente debe regular el flujo de datos a fin de no ser colapsado.

TCP utiliza un protocolo de control de flujo de ventana deslizante. En cada segmento TCP, el receptor especifica en el campo de ventana de recepción la cantidad de datos recibidos adicionalmente (en bytes) que está dispuesto para amortiguar para la conexión. El host emisor sólo puede enviar hasta esa cantidad de datos antes de que se debe esperar a una actualización de acuse de recibo y la ventana del host receptor.

Los números de secuencia TCP y ventanas de recepción comportan muy parecido a un reloj. La ventana de recepción se desplaza cada vez que el receptor recibe y reconoce un nuevo segmento de datos. Una vez que se queda sin números de secuencia, el número de secuencia vuelve de nuevo a 0.
Cuando un receptor anuncia un tamaño de ventana de 0, el emisor deja de enviar datos e inicia el temporizador de persistencia. El temporizador de persistencia se utiliza para proteger TCP de una situación de bloqueo que podría surgir si se pierde una actualización del tamaño de la ventana posterior del receptor y el emisor no puede enviar más datos hasta recibir una nueva actualización tamaño de la ventana del receptor. Cuando el temporizador de persistencia expira, el emisor TCP intenta recuperar la conexión mediante el envío de un pequeño paquete de manera que el receptor respondeaenviando otro acuse de recibo que contiene el nuevo tamaño de ventana.

Si un receptor está procesando los datos entrantes en pequeños incrementos, puede anunciar en repetidas ocasiones que quiere negociar una ventana más pequeña. Esto se conoce como el síndrome de ventana tonto, ya que es ineficiente  enviar sólo unos pocos bytes de datos en un segmento TCP, que tiene una cabecera relativamente grande.


El control de congestión

El principal aspecto final del TCP es el control de congestión. TCP utiliza una serie de mecanismos para lograr un alto rendimiento y evitar el colapso de la congestión, donde el rendimiento de la red pueda caer en varios órdenes de magnitud. Estos mecanismos de control de la tasa de datos al entrar en la red, mantenien un flujo de datos inferior a una tasa que activaría el colapso. También producen una asignación justa aproximada de "max-min" entre los flujos.

Los remitentes infieren en condiciones de la red entre los reconocimientos TCP remitente y el uso del receptor para los datos enviados, o la falta de acuses de recibo. Junto con temporizadores, TCP remitentes y receptores puede alterar el comportamiento del flujo de datos. Esto se conoce más generalmente como control de la congestión y / o evitar la congestión de la red.

Las implementaciones modernas de TCP contienen cuatro algoritmos entrelazados: comienzo lento, para evitar la congestión, retransmisión rápida y recuperación rápida (RFC 5681).
Además, los remitentes emplean un tiempo de retransmisión (RTO) que se basa en el tiempo estimado de ida y vuelta (o RTT) entre el emisor y el receptor, así como la variación en este tiempo de ida y vuelta. El comportamiento de este temporizador se especifica en el RFC 6298. Hay sutilezas en la estimación del RTT. Por ejemplo, los remitentes deben tener cuidado cuando el cálculo de muestras de RTT para paquetes retransmitidos; Por lo general se utilizan marcas de tiempo TCP  o de Karn (véase RFC 1323). Estas muestras individuales RTT se promedian en el tiempo para crear un Smooth Round Trip Time (SRTT) usando el algoritmo de Jacobson. Este valor SRTT es lo que se utiliza finalmente como la estimación del tiempo de ida y vuelta.

La mejora de TCP para manejar de forma fiable la pérdida, minimizar los errores, gestionar la congestión y ir rápido en ambientes de muy alta velocidad son las áreas en curso de la investigación y el desarrollo de normas. Como resultado, hay una serie de variaciones del algoritmo de congestión TCP.


Retraso de unión

Retraso de unión, también llamado empalme conexión TCP, es el aplazamiento de la conexión entre el cliente y el servidor con el fin de obtener suficiente información para tomar una decisión de enrutamiento. Algunos conmutadores y routers de aplicación vinculantes retrasan la sesión del cliente al servidor hasta que "los apretones de manos" son adecuados y a fin de evitar ataques de Denegación de Servicio (DoS).