Wikipedia

ping

IPネットワークにおいて、ノードの到達性を確認するためのソフトウェア
曖昧さ回避 この項目では、ネットワーク試験ツールについて説明しています。
  • ブログなどのウェブ発行メカニズムについては「Ping (ブログ)」をご覧ください。
  • Appleのウェブサービス(iTunes Ping)については「iTunes Ping」をご覧ください。
  • その他のpingについては「ピン」をご覧ください。

ping（ピンまたはピング）はIPネットワークにおいて、ネットワーク上で特定のIPアドレスを持つ機器から応答があるかを調べるためのプログラム（ソフトウェア）[1]。

ping
作者 マイク・ムース
初版 1983年 (41年前) (1983)
プラットフォーム ほとんどのネットワークOS
種別 コマンド
テンプレートを表示

「到達性」を確認するために使え、さまざまな用途があり、たとえばホストシステム（ユーザが現に「ホスト」として使用中のシステム）がインターネットとの基本的な接続を確立しているかテストするため、また自ホストが属するノードが特定のノードと繋がっているかをテストするため、などに使われている。

IPネットワークにおける基本的なツールの一つであり、IPネットワーク機能が実装されているオペレーティングシステムや組み込みネットワーク管理ソフトウェアのほとんどで、何らかの形で用意されている。

概要

編集

pingは、発信元のホストから宛先のコンピュータにメッセージを送信し、宛先がそれに対して返した応答が戻って来るまでのラウンドトリップタイム（RTT、往復時間）を測定する。「ping」という名前は、アクティブソナー（水中で音波のパルスを送信して反射音を聴取することで水中の物体を検出するもの）の用語に由来している[2]。

pingはICMPの"echo request"パケットを対象ホストに送信し、対象ホストから"echo reply"が返って来ることで「到達性」を確認する。プログラムは、エラー、パケットロス率、結果の統計的要約（通常は最小、最大、平均のラウンドトリップタイム）を報告する。

逆に、相手システムから応答がなかった場合は、「制限時間内に応答がなかった」（Request timed out.）「指定されたアドレスやネットワークは到達可能ではない」（Destination host/net unreachable.）「経路が長すぎて到達できない」（TTL expired in transit.）など、応答がなかった理由を表示する。

用途

編集

pingを使用してIPネットワークに関するさまざまな情報を得ることができる。たとえばホストシステムの基本的なネットワーク設定がうまくできているか、ホストシステムはそもそも物理的な回線と繋がっているか、DNS（ドメインネームサーバ）は正常に機能しているか、自分側のノードと相手ノードの経路上に何らかの不具合が生じたり過負荷が生じたりしていないか、などである。

pingで宛先から応答があったと表示される状態を日本では俗語では「pingが通る」というが（あくまで俗語。メーカーの正式な説明書などではこの表現は使わない）、「pingが通る」ということは、「少なくとも、双方向にパケットの送受信ができる」「自システムから送信したパケットは指定IPの機器に（無事に）届き、なおかつ、指定したIPの機器が送信したパケットも自システムに（無事に）届く、という状態にはある」ということを示す。ドメイン名をノード名としてパケットを送信して（俗語では送信することを「投げる」ともいう）正常に応答（リプライ）された場合は、DNSの障害もない、と判る。

pingはたとえば前日までアクセス可能だったウェブサイトが突然アクセス不能・困難になった際にも、その原因や状況を調べるために使える。ウェブサーバのドメイン名でpingを「打ち」、正常に応答があれば、IPネットワークもDNSも正常と判断されるので、より高レベルのレイヤーに属するソフトウェアつまりOSI参照モデルでより高い層を荷うソフトウェアで問題が起きているのだろうと推察できる。もしpingで指定IPアドレスから応答があるのにそのIPアドレスのウェブサイトを閲覧できないならば、たとえばhttpレベルの通信が自身か相手のファイアウォールでブロックされているかもしれないし、相手のWWWサーバソフトウェアに障害が起きているのかも知れない、と推察できるのである。

種類、仕様の違い、特殊な用途

編集

pingユーティリティのコマンドラインオプションとその出力は、実装によって異なる。ペイロードのサイズ、試行回数、パケットを通過させるネットワークホップ数(TTL)の制限、試行間隔などをオプションとして指定できる。多くのシステムでは、IPv6ネットワークで同様のテストをするための、ICMPv6を実装したユーティリティ"ping6"を提供している。

