Protocolo de Control de Transmisión

El Protocolo de control de transmisión (TCP) es uno de los principales protocolos del conjunto de protocolos de Internet. Se originó en la implementación inicial de la red en la que complementó el Protocolo de Internet (IP). Por lo tanto, la suite completa se conoce comúnmente como TCP/IP. TCP proporciona una entrega confiable, ordenada y con verificación de errores de un flujo de octetos (bytes) entre aplicaciones que se ejecutan en hosts que se comunican a través de una red IP. Las principales aplicaciones de Internet, como la World Wide Web, el correo electrónico, la administración remota y la transferencia de archivos, dependen de TCP, que forma parte de la capa de transporte de la suite TCP/IP. SSL/TLS a menudo se ejecuta sobre TCP.

TCP está orientado a la conexión y se establece una conexión entre el cliente y el servidor antes de que se puedan enviar los datos. El servidor debe estar escuchando (abierto pasivo) las solicitudes de conexión de los clientes antes de que se establezca una conexión. El protocolo de enlace de tres vías (apertura activa), la retransmisión y la detección de errores aumentan la confiabilidad pero prolongan la latencia. Las aplicaciones que no requieren un servicio de flujo de datos confiable pueden usar el Protocolo de datagramas de usuario (UDP), que proporciona un servicio de datagramas sin conexión que prioriza el tiempo sobre la confiabilidad. TCP emplea la prevención de la congestión de la red. Sin embargo, existen vulnerabilidades en TCP, que incluyen denegación de servicio, secuestro de conexión, veto de TCP y ataque de reinicio.

Origen histórico

En mayo de 1974, Vint Cerf y Bob Kahn describieron un protocolo de interconexión de redes para compartir recursos mediante la conmutación de paquetes entre los nodos de la red. Los autores habían estado trabajando con Gérard Le Lann para incorporar conceptos del proyecto francés CYCLADES a la nueva red. La especificación del protocolo resultante, RFC 675 (Especificación del programa de control de transmisión de Internet), fue escrita por Vint Cerf, Yogen Dalal y Carl Sunshine y publicada en diciembre de 1974. Contiene el primer uso certificado del término internet, como abreviatura de internetwork.

Un componente de control central de este modelo era el Programa de control de transmisión que incorporaba enlaces orientados a conexión y servicios de datagramas entre hosts. El programa de control de transmisión monolítico se dividió más tarde en una arquitectura modular que consiste en el Protocolo de control de transmisión y el Protocolo de Internet. Esto resultó en un modelo de red que se conoció informalmente como TCP/IP, aunque formalmente se lo denominó modelo del Departamento de Defensa (DOD) y modelo ARPANET, y eventualmente también como Paquete de protocolos de Internet.

En 2004, Vint Cerf y Bob Kahn recibieron el Premio Turing por su trabajo fundamental en TCP/IP.

Función de red

El Protocolo de control de transmisión proporciona un servicio de comunicación a un nivel intermedio entre un programa de aplicación y el Protocolo de Internet. Proporciona conectividad de host a host en la capa de transporte del modelo de Internet. Una aplicación no necesita conocer los mecanismos particulares para enviar datos a través de un enlace a otro host, como la fragmentación de IP requerida para acomodar la unidad de transmisión máxima del medio de transmisión. En la capa de transporte, TCP maneja todos los detalles de intercambio y transmisión y presenta una abstracción de la conexión de red a la aplicación, generalmente a través de una interfaz de socket de red.

En los niveles más bajos de la pila de protocolos, debido a la congestión de la red, el equilibrio de la carga de tráfico o el comportamiento impredecible de la red, los paquetes IP pueden perderse, duplicarse o entregarse desordenados. TCP detecta estos problemas, solicita la retransmisión de datos perdidos, reorganiza los datos desordenados e incluso ayuda a minimizar la congestión de la red para reducir la ocurrencia de otros problemas. Si los datos siguen sin entregarse, se notifica a la fuente de este error. Una vez que el receptor TCP ha reensamblado la secuencia de octetos transmitidos originalmente, los pasa a la aplicación receptora. Por lo tanto, TCP abstrae la comunicación de la aplicación de los detalles de red subyacentes.

Muchas aplicaciones de Internet utilizan ampliamente TCP, incluida la World Wide Web (WWW), el correo electrónico, el protocolo de transferencia de archivos, Secure Shell, el uso compartido de archivos entre pares y la transmisión de medios.

TCP está optimizado para una entrega precisa en lugar de una entrega oportuna y puede generar demoras relativamente largas (del orden de segundos) mientras espera mensajes fuera de servicio o retransmisiones de mensajes perdidos. Por lo tanto, no es particularmente adecuado para aplicaciones en tiempo real como voz sobre IP. Para tales aplicaciones, se recomiendan protocolos como el Protocolo de transporte en tiempo real (RTP) que opera sobre el Protocolo de datagramas de usuario (UDP).

TCP es un servicio confiable de entrega de secuencias de bytes que garantiza que todos los bytes recibidos serán idénticos y en el mismo orden que los enviados. Dado que la transferencia de paquetes por muchas redes no es confiable, TCP logra esto utilizando una técnica conocida como reconocimiento positivo con retransmisión. Esto requiere que el receptor responda con un mensaje de reconocimiento a medida que recibe los datos. El remitente mantiene un registro de cada paquete que envía y mantiene un temporizador desde el momento en que se envió el paquete. El remitente retransmite un paquete si el temporizador expira antes de recibir el acuse de recibo. El temporizador es necesario en caso de que un paquete se pierda o se corrompa.

Mientras que IP maneja la entrega real de los datos, TCP realiza un seguimiento de los segmentos: las unidades individuales de transmisión de datos en las que se divide un mensaje para un enrutamiento eficiente a través de la red. Por ejemplo, cuando se envía un archivo HTML desde un servidor web, la capa de software TCP de ese servidor divide el archivo en segmentos y los reenvía individualmente a la capa de Internet en la pila de red. El software de capa de Internet encapsula cada segmento TCP en un paquete IP agregando un encabezado que incluye (entre otros datos) la dirección IP de destino. Cuando el programa cliente en la computadora de destino los recibe, el software TCP en la capa de transporte vuelve a ensamblar los segmentos y asegura que estén ordenados correctamente y sin errores mientras transmite el contenido del archivo a la aplicación receptora.

Estructura del segmento TCP

El Protocolo de control de transmisión acepta datos de un flujo de datos, los divide en partes y agrega un encabezado TCP creando un segmento TCP. Luego, el segmento TCP se encapsula en un datagrama de Protocolo de Internet (IP) y se intercambia con los pares.

El término paquete TCP aparece tanto en uso informal como formal, mientras que en una terminología más precisa segmento se refiere a la unidad de datos del protocolo TCP (PDU), datagrama a la IP PDU y frame a la PDU de la capa de enlace de datos:

Los procesos transmiten datos llamando al TCP y pasando los búferes de datos como argumentos. El TCP empaqueta los datos de estos buffers en segmentos y llama al módulo de Internet [p. ej. IP] para transmitir cada segmento al destino TCP.

Un segmento TCP consta de un encabezado de segmento y una sección de datos. El encabezado del segmento contiene 10 campos obligatorios y un campo de extensión opcional (Opciones, fondo rosa en la tabla). La sección de datos sigue al encabezado y son los datos de carga útil transportados por la aplicación. La longitud de la sección de datos no se especifica en el encabezado del segmento; se puede calcular restando la longitud combinada del encabezado del segmento y el encabezado IP de la longitud total del datagrama IP especificado en el encabezado IP.

