tcpのping代替？

ネットワークの「品質」-遅延、ドロップされたパケットの数などを確認することは一般的なタスクです。しかし、「ping」には多くの欠点があります。-ICMPを使用します。多くのISPはICMPおよびTCPトラフィック用に異なるシェーパーを持っているため、「ping」では10ミリ秒の遅延が表示されますが、TCP接続では1000ミリ秒以上が発生します。-非常に少量のパケットを送信します。デフォルトでは、毎秒1パケット。TCPプロトコルはパケット損失を許容するため（半分のパケットが失われると非常に良好に動作します-正常です）、pingの「30％パケット損失」が接続を切断するのか、それが絶対に正常なのかは明確ではありません。

だから、ICMPの代わりにTCP接続を使用してインターネット接続の品質をチェックするpingの代替手段はありますか？

TCPがパケット損失/パケットの順序付けの問題を許容できるという事実に関係なく、30％のping損失は、「人口」が十分に大きい場合（つまり、100を超えるpingの場合）、依然としてかなり重要です。

しかし、質問に答えるために、nmapを見ることができます。私はすぐに例があふれてくると確信しています:)

さらに重要なことは、往復時間だけが必要なわけではなく、マシンからサーバーまでのパフォーマンスを（すべての）ホップごとに確認することです。

これを行うことができますtraceroute-ただし、これの最も一般的なバージョンはICMPまたはUDPを使用して行われますが、検索してtcp traceroute-そこから開始します。

ここにいる間、試すための楽しいツールがいくつかあります...

• LFT
• パケット
• hping

以下に例を示しlftます...

 % lft -S 4.2.2.2

 Hop  LFT trace to vnsc-bak.sys.gtei.net (4.2.2.2):80/tcp
  1   ln-gateway.centergate.com (206.117.161.1) 0.5ms
  2   isi-acg.ln.net (130.152.136.1) 2.3ms
  3   isi-1-lngw2-atm.ln.net (130.152.180.21) 2.5ms
  4   gigabitethernet5-0.lsanca1-cr3.bbnplanet.net (4.24.4.249) 3.0ms
  5   p6-0.lsanca1-cr6.bbnplanet.net (4.24.4.2) 3.4ms
  6   p6-0.lsanca2-br1.bbnplanet.net (4.24.5.49) 3.3ms
  7   p15-0.snjpca1-br1.bbnplanet.net (4.24.5.58) 10.9ms
  8   so-3-0-0.mtvwca1-br1.bbnplanet.net (4.24.7.33) 11.1ms
  9   p7-0.mtvwca1-dc-dbe1.bbnplanet.net (4.24.9.166) 11.0ms
 10   vlan40.mtvwca1-dc1-dfa1-rc1.bbnplanet.net (128.11.193.67) 11.1ms
 **   [neglected] no reply packets received from TTLs 11 through 20
 **   [4.2-3 BSD bug] the next gateway may errantly reply with reused TTLs
 21   [target] vnsc-bak.sys.gtei.net (4.2.2.2) 11.2ms

Netcat Power Toolsは、netcatでTCP Pingを行う方法を説明しています。具体的には、すべての非請求ACKパケットはRSTを返す必要があります。

私は個人的にmtr（http://www.bitwizard.nl/mtr/）の大ファンです。mtrはicmpとudpの両方を使用して動作できるncursesベースのtracerouteクローンです。特定のホストへのリンクの弱点が表示され、そのようにして邪魔になりません。

負荷テストに関しては、iperf（クライアント/サーバー）を使用します。

Windowsの場合、tcpingのようなものを使用できます：http ://www.elifulkerson.com/projects/tcping.php

また、Linuxにとって最適なユーティリティは、すでに述べたとおりですhping。

# hping -S -p 80 www.sunet.se
HPING www.sunet.se (eth0 192.36.171.155): S set, 40 headers + 0 data bytes
len=46 ip=192.36.171.155 ttl=59 DF id=0 sport=80 flags=SA seq=0 win=5840 rtt=0.7 ms
len=46 ip=192.36.171.155 ttl=59 DF id=0 sport=80 flags=SA seq=1 win=5840 rtt=0.7 ms
len=46 ip=192.36.171.155 ttl=59 DF id=0 sport=80 flags=SA seq=2 win=5840 rtt=0.6 ms
^C
--- www.sunet.se hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.6/0.7/0.7 ms

ICMPパケットの配信は一般に遅くなります（違いがある場合）。これは、ほとんどのネットワーク、特にpingパケットの優先順位を下げるためです。一般に、ICMPおよびTCP応答からこのような異なる結果が表示される場合、問題はサーバーの過負荷または途中のファイアウォールでの特定のTCPシェーピングのいずれかです。

あなたは調査する必要がありtraceroute -P tcp、tcptraceroute、lftそしてもちろんtelnet。

QoSアプリケーションを使用して、この種のネットワークパラメータを測定できます。例えば：

NetPerf（www.netperf.org/netperf/）：Netperfは、さまざまな種類のネットワークのパフォーマンスを測定するために使用できるベンチマークです。独自のスループットとエンドツーエンドのレイテンシの両方のテストを提供します。現在、netperfで測定可能な環境は次のとおりです。

* TCP and UDP via BSD Sockets for both IPv4 and IPv6
* DLPI
* Unix Domain Sockets
* SCTP for both IPv4 and IPv6 

または

IPerf（sourceforge.net/projects/iperf）Iperfは、最大のTCPおよびUDP帯域幅パフォーマンスを測定するための最新の代替手段としてNLANR / DASTによって開発されました。Iperfでは、さまざまなパラメーターとUDP特性を調整できます。Iperfは、帯域幅、遅延ジッター、データグラム損失を報告します。

hpingをチェックしてから、bingを見てください

TCPは50％のパケット損失を「許容」できません。単純な理由により、単に停止します。パケットの損失に基づいて伝送速度を調整します。パケットが失われると、輻輳を示していると理解されます。トラフィックに関係なく、パケットの50％をドロップすると（たとえば、ランダムドロップファイアウォールルールを使用）、帯域幅の可用性が低下し続けます。

さらに、ISPがICMP対TCPを形成することを疑います。本当に愚かな人がいるので、そうする人もいるかもしれませんが、そうするのはあまり意味がありません。ほとんどは接続全体を形成するか、輻輳のために「自身を形成」します。どちらの場合でも、パケットは通常ランダムにドロップされます。

そうは言っても、TCPでpingを実行できますが、いくつかの注意事項があります。1つ目は、TCP接続で最初のパケットを送信することです。これにより、ポートが開いているサーバーからの応答が誘発されますが、接続試行と見なされます。理想的には、「エコー」サービス（TCPポート7）を使用できますが、実際には、すべての場所でデフォルトで無効になっているため使用できません。とにかく、テストしたいマシン上で誰かがそれを有効にできるなら、プログラムはそれを使ってTCP接続内のパケットのラウンドアバウト時間をチェックできます。

そうは言っても、おそらく「tracepath」コマンドがマシンにインストールされています。tracerouteと似ていますが、TCPもICMPも使用せず、UDPを使用します。TCPにはさまざまなユーティリティがありますが、hpingを試すことができます。

pingの代わりに、「netstat」を使用できます

オプション：1.netstat -antp 2.netstat -anup

-a =すべて、-n =ソケットのローカルエンドのアドレスとポート番号、-t = tcp、-p =プログラム

-u = udp。