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 , que proporciona una entrega fiable , ordenada y con comprobació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. Su origen se remonta a la implementación inicial de la red, donde complementaba el Protocolo de Internet (IP). Por lo tanto, todo el conjunto se conoce comúnmente como TCP/IP .

Las principales aplicaciones de internet, como la World Wide Web , el correo electrónico, la administración remota , la transferencia de archivos y la transmisión de contenido multimedia , dependen de TCP, que forma parte de la capa de transporte del conjunto de protocolos TCP/IP. SSL/TLS suele funcionar sobre TCP. Hoy en día, TCP sigue siendo un protocolo fundamental para la mayoría de las comunicaciones en internet, garantizando una transferencia de datos fiable a través de diversas redes. ^{[ 1 ]}

TCP está orientado a la conexión , lo que significa que el emisor y el receptor primero deben establecer una conexión basada en parámetros acordados; lo hacen a través de un procedimiento de intercambio de tres vías . ^{[ 2 ]} El servidor debe estar escuchando (abierto pasivo) las solicitudes de conexión de los clientes antes de que se establezca una conexión. El intercambio de tres vías (abierto activo), la retransmisión y la detección de errores aumentan la confiabilidad pero alargan la latencia . Las aplicaciones que no requieren un servicio de flujo de datos confiable pueden usar el Protocolo de Datagramas de Usuario (UDP) en su lugar, 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, incluyendo la denegación de servicio , el secuestro de conexión , el veto TCP y el ataque de reinicio .

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 nodos de red. ^{[ 3 ]} Los autores habían estado trabajando con Gérard Le Lann para incorporar conceptos del proyecto francés CYCLADES a la nueva red. ^{[ 4 ]} 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. ^{[ 5 ]} Contiene el primer uso documentado del término internet , como abreviatura de interconexión de redes .

El Programa de Control de Transmisión incorporó enlaces orientados a la conexión y servicios de datagramas entre hosts. En la versión 4, el monolítico Programa de Control de Transmisión se dividió en una arquitectura modular que consta del Protocolo de Control de Transmisión y el Protocolo de Internet . ^{[ 6 ] [ 7 ]} Esto dio como resultado un modelo de red que se conoció informalmente como TCP/IP , aunque formalmente se le denominó de diversas maneras como modelo de arquitectura de Internet del Departamento de Defensa ( modelo DoD para abreviar) o modelo DARPA . ^{[ 8 ] [ 9 ] [ 10 ]} Posteriormente, pasó a formar parte del conjunto de protocolos de Internet y se convirtió en sinónimo de este. TCP continúa evolucionando, con actualizaciones incrementales y mejores prácticas formalizadas en RFC como la RFC 9293 (2022). ^{[ 11 ]}

Los siguientes documentos de Internet Experiment Note (IEN) describen la evolución de TCP hasta su versión moderna: ^{[ 12 ]}

• Especificación IEN #5 del programa de control de transmisión de Internet TCP versión 2 (marzo de 1977)
• Especificación IEN #21 del programa de control de transmisión de interconexión de redes TCP versión 3 (enero de 1978)
• IEN #27 Propuesta para el formato de encabezado de TCP versión 3.1 (febrero de 1978)
• IEN #40 Protocolo de control de transmisión, borrador versión 4 (junio de 1978)
• IEN #44 Últimos formatos de encabezado (junio de 1978)
• Especificación IEN #55 del Protocolo de Control de Transmisión de Interconexión de Redes, Versión 4 (septiembre de 1978)
• IEN #81 Protocolo de control de transmisión, versión 4 (febrero de 1979)
• Protocolo de control de transmisión IEN n.° 112 (agosto de 1979)
• IEN #124 PROTOCOLO ESTÁNDAR DE CONTROL DE TRANSMISIÓN DEL DOD (diciembre de 1979)

El protocolo TCP se estandarizó en enero de 1980 como RFC 761.

En 2004, Vint Cerf y Bob Kahn recibieron el Premio Turing por su trabajo fundamental sobre TCP/IP. ^{[ 13 ] [ 14 ]}

El Protocolo de Control de Transmisión (TCP) proporciona un servicio de comunicación en un nivel intermedio entre un programa de aplicación y el Protocolo de Internet (IP). Ofrece conectividad entre hosts en la capa de transporte del modelo de Internet . Una aplicación no necesita conocer los mecanismos específicos para enviar datos a través de un enlace a otro host, como la fragmentación IP necesaria para adaptarse a la unidad de transmisión máxima del medio. En la capa de transporte, TCP gestiona todos los detalles de la comunicación y la 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 inferiores de la pila de protocolos, debido a la congestión de la red , el equilibrio de carga del tráfico o el comportamiento impredecible de la red, los paquetes IP pueden perderse , duplicarse o entregarse fuera de orden . TCP detecta estos problemas, solicita la retransmisión de los datos perdidos, reorganiza los datos fuera de orden e incluso ayuda a minimizar la congestión de la red para reducir la aparición de otros problemas. Si los datos siguen sin entregarse, se notifica al origen de este fallo. Una vez que el receptor TCP ha reconstruido la secuencia de octetos transmitidos originalmente, los pasa a la aplicación receptora. De este modo, TCP abstrae la comunicación de la aplicación de los detalles subyacentes de la red.

TCP está optimizado para la entrega precisa en lugar de la entrega puntual y puede generar retrasos relativamente largos (del orden de segundos) mientras espera mensajes fuera de orden o retransmisiones de mensajes perdidos. Por lo tanto, no es particularmente adecuado para aplicaciones en tiempo real como la voz sobre IP . Para tales aplicaciones, generalmente se recomiendan protocolos como el Protocolo de Transporte en Tiempo Real (RTP) que opera sobre el Protocolo de Datagramas de Usuario (UDP). ^{[ 15 ]}

