2026-06-03

TCP SACK y DSACK en Wireshark: diagnosticar pérdida de paquetes, opción sack_perm y retransmisión en PCAP

Diagnosticar las opciones TCP SACK, DSACK y sack_perm en los PCAP de Wireshark. Cubre reconocimientos selectivos, recuperación de pérdida de paquetes, reordenamiento, ACK duplicados y retransmisiones espurias.

El análisis de retransmisión TCP se vuelve mucho más preciso cuando el reconocimiento selectivo está disponible. Los usuarios buscan "TCP SACK pcap", "DSACK Wireshark", "SACK duplicado", "retransmisión espuria", "reordenamiento de TCP frente a pérdida de paquetes" y "captura selectiva de paquetes ACK" cuando un seguimiento muestra ACK duplicados, retransmisiones y paquetes desordenados, pero la causa raíz no está clara.

La cirugía PCAP es útil porque la evidencia SACK se incluye en las opciones de TCP. Si elimina los paquetes incorrectos, pierde el protocolo de enlace o separa los ACK de los datos, el diagnóstico se debilita.

Lo que agrega SACK

Los ACK de TCP tradicionales reconocen el siguiente byte esperado. Si falta un segmento pero llegan segmentos posteriores, el receptor solo puede seguir confirmando el espacio.

SACK permite que el receptor diga: "Todavía me falta este rango anterior, pero he recibido estos rangos posteriores".

Esto ayuda a distinguir:

Pérdida real de paquetes.
Entrega fuera de orden.
Paquetes duplicados.
Comportamiento del receptor.
Comportamiento de recuperación del remitente.

SACK debe ser negociado

La capacidad SACK se negocia en SYN y SYN-ACK. Si la captura comienza después del protocolo de enlace, es posible que no sepa si se permitió SACK.

Conservar siempre:

SYN.
SYN-ACK.
Opción permitida SACO.
Opción de escala de ventana.
Opción de marca de tiempo si está presente.

Por este motivo, una "pequeña pcap alrededor de la retransmisión" puede resultar insuficiente.

ACK duplicados con bloques SACK

Los ACK duplicados no significan todos lo mismo. Un ACK duplicado con bloques SACK puede indicarle al remitente exactamente qué rangos de bytes posteriores llegaron.

Evidencia a inspeccionar:

Número de confirmación.
SACO borde izquierdo y borde derecho.
Bloques SACK repetidos.
Nueva información de SACO.
Si los datos faltantes aparecen más adelante.
Si la retransmisión llena el vacío.

Esto es mucho más eficaz que simplemente contar los ACK duplicados.

Pérdida de paquetes versus reordenamiento

Si un segmento llega tarde pero no se pierde, SACK puede mostrar que ya se recibieron datos posteriores. El remitente puede retransmitir y luego también puede llegar el paquete original. Eso puede parecer complicado.

Preguntas:

¿El segmento original llegó tarde?
¿Llegó primero la retransmisión?
¿DSACK informó más tarde datos duplicados?
¿Existe una ruta que reordene los paquetes?
¿Las ráfagas cruzan múltiples enlaces, túneles o rutas con equilibrio de carga?

La cirugía PCAP puede ayudar a aislar el rango de secuencia exacto y comparar el orden de los paquetes.

Qué significa DSACK

Duplicate SACK puede informar que se recibieron datos duplicados. Esto es útil para identificar retransmisiones o reordenaciones espurias.

La evidencia DSACK puede sugerir:

El remitente retransmitió innecesariamente.
La red entregó los datos originales tarde.
El punto de captura vio duplicados.
El receptor obtuvo tanto los bytes originales como los retransmitidos.
Paquetes duplicados de Middlebox.

Esa es una conclusión diferente a la de "el paquete se perdió".

Retransmisiones espurias

Una retransmisión no siempre es prueba de pérdida. Puede ser desencadenado por:

Reordering.
Comportamiento ACK retrasado.
Capture artefactos de descarga.
Tiempo de espera de retransmisión demasiado pequeño.
Compresión ACK.
Cronograma de virtualización.
Asimetría del camino.

SACK y DSACK ayudan a demostrar si realmente faltaban datos o simplemente estaban retrasados.

El punto de captura importa

