La retransmisión TCP continúa incluso después de restablecer el indicador RST

Según tengo entendido, el indicador de restablecimiento TCP (RST) se establece cuando un segmento recibido no está destinado a la conexión actual y esto da como resultado el aborto de la sesión TCP actual. Pero la captura de wireshark pegada debajo no parece seguir esta teoría. Básicamente, el extremo A que ha iniciado RESET (cuadro n. ° 466) intenta retransmitir las tramas TCP en la misma sesión TCP y también siguió respondiendo cualquier solicitud de conexión nueva posterior [SYN] desde el extremo B con [RST, ACK] y esto el comportamiento se repite 5 veces y el de 3 vías nuevamente solo tiene éxito durante el 6to intento (cuadro # 486).La retransmisión TCP continúa incluso después de restablecer el indicador RST

464 04:35.1 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105    
465 04:35.2 enpc > 50000 [ACK] Seq=7454 Ack=31999 Win=32127 Len=0    
466 04:35.2 50000 > enpc [RST] Seq=31999 Win=0 Len=0     
467 04:35.4 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
468 04:36.1 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
469 04:37.5 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
470 04:40.3 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
471 04:45.9 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
472 04:57.1 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
473 05:17.1 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
474 05:17.1 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
475 05:17.5 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
476 05:17.5 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
477 05:18.0 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
478 05:18.0 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
479 05:19.5 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
480 05:23.2 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
481 05:23.2 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
482 05:23.7 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
483 05:23.7 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
484 05:24.2 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
485 05:24.2 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
486 05:29.7 dyniplookup > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1    
487 05:29.7 50000 > dyniplookup [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2    
488 05:29.7 dyniplookup > 50000 [ACK] Seq=1 Ack=1 Win=65536 Len=0    
489 05:29.7 dyniplookup > 50000 [PSH, ACK] Seq=1 Ack=1 Win=65536 Len=105     
490 05:29.7 50000 > dyniplookup [ACK] Seq=1 Ack=106 Win=5840 Len=0    
491 05:29.7 dyniplookup > 50000 [PSH, ACK] Seq=106 Ack=1 Win=65536 Len=105

Mi Pregunta:

Por qué extremo A mantenerse en la re-transmisión de los paquetes a través de una conexión en la RST se genera a partir de su propio fin?

Fuente

2012-02-13 amit

Quizás el iniciador que envió inicialmente ACK no esperaba ACK para otro paquete (número de secuencia diferente), por lo que envía RST y luego envía nuevamente el paquete en intervalos de tiempo crecientes hasta que el receptor devuelve el mensaje correcto (lo cual hace no, entonces el iniciador envía RST una y otra vez). Parece un problema en el canal, tal vez un cable defectuoso o una diferencia en los modos de interfaz (semidúplex frente a dúplex completo, etc.) – Alfabravo

@Alfabravo: ¿Por qué trataría de retransmitir el paquete cuando la conexión se movió al estado CERRADO una vez RST es enviado? – amit

RST no significa cerrado. RST significa "intentemos esto de nuevo". Para una conexión de cierre, la secuencia es FIN->, <-ACK, <-FIN, ACK->. Y, por lo general, RST significa "esperemos un tiempo aleatorio (creciente) para cada nuevo intento, así evitamos colisiones y cosas". – Alfabravo

Hay muchas razones por las que se puede enviar un RST. El indicador de reinicio se utiliza cuando llega un segmento TCP que no está destinado a una conexión abierta actual o puerto de escucha. Por ejemplo, si el puerto TCP está cerrado, la pila TCP en el sistema responderá con un RST.

Normalmente, cuando un sistema envía un restablecimiento de TCP, también se establece el indicador de confirmación, ya que reconoce un intento de conexión. En su caso, no hay indicador de ack, que (desde la memoria) según el RFC solo se hace cuando no hay una conexión establecida, que hay en su caso, lo que me sugeriría que es un firewall o parece un dispositivo intermediario (no es parte de la conexión TCP) que envía el restablecimiento. Por lo tanto, el servidor A legítimamente seguirá pensando que la conexión está activa.

Las tramas 467-472 son un comportamiento de retransmisión TCP estándar (desde el sistema A) con el tiempo entre intentos de conexión doblados con el servidor que finalmente parece ceder después del último intento en la trama 472. Estas tramas son retransmisiones de la trama 464, que parecería indicar que el sistema B no recibió el cuadro 465. Supongo que tomó la captura en el sistema B?

Creo sistema A solamente se trasladó a cerrado después de marco 473 fue enviado, lo que explicaría por qué entonces vemos el enlace de tres vías iniciada desde el sistema B.

Desde su rastro, es difícil decir mucho más sin más conocimiento de la red.

HTH!

Fuente

2012-05-10 13:59:49

La retransmisión TCP continúa incluso después de restablecer el indicador RST

Respuesta

Cuestiones relacionadas