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?
fuente
Respuestas:
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.
Siempre lo he pensado de esta manera:
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 OK
despué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:
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.
fuente
recv()
al socket, en cuyo caso los datos recibidos permanecerían en el buffer de recepción del socket TCP indefinidamente.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.
fuente
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.
fuente