Ping

「ネットワーク接続が不安定になる」というトラブルは…残念ながら結構な頻度で発生する事象だと思います。私自身何度も様々なパターンで体験しています。 そして今日もまた…。 「ネットワーク接続が不安定」という問題は様々な要素が複合的にくみあわさって「完全につながらないわけじゃないけど、なんだか不安定」というような事が多いです。下記にかかれているものは私の経験上「よくあるもの」ではあるのですが必ずしも該当するわけでも設定変更することが必ずしも良いものでも全くありません。ですが、とりあえずパフォーマンスを犠牲にしてでも「安定」する方向の設定であることは間違いありません。一度下記を参考に「安定」方向に設定を変更してみて問題を切り分けてみるのは良いかと思います。 ドライバを最新版にする まずはNICのドライバを最新版にすることをお勧めします。この記事を見ている方はコンシューマー向けのPCを使われている方が多いと思いますので、各メーカーのドライバ更新用の専用ユーティリティーなどを利用してもらえればと思います。 ワイヤレスアダプタの省電力設定を無効化する ワイヤレスアダプタに関しては省電力の設定が存在するものがあります。とりあえず「最大パフォーマンス」で可動させるようにしましょう。 ※PC(NIC)によっては存在しない設定項目です。 NICの各種オフロード機能を無効化する NICの各種のオフロード機能は本来ハードウェアにネットワーク関連の処理を行ってもらうことによりネットワークパフォーマンスを向上させるための仕組みなのですが、場合よってうまく動作せずむしろ接続不良の原因となることがあります。一度各種オフロード機能を無効にして切り分けてみるのは多くの場合有効です。 オフロード系の機能を無効化します。どの項目が無効化していいものかわからないということもあると思いますが、項目名と現在の設定値を控えておいた上で無効化できるものは何から何まで全部無効化してまわってまず挙動の変化を確認するようなやり方を個人的にお勧めします。 MTUの引き下げ MTUはMaximum Transfer Unitの略でようはNICが送信するパケットの最大サイズに関係するものです。途中の経路で小さなパケットしか通せない部分があるにもかかわらず大きなパケットを送信することで経路の途中でパケットが破棄されてしまうような挙動が比較的多くあります。この場合通信できないわけではないのですが異様に遅い…というような挙動になります。最適なサイズを検出するような手法もありますが、まずは一度小さく設定してみて挙動を確認することをお勧めします。 これはコマンドプロンプトで設定するのが簡単です。 コマンドプロンプトを管理者として実行します。 まずはインターフェースの一覧を表示して名前や現在のMTUを確認します。 netsh interface ipv4 show subinterface 今回は「Wi-Fi」というInterfaceのMTUを1430に変更してみます。 netsh interface ipv4 set subinterface “Wi-Fi” mtu=1430 store=persistent 再度インターフェースの一覧を表示するとMTUが変更できたことが確認できます。 確認 設定を変更したら一度再起動した上で確認先のホストに継続的にping(icmp echo)を送信し応答を確認するのがお手軽です。 下記の例ではwww.google.comを宛先に設定させてもらっています。安定的に通信できている様子が見えますね。 これでもだめなら私としてはもうパケットをキャプチャしてしまってパケットレベルで処理を追うことをしてしまいます。流石にそれは必要となる前提知識の量が違いすぎるのでまた別エントリにしたいと思います。要望あれば…書くかも…しれません。

ホスト名、それに対応するIPアドレス。それがどのようにホスト上にキャッシュされるのかについて見てみます。なお、ここではNETBIOS名に関しては言及しません。ホスト名限定の話です。 キャッシュする様子を見てみる まずは単純にホストに対してpingを実行する、というケースに対し、このときの動きをキャッシュを含めてみてみましょう。 まず、キャッシュを確認してみます。コマンドは「ipconfig /displaydns」です。 C : \ D o c u m e n t s a n d S e t t i n g s \ A d m i n i s t r a t o r > i p c o n f i g / d i s p l a y d n s W i n d o w s I P C o n f i g u r a t i o n 1 . 0 . 0 . 1 2 7 . i n - a d d r . a r p a R e c o r d N a m e . . : 1 . 0 . 0 . 1 2 7 . i n - a d d r . a r p a . R e c o r d T y p e . . : 1 2 T i m e T o L i v e . : 4 8 8 3 5 4 D a t a L e n g t h . . : 4 S e c t i o n . . : A n s w e r P T R R e c o r d . : l o c a l h o s t l o c a l h o s t R e c o r d N a m e . . : l o c a l h o s t R e c o r d T y p e . . : 1 T i m e T o L i v e . : 4 8 8 3 5 4 D a t a L e n g t h . . : 4 S e c t i o n . . : A n s w e r A ( H o s t ) R e c o r d . . : 1 2 7 . 0 . 0 . 1 .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, “Courier New”, courier, monospace; background-color: #ffffff; /white-space: pre;/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } キャッシュ上にはlocalhostとローカルループバックの逆引きのレコードしか登録されていません。 ...