Puerto fuente (16 bits)

Identifica el puerto de envío.

Puerto de destino (16 bits)

Identifica el puerto receptor.

Número de secuencia (32 bits)

Tiene un doble papel:

• Si la bandera SYN se establece (1), entonces este es el número de secuencia inicial. El número de secuencia del primer byte de datos real y el número reconocido en el ACK correspondiente son entonces este número de secuencia más 1.
• Si la bandera SYN es clara (0), entonces este es el número de secuencia acumulada del primer byte de datos de este segmento para la sesión actual.

Número de reconocimiento (32 bits)

Si la bandera ACK se establece entonces el valor de este campo es el siguiente número de secuencia que el remitente de la ACK está esperando. Esto reconoce la recepción de todos los bytes anteriores (si los hay). El primer ACK enviado por cada extremo reconoce el número de secuencia inicial del otro extremo en sí, pero no hay datos.

offset (4 bits)

Especifica el tamaño del encabezado TCP en palabras de 32 bits. El encabezado de tamaño mínimo es de 5 palabras y el máximo es de 15 palabras dando así el tamaño mínimo de 20 bytes y máximo de 60 bytes, permitiendo hasta 40 bytes de opciones en el encabezado. Este campo obtiene su nombre del hecho de que también es el offset desde el inicio del segmento TCP a los datos reales.

Reservado (3 bits)

Para uso futuro y debe establecerse a cero.

Banderas (9 bits)

Contiene 9 banderas de 1 bit (bits de control) como sigue:

• NS (1 bit): ECN-nonce - protección de ocultación
• CWR (1 bit): El host envía una bandera reducida (CWR) para indicar que recibió un segmento TCP con el conjunto de la bandera de la CEPE y respondió en el mecanismo de control de la congestión.
• ECE (1 bit): ECN-Echo tiene un doble papel, dependiendo del valor de la bandera SYN. Indica:

• Si la bandera SYN se establece (1), que el par TCP es capaz de ECN.
• Si la bandera SYN es clara (0), se recibió un paquete con el conjunto de banderas Experimentadas (ECN=11) en el encabezado IP durante la transmisión normal. Esto sirve como una indicación de la congestión de red (o la congestión inminente) al remitente TCP.

• URG (1 bit): Indica que el campo puntero urgente es significativo
• ACK (1 bit): Indica que el campo de reconocimiento es significativo. Todos los paquetes después del paquete inicial SYN enviado por el cliente deben tener este conjunto de bandera.
• PSH (1 bit): Función de empuje. Pide empujar los datos amortiguados a la aplicación receptora.
• RST (1 bit): Restablecer la conexión
• SYN (1 bit): Sincronizar números de secuencia. Sólo el primer paquete enviado de cada extremo debe tener este conjunto de bandera. Algunas otras banderas y campos cambian el significado basado en esta bandera, y algunas sólo son válidas cuando se establece, y otras cuando está clara.
• FIN (1 bit): Último paquete del remitente

Tamaño de ventana (16 bits)

El tamaño del recibe ventana, que especifica el número de unidades de tamaño de ventana que el remitente de este segmento está actualmente dispuesto a recibir. (Ver § Control de flujo y § Escalada de ventana.)

Checksum (16 bits)

El campo de checksum de 16 bits se utiliza para el control de errores del encabezado TCP, la carga útil y un pseudocabetero IP. La pseudocabeza consiste en la dirección IP fuente, la dirección IP de destino, el número de protocolo para el protocolo TCP (6) y la longitud de los encabezados TCP y la carga útil (en bytes).

puntero urgente (16 bits)

Si se establece la bandera URG, este campo de 16 bits es un offset del número de secuencia que indica el último byte de datos urgentes.

Opciones (Variables 0-320 bits, en unidades de 32 bits)

La longitud de este campo es determinada por el offset campo. 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 del valor Option-Kind, se pueden establecer los dos campos siguientes. Option-Length indica la longitud total de la opción, y Option-Data contiene datos asociados con la opción, si es aplicable. Por ejemplo, un byte Option-Kind de 1 indica que esta no es una opción de operación usada sólo para el relleno, y no tiene campos Option-Length o Option-Data siguiendolo. Un byte Option-Kind de 0 marca el final de las opciones, y también es sólo un byte. Un byte Option-Kind de 2 se utiliza para indicar la opción de tamaño máximo de segmento, y será seguido por un byte Option-Length especificando la longitud del campo MSS. Option-Length es la longitud total del campo de opciones dadas, incluyendo campos Option-Kind y Option-Length. Así, mientras que el valor MSS se expresa normalmente en dos bytes, Option-Length será 4. Como ejemplo, un campo de opción MSS con un valor de 0x05B4 se codifica como (0x02 0x04 0x05B4) en la sección opciones TCP.

Algunas opciones sólo se pueden enviar cuando se establece SYN; se indican a continuación como ^[SYN]. Longitudes estándar y de opción dadas como (Option-Kind, Option-Length).

Option-Kind	Option-Length	Option-Data	Propósito	Notas
0	—	—	Lista final de opciones
1	—	—	Sin operación	Esto se puede utilizar para alinear campos de opciones en límites de 32 bits para un mejor rendimiento.
2	4	SS	Tamaño máximo del segmento	Véase § Tamaño máximo del segmento [SYN]
3	3	S	Escala de venta	Ver § Ventana escalando para detalles [SYN]
4	2	—	Reconocimiento selectivo permitido	Ver § Reconocimientos selectivos para detalles[SYN]
5	N (10, 18, 26 o 34)	BBBB, EEEE,...	Reconocimiento selectivo (SACK)	Estos dos primeros bytes son seguidos por una lista de 1–4 bloques que se reconocen selectivamente, especificados como punteros de inicio/fino de 32 bits.
8	10	TTTT, EEEE	Timestamp y eco de tiempos anteriores	See § TCP timestamps for details

Los valores restantes de Option-Kind son históricos, obsoletos, experimentales, aún no estandarizados o no firmados. Las asignaciones del número de opción son mantenidas por la IANA.

Padding

El relleno de cabecera TCP se utiliza para asegurar que el encabezado TCP termine, y los datos comiencen, en un límite de 32 bits. El relleno está compuesto de ceros.

Operación de protocolo

Un diagrama simplificado del estado TCP. Ver diagrama TCP EFSM para diagramas más detallados, incluyendo detalles sobre el estado ESTABLISHED.

Las operaciones del protocolo TCP se pueden dividir en tres fases. Establecimiento de conexión es un proceso de negociación de varios pasos que establece una conexión antes de ingresar a la fase de transferencia de datos. Una vez completada la transferencia de datos, la terminación de la conexión cierra la conexión y libera todos los recursos asignados.

Una conexión TCP es administrada por un sistema operativo a través de un recurso que representa el punto final local para las comunicaciones, el conector de Internet. Durante el tiempo de vida de una conexión TCP, el punto final local sufre una serie de cambios de estado:

Establecimiento de conexión

Antes de que un cliente intente conectarse con un servidor, el servidor primero debe vincularse y escuchar en un puerto para abrirlo a las conexiones: esto se denomina apertura pasiva. Una vez que se establece la apertura pasiva, un cliente puede establecer una conexión iniciando una apertura activa mediante el protocolo de enlace de tres vías (o 3 pasos):

