alternativa de ping para tcp?


12

É uma tarefa comum verificar a 'qualidade' da rede - latência, número de pacotes descartados etc. Mas 'ping' tem várias desvantagens: - Ele usa ICMP. Muitos ISP têm modeladores diferentes para o tráfego ICMP e TCP, portanto, 'ping' mostrará latência de 10ms, mas as conexões TCP terão 1000ms +. - Envia uma quantidade muito pequena de pacotes. Por padrão, um pacote por segundo. Como o protocolo TCP tolera a perda de pacotes (ele pode funcionar muito bem com a perda de metade dos pacotes - é normal), não é absolutamente claro se a "30% de perda de pacotes" do ping está matando a conexão ou se é absolutamente normal.

Portanto, existe alguma alternativa para o ping que usa conexão TCP em vez do ICMP e verifica a qualidade da conexão com a Internet?


A perda de ping de% 30 é a morte para qualquer outra conexão entre esses endereços. % 10 está próximo da morte. % 1 é provavelmente o limite antes de você começar a ver problemas sérios.
Jonesome Restabelece Monica

Respostas:


14

Independentemente do TCP poder tolerar problemas de perda de pacotes / pedidos de pacotes, uma perda de ping de 30% ainda é bastante significativa se a "população" for grande o suficiente - ou seja, mais do que 100 pings.

Mas, para responder à pergunta, você pode olhar para o nmap. Tenho certeza de que alguns exemplos virão em breve :)

Mais importante, porém, você não quer apenas um tempo de ida e volta, você realmente deseja ver o desempenho da sua máquina no servidor e voltar a cada salto possível.

Você pode fazer isso com traceroute- no entanto, a versão mais encontrada disso é feita usando ICMP ou UDP, mas procure tcp traceroute- e comece por aí.

Aqui estão algumas ferramentas divertidas para experimentar enquanto você está nisso ...

Aqui está um exemplo com 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

Estou tentando encontrar paketto há horas, mas havia esquecido completamente o nome e a maior parte do contexto. Obrigado pelo link!
Clee


3

Pessoalmente, sou um grande fã do mtr ( http://www.bitwizard.nl/mtr/ ), o mtr é um clone de traceroute baseado em ncurses que pode funcionar usando o icmp e o udp. Ele mostra os pontos fracos no seu link para um determinado host e, dessa forma, não é invasivo.

Quando realmente se trata de alguns testes de carga, eu usava o iperf (que é cliente / servidor).


Também, há uma variante GTK de MTR para qualquer pessoa interessada
Kent Fredric

2

Para Windows, você pode usar algo como tcping:
http://www.elifulkerson.com/projects/tcping.php

E para Linux, o melhor utilitário já é mencionado 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

Os pacotes ICMP geralmente são entregues mais lentamente (se houver alguma diferença), porque a maioria das redes os desvaloriza, principalmente os pacotes de ping. Geralmente, se você estiver vendo resultados tão divergentes das respostas ICMP e TCP, o problema é um servidor sobrecarregado ou a configuração específica de TCP em um firewall ao longo do caminho.

Você deve investigar traceroute -P tcp, tcptraceroute, lfte, é claro telnet.


Defina "mais devagar". Sua resposta está errada. Pacotes despriorizados não são visivelmente "abrandados", eles são apenas mais propensos a serem descartados. Isso faz com que o fluxo pareça mais lento, pois para o TCP, por exemplo, resulta em mais retransmissões, mas um único pacote não fica mais lento ou, se estiver, apenas marginalmente. Observe que isso afetaria apenas links lentos, por exemplo, pontos de extremidade DSL; na própria internet, há muita coisa acontecendo para alguém se incomodar em filtrar esses pacotes, a menos que seja forçado.
NiXar 29/05/2009

1
Certamente, dizer "mais lento" era preguiçoso, "mais provável de ser descartado" é preciso. Também não é incomum na rede, basta configurar alguns mtrem vários locais da rede e você perceberá com bastante frequência que várias redes têm problemas para entregar pacotes ICMP em vários pontos.
287 Alex J

1

Você pode usar algum aplicativo de QoS para medir esse tipo de parâmetros de rede. Por exemplo:

NetPerf (www.netperf.org/netperf/): O Netperf é uma referência que pode ser usada para medir o desempenho de muitos tipos diferentes de rede. Ele fornece testes para taxa de transferência unidirecitonal e latência de ponta a ponta. Os ambientes atualmente mensuráveis ​​pelo netperf incluem:

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

OU

IPerf (sourceforge.net/projects/iperf) O Iperf foi desenvolvido pela NLANR / DAST como uma alternativa moderna para medir o desempenho máximo da largura de banda TCP e UDP. O Iperf permite o ajuste de vários parâmetros e características UDP. O Iperf relata largura de banda, atraso no jitter, perda de datagramas.


1

confira hping e depois dê uma olhada no bing


hping é bom, mas requer winpcap. Parece que o pcap é a única maneira de o Windows usar essas ferramentas?
grigoryvp

Eca ... Não sabia disso. Isso atrapalha o hardware da HP - o software de formação de interface da HP parece usar algumas bibliotecas winpcap. - Descobri isso ao tentar instalar o wireshark.
315 Matthew

1

O TCP não pode "tolerar" 50% de perda de pacotes. Ele simplesmente trará uma parada, por uma razão simples: adapta sua velocidade de transmissão com base na perda de pacotes. Quando os pacotes são perdidos, entende-se que indicam congestionamento. Se você eliminar 50% dos pacotes (digamos, com uma regra aleatória de firewall de descarte) independentemente do tráfego, haverá uma disponibilidade cada vez menor da largura de banda.

Além disso, duvido que os ISPs moldem o ICMP vs o TCP. Alguns podem fazer, pois existem pessoas realmente estúpidas por aí, mas não faz muito sentido fazê-lo. A maioria moldará toda a conexão ou "se moldará" devido ao congestionamento. Em ambos os casos, os pacotes geralmente são descartados aleatoriamente.

Dito isto, você pode executar ping com o TCP, mas existem várias advertências. O primeiro é apenas enviar o pacote inicial em uma conexão TCP, o que provocará uma resposta de um servidor com uma porta aberta, mas será visto como uma tentativa de conexão. Idealmente, você poderia usar o serviço "eco" (porta TCP 7) ... mas na verdade não pode, porque agora está desativado por padrão em qualquer lugar. De qualquer forma, se você conseguir alguém para habilitá-lo na máquina que deseja testar, um programa poderá usá-lo para verificar o tempo de recuperação de pacotes dentro de uma conexão TCP.

Dito isto, você provavelmente tem o comando "tracepath" instalado em sua máquina; é semelhante ao traceroute, mas não usa TCP ou ICMP, mas UDP. Para o TCP, existem vários utilitários por aí, você pode tentar hping .


0

A alternativa ao ping, você pode usar 'netstat'

Opções: 1.netstat -antp 2.netstat -anup

-a = all, -n = Endereço e número da porta da extremidade local do soquete, -t = tcp, -p = program

-u = udp.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.