同社は遅いwgetをしていた前に、IPv4とIPv6にもDNS要求を送信します、デフォルトのシステムのgetaddrinfoを呼び出すためにwgetを見つけ、2つだけが受信またはIPv6残業している、ダウンロードされます。
同社は、DNSのIPv6が前で、その結果、要求に応答しない使用し、各wgetの後にDNSがカトン5秒を上演する必要があり、解決策は、DNSコード出会いがIPv6ダイレクトリターン空のデータ、効果的な解決策を要求する修正することですgetaddrinfoはwgetの、スロー手続きの問題の関数を使用します。
出会いpingパケット遅いので最初、無意識のうちにそれがIPv6の問題であるべきだと思うが、私の同僚を助けるために、時間の問題を解決するために最初のパッケージカトンではなく、デフォルトの5秒で、不規則である見つけました。
Etherealのは明らかに最初のパッケージは、カトンの状態にあるのping、応答を受信した、非常に迅速に、すぐにDNSのリターンは、pingパケット要求と応答を見ました。
Etherealのは、ICMPインスタントリターンを見つけました。
しかし、時間が巨人遅い表示されている、あなたは3秒待つ必要があります。
だから、またするDNSをキャプチャするために
、DNS解決、ping応答で見つけ、IPのDNSとステップの追加は、ルックアップドメイン名を逆に、多くの時間を無駄にしました。
男はピングの設定を発見した
数字のみ出力-n。いかなる試みがされますホストアドレスのシンボリック名をルックアップするために行われていないこと。
問題は、最初のパケットの遅延を解決するために、このパラメータを使用します。
また、直接のping IPアドレスならば、私は、ルックアップDNSを逆に行くことはありません。
同社は、試験した場合、ネットワーク探索pingパケットは、多くの場合、応答を受信していないが、応答パケットキャプチャので、ローカルパケットキャプチャ解析を得るために、あります。
ICMP pingパケットがポートではないので、フィールドの内部は、メッセージが送信され、誰によって決定され、それぞれが選択プロセスの結果に対応するため、独自の監視プロセスを持っています。
要求パケットとして
応答パケットとして
発見の第二セットでは、しかし、要求パケットと応答パケットは、同じ識別フィールドが使用されていない、矛盾しているが、最後の識別フィールド推定の使用は、ファイアウォール保護処理しなかった、キャッシュへの最後のpingパケットの結果、新しいping要求に応答しました。結果は失敗につながりました。そのどこにも上のときにping。
だから、合意が明確でない場合、それは人々がキャッシングを行うべきではないことを理解しています。