TCP es un servicio confiable de entrega de flujo de bytes que garantiza que todos los bytes recibidos serán idénticos y estarán en el mismo orden que los enviados. Dado que la transferencia de paquetes en muchas redes no es confiable, TCP logra esto mediante una técnica conocida como acuse de recibo positivo con retransmisión . Esto requiere que el receptor responda con un mensaje de acuse de recibo al recibir los datos. El remitente mantiene un registro de cada paquete que envía y 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. ^{[ 15 ]}

Mientras que IP gestiona 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 la capa de Internet encapsula cada segmento TCP en un paquete IP añadiendo una cabecera que incluye (entre otros datos) la dirección IP de destino . Cuando el programa cliente en el ordenador de destino los recibe, el software TCP en la capa de transporte vuelve a ensamblar los segmentos y se asegura de que estén correctamente ordenados y sin errores mientras transmite el contenido del archivo a la aplicación receptora.

El Protocolo de Control de Transmisión (TCP) acepta datos de un flujo de datos, los divide en fragmentos y agrega una cabecera TCP, creando un segmento TCP. El segmento TCP se encapsula en un datagrama del Protocolo de Internet (IP) y se intercambia con los pares. ^{[ 16 ]}

El término paquete TCP aparece tanto en el 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 ^{[ 17 ]} a la PDU IP y trama a la PDU de la capa de enlace de datos :

Los procesos transmiten datos llamando al TCP y pasando búferes de datos como argumentos. El TCP empaqueta los datos de estos búferes en segmentos y llama al módulo de Internet [por ejemplo, IP] para transmitir cada segmento al TCP de destino. ^{[ 18 ]}

Un segmento TCP consta de una cabecera y una sección de datos . La cabecera contiene 10 campos obligatorios y un campo de extensión opcional ( Opciones , octetos del 20 al 56 en la tabla). La sección de datos sigue a la cabecera y contiene los datos de carga útil de la aplicación. ^{[ 19 ]} La longitud de la sección de datos no se especifica en la cabecera; se puede calcular restando la longitud combinada de la cabecera y la cabecera IP de la longitud total del datagrama IP especificada en la cabecera IP.

Puerto de origen : 16 bits

Identifica el puerto de envío.

Puerto de destino : 16 bits

Identifica el puerto receptor.

Número de secuencia : 32 bits

Tiene una doble función:

• Si el indicador SYN está activado (1), este es el número de secuencia inicial. El número de secuencia del primer byte de datos real y el número de confirmación en el ACK correspondiente son entonces este número de secuencia más 1.
• Si el indicador SYN no está establecido (0), entonces este es el número de secuencia acumulado del primer byte de datos de este segmento para la sesión actual.

Número de acuse de recibo : 32 bits

Si se activa el indicador ACK, el valor de este campo es el siguiente número de secuencia que espera el remitente del ACK. Esto confirma la recepción de todos los bytes anteriores (si los hay). ^{[ 21 ]} El primer ACK enviado por cada extremo confirma el número de secuencia inicial del otro extremo, pero no datos. ^{[ 22 ]}

Desplazamiento de datos  (DOffset) : 4 bits

Especifica el tamaño de la cabecera TCP en palabras de 32 bits . El tamaño mínimo de la cabecera es de 5 palabras y el máximo de 15, lo que da como resultado un tamaño mínimo de 20 bytes y un máximo de 60 bytes, permitiendo hasta 40 bytes de opciones en la cabecera. Este campo recibe su nombre del hecho de que también representa el desplazamiento desde el inicio del segmento TCP hasta los datos propiamente dichos.

Reservado  (Rsrvd) : 4 bits

Para uso futuro, deben establecerse en cero; los remitentes no deben configurarlos y los receptores deben ignorarlos si están configurados, en ausencia de especificaciones e implementación adicionales.

Desde 2003 hasta 2017, el último bit (bit 103 del encabezado) fue definido como el indicador NS (Nonce Sum) por el RFC experimental 3540 , ECN-nonce. ECN-nonce nunca se generalizó y el RFC pasó a tener estatus histórico. ^{[ 23 ]}

Un borrador de RFC ^{[ 24 ]} propone un nuevo uso para este bit. El bit ahora se utiliza para negociar el uso de Accurate ECN .

Banderas : 8 bits

Contiene 8 indicadores de 1 bit (bits de control) como se muestra a continuación. Al usar tcpdump , un indicador activado se indica con el carácter entre paréntesis.

CWR  (W) : 1 bit

El indicador de ventana de congestión reducida (CWR) es establecido por el host emisor para indicar que recibió un segmento TCP con el indicador ECE establecido y que respondió en el mecanismo de control de congestión. ^{[ 25 ] [ a ]}

ECE  (E) : 1 bit

ECN-Echo tiene una doble función, dependiendo del valor del indicador SYN. ​​Indica:

• Si el indicador SYN está activado (1), el par TCP es compatible con ECN . ^{[ 26 ]}
• Si el indicador SYN no está activado (0), se recibió un paquete con el indicador Congestion Experienced activado (ECN=11) en su encabezado IP durante la transmisión normal. ^{[ a ]} ​​Esto sirve como indicación de congestión de la red (o congestión inminente) para el remitente TCP. ^{[ 27 ]}

URG  (U) : 1 bit

Indica que el campo de puntero Urgente es significativo.

ACK  (.) : 1 bit

Indica que el campo de acuse de recibo es significativo. Todos los paquetes posteriores al paquete SYN inicial enviado por el cliente deben tener este indicador activado. ^{[ 28 ]}

PSH  (P) : 1 bit

Función Push. Solicita que se envíen los datos almacenados en búfer desde el extremo del remitente a la aplicación receptora en el extremo del receptor. ^{[ 19 ]}

RST  (R) : 1 bit

Restablecer la conexión

SYN  (S) : 1 bit