一部のオンラインソフト[注釈 1]にもping機能を持つものがある。

オンラインゲームなどにおいて、サーバーとプレイヤー（クライアント）間の通信タイムラグをpingとして表示するものもある。また、短時間で切断されるような特殊なセッションを定期的なpingによって強制的に保持するという使い方もある。

歴史

編集

pingは、1983年12月に、当時アメリカ陸軍弾道研究所（現 アメリカ陸軍研究所（英語版））に勤務していたマイク・ムースが、自身の管理するIPネットワークでのトラブルシュート用に作成した。これは、後にNTPを開発したデイヴィッド・L・ミルズの、IPネットワークの診断と測定にICMPエコーパケットを使用することについての発言に触発されたものである[3]。ムースは、その挙動が潜水艦などで使われるアクティブソナーの発する音波（＝ping）の挙動と似ていることから、このプログラムをpingと名づけた[2][4]。この事からpingを実行する事を「pingを打つ」と呼ぶ場合が多い。ムースはpingが何かの略語であることを否定しているが、ミルズにより"packet internet groper"、別の人より"packet internet gopher"[注釈 2]というバクロニムを授かっている[5]。

最初にリリースされたバージョンはパブリックドメインだったが、後にBSDライセンスの下でライセンスされるようになった。pingは4.3BSDに最初から含まれていた[6]。

RFC 1122 では、どのホストもICMP echo requestを処理し、echo replyを返送する必要があると規定している[7]。しかし、セキュリティ上の理由から、これはしばしば無効になっている[8]。

インターネットの接続性の問題の“診断”にも有用なpingであったが、2003年末、Welchiaのようなpingをネットワークにフラッドし標的を探すタイプのコンピュータウイルスが出現したり、悪意を持ったユーザが攻撃目標の調査やネットワークに負荷をかけるなどの目的でpingの悪用を行ったため、一部のISPでICMP Type 8（echo request）パケットがフィルタリングされるようになった。

pingの出力例

編集

下線は利用者が入力する部分

Linux

編集

以下の出力例はLinux端末からwww.google.comへ、iputilsバージョンのpingからpingを打った結果である。 

$ ping www.google.com
PING www.l.google.com (64.233.183.103) 56(84) bytes of data.
64 bytes from 64.233.183.103: icmp_seq=1 ttl=246 time=22.2 ms
64 bytes from 64.233.183.103: icmp_seq=2 ttl=245 time=25.3 ms
64 bytes from 64.233.183.103: icmp_seq=3 ttl=245 time=22.7 ms
64 bytes from 64.233.183.103: icmp_seq=4 ttl=246 time=25.6 ms
64 bytes from 64.233.183.103: icmp_seq=5 ttl=246 time=25.3 ms
64 bytes from 64.233.183.103: icmp_seq=6 ttl=245 time=25.4 ms
64 bytes from 64.233.183.103: icmp_seq=7 ttl=245 time=25.4 ms
64 bytes from 64.233.183.103: icmp_seq=8 ttl=245 time=21.8 ms
64 bytes from 64.233.183.103: icmp_seq=9 ttl=245 time=25.7 ms
64 bytes from 64.233.183.103: icmp_seq=10 ttl=246 time=21.9 ms

--- www.l.google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9008ms
rtt min/avg/max/mdev = 21.896/24.187/25.718/1.619 ms

出力例からわかることは、まずwww.google.comというホスト名がDNSのCNAMEレコードによりwww.l.google.comへ誘導され、64.233.183.103というIPアドレスに名前解決されている。そして64.233.183.103に向けて10回pingが打たれており（Linuxの場合はデフォルトでは割込み文字を打って止めるまで、ずっとpingが打たれる設定となっている）、出力の最後にpingの結果が出ている。

結果からわかることは以下の通りである。

  • パケットは10回送信され、10回とも受信された。パケットロスは0%である。
  • ラウンドトリップタイムは最短21.896ミリ秒（1ミリ秒=1/1000秒）、平均24.187ミリ秒、最長25.718ミリ秒、標準偏差は1.619ミリ秒である。

macOS

編集

以下の出力例はmacOS端末からwww.google.comへ、ターミナルのコマンドpingからpingを打った結果である。 ただし、computernameはコンピューター名、usernameはユーザー名である（Macintosh HD→アプリケーション→ユーティリティ→ターミナル）。 

