El Protocolo de control de transmisión ( TCP ) es uno de los principales protocolos del conjunto de protocolos de Internet . Se originó en la implementación inicial de la red en la que complementaba el Protocolo de Internet (IP). Por lo tanto, toda la suite se denomina comúnmente 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 del conjunto 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 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 alargan la latencia . Las aplicaciones que no requieren un servicio de flujo de datos confiable pueden utilizar en su lugar 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 para evitar la congestión de la red . Sin embargo, existen vulnerabilidades en TCP, que incluyen denegación de servicio , secuestro de conexión , veto de TCP y ataque de reinicio .
En mayo de 1974, Vint Cerf y Bob Kahn describieron un protocolo de interconexión para compartir recursos mediante conmutación de paquetes entre nodos de red. [1] Los autores habían estado trabajando con Gérard Le Lann para incorporar conceptos del proyecto francés CYCLADES en la nueva red. [2] 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. [3] Contiene el primer uso documentado de el término internet , como abreviatura de internetwork . [ cita necesaria ]
Un componente de control central de este modelo fue el Programa de Control de Transmisión que incorporaba enlaces orientados a conexión y servicios de datagramas entre hosts. El monolítico Programa de Control de Transmisión se dividió posteriormente en una arquitectura modular que constaba del Protocolo de Control de Transmisión y el Protocolo de Internet . Esto dio lugar a un modelo de red que se conoció informalmente como TCP/IP , aunque formalmente se le denominó modelo del Departamento de Defensa (DOD), modelo ARPANET y, finalmente, también como Internet Protocol Suite .
En 2004, Vint Cerf y Bob Kahn recibieron el Premio Turing por su trabajo fundamental en TCP/IP. [4] [5]
El Protocolo de control de transmisión proporciona un servicio de comunicación en un nivel intermedio entre un programa de aplicación y el Protocolo de Internet. Proporciona conectividad 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 transmisión y protocolo de enlace 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 datos perdidos, reorganiza los datos desordenados e incluso ayuda a minimizar la congestión de la red para reducir la aparición de otros problemas. Si los datos aún no se han entregado, se notifica a la fuente de este error. Una vez que el receptor TCP ha vuelto a ensamblar la secuencia de octetos transmitidos originalmente, los pasa a la aplicación receptora. Por tanto, TCP abstrae la comunicación de la aplicación de los detalles de red subyacentes.
TCP se utiliza ampliamente en muchas aplicaciones de Internet, incluida la World Wide Web (WWW), el correo electrónico , el protocolo de transferencia de archivos , Secure Shell , el intercambio 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 retrasos relativamente largos (del orden de segundos) mientras se esperan mensajes desordenados o retransmisiones de mensajes perdidos. Por lo tanto, no es particularmente adecuado para aplicaciones en tiempo real como 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). [6]
TCP es un servicio confiable de entrega de flujo de bytes que garantiza que todos los bytes recibidos serán idénticos y en el mismo orden que los enviados. Dado que la transferencia de paquetes por muchas redes no es confiable, TCP lo logra utilizando una técnica conocida como reconocimiento positivo con retransmisión . Esto requiere que el receptor responda con un mensaje de acuse de recibo cuando 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 dañe. [6]
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 la 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 garantiza que estén ordenados correctamente y sin errores mientras transmite el contenido del archivo a la aplicación receptora.
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 pares. [7]
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 [8] 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 buffers de datos como argumentos. El TCP empaqueta los datos de estos buffers en segmentos y llama al módulo de Internet [por ejemplo, IP] para transmitir cada segmento al TCP de destino. [9]
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 que se transportan para la aplicación. [10] 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 especificada en el encabezado IP. [ cita necesaria ]
[SYN]. Tipo de opción y longitudes estándar dadas como (Tipo de opción, Longitud de opción).
Las operaciones del protocolo TCP se pueden dividir en tres fases. El establecimiento de la conexión es un proceso de protocolo de enlace 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 la vida útil de una conexión TCP, el punto final local sufre una serie de cambios de estado : [23]
Antes de que un cliente intente conectarse con un servidor, el servidor primero debe vincularse y escuchar en un puerto para abrirlo para 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):
Los pasos 1 y 2 establecen y reconocen el número de secuencia para una dirección (cliente a servidor). Los pasos 2 y 3 establecen y reconocen el número de secuencia para la otra dirección (servidor a cliente). Una vez completados estos pasos, tanto el cliente como el servidor han recibido acuses de recibo y se establece una comunicación full-duplex.
La fase de terminación de la conexión utiliza un protocolo de enlace de cuatro vías, en el que cada lado de la conexión termina de forma independiente. Cuando un punto final 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 punto final TCP. Después de que el lado que envió el primer FIN ha respondido con el ACK final, espera un tiempo de espera antes de cerrar finalmente la conexión, tiempo durante el cual el puerto local no está disponible para nuevas conexiones; este estado permite al cliente TCP reenviar el acuse de recibo final al servidor en caso de que el ACK se pierda en tránsito. La duración del tiempo depende de la implementación, pero algunos valores comunes son 30 segundos, 1 minuto y 2 minutos. Después del tiempo de espera, el cliente ingresa al estado CERRADO y el puerto local queda disponible para nuevas conexiones. [24]
También es posible terminar la conexión mediante un protocolo de enlace de tres 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. [25]
Algunos sistemas operativos, como Linux y HP-UX , [ cita necesaria ] implementan una secuencia de cierre semidúplex. Si el host cierra activamente una conexión, mientras todavía tiene datos entrantes no leídos disponibles, el host envía la señal RST (perdiendo todos los datos recibidos) en lugar de FIN. Esto asegura que una aplicación TCP sepa que hubo una pérdida de datos. [26]
Una conexión puede estar en un estado medio abierto , 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í. El lado terminal debe continuar leyendo los datos hasta que el otro lado termine también. [ cita necesaria ]
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 puntos finales 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 en la tabla se conoce como Bloque de control de transmisión o TCB. Contiene información sobre los puntos finales (IP y puerto), estado de la conexión, datos de ejecución sobre los paquetes que se intercambian y buffers para enviar y recibir datos.
El número de sesiones en el lado del servidor está limitado únicamente por la memoria y puede crecer a medida que llegan nuevas conexiones, pero el cliente debe asignar un puerto efímero antes de enviar el primer SYN al servidor. Este puerto permanece asignado durante toda la conversación y limita efectivamente la cantidad de conexiones salientes de cada una de las direcciones IP del cliente. Si una aplicación no logra cerrar correctamente las conexiones no requeridas, un cliente puede quedarse sin recursos y no poder establecer nuevas conexiones TCP, incluso desde otras aplicaciones.
Ambos puntos finales también deben asignar espacio para paquetes no reconocidos y datos recibidos (pero no leídos).
El Protocolo de control de transmisión se diferencia en varias características clave en comparación con el Protocolo de datagramas de usuario :
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 desordenada que pueda ocurrir. El transmisor elige el número de secuencia del primer byte para el primer paquete, que se marca 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 indicarle al remitente que se han recibido datos en el byte especificado. Los ACK no implican que los datos se hayan entregado a la aplicación, simplemente significan que ahora es responsabilidad del receptor entregar los datos.
La confiabilidad se logra cuando el remitente detecta la pérdida de datos 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).
Cuando se retransmite un segmento TCP, conserva el mismo número de secuencia que el intento de entrega original. Esta combinación de entrega y ordenamiento lógico de datos significa que, cuando se recibe un acuse de recibo después de una retransmisión, el remitente no puede saber si se está acusando recibo de la transmisión original o de la retransmisión, lo que se conoce como ambigüedad de retransmisión . [27] TCP genera complejidad debido a la ambigüedad de la retransmisión. [28]
Si se pierde un solo segmento (digamos el segmento número 100) en una secuencia, entonces el receptor no puede reconocer los paquetes por encima de ese número de segmento (100) porque utiliza ACK acumulativos. Por lo 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 acuses de recibo duplicados, retransmite el último paquete no reconocido. Se utiliza un umbral de tres porque la red puede reordenar segmentos provocando acuses de recibo duplicados. Se ha demostrado que este umbral evita retransmisiones espurias debido a reordenamiento. [29] 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.
La ambigüedad de la retransmisión puede causar retransmisiones rápidas espurias y evitar la congestión si hay reordenamiento más allá del umbral de acuse de recibo duplicado. [30]
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 está la granularidad del reloj. [31] Esto protege contra el tráfico de transmisión excesivo debido a actores defectuosos o maliciosos, como atacantes de denegación de servicio tipo intermediario .
Las estimaciones precisas de RTT son importantes para la recuperación de pérdidas, ya que permiten al remitente asumir que un paquete no reconocido se perderá después de que transcurra un tiempo suficiente (es decir, determinar el tiempo de RTO). [32] La ambigüedad de la retransmisión puede hacer que la estimación del RTT del remitente sea imprecisa. [32] En un entorno con RTT variables, pueden ocurrir tiempos de espera falsos: [33] 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, provocando más retransmisiones innecesarias en la medida en que el enlace realmente se congestiona; [34] [35] el reconocimiento selectivo puede reducir este efecto. [36] RFC 6298 especifica que las implementaciones no deben utilizar segmentos retransmitidos al estimar el RTT. [37] El algoritmo de Karn garantiza que se producirá una buena estimación del RTT (eventualmente) esperando hasta que haya un reconocimiento inequívoco antes de ajustar el RTO. [38] Sin embargo, después de retransmisiones espurias, puede pasar mucho tiempo antes de que llegue un reconocimiento tan inequívoco, degradando el rendimiento mientras tanto. [39] Las marcas de tiempo de TCP también resuelven el problema de ambigüedad de retransmisión al establecer el RTO, [37] aunque no necesariamente mejoran la estimación de RTT. [40]
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 garantizar la exactitud se incluye un campo de suma de verificació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 la que se usa en PPP o la trama 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. [41]
TCP utiliza un protocolo de control de flujo de un extremo a otro 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 esencial 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. [6]
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 buffer para la conexión. El host emisor solo puede enviar hasta esa cantidad de datos antes de tener que 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 utiliza 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 recibir una nueva actualización del tamaño de la ventana del receptor. Cuando expira el temporizador de persistencia, el remitente TCP intenta la recuperación enviando un pequeño paquete para que el receptor responda enviando otra confirmación que contenga el nuevo tamaño de ventana.
Si un receptor procesa datos entrantes en pequeños incrementos, puede anunciar repetidamente una pequeña ventana de recepción. Esto se conoce como el síndrome de la ventana tonta , ya que es ineficaz enviar sólo unos pocos bytes de datos en un segmento TCP, dada la sobrecarga relativamente grande del encabezado TCP.
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 velocidad de los datos que ingresan a la red, manteniendo el flujo de datos por debajo de una velocidad que provocaría un colapso. También producen una asignación justa aproximadamente máxima-mínima 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 y el receptor TCP. Junto con los temporizadores, los emisores y receptores TCP pueden alterar el comportamiento del flujo de datos. Esto se conoce más generalmente como control de congestión o evitació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 . [42]
Además, los remitentes emplean un tiempo de espera de retransmisión (RTO) que se basa en el tiempo estimado de ida y vuelta (RTT) entre el remitente y el receptor, así como la variación en este tiempo de ida y vuelta. [43] Hay sutilezas en la estimación de RTT. Por ejemplo, los remitentes deben tener cuidado al calcular muestras RTT para paquetes retransmitidos; normalmente utilizan el algoritmo de Karn o marcas de tiempo TCP. [18] 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, existen varias variaciones del algoritmo para evitar la congestión de TCP .
El tamaño máximo de segmento (MSS) es la mayor cantidad de datos, especificada 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 pérdida de paquetes y retransmisiones excesivas. Para lograr esto, normalmente cada lado anuncia el MSS utilizando la opción MSS cuando se establece la conexión TCP. El valor de la opción se deriva del tamaño de la unidad de transmisión máxima (MTU) de la capa de enlace de datos de las redes a las que el remitente y el receptor están conectados directamente. Los remitentes 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 del MSS también puede denominarse negociación del MSS pero, estrictamente hablando, el MSS no se negocia . Se permiten dos valores de MSS completamente independientes para las dos direcciones del flujo de datos en una conexión TCP, [44] [9] por lo que no es necesario acordar una configuración de MSS común para una conexión bidireccional.
Depender únicamente del esquema de reconocimiento acumulativo empleado por el TCP original puede generar ineficiencias cuando se pierden paquetes. Por ejemplo, supongamos que los bytes con números de secuencia del 1000 al 10999 se envían en 10 segmentos TCP diferentes del mismo tamaño y el segundo segmento (números de secuencia del 2000 al 2999) se pierde durante la transmisión. En un protocolo de acuse de recibo acumulativo puro, el receptor solo puede enviar un valor de 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ó los bytes 3000 a 10999 con éxito. Por lo tanto, es posible que el remitente tenga que reenviar todos los datos que comiencen con el número de secuencia 2000.
Para aliviar 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 inmediatamente posterior al último número de secuencia del último byte contiguo recibido sucesivamente, como en el acuse de recibo TCP básico. El acuse de recibo puede incluir varios bloques SACK , donde cada bloque SACK es transmitido por el borde izquierdo del bloque (el primer número de secuencia del bloque) y el borde derecho del bloque (el número de secuencia que sigue inmediatamente al último número de secuencia del bloque). ), siendo un Bloque un rango contiguo que el receptor recibió correctamente. En el ejemplo anterior, el receptor enviaría un segmento ACK con un valor ACK acumulativo de 2000 y un encabezado de opción SACK con números de secuencia 3000 y 11000. En consecuencia, el remitente retransmitiría sólo el segundo segmento con los números de secuencia del 2.000 al 2.999.
Un remitente TCP puede interpretar la entrega de un segmento desordenado como un segmento perdido. Si lo hace, el remitente TCP retransmitirá el segmento anterior al paquete desordenado y reducirá la velocidad de entrega de datos para esa conexión. La opción duplicar-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 perdió ningún segmento y el remitente TCP puede restablecer la velocidad de transmisión más alta.
La opción SACK no es obligatoria y entra en funcionamiento sólo si ambas partes la apoyan. Esto se negocia cuando se establece una conexión. SACK utiliza una opción de encabezado TCP (consulte § Estructura del segmento TCP para obtener más detalles). El uso de SACK se ha generalizado: todas las pilas TCP populares lo admiten. El reconocimiento selectivo también se utiliza en el protocolo de transmisión de control de flujo (SCTP).
Los acuses de recibo selectivos pueden "renegarse", donde el receptor descarta unilateralmente los datos reconocidos selectivamente. RFC 2018 desalentó este comportamiento, pero no prohibió permitir a los receptores la opción de incumplir si, por ejemplo, se quedaban sin espacio en el buffer. [45] La posibilidad de incumplir conduce a una complejidad de implementación tanto para los remitentes como para los receptores, y también impone costos de memoria al remitente. [46]
Para un uso más eficiente de las redes de gran ancho de banda, se puede utilizar un tamaño de ventana TCP mayor. Un campo de tamaño de ventana TCP de 16 bits controla el flujo de datos y su valor está limitado a 65.535 bytes. Dado que el campo de tamaño no se puede ampliar más allá de este límite, se utiliza un factor de escala. La opción de escala de ventana TCP , tal como se define en RFC 1323, es una opción que se utiliza para aumentar el tamaño máximo de la ventana a 1 gigabyte. Es necesario ampliar a estos tamaños de ventana más grandes para el ajuste de TCP .
La opción de escala de ventana se utiliza sólo durante el protocolo de enlace de tres vías TCP. El valor de escala de la ventana representa el número de bits para desplazar hacia la izquierda el campo de tamaño de ventana de 16 bits al interpretarlo. El valor de escala de la ventana se puede configurar de 0 (sin desplazamiento) a 14 para cada dirección de forma independiente. Ambos lados deben enviar la opción en sus segmentos SYN para permitir el escalado de la ventana en cualquier dirección.
Algunos enrutadores y firewalls de paquetes reescriben el factor de escala de la ventana durante una transmisión. Esto hace que los lados emisor y receptor asuman diferentes tamaños de ventana TCP. El resultado es un tráfico inestable que puede ser muy lento. El problema es visible en algunos sitios detrás de un enrutador defectuoso. [47]
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 con algún valor aleatorio. Muchos sistemas operativos incrementarán la marca de tiempo por cada milisegundo transcurrido; sin embargo, el RFC sólo establece que los ticks deben ser proporcionales.
Hay dos campos de marca de tiempo:
Las marcas de tiempo TCP se utilizan en un algoritmo conocido como Protección contra números de secuencia envueltos o PAWS . PAWS se utiliza cuando la ventana de recepción cruza el límite envolvente del número de secuencia. En el caso de que un paquete haya sido potencialmente retransmitido, responde a la pregunta: "¿Este número de secuencia está en los primeros 4 GB o en el segundo?" Y la marca de tiempo se utiliza para romper el empate.
Además, el algoritmo de detección de Eifel utiliza marcas de tiempo TCP para determinar si las retransmisiones se producen porque los paquetes se pierden o simplemente están fuera de orden. [48]
Las marcas de tiempo TCP están habilitadas de forma predeterminada en Linux [49] y deshabilitadas de forma predeterminada en Windows Server 2008, 2012 y 2016. [50]
Estadísticas recientes muestran que el nivel de adopción de marcas de tiempo TCP se ha estancado, en ~40%, debido a que Windows Server dejó de ser compatible desde Windows Server 2008. [51]
Es posible interrumpir o cancelar la transmisión en cola en lugar de esperar a que finalice. Esto se hace especificando los datos como urgentes . Esto marca la transmisión como datos fuera de banda (OOB) y le indica al programa receptor que los procese inmediatamente. Cuando termina, TCP informa a la aplicación y reanuda la cola de transmisión. Un ejemplo es cuando se utiliza TCP para una sesión de inicio de sesión remota donde el usuario puede enviar una secuencia de teclado que interrumpe o aborta el programa que se ejecuta de forma remota sin esperar a que el programa finalice su transferencia actual. [6]
El puntero urgente sólo altera el procesamiento en el host remoto y no acelera ningún procesamiento en la red misma. La capacidad se implementa de manera diferente o deficiente en diferentes sistemas o puede que no sea compatible. Cuando esté disponible, es prudente asumir que sólo se manejarán de manera confiable solo bytes individuales de datos OOB. [52] [53] Dado que la función no se utiliza con frecuencia, no se ha probado bien en algunas plataformas y se ha asociado con vulnerabilidades , como WinNuke , por ejemplo.
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 la transferencia de un archivo. Por ejemplo, un bloque de envío típico sería de 4 KB, un MSS típico es 1460, por lo que salen 2 paquetes en una Ethernet de 10 Mbit/s que tardan ~1,2 ms cada uno, seguidos de un tercero que transporta los 1176 restantes después de una pausa de 197 ms porque TCP está esperando un búfer lleno. 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 resultaría muy molesto.
La configuración de la opción de socketTCP_NODELAY anula el retraso de envío predeterminado de 200 ms. Los programas de aplicación utilizan esta opción de socket para forzar el envío de resultados después de escribir un carácter o una línea de caracteres.
El RFC [ ¿cuál? ] define el PSHbit de inserción como "un mensaje a la pila TCP receptora para enviar estos datos inmediatamente a la aplicación receptora". [6] No hay forma de indicarlo o controlarlo en el espacio del usuario utilizando sockets Berkeley ; está controlado únicamente por la pila de protocolos . [54]
TCP puede ser atacado de diversas formas. Los resultados de una evaluación exhaustiva de la seguridad de TCP, junto con posibles mitigaciones para los problemas identificados, se publicaron en 2009 [55] y se llevaron a cabo dentro del IETF hasta 2012. [56] Las vulnerabilidades notables incluyen denegación de servicio, secuestro de conexión, TCP Ataque de veto y reinicio de TCP .
Al utilizar una dirección IP falsificada y enviar repetidamente paquetes SYN ensamblados intencionalmente , seguidos de muchos paquetes ACK, los atacantes pueden hacer que el servidor consuma grandes cantidades de recursos para realizar un seguimiento de las conexiones falsas. Esto se conoce como ataque de inundación SYN . Las soluciones propuestas a este problema incluyen cookies SYN y acertijos criptográficos, aunque las cookies SYN vienen con su propio conjunto de vulnerabilidades. [57] Sockstress es un ataque similar, que podría mitigarse con la gestión de recursos del sistema. [58] En la fracking #66 se analizó un ataque DoS avanzado que involucra la explotación del temporizador de persistencia de TCP . [59] Las inundaciones PUSH y ACK son otras variantes. [60]
Un atacante que pueda espiar una sesión TCP y redirigir paquetes puede secuestrar una conexión TCP. Para hacerlo, el atacante aprende el número de secuencia de la comunicación en curso y falsifica un segmento falso que se parece al siguiente segmento de la secuencia. Un simple secuestro puede provocar que un paquete sea aceptado erróneamente en un extremo. Cuando el host receptor reconoce el segmento falso, se pierde la sincronización. [61] El secuestro se puede combinar con la suplantación de ARP u otros ataques de enrutamiento que permiten a un atacante tomar el control permanente de la conexión TCP.
Suplantar una dirección IP diferente no era difícil antes del RFC 1948, cuando el número de secuencia inicial era fácilmente adivinable. Las implementaciones anteriores permitían a un atacante enviar ciegamente una secuencia de paquetes que el receptor creería que provienen de una dirección IP diferente, sin necesidad de interceptar la comunicación a través de ARP o ataques de enrutamiento: basta con asegurarse de que el host legítimo de la IP suplantada la dirección está inactiva o llevarla a esa condición mediante ataques de denegación de servicio . Esta es la razón por la que el número de secuencia inicial ahora se elige al azar.
Un atacante que pueda escuchar y predecir el tamaño del siguiente paquete que se enviará puede hacer que el receptor acepte una carga útil maliciosa sin interrumpir la conexión existente. El atacante inyecta un paquete malicioso con el número de secuencia y el tamaño de carga útil del siguiente paquete esperado. Cuando finalmente se recibe el paquete legítimo, se descubre 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 conexión, la conexión nunca se desincroniza y la comunicación continúa normalmente después de que se acepta la carga 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. La única evidencia para el receptor de que algo anda mal es un único paquete duplicado, algo normal en una red IP. El remitente del paquete vetado nunca ve ninguna evidencia de un ataque. [62]
Una conexión TCP se identifica mediante una cuádruple de dirección de origen, puerto de origen , dirección de destino y puerto de destino. [d] [63] [64] Los números de puerto se utilizan para identificar diferentes servicios y para permitir múltiples conexiones entre hosts. [7] TCP utiliza números de puerto de 16 bits , proporcionando 65.536 valores posibles para cada uno de los puertos de origen y destino. [10] 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 múltiples tengan disponibles y las conexiones se interrumpen si cambia la dirección de un punto final. [sesenta y cinco]
Los números de puerto se clasifican en tres categorías básicas: conocidos, registrados y dinámicos o privados. Los puertos conocidos los asigna la Autoridad de Números Asignados de Internet (IANA) y normalmente los utilizan procesos a nivel de 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 suelen ser utilizados por las aplicaciones de usuario final como puertos de origen efímeros al contactar con los servidores, pero también pueden identificar servicios nombrados que han sido registrados por un tercero. Las aplicaciones de usuario final también pueden utilizar puertos dinámicos o privados; sin embargo, estos puertos normalmente no contienen ningún significado fuera de una conexión TCP en particular.
La traducción de direcciones de red (NAT) normalmente utiliza números de puerto dinámicos, en el lado público, para eliminar la ambigüedad del flujo de tráfico que pasa entre una red pública y una subred privada , permitiendo así que muchas direcciones IP (y sus puertos) en el subred que será atendida por una única dirección pública.
TCP es un protocolo complejo. Sin embargo, si bien 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 de TCP, uno de los RFC relacionados con TCP más importantes de los últimos años, que describe algoritmos actualizados que evitan una 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 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 multiruta (MPTCP) [66] [67] es un esfuerzo continuo dentro del IETF que tiene como objetivo permitir que una conexión TCP utilice múltiples rutas para maximizar el uso de recursos y aumentar la redundancia. La redundancia que ofrece Multipath TCP en el contexto de redes inalámbricas permite la utilización simultánea de diferentes redes, lo que aporta un mayor rendimiento y mejores capacidades de transferencia. TCP multiruta también aporta beneficios de rendimiento en entornos de centros de datos. [68] La implementación de referencia [69] de Multipath TCP se desarrolló en el kernel de Linux. [70] TCP multiruta se utiliza para admitir la aplicación de reconocimiento de voz Siri en iPhones, iPads y Macs. [71]
tcpcrypt es una extensión propuesta en julio de 2010 para proporcionar cifrado a nivel de transporte directamente en el propio TCP. Está diseñado para funcionar de forma transparente y no requiere ninguna configuración. A diferencia de TLS (SSL), tcpcrypt en sí no proporciona autenticación, pero proporciona primitivas simples a la aplicación para hacerlo. El RFC de tcpcrypt fue publicado por el IETF en mayo de 2019. [72]
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 adoptada ampliamente debido a problemas de seguridad. [73] TCP Fast Open se publicó como RFC 7413 en 2014. [74]
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 esté lo más cerca posible del umbral de inicio lento . [75] 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+. [76]
TCP Cookie Transactions (TCPCT) es una extensión propuesta en diciembre de 2009 [77] para proteger 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ó obsoleto en favor de TCP Fast Open . El estado del RFC original se cambió a "histórico". [78]
Una forma de superar los requisitos de potencia de procesamiento de TCP es crear implementaciones de hardware del mismo, ampliamente conocidas como motores de descarga de TCP (TOE). El principal problema de los TOE es que son difíciles de integrar en los sistemas informáticos, lo que requiere cambios importantes en el sistema operativo de la computadora o dispositivo. Una empresa que desarrolló un dispositivo de este tipo fue Alacritech.
La imagen de cable de TCP proporciona importantes oportunidades de modificación y recopilación de información a los observadores en la ruta, ya que los metadatos del protocolo se transmiten en texto sin cifrar . [79] [80] Si bien esta transparencia es útil para los operadores de red [81] y los investigadores, [82] la información recopilada a partir de los metadatos del protocolo puede reducir la privacidad del usuario final. [83] Esta visibilidad y maleabilidad de los metadatos ha hecho que TCP sea difícil de extender, un caso de osificación del protocolo , ya que cualquier nodo intermedio (un ' middlebox ') puede tomar decisiones basadas en esos metadatos o incluso modificarlos, [84] [ 85] rompiendo el principio de extremo a extremo . [86] Una medición encontró que un tercio de las rutas a través de Internet encuentran al menos un intermediario que modifica los metadatos TCP, y el 6,5% de las rutas encuentran efectos osificantes dañinos de los intermediarios. [87] Evitar los riesgos de extensibilidad de los intermediarios impuso importantes limitaciones al diseño de MPTCP , [88] [89] y las dificultades causadas por los intermediarios han obstaculizado la implementación de TCP Fast Open en los navegadores web . [90] Otra fuente de osificación es la dificultad de modificación de las funciones TCP en los puntos finales, generalmente en el núcleo del sistema operativo [91] o en el hardware con un motor de descarga TCP . [92]
Como TCP proporciona a las aplicaciones la abstracción de un flujo de bytes confiable , puede sufrir un bloqueo de cabecera de línea : si los paquetes se reordenan o se pierden y necesitan ser retransmitidos (y por lo tanto llegan desordenados), los datos de forma secuencial posterior partes del flujo pueden recibirse antes que partes secuencialmente anteriores del flujo; sin embargo, los datos posteriores normalmente no se pueden utilizar hasta que se hayan recibido los datos anteriores, lo que genera latencia en la red . Si se encapsulan y multiplexan varios mensajes independientes de nivel superior en una única conexión TCP, el bloqueo de cabecera de línea puede hacer que el procesamiento de un mensaje completamente recibido que se envió más tarde espere la entrega de un mensaje que se envió anteriormente. [93] Los navegadores web intentan mitigar el bloqueo de cabecera de línea abriendo múltiples conexiones paralelas. Esto genera repetidamente el costo del establecimiento de la conexión, además de multiplicar los recursos necesarios para rastrear esas conexiones en los puntos finales. [94] Las conexiones paralelas también tienen control de congestión que opera independientemente unas de otras, en lugar de poder agrupar información y responder más rápidamente a las condiciones observadas de la red; [95] 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 recursos por parte de aplicaciones que adoptan este enfoque. [96]
El establecimiento de la conexión es un factor importante que contribuye a la latencia según la experimentan los usuarios de la Web. [97] [98] 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. [98] Para flujos cortos, estos retrasos son muy significativos. [99] Transport Layer Security (TLS) requiere un protocolo de enlace propio 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 se realizan en serie: el protocolo de enlace TLS no puede comenzar hasta que el protocolo de enlace TCP haya concluido. [100] Se requieren dos RTT para el establecimiento de conexión con TLS 1.3 sobre TCP. [101] TLS 1.3 permite la reanudación de la conexión RTT cero 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 apretones de manos de RTT cero también presentan desafíos criptográficos, ya que el intercambio de claves no interactivo eficiente, seguro para la reproducción y seguro hacia adelante es un tema de investigación abierto. [102] 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. [103] Sin embargo, TCP Fast Open ha sido difícil de implementar debido a la osificación del protocolo; en 2020, ningún navegador web lo utilizó de forma predeterminada. [90]
El rendimiento de TCP se ve afectado por la reordenación de paquetes . Los paquetes reordenados pueden provocar el envío de acuses de recibo duplicados que, si cruzan el umbral, desencadenarán una retransmisión espuria y un control de congestión. El comportamiento de transmisión también puede volverse menos fluido y más ráfaga, ya que los rangos grandes se reconocen todos a la vez cuando se recibe un paquete reordenado al inicio del rango (de manera similar a cómo el bloqueo de cabecera de línea afecta a las aplicaciones). [104] Blanton y Allman (2002) descubrieron que el rendimiento estaba inversamente relacionado con la cantidad de reordenamiento, hasta un límite en el que todo reordenamiento desencadena una retransmisión espuria. [105] 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 resolver la ambigüedad de la retransmisión. [106] La reducción de las retransmisiones espurias inducidas por la reordenación compensa una recuperación rápida de una pérdida genuina. [107]
El reconocimiento selectivo puede proporcionar un beneficio significativo al rendimiento; Bruyeron, Hemon y Zhang (1998) midieron ganancias de hasta el 45%. [108] Un factor importante en la mejora es que el reconocimiento selectivo puede evitar con mayor frecuencia un inicio lento después de una pérdida y, por lo tanto, puede utilizar mejor el ancho de banda disponible. [109] Sin embargo, TCP sólo puede reconocer selectivamente un máximo de tres bloques de números de secuencia. Esto puede limitar la tasa de retransmisión y, por tanto, la recuperación de pérdidas o provocar retransmisiones innecesarias, especialmente en entornos con altas pérdidas. [110] [111]
TCP fue diseñado 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, transferencias, interferencias 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 provoca que el enlace de radio esté infrautilizado. Se han realizado amplias investigaciones para combatir estos efectos nocivos. Las soluciones sugeridas se pueden clasificar como soluciones de extremo a extremo, que requieren modificaciones en el cliente o servidor, [112] 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. [112] [113]
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. [ cita necesaria ]
La idea de un acelerador TCP es terminar las conexiones TCP dentro del procesador de red y luego transmitir los datos a una segunda conexión hacia el sistema final. Los paquetes de datos que se originan en el remitente se almacenan en el nodo acelerador, que es responsable de realizar retransmisiones locales en caso de pérdida de paquetes. Así, en caso de pérdidas, el circuito de retroalimentación entre el emisor y el receptor se acorta al que existe entre el nodo de aceleración y el receptor, lo que garantiza una entrega más rápida de datos al receptor.
Dado que TCP es un protocolo de velocidad adaptable, la velocidad a la que el remitente TCP inyecta paquetes en la red es directamente proporcional a la condición de carga predominante dentro de la red, así como a la capacidad de procesamiento del receptor. El remitente juzga las condiciones predominantes dentro de la red en función de los acuses de recibo que recibe. El nodo de aceleración divide el circuito de retroalimentación entre el remitente y el receptor y así garantiza un tiempo de ida y vuelta (RTT) más corto por paquete. Un RTT más corto es beneficioso ya que garantiza un tiempo de respuesta más rápido a cualquier cambio en la red y una adaptación más rápida por parte del remitente para combatir estos cambios.
Las desventajas del método incluyen el hecho de que la sesión TCP debe dirigirse a través del acelerador; esto significa que si la ruta cambia, de modo que el acelerador ya no esté en la ruta, la conexión se interrumpirá. También destruye la propiedad de extremo a extremo del mecanismo de confirmación de TCP; Cuando el remitente recibe el ACK, el paquete ha sido almacenado por el acelerador y no entregado al receptor.
Un rastreador de paquetes , que intercepta el tráfico TCP en un enlace de red, puede resultar útil para depurar redes, pilas de red y aplicaciones que utilizan TCP al mostrarle al usuario qué paquetes pasan a través de un enlace. Algunas pilas de red admiten la opción de socket SO_DEBUG, que se puede habilitar en el socket usando setsockopt. Esa opción descarga todos los paquetes, estados TCP y eventos en ese socket, lo cual es útil en la depuración. Netstat es otra utilidad que se puede utilizar para depurar.
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 reciba la copia retransmitida del paquete perdido. Esto causa problemas para aplicaciones en tiempo real, como transmisión de medios, juegos multijugador en tiempo real y voz sobre IP (VoIP), donde generalmente es más útil obtener la mayoría de los datos de manera oportuna que obtener todos los datos. en orden.
Por motivos históricos y de rendimiento, la mayoría de las redes de área de almacenamiento (SAN) utilizan el protocolo Fibre Channel (FCP) sobre conexiones Fibre Channel .
Además, para los sistemas integrados , el arranque en red y los 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 medio.
Generalmente, cuando TCP no es adecuado, se utiliza el protocolo de datagramas de usuario (UDP). Esto proporciona la multiplexación de aplicaciones y sumas de verificación que realiza TCP, pero no maneja transmisiones ni retransmisiones, lo que brinda al desarrollador de aplicaciones la capacidad de codificarlas de una manera adecuada a la situación o reemplazarlas con otros métodos como corrección de errores directa o interpolación .
El Protocolo de transmisión de control de transmisión (SCTP) es otro protocolo que proporciona servicios confiables orientados a la transmisión similares a TCP. Es más nuevo 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 las consideraciones casi en tiempo real son importantes.
Venturi Transport Protocol (VTP) es un protocolo patentado que está diseñado para reemplazar TCP de forma transparente para superar las ineficiencias percibidas relacionadas con el transporte de datos inalámbrico.
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 no se conoce de antemano el remitente de los datos. Si el entorno es predecible, un protocolo basado en temporización como el modo de transferencia asincrónica (ATM) puede evitar la sobrecarga de retransmisiones de TCP.
El protocolo de transferencia de datos (UDT) basado en UDP tiene mejor eficiencia y equidad que TCP en redes que tienen un producto de alto retardo de ancho de banda . [114]
El Protocolo de transacciones multipropósito (MTP/IP) es un software patentado que está diseñado para lograr de manera adaptativa un alto rendimiento y rendimiento de transacciones en una amplia variedad de condiciones de red, particularmente aquellas en las que TCP se percibe como ineficiente.
Cuando TCP se ejecuta sobre IPv4 , el método utilizado para calcular la suma de comprobación se define de la siguiente manera: [9]
El campo de suma de comprobación es el complemento a unos de 16 bits de la suma en complemento a unos de todas las palabras de 16 bits en el encabezado y el texto. El cálculo de la suma de comprobación debe garantizar la alineación de 16 bits de los datos que se suman. Si un segmento contiene un número impar de octetos de encabezado y texto, la alineación se puede lograr rellenando el último octeto con ceros a su derecha para formar una palabra de 16 bits a efectos de suma de verificación. El pad no se transmite como parte del segmento. Mientras se calcula la suma de verificación, el campo de suma de verificación se reemplaza por ceros.
En otras palabras, después del relleno apropiado, todas las palabras de 16 bits se suman utilizando la aritmética en complemento a uno . Luego, la suma se complementa bit a bit y se inserta como campo de suma de verificación. En la siguiente tabla se muestra un pseudoencabezado que imita el encabezado del paquete IPv4 utilizado en el cálculo de la suma de comprobación.
Las direcciones de origen y destino son las del encabezado IPv4. El valor del protocolo es 6 para TCP (consulte Lista de números de protocolo IP ). El campo de longitud de TCP es la longitud del encabezado y los datos de TCP (medido en octetos).
Cuando TCP se ejecuta sobre IPv6 , el método utilizado para calcular la suma de comprobación cambia: [115]
Cualquier protocolo de 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 direcciones IPv6 de 128 bits en lugar de direcciones IPv4 de 32 bits.
A continuación se muestra un pseudoencabezado que imita el encabezado IPv6 para el cálculo de la suma de comprobación.
Muchas implementaciones de pila de software TCP/IP brindan opciones para usar 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 aliviar al sistema operativo del uso de valiosos ciclos de CPU para calcular la suma de comprobación. Por lo tanto, aumenta el rendimiento general de la red.
Esta característica puede hacer que los analizadores de paquetes que desconocen o no están seguros del uso de la descarga de suma de verificación informen sumas de verificación no válidas en paquetes salientes que aún no han llegado al adaptador de red. [116] Esto solo ocurrirá para paquetes que sean 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. [117] Este problema también puede ocurrir cuando se monitorean 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 optimización), sabiendo que la suma de verificación será calculada más adelante por el núcleo del host de la VM. o su hardware físico.
{{cite book}}: CS1 maint: location missing publisher (link){{cite book}}: |journal=ignorado ( ayuda ){{cite web}}: CS1 maint: bot: original URL status unknown (link){{cite book}}: |journal=ignorado ( ayuda )Wireshark captura paquetes antes de enviarlos al adaptador de red.
No verá la suma de verificación correcta porque aún no se ha calculado.
Peor aún, la mayoría de los sistemas operativos no se molestan en inicializar estos datos, por lo que probablemente veas pequeños fragmentos de memoria que no deberías.
Las nuevas instalaciones de Wireshark 1.2 y superiores deshabilitan la validación de suma de comprobación de IP, TCP y UDP de forma predeterminada.
Puede desactivar la validación de la suma de comprobación en cada uno de esos disectores manualmente si es necesario.
La descarga de sumas de verificación a menudo causa confusión ya que los paquetes de red que se transmitirán se entregan a Wireshark antes de que se calculen realmente las sumas de verificación.
Wireshark obtiene estas sumas de verificación "vacías" y las muestra como no válidas, aunque los paquetes contendrán sumas de verificación válidas cuando abandonen el hardware de la red más adelante.
