TCP entrega un flujo ordenado entre dos procesos
TCP, Transmission Control Protocol, es un protocolo de transporte orientado a conexión que ofrece a las aplicaciones un flujo de bytes fiable y ordenado entre dos extremos. Divide los datos en segmentos, numera posiciones, confirma lo recibido y retransmite lo que parece perdido. También regula cuánto puede enviar para no desbordar al receptor ni agravar congestión en la red. TCP no decide la ruta entre países ni garantiza que internet nunca falle: construye fiabilidad sobre el servicio de datagramas de IP.
Los extremos se identifican mediante direcciones IP y puertos. Un servidor web puede escuchar en un puerto mientras cada cliente usa otro, permitiendo múltiples conversaciones simultáneas. La aplicación ve un flujo continuo, no conserva necesariamente los límites de cada escritura. Si necesita mensajes separados, su protocolo —por ejemplo HTTP— debe indicar longitud o delimitadores.
El saludo inicial sincroniza estados
La apertura habitual usa un intercambio de tres pasos: SYN, SYN-ACK y ACK. Los extremos anuncian números de secuencia iniciales y opciones. Este saludo confirma que ambos pueden comunicarse en ese momento y prepara estructuras de estado. No autentica por sí mismo la identidad del servidor ni cifra contenido; TLS añade esas propiedades cuando una aplicación lo utiliza.
Mantener estado tiene costes. Servidores deben reservar recursos y defenderse de aperturas incompletas, como ataques SYN flood. Los sistemas usan colas, cookies SYN y límites. Una conexión TCP tampoco equivale a una sesión de usuario: si la red cambia o el proceso reinicia, la aplicación decide cómo recuperar autenticación y operación.
Los números de secuencia reconstruyen el orden
Cada byte ocupa una posición en el espacio de secuencia. El receptor confirma el siguiente byte que espera, de modo que un ACK acumulativo indica que todo lo anterior llegó. Los segmentos pueden recorrer caminos diferentes y llegar desordenados; TCP los almacena temporalmente y entrega a la aplicación en orden. Si falta un tramo, los posteriores no llenan ese hueco por sí solos.
Temporizadores y confirmaciones duplicadas permiten inferir pérdida. La retransmisión no distingue con certeza un paquete perdido de uno muy retrasado, por lo que estima el tiempo de ida y vuelta y ajusta el plazo. Opciones como SACK informan bloques recibidos y evitan repetir más datos de los necesarios. La fiabilidad nace de estos acuerdos entre extremos, no de que cada router conserve una copia.
Un ACK confirma recepción de bytes, no que la aplicación haya procesado correctamente una compra o guardado un archivo. Si el servidor confirma TCP y falla después, el cliente necesita reglas de aplicación, identificadores e idempotencia para decidir si reintenta. La fiabilidad de transporte no sustituye la consistencia del negocio.
Proteger al receptor no es lo mismo que proteger la red
El control de flujo usa la ventana anunciada por el receptor para limitar datos pendientes según su búfer. El control de congestión estima la capacidad del camino y reduce envío ante señales de saturación. Son problemas distintos: un móvil lento puede tener red despejada, y un servidor rápido puede atravesar un enlace congestionado. La cantidad efectiva se limita por la menor de ambas ventanas.
Algoritmos como slow start aumentan gradualmente la cantidad en vuelo; pérdidas o marcas explícitas pueden frenarla. Las implementaciones modernas refinan este comportamiento, y distintos flujos compiten por enlaces. TCP busca estabilidad y reparto razonable, no velocidad máxima instantánea. Un archivo grande puede tardar en acelerar aunque el ancho de banda nominal sea alto si la latencia también es grande.
IP mueve paquetes; TCP repara la conversación
El protocolo IP aporta direcciones y encaminamiento de datagramas con un servicio de mejor esfuerzo: pueden perderse, duplicarse o desordenarse. TCP vive encima, detecta esos efectos en los extremos y ofrece un flujo fiable a la aplicación. Un router intermedio normalmente examina IP para reenviar; no participa en las confirmaciones de la conexión TCP.
Esta división permite que aplicaciones compartan una infraestructura de red sin que cada router conozca sus conversaciones. También explica un fallo frecuente: si una dirección IP es alcanzable pero el puerto está cerrado, IP ha cumplido su parte y TCP no encuentra un proceso que acepte. Diagnosticar red requiere identificar la capa donde se rompe el recorrido.
Los puertos pertenecen a TCP o UDP, no a IP por sí solo. Dos protocolos pueden usar el mismo número sin compartir conexión. La arquitectura cliente-servidor muestra cómo un servicio escucha peticiones; una dirección lleva al equipo y el puerto completa la identificación del extremo de transporte.
Fiabilidad ordenada puede añadir latencia innecesaria
Videollamadas, juegos o telemetría pueden preferir datos recientes a retransmitir información vieja. UDP ofrece datagramas sin conexión y deja a la aplicación decidir qué recuperar. QUIC construye fiabilidad, seguridad y múltiples flujos sobre UDP, evitando que la pérdida en un flujo bloquee necesariamente a los demás. Elegir protocolo depende de semántica, no de declarar TCP bueno y UDP malo.
El dato memorable es que TCP no envía “archivos”: transporta bytes y no conoce páginas web, correos o fotos. Protocolos de aplicación dan significado al flujo. HTTP define mensajes web y puede usar TCP o QUIC según versión. Esta página mantiene su intención en los mecanismos de conexión, orden, retransmisión, flujo y congestión.
Cerrar una conexión también intercambia señales porque cada dirección del flujo puede terminar por separado. FIN indica que no habrá más bytes; RST aborta el estado. Conexiones que quedan medio abiertas o dispositivos que borran su seguimiento explican fallos difíciles. Mantener latidos de aplicación puede detectar inactividad, pero añade tráfico y decisiones de tiempo.
