tcpの代替ping？
ネットワークの「品質」を確認することは一般的なタスクです。遅延、ドロップされたパケットの数などです。しかし、「ping」にはいくつかの欠点があります。-ICMPを使用します。多くのISPはICMPとTCPトラフィックのために異なるシェーパーを持っているので、「ping」は10msの待ち時間を示しますが、TCP接続は1000ms +を経験します。-それは非常に小さいパケットの量。デフォルトでは、1パケット/秒。TCPプロトコルは、パケットの損失を許容するため（半分のパケットが失われると正常に動作し、正常に動作します）、pingが「30 ％パケット損失」接続を強制終了するか、それが完全に正常かどうか。
では、ICMPの代わりにTCP接続を使用し、インターネット接続の品質をチェックすることは、pingの代替手段ですか？
TCPはパケット損失/パケット順序付けの問題を許容できるという事実に関係なく、「人口」が十分に大きい場合、つまり言う以上に、30％のping損失は依然としてかなり重要です。 100 ping。
しかし、質問に答えるために、nmapを見ることができます。例はまもなく殺到するでしょう:)
さらに重要なのは、往復時間だけではなく、マシンからサーバーまでのパフォーマンスと、（可能性のある）ホップごとのパフォーマンスを確認することです。
これはtracerouteで実行できますが、最も一般的に見られるバージョンはICMPまたはUDPを使用して行われますが、tcp tracerouteを検索してそこから開始します。
ここにいる間に試すためのいくつかの楽しいツールがあります...
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
OR
IPerf（sourceforge.net/projects/iperf）Iperfは、最大のTCPおよびUDP帯域幅のパフォーマンスを測定するための最新の代替手段として、NLANR/DASTによって開発されました。Iperfによりチューニングが可能になります。 Iperfは、帯域幅、遅延ジッター、データグラム損失を報告します。
TCPは50％のパケット損失を「許容」できません。単純な理由で、単純にグラインドして停止します。パケットの損失に基づいて伝送速度を調整します。パケットが失われると、それらは輻輳を示すと理解されます。トラフィックに関係なくパケットの50％をドロップすると（たとえば、randomドロップファイアウォールルールを使用して）、帯域幅の可用性が低下し続けることがわかります。
さらに、ISPがICMPとTCPを形成しているとは思えません。世の中には本当に愚かな人々がいるので、そうする人もいるかもしれませんが、そうすることはあまり意味がありません。ほとんどは接続全体を形成するか、または輻輳のために「それ自体を形成」します。どちらの場合も、パケットは通常ランダムにドロップされます。
そうは言っても、TCPでpingを実行できますが、いくつかの注意点があります。 1つ目は、TCP接続で最初のパケットを送信するだけです。これにより、ポートが開いているサーバーからの応答が引き出されますが、接続試行と見なされます。理想的には、 "echo"サービス（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。