Sincronizar los números de secuencia. Solo el primer paquete enviado desde cada extremo debe tener este indicador activado. Algunos otros indicadores y campos cambian de significado según este indicador, y algunos solo son válidos cuando está activado, mientras que otros lo están cuando está desactivado.

FIN  (F) : 1 bit

Último paquete del remitente

Ventana : 16 bits

El tamaño de la ventana de recepción , que especifica el número de unidades de tamaño de ventana ^{[ b ]} que el remitente de este segmento está dispuesto a recibir actualmente. ^{[ c ]} (Véase §  Control de flujo y §  Escalado de ventana ).

Suma de verificación : 16 bits

El campo de suma de verificación de 16 bits se utiliza para comprobar errores en la cabecera TCP, la carga útil y una pseudocabecera IP. La pseudocabecera consta de la dirección IP de origen , la dirección IP de destino , el número de protocolo para el protocolo TCP (6) y la longitud de las cabeceras TCP y la carga útil (en bytes).

Puntero urgente : 16 bits

Si se activa el indicador URG, este campo de 16 bits es un desplazamiento con respecto al número de secuencia que indica el último byte de datos urgentes.

Opciones  (Opción TCP) : Longitud variable, hasta 40 bytes (320 bits) ;Options length (bytes) = (Data Offset − 5) × 4; equivalent bit formula per RFC 9293: (Data Offset − 5) × 32

La longitud de este campo viene determinada por el campo Desplazamiento de datos . El relleno del encabezado TCP se utiliza para asegurar que el encabezado TCP finalice y los datos comiencen en un límite de 32 bits. El relleno se compone de ceros. ^{[ 18 ]}

Las opciones tienen hasta tres campos: Tipo de opción (1 byte), Longitud de opción (1 byte) y Datos de opción (variable). El campo Tipo de opción indica el tipo de opción y es el único campo obligatorio. Dependiendo del valor de Tipo de opción, se pueden configurar los dos campos siguientes. Longitud de opción indica la longitud total de la opción, y Datos de opción contiene los datos asociados a la opción, si corresponde. Por ejemplo, un byte de Tipo de opción de 1 indica que se trata de una opción sin operación, utilizada únicamente para relleno, y no tiene campos de Longitud de opción ni de Datos de opción a continuación. Un byte de Tipo de opción de 0 marca el final de las opciones y también es de un solo byte. Un byte de Tipo de opción de 2 se utiliza para indicar la opción Tamaño máximo de segmento, y irá seguido de un byte de Longitud de opción que especifica la longitud del campo MSS. Longitud de opción es la longitud total del campo de opciones dado, incluidos los campos Tipo de opción y Longitud de opción. Así, mientras que el valor MSS normalmente se expresa 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 de opciones TCP.

Algunas opciones solo se pueden enviar cuando SYN está activado; se indican a continuación como ^[SYN]. El tipo de opción y las longitudes estándar se dan como (Tipo de opción, Longitud de opción).

Los valores restantes de Option-Kind son históricos, obsoletos, experimentales, aún no estandarizados o no asignados. La asignación de números de opción la mantiene la Autoridad de Números Asignados de Internet (IANA). ^{[ 33 ]}

Datos : Variable

La carga útil del paquete TCP

El protocolo TCP se divide en tres fases. El establecimiento de la conexión es un proceso de enlace en varios pasos que establece la conexión antes de la transferencia de datos . Una vez completada la transferencia de datos, la terminación de la conexión la cierra y libera todos los recursos asignados.

Una conexión TCP es gestionada por un sistema operativo a través de un recurso que representa el punto final local para las comunicaciones, el socket de Internet . Durante la vida útil de una conexión TCP, el punto final local experimenta una serie de cambios de estado : ^{[ 34 ]}

Establecimiento de conexión

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

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

Los pasos 1 y 2 establecen y confirman el número de secuencia en una dirección (cliente a servidor). Los pasos 2 y 3 establecen y confirman el número de secuencia en la otra dirección (servidor a cliente). Una vez completados estos pasos, tanto el cliente como el servidor han recibido confirmaciones y se establece una comunicación dúplex completa.

Terminación de la conexión

La fase de terminación de la conexión utiliza un protocolo de enlace de cuatro vías, donde cada extremo de la conexión finaliza de forma independiente. Cuando un extremo desea finalizar su parte de la conexión, transmite un paquete FIN, que el otro extremo confirma con un ACK. Por lo tanto, una finalización típica requiere un par de segmentos FIN y ACK de cada extremo TCP. Después de que el extremo que envió el primer FIN haya respondido con el ACK final, espera un tiempo de espera antes de cerrar definitivamente la conexión, durante el cual el puerto local no está disponible para nuevas conexiones; este estado permite al cliente TCP reenviar la confirmación 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 entra en el estado CERRADO y el puerto local vuelve a estar disponible para nuevas conexiones. ^{[ 35 ]}

También es posible terminar la conexión mediante un intercambio de tres vías, cuando el host A envía un FIN y el host B responde con un FIN y un ACK (combinando dos pasos en uno) y el host A responde con un ACK. ^{[ 36 ]}

Algunos sistemas operativos, como Linux ^{[ 37 ],} implementan una secuencia de cierre semidúplex. Si el host cierra activamente una conexión, mientras aún tiene datos entrantes sin leer, envía la señal RST (perdiendo los datos recibidos) en lugar de FIN. Esto garantiza que una aplicación TCP sepa que se ha producido una pérdida de datos . ^{[ 38 ]}

Una conexión puede estar en un estado semiabierto , en cuyo caso una de las partes ha terminado la conexión, pero la otra no. La parte que ha terminado ya no puede enviar datos a la conexión, pero la otra sí. La parte que termina debe seguir leyendo los datos hasta que la otra parte también termine. ^{[ 39 ] [ 40 ]}

