
Иногда мой клиент не может добраться до моего сервера. Когда это происходит, то на моем сервере я могу вручную подключить ping
клиента и теперь клиент может видеть сервер.
Мой вопрос:Что можно сделать, чтобы исправить это, не используя ping
?
Я очень надеюсь, что вы сможете помочь пролить свет на эту спорадическую проблему. В плохой день это случается до 5 раз. В хороший день, может быть, 1 раз. В действительно хороший день проблем нет, но это редкость.
Я разрабатываю в свободное время проект, который представляет собой приложение iOS с сервером C++. В какой-то момент его должны сделать открытым исходным кодом.
О моей установке
И сервер, и клиент подключены к одному и тому же Wi-Fi.
Оба устройства могут работать www.google.com
в браузере, поэтому имеют доступ к Интернету.
Сервер
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.
Ссылка на мойКонфигурация NGINXиимя_хоста,ifconfig,resolv.
Клиент
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.
Маршрутизатор
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.
В журнал событий маршрутизатора ничего не записано.
Действия по воспроизведению
Я прохожу эти этапы.
Шаг 1: Клиент не может связаться с сервером
На клиенте:
В браузере ввожу IP сервера и порт: http://192.168.0.13:12345/status
Но ничего не происходит. Клиент не может достучаться до сервера.
Клиент может без проблем получить доступ к Интернету.
Шаг 2: Сервер пингует клиента — все работает
На сервере:
Я ping
идентифицирую клиента по его IP-адресу, вот так
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>
Эта ping
команда позволяет клиенту получить доступ к серверу. Почему ping
make это работает?
Шаг 3: Теперь клиент может подключиться к серверу.
На клиенте:
В браузере ввожу IP сервера и порт: http://192.168.0.13:12345/status
Теперь получаю ответ от сервера. Работает.
Если я запущу прокси и перехвачу трафик, то запрос/ответ будет выглядеть так:
запрос
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
ответ
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"
}
решение1
ping делает ARP-запрос, который внезапно исправляет вашу маршрутизацию. Он обновит вашу ARP-таблицу с MAC-адресом и IP-адресом сервера или клиента.
Похоже, в вашей сети возник конфликт IP-адресов.
Как это исправить:
при возникновении проблемы выполните команду
arp -a
для печати таблицы ARP. Затем сохраните копию этого листинга.удалите запись для IP-адреса сервера (или клиента), выполнив:
arp -d ipaddress-of-server-or-client
пингуйте сервер (или клиента)
введите
arp -a
команду еще раз и проверьте, какой MAC-адрес теперь отображается для этого IP-адреса.Если они отличаются, значит, где-то произошел конфликт IP-адресов.
Вот краткая информация об ARP:https://www.tummy.com/articles/networking-basics-how-arp-works/