時々、クライアントがサーバーにアクセスできないことがあります。その場合は、サーバー上でpingクライアントを手動で操作すると、クライアントがサーバーを認識できるようになります。
私の質問：を使用せずにこれを修正するにはどうすればよいでしょうかping?
この散発的な問題の原因を解明していただければ幸いです。ひどい日には 5 回ほど起こります。調子のよい日には 1 回程度です。本当に調子のよい日には問題はありませんが、まれです。
私は余暇のプロジェクトとして、C++ サーバーを使用した iOS アプリを開発しています。これはいずれオープンソースになる予定です。
私の設定について
サーバーとクライアントは両方とも同じ 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を送信 - 動作を開始します
サーバー上:
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これが機能するのでしょうか?
ステップ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 要求を実行し、ルーティングを突然修正します。サーバーまたはクライアントの MAC アドレスと IP で ARP テーブルを更新します。
ネットワーク上で IP 競合が発生している可能性があります。
修正方法:
問題が発生した場合は、 を発行して
arp -aARP テーブルを印刷します。次に、そのリストのコピーを保存します。次のコマンドを発行して、サーバー (またはクライアント) の IP のエントリを削除します。
arp -d ipaddress-of-server-or-clientサーバー（またはクライアント）にpingを実行する
再度コマンドを発行し
arp -a、その IP に対して現在表示されている MAC アドレスを確認します。異なる場合は、どこかで IP 競合が発生しています。
ARP についておさらいしましょう:https://www.tummy.com/articles/networking-basics-how-arp-works/