「インターネットに繋がらない！」という発言をよく聞きます。テクノロジーを理解していないお客さんならともかく、プロとしてはこのような発言はしたくないものです。「インターネットに繋がらない」時には具体的にどのようなことが原因として考えられるのか考えてみます。 ※ここでは「インターネットに繋がる」という言葉の正確さに関しては議論しないことにします。 大まかな流れとその確認確認ポイント 通常お客さんが「インターネットに繋がらない」と言ったときにはブラウザでWeb上のコンテンツを表示できなくなったときでしょうから、そのときの大まかな流れを見てみます。 PCが起動する 有線または無線にてEthernetに接続する 固定またはDHCPにてTCP/IPの設定がなされる ブラウザにてURLが指定される DNSにホスト名に対応するIPアドレスを問い合わせ、回答を得る 該当のWeb Serverに接続する Web Serverからコンテンツを得る ブラウザにコンテンツを表示する これはかなり大まかな流れであって、実際にはまだまだいくらでも細かく処理を記述することが可能ですが、最低この程度の粒度では事象を抑えてもらいたいです。 このレベルでの確認ポイントは以下です。 きちんとケーブルが刺さっているか IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSの設定がきちんとなされているか DNSでの名前解決(ホスト名からIPアドレスへの変換)がきちんとなされているか 該当のWeb Serverに接続できているか コンテンツを得られるか それぞれ確認方法を紹介してみましょう。 きちんとケーブルが刺さっているか これはどうやって確認すればいいかというと････。目で見て確認してください(笑)。でも、せっかくなのでコマンドで確認する方法も紹介しましょう。 このように「ipconfig」というコマンドを使うとネットワークの状態を見ることができます。今、上の図ではきちんとIPアドレス等が表示されているので、この状態であれば「ケーブルがきちんと刺さっている」と言うことがわかります。ケーブルがきちんと刺さっていない場合にはここには「media disconnected」と表示されます。このように表示された場合にはケーブルが刺さっていない状態ですので、ケーブルの確認をしてください。 IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSの設定がきちんとなされているか ケーブルが刺さっていることを確認したら次はIPアドレス、サブネットマスク、デフォルトゲートウェイ、DNS等のTCP/IPの設定がきちんとなされているかを確認します。これも先ほどと同じく「ipconfig」コマンドで確認できるのですが、「ipconfig」コマンドだけではDNSの設定が確認できないので「ipconfig /all」コマンドを実行することで確認します。 ここできちんとIPアドレス(IP Address)、サブネットマスク(Subnet Mask)、デフォルトゲートウェイ(Default Gateway)、DNS(DNS Servers)が設定されていることを確認します。 ここでこれらのパラメータを自分で設定している人(固定的に設定している人)と自動的に設定している人とで若干確認、修正方法が異なります。 固定になっているのか、自動になっているのかの判別は上記コマンド結果の「Dhcp Enabled」の部分がYesになっているかNoになっているかでわかります。上記のサンプルではDHCPが有効になっていて、DHCPサーバー(192.168.1.254)からTCP/IPの設定を自動取得していることがわかります。 固定で設定している場合には「インターネットプロトコル(TCP/IP)」のプロパティから手動で値を設定、修正します。 自動になっている場合にはDHCPサーバーがきちんと稼動して、正しい設定を配布してくれている必要があります。自動的に取得する設定になっているにもかかわらず「169.254.x.x」、あるいは「0.0.0.0｣というアドレスになっている場合には正常にDHCPサーバーから設定を取得できていない状態です。DHCPサーバーの正常動作を確認するか、あるいは固定で設定してしまうかなどの対応が必要です。 参考：APIPA - Wikipedia そもそもどんな値を設定すればいいのか、設定されていればいいのかわからない人はTCP/IPの基礎を勉強しなくてはいけないですね。後日書く予定です。 ここまでの設定の確認としては、「デフォルトゲートウェイまでのpingが通ることを確認する」という方法が有効です。 「ping デフォルトゲートウェイのIPアドレス」を実行して、Pingに対してReplyがあることを確認しましょう。 DNSでの名前解決(ホスト名からIPアドレスへの変換)がきちんとなされているか 次にDNSでの名前解決がきちんとなされているかの確認方法です。「nslookup」というコマンドをつかって「nslookup ホスト名」とすることで調べられます。「ホスト名」というのはURLのうち下の例で言うとxxxx.xxx.xxの部分です。 「http://xxxx.xxx.xx/yyy/xxx/」 http://の直後からはじめの「/」の前までの部分ですね。 このようにホスト名からIPアドレスへの変換がうまくいっている必要があります。そもそもここでスペルミスなどをすると以下のように答えが返ってきません。 ここがうまくいかない場合には以下の2つの可能性があります。 TCP/IPの設定でDNSの設定を間違えている(正しいDNSサーバーを利用していない) 接続しようとしている先のサイトの情報を保持しているDNSサーバーに障害が起きている どちらなのかを判断するためには、その他のホスト名の名前解決ができるかどうかを調べましょう。私はいつも「www.google.com」が解決できるかどうか試しています。 ここまでのこと(ケーブル、TCP/IP設定、DNS)を一度に試す方法があります。それは「ping www.google.com」を実行することです。 ケーブルが繋がっていなければPingに応答があるわけはありませんし、TCP/IPの設定がただしいからgoogleのサーバーまで通信できています。また、www.google.comをDNSをつかってIPアドレスに変換できているからPingが打てているのです。www.google.comのホストはきちんとpingのReplyを返してくれるので確認が取れるわけです。 該当のWeb Serverに接続できているか ここまでの確認でクライアント側のTCP/IPおよびDNSの設定は問題ないことがわかりました。もう少し上の層に視点を切り替えていきます。まずは、該当のWeb Serverに接続できているかどうかです。 ...