TCP에 대한 핑 대안?


12

대기 시간, 손실 된 패킷 수 등 네트워크 '품질'을 확인하는 것이 일반적인 작업입니다. 그러나 '핑'에는 여러 가지 단점이 있습니다.-ICMP를 사용합니다. 많은 ISP가 ICMP 및 TCP 트래픽에 대해 다른 셰이퍼를 가지고 있으므로 'ping'은 10ms 대기 시간을 표시하지만 TCP 연결은 1000ms 이상을 경험합니다. -매우 적은 양의 패킷을 보냅니다. 기본적으로 초당 1 개의 패킷. TCP 프로토콜은 패킷 손실을 허용하므로 (패킷 손실이 절반이면 정상으로 작동합니다.) 핑의 "30 % 패킷 손실"로 인해 연결이 끊어 지거나 절대적으로 정상인지는 확실하지 않습니다.

그렇다면 ICMP 대신 TCP 연결을 사용하고 인터넷 연결 품질을 확인하는 것이 Ping의 대안입니까?


% 30의 핑 손실은 해당 주소 사이의 다른 연결에 대한 사망입니다. % 10이 거의 사망했습니다. 심각한 문제가 발생하기 전에 % 1이 (가) 아마도 한계입니다.
Jonesome Reinstate Monica

답변:


14

TCP가 패킷 손실 / 패킷 순서 문제를 허용 할 수 있다는 사실과 상관없이 "인구"가 충분히 큰 경우 (즉, 100 개 이상의 핑) 30 %의 핑 손실은 여전히 ​​상당히 중요합니다.

그러나 질문에 대답하기 위해 nmap을 볼 수 있습니다. 나는 곧 예제가 범람 될 것이라고 확신한다 :)

더 중요한 것은 왕복 시간 만 원하지는 않으며 실제로 컴퓨터에서 서버까지 성능을 확인하고 모든 (가능한) 홉마다 다시 돌아 가기를 원한다는 것입니다.

당신은이 작업을 수행 할 수 있습니다 traceroute- 그러나이 가장 일반적으로 발견 버전 ICMP 또는 UDP를 사용하여 수행됩니다,하지만 검색 tcp traceroute- 거기에 시작합니다.

여기있는 동안 시도해 볼만한 재미있는 도구가 있습니다.

여기에 예가 있습니다 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

나는 몇 시간 동안 paketto를 찾으려고 노력했지만 이름과 컨텍스트의 대부분을 완전히 잊어 버렸습니다. 링크 주셔서 감사합니다!
clee


3

나는 개인적으로 mtr ( http://www.bitwizard.nl/mtr/ ) 의 큰 팬입니다 .mtr 은 icmp와 udp를 모두 사용하여 작동 할 수있는 ncurses 기반 traceroute 클론입니다. 특정 호스트에 대한 링크의 약점을 표시하며 비침 입적입니다.

실제로로드 테스트에 관해서는 iperf (클라이언트 / 서버)와 함께 갈 것입니다.


또한 관심있는 사람을위한 MTR의 GTK 변형이 있습니다.
Kent Fredric

2

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

1

ICMP 패킷은 일반적으로 속도가 느려집니다 (차이가있는 경우). 대부분의 네트워크가 우선 순위를 정하기 때문에, 특히 핑 패킷입니다. 일반적으로 ICMP 및 TCP 응답에서 이러한 결과가 발생하는 경우 문제는 과부하 된 서버 또는 방화벽을 따라 특정 TCP가 형성되는 것입니다.

당신은 조사해야합니다 traceroute -P tcp, tcptraceroute, lft물론 telnet.


"느리게"를 정의하십시오. 당신의 대답은 틀 렸습니다. 우선 순위가 해제 된 패킷은 눈에 띄게 "느려진"것이 아니라 삭제 될 가능성이 높습니다. 예를 들어 TCP의 경우 재전송이 더 많이 발생하지만 단일 패킷의 속도가 느려지지 않거나 조금이라도 느리게 표시되므로 흐름이 느리게 나타납니다. 이는 DSL 엔드 포인트와 같은 저속 링크에만 영향을 미칩니다. 인터넷 자체에서는 그러한 패킷을 강제로 필터링하지 않는 한 이러한 패킷 필터링을 방해하는 일이 너무 많습니다.
niXar

1
물론 "느리게"느리다는 말은 "떨어질 가능성이 높다"는 것이 정확합니다. 인터넷에서 그렇게 드문 일이 아니며, 인터넷 mtr을 통해 다양한 위치에 일부를 설정 하면 다양한 네트워크에서 다양한 지점에서 ICMP 패킷을 전달하는 데 문제가 있다는 것을 알 수 있습니다.
Alex J

1

일부 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는 대역폭, 지연 지터, 데이터 그램 손실을보고합니다.


1

hping을 확인한 다음 bing을 살펴보십시오.


hping은 좋지만 winpcap이 필요합니다. pcap이 윈도우가 이러한 도구를 사용할 수있는 유일한 방법 인 것 같습니다.
grigoryvp

...... 몰랐어 HP 인터페이스 팀 구성 소프트웨어는 일부 winpcap 라이브러리를 사용하는 것으로 보입니다. -wireshark를 설치할 때 이것을 발견했습니다.
Matthew

1

TCP는 50 % 패킷 손실을 "허용"할 수 없습니다. 간단한 이유로 중단 될 것입니다. 패킷 손실에 따라 전송 속도를 조정합니다. 패킷이 손실되면 정체를 나타내는 것으로 이해됩니다. 트래픽에 관계없이 패킷의 50 %를 삭제하면 (예 : 임의 삭제 방화벽 규칙으로) 대역폭 가용성이 계속 감소합니다.

게다가 ISP가 ICMP와 TCP를 형성하는 것은 의심 스럽다. 어리석은 사람들이 있기 때문에 어떤 사람들은 할 수도 있지만 그렇게하는 것은 의미가 없습니다. 대부분은 전체 연결을 형성하거나 혼잡으로 인해 "자신을 형성"합니다. 두 경우 모두 패킷은 일반적으로 임의로 삭제됩니다.

즉, TCP로 ping 할 수 있지만 몇 가지주의 사항이 있습니다. 첫 번째는 TCP 연결로 초기 패킷을 보내는 것입니다.이 패킷은 열린 포트가있는 서버에서 응답을 이끌어 낼 수 있지만 연결 시도로 간주됩니다. 이상적으로는 "echo"서비스 (TCP 포트 7)를 사용할 수 있지만 실제로는 기본적으로 모든 곳에서 기본적으로 비활성화되어 있기 때문에 사용할 수 없습니다. 어쨌든, 테스트하려는 머신에서 누군가가 당신을 위해 그것을 가능하게 할 수 있다면, 프로그램은 이것을 사용하여 TCP 연결 내부의 패킷에 대한 소요 시간을 확인할 수 있습니다.

즉, "tracepath"명령이 시스템에 설치되어있을 것입니다. traceroute와 비슷하지만 TCP 나 ICMP를 사용하지 않고 UDP를 사용합니다. TCP에는 다양한 유틸리티가 있으며 hping 을 시도 할 수 있습니다 .


0

ping 대신 'netstat'를 사용할 수 있습니다

옵션 : 1.netstat -antp 2.netstat -anup

-a = all, -n = 소켓 로컬 끝의 주소 및 포트 번호, -t = tcp, -p = 프로그램

-u = udp.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.