ping alternatywa dla tcp?

Częstym zadaniem jest sprawdzanie „jakości” sieci - opóźnienie, liczba odrzuconych pakietów itp. Ale „ping” ma wiele wad: - Używa ICMP. Wielu dostawców usług internetowych ma różne moduły kształtujące dla ruchu ICMP i TCP, więc „ping” pokaże 10 ms opóźnienia, ale połączenia TCP doświadczą 1000 ms +. - Wysyła bardzo małą liczbę pakietów. Domyślnie jeden pakiet na sekundę. Ponieważ protokół TCP toleruje utratę pakietów (może działać bardzo dobrze, gdy traci się połowę pakietów - to normalne), absolutnie nie jest jasne, czy ping zabija połączenie „30% utraty pakietu” ping, czy jest to absolutnie normalne.

Czy jest więc jakaś alternatywa dla ping, który używa połączenia TCP zamiast ICMP i sprawdza jakość połączenia z Internetem?

Niezależnie od tego, że TCP toleruje problemy z utratą pakietów / kolejnością pakietów, utrata ping w wysokości 30% jest nadal dość znacząca, jeśli „populacja” jest wystarczająco duża - tj. Ponad 100 pingów.

Ale aby odpowiedzieć na pytanie, możesz spojrzeć na nmap. Jestem pewien, że wkrótce pojawią się przykłady :)

Co ważniejsze, nie chcesz tylko czasu podróży w obie strony, naprawdę chcesz zobaczyć wydajność ze swojego komputera na serwer iz powrotem przy każdym (możliwym) przeskoku.

Możesz to zrobić za pomocą traceroute- jednak najczęściej spotykana wersja jest wykonywana przy użyciu ICMP lub UDP, ale szukaj tcp traceroute- i zacznij od tego.

Oto kilka zabawnych narzędzi do wypróbowania, gdy jesteś przy tym ...

• lft
• paketto
• hping

Oto przykład z 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 opisuje, jak wykonać pingowanie TCP za pomocą netcat. W szczególności każdy niechciany pakiet ACK powinien zwrócić RST.

Osobiście jestem wielkim fanem mtr ( http://www.bitwizard.nl/mtr/ ), mtr jest klonem traceroute opartym na ncurses, który może pracować zarówno z icmp, jak i udp. Pokazuje słabe punkty w łączu do określonego hosta i jest w ten sposób nieinwazyjny.

Jeśli naprawdę chodzi o niektóre testy obciążenia, wybrałbym iperf (czyli klient / serwer).

W systemie Windows możesz użyć czegoś takiego jak tcping:
http://www.elifulkerson.com/projects/tcping.php

A dla Linuksa najlepsze narzędzie jest już wspomniano 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

Pakiety ICMP są generalnie dostarczane wolniej (jeśli w ogóle jest różnica), ponieważ większość sieci je deprioryzuje, szczególnie pakiety ping. Ogólnie rzecz biorąc, jeśli widzisz tak rozbieżne wyniki z odpowiedzi ICMP i TCP, problemem jest albo przeciążony serwer, albo określone kształtowanie TCP na zaporze ogniowej po drodze.

Należy zbadać traceroute -P tcp, tcptraceroute, lfti oczywiście telnet.

Możesz użyć aplikacji QoS do pomiaru tego rodzaju parametrów sieci. Na przykład:

NetPerf (www.netperf.org/netperf/): Netperf to punkt odniesienia, którego można użyć do pomiaru wydajności wielu różnych rodzajów sieci. Zapewnia testy zarówno jednokierunkowej przepustowości, jak i opóźnień od końca do końca. Środowiska obecnie mierzone przez netperf obejmują:

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

LUB

IPerf (sourceforge.net/projects/iperf) Iperf został opracowany przez NLANR / DAST jako nowoczesna alternatywa do pomiaru maksymalnej wydajności przepustowości TCP i UDP. Iperf umożliwia dostrajanie różnych parametrów i charakterystyk UDP. Iperf zgłasza przepustowość, opóźnienie jittera, utratę datagramów.

sprawdź hping, a następnie spójrz na bing

TCP nie może „tolerować” 50% utraty pakietów. Po prostu zatrzyma się, z prostego powodu: dostosowuje prędkość transmisji na podstawie utraty pakietów. Gdy pakiety zostaną utracone, należy je rozumieć jako zator. Jeśli upuścisz 50% pakietów (powiedzmy, z przypadkową regułą zapory) niezależnie od ruchu, zobaczysz coraz mniejszą przepustowość.

Ponadto wątpię, by dostawcy usług internetowych kształtowali ICMP w porównaniu z TCP. Niektórzy mogą to zrobić, ponieważ są naprawdę głupi ludzie, ale nie ma to większego sensu. Większość ukształtuje całe połączenie lub „ukształtuje się” z powodu przeciążenia. W obu przypadkach pakiety są zazwyczaj upuszczane losowo.

To powiedziawszy, możesz pingować za pomocą TCP, ale istnieje kilka zastrzeżeń. Pierwszym z nich jest po prostu wysłanie pakietu początkowego w połączeniu TCP, który wywoła odpowiedź z serwera z otwartym portem, ale będzie postrzegany jako próba połączenia. Idealnie byłoby, gdybyś mógł skorzystać z usługi „echo” (port TCP 7) ... ale tak naprawdę nie możesz, ponieważ jest teraz domyślnie wyłączony wszędzie. W każdym razie, jeśli możesz poprosić kogoś o włączenie go dla ciebie na maszynie, którą chcesz przetestować, program mógłby użyć tego, aby sprawdzić czas obchodzenia pakietów w połączeniu TCP.

To powiedziawszy, prawdopodobnie masz na komputerze polecenie „tracepath”; jest podobny do traceroute, ale nie używa TCP ani ICMP, ale UDP. W przypadku TCP istnieją różne narzędzia, możesz spróbować hping .

Alternatywą dla ping, możesz użyć „netstat”

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

-a = wszystko, -n = adres i numer portu lokalnego końca gniazda, -t = tcp, -p = program

-u = udp.