alternativa de ping para tcp?

Es una tarea común verificar la 'calidad' de la red: latencia, número de paquetes descartados, etc. Pero 'ping' tiene una serie de inconvenientes: - Utiliza ICMP. Muchos ISP tienen diferentes modeladores para el tráfico ICMP y TCP, por lo que 'ping' mostrará una latencia de 10 ms, pero las conexiones TCP experimentarán más de 1000 ms. - Envía una cantidad muy pequeña de paquetes. Por defecto, un paquete por segundo. Dado que el protocolo TCP tolera la pérdida de paquetes (puede funcionar muy bien si la mitad de los paquetes se pierden, es normal), no está absolutamente claro si la conexión de "30% de pérdida de paquetes" de ping o si es absolutamente normal.

Entonces, ¿hay alguna alternativa para hacer ping que use la conexión TCP en lugar de ICMP y verifique la calidad de la conexión a Internet?

Independientemente del hecho de que TCP puede tolerar problemas de pérdida de paquetes / orden de paquetes, una pérdida de ping del 30% sigue siendo bastante significativa si la "población" es lo suficientemente grande, es decir, más de 100 pings.

Pero para responder la pregunta, puede mirar nmap. Estoy seguro de que los ejemplos se inundarán en breve :)

Sin embargo, lo más importante es que no desea solo un tiempo de ida y vuelta, realmente desea ver el rendimiento de su máquina al servidor y viceversa en cada (posible) salto.

Puede hacer esto con traceroute, sin embargo, la versión más común de esto se hace usando ICMP o UDP, pero busque tcp traceroute, y comience allí.

Aquí hay algunas herramientas divertidas para probar mientras lo hace ...

• lft
• paketto
• hping

Aquí hay un ejemplo con 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 describe cómo hacer TCP Ping con netcat. Específicamente, cada paquete ACK no solicitado debe devolver RST.

Personalmente soy un gran admirador de mtr ( http://www.bitwizard.nl/mtr/ ), mtr es un clon de traceroute basado en ncurses que puede funcionar usando icmp y udp. Le muestra los puntos débiles en su enlace a un determinado host y de esa manera no es intrusivo.

Cuando realmente se trata de algunas pruebas de carga, iría con iperf (que es cliente / servidor).

Para Windows puede usar algo como tcping:
http://www.elifulkerson.com/projects/tcping.php

Y para Linux está, ya se ha mencionado la mejor utilidad, 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

Los paquetes ICMP generalmente se entregan más lentamente (si es que hay alguna diferencia), porque la mayoría de las redes los priorizan, especialmente los paquetes ping. En general, si observa resultados tan divergentes de las respuestas ICMP y TCP, el problema es un servidor sobrecargado o una configuración TCP específica en un firewall en el camino.

Debe investigar traceroute -P tcp, tcptraceroute, lfty, por supuesto telnet.

Podría usar alguna aplicación de QoS para medir este tipo de parámetros de red. Por ejemplo:

NetPerf (www.netperf.org/netperf/): Netperf es un punto de referencia que se puede utilizar para medir el rendimiento de muchos tipos diferentes de redes. Proporciona pruebas para el rendimiento unidirecitonal y la latencia de extremo a extremo. Los entornos actualmente medibles por netperf incluyen:

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

O

IPerf (sourceforge.net/projects/iperf) Iperf fue desarrollado por NLANR / DAST como una alternativa moderna para medir el rendimiento máximo de ancho de banda TCP y UDP. Iperf permite el ajuste de varios parámetros y características UDP. Iperf informa de ancho de banda, jitter de retraso, pérdida de datagramas.

echa un vistazo a hping y luego echa un vistazo a bing

TCP no puede "tolerar" la pérdida de paquetes del 50%. Simplemente se detendrá, por una simple razón: adapta su velocidad de transmisión en función de la pérdida de paquetes. Cuando se pierden paquetes, se entiende que indican congestión. Si descarta el 50% de los paquetes (por ejemplo, con una regla de firewall de eliminación aleatoria ) independientemente del tráfico, verá una disponibilidad de ancho de banda cada vez menor.

Además, dudo que los ISP formen ICMP vs TCP. Algunos podrían hacerlo, ya que hay algunas personas realmente estúpidas, pero no tiene mucho sentido hacerlo. La mayoría dará forma a toda la conexión, o se "formará a sí misma" debido a la congestión. En cualquier caso, los paquetes generalmente se descartan al azar.

Dicho esto, puede hacer ping con TCP, pero hay varias advertencias. El primero es enviar el paquete inicial en una conexión TCP, lo que generará una respuesta de un servidor con un puerto abierto, pero se verá como un intento de conexión. Idealmente, podría usar el servicio "echo" (puerto TCP 7) ... pero en realidad no puede porque ahora está deshabilitado por defecto en todas partes. De todos modos, si puede hacer que alguien lo habilite para usted en la máquina que desea probar, un programa podría usarlo para verificar el tiempo de respuesta para los paquetes dentro de una conexión TCP.

Dicho esto, probablemente tengas el comando "tracepath" instalado en tu máquina; es similar a traceroute pero no usa TCP o ICMP, sino UDP. Para TCP hay varias utilidades disponibles, puede intentar hping .

La alternativa al ping, puede usar 'netstat'

Opciones: 1.netstat -antp 2.netstat -anup

-a = todos, -n = Dirección y número de puerto del extremo local del socket, -t = tcp, -p = programa

-u = udp.