Já experimentou o ping bitly.com a partir do PC1 e do PC2? Tenha em mente que nem todos os sistemas responderão aos pacotes de solicitação de eco ICMP emitidos por ping e traceroute comandos. Eu tentei ping bitly.com
de sistemas, um Linux, um Microsoft Windows e um sistema OS X, em três locais. Todos mostravam "solicitação expirada" ou 100% de perda de pacotes, mas eu podia acessar o site deles. Então, parece-me que os pacotes de solicitação de eco ICMP estão sendo bloqueados em algum lugar ao longo do caminho.
Isso não é incomum. Muitas empresas e organizações bloquearão esse tipo de tráfego por vários motivos. Às vezes, isso é feito em um firewall por motivos de segurança, para que entidades externas não possam mapear sua rede. Às vezes, os roteadores não respondem ou dão a esse tráfego prioridade muito baixa por motivos de desempenho, portanto, você pode ver asteriscos em alguns saltos por esses motivos, embora o sistema esteja processando outros tipos de tráfego de rede nominalmente.
A captura de tela que você postou da saída de um comando tracert mostra os tempos de ida e volta dos pacotes enviados aos roteadores o caminho de rede do sistema que está executando o comando para o host final. Eu posso ver que o tempo de ida e volta (RTT) para pacotes para ix-0-100.tcore1.MLV-Mumbai-as6453.net [180.87.38.5]
é de cerca de 21 milissegundos. Mas então, no próximo salto, if-9-5.tcore1.WYN-Marseille.as6453.net [80.231.217.17]
no salto 9, o RTT salta dramaticamente para cerca de 127 ms com um pacote sendo perdido. Isso não é um RTT horrível nesse ponto, mas também não é ótimo. Quando fiz um tracert para o www.bitly.com a partir de três locais separados, onde o serviço de rede é fornecido por três provedores de serviços de Internet diferentes, embora em um raio de 50 milhas, eu vejo RTTs em torno de 11 ms em um local. 18 ms em outro e 71 ms no terceiro. No hop 20 para o seu tracert, o RTT é de até um quarto de segundo. Novamente, isso não é horrível, mas também não é ótimo.
Embora eu não ache que a saída de tracert que você postou possa ser usada para discernir a causa da discrepância entre os sistemas em sua rede local (LAN). Eu também vejo todos os asteriscos para hops após te1-2.r1.colo-fo.ilg1.vrsn.net [69.58.176.198]
na maioria dos casos, embora eu tenha visto o próximo salto 69.58.176.194 responder ocasionalmente, então, talvez haja algum congestionamento de rede nesse salto ou o roteador está dando uma prioridade muito baixa ao tráfego ICMP .
No entanto, eu posso acessar www.bitly.com a partir de um navegador e quando Eu testei o tempo de resposta do site pingdom.com e mostrei um bom tempo de resposta para o site de Estocolmo na Suécia, afirmando que "o site é mais rápido que 49% de todos os sites testados ". Um teste WebsitePulse também mostrou um bom tempo de resposta.
Então, para explicar a discrepância entre os sistemas na sua LAN, os resultados são consistentes? Por exemplo, você já tentou várias vezes acessar www.bitly.com de PC1 e PC2 e pode acessar consistentemente www.bitly.com do PC2, mas não do PC1? E você testou o acesso ao Facebook de ambos os sistemas várias vezes? Ambos os sistemas estão usando o mesmo caminho de rede para obter acesso a sites externos? Por exemplo, um usa a conectividade de rede sem fio enquanto o outro está usando uma conexão com fio? Você está usando os mesmos servidores DNS para ambos os sistemas? Você pode verificar se ambos os sistemas estão usando o mesmo roteador como o primeiro salto e estão usando o mesmo Sistema de Nomes de Domínio (DNS) servidores nos sistemas Microsoft Windows usando o comando ipconfig/all
. Eles têm o mesmo gateway padrão e servidores DNS? Você está testando com o mesmo navegador em ambos os sistemas? O navegador em um sistema está configurado para usar um servidor proxy, enquanto o outro não usa um servidor proxy?