El problema no es enviar segmentos, sino conservar una conversación interpretable
Cuando una aplicación dice que «envió» datos, todavía quedan varias preguntas abiertas. ¿Esos bytes entraron en el flujo TCP? ¿Qué números de secuencia los representan? ¿El receptor los aceptó dentro de su ventana? ¿El emisor recibió un reconocimiento suficiente para avanzar? ¿La aplicación receptora los leyó, o quedaron en una cola? ¿La red está perdiendo segmentos, o el receptor está anunciando poco espacio? Una captura de un paquete rara vez responde todas esas preguntas.
TCP (Transmission Control Protocol) ofrece a una aplicación un servicio orientado a conexión y de flujo de bytes fiable y ordenado. Lo hace manteniendo estado en ambos extremos, numerando el flujo, reconociendo datos, regulando cuánto puede recibir el otro extremo y reaccionando a señales de congestión. El protocolo no conserva los límites de mensajes de la aplicación, no autentica por sí mismo la identidad de las partes y no cifra el contenido. Esas propiedades pertenecen a contratos distintos.
Este capítulo construye un modelo operativo de TCP para seguridad. El objetivo no es memorizar todos los campos, sino reconstruir una conversación: estado, secuencia, ventana, temporización, cierre y punto de observación. Después usa ese modelo para separar control de flujo de control de congestión, interpretar retransmisiones sin convertirlas en prueba automática de pérdida y reconocer cómo un abuso de estado puede afectar disponibilidad. Los ejemplos son sintéticos; no autorizan tráfico contra sistemas ajenos.
Qué servicio presta TCP y qué queda fuera
TCP presenta a la aplicación una secuencia de octetos. Si una aplicación escribe tres veces "A", "BC" y "DEF", el receptor puede leer "ABCDEF" en una, dos o más operaciones. TCP no transporta tres mensajes con esos límites: transporta seis octetos en orden. Si la aplicación necesita mensajes, debe conservar fronteras en su propio protocolo, por ejemplo con longitud, delimitador o una capa de mensajes. RFC 9293, §2.2 y §3.9
La fiabilidad de TCP es una propiedad del transporte. El protocolo detecta segmentos no aceptables mediante números de secuencia y checksum, recibe reconocimientos y retransmite cuando su algoritmo determina que debe hacerlo. «Fiable» no significa que la aplicación remota haya interpretado la petición, que la operación de negocio se haya confirmado o que el dato se haya escrito en almacenamiento. Un ACK informa sobre la secuencia que el receptor espera a continuación; no es una notificación de que el proceso consumidor haya leído los bytes.
TCP usa puertos para multiplexar conversaciones y mantiene estado por conexión. El conjunto de direcciones y puertos ayuda a identificar un flujo para la pila, pero no es una identidad humana ni una autorización. Un balanceador puede terminar una conexión y abrir otra; un NAT puede traducir direcciones y puertos; un proceso puede aceptar varias conexiones. Para afirmar quién está autorizado hacen falta autenticación y autorización en la capa correspondiente.
Tampoco hay cifrado implícito en TCP. Un segmento puede viajar protegido por una capa superior como TLS, por una VPN o por otra arquitectura, pero TCP sólo entrega el flujo según su contrato. No debe atribuirse a TCP confidencialidad, autenticación criptográfica o integridad semántica de una solicitud.
Del flujo a los segmentos: secuencia y reconocimiento
El ACK avanza sólo por datos aceptados y sin hueco previo; una retransmisión no prueba por sí sola pérdida.
Un segmento TCP contiene puertos, número de secuencia, número de reconocimiento, flags, ventana, checksum, opciones y datos. El número de secuencia identifica el primer octeto de datos del segmento. Un SYN consume un número de secuencia aunque no lleve datos; por eso el primer octeto de aplicación usa el ISN (Initial Sequence Number, número de secuencia inicial) más uno. Si el segmento lleva L octetos de datos a partir de SEQ, el siguiente número esperado después de aceptarlos es SEQ + L.
Un ACK acumulativo anuncia el siguiente número de secuencia que el emisor del ACK espera recibir. Si llegan datos posteriores antes de un hueco, el receptor puede reconocer sólo hasta el primer octeto que falta. Opciones como SACK (Selective Acknowledgment) permiten aportar información adicional sobre bloques recibidos, cuando ambas implementaciones las negocian y soportan. El capítulo se concentra en la semántica acumulativa común; no debe confundirse un ACK con una confirmación de entrega a la aplicación.
Ejemplo numérico: tres mensajes de aplicación, un flujo
Supongamos que el cliente elige ISN 1000 y el servidor elige ISN 5000.
Desliza horizontalmente para consultar todas las columnas.
En el paso 4 no existe una frontera TCP entre las escrituras de la aplicación. En el paso 5 tampoco se puede concluir que el proceso servidor ya leyó los 1200 octetos. Se puede afirmar, si la captura y el estado son fiables, que el receptor TCP reconoció acumulativamente hasta 2201 y que esos octetos dejaron de estar pendientes para ese reconocimiento. La semántica de la operación depende todavía de la aplicación.
La aritmética también explica por qué un ACK no es una cuenta de segmentos. Un segmento puede llevar 1200 octetos; otro puede llevar 800. El ACK avanza por el espacio de secuencia, no por el número de paquetes. Las retransmisiones reutilizan números de secuencia ya enviados: ver dos segmentos no implica ver dos veces dos operaciones de aplicación.
Dos ventanas, dos mecanismos distintos
El emisor no debería llenar al receptor ni saturar la red. TCP mantiene, como mínimo, dos límites conceptualmente distintos:
- Ventana anunciada o de recepción (
rwnd): cuánto espacio de recepción está dispuesto a aceptar el otro extremo a partir del ACK anunciado. Es control de flujo. - Ventana de congestión (
cwnd): cuánto tráfico considera prudente mantener en vuelo según la evidencia sobre el camino. Es control de congestión.
La cantidad de datos no reconocidos que el emisor puede mantener en vuelo queda limitada por el mínimo efectivo de ambos, además de límites de la implementación y del protocolo. Si rwnd = 5840 octetos y cwnd = 2920, el emisor no debería tener más de 2920 octetos pendientes por esa conexión, aunque el receptor tenga espacio para más. Con un MSS (Maximum Segment Size, tamaño máximo de segmento) de 1460 octetos, ese límite equivale aproximadamente a dos segmentos de datos.
El control de flujo protege al receptor. Si la aplicación receptora consume despacio, su pila puede anunciar una ventana menor; el emisor debe reducir el envío aunque la red esté libre. El control de congestión protege el camino compartido. Pérdidas, ACK duplicados, señales ECN (Explicit Congestion Notification) u otras señales pueden llevar a reducir cwnd según el algoritmo usado. Un receptor con mucho espacio no demuestra que el camino tolere más tráfico.
RFC 5681 describe inicio lento, prevención de congestión, retransmisión rápida y recuperación rápida como mecanismos de control de congestión, con variables y condiciones específicas. No convierte una única receta en comportamiento idéntico de todas las implementaciones modernas: TCP permite extensiones y algoritmos complementarios. RFC 5681, §§2–4
La distinción es útil para el diagnóstico. Una ventana anunciada que cae a cero puede indicar presión en el receptor; no demuestra congestión. Una reducción de cwnd después de ACK duplicados puede ser una reacción conservadora a un posible segmento fuera de orden; no demuestra que un enlace haya descartado un paquete concreto. Para decidir, hay que correlacionar ventanas, ACK, tiempos, retransmisiones, señales ECN y estado de la aplicación.
Retransmisión, RTO y el límite de la inferencia
RFC 6298 §2.4 formula un SHOULD de mínimo de un segundo bajo sus supuestos; no es una constante universal.
TCP puede retransmitir cuando expira el RTO (Retransmission Timeout, temporizador de retransmisión), cuando recibe suficientes ACK duplicados según el algoritmo o por otras reglas de recuperación. Una retransmisión muestra que el emisor volvió a enviar un rango de secuencia; no demuestra por sí sola que el segmento original se perdiera. También son compatibles el reordenamiento, un ACK perdido, un retraso superior al esperado, procesamiento lento o un filtro que afectó una dirección del flujo.
RFC 6298 establece un cálculo de referencia para el RTO a partir de muestras de RTT (Round-Trip Time), SRTT y RTTVAR. En §2.4 recomienda (SHOULD) redondear el RTO calculado a un mínimo de un segundo bajo los supuestos del algoritmo; no es una obligación idéntica de toda implementación. Tras un timeout, el RTO se duplica antes de continuar. La implementación puede aplicar límites y evoluciones posteriores, por lo que una captura debe conservar versión y configuración. RFC 6298, §§2–5
Un cálculo sencillo muestra la escala, no una garantía sobre todos los relojes. Para la primera muestra R = 100 ms, RFC 6298 inicializa SRTT = R y RTTVAR = R/2 = 50 ms; el cálculo SRTT + max(G, 4·RTTVAR) da 100 + 200 = 300 ms. Como el algoritmo aplica un mínimo de 1 segundo, el RTO usado sería 1 s, suponiendo que no interviene otra condición. Con muestras posteriores, las actualizaciones suavizadas y el retroceso tras timeout cambian el valor.
No se debe medir el RTT de una retransmisión como si fuera una muestra ordinaria sin respetar la ambigüedad introducida por el segmento original. El emisor necesita saber qué transmisión está midiendo; el algoritmo de Karn y Partridge evita actualizar RTT con segmentos retransmitidos. Esta es una razón para no inferir «la red tardó exactamente X» de una sola línea de captura.
La fiabilidad tampoco elimina duplicados en la observación. Un capturador puede ver el original y la retransmisión; el receptor TCP elimina la duplicación usando secuencia y entrega una sola copia al flujo. Una aplicación puede procesar una petición dos veces si su protocolo de aplicación no es idempotente y la primera operación llegó pero la respuesta se perdió. TCP protege el flujo, no la semántica de reintentos de la operación.
MSS, PMTU y lo que realmente limita un segmento
El MSS anunciado en el handshake expresa el máximo de datos TCP que el receptor está dispuesto a aceptar en un segmento, bajo las condiciones de la conexión. No es el tamaño total de la trama: cabeceras TCP, IP, opciones y enlace ocupan espacio adicional. El MSS no garantiza que cada segmento tenga exactamente ese tamaño ni que el camino completo lo soporte.
La PMTU (Path Maximum Transmission Unit, unidad máxima de transmisión del camino) depende del tramo y de la versión de IP. Un cambio de túnel, encapsulación, interfaz o ruta puede reducirla. TCP puede ajustar la segmentación y las implementaciones pueden usar descubrimiento de MTU; un intermediario también puede alterar opciones o aplicar MSS clamping. No se debe presentar ese ajuste de implementación como propiedad de TCP universal.
En IPv4 pueden existir fragmentación y reensamblaje IP bajo sus reglas; en IPv6 los routers no fragmentan en tránsito y el origen usa las reglas de fragmentación de IPv6. TCP recibe el resultado que la capa IP entrega. Una captura que muestra un segmento pequeño no prueba que el MSS sea la causa del tamaño: puede ser una escritura corta, Nagle, una ventana reducida, PMTU u otra decisión local. RFC 9293, §§3.7.1–3.7.3
Estados: abrir, usar y cerrar sin inventar autenticación
Es un mapa de estados comunes, no una secuencia universal de todas las implementaciones.
Una conexión TCP es una máquina de estados. En la apertura típica, el cliente pasa de CLOSED a SYN-SENT, el servidor escucha en LISTEN, responde y pasa a SYN-RECEIVED, y ambos llegan a ESTABLISHED después del tercer segmento. El intercambio sincroniza números de secuencia y demuestra que el camino puede transportar los mensajes de ese handshake en ambas direcciones. No demuestra quién controla las direcciones, que un usuario sea legítimo ni que el servicio autorice una operación.
El handshake de tres vías evita aceptar como conexión establecida un único segmento antiguo o una comunicación donde un extremo no recibió la respuesta necesaria. Las opciones se negocian ahí: por ejemplo, MSS y, si se ofrecen y aceptan, window scaling y timestamps. RFC 7323, §§2–3 describe esas extensiones y sus condiciones de uso. Una opción ausente puede reducir capacidad o cambiar observabilidad; no debe asumirse que todas las conexiones tienen las mismas extensiones.
El cierre también es estado, no un interruptor instantáneo. Un FIN indica que el emisor no enviará más datos en esa dirección; la otra dirección puede seguir abierta durante un estado half-closed. El intercambio normal conduce por estados como FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, LAST-ACK y TIME-WAIT. Un RST aborta o rechaza según el estado y el segmento; no es equivalente a un cierre ordenado. RFC 9293, §§3.5–3.6
TIME-WAIT conserva estado después del cierre activo para evitar que segmentos antiguos se confundan con una conexión nueva y para completar obligaciones del cierre. Muchos sockets en TIME-WAIT pueden ser normales después de un patrón de clientes que abren y cierran, aunque también pueden contribuir al agotamiento de recursos según el sistema. El diagnóstico debe incluir ritmo, tuplas, puertos efímeros, límites y configuración; no basta contar estados.
Caso conductor: Quasar y una respuesta que no llega
Quasar es un servicio sintético detrás de un balanceador. El cliente abre una conexión TCP y envía una petición de 2400 octetos de aplicación. La captura del cliente muestra handshake completo, dos segmentos de datos y ACK del servidor. El log de la aplicación no contiene la petición. Antes de declarar «la aplicación perdió datos», se separan las observaciones:
- El cliente alcanzó
ESTABLISHEDy transmitió números de secuencia concretos. - El ACK del servidor cubrió el rango observado; eso es una confirmación del estado TCP remoto, no de lectura por el proceso.
- El balanceador puede haber terminado la conexión del cliente y no haber creado la conexión al origen, o puede haber rechazado el mensaje antes de registrarlo.
- El log puede estar filtrado, retrasado o usar otro identificador; la ventana temporal puede no coincidir.
La siguiente evidencia debe discriminar hipótesis: estado y cola del socket del balanceador, correlación de la conexión hacia el origen, tamaño y checksum de los segmentos, logs del terminador y del servicio, y configuración de límites. Si el servidor TCP reconoce los bytes, una captura en el cliente no demuestra que la aplicación los consumió. Si el balanceador no abrió el segundo tramo, tampoco es correcto atribuir el resultado a routing del origen.
Ahora supongamos que el cliente observa una retransmisión después de 1 segundo y luego un ACK. Hay al menos dos explicaciones compatibles: el ACK original se perdió, o el segmento original no llegó a un punto que pudiera generar el ACK. Para distinguirlas se correlacionan ambos sentidos y el punto de captura más cercano al receptor. La retransmisión prueba una decisión temporal del emisor; no adjudica por sí sola la causa física.
Observabilidad: el punto de captura cambia la pregunta
Una captura en el cliente permite observar segmentos que el capturador recibió en esa interfaz y que su filtro decodificó. Puede revelar flags, secuencia, ACK, ventana, opciones, tiempos relativos y retransmisiones visibles. No prueba que un balanceador, firewall o servidor recibiera la misma copia. Offloading, encapsulación, filtros, pérdida de captura, NAT y terminación de TCP pueden cambiar la representación.
El estado del socket aporta otra vista: puede mostrar conexión establecida, cierre, error, cola de recepción o presión de ventana según la interfaz del sistema. Tampoco equivale a un log de aplicación. La aplicación puede tener datos en una cola del kernel, leer sólo un prefijo o cerrar sin interpretar el protocolo superior.
Un firewall o balanceador puede mantener otra máquina de estados. Puede responder con RST, eliminar silenciosamente, limitar SYN, traducir la tupla o crear dos conexiones. Ver un SYN en el cliente y un estado ESTABLISHED en el origen no demuestra que sean la misma conexión. La correlación necesita extremos, puertos, versión de configuración, tiempo y un identificador de aplicación cuando exista.
Una afirmación profesional conserva esa frontera: «En el punto C, durante T, se observó una retransmisión de la secuencia S y un ACK posterior; la evidencia no distingue todavía entre pérdida del ACK, reordenamiento y pérdida del segmento en otro tramo». La ausencia de un segmento en una captura no es ausencia universal del segmento. La presencia de un ACK tampoco es confirmación de una transacción de negocio.
Agotamiento de estado y abuso del handshake
El establecimiento necesita que alguna función conserve o codifique la información necesaria para validar el ACK y crear el estado de la conexión. Una implementación tradicional reserva un TCB y una entrada SYN-RECEIVED al recibir el SYN; una SYN cookie puede codificar información en el SYN-ACK y no reservar ese estado pendiente, reconstruyéndolo cuando llega un ACK válido; un proxy puede asumir la transición en otro punto. Por eso una ráfaga de SYN puede consumir backlogs y memoria en una arquitectura, pero en otra presionar CPU, ancho de banda, validación criptográfica, tablas de seguimiento o capacidad del proxy. RFC 4987, §§2.2 y 3.6
Las defensas dependen de la arquitectura. Un sistema puede usar cookies SYN para no asignar estado SYN-RECEIVED hasta validar el ACK, ampliar o proteger backlogs, limitar tasas, filtrar en un punto anterior, distribuir terminación o separar servicios críticos. Cada control tiene costes y límites: RFC 4987 documenta restricciones y compromisos de cookies, y ninguna cookie elimina el consumo de ancho de banda ni resuelve abusos de conexiones establecidas; un rate limit puede afectar a clientes legítimos; una mitigación en el balanceador no protege un listener expuesto por otra ruta.
Un assessment defensivo debe preguntar qué recurso se agota, en qué estado, quién puede observar la presión y qué tráfico legítimo se sacrifica. El control positivo puede ser una carga sintética autorizada que alcance el umbral y active la defensa; el control negativo, tráfico normal que no debería ser limitado. La conclusión debe incluir tasa, duración, versión, topología y métricas. «Hay SYN cookies» no demuestra resiliencia universal, y «la cola se llenó» no demuestra que una aplicación haya sido comprometida.
El abuso también puede dirigirse a estados de cierre, puertos efímeros, tablas de NAT o conexiones ya establecidas. El capítulo no convierte cada mecanismo en una receta ofensiva: enseña a identificar el estado, el recurso, la precondición y el control, usando únicamente un entorno autorizado y datos sintéticos.
Pruebas positivas, negativas y de regresión
Una prueba positiva de propiedad puede verificar que un cliente autorizado establece una conexión, envía un flujo pequeño y recibe exactamente los octetos esperados en orden. El oráculo debe incluir la versión de IP, opciones negociadas, límites de tiempo, estado final y separación entre bytes entregados por TCP y mensaje aceptado por la aplicación.
Una prueba negativa puede presentar un SYN a un puerto que el diseño debe rechazar, un segmento fuera de la ventana esperada en un entorno de prueba o una ráfaga sintética que debe activar un límite de estado. No basta exigir un código o un RST: el oráculo debe nombrar si se creó estado, si el servicio legítimo siguió disponible y qué telemetría permite distinguir descarte, rate limit y fallo de backend. La prueba debe ser autorizada; nunca se usa una red de terceros para comprobar saturación.
Una regresión después de cambiar un timeout, una opción de window scaling o una defensa de SYN debe conservar el camino legítimo y el caso límite que motivó el cambio. Debe comprobar handshake, datos segmentados, cierre, conexiones simultáneas y observabilidad. Un test verde que sólo repite el handshake no demuestra que el flujo largo, el receptor lento o la ruta con PMTU menor sigan funcionando.
Los controles también deben declararse. Un control positivo de un detector de SYN flood es una señal sintética que atraviesa la misma telemetría y debe activar la detección; un control negativo es tráfico normal con características cercanas que no debe activar la alerta. Una retransmisión visible en un laboratorio no es un control positivo universal de pérdida: el fenómeno observado puede ser reordenamiento o ACK perdido.
Límites y errores frecuentes
«TCP conserva mensajes». Falso: conserva un flujo ordenado de octetos. Las fronteras requieren un protocolo de aplicación.
«ACK implica que la app consumió los datos». Falso: ACK describe el espacio de secuencia que la pila TCP acepta o espera; la aplicación puede no haber leído la cola.
«Una retransmisión prueba pérdida». No por sí sola: también son compatibles ACK perdido, reordenamiento, demora y decisiones del algoritmo.
«El handshake autentica al servidor». No: sincroniza secuencias y confirma un intercambio TCP. La autenticación requiere un mecanismo adicional.
«TCP cifra». No: cifrado y autenticación de contenido pertenecen a capas como TLS o a otra arquitectura.
«La ventana es la congestión». No: rwnd limita al receptor; cwnd representa una política de envío frente al camino.
«MSS es el tamaño del paquete». No: limita datos TCP anunciados y depende de opciones y del camino; cabeceras y encapsulación ocupan espacio adicional.
«SYN cookies resuelven el abuso». No universalmente: cambian qué estado se conserva y no eliminan ancho de banda, conexiones establecidas ni rutas alternativas.
«Un socket establecido prueba disponibilidad de la aplicación». No: el transporte puede estar establecido mientras el servicio está bloqueado, esperando datos o detrás de un intermediario.
Uso profesional: convertir estado en una conclusión acotada
Un informe debe registrar extremos y versión, dirección, puertos, estado inicial y final, opciones negociadas, MSS/PMTU relevantes, secuencias, ACK, ventanas, RTT y retransmisiones, punto de captura, reloj, intermediarios y evidencia de aplicación. La decisión debe separar:
- observación: lo que muestra la captura, el socket, el dispositivo o el log;
- inferencia: el mecanismo compatible con esas observaciones;
- impacto observado: por ejemplo, disponibilidad degradada o una respuesta no entregada;
- impacto potencial: agotamiento bajo otra tasa, afectación a otros clientes o reintentos duplicados;
- límite: qué tramo, estado, versión o consumidor no se observó.
Un claim defendible podría ser: «Entre C y el terminador G, en la versión V y durante T, se observó que dos retransmisiones de la secuencia S precedieron a un ACK acumulativo; el punto de captura no permite decidir si la causa fue pérdida del segmento, del ACK o reordenamiento en el tramo posterior». Es más útil que «la red pierde paquetes» porque permite elegir la siguiente observación.
La misma disciplina vale para disponibilidad: «La cola de SYN del terminador alcanzó el umbral configurado durante una carga sintética autorizada y la defensa activó la métrica D; no se evaluaron conexiones ya establecidas ni otra interfaz». La frase no promete que el servicio sea resistente a todo abuso. Identifica propiedad, mecanismo, evidencia y límite.
Síntesis
TCP convierte un flujo de bytes en segmentos numerados y mantiene estado para abrir, transportar y cerrar una conversación. Los números de secuencia y los ACK permiten ordenar y reconocer rangos; el rwnd limita lo que el receptor puede aceptar y el cwnd modula lo que el emisor pone en el camino; el RTO y la retransmisión recuperan ciertas condiciones sin revelar por sí solos su causa.
El handshake sincroniza estado, no identidad. Un cierre puede ser half-closed y TIME-WAIT conserva una función de seguridad de estado. MSS y PMTU limitan segmentación bajo supuestos del camino. Un punto de captura sólo observa su tramo; un ACK no certifica consumo por la aplicación; y TCP no aporta cifrado ni autorización.
El abuso profesionalmente relevante se formula como agotamiento de un recurso de estado o de capacidad, con una defensa y un coste concretos. La pregunta final no es «¿TCP es seguro?», sino: ¿qué propiedad se evaluó, entre qué extremos, bajo qué versión y qué evidencia permite distinguir transporte, intermediario, aplicación y congestión?
Comprobación de conocimiento
- Una aplicación escribe
"A","BC"y"DEF"en un socket. ¿Qué puede leer la aplicación receptora y qué propiedad debe aportar su protocolo si necesita conservar los tres mensajes? - Dados ISN cliente
1000, ISN servidor5000y un segmento de datos de 1200 octetos desdeSEQ=1001, calcula el ACK acumulativo esperado si no hay huecos. Explica por qué el ACK no implica que la aplicación haya leído los datos. - Un emisor anuncia
rwnd=5840y estimacwnd=2920, con MSS 1460. ¿Qué límite conceptual gobierna los datos en vuelo y qué mecanismo representa cada ventana? - Una captura muestra una retransmisión después de un timeout. Formula dos explicaciones compatibles con pérdida y una sin pérdida; indica qué observación las discriminaría.
- Explica qué sincroniza el handshake de tres vías y qué afirmación de identidad o autorización no permite sostener.
- Distingue MSS, tamaño total del segmento y PMTU. ¿Qué cambio de camino podría alterar la segmentación sin cambiar el protocolo de aplicación?
- Un balanceador ve
ESTABLISHEDhacia un cliente, pero el origen no registra la solicitud. Separa observaciones, hipótesis e información que pedirías antes de culpar a TCP. - Diseña una prueba positiva, una negativa y una regresión para una defensa contra agotamiento de estado TCP. Incluye controles, límites de seguridad y qué no autorizaría la evidencia.
Problema de transferencia
Una API sintética detrás de un proxy presenta picos de latencia. En el cliente se observan ACK duplicados, una reducción de cwnd y retransmisiones; el proxy registra ventanas anunciadas pequeñas y el origen no muestra errores de aplicación. Construye una matriz con observación, hipótesis alternativas, evidencia discriminante y límite para separar congestión, receptor lento, reordenamiento, pérdida de ACK y presión del proxy. Después diseña un retest seguro que compare una conexión directa de laboratorio con la ruta intermediada, conserve los números de secuencia y no convierta una retransmisión en prueba de pérdida. Explica qué conclusión seguiría siendo desconocida aunque la latencia descendiera.
Fuentes principales
- W. Eddy (ed.). RFC 9293: Transmission Control Protocol, §§2.2, 3.3–3.10, 2022. Especificación base actual de TCP; reemplaza RFC 793 y mantiene separadas las extensiones complementarias.
- M. Allman, V. Paxson y E. Blanton. RFC 5681: TCP Congestion Control, §§2–4, 2009. Algoritmos y terminología de control de congestión citados con su alcance; no se presenta como la única implementación moderna.
- V. Paxson et al. RFC 6298: Computing TCP's Retransmission Timer, §§2–5, 2011. Cálculo de referencia de RTO, muestras RTT y backoff.
- D. Borman, B. Braden, V. Jacobson y R. Scheffenegger. RFC 7323: TCP Extensions for High Performance, §§1–3, 2014. Window scaling, timestamps y protección PAWS, con negociación y límites explícitos.