1. SYN: La apertura activa es realizada por el cliente enviando un SYN al servidor. El cliente establece el número de secuencia del segmento a un valor aleatorio A.
2. SYN-ACK: En respuesta, el servidor responde con un SYN-ACK. El número de reconocimiento se establece a uno más que el número de secuencia recibida, es decir A+1, y el número de secuencia que el servidor elige para el paquete es otro número aleatorio, B.
3. ACK: Finalmente, el cliente envía un ACK al servidor. El número de secuencia se establece en el valor de reconocimiento recibido, es decir, A+1, y el número de reconocimiento se establece en uno más que el número de secuencia recibida, es decir, B+1.

Los pasos 1 y 2 establecen y reconocen el número de secuencia para una dirección. Los pasos 2 y 3 establecen y reconocen el número de secuencia para la otra dirección. Después de completar estos pasos, tanto el cliente como el servidor han recibido reconocimientos y se establece una comunicación full-duplex.

Terminación de la conexión

Terminación de conexión

La fase de finalización de la conexión utiliza un protocolo de enlace de cuatro vías, en el que cada lado de la conexión finaliza de forma independiente. Cuando un extremo desea detener su mitad de la conexión, transmite un paquete FIN, que el otro extremo reconoce con un ACK. Por lo tanto, un desmontaje típico requiere un par de segmentos FIN y ACK de cada extremo TCP. Después de que el lado que envió el primer FIN haya respondido con el ACK final, espera un tiempo de espera antes de cerrar finalmente la conexión, tiempo durante el cual el puerto local no está disponible para nuevas conexiones; este estado le permite al cliente TCP reenviar el reconocimiento final al servidor en caso de que el ACK se pierda en tránsito. La duración del tiempo depende de la implementación, pero algunos valores comunes son 30 segundos, 1 minuto y 2 minutos. Después del tiempo de espera, el cliente ingresa al estado CERRADO y el puerto local queda disponible para nuevas conexiones.

También es posible finalizar la conexión mediante un protocolo de enlace de 3 vías, cuando el host A envía un FIN y el host B responde con un FIN & ACK (combinando dos pasos en uno) y el host A responde con un ACK.

Algunos sistemas operativos, como Linux y HP-UX, implementan una secuencia de cierre semidúplex. Si el host cierra activamente una conexión, mientras aún tiene datos entrantes sin leer disponibles, el host envía la señal RST (perdiendo los datos recibidos) en lugar de FIN. Esto asegura que una aplicación TCP sepa que hubo una pérdida de datos.

Una conexión puede estar en un estado semiabierto, en cuyo caso un lado ha terminado la conexión, pero el otro no. El lado que ha terminado ya no puede enviar ningún dato a la conexión, pero el otro lado sí puede. El lado de terminación debe continuar leyendo los datos hasta que el otro lado también termine.

Uso de recursos

La mayoría de las implementaciones asignan una entrada en una tabla que asigna una sesión a un proceso del sistema operativo en ejecución. Debido a que los paquetes TCP no incluyen un identificador de sesión, ambos extremos identifican la sesión utilizando la dirección y el puerto del cliente. Cada vez que se recibe un paquete, la implementación de TCP debe realizar una búsqueda en esta tabla para encontrar el proceso de destino. Cada entrada de la tabla se conoce como bloque de control de transmisión o TCB. Contiene información sobre los puntos finales (IP y puerto), el estado de la conexión, datos en ejecución sobre los paquetes que se intercambian y búferes para enviar y recibir datos.

La cantidad de sesiones en el lado del servidor está limitada únicamente por la memoria y puede crecer a medida que llegan nuevas conexiones, pero el cliente debe asignar un puerto efímero antes de enviar el primer SYN al servidor. Este puerto permanece asignado durante toda la conversación y limita efectivamente la cantidad de conexiones salientes de cada una de las direcciones IP del cliente. Si una aplicación no cierra correctamente las conexiones no requeridas, un cliente puede quedarse sin recursos y no poder establecer nuevas conexiones TCP, incluso desde otras aplicaciones.

Ambos extremos también deben asignar espacio para paquetes no confirmados y datos recibidos (pero no leídos).

Transferencia de datos

El Protocolo de control de transmisión difiere en varias características clave en comparación con el Protocolo de datagramas de usuario:

• Transferencia de datos ordenada: el host de destino reorganiza segmentos según un número de secuencia
• Retransmisión de paquetes perdidos: cualquier flujo acumulativo no reconocido es retransmitido
• Transferencia de datos sin errores: los paquetes dañados se tratan como perdidos y son retransmitidos
• Control de flujo: limita la tasa que un remitente transfiere datos para garantizar una entrega fiable. El receptor insinúa continuamente al remitente cuántos datos se pueden recibir. Cuando el buffer del host receptor se llena, el siguiente reconocimiento suspende la transferencia y permite procesar los datos en el búfer.
• Control de congestión: paquetes perdidos (presumados por congestión) desencadenan una reducción de la tasa de entrega de datos

Transmisión confiable

TCP utiliza un número de secuencia para identificar cada byte de datos. El número de secuencia identifica el orden de los bytes enviados desde cada computadora para que los datos puedan reconstruirse en orden, independientemente de cualquier entrega fuera de orden que pueda ocurrir. El transmisor elige el número de secuencia del primer byte para el primer paquete, que está marcado como SYN. Este número puede ser arbitrario y, de hecho, debería ser impredecible para defenderse de los ataques de predicción de secuencia TCP.

El receptor de datos envía acuses de recibo (ACK) con un número de secuencia para informar al remitente que se han recibido datos en el byte especificado. Los ACK no implican que los datos hayan sido entregados a la aplicación, simplemente significan que ahora es responsabilidad del receptor entregar los datos.

La confiabilidad se logra cuando el remitente detecta los datos perdidos y los retransmite. TCP utiliza dos técnicas principales para identificar pérdidas. Tiempo de espera de retransmisión (RTO) y acuses de recibo acumulativos duplicados (DupAcks).

Retransmisión basada en Dupack

Si se pierde un solo segmento (por ejemplo, el número de segmento 100) en un flujo, el receptor no puede reconocer paquetes por encima de ese número de segmento (100) porque usa ACK acumulativos. Por tanto, el receptor vuelve a acusar recibo del paquete 99 al recibir otro paquete de datos. Este acuse de recibo duplicado se utiliza como señal de pérdida de paquetes. Es decir, si el remitente recibe tres reconocimientos duplicados, retransmite el último paquete no reconocido. Se utiliza un umbral de tres porque la red puede reordenar los segmentos provocando reconocimientos duplicados. Se ha demostrado que este umbral evita retransmisiones espurias debido a la reordenación. Algunas implementaciones de TCP utilizan reconocimientos selectivos (SACK) para proporcionar comentarios explícitos sobre los segmentos que se han recibido. Esto mejora enormemente la capacidad de TCP para retransmitir los segmentos correctos.

Retransmisión basada en tiempo de espera