Si el pcap es unilateral o está detrás de una NAT, la interpretación de SACK puede ser complicada. Un paquete puede estar ausente de su punto de captura pero presente en el receptor.

Práctica útil:

Compare capturas del lado del remitente y del lado del receptor.
Mantenga las marcas de tiempo sincronizadas.
Conservar los números de secuencia.
Evite recortar paquetes de solo ACK.
Anote la ubicación de descarga y captura.

El análisis SACK sin paquetes ACK no es análisis.

Lista de verificación de depuración

Utilice este flujo de trabajo:

Mantenga el protocolo de enlace TCP.
Confirmar SACK permitido.
Encuentre el primer ACK duplicado.
Decodifica bloques SACK.
Asigne rangos de SACK a paquetes de datos.
Identificar rangos de secuencia retransmitidos.
Compruebe si hay DSACK.
Separe la pérdida de la reordenación.
Verifique el punto de captura y descargue el contexto.
Conserve los paquetes antes/después del evento de recuperación.

Diagnóstico final

TCP SACK y DSACK proporcionan evidencia precisa de pérdida de paquetes, reordenamiento, entrega duplicada y retransmisiones espurias. La clave es preservar las opciones de protocolo de enlace, los paquetes de solo ACK, los bloques SACK y los rangos de secuencia retransmitidos.

La cirugía PCAP ayuda a mantener esa evidencia intacta para que el análisis de pérdidas de TCP pueda ir más allá de los recuentos genéricos de ACK duplicados.

Respuesta basada en paquetes para «TCP SACK y DSACK en Wireshark: diagnosticar pérdida de paquetes, opción sack_perm y retransmisión en PCAP»

La respuesta directa es que una etiqueta del analizador o un mensaje de la aplicación no determina la causa. Empieza por punto de captura y dirección; demuestra la última frontera correcta y la primera fallida. En «TCP SACK y DSACK en Wireshark: diagnosticar pérdida de paquetes, opción sack_perm y retransmisión en PCAP», otro revisor debe poder encontrar el packet, hueco o intervalo que sostiene cada frase y saber qué evidencia podría refutarla.

Situar la captura en el camino

Registra client, server y cualquier proxy, load balancer, NAT o firewall. Indica interface, lugar, reloj, sistema y direcciones visibles. Una captura junto al client demuestra lo que llegó allí, no que el server no enviara. Una junto al server demuestra salida en ese punto, no tránsito completo. Antes de comparar dos puntos corrige clock offset y alinea flow tuple, TCP sequence o transaction ID.

Comprueba calidad: snap length, dropped packets, offload, capture filter, ring buffer y hora inicial. Un checksum incorrecto en host puede ser offload artifact. Un segmento grande puede provenir de GRO/TSO y no existir así en el cable. Un packet ausente en un archivo limitado no es network loss hasta demostrar que el punto debía verlo.

Leer fronteras en orden

Frontera	Evidencia correcta	Evidencia de fallo
Link e IP	dirección, addresses y ruta coherentes	ARP/NDP ausente, ICMP, MTU, asimetría
TCP	SYN, SYN-ACK, ACK y sequence	retransmission, RST, zero window, timeout
TLS	ClientHello, ServerHello y progreso	alert o límite SNI/ALPN/certificate
Aplicación	request completo y response relacionado	status, gap o cierre temprano
Usuario	response time o failure window	stall ligado a una frontera

Detente en la primera frontera sin éxito. Si TCP no termina, no empieces por HTTP. Si request llega al proxy pero no al upstream, el límite está en proxy o su camino. Si llega al upstream sin response antes del timeout, usa ACK y progreso de bytes para separar application delay de network loss.

Separar observación e hipótesis

La observación se puede señalar: «Client envió hasta cierta sequence; sender repitió un segmento tres veces y no apareció ACK avanzado en este punto». La hipótesis es «el camino perdió el segmento». Otra captura o dropped records pueden refutarla. Para cada hipótesis escribe una prueba favorable y una contraria.

Retransmission o duplicate ACK no asigna culpable. Reordering, loss, capture artifact y receiver delay producen marcas similares. Relaciona dirección, sequence, ACK, SACK, RTT, window y tiempo de aplicación. En DNS o DHCP enlaza transaction ID, addresses e intentos; en HTTP, request y response; en TLS, dirección del handshake.

