el reconocimiento por parte de TCP no garantiza que los datos hayan sido entregados

11

En RFC 793 hay una parte sobre el reconocimiento de segmentos TCP:

Cuando el TCP transmite un segmento que contiene datos, coloca una copia en una cola de retransmisión e inicia un temporizador; cuando se recibe el acuse de recibo de esos datos, el segmento se elimina de la cola. Si el acuse de recibo no se recibe antes de que se agote el temporizador, el segmento se retransmite.

Un reconocimiento por parte de TCP no garantiza que los datos se hayan entregado al usuario final , sino solo que el TCP receptor ha asumido la responsabilidad de hacerlo.

Ahora, esto es interesante. En nuestro NOC, a menudo solucionamos problemas de conectividad entre nuestra red y la red del cliente externo y cada vez que detectamos el tráfico en un firewall y vemos los bits SYN y ACK enviados y recibidos en ambas direcciones, asumimos que la conectividad está establecida y que el problema no tiene nada que ver. hacer con la red.

Pero ahora este RFC me hizo pensar: ¿qué más debería comprobar (sin configurar Wireshark) si se establece la conexión TCP pero los usuarios aún experimentan problemas de conectividad?

— kamokoba
fuente

55

Lo que significa esta oración es simplemente el significado literal en inglés de la oración: el hecho de que el controlador de red recibió los datos (y reconoció la recepción) no garantiza que el usuario final reciba los datos. Podría haber un error en el servidor web, por ejemplo. Con respecto a su pregunta de cierre: la única forma de determinar si el usuario final recibió los datos es llamarlos y preguntarles.

— Jörg W Mittag

24

Esta parte del RFC se trata de pasar la responsabilidad al sistema operativo o lo que sea la siguiente etapa del proceso. Se trata fundamentalmente de la separación de capas.

Un reconocimiento por parte de TCP no garantiza que los datos se hayan entregado al usuario final, sino solo que el TCP receptor ha asumido la responsabilidad de hacerlo.

Siempre lo he pensado de esta manera:

El sistema operativo podría bloquearse entre el envío del ACK y los datos que llegan al proceso del cliente ("cliente" aquí significa cliente del sistema operativo, no "cliente de red")
El proceso del cliente puede ser defectuoso o bloqueado, o simplemente mucho más lento de lo previsto para tratar con sus datos entrantes, o de hecho solo leerlo en circunstancias no obvias
Si el cliente envía los datos en adelante, tal vez a un archivo de disco, es posible que el archivo aún no se haya escrito o vaciado
Si el cliente envía los datos en adelante por TCP, es posible que el lado lejano TCP no haya transmitido los datos, no haya recibido un ACK o el proceso lejano haya consumido los datos con éxito

Todo lo que dice es que este es un reconocimiento de capa 3 ("escucho sus bytes") no un reconocimiento de capa superior . Considere, por ejemplo, la diferencia entre el TCP ACK, el SMTP 250 OKdespués de que la pasarela de correo del siguiente salto acepte un mensaje, un mensaje de recepción de mensaje (por ejemplo, según RFC 3798 ), un píxel de seguimiento de mensaje abierto, una nota de agradecimiento de un PA, y una respuesta que dice "Sí, lo haré".

Otro ejemplo concreto sería una impresora:

Debe ACEPTAR los datos antes de saber lo que contiene (puede ser un archivo PostScript que comience con una biblioteca incluida más grande que la ventana de transmisión TCP)
Puede contener una consulta de estado ("¿tiene papel?", Que obviamente puede ejecutar)
Puede contener un comando de impresión ("imprima esto", que podría fallar si no tiene papel)

Sugeriría que si los usuarios ven y envían ACK pero aún experimentan problemas de conectividad, es mucho más probable que haya problemas de congestión, sistema operativo o aplicaciones que cualquier cosa estrictamente relacionada con la red.

Para diagnosticar, sugiero buscar retransmisiones, en lugar de los ACK específicamente.

— jonathanjo
fuente

Otro elemento de viñeta: incluso si el proceso del cliente funciona bien, es posible que todavía no haya leído los datos.

— Barmar

1

El proceso del cliente (si se siente perezoso o perverso) podría simplemente nunca llamar recv()al socket, en cuyo caso los datos recibidos permanecerían en el buffer de recepción del socket TCP indefinidamente.

— Jeremy Friesner

Gracias a ambos, actualizado para sugerir que el proceso del cliente puede ser lento, con errores, voluble.

— jonathanjo

No puede confiar en ACK para asegurarse de que la aplicación procesó su entrada, debe implementar una capa de aplicación ACK o Check. Para poner esto en otro contexto. Para las redes de control industrial que usan TSN con una pila de IP en el lado del cliente, el ACK de TCP no es suficiente para garantizar que las variables de proceso se enganchen. Es decir, no puede confiar en TCP ACK para poner el sistema en un estado seguro o de servicio, debe tener un reconocimiento de un servicio de capa de aplicación de que es seguro meter la mano en la máquina.

— crasic

10

Desde la perspectiva de RFC, el "usuario final" es la aplicación. No hay garantía de que la aplicación haya recibido los datos, solo que el proceso TCP los recibió.

Desde su perspectiva NOC, la red está funcionando y los datos llegaron al host final. Presumiblemente, eso es todo lo que te importa.

— Ron Trunk
fuente

0

Podrías verlo de esta manera.

Usted es M.Smith y desea enviar una carta a M.Toto (las personas son la capa de aplicación).

Para enviar la carta, vaya a su oficina de correos local A, que enviará la carta a M.Toto, la oficina de correos local B (las oficinas de correos son la capa TCP).

Todo podría funcionar bien entre usted, la oficina de correos A y la oficina de correos B - B enviarán un ACK a la oficina de correos A. Pero nada garantiza que la carta llegue a M.Toto. Cualquier cosa podría pasar entre la oficina de correos B y M.Toto.

Eso es básicamente lo que dice RFC.

— toto
fuente