linux - conexiones - close_wait que significa
Las conexiones de Tcp dependen del estado de CLOSE_WAIT (3)
El cliente cierra el socket primero, cuando no hay muchos datos del servidor, el cierre de la conexión tcp está bien, como:
FIN -->
<-- ACK
<-- FIN, ACK
ACK -->
Cuando el servidor está ocupado enviando datos:
FIN -->
<-- ACK,PSH
RST -->
Y la conexión del servidor pasa al estado CLOSE_WAIT y se queda allí durante mucho tiempo.
¿Cuál es el problema aquí? relacionado con el cliente o relacionado al servidor? Esto sucede en Redhat5 para enchufes locales.
Este artículo habla de por qué se envía "RST", pero no sé por qué la conexión del servidor se atascó en CLOSE_WAIT y no envía un FIN.
[EDITAR] Ignore la información más importante, esto sucede en la emulación de red slirp de qemu. Parece ser un problema de error de deslizamiento para tratar con una conexión cercana.
Este es un defecto conocido para qemu.
Esto significa que quedan datos no leídos en la transmisión, que el cliente no ha terminado de leer.
Puede forzarlo utilizando la opción SO_LINGER
. Aquí hay documentación relevante para Linux (también vea la opción en sí, aquí ), y [aquí está la función correspondiente2] para Win32.
Es el lado del servidor el que permanece abierto, por lo que en el lado del servidor puede intentar deshabilitar SO_LINGER
.
Puede significar que el servidor no ha cerrado el socket. Puede decir esto fácilmente usando "lsof" para listar los descriptores de archivo abiertos por ese proceso que incluirá sockets TCP. La solución es hacer que el proceso cierre siempre el socket cuando esté terminado (incluso en casos de error, etc.)