Transferencia de datos

El Protocolo de Control de Transmisión (TCP) difiere en varias características clave en comparación con el Protocolo de Datagramas de Usuario (UDP) :

• Transferencia de datos ordenada: el host de destino reorganiza los segmentos según un número de secuencia ^{[ 15 ].}
• Retransmisión de paquetes perdidos: cualquier flujo acumulativo no reconocido se retransmite ^{[ 15 ].}
• Transferencia de datos sin errores: los paquetes corruptos se tratan como perdidos y se retransmiten ^{[ 16 ].}
• Control de flujo: limita la velocidad a la que un emisor transfiere datos para garantizar una entrega fiable. El receptor informa continuamente al emisor sobre la cantidad de datos que puede recibir. Cuando el búfer del host receptor se llena, la siguiente confirmación suspende la transferencia y permite que se procesen los datos que contiene. ^{[ 15 ]}
• Control de congestión: los paquetes perdidos (presumiblemente debido a la congestión) provocan una reducción en la tasa de entrega de datos ^{[ 15 ].}

Transmisión fiable

TCP utiliza un número de secuencia para identificar cada byte de datos. Este número de secuencia identifica el orden de los bytes enviados desde cada equipo, de modo que los datos puedan reconstruirse en orden, independientemente de cualquier entrega desordenada que pueda ocurrir. El transmisor elige el número de secuencia del primer byte para el primer paquete, que se marca como SYN. ​​Este número puede ser arbitrario y, de hecho, debería ser impredecible para protegerse contra ataques de predicción de secuencia TCP .

Los acuses de recibo (ACK) son enviados por el receptor de datos con un número de secuencia para informar al remitente que los datos se han recibido hasta el byte especificado. Los ACK no implican que los datos se hayan entregado a la aplicación; simplemente indican que ahora es responsabilidad del receptor entregarlos.

La fiabilidad se logra mediante la detección por parte del remitente de los datos perdidos y su retransmisión. TCP utiliza dos técnicas principales para identificar la pérdida: el tiempo de espera de retransmisión (RTO) y los acuses de recibo acumulativos duplicados (DupAcks).

Cuando se retransmite un segmento TCP, conserva el mismo número de secuencia que el intento de entrega original. Esta confusión entre la entrega y el orden lógico de los datos implica que, al recibirse una confirmación tras una retransmisión, el remitente no puede determinar si se está confirmando la transmisión original o la retransmisión, lo que se conoce como ambigüedad de retransmisión . ^{[ 41 ]} TCP presenta complejidad debido a la ambigüedad de retransmisión. ^{[ 42 ]}

retransmisión basada en ACK duplicado

Si se pierde un solo segmento (por ejemplo, el segmento número 100) en un flujo, el receptor no puede confirmar los paquetes posteriores a ese segmento (100) porque utiliza confirmaciones acumulativas. Por lo tanto, el receptor confirma el paquete 99 nuevamente al recibir otro paquete de datos. Esta confirmación duplicada se utiliza como señal de pérdida de paquetes. Es decir, si el emisor recibe tres confirmaciones duplicadas, retransmite el último paquete no confirmado. Se utiliza un umbral de tres porque la red puede reordenar los segmentos, lo que provoca confirmaciones duplicadas. Se ha demostrado que este umbral evita retransmisiones espurias debidas a la reordenación. ^{[ 43 ]} Algunas implementaciones de TCP utilizan confirmaciones selectivas (SACK) para proporcionar información explícita sobre los segmentos que se han recibido. Esto mejora considerablemente la capacidad de TCP para retransmitir los segmentos correctos.

La ambigüedad de retransmisión puede causar retransmisiones rápidas espurias y evitación de congestión si hay reordenamiento más allá del umbral de acuse de recibo duplicado. ^{[ 44 ]} En las últimas dos décadas se ha observado un mayor reordenamiento de paquetes en Internet ^{[ 45 ]} lo que llevó a las implementaciones de TCP, como la del kernel de Linux, a adoptar métodos heurísticos para escalar el umbral de acuse de recibo duplicado. ^{[ 46 ]} Recientemente, se han realizado esfuerzos para eliminar por completo las retransmisiones rápidas basadas en ACK duplicados y reemplazarlas por retransmisiones basadas en temporizadores. ^{[ 47 ]} (No confundir con el RTO clásico que se analiza más adelante). El algoritmo de detección de pérdida basado en el tiempo llamado Reconocimiento Reciente (RACK) ^{[ 48 ]} se ha adoptado como algoritmo predeterminado en Linux y Windows. ^{[ 49 ]}

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 acuse de recibo. El segmento se retransmite si el temporizador expira, con un nuevo umbral de tiempo de espera del doble del valor anterior, lo que resulta en un comportamiento de retroceso exponencial . Normalmente, el valor inicial del temporizador es RTT suavizado + max( G , 4 × variación de RTT) , donde G es la granularidad del reloj. ^{[ 50 ]} Esto protege contra el tráfico de transmisión excesivo debido a actores defectuosos o maliciosos, como los atacantes de denegación de servicio de intermediario .

