tener un problema con un proveedor que afirma que la causa del problema es un valor de "ack" no válido en los datos tcp. Estoy usando Java, así que no escribí esta capa. Utilicé snoop para capturar el tráfico en el cable y estoy usando Wirehark para mostrar los datos. Esto es lo que está pasando. Después de recibir un mensaje de paquete múltiple (5), veo una respuesta de paquete múltiple (3). El primer paquete de la respuesta tiene un valor de "ack" que es diferente al valor de "ack" de los otros dos paquetes. El proveedor afirma que estos datos son sospechosos. He proporcionado datos de muestra a continuación. No soy un experto en TCP, así que no sé si esto es un problema o no. Intenté encontrar algo sobre valores de confirmación válidos y me parece que el valor debería ser 80018, pero eso no significa que 78345 sea incorrecto. Encontré esto en la web y parece aplicarse, pero no estoy seguro: "el valor de reconocimiento de cualquier segmento de datos se considera válido siempre que no reconozca los datos antes del siguiente segmento a enviar". Gracias por tu ayuda. Según tengo entendido, el proveedor ha escrito su propia capa TCP.
tiempo de confirmación de secuencia de fuente
yo 10734 75465 190 aaaammdd 09:18:21.785757
proveedor 75465 10924 0 aaaammdd 09:18:21.789319
proveedor 75465 10924 1440 aaaammdd 09:18:34.196661
proveedor 76905 10924 1440 aaaammdd 09:18:34.196762
proveedor 78345 10924 1440 aaaammdd 09:18:34.196901
proveedor 79785 10924 233 aaaammdd 09:18:34.196915
yo 10924 78345 0 aaaammdd 09:18:34.196968
yo 10924 80018 0 aaaammdd 09:18:34.197102
yo 10924 80018 197 aaaammdd 09:18:34.579479
Respuesta1
http://en.wikipedia.org/wiki/Transmission_Control_Protocoldice
Número de acuse de recibo (32 bits): si el indicador ACK está activado, el valor de este campo es el siguiente número de secuencia que espera el receptor. Esto acusa recibo de todos los bytes anteriores (si los hubiera). El primer ACK enviado por cada extremo reconoce el número de secuencia inicial del otro extremo, pero ningún dato.
Esto sugiere que el primer paquete de respuesta acusa recibo de los primeros tres paquetes deproveedor(sec 76905 + len 1440 = 78345)
El segundo paquete de respuesta acusa recibo del cuarto y quinto paquete deproveedor(sec 79785 + len 233 = 80018)
El tercer paquete de respuesta indica que no se han recibido más datos deproveedor(mismo reconocimiento) y contiene una carga útil de 197 bytes.
Esto me parece bien.
Si sus datos son toda la conversación, el reconocimiento inicial sería incorrecto ya que debería reconocer el primer paquete deproveedorcon un reconocimiento de 75465 (seq 75465 + 1 = 75466).
Aquí hay una secuencia que capturé con Wirehark. Primero vemos el protocolo de enlace de tres vías, luego la transmisión de una solicitud de obtención HTTP seguida de una respuesta HTTP.
Banderas de origen Seq Ack Len cliente SYN 0 - 0 servidor SYN,ACK 0 1 0 cliente ACK 1 1 0 cliente - 1 1 429 Obtener ... servidor ACK 1 430 0 servidor - 1 430 1456 respuesta HTML servidor - 1457 430 1456 cliente ACK 430 2913 0 ...
La secuencia y los números de reconocimiento son relativos (al número inicial elegido aleatoriamente de cada extremo)
Usar una única conexión para una secuencia de solicitudes es una optimización común. Se agregó a HTTP en la versión 1.1 y se conoce comoconexiones persistentes. Configurar y eliminar conexiones TCP tiene un costo.
Respuesta2
Brevemente, el campo ACK se utiliza para indicar el siguiente número de secuencia que un receptor espera recibir de un remitente. Es decir, el número de secuencia del último segmento recibido + longitud de ese segmento. (Hay algunos otros usos relacionados con el manejo de pérdidas/retransmisiones, pero los dejaremos de lado por ahora).
TCP está diseñado para que se puedan reconocer múltiples segmentos en una sola respuesta. Esto permite una utilización más eficiente de los enlaces de alta latencia. VerRFC1122yRFC2581, en particular las secciones sobre acuses de recibo retrasados.
En términos de su pregunta específica: una pila TCP siempre tendrá algún nivel de entrelazado; es decir, incluso si el paquete final (sec 79785) se hubiera colocado en el búfer de recepción, es posible que no se haya procesado en el tiempo permitido antes de que se tuviera que enviar un ACK al otro extremo de la conexión. Los encabezados que ha proporcionado me parecen representar una conversación TCP completamente normal. La explicación de su proveedor parece, en el mejor de los casos, dudosa.