ping alternativo per tcp?

È un compito comune controllare la "qualità" della rete: latenza, numero di pacchetti rilasciati ecc. Ma "ping" presenta numerosi inconvenienti: - Utilizza ICMP. Molti ISP hanno diversi shaper per il traffico ICMP e TCP, quindi 'ping' mostrerà una latenza di 10ms, ma le connessioni TCP avranno 1000ms +. - Invia una quantità molto piccola di pacchetti. Per impostazione predefinita, un pacchetto al secondo. Dato che il protocollo TCP tollera la perdita di pacchetti (può funzionare molto bene se si perdono metà pacchetti - è normale), non è assolutamente chiaro se la connessione del ping "30% perdita di pacchetti" uccide o se è assolutamente normale.

Quindi, c'è qualche alternativa per il ping che utilizza la connessione TCP invece dell'ICMP e controlla la qualità della connessione Internet?

Indipendentemente dal fatto che TCP possa tollerare problemi di perdita di pacchetti / ordinamento di pacchetti, una perdita di ping del 30% è ancora abbastanza significativa se la "popolazione" è abbastanza grande, vale a dire più di 100 ping.

Ma per rispondere alla domanda, puoi guardare nmap. Sono sicuro che presto arriveranno degli esempi :)

Ancora più importante, però, non vuoi solo un viaggio di andata e ritorno, vuoi davvero vedere le prestazioni dalla tua macchina al server e tornare ad ogni (possibile) hop.

Puoi farlo con traceroute- comunque la versione più comunemente trovata viene fatta usando ICMP o UDP, ma cerca tcp traceroute- e inizia da lì.

Ecco alcuni strumenti divertenti da provare mentre ci sei ...

• LFT
• paketto
• hping

Ecco un esempio 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 descrive come eseguire il ping TCP con netcat. In particolare, ogni pacchetto ACK non richiesto deve restituire RST.

Personalmente sono un grande fan di mtr ( http://www.bitwizard.nl/mtr/ ), mtr è un clone traceroute basato su ncurses che può funzionare sia con icmp che con udp. Ti mostra i punti deboli nel tuo collegamento a un determinato host ed è in questo modo non invadente.

Quando si tratta davvero di alcuni test di carico, andrei con iperf (che è client / server).

Per Windows puoi usare qualcosa come tcping:
http://www.elifulkerson.com/projects/tcping.php

E per Linux meglio l'utilità è, già accennato, 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

I pacchetti ICMP vengono generalmente consegnati più lentamente (se c'è una differenza), perché la maggior parte delle reti li depriorizza, in particolare i pacchetti ping. In genere, se si riscontrano risultati così divergenti dalle risposte ICMP e TCP, il problema è un server sovraccarico o una specifica configurazione TCP su un firewall lungo il percorso.

Si dovrebbe indagare traceroute -P tcp, tcptraceroute, lfte, naturalmente telnet.

È possibile utilizzare alcune applicazioni QoS per misurare questo tipo di parametri di rete. Per esempio:

NetPerf (www.netperf.org/netperf/): Netperf è un benchmark che può essere utilizzato per misurare le prestazioni di molti diversi tipi di rete. Fornisce test sia per la velocità unidirezionale sia per la latenza end-to-end. Gli ambienti attualmente misurabili da netperf includono:

* 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 è stato sviluppato da NLANR / DAST come moderna alternativa per misurare le massime prestazioni della larghezza di banda TCP e UDP. Iperf consente la messa a punto di vari parametri e caratteristiche UDP. Iperf riporta larghezza di banda, delay jitter, perdita di datagrammi.

controlla hping e poi dai un'occhiata a bing

TCP non può "tollerare" la perdita di pacchetti del 50%. Si fermerà semplicemente, per una semplice ragione: adatta la sua velocità di trasmissione in base alla perdita di pacchetti. Quando i pacchetti vengono persi, si intende che indicano congestione. Se elimini il 50% dei pacchetti (ad esempio, con una regola del firewall di rilascio casuale ) indipendentemente dal traffico, vedrà una disponibilità di larghezza di banda in costante diminuzione.

Inoltre, dubito che gli ISP modellino ICMP vs TCP. Alcuni potrebbero farlo, dato che ci sono persone davvero stupide là fuori, ma non ha molto senso farlo. La maggior parte modellerà l'intera connessione o "modellerà se stessa" a causa della congestione. In entrambi i casi i pacchetti vengono in genere rilasciati casualmente.

Detto questo, puoi eseguire il ping con TCP, ma ci sono molti avvertimenti. Il primo è semplicemente inviare il pacchetto iniziale in una connessione TCP, che genererà una risposta da un server con una porta aperta, ma verrà visto come un tentativo di connessione. Idealmente potresti usare il servizio "echo" (porta TCP 7) ... ma in realtà non puoi perché ora è disabilitato di default ovunque. Ad ogni modo, se riesci a ottenere qualcuno che lo abiliti sulla macchina che vuoi testare, un programma potrebbe usarlo per controllare il tempo di arrotondamento per i pacchetti all'interno di una connessione TCP.

Detto questo, probabilmente hai il comando "tracepath" installato sul tuo computer; è simile a traceroute ma non utilizza né TCP né ICMP, ma UDP. Per TCP ci sono varie utility là fuori, puoi provare hping .

L'alternativa al ping, puoi usare 'netstat'

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

-a = all, -n = indirizzo e numero di porta dell'estremità locale del socket, -t = tcp, -p = programma

-u = udp.