Las estimaciones precisas de RTT son importantes para la recuperación de pérdidas, ya que permiten a un remitente asumir que un paquete no confirmado se ha perdido después de que transcurra un tiempo suficiente (es decir, determinar el tiempo RTO). ^{[ 51 ]} La ambigüedad de la retransmisión puede llevar a que la estimación de RTT de un remitente sea imprecisa. ^{[ 51 ]} En un entorno con RTT variables, pueden producirse tiempos de espera espurios: ^{[ 52 ]} si el RTT se subestima, entonces el RTO se activa y desencadena una retransmisión innecesaria y un inicio lento. Después de una retransmisión espuria, cuando llegan los acuses de recibo de las transmisiones originales, el remitente puede creer que están acusando recibo de la retransmisión y concluir, incorrectamente, que los segmentos enviados entre la transmisión original y la retransmisión se han perdido, causando más retransmisiones innecesarias hasta el punto en que el enlace realmente se congestiona; ^{[ 53 ] [ 54 ]} el acuse de recibo selectivo puede reducir este efecto. ^{[ 55 ]} RFC 6298 especifica que las implementaciones no deben usar segmentos retransmitidos al estimar el RTT. ^{[ 56 ]} El algoritmo de Karn asegura que se producirá una buena estimación del RTT —eventualmente— al esperar hasta que haya un acuse de recibo inequívoco antes de ajustar el RTO. ^{[ 57 ]} Sin embargo, después de retransmisiones espurias, puede pasar un tiempo significativo antes de que llegue dicho acuse de recibo inequívoco, lo que degrada el rendimiento en el intervalo. ^{[ 58 ]} Las marcas de tiempo TCP también resuelven el problema de la ambigüedad de la retransmisión al establecer el RTO, ^{[ 56 ]} aunque no necesariamente mejoran la estimación del RTT. ^{[ 59 ]}

Detección de errores

Los números de secuencia permiten a los receptores descartar paquetes duplicados y ordenar correctamente los paquetes que llegan fuera de orden. 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 la sección "  Cálculo de la suma de comprobación" para obtener más detalles. La suma de comprobación TCP es una comprobación débil según los estándares modernos y normalmente se combina con una comprobación de integridad CRC en la capa 2 , por debajo de TCP e IP, como la que se utiliza en PPP o en la trama Ethernet . Sin embargo, es común la introducción de errores en los paquetes entre saltos protegidos por CRC, y la suma de comprobación TCP de 16 bits detecta la mayoría de ellos. ^{[ 60 ]}

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, impidiendo que el receptor TCP los reciba y procese de forma fiable. Contar con un mecanismo de control de flujo es esencial en un entorno donde se comunican máquinas con diferentes velocidades de red. Por ejemplo, si un 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 saturarse. ^{[ 15 ]}

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 adicionales recibidos (en bytes) que está dispuesto a almacenar en búfer para la conexión. El host emisor solo puede enviar hasta esa cantidad de datos antes de tener que esperar una confirmación y una actualización de la ventana de recepción por parte del host receptor.

Cuando un receptor anuncia un tamaño de ventana de 0, el emisor deja de enviar datos e inicia su temporizador de persistencia . Este temporizador protege a TCP de un posible bloqueo que podría ocurrir si se pierde una actualización posterior del tamaño de ventana por parte del receptor. El emisor no puede enviar más datos hasta recibir una nueva actualización del tamaño de ventana. Cuando expira el temporizador de persistencia, el emisor TCP intenta recuperarse enviando un paquete pequeño para que el receptor responda enviando otra confirmación con el nuevo tamaño de ventana.

Si un receptor procesa los 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 resulta ineficiente enviar solo unos pocos bytes de datos en un segmento TCP, dado el considerable coste adicional de la cabecera TCP.

Control de congestión

El último aspecto principal de TCP es el control de congestión . TCP utiliza diversos mecanismos para lograr un alto rendimiento y evitar el colapso por congestión , una situación de bloqueo que degrada gravemente el rendimiento de la red . Estos mecanismos controlan la velocidad de entrada de datos a la red, manteniendo el flujo de datos por debajo de una velocidad que desencadenaría el colapso. Además, proporcionan una asignación aproximadamente equitativa entre los flujos, basada en el principio de máximo-mínimo.

Los remitentes utilizan las confirmaciones de recepción de datos, o la ausencia de ellas, para inferir el estado de la red entre el emisor y el receptor TCP. Junto con los temporizadores, los emisores y receptores TCP pueden modificar el comportamiento del flujo de datos. Esto se conoce 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 . ^{[ 61 ]}

Además, los remitentes emplean un tiempo de espera de retransmisión (RTO) que se basa en el tiempo de ida y vuelta (RTT) estimado entre el remitente y el receptor, así como en la varianza de este tiempo de ida y vuelta. ^{[ 62 ]} Hay sutilezas en la estimación del RTT. Por ejemplo, los remitentes deben tener cuidado al calcular muestras de RTT para paquetes retransmitidos; normalmente utilizan el algoritmo de Karn o marcas de tiempo TCP. ^{[ 29 ]} Estas muestras individuales de RTT 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 el que se utiliza como estimación del tiempo de ida y vuelta.

Mejorar TCP para gestionar de forma fiable las pérdidas, minimizar los errores, controlar la congestión y alcanzar altas velocidades en entornos de muy alta velocidad son áreas de investigación y desarrollo de estándares en constante evolución. Como resultado, existen diversas variantes de algoritmos para evitar la congestión de TCP .

TCP puede ser atacado de diversas maneras. Los resultados de una evaluación de seguridad exhaustiva de TCP, junto con posibles mitigaciones para los problemas identificados, se publicaron en 2009, ^{[ 74 ]} y se continuó trabajando en el IETF hasta 2012. ^{[ 75 ]} Las vulnerabilidades notables incluyen denegación de servicio, secuestro de conexión, veto TCP y ataque de reinicio TCP .

Una conexión TCP se identifica mediante una cuádrupla formada por la dirección de origen, el puerto de origen , la dirección de destino y el puerto de destino. ^{[ d ] [ 82 ] [ 83 ]} Los números de puerto se utilizan para identificar diferentes servicios y para permitir múltiples conexiones entre hosts. ^{[ 16 ]} TCP utiliza números de puerto de 16 bits , lo que proporciona 65.536 valores posibles para cada uno de los puertos de origen y destino. ^{[ 19 ]} La dependencia de la identidad de la conexión en las direcciones significa que las conexiones TCP están vinculadas a una única ruta de red; TCP no puede utilizar otras rutas que los hosts con múltiples interfaces de red tienen disponibles, y las conexiones se interrumpen si cambia la dirección de un punto final. ^{[ 84 ]}

