альтернатива ping для tcp?

Независимо от того факта, что TCP может допускать проблемы с потерей пакетов / упорядочением пакетов, 30% -ная потеря эхо-запросов все еще довольно значительна, если «совокупность» достаточно велика, то есть более чем, скажем, 100 эхо-запросов.

Но чтобы ответить на вопрос, вы можете посмотреть 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 описывает, как делать TCP Ping с netcat. В частности, каждый незапрошенный пакет ACK должен возвращать RST.

Я лично большой поклонник mtr ( http://www.bitwizard.nl/mtr/ ), mtr - это клон traceroute на основе ncurses, который может работать как с icmp, так и с udp. Он показывает слабые места в вашей ссылке на определенный хост и, таким образом, не навязчив.

Когда дело доходит до некоторых нагрузочных тестов, я бы выбрал 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 был разработан NLANR / DAST как современная альтернатива для измерения максимальной пропускной способности TCP и UDP. Iperf позволяет настраивать различные параметры и характеристики UDP. Iperf сообщает о пропускной способности, джиттере задержки, потере дейтаграммы.

проверять, выписываться hping а затем взгляните на бин

TCP не может «терпеть» потерю 50% пакетов. Он просто остановится по простой причине: он адаптирует скорость передачи в зависимости от потери пакетов. Считается, что потеря пакетов указывает на перегрузку. Если вы отбрасываете 50% пакетов (скажем, с случайный drop firewall rule) независимо от трафика, доступность полосы пропускания будет постоянно уменьшаться.

Более того, я сомневаюсь, что интернет-провайдеры формируют ICMP вместо TCP. Некоторые могут подойти, поскольку есть действительно глупые люди, но в этом нет особого смысла. Большинство из них будет формировать все соединение, или оно будет «формировать само себя» из-за скопления. В любом случае пакеты обычно отбрасываются случайным образом.

При этом вы можете пинговать с TCP, но есть несколько предостережений. Первый - просто отправить начальный пакет в 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.