TCP

El Protocolo de control de transmisión o TCP por sus siglas en inglés (Transmission Control Protocol) 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 para 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 (Specification of Internet Transmission Control Program), 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 fue el Programa de Control de Transmisión que incorporó 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 dio como resultado 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 Internet Protocol Suite.

En 2004, Vint Cerf y Bob Kahn recibieron el Premio Turing por su trabajo fundacional sobre 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 negociación 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 del 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 incurrir en 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 de entrega de flujo fiable 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 mediante 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 fragmentos 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 el uso formal como en el informal, mientras que en una terminología más precisa, el segmento se refiere a la unidad de datos del protocolo TCP (PDU), el datagrama a la PDU IP y la 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.

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.

Compensaciones	Octeto	0	1	2	3
Octeto	Un poco	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
0	0	Puerto de origen	Puerto de destino
4	32	Secuencia de números
8	64	Número de acuse de recibo (si se establece ACK)
12	96	Compensación de datos	Reservado0 0 0	NS	CWR	CEPE	URG	ACK	PSH	PRIMERA	SYN	ALETA	Tamaño de ventana
dieciséis	128	Suma de verificación	Puntero urgente (si se establece URG)
20	160	Opciones (si el desplazamiento de datos es > 5. Se rellena al final con bits "0" si es necesario).
⋮	⋮
60	480

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á establecido (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 el indicador SYN está limpio (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 establece el indicador ACK, el valor de este campo es el siguiente número de secuencia que espera el remitente del ACK. Esto acusa recibo 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, pero no los datos.Compensación de datos (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 de 15 palabras, lo que da un tamaño mínimo de 20 bytes y un máximo de 60 bytes, lo que permite hasta 40 bytes de opciones en el encabezado. Este campo recibe su nombre del hecho de que también es el desplazamiento desde el inicio del segmento TCP hasta los datos reales.Reservado (3 bits)Para uso futuro y debe establecerse en cero.Banderas (9 bits)Contiene 9 banderas de 1 bit (bits de control) de la siguiente manera:

• NS (1 bit): ECN-nonce - protección de ocultación
• CWR (1 bit): el host de envío establece el indicador de ventana de congestión reducida (CWR) para indicar que recibió un segmento TCP con el indicador ECE establecido y respondió en el mecanismo de control de congestión.
• ECE (1 bit): ECN-Echo tiene una doble función, según el valor de la bandera SYN. Esto indica:

• Si el indicador SYN está establecido (1), el par TCP es compatible con ECN.
• Si el indicador SYN está claro (0), significa que se recibió un paquete con el indicador Congestión experimentada establecido (ECN=11) en el encabezado IP durante la transmisión normal. Esto sirve como indicación de congestión en la red (o congestión inminente) para el remitente TCP.

• URG (1 bit): indica que el campo de puntero Urgente es significativo
• ACK (1 bit): Indica que el campo Reconocimiento es significativo. Todos los paquetes posteriores al paquete SYN inicial enviado por el cliente deben tener este indicador establecido.
• PSH (1 bit): función de pulsación. Pide enviar los datos almacenados en búfer a la aplicación receptora.
• RST (1 bit): restablecer la conexión
• SYN (1 bit): Sincroniza números de secuencia. Solo el primer paquete enviado desde cada extremo debe tener este indicador establecido. Algunas otras banderas y campos cambian de significado en función de esta bandera, y algunas solo son válidas cuando está configurada y otras cuando está clara.
• FIN (1 bit): último paquete del remitente

Tamaño de ventana (16 bits)El tamaño de la ventana de recepción, que especifica el número de unidades de tamaño de ventana que el remitente de este segmento está dispuesto a recibir actualmente. (Ver § Control de flujo y § Escalado de ventana.)Suma de comprobación (16 bits)El campo de suma de comprobación de 16 bits se utiliza para la comprobación de errores del encabezado TCP, la carga útil y un pseudoencabezado IP. El pseudoencabezado 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 los encabezados TCP y la carga útil (en bytes).Puntero urgente (16 bits)Si se establece el indicador URG, este campo de 16 bits es un desplazamiento del número de secuencia que indica el último byte de datos urgente.Opciones (Variable 0–320 bits, en unidades de 32 bits)La longitud de este campo está determinada por el desplazamiento de datoscampo. Las opciones tienen hasta tres campos: Tipo de opción (1 byte), Longitud de opción (1 byte), Datos de opción (variable). El campo Tipo de opción indica el tipo de opción y es el único campo que no es opcional. Según el valor de Tipo de opción, se pueden establecer los siguientes dos campos. Option-Length indica la duración total de la opción, y Option-Data contiene datos asociados con la opción, si corresponde. Por ejemplo, un byte de tipo de opción de 1 indica que esta es una opción sin operación que se usa solo para rellenar, y no tiene campos de longitud de opción u 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 solo un byte. Se utiliza un byte de tipo de opción de 2 para indicar la opción Tamaño máximo de segmento, y será seguido por un byte de longitud de opción que especifica la longitud del campo MSS. Option-Length es la longitud total del campo de opciones dado, incluidos los campos Option-Kind y Option-Length. Entonces, mientras que el valor de MSS generalmente se expresa en dos bytes, Option-Length será 4. Como ejemplo, un campo de opción de MSS con un valor de 0x05B4 se codifica como (0x02 0x04 0x05B4) en la sección de opciones de TCP.Es posible que algunas opciones solo se envíen cuando se establece SYN; se indican a continuación como. Option-Kind y longitudes estándar dadas como (Option-Kind, Option-Length).

Tipo de opción	Opción-Longitud	Opción-Datos	Objetivo	notas
0	N / A	N / A	Fin de la lista de opciones
1	N / A	N / A	No operacion	Esto se puede usar para alinear campos de opciones en límites de 32 bits para un mejor rendimiento.
2	4	SS	Tamaño máximo de segmento	Ver § Tamaño máximo de segmento
3	3	S	Escala de ventana	Ver § Escalado de ventana para más detalles
4	2	N / A	Reconocimiento selectivo permitido	Ver § Agradecimientos selectivos para más detalles
5	N (10, 18, 26 o 34)	BBBB, EEEE,...	Acuse de recibo selectivo (SACK)	Estos dos primeros bytes van seguidos de una lista de 1 a 4 bloques que se reconocen de forma selectiva, especificados como punteros de inicio/fin de 32 bits.
8	10	TTTT, EEE	Marca de tiempo y eco de la marca de tiempo anterior	Ver § Marcas de tiempo TCP para más detalles

Los valores de tipo de opción restantes son históricos, obsoletos, experimentales, aún no estandarizados o sin asignar. La IANA mantiene las asignaciones de números de opción.RellenoEl relleno del encabezado TCP se utiliza para garantizar que el encabezado TCP termine y los datos comiencen en un límite de 32 bits. El relleno se compone de ceros.

Operación de protocolo

Las operaciones del protocolo TCP se pueden dividir en tres fases. El establecimiento de la conexión es un proceso de reconocimiento 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 socket de Internet. Durante el tiempo de vida de una conexión TCP, el punto final local sufre una serie de cambios de estado:

Estado	punto final	Descripción
ESCUCHAR	Servidor	Esperando una solicitud de conexión desde cualquier punto final TCP remoto.
SYN-ENVIADO	Cliente	Esperando una solicitud de conexión coincidente después de haber enviado una solicitud de conexión.
SYN-RECIBIDO	Servidor	Esperando un reconocimiento de solicitud de conexión de confirmación después de haber recibido y enviado una solicitud de conexión.
ESTABLECIDO	servidor y cliente	Una conexión abierta, los datos recibidos pueden ser entregados al usuario. El estado normal para la fase de transferencia de datos de la conexión.
FIN-ESPERA-1	servidor y cliente	Esperando una solicitud de terminación de conexión del TCP remoto, o un reconocimiento de la solicitud de terminación de conexión enviada anteriormente.
FIN-ESPERA-2	servidor y cliente	Esperando una solicitud de terminación de conexión del TCP remoto.
CERRAR-ESPERAR	servidor y cliente	Esperando una solicitud de terminación de conexión del usuario local.
CLAUSURA	servidor y cliente	Esperando un reconocimiento de solicitud de terminación de conexión del TCP remoto.
ÚLTIMO ACK	servidor y cliente	Esperando un reconocimiento de la solicitud de finalización de la conexión enviada previamente al TCP remoto (que incluye un reconocimiento de su solicitud de finalización de la conexión).
TIEMPO DE ESPERA	servidor o cliente	Esperar a que pase el tiempo suficiente para asegurarse de que todos los paquetes restantes en la conexión hayan expirado.
CERRADO	servidor y cliente	No hay estado de conexión en absoluto.

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 la realiza el cliente enviando un SYN al servidor. El cliente establece el número de secuencia del segmento en un valor aleatorio A.
2. SYN-ACK: En respuesta, el servidor responde con un SYN-ACK. El número de reconocimiento se establece en uno más que el número de secuencia recibido, es decir, A+1, y el número de secuencia que elige el servidor para el paquete es otro número aleatorio, B.
3. ACK: finalmente, el cliente envía un ACK de vuelta al servidor. El número de secuencia se establece en el valor de acuse de recibo recibido, es decir, A+1, y el número de acuse de recibo se establece en uno más que el número de secuencia recibido, 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 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; esto evita la posible confusión que puede ocurrir si los paquetes retrasados ​​asociados con una conexión anterior se entregan durante una conexión posterior.

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 y 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.

El 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 solo 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 reconocidos 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 ordenados: el host de destino reorganiza los segmentos de acuerdo con un número de secuencia
• Retransmisión de paquetes perdidos: cualquier flujo acumulativo no reconocido se retransmite
• Transferencia de datos sin errores: los paquetes corruptos se tratan como perdidos y se retransmiten
• Control de flujo: limita la tasa de transferencia de datos de un remitente para garantizar una entrega confiable. El receptor insinúa continuamente al remitente sobre la cantidad de datos que se pueden recibir. Cuando se llena el búfer del host receptor, el siguiente reconocimiento suspende la transferencia y permite que se procesen los datos en el búfer.
• Control de congestión: los paquetes perdidos (supuestamente debido a la congestión) provocan una reducción en 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 decirle 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 los paquetes por encima de ese número de segmento (100) porque utiliza 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 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 da como resultado un comportamiento de retroceso exponencial. Normalmente, el valor inicial del temporizador es , donde es la granularidad del reloj. 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.

Detección de errores

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

Para asegurar 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 de la 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.

Cuando un receptor anuncia un tamaño de ventana de 0, el remitente deja de enviar datos e inicia su temporizador de persistencia. 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 ineficiente 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 en la variación de este tiempo de ida y vuelta. El comportamiento de este temporizador se especifica en RFC 6298. 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 (ver RFC 1323). Estas muestras RTT individuales 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 intentar lograr esto, normalmente cada lado anuncia el MSS mediante la opción MSS cuando se establece la conexión TCP, en cuyo caso 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 el emisor y el receptor están directamente conectados. Además, 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 suele denominarse "negociación de MSS". Estrictamente hablando, el MSS no se "negocia" entre el emisor y el receptor, porque eso implicaría que tanto el emisor como el receptor negociarán y acordarán un único MSS unificado que se aplica a todas las comunicaciones en ambas direcciones de la conexión. De hecho, se permiten dos valores de MSS completamente independientes para las dos direcciones de flujo de datos en una conexión TCP. Esta situación puede surgir, por ejemplo, si uno de los dispositivos que participan en una conexión tiene una cantidad extremadamente limitada de memoria reservada (quizás incluso más pequeña que la MTU de ruta descubierta general) para procesar los segmentos TCP entrantes.

Agradecimientos selectivos

Confiar únicamente en el esquema de reconocimiento acumulativo empleado por el protocolo 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 del 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 especificar una cantidad de 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).), con un bloquesiendo 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 sólo entra en funcionamiento si ambas partes la apoyan. Esto se negocia cuando se establece una conexión. SACK usa una opción de encabezado TCP (consulte la estructura del segmento TCP para obtener más información). 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. El campo de tamaño de ventana TCP controla el flujo de datos y su valor está limitado a entre 2 y 65.535 bytes.

Dado que el campo de tamaño no se puede expandir, 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 de 65 535 bytes a 1 gigabyte. Escalar a tamaños de ventana más grandes es parte de lo que se necesita 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. 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 marca de tiempo del remitente de 4 bytes (mi marca de tiempo)un valor de marca de tiempo de respuesta de eco de 4 bytes (la marca de tiempo más reciente recibida de usted).

Las marcas de tiempo TCP se utilizan en un algoritmo conocido como Protección contra números de secuencia envueltos o PAWS (consulte RFC 1323 para obtener más detalles). 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 (RFC 3522) utiliza marcas de tiempo TCP para determinar si se están produciendo retransmisiones porque los paquetes se han perdido o simplemente están fuera de servicio.

Las estadísticas recientes muestran que el nivel de adopción de la marca de tiempo se ha estancado, en aproximadamente un 40 %, debido a que el servidor de Windows dejó de admitir desde Windows Server 2008.

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

Datos fuera de banda

Es posible interrumpir o anular la secuencia en cola en lugar de esperar a que finalice la secuencia. Esto se hace especificando los datos como urgentes. Esto le dice al programa receptor que lo procese inmediatamente, junto con el resto de los datos urgentes. Cuando finaliza, TCP informa a la aplicación y vuelve a la cola de transmisión. Un ejemplo es cuando se usa TCP para una sesión de inicio de sesión remota, el usuario puede enviar una secuencia de teclado que interrumpe o aborta el programa en el otro extremo. Estas señales se necesitan con mayor frecuencia cuando un programa en la máquina remota no funciona correctamente. Las señales deben enviarse sin esperar a que el programa termine su transferencia actual.

Los datos TCP fuera de banda no se diseñaron para la Internet moderna. El puntero urgente solo altera el procesamiento en el host remoto y no acelera ningún procesamiento en la propia red. Cuando llega al host remoto, hay dos interpretaciones ligeramente diferentes del protocolo, lo que significa que solo los bytes individuales de datos OOB son confiables. Esto supone que es confiable en absoluto, ya que es uno de los elementos de protocolo menos utilizados y tiende a implementarse de manera deficiente.

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 de 1460, por lo que salen 2 paquetes en una Ethernet de 10 Mbit/s y 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.

La configuración de la opción de socket TCP_NODELAYanula 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 PSHbit de inserción 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 y solo se controla mediante la pila de protocolos.

Vulnerabilidades

TCP puede ser atacado de varias maneras. 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.

Negación de servicio

Mediante el uso de una dirección IP falsificada y el envío repetido de 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 puede 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.

Hacerse pasar por 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 de tcp

Un atacante que puede 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 próximo paquete esperado. Cuando finalmente se recibe el paquete legítimo, se encuentra que tiene el mismo número de secuencia y longitud que un paquete ya recibido y se descarta silenciosamente como un paquete duplicado normal: el paquete malicioso "veta" el paquete legítimo. 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 la aplicación de envío y recepción en un host, a menudo llamados sockets 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: conocido, registrado y dinámico/privado. 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.

La traducción de direcciones de red (NAT), generalmente usa 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 para ser atendida 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. 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 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 las extensiones de TCP que permite que las aplicaciones se suscriban a eventos de 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 de 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 utilizando 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 los 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 en desuso

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 categorizar como soluciones integrales, que requieren modificaciones en el cliente o 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 construir implementaciones de hardware del mismo, ampliamente conocidas como motores de descarga 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.

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 la transmisión de medios, los juegos multijugador en tiempo real y la 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.

Generalmente, 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 fiables 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.

Venturi Transport Protocol (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 temporización 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 forma adaptativa un alto rendimiento y un rendimiento de transacción en una amplia variedad de condiciones de red, en particular aquellas en las que se percibe que TCP es 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 en RFC 793:

El campo de suma de comprobación es el complemento a uno de 16 bits de la suma del complemento a uno de todas las palabras de 16 bits en el encabezado y el texto. Si un segmento contiene un número impar de octetos de cabecera y de texto para sumar, el último octeto se rellena a la derecha con ceros para formar una palabra de 16 bits para fines de suma de control. El pad no se transmite como parte del segmento. Al calcular la suma de verificación, el campo de suma de verificación en sí se reemplaza con ceros.

En otras palabras, después del relleno adecuado, todas las palabras de 16 bits se suman 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.

Compensación de bits	0–3	4–7	8–15	16–31
0	Dirección de la fuente
32	Dirección de destino
64	ceros	Protocolo	Longitud TCP
96	Puerto de origen	Puerto de destino
128	Secuencia de números
160	Número de acuse de recibo
192	Compensación de datos	Reservado	Banderas	Ventana
224	Suma de verificación	puntero urgente
256	Opciones (opcional)
256/288+	Datos

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, según RFC 2460:Cualquier transporte u otro protocolo de capa superior que incluya las direcciones del encabezado IP en su cálculo de suma de verificación debe modificarse para su uso en IPv6, para incluir las direcciones IPv6 de 128 bits en lugar de las 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.

Compensación de bits	0–7	8–15	16–23	24–31
0	Dirección de la fuente
32
64
96
128	Dirección de destino
160
192
224
256	Longitud TCP
288	ceros	Siguiente encabezado= Protocolo
320	Puerto de origen	Puerto de destino
352	Secuencia de números
384	Número de acuse de recibo
416	Compensación de datos	Reservado	Banderas	Ventana
448	Suma de verificación	puntero urgente
480	Opciones (opcional)
480/512+	Datos

• Dirección de origen: la de la cabecera IPv6
• Dirección de destino: el destino final; si el paquete IPv6 no contiene un encabezado de enrutamiento, TCP usa la dirección de destino en el encabezado de IPv6; de lo contrario, en el nodo de origen, usa la dirección en el último elemento del encabezado de enrutamiento y, en el nodo receptor, utiliza la dirección de destino en el encabezado IPv6.
• Longitud de TCP: la longitud del encabezado y los datos de TCP
• Siguiente encabezado: el valor del 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 transmisión de Internet, versión de diciembre de 1974
• RFC 793 – TCP v4
• STD 7 - Protocolo de control de transmisión, especificación de protocolo
• RFC 1122: incluye algunas correcciones de errores para TCP
• RFC 1323: Extensiones TCP para alto rendimiento [Obsoleto por RFC 7323]
• RFC 1379: extensión de TCP para transacciones: conceptos [Obsoleto por RFC 6247]
• RFC 1948: defensa contra ataques de número de secuencia
• RFC 2018: opciones de reconocimiento selectivo de TCP
• RFC 5681 – Control de congestión de TCP
• RFC 6247: mover las extensiones TCP no implementadas RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644 y RFC 1693 al estado histórico
• RFC 6298 - Cómputo del temporizador de retransmisión de TCP
• RFC 6824 - Extensiones TCP para operación de múltiples rutas con múltiples direcciones
• RFC 7323: extensiones TCP para alto rendimiento
• RFC 7414: una hoja de ruta para los documentos de especificación de TCP