tcp için ping alternatifi?


12

Bu, ağ 'kalitesini' kontrol etmek için yaygın bir görevdir - gecikme süresi, bırakılan paket sayısı vb. Ancak 'ping'in bir takım dezavantajları vardır: - ICMP kullanır. Birçok ISS'nin ICMP ve TCP trafiği için farklı şekillendiricileri vardır, bu nedenle 'ping' 10ms gecikme gösterir, ancak TCP bağlantıları 1000ms + ile karşılaşır. - Çok az miktarda paket gönderir. Varsayılan olarak, saniyede bir paket. TCP protokolü paket kaybını tolere ettiği için (çok iyi çalışabilir yarım paketler kaybolur - normaldir), ping'in "% 30 paket kaybı" öldürme bağlantısını veya kesinlikle normal olup olmadığını kesinlikle belirsizdir.

Peki, ICMP yerine TCP bağlantısı kullanan ve internet bağlantı kalitesini kontrol eden ping için alternatif var mı?


% 30'luk ping kaybı, bu adresler arasındaki diğer bağlantılar için ölümdür. % 10 ölüme yakın. % 1 muhtemelen ciddi sorunlar görmeye başlamadan önceki sınırdır.
Jonesome

Yanıtlar:


14

TCP'nin paket kaybı / paket siparişi sorunlarını tolere edebileceğine bakılmaksızın, "nüfus" yeterince büyükse, yani 100 ping'den fazla ise,% 30'luk bir ping kaybı hala oldukça önemlidir.

Ancak soruyu cevaplamak için nmap'e bakabilirsiniz. Eminim örnekler kısa sürede sular altında kalacaktır :)

Daha da önemlisi, sadece gidiş-dönüş süresi istemiyorsunuz, makinenizden sunucuya ve her sıçramada performansı gerçekten görmek istiyorsunuz.

Bunu yapabilirsiniz traceroute- ancak bunun en yaygın bulunan sürümü ICMP veya UDP kullanılarak yapılır, ancak arayın tcp traceroute- ve buradan başlayın.

İşte siz çalışırken denemek için bazı eğlenceli araçlar ...

İşte bir örnek 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

Saatlerdir paketto bulmaya çalışıyorum ama içeriğin ve içeriğin çoğunu tamamen unutmuştum. Bağlantı için teşekkürler!
clee


3

