¿Es posible que una conexión TCP se cierre silenciosamente?

Lo siento, pero esta pregunta no tiene sentido. Si usamos TCP, es para obtener un ACKnowlegment de solicitud.

Deberías estudiar UDP.

UDP:
UDP no devuelve ACK. el receptor no puede indicar que los paquetes se han entregado con éxito. Los paquetes perdidos no se retransmiten.

UDP no inserta números de secuencia. Se espera que los paquetes lleguen como una secuencia continua o se descartan.

Lo que estás describiendo es algo que he escuchado llamado “conexiones TCP medio abiertas”. Los escritores de aplicaciones intentan evitarlos utilizando una variedad de técnicas como:

• Uso de “TCP Keepalive”, que básicamente utiliza los mensajes de segmento / ventana TCP para sondear y ver si el otro extremo todavía está activo. El uso de tiempos de espera o la recepción de mensajes ICMP (o mensajes de puerto TCP inaccesibles) son pistas utilizadas para notificar a la aplicación que la conexión TCP se ha ido.
• Uso de mensajes de “mantener vivo” específicos de la aplicación: OpenSSH también adopta este enfoque, ya que hay un protocolo codificado en el flujo TCP que se puede usar para consultar si el otro extremo de la APLICACIÓN (ssh en este caso) todavía responde.

Además de “tirar del cable”, las siguientes situaciones pueden causar una conexión TCP medio abierta:

• Un extremo del cliente es móvil (es decir, WiFi) y se mueve de una LAN a otra y obtiene una dirección IP pública diferente.
• Un cliente se va a dormir (tapa del portátil cerrada, lo que sea), y luego, cuando se despierta nuevamente, se le asigna una dirección IP diferente a través de DHCP.
• La LAN local está sobrecargada y DHCP asigna direcciones IP a diferentes dispositivos rápidamente.
• Un NAT saliente se sobrecarga y deja caer rápidamente nupcias de IP / protocolo / puerto.
• La red entre las dos particiones de punto final y las dos no pueden comunicarse entre sí Y no pueden detectar que las redes son inalcanzables. (Esta es una condición bastante patológica).

No existe una forma legal de protocolo para cerrar una conexión en silencio. Tendría que matar sin gracia el programa de máquina de estado en ambos lados de la conexión cuando se encuentre en el estado ESTABLECIDO. Como Tony Li menciona, un apagado abrupto es una forma de lograr esto.

Teóricamente, la conexión puede permanecer abierta para siempre una vez que se detengan los paquetes. Hablando en términos prácticos, después de un tiempo de espera, la aplicación de un lado de la conexión u otro cerrará la sesión TCP inactiva, enviando un FIN al otro lado. En ese punto obtendrá un ACK, FIN, un RST o nada. Si no obtiene nada, esperará en FIN_WAIT_1 hasta que expire el temporizador y obligue a cerrar la conexión.

Entonces, para pasar de ESTABLECIDO a CERRADO, siempre se enviará o recibirá un FIN al menos en algún punto del camino, dada una implementación de TCP que funcione correctamente.

Por supuesto que todo es posible. Especialmente cuando usas un programa como “scapy”. De todos modos, RFC 793 es para TCP. La “P” en TCP significa protocolo. Lo que significa que hay reglas que deben / deben seguirse.

Si bien normalmente le informaría a la otra parte que desconecte o cierre la conexión enviando paquetes fin / ack y / o primer paquete, puede optar por no informar a la otra parte. Sin embargo, aquí es donde intervienen los “keepalives”. El otro lado eventualmente destruirá la conexión por sí solo.

Por supuesto. ¿Qué sucede cuando el compañero simplemente se reinicia?

Si ambas partes no saben que la conexión está cerrada, la explicación más adecuada es que la conexión se cortó.

Sí. Si tiraste del cable.

UDP lo hace. Si tcp se cierra, envía un paquete.