computername:~ username$ ping www.google.com
PING www.l.google.com (66.249.89.104): 56 data bytes
64 bytes from 66.249.89.104: icmp_seq=1 ttl=238 time=30.556 ms
64 bytes from 66.249.89.104: icmp_seq=2 ttl=238 time=30.412 ms
64 bytes from 66.249.89.104: icmp_seq=3 ttl=238 time=31.272 ms
64 bytes from 66.249.89.104: icmp_seq=4 ttl=238 time=30.121 ms
64 bytes from 66.249.89.104: icmp_seq=5 ttl=238 time=30.942 ms
64 bytes from 66.249.89.104: icmp_seq=6 ttl=238 time=32.132 ms
64 bytes from 66.249.89.104: icmp_seq=7 ttl=238 time=30.680 ms
64 bytes from 66.249.89.104: icmp_seq=8 ttl=238 time=32.614 ms
64 bytes from 66.249.89.104: icmp_seq=9 ttl=238 time=29.405 ms
64 bytes from 66.249.89.104: icmp_seq=10 ttl=238 time=41.360 ms
64 bytes from 66.249.89.104: icmp_seq=11 ttl=238 time=32.176 ms
64 bytes from 66.249.89.104: icmp_seq=12 ttl=238 time=32.321 ms
^C
--- www.l.google.com ping statistics ---
13 packets transmitted, 12 packets received, 7% packet loss
round-trip min/avg/max/stddev = 29.405/31.999/41.360/2.978 ms

macOSはUNIXであるため、Linuxとほぼ変わらない表示である。 今回は-cオプションで回数設定していないため、割込み文字（この例ではControl+C）で止めない限り永遠に続く（例では13回pingを送信）。見方はLinuxの出力例を参考。

logから分かる事は、

  • 13回パケットを送信し、12回受信してロスは、7%である。
  • RTT(ラウンドトリップタイム)は最短29.405ミリ秒(ms)、平均31.999ミリ秒、最長41.360ミリ秒、標準偏差は2.978ミリ秒である。

Windows

編集

以下の出力例はMicrosoft Windows XP端末からwww.google.comへ、コマンドプロンプト標準のpingを使用してpingを打った結果である(95、98、Me、2000も同様)。 

C:\>ping www.google.com

Pinging www.l.google.com [64.233.183.103] with 32 bytes of data:

Reply from 64.233.183.103: bytes=32 time=25ms TTL=245
Reply from 64.233.183.103: bytes=32 time=22ms TTL=245
Reply from 64.233.183.103: bytes=32 time=25ms TTL=246
Reply from 64.233.183.103: bytes=32 time=22ms TTL=246

Ping statistics for 64.233.183.103:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 22ms, Maximum = 25ms, Average = 23ms

出力例からわかることは、まずwww.google.comというホスト名がDNSのCNAMEレコードによりwww.l.google.comへ誘導され、64.233.183.103というIPアドレスに名前解決されている。そして64.233.183.103に向けて4回pingが打たれており（Windowsの場合はデフォルトではpingは4回ずつ打たれる設定となっている）、出力の最後にpingの結果が出ている。

結果からわかることは以下の通りである。

  • パケットは4回送信され、4回とも受信された。パケットロスは0%である。
  • ラウンドトリップタイムは最短22ミリ秒、最長25ミリ秒、平均23ミリ秒である。

また、次の出力例は日本版Microsoft Windows 10端末からwww.google.comへ、2018年10月29日にコマンドプロンプト標準のpingを使用してpingを打った結果である。 

C:\Users\（ユーザー名）>ping www.google.com

www.google.com [2404:6800:400a:808::2004]に ping を送信しています 32 バイトのデータ:
2404:6800:400a:808::2004 からの応答: 時間 =13ms
2404:6800:400a:808::2004 からの応答: 時間 =14ms
2404:6800:400a:808::2004 からの応答: 時間 =14ms
2404:6800:400a:808::2004 からの応答: 時間 =14ms

2404:6800:400a:808::2004 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 13ms、最大 = 14ms、平均 = 13ms

基本的な部分は上の例と同一だが、www.google.comから名前解決されたIPアドレスが、IPv6の表示となっている。

Ping ipv6

編集

現在主流のipv4のPingとは違って、ipv6の場合はInternet Control Message Protocol for IPv6 を使用し、IPv4で使われていたICMPのエラー通知（詳細はエラー表示の欄を参照）などの機能に加えて、ARPに相当するアドレス解決の機能もあわせ持つようになった。

エラー表示

