Transmission Control Protocol (TCP) is a transport layer network protocol defined in RFC 9293 that provides reliable, ordered, error-checked delivery of byte streams between applications on IP hosts through a three-way handshake and per-byte tracking. TCP is fundamental to enterprise application traffic including web, email, and database sessions, and also supports critical network services such as DNS zone transfers and large DNS responses over TCP port 53 as required by RFC 7766. Understanding TCP's connection-oriented nature, retransmission behavior, and proper firewall configuration is essential for network operators to avoid intermittent service failures and security vulnerabilities such as SYN flood attacks.
Cómo funciona el TCP
El protocolo TCP proporciona a las aplicaciones un flujo de bytes fiable sobre IP, que entrega los paquetes sin garantizar su llegada ni su orden. Lo hace estableciendo una conexión y realizando un seguimiento de cada byte enviado.
- Abrir la conexión: el cliente envía un segmento SYN con un número de secuencia inicial. El servidor responde con un SYN-ACK y el cliente contesta con un ACK. Este es el «handshake» de tres pasos.
- Transferencia de datos: cada parte divide los datos en segmentos y los numera según su posición en bytes. El receptor envía acuses de recibo que confirman el siguiente byte que espera recibir.
- Flujo de control y congestión: el receptor anuncia una ventana que limita la cantidad de datos sin confirmar que el emisor puede tener en tránsito. El emisor también reduce la velocidad cuando detecta pérdidas que sugieren congestión en la red.
- Recuperación ante pérdidas: si un acuse de recibo no llega a tiempo, o si los acuses de recibo repetidos indican una pérdida, el remitente retransmite los datos que faltan. El receptor reordena los segmentos y descarta los duplicados antes de pasar los datos a la aplicación.
- Cerrar la conexión: cada parte envía un segmento FIN cuando ha terminado de enviar, y la otra parte lo confirma. Un segmento RST interrumpe una conexión de forma inmediata.
Una suma de comprobación en cada segmento permite al receptor detectar posibles errores. El protocolo TCP transporta un flujo de bytes sin límites de mensaje, por lo que las aplicaciones deben estructurar sus propios mensajes. Debido al protocolo de establecimiento de conexión y a los acuses de recibo, el TCP añade latencia y un estado por conexión en comparación con el UDP.
Conceptos erróneos comunes sobre el TCP
Muchas personas dan por sentado que el DNS nunca utiliza TCP. El RFC 7766 exige que las implementaciones de DNS sean compatibles con TCP, y este se utiliza para respuestas truncadas, transferencias de zona y respuestas de gran tamaño. Un cortafuegos que solo permita el puerto UDP 53 puede provocar fallos intermitentes en las respuestas de gran tamaño.
TCP/IP es una familia de protocolos, no un único protocolo. IP se encarga del direccionamiento y el enrutamiento de los paquetes, mientras que TCP añade fiabilidad sobre IP. Otros protocolos de transporte, como UDP, también se ejecutan sobre IP.
La asignación de direcciones DHCP se realiza a través de los puertos UDP 67 y 68, no por TCP. Abrir un puerto TCP para los clientes DHCP no soluciona los fallos de concesión; comprueba, en su lugar, la accesibilidad a UDP y la configuración del relé.
El protocolo TCP garantiza la entrega, no una baja latencia. La pérdida de paquetes activa la retransmisión y el control de congestión, lo que puede reducir el rendimiento y añadir retraso, por lo que una sesión fiable a través de un enlace con pérdidas puede seguir pareciendo lenta.
Un protocolo de enlace TCP satisfactorio solo indica que hay algo a la escucha y que la ruta permite la conexión. La aplicación que hay detrás del puerto puede seguir fallando, por lo que una prueba de protocolo de enlace no demuestra que el servicio responda correctamente.