A veces, mi cliente no puede comunicarse con mi servidor. Cuando sucede, entonces en mi servidor, puedo manualmente pingel cliente y ahora el cliente puede ver el servidor.
Mi pregunta:¿Qué se puede hacer para solucionarlo sin utilizar ping?
Realmente espero que puedas ayudar a arrojar luz sobre este problema esporádico. En un mal día pasa hasta 5 veces. En un buen día tal vez 1 vez. En un día realmente bueno no hay problemas, pero es raro.
Estoy desarrollando en mi proyecto de tiempo libre que es una aplicación para iOS con un servidor C++. Esto se hará de código abierto en algún momento.
Acerca de mi configuración
Tanto el servidor como el cliente están en el mismo wifi.
Ambos dispositivos pueden abrirse www.google.comen un navegador, por lo que tienen acceso a Internet.
Servidor
macOS version 10.11.6 - El Capitan
NGINX version 1.10.0
IP address: 192.168.0.13 (proxy disabled)
The server is not connected to the router via cable.
The NGINX server is running on port 12345 and controls a FastCGI script.
enlace a miConfiguración NGINXynombre de host,ifconfig,resolv.
Cliente
iPad Pro (I'm also experiencing the same problem with my iPhone)
iOS 9.3.5 (13G36)
IP address: 192.168.0.18 (proxy disabled)
The client is not connected to the server via cable.
Enrutador
Netgear CG3000, hardware version 1.04, software version 3.9.21.13.mp3.V1.32.02
I'm experiencing the same problem with other routers, can't remember which ones.
No se escribe nada en el registro de eventos del enrutador.
pasos para reproducir
Sigo estos pasos.
Paso 1: el cliente no puede comunicarse con el servidor
Sobre el cliente:
En un navegador escribo la IP y el puerto del servidor: http://192.168.0.13:12345/status
Pero no pasa nada. El cliente no puede llegar al servidor.
El cliente puede acceder a Internet sin problemas.
Paso 2: Cliente haciendo ping al servidor: hace que todo funcione
En el servidor:
Yo pingel cliente por su dirección IP, así
PROMPT> ping 192.168.0.18
PING 192.168.0.18 (192.168.0.18): 56 data bytes
64 bytes from 192.168.0.18: icmp_seq=0 ttl=64 time=102.210 ms
64 bytes from 192.168.0.18: icmp_seq=1 ttl=64 time=102.966 ms
64 bytes from 192.168.0.18: icmp_seq=2 ttl=64 time=21.176 ms
^C
--- 192.168.0.18 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 21.176/75.451/102.966/38.379 ms
PROMPT>
Este pingcomando hace que el cliente pueda comunicarse con el servidor. ¿Por qué pinglo hace funcionar?
Paso 3: el cliente ahora puede acceder al servidor
Sobre el cliente:
En un navegador escribo la IP y el puerto del servidor: http://192.168.0.13:12345/status
ahora recibo una respuesta del servidor. Funciona.
Si inicio un proxy e intercepto el tráfico, entonces la solicitud/respuesta se ve así:
pedido
GET /status HTTP/1.1
Host: 192.168.0.13:12345
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPad; CPU OS 9_3_5 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13G36 Safari/601.1
Accept-Language: da-dk
Cache-Control: max-age=0
Connection: keep-alive
respuesta
HTTP/1.1 200 OK
Server: nginx/1.10.0
Date: Sun, 04 Sep 2016 16:11:39 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
{
"request_index": 1047,
"time": "1473005499"
}
Respuesta1
ping realiza una solicitud ARP, que de repente corrige su enrutamiento. Actualizará su tabla ARP con la dirección MAC y la IP del servidor o cliente.
Parece que puede tener un conflicto de IP en su red.
Una forma de solucionarlo:
cuando ocurra el problema, emita un
arp -apara imprimir la tabla ARP. Luego guarde una copia de ese listado.elimine la entrada para la IP del servidor (o cliente) emitiendo:
arp -d ipaddress-of-server-or-clienthacer ping al servidor (o cliente)
emita un
arp -acomando nuevamente y verifique qué dirección MAC se muestra ahora para esa IP.si es diferente, tienes un conflicto de IP en alguna parte.
Aquí hay un repaso sobre ARP:https://www.tummy.com/articles/networking-basics-how-arp-works/