編集

宛先のホストからの応答がない場合、ほとんどの実装では単にタイムアウトを表示するだけだが、一部の実装では、タイムアウトに関する以下のようなエラー通知を定期的に出力する。

  • H – ホストにアクセスできない
  • !N – ネットワークにアクセスできない
  • !P – プロトコルにアクセスできない
  • S – 送信元ルートが失敗した
  • F – フラグメントが必要
  • U – 宛先ネットワークが不明
  • !W – 宛先ホストが不明
  • I – 送信元ホストが孤立している
  • A – 宛先ネットワークとの通信が管理上禁止されている
  • Z – 宛先ホストとの通信が管理上禁止されている
  • Q – このToSでは、宛先ネットワークに到達できない
  • T – このToSでは、宛先ホストに到達できない
  • X – 通信が管理上禁止されている
  • V – ホスト優先順位違反
  • C – 優先順位カットオフが有効

エラーが発生した場合、宛先ホストや中間ルータは、"host unreachable"や"TTL exceeded in transit"などのICMPエラーメッセージを返信する。このメッセージには、元のメッセージの最初の8バイト（この場合はICMP echo requestのヘッダ）が含まれているため、pingユーティリティは応答を発信元のクエリーと照合できる[9]。

メッセージのフォーマット

編集

ICMPパケット

編集
IPv4データグラム
  Bits 0–7 Bits 8–15 Bits 16–23 Bits 24–31
ヘッダ
(20 bytes) 		バージョン/IHL サービスの種類 長さ
識別子 フラグとオフセット
Time To Live (TTL) Protocol ヘッダのチェックサム
送信元IPアドレス
宛先IPアドレス
ICMPヘッダ
（8バイト） 		メッセージの種類 コード チェックサム
ヘッダデータ
ICMPペイロード
（オプション） 		ペイロードデータ
IPv6データグラム
  Bits 0–3 Bits 4–7 Bits 8–11 Bits 12–15 Bits 16–23 Bits 24–31
ヘッダ
（40バイト） 		バージョン トラフィッククラス フローラベル
ペイロード長 次のヘッダ ホップリミット
送信元アドレス
宛先アドレス
ICMP6ヘッダ
（8バイト） 		メッセージの種類 コード チェックサム
ヘッダデータ
ICMP6ペイロード
（オプション） 		ペイロードデータ

ICMPパケットの一般的な構成:[10]

  • IPv4ヘッダ（青）: プロトコルは1(ICMP)、サービスタイプは0が設定される。
  • IPv6ヘッダ（青）: 次のヘッダは58(ICMP6)が設定される。
  • ICMPヘッダ（赤）:
    • ICMPメッセージの種類（8ビット）
    • コード（8ビット）
    • チェックサム（16ビット）。パケットのICMP部分で計算される（IPヘッダは使用されない）。Typeフィールドで始まるICMPメッセージの1の補数和の16ビットの1の補数である[11]。
    • ヘッダデータ（32ビット）。echo request, replyでは、識別子（16ビット）とシーケンス番号（16ビット）で構成される。
  • ICMPペイロード：様々な種類の回答のペイロード。実装の詳細により任意の長さにすることができる。ただし、IPヘッダとICMPヘッダを含むパケットは、ネットワークのmaximum transmission unit(MTU)より小さくなければならない。MTUより大きくなると、フラグメントされる危険性がある。

echo request

編集

echo request（エコー要求）は、ICMP/ICMP6のメッセージである。

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Type = 8(IPv4, ICMP) 128(IPv6,ICMP6) Code = 0 ヘッダチェックサム
識別子 シーケンス番号
ペイロード

クライアントは、識別子とシーケンス番号を使用して、応答を要求と一致させることができる。実際には、ほとんどのLinuxシステムはpingプロセスごとに異なる識別子を使用しており、シーケンス番号はそのプロセス内で増加する番号である。Windowsは、Windowsのバージョンによって異なる固定識別子と、起動時にのみリセットされるシーケンス番号を使用する。

echo reply

編集

echo reply（エコー応答）は、echo requestの応答として生成されるICMPメッセージである。規定では、エコー要求を受信した場合は必ずエコー応答を返信しなければならず、エコー応答にはエコー要求に含まれるペイロードをそのまま含まなければならない。

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Type = 0(IPv4,ICMP) 129(IPv6,ICMP6) Code = 0 ヘッダチェックサム
識別子 シーケンス番号
ペイロード

