Enviarlo de forma fiable: TCP
¿Y si una carta enviada pierde una hoja por el camino, o una hoja posterior llega primero? Los paquetes en internet también lo hacen. Algunos se pierden, otros llegan desordenados. El mensaje llega intacto gracias a TCP.
Completo y exacto
Como vimos la lección pasada,
los datos se vuelven piezas pequeñas, paquetes,
y cada uno cruza por su propia ruta.
Pero la ruta no es perfecta.
Una pieza puede caerse por el camino,
una pieza posterior puede llegar primero.
Aun así, el receptor debe recibirlo
sin que falte nada y en orden.
La promesa que se encarga de esto es TCP.
Toca las dos cosas que TCP promete. Nada perdido, y en orden.
El objetivo ya está claro.
Completo, y en orden.
Fácil de decir,
pero no fácil cuando la ruta es imperfecta.
TCP lo resuelve con
tres pequeños hábitos.
Avisar que llegó,
reenviar lo que no llegó,
ordenar las cosas por su número.
Sigámoslos uno por uno.
Avisa que llegó
El primer hábito es acusar recibo.
Cada vez que llega una pieza, el receptor
responde breve: "recibido".
Esta respuesta se llama acuse de recibo, ACK.
Es igual que pulsar "recibido"
cuando llega un paquete.
El emisor solo sabe que una pieza llegó bien
cuando vuelve su ACK.
Sin ACK, el emisor todavía no lo sabe.
Toca un paquete que llegó para devolver un 'recibido' (ACK). Cuando vuelve el ACK, el emisor se queda tranquilo.
Con un ACK por cada pieza,
el emisor sabe qué llegó.
Va y vuelve un mensaje más,
así que puede parecer algo más lento.
Pero gracias a esta palabra
puedes señalar la pieza que falta.
Entonces, ¿y la pieza
cuyo ACK nunca llegó?
La respuesta es simple. Enviarla otra vez.
Si no responde, reenvía
El segundo hábito es la retransmisión.
Si el emisor espera un buen rato
y el ACK de alguna pieza nunca llega,
piensa: "ah, esa se cayó por el camino",
y envía esa misma pieza otra vez.
El receptor recibe la pieza reenviada
y esta vez devuelve un ACK.
Rellenando así la pieza que falta,
al final no queda nada fuera.
Toca una pieza cuyo ACK nunca volvió para reenviarla. Cuando llega la pieza reenviada, el hueco se rellena.
Gracias a la retransmisión,
ya no falta ninguna pieza.
Ahora en manos del receptor
se han reunido todas las piezas.
Pero queda una cosa.
Las piezas cruzaron por rutas distintas,
así que el orden en que llegaron está revuelto.
A veces la pieza 5 llega antes que la 2.
¿Cómo enderezamos este orden?
Ordénalos por número
El tercer hábito es reordenar.
TCP envía cada pieza con un número.
Número 1, número 2, número 3.
El orden de llegada puede estar revuelto, no pasa nada.
El receptor mira los números
y los alinea desde el más pequeño.
Aunque llegue primero el 5,
deja libre el sitio del 2 y espera.
Una vez lleno cada número en orden,
el mensaje original vuelve tal cual.
Toca las piezas revueltas en orden de número (1, 2, 3, 4) para alinearlas. Si las pones todas, vuelve el mensaje original.
Alineadas por número,
las piezas revueltas
encajaron de vuelta en el mensaje original.
Las perdidas se recibieron de nuevo y se rellenaron,
el orden se arregló por número.
A ojos de quien recibe,
parece que ningún paquete se perdió ni se cambió.
Todo ese trabajo
lo hizo TCP, callado, por detrás.
Resumamos
Reunido en una línea, es esto.
Los paquetes pueden perderse o llegar desordenados.
TCP envía un ACK cuando llega uno,
reenvía lo que no llega (retransmisión),
y ordena las piezas por su número.
Así el receptor siempre lo recibe
completo y en orden.
Fiabilidad antes que pura velocidad: esa es la promesa de TCP.
Toca los puntos clave en orden para repasar. (perdida/revuelto → ACK al llegar → reenviar si no hay → ordenar por número)
Por seguridad, TCP
acusa recibo, reenvía y ordena.
Eso significa esperar un poco más.
Pero a veces esa espera no compensa.
Para una llamada de voz o un juego,
donde ser rápido vale más que ser perfecto,
usamos otra forma.
En la próxima lección, conozcamos una forma
que omite los acuses y solo envía rápido.