Los números de puerto se clasifican en tres categorías básicas: conocidos, registrados y dinámicos o privados. Los puertos conocidos son asignados por la Autoridad de Números Asignados de Internet (IANA) y suelen ser utilizados por procesos 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). ^{[ e ]} Los puertos registrados (1024–49151) pueden ser asignados a servicios específicos por desarrolladores externos, pero algunos sistemas operativos también asignan puertos de cliente efímeros de este rango. Los puertos dinámicos o privados (49152–65535) no están asociados con ningún servicio registrado y se utilizan comúnmente de forma exclusiva como puertos efímeros para conexiones de cliente temporales.

La traducción de direcciones de red (NAT, por sus siglas en inglés) suele utilizar números de puerto dinámicos, en el lado público, para desambiguar el 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 única dirección pública.

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 , publicada en octubre de 1989, aclaró una serie de requisitos de implementación del protocolo TCP. Una lista de las 8 especificaciones requeridas y más de 20 mejoras altamente recomendadas está disponible en RFC 7414. Entre esta lista se encuentra RFC 2581 , Control de Congestión TCP, uno de los RFC relacionados con TCP más importantes de los últimos años, que describe algoritmos actualizados que evitan la congestión indebida. En 2001, se escribió RFC 3168 para describir la Notificación Explícita de Congestión (ECN), un mecanismo de señalización para evitar la congestión.

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

El protocolo TCP multipath (MPTCP) ^{[ 85 ] [ 86 ]} es un esfuerzo continuo dentro del IETF que busca permitir que una conexión TCP utilice múltiples rutas para maximizar el uso de recursos y aumentar la redundancia. La redundancia que ofrece el protocolo TCP multipath en el contexto de redes inalámbricas permite el uso simultáneo de diferentes redes, lo que proporciona un mayor rendimiento y mejores capacidades de transferencia. El protocolo TCP multipath también ofrece beneficios de rendimiento en entornos de centros de datos. ^{[ 87 ]} La ​​implementación de referencia ^{[ 88 ]} del protocolo TCP multipath se desarrolló en el kernel de Linux. ^{[ 89 ]} El protocolo TCP multipath se utiliza para admitir la aplicación de reconocimiento de voz Siri en iPhones, iPads y Macs. ^{[ 90 ]}

tcpcrypt es una extensión propuesta en julio de 2010 para proporcionar cifrado a nivel de transporte directamente en TCP. Está diseñada para funcionar de forma transparente y no requiere ninguna configuración. A diferencia de TLS (SSL), tcpcrypt no proporciona autenticación, pero ofrece primitivas sencillas a la aplicación para que la implementen. El RFC de tcpcrypt fue publicado por la IETF en mayo de 2019. ^{[ 91 ]}

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. ^{[ 92 ]} TCP Fast Open se publicó como RFC 7413 en 2014. ^{[ 93 ]}

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 TCP después de la recuperación sea lo más cercano posible al umbral de inicio lento . ^{[ 94 ]} El algoritmo está diseñado para mejorar la velocidad de recuperación y es el algoritmo de control de congestión predeterminado en los núcleos de Linux 3.2+. ^{[ 95 ]}

Una forma de superar los requisitos de potencia de procesamiento de TCP es mediante la creación de implementaciones de hardware, conocidas como motores de descarga de TCP (TOE). El principal problema de los TOE es su difícil integración en sistemas informáticos, que requiere modificaciones importantes en el sistema operativo del ordenador o dispositivo.

Se ha demostrado que TCP de baja potencia ( TCPLp ) funciona en entornos con recursos limitados donde, de otro modo, se prefiere CoAP basado en UDP. ^{[ 98 ] [ 99 ]}

Los datos de cable de TCP brindan oportunidades significativas de recopilación y modificación de información a los observadores en la ruta, ya que los metadatos del protocolo se transmiten en texto plano . ^{[ 100 ] [ 101 ]} Si bien esta transparencia es útil para los operadores de red ^{[ 102 ]} e investigadores, ^{[ 103 ]} la información recopilada de los metadatos del protocolo puede reducir la privacidad del usuario final. ^{[ 104 ]} Esta visibilidad y maleabilidad de los metadatos ha llevado a que TCP sea difícil de extender —un caso de osificación del protocolo— ya que cualquier nodo intermedio (una ' caja intermedia ') puede tomar decisiones basadas en esos metadatos o incluso modificarlos, ^{[ 105 ] [ 106 ]} rompiendo el principio de extremo a extremo . ^{[ 107 ]} 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 de osificación dañinos de los intermediarios. ^{[ 108 ]} Evitar los riesgos de extensibilidad de los intermediarios impuso restricciones significativas al diseño de MPTCP , ^{[ 109 ] [ 110 ]} y las dificultades causadas por los intermediarios han obstaculizado el despliegue de TCP Fast Open en navegadores web . ^{[ 111 ]} Otra fuente de osificación es la dificultad de modificar las funciones TCP en los puntos finales, típicamente en el núcleo del sistema operativo ^{[ 112 ]} o en hardware con un motor de descarga TCP . ^{[ 113 ]}