識別子とシーケンス番号は、エコー要求と応答を関連付けるためにクライアントで使用される。

ペイロード

編集

パケットのペイロードは一般にASCII文字で埋められている。以下に、ICMP echo requestの最後の32バイトのtcpdumpユーティリティによる出力の例を示す（echo requestパケットは0x0800から始まり、ICMPヘッダの後にペイロードがある）。 

16:24:47.966461 IP (tos 0x0, ttl 128, id 15103, offset 0, flags [none],
proto: ICMP (1), length: 60) 192.168.146.22 > 192.168.144.5: ICMP echo request,
id 1, seq 38, length 40
       0x0000:  4500 003c 3aff 0000 8001 5c55 c0a8 9216  E..<:.....\U....
       0x0010:  c0a8 9005 0800 4d35 0001 0026 6162 6364  ......M5...&abcd
       0x0020:  6566 6768 696a 6b6c 6d6e 6f70 7172 7374  efghijklmnopqrst
       0x0030:  7576 7761 6263 6465 6667 6869            uvwabcdefghi

ペイロードには、送信の時間を示すタイムスタンプやシーケンス番号（上記の例では含まれていない）を含むことができる。これにより、pingは各パケットの送信時刻を記録することなく、ステートレスな方法でラウンドトリップタイムを計算できる。

セキュリティ上の考慮事項

編集

多くのpingの実装には"flood"オプションが存在する。これは、高負荷条件下でのネットワークの応答を判断するために、できるだけ速くリクエストを送信するものである。このオプションは管理者特権を持つユーザに制限されているが、標的の元に大量のICM echo requestが届くようにするDoS攻撃の一種のping floodに使用される可能性がある。

pingは、単にホストの存在を知らせることによって潜在的なターゲットとして確認されるため、セキュリティ上のリスクと見なされている。解決策として、多くのシステムにおいて、 RFC 1122 においてホストは常に返信を返さなければならないという規定を無視して、返信を無効にする手段を提供している[8][12]。さらに、pingによって計算されたラウンドトリップ時間は、完全性チェックに欠けていることが多く、そのため、過酷な環境では信頼できない。攻撃者は、ほとんどのping実装で計算された遅延を延長または短縮する可能性がある[13] 。

関連項目

編集

脚注

編集
[脚注の使い方]

注釈

編集
  1. ^ EditMTU等。
  2. ^ ここでのgopherはIT用語でのgopherではなく、齧歯目のgopherのことである。

出典

編集
  1. ^ [1]
  2. ^ a b Mike Muuss. “The Story of the PING Program”. U.S. Army Research Laboratory. 8 September 2010時点のオリジナルよりアーカイブ。8 September 2010閲覧。 “I named it after the sound that a sonar makes, inspired by the whole principle of echo-location.”
  3. ^ "The Story of the PING Program", Mike Muuss
  4. ^ Salus, Peter (1994). A Quarter Century of UNIX. Addison-Wesley. ISBN 978-0-201-54777-1 
  5. ^ Mills, D.L. (1983). Internet Delay Experiments (英語). IETF. p. 1. doi:10.17487/RFC0889. STD 8. RFC 889. 2015年6月26日閲覧。
  6. ^ http://www.manpagez.com/man/8/ping/
  7. ^ “RFC [https://datatracker.ietf.org/doc/html/rfc1122 1122 - Requirements for Internet Hosts -- Communication Layers]”. p. 42. 2012年3月19日閲覧。 “Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies.”
  8. ^ a b “Windows firewall: how block ICMP (echo response)”. 2019年2月27日閲覧。
  9. ^ “ICMP: Internet Control Message Protocol”. repo.hackerzvoice.net (January 13, 2000). December 4, 2014閲覧。
  10. ^ “RFC 792 - Internet Control Message Protocol”. Tools.ietf.org. 2014年2月2日閲覧。
  11. ^ “RFC Sourcebook's page on ICMP”. 20 December 2010閲覧。
  12. ^ “redhat linux /proc/sys/net/ipv4 parameters”. 2019年2月27日閲覧。
  13. ^ Abdou, AbdelRahman; Matrawy, Ashraf; van Oorschot, Paul (April 2017). Accurate Manipulation of Delay-based Internet Geolocation. ACM AsiaCCS. doi:10.1145/3052973.3052993。

外部リンク

編集
「https://ja.wiki.x.io/w/index.php?title=Ping&oldid=101377443」から取得