¿Cómo se da cuenta TCP del transporte confiable de datos a través de un protocolo IP poco confiable?

Esa es una muy buena pregunta. El medio a través del cual se envían los datos no siempre es confiable. TCP promete confiabilidad al asegurarse de que los datos lleguen a su destino previsto (a través de un medio no confiable).
Lo logra mediante Agradecimientos (ACK). Cuando TCP recibe datos de la capa superior (capa de aplicación), divide los datos en segmentos y agrega su propio encabezado. Este encabezado asigna un segmento único no. a esta porción de datos. Cuando el destinatario recibe esta porción, responde al remitente diciéndole la siguiente secuencia de datos que espera recibir.
Puede haber no. de razones por las cuales el remitente no recibe ACK:
1. Los datos se perdieron a mitad de camino y, por lo tanto, el destino no los recibió en absoluto.
2. Los datos estaban dañados y el destino no podía tener sentido.
3. ACK se perdió.
4. Proceso de destino cerrado sin intimidar al remitente, etc., etc.
Si el remitente no recibe este ACK dentro de un cierto intervalo (llamado intervalo de tiempo de espera), el remitente reenvía estos datos y restablece el intervalo de tiempo de espera. Sigue intentándolo hasta que se rinde después de un cierto no. de tiempos de espera. Tanto el remitente como el destino usan una secuencia inicial aleatoria única no. para este propósito. Esta secuencia no. representa el siguiente byte de datos que espera el otro lado.
El remitente también envía un ACK por cada ACK enviado por destino, para indicarle al destino que “sé que recibió los datos”. El host (remitente / cliente) no necesita enviar al paquete un paquete especial para ACK, puede complementar este ACK junto con el siguiente fragmento de segmento que se enviará.
Por otro lado, si ACK se recibe con éxito, el remitente está seguro de que el destino recibió los datos. El siguiente diagrama debería tener algún sentido ahora

Dos razones:

1) TCP tiene un mecanismo para verificar si todo lo que se transmitió al final de la transmisión se recibió al final de la recepción. Esto se debe a que mantiene un orden estricto de señales de reconocimiento / no reconocimiento (ACK / NACK) y ventanas de tiempo de espera estrictas. Sabe si sus paquetes han sido “traviesos” (perdidos) o “agradables” (recibidos)

2) TCP, a diferencia de UDP, puede volver a enviar paquetes una y otra vez si no se reciben. Si se descartan los paquetes, TCP seguirá intentando enviar los paquetes, hasta un tiempo de espera especificado. Como tal, podemos decir que TCP hizo de manera confiable todo lo que pudo para enviar esos paquetes.

TCP establece un mecanismo de reconocimiento. En cada paquete recibido, el receptor reconoce el número de BYTES (no paquetes) recibidos correctamente (incluido el orden correcto) en la respuesta al remitente. Si el remitente recibe dos acuses de recibo consecutivos con el mismo número de reconocimiento, la conclusión es que un paquete se perdió y se reenvió.

Como respuesta simple, la confiabilidad de TCP se basa en la retransmisión de paquetes perdidos y el reensamblaje de paquetes mal ordenados

TCP utiliza acuses de recibo y temporizadores para verificar si los datos se entregan o no.