Preservar el original

Calcula checksum y conserva el original sin cambios. Filtra, recorta y redacta una working copy. Registra input, transformación, hora, packet count antes/después, checksum y motivo. Tras reescribir timestamps o eliminar packets, esa copia pierde capacidad para algunas conclusiones de tiempo o secuencia.

Sustituye addresses e identificadores de forma constante para seguir el mismo endpoint. No elimines ports, directions o lengths necesarios. Guarda aparte el mapa secreto. Revisa límites de captura y exportación y el flujo general de PCAP Surgery.

QA antes de publicar

¿Título y respuesta tratan el mismo flow? ¿Cada duración nombra reloj y puntos? ¿Está identificada la primera frontera fallida? ¿Existe explicación alternativa? ¿Se repite cambiando una variable? ¿Se conserva el original? Declara el límite: «Esta captura demuestra comportamiento junto al client durante este intervalo; no demuestra la ejecución interna del server».

Semrush no se distribuye por plantilla. El término validado PCAP analyzer pertenece solo a la página del producto; este artículo conserva su pregunta técnica y no inventa volumen ni KD.

Respuesta directa y límite de aceptación

La respuesta breve a «TCP SACK y DSACK en Wireshark: diagnosticar pérdida de paquetes, opción sack_perm y retransmisión en PCAP» es: Diagnosticar las opciones TCP SACK, DSACK y sack_perm en los PCAP de Wireshark. Cubre reconocimientos selectivos, recuperación de pérdida de paquetes, reordenamiento, ACK duplicados y retransmisiones espurias. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en PCAP Surgery.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: TCP SACK y DSACK en Wireshark: diagnosticar pérdida de paquetes, opción sackperm y retrans

Trate «TCP SACK y DSACK en Wireshark: diagnosticar pérdida de paquetes, opción sack_perm y retransmisión en PCAP» como una puerta de aceptación independiente para «TCP SACK y DSACK en Wireshark: diagnosticar pérdida de paquetes, opción sack_perm y retransmisión en PCAP». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 2: Diagnosticar las opciones TCP SACK, DSACK y sackperm en los PCAP de Wireshark. Cubre recon

Convierta «Diagnosticar las opciones TCP SACK, DSACK y sack_perm en los PCAP de Wireshark. Cubre reconocimientos selectivos, recuperación de pérdida de paquetes,» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 3: Lo que agrega SACK

Trate «Lo que agrega SACK» como una puerta de aceptación independiente para «TCP SACK y DSACK en Wireshark: diagnosticar pérdida de paquetes, opción sack_perm y retransmisión en PCAP». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 4: SACK debe ser negociado

Convierta «SACK debe ser negociado» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 5: ACK duplicados con bloques SACK

Trate «ACK duplicados con bloques SACK» como una puerta de aceptación independiente para «TCP SACK y DSACK en Wireshark: diagnosticar pérdida de paquetes, opción sack_perm y retransmisión en PCAP». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 6: Pérdida de paquetes versus reordenamiento

Convierta «Pérdida de paquetes versus reordenamiento» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 7: Qué significa DSACK

Trate «Qué significa DSACK» como una puerta de aceptación independiente para «TCP SACK y DSACK en Wireshark: diagnosticar pérdida de paquetes, opción sack_perm y retransmisión en PCAP». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 8: Retransmisiones espurias

Convierta «Retransmisiones espurias» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 9: El punto de captura importa

Trate «El punto de captura importa» como una puerta de aceptación independiente para «TCP SACK y DSACK en Wireshark: diagnosticar pérdida de paquetes, opción sack_perm y retransmisión en PCAP». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 10: Lista de verificación de depuración

Convierta «Lista de verificación de depuración» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
TCP SACK y DSACK en Wireshark: diagnosticar pérdida de paquetes, opción sackperm y retransmisión en PCAP	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Diagnosticar las opciones TCP SACK, DSACK y sackperm en los PCAP de Wireshark. Cubre reconocimientos selectivos, recuper	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Lo que agrega SACK	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
SACK debe ser negociado	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
ACK duplicados con bloques SACK	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Pérdida de paquetes versus reordenamiento	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: