Ninguna red es perfecta: los routers descartan paquetes, los enlaces inalámbricos introducen ruido y los extremos pueden saturarse. TCP incorpora algoritmos para detectar estas condiciones y recuperarse sin que la aplicación perciba fallos graves, mientras que UDP delega toda la responsabilidad al software superior.
En este tema se detalla cómo se reenvían paquetes perdidos, cómo se evitan duplicados, qué temporizadores intervienen y qué diferencias existen entre la gestión de errores de TCP y UDP.
Los incidentes más frecuentes son:
TCP enfrenta cada caso con mecanismos específicos; UDP simplemente entrega el datagrama tal como llega o lo descarta si falla la verificación.
TCP deduce una pérdida mediante dos eventos:
Estas estrategias limitan el tiempo de recuperación. Una pérdida aislada suele corregirse en milisegundos mediante fast retransmit; en cambio, una cadena de timeouts prolonga la interrupción.
El checksum TCP cubre la cabecera y los datos, además de una pseudo-cabecera con IP de origen y destino. Si el valor no coincide, el segmento se descarta sin notificar.
Los números de secuencia permiten filtrar duplicados: si llega un segmento cuyo rango ya fue recibido, el receptor lo descarta pero vuelve a enviar un ACK acumulativo para mantener la sesión sincronizada.
UDP también incorpora checksum (obligatorio en IPv6), pero no existe un mecanismo estándar para pedir retransmisión; la aplicación debe decidir si reintenta o ignora la pérdida.
TCP gestiona varios temporizadores:
Ajustar estos temporizadores es crítico: valores demasiado cortos generan retransmisiones injustificadas; demasiado largos retrasan la recuperación.
| Aspecto | TCP | UDP |
|---|---|---|
| Retransmisiones | Automáticas con temporizadores y ACK duplicados. | No existen; la aplicación debe decidir si reintenta. |
| Detección de duplicados | Secuencias y ACK acumulativos. | No se detecta; los duplicados llegan a la aplicación. |
| Checksum | Obligatorio, descarta segmentos corruptos. | Opcional en IPv4, obligatorio en IPv6. |
| Control de tiempo | RTO, persistencia, keepalive, time-wait. | Ninguno estándar. |
Las capturas en Wireshark muestran retransmissions (coloreadas en rojo) y ACK duplicados (amarillo). Además, Windows permite inspeccionar sucesos desde la consola:
Get-Counter "\TCPv4\Segments Retransmitted/sec" -SampleInterval 1 -MaxSamples 5
Get-NetTCPConnection -State Established |
Select-Object -First 5 -Property LocalPort, RemoteAddress, RetransmissionTimeout
El contador de rendimiento revela si las retransmisiones aumentan durante una ventana de tiempo.
Get-NetTCPConnection expone el RTO actual negociado por cada socket, lo que ayuda a detectar configuraciones anómalas.
El siguiente script emula un emisor que incrementa el RTO cada vez que falla una entrega y vuelve a la normalidad cuando recibe ACK:
def retransmitir(intentos, rto_inicial=0.2, factor=2):
rto = rto_inicial
for intento in range(1, intentos + 1):
print(f"Intento {intento}: envío segmento (RTO={rto:.2f}s)")
exito = intento == intentos
if exito:
print("ACK recibido, RTO vuelve al valor inicial")
rto = rto_inicial
else:
rto *= factor
print("Sin ACK, duplico RTO para evitar congestión")
return rto
retransmitir(4)Aunque simplificado, demuestra el comportamiento exponencial del RTO y el hecho de que se restablece al completar una retransmisión exitosa.
La forma en que la capa de transporte maneja errores determina la experiencia del usuario final. TCP ofrece una red virtual confiable gracias a sus mecanismos de detección y recuperación; UDP, en cambio, proporciona velocidad a costa de simplicidad. Conocer estas diferencias permite diseñar aplicaciones resilientes y diagnosticar problemas sin adivinar.