コンテンツにスキップ

「Ping」の版間の差分

出典: フリー百科事典『ウィキペディア(Wikipedia)』
削除された内容 追加された内容
外部リンク: 外部リンクの修正 https://ftp.arl.army.mil/~mike/ping.htmlhttps://linuxjm.osdn.jp/html/netkit/man8/ping.8.htmlhttps://nixdoc.net/man-pages/HP-UX/man1m/ping.1m.htmlhttps://docs.oracle.com/cd/E19455-01/806-2719/6jbtsiffe/index.htmlhttps://ping.eu/https://hp.vector.co.jp/authors/VA022090/editmtu/* {{en}} [http://www.test-net.org/ping/ Ping test online]*[http://www1.seaple.ne.jp/t-arai/T00702.htm MacOSX PING / update 25 Jan. 2004] コマンドライン版
157行目: 157行目:
*ラウンドトリップタイムは最短22ミリ秒、最長25ミリ秒、平均23ミリ秒である。
*ラウンドトリップタイムは最短22ミリ秒、最長25ミリ秒、平均23ミリ秒である。


なお、次の出力例は日本版[[Microsoft Windows 10]]端末から<tt>www.google.com</tt>へ、018年10月29日にマンドプロンプト標準のpingを使用してpingを打った結果である
また、次の出力例は日本版[[Microsoft Windows 10]]端末から<tt>www.google.com</tt>へ、018年10月29日にマンドプロンプト標準のpingを使用してpingを打った結果である
C:\Users\(ユーザー名)>ping www.google.com
C:\Users\(ユーザー名)>ping www.google.com

2019年11月18日 (月) 04:27時点における版

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

ping(ピン)はIPネットワークにおいて、ノードの到達性を確認するためのソフトウェアである。IPネットワークにおける基本的なツールの一つであり、組み込みネットワーク管理ソフトウェアを含む、ネットワーク機能が実装されているオペレーティングシステムのほとんどにおいて、何らかの形で用意されている。

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

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

これらは対象ノード間の回線状況を知るため重要な情報である。前日までアクセス可能だったサイトがアクセス不能・困難になった時に原因や状況を調べるのに有効なツールである。pingが通るということは、「少なくとも双方向にIPパケットが通り、対象から応答があった」事を示す。ドメイン名をノード名としてパケットを投げて正常にリプライされた場合は、DNSの障害もないことが確認できる。例えばウェブサイトが閲覧できなくなっている場合、ウェブサーバのドメイン名でpingを打ち正常に応答があれば、ネットワークもDNSも正常と判断されるので、より高レベルに位置するソフトウェア側に問題が起きていると推測できる。つまり自身か相手のファイアウォールでhttp通信をブロックされているかもしれないし、相手のWWWサーバソフトウェアに障害が起きている可能性がある。一部のオンラインソフト[2]にもping機能を持つものがある。

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

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

歴史

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

エラー表示

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

  • 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. ^ ここでのgopherはIT用語でのgopherではなく、齧歯目のgopherのことである。

出典

  1. ^ 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.”
  2. ^ EditMTU等。
  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日閲覧 {{citation}}: 不明な引数|month=は無視されます。 (説明)
  6. ^ http://www.manpagez.com/man/8/ping/
  7. ^ RFC 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

外部リンク