Cuando un remitente transmite un segmento, inicializa un temporizador con una estimación conservadora del tiempo de llegada del reconocimiento. El segmento es retransmitido si el temporizador expira, con un nuevo umbral de tiempo fuera del doble del valor anterior, lo que resulta en comportamiento de retroceso exponencial. Típicamente, el valor inicial del temporizador es ${displaystyle {text{smoothed RTT}}+max(G,4times {text{RTT variation}}}}}}$, donde ${displaystyle G.$ es la granularidad del reloj. Esto protege contra el tráfico excesivo de transmisión debido a actores defectuosos o malintencionados, como la negación man-en-el-medio de los atacantes de servicio.

Detección de errores

Los números de secuencia permiten a los receptores descartar paquetes duplicados y secuenciar correctamente los paquetes desordenados. Los acuses de recibo permiten a los remitentes determinar cuándo retransmitir los paquetes perdidos.

Para garantizar la corrección, se incluye un campo de suma de comprobación; consulte § Cálculo de la suma de comprobación para obtener más detalles. La suma de verificación de TCP es una verificación débil según los estándares modernos y normalmente se combina con una verificación de integridad CRC en la capa 2, debajo de TCP e IP, como se usa en PPP o la trama de Ethernet. Sin embargo, la introducción de errores en paquetes entre saltos protegidos por CRC es común y la suma de comprobación TCP de 16 bits detecta la mayoría de ellos.

Control de flujo

TCP utiliza un protocolo de control de flujo de extremo a extremo para evitar que el remitente envíe datos demasiado rápido para que el receptor TCP los reciba y procese de manera confiable. Tener un mecanismo para el control de flujo es fundamental en un entorno donde se comunican máquinas de diversas velocidades de red. Por ejemplo, si una PC envía datos a un teléfono inteligente que procesa lentamente los datos recibidos, el teléfono inteligente debe poder regular el flujo de datos para no verse abrumado.

TCP utiliza un protocolo de control de flujo de ventana deslizante. En cada segmento TCP, el receptor especifica en el campo ventana de recepción la cantidad de datos recibidos adicionales (en bytes) que está dispuesto a almacenar en el búfer para la conexión. El host emisor puede enviar solo hasta esa cantidad de datos antes de que deba esperar un reconocimiento y recibir una actualización de la ventana del host receptor.

Los números de secuencia TCP y recibir ventanas se comportan mucho como un reloj. La ventana recibe turnos cada vez que el receptor recibe y reconoce un nuevo segmento de datos. Una vez que se agota de los números de secuencia, el número de secuencia se vuelve a 0.

Cuando un receptor anuncia un tamaño de ventana de 0, el remitente deja de enviar datos e inicia su temporizador persistente. El temporizador de persistencia se usa para proteger TCP de una situación de interbloqueo que podría surgir si se pierde una actualización posterior del tamaño de la ventana del receptor y el remitente no puede enviar más datos hasta que reciba una nueva actualización del tamaño de la ventana del receptor. Cuando el temporizador de persistencia expira, el remitente TCP intenta la recuperación enviando un paquete pequeño para que el receptor responda enviando otro reconocimiento que contiene el nuevo tamaño de ventana.

Si un receptor está procesando datos entrantes en pequeños incrementos, puede anunciar repetidamente una pequeña ventana de recepción. Esto se conoce como el síndrome de la ventana tonta, ya que es ineficaz enviar solo unos pocos bytes de datos en un segmento TCP, dada la sobrecarga relativamente grande del encabezado TCP.

Control de congestión

El último aspecto principal de TCP es el control de la congestión. TCP utiliza una serie de mecanismos para lograr un alto rendimiento y evitar el colapso congestivo, una situación de estancamiento en la que el rendimiento de la red se degrada gravemente. Estos mecanismos controlan la tasa de datos que ingresan a la red, manteniendo el flujo de datos por debajo de una tasa que desencadenaría el colapso. También producen una asignación justa aproximadamente máximo-mínimo entre flujos.

Los remitentes utilizan los acuses de recibo de los datos enviados, o la falta de acuses de recibo, para inferir las condiciones de la red entre el remitente TCP y el receptor. Junto con los temporizadores, los emisores y receptores de TCP pueden alterar el comportamiento del flujo de datos. Esto se conoce más generalmente como control de congestión o prevención de congestión.

Las implementaciones modernas de TCP contienen cuatro algoritmos entrelazados: inicio lento, evitación de congestión, retransmisión rápida y recuperación rápida.

Además, los remitentes emplean un tiempo de espera de retransmisión (RTO) que se basa en el tiempo estimado de ida y vuelta (RTT) entre el remitente y el receptor, así como la variación en este tiempo de ida y vuelta. hora. Hay sutilezas en la estimación de RTT. Por ejemplo, los remitentes deben tener cuidado al calcular muestras RTT para paquetes retransmitidos; por lo general, utilizan el algoritmo de Karn o las marcas de tiempo de TCP. Estas muestras individuales de RTT luego se promedian a lo largo del tiempo para crear un tiempo de ida y vuelta suavizado (SRTT) utilizando el algoritmo de Jacobson. Este valor SRTT es lo que se utiliza como estimación del tiempo de ida y vuelta.

Mejorar TCP para manejar pérdidas de manera confiable, minimizar errores, administrar la congestión e ir rápido en entornos de muy alta velocidad son áreas de investigación y desarrollo de estándares en curso. Como resultado, hay una serie de variaciones del algoritmo para evitar la congestión de TCP.

Tamaño máximo de segmento

El tamaño máximo de segmento (MSS) es la mayor cantidad de datos, especificados en bytes, que TCP está dispuesto a recibir en un solo segmento. Para obtener el mejor rendimiento, el MSS debe configurarse lo suficientemente pequeño para evitar la fragmentación de IP, lo que puede provocar la pérdida de paquetes y retransmisiones excesivas. Para lograr esto, normalmente cada lado anuncia el MSS mediante la opción MSS cuando se establece la conexión TCP. El valor de la opción se deriva del tamaño de la unidad de transmisión máxima (MTU) de la capa de enlace de datos de las redes a las que están conectados directamente el remitente y el receptor. Los remitentes de TCP pueden usar el descubrimiento de MTU de ruta para inferir la MTU mínima a lo largo de la ruta de red entre el remitente y el receptor, y usar esto para ajustar dinámicamente el MSS para evitar la fragmentación de IP dentro de la red.

El anuncio de MSS también puede llamarse negociación de MSS pero, estrictamente hablando, el MSS no se negocia. Se permiten dos valores de MSS completamente independientes para las dos direcciones de flujo de datos en una conexión TCP, por lo que no es necesario acordar una configuración de MSS común para una conexión bidireccional.

Agradecimientos selectivos

Confiar exclusivamente en el esquema de reconocimiento acumulativo empleado por el TCP original puede generar ineficiencias cuando se pierden paquetes. Por ejemplo, suponga que los bytes con el número de secuencia 1000 a 10 999 se envían en 10 segmentos TCP diferentes del mismo tamaño, y el segundo segmento (números de secuencia 2000 a 2999) se pierde durante la transmisión. En un protocolo de acuse de recibo acumulativo puro, el receptor solo puede enviar un valor ACK acumulativo de 2000 (el número de secuencia que sigue inmediatamente al último número de secuencia de los datos recibidos) y no puede decir que recibió correctamente los bytes 3000 a 10 999. Por lo tanto, es posible que el remitente tenga que volver a enviar todos los datos que comiencen con el número de secuencia 2000.

Para paliar este problema, TCP emplea la opción de reconocimiento selectivo (SACK), definida en 1996 en RFC 2018, que permite al receptor reconocer bloques discontinuos de paquetes que se recibieron correctamente, además de la número de secuencia que sigue inmediatamente al último número de secuencia del último byte contiguo recibido sucesivamente, como en el acuse de recibo TCP básico. El acuse de recibo puede incluir varios bloques SACK, donde cada bloque SACK se transmite por el borde izquierdo del bloque (el primer número de secuencia del bloque) y el Borde derecho del bloque (el número de secuencia que sigue inmediatamente al último número de secuencia del bloque), siendo un Bloque un rango contiguo que el receptor recibió correctamente. En el ejemplo anterior, el receptor enviaría un segmento ACK con un valor ACK acumulativo de 2000 y un encabezado de opción SACK con números de secuencia 3000 y 11 000. En consecuencia, el remitente retransmitiría solo el segundo segmento con los números de secuencia 2000 a 2999.

Un remitente TCP puede interpretar la entrega de un segmento fuera de servicio como un segmento perdido. Si lo hace, el remitente TCP retransmitirá el segmento anterior al paquete fuera de servicio y reducirá la velocidad de entrega de datos para esa conexión. La opción duplicate-SACK, una extensión de la opción SACK que se definió en mayo de 2000 en RFC 2883, resuelve este problema. El receptor TCP envía un D-ACK para indicar que no se perdieron segmentos y el remitente TCP puede restablecer la velocidad de transmisión más alta.

La opción SACK no es obligatoria y entra en funcionamiento solo si ambas partes la apoyan. Esto se negocia cuando se establece una conexión. SACK usa una opción de encabezado TCP (ver § estructura de segmento TCP para más detalles). El uso de SACK se ha generalizado: todas las pilas TCP populares lo admiten. El reconocimiento selectivo también se utiliza en el Protocolo de transmisión de control de flujo (SCTP).

Escalado de ventana

Para un uso más eficiente de las redes de gran ancho de banda, se puede utilizar un tamaño de ventana de TCP más grande. Un campo de tamaño de ventana TCP de 16 bits controla el flujo de datos y su valor está limitado a 65.535 bytes. Dado que el campo de tamaño no se puede expandir más allá de este límite, se utiliza un factor de escala. La opción de escala de ventana TCP, tal como se define en RFC 1323, es una opción que se utiliza para aumentar el tamaño máximo de la ventana a 1 gigabyte. Es necesario escalar a estos tamaños de ventana más grandes para el ajuste de TCP.

La opción de escala de ventana se usa solo durante el protocolo de enlace de 3 vías de TCP. El valor de escala de ventana representa el número de bits para desplazar a la izquierda el campo de tamaño de ventana de 16 bits al interpretarlo. El valor de la escala de la ventana se puede configurar de 0 (sin cambio) a 14 para cada dirección de forma independiente. Ambos lados deben enviar la opción en sus segmentos SYN para habilitar la escala de ventana en cualquier dirección.

Algunos enrutadores y cortafuegos de paquetes reescriben el factor de escala de la ventana durante una transmisión. Esto hace que los lados de envío y recepción asuman diferentes tamaños de ventana de TCP. El resultado es un tráfico no estable que puede ser muy lento. El problema es visible en algunos sitios detrás de un enrutador defectuoso.

Marcas de tiempo de TCP

Las marcas de tiempo de TCP, definidas en RFC 1323 en 1992, pueden ayudar a TCP a determinar en qué orden se enviaron los paquetes. Las marcas de tiempo de TCP normalmente no están alineadas con el reloj del sistema y comienzan en algún valor aleatorio. Muchos sistemas operativos incrementarán la marca de tiempo por cada milisegundo transcurrido; sin embargo, el RFC solo establece que los ticks deben ser proporcionales.

Hay dos campos de marca de tiempo:

• un valor de temporizador de 4 bytes (mi timetamp)
• a 4-byte eco réplica temporal valor (el más reciente de los tiempos recibido de usted).

Las marcas de tiempo de TCP se utilizan en un algoritmo conocido como Protección contra números de secuencia envueltos, o PAWS. PAWS se utiliza cuando la ventana de recepción cruza el límite de ajuste del número de secuencia. En el caso de que un paquete se retransmitiera potencialmente, responde a la pregunta: "¿Este número de secuencia está en los primeros 4 GB o en los segundos?" Y la marca de tiempo se usa para desempatar.

Además, el algoritmo de detección de Eifel utiliza marcas de tiempo de TCP para determinar si se están produciendo retransmisiones porque los paquetes se han perdido o simplemente están fuera de servicio.

Las marcas de tiempo de TCP están habilitadas de manera predeterminada en Linux y deshabilitadas de manera predeterminada en Windows Server 2008, 2012 y 2016.

Estadísticas recientes muestran que el nivel de adopción de marcas de tiempo de TCP se ha estancado, en aproximadamente un 40 %, debido a que Windows Server dejó de admitir desde Windows Server 2008.

Datos fuera de banda

Es posible interrumpir o anular la transmisión en cola en lugar de esperar a que finalice la transmisión. Esto se hace especificando los datos como urgentes. Esto marca la transmisión como datos fuera de banda (OOB) y le dice al programa receptor que la procese inmediatamente. Cuando finaliza, TCP informa a la aplicación y reanuda la cola de transmisión. Un ejemplo es cuando se usa TCP para una sesión de inicio de sesión remota donde el usuario puede enviar una secuencia de teclado que interrumpe o aborta el programa que se ejecuta de forma remota sin esperar a que el programa termine su transferencia actual.

El puntero urgente solo altera el procesamiento en el host remoto y no acelera ningún procesamiento en la propia red. La capacidad se implementa de manera diferente o deficiente en diferentes sistemas o puede no ser compatible. Cuando esté disponible, es prudente suponer que solo se manejarán de manera confiable bytes individuales de datos OOB. Dado que la función no se usa con frecuencia, no se ha probado bien en algunas plataformas y se ha asociado con vulnerabilidades, por ejemplo, WinNuke.

Forzar la entrega de datos

Normalmente, TCP espera 200 ms para enviar un paquete completo de datos (el algoritmo de Nagle intenta agrupar mensajes pequeños en un solo paquete). Esta espera crea retrasos pequeños, pero potencialmente graves, si se repite constantemente durante una transferencia de archivos. Por ejemplo, un bloque de envío típico sería de 4 KB, un MSS típico es 1460, por lo que salen 2 paquetes en una Ethernet de 10 Mbit/s que tardan ~1,2 ms cada uno, seguidos de un tercero que transporta los 1176 restantes después de una pausa de 197 ms porque TCP está esperando un búfer completo. En el caso de telnet, el servidor repite cada pulsación de tecla del usuario antes de que el usuario pueda verla en la pantalla. Este retraso se volvería muy molesto.

Configurar la opción de socket TCP_NODELAY anula el retraso de envío predeterminado de 200 ms. Los programas de aplicación utilizan esta opción de socket para forzar el envío de la salida después de escribir un carácter o una línea de caracteres.

El RFC define el bit de inserción PSH como "un mensaje a la pila TCP receptora para enviar estos datos inmediatamente a la aplicación receptora". No hay forma de indicarlo o controlarlo en el espacio del usuario utilizando los sockets de Berkeley; está controlado únicamente por la pila de protocolos.

Vulnerabilidades

TCP puede ser atacado de varias formas. Los resultados de una evaluación exhaustiva de la seguridad de TCP, junto con las posibles mitigaciones de los problemas identificados, se publicaron en 2009 y actualmente se están investigando en el IETF.

Denegación de servicio

Al usar una dirección IP falsificada y enviar repetidamente paquetes SYN ensamblados a propósito, seguidos de muchos paquetes ACK, los atacantes pueden hacer que el servidor consuma grandes cantidades de recursos al realizar un seguimiento de las conexiones falsas. Esto se conoce como ataque de inundación SYN. Las soluciones propuestas para este problema incluyen cookies SYN y acertijos criptográficos, aunque las cookies SYN vienen con su propio conjunto de vulnerabilidades. Sockstress es un ataque similar, que podría mitigarse con la gestión de recursos del sistema. En Phrack #66 se analizó un ataque DoS avanzado que implicaba la explotación de TCP Persist Timer. Las inundaciones PUSH y ACK son otras variantes.

Secuestro de conexión

Un atacante que pueda espiar una sesión TCP y redirigir paquetes puede secuestrar una conexión TCP. Para hacerlo, el atacante aprende el número de secuencia de la comunicación en curso y falsifica un segmento falso que se parece al siguiente segmento de la transmisión. Un secuestro tan simple puede resultar en que un paquete sea aceptado erróneamente en un extremo. Cuando el host receptor reconoce el segmento adicional al otro lado de la conexión, se pierde la sincronización. El secuestro puede combinarse con el Protocolo de resolución de direcciones (ARP) o ataques de enrutamiento que permiten tomar el control del flujo de paquetes, para obtener un control permanente de la conexión TCP secuestrada.

Suplantar una dirección IP diferente no era difícil antes de RFC 1948, cuando el número de secuencia inicial era fácil de adivinar. Eso permitió a un atacante enviar a ciegas una secuencia de paquetes que el receptor creería que provienen de una dirección IP diferente, sin la necesidad de implementar ARP o ataques de enrutamiento: es suficiente para garantizar que el host legítimo de la dirección IP suplantada esté caído., o llevarlo a esa condición mediante ataques de denegación de servicio. Esta es la razón por la cual el número de secuencia inicial ahora se elige al azar.

Veto TCP

Un atacante que pueda espiar y predecir el tamaño del siguiente paquete que se enviará puede hacer que el receptor acepte una carga maliciosa sin interrumpir la conexión existente. El atacante inyecta un paquete malicioso con el número de secuencia y el tamaño de la carga útil del siguiente paquete esperado. Cuando finalmente se recibe el paquete legítimo, se encuentra que tiene el mismo número de secuencia y la misma longitud que un paquete ya recibido y se descarta silenciosamente como un paquete duplicado normal: el paquete legítimo es "vetado" por el paquete malicioso. A diferencia del secuestro de la conexión, la conexión nunca se desincroniza y la comunicación continúa con normalidad después de que se acepta la carga útil maliciosa. El veto de TCP le da al atacante menos control sobre la comunicación, pero hace que el ataque sea particularmente resistente a la detección. Se evita el gran aumento en el tráfico de red de la tormenta ACK. La única evidencia para el receptor de que algo anda mal es un solo paquete duplicado, algo normal en una red IP. El remitente del paquete vetado nunca ve ninguna evidencia de un ataque.

Otra vulnerabilidad es el ataque de restablecimiento de TCP.

Puertos TCP

TCP y UDP utilizan números de puerto para identificar los puntos finales de las aplicaciones de envío y recepción en un host, a menudo denominados conexiones de Internet. Cada lado de una conexión TCP tiene un número de puerto sin firmar de 16 bits asociado (0-65535) reservado por la aplicación de envío o recepción. Los paquetes TCP que llegan se identifican como pertenecientes a una conexión TCP específica por sus sockets, es decir, la combinación de la dirección del host de origen, el puerto de origen, la dirección del host de destino y el puerto de destino. Esto significa que una computadora servidor puede proporcionar a varios clientes varios servicios simultáneamente, siempre que un cliente se encargue de iniciar cualquier conexión simultánea a un puerto de destino desde diferentes puertos de origen.

Los números de puerto se clasifican en tres categorías básicas: conocidos, registrados y dinámicos/privados. Los puertos conocidos son asignados por la Autoridad de Números Asignados de Internet (IANA) y, por lo general, los utilizan los procesos raíz o de nivel del sistema. Las aplicaciones conocidas que se ejecutan como servidores y escuchan pasivamente las conexiones suelen utilizar estos puertos. Algunos ejemplos incluyen: FTP (20 y 21), SSH (22), TELNET (23), SMTP (25), HTTP sobre SSL/TLS (443) y HTTP (80). Tenga en cuenta que, a partir del último estándar, HTTP/3, QUIC se utiliza como transporte en lugar de TCP. Los puertos registrados suelen ser utilizados por las aplicaciones de los usuarios finales como puertos de origen efímeros cuando se comunican con los servidores, pero también pueden identificar servicios con nombre que han sido registrados por un tercero. Los puertos dinámicos/privados también pueden ser utilizados por aplicaciones de usuarios finales, pero son menos comunes. Los puertos dinámicos/privados no contienen ningún significado fuera de una conexión TCP en particular.

La traducción de direcciones de red (NAT), por lo general, utiliza números de puerto dinámicos, en el lado público ("orientado a Internet"), para eliminar la ambigüedad del flujo de tráfico que pasa entre una red pública y una subred privada., lo que permite que muchas direcciones IP (y sus puertos) en la subred sean atendidas por una sola dirección pública.

Desarrollo

TCP es un protocolo complejo. Sin embargo, aunque se han realizado y propuesto mejoras significativas a lo largo de los años, su funcionamiento más básico no ha cambiado significativamente desde su primera especificación RFC 675 en 1974 y la especificación v4 RFC 793, publicada en septiembre de 1981. RFC 1122, Requisitos de host para Internet Hosts, aclaró una serie de requisitos de implementación del protocolo TCP. En el RFC 7414 se encuentra disponible una lista de las 8 especificaciones requeridas y más de 20 mejoras recomendadas. Entre esta lista se encuentra el RFC 2581, Control de congestión de TCP, uno de los RFC más importantes relacionados con TCP en los últimos años, describe algoritmos actualizados que evitan la congestión indebida.. En 2001, se escribió RFC 3168 para describir la Notificación de congestión explícita (ECN), un mecanismo de señalización para evitar la congestión.

El algoritmo original para evitar la congestión de TCP se conocía como "TCP Tahoe", pero desde entonces se han propuesto muchos algoritmos alternativos (incluidos TCP Reno, TCP Vegas, FAST TCP, TCP New Reno y TCP Hybla).

TCP Interactive (iTCP) es un esfuerzo de investigación sobre extensiones TCP que permite que las aplicaciones se suscriban a eventos TCP y registren componentes de controlador que pueden iniciar aplicaciones para varios propósitos, incluido el control de congestión asistido por aplicaciones.

Multipath TCP (MPTCP) es un esfuerzo continuo dentro del IETF que tiene como objetivo permitir que una conexión TCP use múltiples rutas para maximizar el uso de recursos y aumentar la redundancia. La redundancia que ofrece Multipath TCP en el contexto de las redes inalámbricas permite la utilización simultánea de diferentes redes, lo que brinda un mayor rendimiento y mejores capacidades de traspaso. Multipath TCP también brinda beneficios de rendimiento en entornos de centros de datos. La implementación de referencia de Multipath TCP se está desarrollando en el kernel de Linux. Multipath TCP se utiliza para admitir la aplicación de reconocimiento de voz Siri en iPhones, iPads y Macs

tcpcrypt es una extensión propuesta en julio de 2010 para proporcionar cifrado de nivel de transporte directamente en el mismo TCP. Está diseñado para funcionar de forma transparente y no requiere ninguna configuración. A diferencia de TLS (SSL), tcpcrypt en sí mismo no proporciona autenticación, pero proporciona primitivas simples hasta la aplicación para hacerlo. A partir de 2010, se publicó el primer borrador de tcpcrypt IETF y existen implementaciones para varias plataformas importantes.

TCP Fast Open es una extensión para acelerar la apertura de conexiones TCP sucesivas entre dos puntos finales. Funciona omitiendo el protocolo de enlace de tres vías mediante una 'cookie' criptográfica. Es similar a una propuesta anterior llamada T/TCP, que no fue ampliamente adoptada debido a problemas de seguridad. TCP Fast Open se publicó como RFC 7413 en 2014.

Propuesta en mayo de 2013, la reducción de tasa proporcional (PRR) es una extensión de TCP desarrollada por ingenieros de Google. PRR garantiza que el tamaño de la ventana de TCP después de la recuperación esté lo más cerca posible del umbral de inicio lento. El algoritmo está diseñado para mejorar la velocidad de recuperación y es el algoritmo de control de congestión predeterminado en los kernels de Linux 3.2+.

Propuestas obsoletas

TCP Cookie Transactions (TCPCT) es una extensión propuesta en diciembre de 2009 para proteger los servidores contra ataques de denegación de servicio. A diferencia de las cookies SYN, TCPCT no entra en conflicto con otras extensiones de TCP, como el escalado de ventanas. TCPCT fue diseñado debido a las necesidades de DNSSEC, donde los servidores tienen que manejar una gran cantidad de conexiones TCP de corta duración. En 2016, TCPCT quedó en desuso en favor de TCP Fast Open. El estado del RFC original se cambió a "histórico".

TCP sobre redes inalámbricas

TCP se diseñó originalmente para redes cableadas. Se considera que la pérdida de paquetes es el resultado de la congestión de la red y el tamaño de la ventana de congestión se reduce drásticamente como medida de precaución. Sin embargo, se sabe que los enlaces inalámbricos experimentan pérdidas esporádicas y generalmente temporales debido a desvanecimientos, sombras, traspasos, interferencias y otros efectos de radio que no son estrictamente congestión. Después del retroceso (erróneo) del tamaño de la ventana de congestión, debido a la pérdida de paquetes inalámbricos, puede haber una fase de evitación de la congestión con una disminución conservadora del tamaño de la ventana. Esto hace que el enlace de radio sea infrautilizado. Se ha llevado a cabo una amplia investigación para combatir estos efectos nocivos. Las soluciones sugeridas se pueden clasificar como soluciones integrales, que requieren modificaciones en el cliente o el servidor, soluciones de capa de enlace, como el Protocolo de enlace de radio (RLP) en redes celulares, o soluciones basadas en proxy que requieren algunos cambios en la red. sin modificar los nodos finales.

Se han propuesto varios algoritmos de control de congestión alternativos, como Vegas, Westwood, Veno y Santa Cruz, para ayudar a resolver el problema inalámbrico.

Implementaciones de hardware

Una forma de superar los requisitos de potencia de procesamiento de TCP es crear implementaciones de hardware del mismo, ampliamente conocidas como motores de descarga de TCP (TOE). El principal problema de los TOE es que son difíciles de integrar en los sistemas informáticos, lo que requiere cambios extensos en el sistema operativo de la computadora o dispositivo. Una empresa que desarrolló un dispositivo de este tipo fue Alacritech.

Imagen de alambre y osificación

La imagen cableada de TCP brinda importantes oportunidades de recopilación y modificación de información a los observadores en ruta, ya que los metadatos del protocolo se transmiten en texto no cifrado. Si bien esta transparencia es útil para los operadores de red y los investigadores, la información recopilada de los metadatos del protocolo puede reducir la privacidad del usuario final. Esta visibilidad y maleabilidad de los metadatos ha hecho que TCP sea difícil de extender, un caso de osificación del protocolo, ya que cualquier nodo intermedio (un 'middlebox') puede tomar decisiones basadas en esos metadatos o incluso modificarlos, rompiendo el principio de extremo a extremo. Una medición encontró que un tercio de las rutas a través de Internet encuentran al menos un intermediario que modifica los metadatos de TCP, y el 6,5% de las rutas encuentran efectos dañinos de osificación de los intermediarios. Evitar los peligros de extensibilidad de los intermediarios impuso restricciones significativas en el diseño de MPTCP, y las dificultades causadas por los intermediarios han obstaculizado la implementación de TCP Fast Open en los navegadores web. Otra fuente de osificación es la dificultad de modificar las funciones de TCP en los puntos finales, normalmente en el núcleo del sistema operativo o en el hardware con un motor de descarga de TCP.

Rendimiento

Como TCP brinda a las aplicaciones la abstracción de un flujo de bytes confiable, puede sufrir bloqueos de encabezado de línea: si los paquetes se reordenan o se pierden y deben retransmitirse (y, por lo tanto, llegan desordenados), los datos desde secuencialmente, las partes posteriores del flujo pueden recibirse antes que las partes secuencialmente anteriores del flujo; sin embargo, los datos posteriores normalmente no se pueden usar hasta que se hayan recibido los datos anteriores, lo que genera latencia en la red. Si varios mensajes independientes de alto nivel se encapsulan y multiplexan en una sola conexión TCP, entonces el bloqueo de encabezado de línea puede hacer que el procesamiento de un mensaje recibido en su totalidad que se envió más tarde espere la entrega de un mensaje que se envió antes.

Aceleración

La idea de un acelerador TCP es terminar las conexiones TCP dentro del procesador de red y luego transmitir los datos a una segunda conexión hacia el sistema final. Los paquetes de datos que se originan en el remitente se almacenan en el nodo acelerador, que es responsable de realizar retransmisiones locales en caso de pérdida de paquetes. Así, en caso de pérdidas, el bucle de retroalimentación entre el emisor y el receptor se acorta al que existe entre el nodo de aceleración y el receptor, lo que garantiza una entrega de datos más rápida al receptor.

Dado que TCP es un protocolo adaptable a la velocidad, la velocidad a la que el remitente TCP inyecta paquetes en la red es directamente proporcional a la condición de carga prevaleciente dentro de la red, así como la capacidad de procesamiento del receptor. Las condiciones prevalecientes dentro de la red son juzgadas por el remitente sobre la base de los acuses de recibo que recibe. El nodo de aceleración divide el bucle de retroalimentación entre el remitente y el receptor y, por lo tanto, garantiza un tiempo de ida y vuelta (RTT) más corto por paquete. Un RTT más corto es beneficioso ya que asegura un tiempo de respuesta más rápido a cualquier cambio en la red y una adaptación más rápida por parte del remitente para combatir estos cambios.

Las desventajas del método incluyen el hecho de que la sesión TCP tiene que ser dirigida a través del acelerador; esto significa que si el enrutamiento cambia y el acelerador ya no está en la ruta, la conexión se interrumpirá. También destruye la propiedad de extremo a extremo del mecanismo de acuse de recibo de TCP; cuando el remitente recibe el ACK, el paquete ha sido almacenado por el acelerador, no entregado al receptor.

Depuración

Un rastreador de paquetes, que intercepta el tráfico TCP en un enlace de red, puede ser útil para depurar redes, pilas de red y aplicaciones que usan TCP al mostrarle al usuario qué paquetes pasan a través de un enlace. Algunas pilas de redes admiten la opción de socket SO_DEBUG, que se puede habilitar en el socket mediante setsockopt. Esa opción vuelca todos los paquetes, estados TCP y eventos en ese socket, lo que es útil para la depuración. Netstat es otra utilidad que se puede utilizar para la depuración.

Alternativas

Para muchas aplicaciones, TCP no es apropiado. Un problema (al menos con las implementaciones normales) es que la aplicación no puede acceder a los paquetes que vienen después de un paquete perdido hasta que se recibe la copia retransmitida del paquete perdido. Esto causa problemas para las aplicaciones en tiempo real, como transmisión de medios, juegos multijugador en tiempo real y voz sobre IP (VoIP), donde generalmente es más útil obtener la mayoría de los datos de manera oportuna que obtener todos los datos. en orden.

Por razones históricas y de rendimiento, la mayoría de las redes de área de almacenamiento (SAN) utilizan el Protocolo de canal de fibra (FCP) sobre conexiones de Canal de fibra.

Además, para sistemas integrados, arranque de red y servidores que atienden solicitudes simples de una gran cantidad de clientes (por ejemplo, servidores DNS), la complejidad de TCP puede ser un problema. Finalmente, algunos trucos como la transmisión de datos entre dos hosts que están detrás de NAT (usando STUN o sistemas similares) son mucho más simples sin un protocolo relativamente complejo como TCP en el camino.

Por lo general, cuando TCP no es adecuado, se utiliza el Protocolo de datagramas de usuario (UDP). Esto proporciona la multiplexación de la aplicación y las sumas de verificación que hace TCP, pero no maneja los flujos ni la retransmisión, lo que brinda al desarrollador de la aplicación la capacidad de codificarlos de una manera adecuada para la situación, o reemplazarlos con otros métodos como la corrección de errores hacia adelante o la interpolación.

El Protocolo de transmisión de control de flujo (SCTP) es otro protocolo que proporciona servicios confiables orientados al flujo similares a TCP. Es más nuevo y considerablemente más complejo que TCP, y aún no ha visto un despliegue generalizado. Sin embargo, está especialmente diseñado para usarse en situaciones donde la confiabilidad y las consideraciones de tiempo casi real son importantes.

El Protocolo de transporte Venturi (VTP) es un protocolo propietario patentado que está diseñado para reemplazar TCP de manera transparente para superar las ineficiencias percibidas relacionadas con el transporte inalámbrico de datos.

TCP también tiene problemas en entornos de gran ancho de banda. El algoritmo para evitar la congestión de TCP funciona muy bien para entornos ad-hoc donde el remitente de los datos no se conoce de antemano. Si el entorno es predecible, un protocolo basado en tiempo como el modo de transferencia asíncrono (ATM) puede evitar la sobrecarga de retransmisiones de TCP.

El protocolo de transferencia de datos (UDT) basado en UDP tiene una mayor eficiencia y equidad que TCP en redes que tienen un producto de retraso de ancho de banda alto.

El protocolo de transacción multipropósito (MTP/IP) es un software propietario patentado que está diseñado para lograr de manera adaptativa un alto rendimiento y rendimiento de transacciones en una amplia variedad de condiciones de red, particularmente aquellas en las que TCP se percibe como ineficiente.

Cálculo de la suma de comprobación

Suma de comprobación de TCP para IPv4

Cuando TCP se ejecuta sobre IPv4, el método utilizado para calcular la suma de comprobación se define de la siguiente manera:

El campo de checksum es el complemento de 16 bits de la suma completa de las palabras de 16 bits en el encabezado y el texto. La computación de la suma de comprobación debe garantizar la alineación de 16 bits de los datos que se resumen. Si un segmento contiene un número impar de auriculares y octets de texto, la alineación se puede lograr mediante la colocación del último octeto con ceros en su derecho a formar una palabra de 16 bits para fines de la suma de comprobación. El pad no se transmite como parte del segmento. Mientras computa la suma de comprobación, el campo de la suma de comprobación en sí es reemplazado por ceros.

En otras palabras, después del relleno adecuado, todas las palabras de 16 bits se agregan utilizando la aritmética de complemento a uno. A continuación, la suma se complementa bit a bit y se inserta como el campo de suma de comprobación. En la siguiente tabla se muestra un pseudoencabezado que imita el encabezado del paquete IPv4 utilizado en el cálculo de la suma de comprobación.

Las direcciones de origen y destino son las del encabezado IPv4. El valor del protocolo es 6 para TCP (ver Lista de números de protocolo IP). El campo de longitud TCP es la longitud del encabezado TCP y los datos (medidos en octetos).

Suma de comprobación de TCP para IPv6

Cuando TCP se ejecuta sobre IPv6, el método utilizado para calcular la suma de comprobación cambia:

Cualquier protocolo de transporte u otro protocolo de capa superior que incluya las direcciones del encabezado IP en su computación de suma de comprobación debe ser modificado para su uso sobre IPv6, para incluir las direcciones IPv6 de 128 bits en lugar de direcciones IPv4 de 32 bits.

A continuación, se muestra un pseudoencabezado que imita el encabezado de IPv6 para el cálculo de la suma de comprobación.

• Dirección de origen: la del encabezado IPv6
• Dirección de destino: el destino final; si el paquete IPv6 no contiene un encabezado Routing, TCP utiliza la dirección de destino en el encabezado IPv6, de lo contrario, en el nodo originario, utiliza la dirección en el último elemento del encabezado Routing, y, en el nodo receptor, utiliza la dirección de destino en el encabezado IPv6.
• Longitud TCP: la longitud del encabezado TCP y los datos
• Next Header: el valor de protocolo para TCP

Descarga de suma de comprobación

Muchas implementaciones de paquetes de software TCP/IP brindan opciones para utilizar la asistencia de hardware para calcular automáticamente la suma de verificación en el adaptador de red antes de la transmisión a la red o al recibirla desde la red para su validación. Esto puede evitar que el sistema operativo use valiosos ciclos de CPU para calcular la suma de verificación. Por lo tanto, se incrementa el rendimiento general de la red.

Esta característica puede hacer que los analizadores de paquetes que no conocen o no están seguros del uso de la descarga de suma de comprobación informen sumas de comprobación no válidas en paquetes salientes que aún no han llegado al adaptador de red. Esto solo ocurrirá para los paquetes que son interceptados antes de ser transmitidos por el adaptador de red; todos los paquetes transmitidos por el adaptador de red en el cable tendrán sumas de verificación válidas. Este problema también puede ocurrir al monitorear paquetes que se transmiten entre máquinas virtuales en el mismo host, donde un controlador de dispositivo virtual puede omitir el cálculo de la suma de verificación (como una optimización), sabiendo que la suma de verificación será calculada más tarde por el kernel del host de VM o su físico. hardware.

Documentos RFC

• RFC 675 – Especificación del Programa de Control de Transmisiones de Internet, Versión de diciembre de 1974
• RFC 793 – TCP v4
• RFC 1122 – incluye algunas correcciones de errores para TCP
• RFC 1323 – Extensiones TCP para alto rendimiento [Obsoleted by RFC 7323]
• RFC 1379 – Extender TCP para las transacciones – Conceptos [Obsoleto por RFC 6247]
• RFC 1948 – Defending Against Sequence Number Attacks
• RFC 2018 – Opciones de reconocimiento selectivo TCP
• RFC 5681 – Control de Congestión TCP
• RFC 6247 – Moving the Undeployed TCP Extensions RFC 1072, 1106, 1110, 1145, 1146, 1379, 1644 y 1693 to Historic Status
• RFC 6298 – Computing TCP Retransmission Timer
• RFC 6824 – TCP Extensiones para la operación multipática con múltiples direcciones
• RFC 7323 – TCP Prórrogas para un alto rendimiento
• RFC 7414 – Una hoja de ruta para documentos de especificación TCP
• RFC 9293 – Protocolo de Control de Transmisiones (TCP)