¿Qué es realmente la retransmisión TCP en los paquetes TCP de Wirehark?
La primera vez que vi en “Retransmisiones TCP espurias” en Wireshark, tuve que buscar la definición de espurias en Google, ya que nunca había escuchado esa palabra antes :). Se lee “no ser lo que pretende ser; falso o falso”. Retransmisiones falsas? hmmm … interesante … comenzó a preguntarse qué significa esto realmente. Después de investigar un poco, descubrí cuáles son realmente estas misteriosas retransmisiones espurias. En Wireshark, las retransmisiones TCP se clasifican como una de tres categorías.
Términos clave:
- ¿Cuál fue el propósito original del correo electrónico?
- Cómo verificar qué puertos TCP están abiertos en su computadora
- ¿Por qué se creó el modelo OSI cuando el TCP / IP ya existía y ya se estaba utilizando?
- ¿Cuál es el significado del protocolo HTTP / 2.0?
- Cómo monitorear el ancho de banda disponible de mi conexión sin afectar una transmisión saliente
RTO – Tiempo de espera de retransmisión. Cada segmento TCP que se envía a la capa IP tiene un temporizador asociado y se debe recibir un ACK antes de que expire este temporizador. Este temporizador se ajusta dinámicamente de acuerdo con RTT y otros factores. Aquí hay una buena redacción RFC 6298 si desea obtener más información sobre cómo se calcula el RTO.
Retransmisiones TCP : estas son las retransmisiones cotidianas normales (aunque no tan normales si sucede con bastante frecuencia) en las que los paquetes enviados no son reconocidos por el receptor dentro de una ce ¿Qué significa “retransmisión espuria”?
Retransmisiones rápidas de TCP: TCP utiliza estas retransmisiones para reaccionar a PacketLoss más rápido y retransmitir los paquetes faltantes antes del RTO. Este tipo de retransmisión es menos dura en el rendimiento de TCP porque el remitente se da cuenta de que los paquetes están llegando al receptor, y que son solo caídas ocasionales de paquetes y la ruta generalmente no está congestionada.
Retransmisiones espurias de TCP : estas son las retransmisiones en las que el receptor reconoció el paquete pero no antes de que el remitente retransmita el paquete debido a un RTO. Este tipo de retransmisiones dificultará el rendimiento de TCP al igual que las retransmisiones de TCP debido a RTO. Wireshark los detecta porque ve un ACK para el paquete enviado, pero el remitente retransmite los paquetes de todos modos, por lo que wireshark ve el paquete dos veces. Por ejemplo, SEQ 2 es visto dos veces por Wireshark a pesar de que ACK 2 fue enviado.
¿Qué significa “retransmisión espuria”?
Básicamente, la “retransmisión espuria” significa que se enviaron nuevamente datos que el receptor ya había reconocido , que es algo que solíamos llamar “retransmisión innecesaria” en nuestro propio sistema experto. “Innecesario” probablemente no suena técnicamente lo suficientemente extraño, por lo que en los documentos sobre esas retransmisiones fueron etiquetados como “espurios”. Hay un informe de error en el que se mencionó el parche durante cierto tiempo (derivado de SRTT … tiempo de ida y vuelta suavizado). Esto a veces también se conoce como retransmisión de TCP debido a RTO (tiempo de espera de retransmisión). Las retransmisiones de TCP debido a RTO son peores que otras causas de retransmisiones de TCP porque, dependiendo de su implementación de TCP, el flujo puede ir a inicio lento, la ventana de congestión (cwnd) se puede reducir a la mitad y el rendimiento se ve afectado por graves penalizaciones.