Como TCP proporciona a las aplicaciones la abstracción de un flujo de bytes confiable , puede sufrir bloqueo de cabecera de línea : si los paquetes se reordenan o se pierden y necesitan ser retransmitidos (y por lo tanto se reordenan), los datos de partes secuencialmente 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 de red . Si se encapsulan y multiplexan varios mensajes independientes de nivel superior en una sola conexión TCP, el bloqueo de cabecera de línea puede hacer que el procesamiento de un mensaje completamente recibido que se envió posteriormente espere la entrega de un mensaje que se envió anteriormente. ^{[ 114 ]} Los navegadores web intentan mitigar el bloqueo de cabecera de línea abriendo múltiples conexiones paralelas. Esto genera el costo de establecer la conexión repetidamente, así como multiplicar los recursos necesarios para rastrear esas conexiones en los puntos finales. ^{[ 115 ]} Las conexiones paralelas también tienen un control de congestión que opera independientemente entre sí, en lugar de poder agrupar información y responder más rápidamente a las condiciones de red observadas; ^{[ 116 ]} Los agresivos patrones de envío inicial de TCP pueden causar congestión si se abren múltiples conexiones paralelas; y el modelo de equidad por conexión conduce a una monopolización de los recursos por parte de las aplicaciones que adoptan este enfoque. ^{[ 117 ]}

El establecimiento de la conexión es un importante contribuyente a la latencia experimentada por los usuarios web. ^{[ 118 ] [ 119 ]} El protocolo de enlace de tres vías de TCP introduce un RTT de latencia durante el establecimiento de la conexión antes de que se puedan enviar datos. ^{[ 119 ]} Para flujos cortos, estos retrasos son muy significativos. ^{[ 120 ]} Transport Layer Security (TLS) requiere su propio protocolo de enlace para el intercambio de claves en el establecimiento de la conexión. Debido al diseño en capas, el protocolo de enlace TCP y el protocolo de enlace TLS proceden en serie; el protocolo de enlace TLS no puede comenzar hasta que el protocolo de enlace TCP haya concluido. ^{[ 121 ]} Se requieren dos RTT para el establecimiento de la conexión con TLS 1.2 sobre TCP. ^{[ 122 ]} TLS 1.3 permite la reanudación de la conexión con cero RTT en algunas circunstancias, pero, cuando se superpone a TCP, todavía se requiere un RTT para el protocolo de enlace TCP, y esto no puede ayudar a la conexión inicial; Los intercambios de claves con RTT cero también presentan desafíos criptográficos, ya que el intercambio de claves no interactivo eficiente, seguro contra repetición y seguro hacia adelante es un tema de investigación abierto. ^{[ 123 ]} TCP Fast Open permite la transmisión de datos en los paquetes iniciales (es decir, SYN y SYN-ACK), eliminando un RTT de latencia durante el establecimiento de la conexión. ^{[ 124 ]} Sin embargo, TCP Fast Open ha sido difícil de implementar debido a la osificación del protocolo; a partir de 2020, ningún navegador web lo usaba por defecto. ^{[ 111 ]}

El rendimiento de TCP se ve afectado por el reordenamiento de paquetes . Los paquetes reordenados pueden causar el envío de acuses de recibo duplicados, que, si superan un umbral, activarán una retransmisión espuria y el control de congestión. El comportamiento de la transmisión también puede volverse irregular, ya que se reconocen rangos grandes de una sola vez cuando se recibe un paquete reordenado al inicio del rango (de manera similar a como el bloqueo de cabecera de línea afecta a las aplicaciones). ^{[ 125 ]} Blanton y Allman (2002) encontraron que el rendimiento estaba inversamente relacionado con la cantidad de reordenamiento, hasta un umbral donde todo reordenamiento activa una retransmisión espuria. ^{[ 126 ]} La mitigación del reordenamiento depende de la capacidad del remitente para determinar que ha enviado una retransmisión espuria y, por lo tanto, de la resolución de la ambigüedad de la retransmisión. ^{[ 127 ]} La reducción de las retransmisiones espurias inducidas por el reordenamiento puede ralentizar la recuperación de una pérdida genuina. ^{[ 128 ]}

El acuse de recibo selectivo puede proporcionar un beneficio significativo al rendimiento; Bruyeron, Hemon y Zhang (1998) midieron ganancias de hasta el 45 %. ^{[ 129 ]} Un factor importante en la mejora es que el acuse de recibo selectivo puede evitar con mayor frecuencia el inicio lento después de una pérdida y, por lo tanto, puede utilizar mejor el ancho de banda disponible. ^{[ 130 ]} Sin embargo, TCP solo puede acusar de recibo selectivamente un máximo de tres bloques de números de secuencia. Esto puede limitar la tasa de retransmisión y, por lo tanto, la recuperación de pérdidas o causar retransmisiones innecesarias, especialmente en entornos con alta pérdida. ^{[ 131 ] [ 132 ]}

TCP fue diseñado originalmente para redes cableadas donde la pérdida de paquetes se considera el resultado de la congestión de la red y el tamaño de la ventana de congestión se reduce drásticamente como precaución. Sin embargo, se sabe que los enlaces inalámbricos experimentan pérdidas esporádicas y generalmente temporales debido al desvanecimiento , la sombra, la transferencia, la interferencia y otros efectos de radio, que no son estrictamente congestión. Después de la reducción (errónea) 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 en el tamaño de la ventana. Esto hace que el enlace de radio se subutilice. Se ha llevado a cabo una extensa investigación para combatir estos efectos perjudiciales. Las soluciones sugeridas se pueden categorizar como soluciones de extremo a extremo, que requieren modificaciones en el cliente o el servidor, ^{[ 133 ]} soluciones de capa de enlace, como el Protocolo de Enlace de Radio en redes celulares, o soluciones basadas en proxy que requieren algunos cambios en la red sin modificar los nodos finales. ^{[ 133 ] [ 134 ]} Se han propuesto varios algoritmos alternativos de control de congestión, como Vegas , Westwood , Veno y Santa Cruz, para ayudar a resolver el problema inalámbrico.

La idea de un acelerador TCP es finalizar las conexiones TCP dentro del procesador de red y luego reenviar los datos a una segunda conexión hacia el sistema final. Los paquetes de datos que se originan del remitente se almacenan en búfer en el nodo acelerador, que se encarga de realizar retransmisiones locales en caso de pérdida de paquetes. De esta manera, en caso de pérdidas, el bucle de retroalimentación entre el remitente y el receptor se acorta al que existe entre el nodo acelerador y el receptor, lo que garantiza una entrega de datos más rápida al receptor. ^{[ 135 ]}

Dado que TCP es un protocolo adaptativo a la velocidad, la frecuencia con la que el emisor TCP inyecta paquetes en la red es directamente proporcional a la carga de la red y a la capacidad de procesamiento del receptor. El emisor evalúa las condiciones de la red a partir de las confirmaciones recibidas. El nodo acelerador divide el bucle de retroalimentación entre el emisor y el receptor, garantizando así un tiempo de ida y vuelta (RTT) más corto por paquete. Un RTT más corto resulta beneficioso, ya que asegura una respuesta más rápida ante cualquier cambio en la red y una adaptación más veloz del emisor para contrarrestar dichos cambios.

Entre las desventajas de este método se encuentra el hecho de que la sesión TCP debe dirigirse a través del acelerador; esto significa que si el enrutamiento cambia y el acelerador ya no se encuentra en la ruta, la conexión se interrumpirá. Además, destruye la propiedad de extremo a extremo del mecanismo TCP ACK; cuando el remitente recibe el ACK, el paquete ha sido almacenado por el acelerador, no entregado al receptor.

Un analizador 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 utilizan TCP, ya que muestra al ingeniero qué paquetes pasan por el enlace. Algunas pilas de red admiten la opción de socket SO_DEBUG, que se puede habilitar en el socket mediante setsockopt. Esta opción vuelca todos los paquetes, estados TCP y eventos en ese socket, lo que resulta útil para la depuración. Netstat es otra utilidad que se puede utilizar para la depuración.

Para muchas aplicaciones, TCP no es apropiado. Normalmente, la aplicación no puede acceder a los paquetes que llegan después de un paquete perdido hasta que se recibe la copia retransmitida del paquete perdido. Esto causa problemas en aplicaciones en tiempo real, como la transmisión de contenido multimedia, los juegos multijugador en tiempo real y la voz sobre IP (VoIP), donde generalmente es más útil obtener la mayor parte de los datos de forma oportuna que obtenerlos todos en orden.

Por razones históricas y de rendimiento, la mayoría de las redes de área de almacenamiento (SAN) utilizan el protocolo Fibre Channel (FCP) sobre conexiones Fibre Channel . Para sistemas embebidos , arranque de red y servidores que atienden solicitudes sencillas de un gran número de clientes (por ejemplo, servidores DNS ), la complejidad de TCP puede ser un problema. Tareas como la transmisión de datos entre dos hosts que se encuentran detrás de NAT (mediante STUN o sistemas similares) son mucho más sencillas sin un protocolo relativamente complejo como TCP.

En general, cuando TCP no es adecuado, se utiliza el Protocolo de Datagramas de Usuario (UDP). Este protocolo ofrece la misma multiplexación de aplicaciones y sumas de verificación que TCP, pero no gestiona flujos ni retransmisiones, lo que permite al desarrollador de la aplicación programarlos de forma adecuada para la situación o sustituirlos por otros métodos, como la corrección de errores hacia adelante o la ocultación de errores .

El Protocolo de Transmisión de Control de Flujo (SCTP) es otro protocolo que proporciona servicios de flujo confiables, similares a TCP. Es más reciente y considerablemente más complejo que TCP, y aún no se ha implementado de forma generalizada. Sin embargo, está especialmente diseñado para usarse en situaciones donde la confiabilidad y la precisión casi en tiempo real son cruciales.

El Protocolo de Transporte Venturi (VTP) es un protocolo propietario patentado diseñado para reemplazar a TCP de forma transparente y superar las ineficiencias percibidas en la transmisión inalámbrica de datos. En particular, en las comunicaciones móviles y las redes inalámbricas, la transmisión de datos puede volverse inestable debido a la alta latencia y las interferencias de señal.

El algoritmo de prevención de congestión de TCP funciona muy bien en entornos ad hoc donde se desconoce de antemano quién envía los datos. Si el entorno es predecible, un protocolo basado en temporización, como el Modo de Transferencia Asíncrona (ATM), puede evitar la sobrecarga de retransmisión de TCP.

El protocolo de transferencia de datos basado en UDP (UDT) está diseñado para entornos de red de alto ancho de banda y alta latencia, en particular para transferencias de datos a gran escala, como la transmisión de archivos o contenido multimedia. En redes con un alto producto ancho de banda-retardo , ^{[ 136 ]} UDT ofrece ventajas sobre TCP, proporcionando mayor eficiencia y equidad.

El Protocolo de Transacciones Multipropósito (MTP/IP) es un software propietario patentado diseñado para lograr de forma adaptativa un alto rendimiento y una excelente capacidad de transmisión de datos en una amplia variedad de condiciones de red, en particular aquellas en las que se percibe que TCP es ineficiente.

• Stevens, W. Richard (1994-01-10). TCP/IP Ilustrado, Volumen 1: Los Protocolos . Addison-Wesley Pub. Co. ISBN 978-0-201-63346-7.
• Stevens, W. Richard; Wright, Gary R (1994). TCP/IP Ilustrado, Volumen 2: La Implementación . Addison-Wesley. ISBN 978-0-201-63354-2.
• Stevens, W. Richard (1996). TCP/IP Ilustrado, Volumen 3: TCP para transacciones, HTTP, NNTP y los protocolos del dominio UNIX . Addison-Wesley. ISBN 978-0-201-63495-2.**

• Entrevista de historia oral con Robert E. Kahn
• Asignaciones de puertos de IANA
• Parámetros TCP de IANA
• Archivado el 14 de febrero de 2021 en Wayback Machine .