Ben şahsen mtr ( http://www.bitwizard.nl/mtr/ ) büyük bir hayranıyım, mtr hem icmp hem de udp kullanarak çalışabilen ncurses tabanlı bir traceroute klonudur. Belirli bir sunucuya bağlantınızdaki zayıf noktaları gösterir ve bu şekilde müdahaleci değildir.

Gerçekten bazı yük testleri geldiğinde iperf (istemci / sunucu olan) ile gitmek istiyorum.


Ayrıca, ilgilenen herkes için bir MTR GTK varyantı var
Kent Fredric

2

Windows için tcping gibi bir şey kullanabilirsiniz:
http://www.elifulkerson.com/projects/tcping.php

Ve Linux için en iyi yardımcı program, daha önce de belirtilmiştir 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

1

ICMP paketleri genellikle daha yavaş gönderilir (eğer bir fark varsa), çünkü çoğu ağ onlara pititize olur, özellikle ping paketleri. Genel olarak, ICMP ve TCP yanıtlarından bu tür farklı sonuçlar görüyorsanız, sorun ya aşırı yüklenmiş bir sunucu ya da yol boyunca bir güvenlik duvarında belirli bir TCP şekillendirmesidir.

Araştırmak gerekir traceroute -P tcp, tcptraceroute, lftve tabii ki telnet.


"Yavaş" ı tanımlayın. Cevabınız yanlış. Deprioritize edilmiş paketler belirgin şekilde "yavaşladı" değil, sadece düşürülmeleri daha olasıdır. Örneğin, TCP için daha fazla yeniden iletim ile sonuçlandığından, akışın daha yavaş görünmesine neden olur, ancak tek bir paket yavaşlamaz veya eğer öyleyse sadece marjinal olarak. Bunun yalnızca yavaş bağlantıları, örneğin DSL uç noktalarını etkileyeceğini; internetin kendisinde, zorlanmadıkça, herkesin bu tür paketleri filtrelemesini rahatsız edecek çok şey var.
niXar

1
Tabii, "yavaş" tembel olduğunu, "düşme olasılığı daha yüksek" olduğunu doğrudur. İnternette bu kadar nadir değildir, sadece bazılarını mtrağdaki çeşitli konumlara ayarlayın ve sık sık çeşitli ağların çeşitli noktalarda ICMP paketleri teslim etme konusunda sorunları olduğunu fark edeceksiniz.
Alex J

1

Bu tür ağ parametrelerini ölçmek için bazı QoS uygulamaları kullanabilirsiniz. Örneğin:

NetPerf (www.netperf.org/netperf/): Netperf, birçok farklı ağ türünün performansını ölçmek için kullanılabilecek bir ölçüttür. Hem tek yönlü verim hem de uçtan uca gecikme için testler sağlar. Şu anda netperf tarafından ölçülebilen ortamlar şunları içerir:

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

VEYA

IPerf (sourceforge.net/projects/iperf) Iperf, NLANR / DAST tarafından maksimum TCP ve UDP bant genişliği performansını ölçmek için modern bir alternatif olarak geliştirilmiştir. Iperf, çeşitli parametrelerin ve UDP özelliklerinin ayarlanmasına izin verir. Iperf bant genişliği, gecikme titremesi, datagram kaybı rapor eder.


1

kontrol hping ve sonra bir göz Bing


hping iyidir, ancak winpcap gerektirir. Pcap, bu araçları kullanabilmenin tek yolu gibi görünüyor mu?
grigoryvp

Yuck ... Bunu bilmiyordum. Bunu HP donanımında gölgeleyen - HP arayüzü ekip yazılımı bazı winpcap kütüphanelerini kullanıyor gibi görünüyor. - Bunu wireshark takmaya çalışırken öğrendim.
Matthew

1

TCP% 50 paket kaybını "tolere edemez". Basit bir nedenden ötürü sadece durma noktasına öğütülür: iletim hızını paket kaybına göre uyarlar. Paketler kaybolduğunda, tıkanıklığı gösterdikleri anlaşılır. Trafikten bağımsız olarak paketlerin% 50'sini ( rastgele bir güvenlik duvarı kuralıyla) düşürürseniz, giderek azalan bir bant genişliği kullanılabilirliği göreceksiniz.

Ayrıca ISS'lerin TCP'ye karşı ICMP'yi şekillendirdiğinden şüpheliyim. Bazıları yapabilir, çünkü orada gerçekten aptal insanlar var, ama bunu yapmak pek mantıklı değil. Çoğu tüm bağlantıyı şekillendirecek veya tıkanıklık nedeniyle "kendini şekillendirecektir". Her iki durumda da paketler tipik olarak rastgele düşer.

Bununla birlikte, TCP ile ping yapabilirsiniz, ancak birkaç uyarı var. Birincisi, sadece ilk bağlantı noktasını bir TCP bağlantısında göndermektir; bu, açık bağlantı noktasına sahip bir sunucudan yanıt alacaktır, ancak bağlantı girişimi olarak görülecektir. İdeal olarak "echo" hizmetini (TCP bağlantı noktası 7) kullanabilirsiniz ... ancak aslında her yerde varsayılan olarak devre dışı bırakıldığı için yapamazsınız. Her neyse, birisini test etmek istediğiniz makinede sizin için etkinleştirmesini sağlayabilirseniz, bir program bunu bir TCP bağlantısı içindeki paketlerin gidiş-dönüş süresini kontrol etmek için kullanabilir.

Bununla birlikte, muhtemelen makinenizde "tracepath" komutu yüklüdür; traceroute'a benzer ancak TCP veya ICMP'yi değil UDP'yi kullanır. TCP için orada çeşitli yardımcı programlar vardır, hping deneyebilirsiniz .


0

Ping alternatifi, 'netstat' kullanabilirsiniz

Seçenekler: 1.netstat -antp 2.netstat -anup

-a = tümü, -n = Soketin yerel ucunun adresi ve bağlantı noktası numarası, -t = tcp, -p = program

-u = udp.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.