이 연결에는 웹페이지 시간 초과 및 느린 전송 속도와 같은 심각한 연결 문제가 있습니다. USB 모뎀(Huawei E303c)을 사용하여 액세스하는 무선 HSDPA 연결입니다.
실행하면 mtr google.com다음과 같은 출력이 제공됩니다.
해당 IP의 높은 패킷 손실은 내 ISP가 속도를 제한하고 연결을 방지하려고 한다는 신호입니까? 이 패킷 손실은 ISP 측의 오류입니까, 아니면 이러한 유형의 네트워크가 구현되는 일반적인 방식입니까?
편집 1: 이 게시물은 문제에 대해 많이 밝히지 않으므로 다음 게시물은여기
편집 2: 추적 경로 분석을 읽는 동안 mtr다음을 발견했습니다.이 페이지.그것은 말한다 :
후속 홉에서는 지속되지 않는 한 홉의 패킷 손실이 있는 경우 손실은 다음으로 인해 발생합니다.ICMP 제한.
답변1
아니요. 해당 IP는 로컬에서 ICMP 오류를 생성하는 형편없는 작업을 수행합니다. 그 증거는 그 지점을 지나간 지점이 잘 반응한다는 것입니다. 그 점에 정말로 잘못된 것이 있다면 그 이후의 모든 것도 나쁠 것입니다.
라우터는 라우팅에 최적화되어 있습니다. 코어 라우터는 고도로 최적화된 하드웨어 경로를 통해 트래픽이 통과하도록 합니다. 그러나 로컬에서 트래픽을 생성해야 하는 경우 해당 트래픽을 프로세스 수준으로 전달해야 합니다. 그리고 프로세스 수준에서 발생하는 모든 라우팅 작업이 우선순위를 갖습니다. 그래서 지연되거나 신뢰할 수 없는 경우가 많습니다.
이는 경로의 신뢰성이나 처리량에 대해서는 아무런 의미가 없습니다.
답변2
해당 IP의 높은 패킷 손실은 내 ISP가 속도를 제한하고 연결을 방지하려고 한다는 신호입니까?
이는 조절의 징후일 수 있지만 제가 본 바로는 패킷 손실이 발생하는 위치에 따른 경우인지 의심스럽습니다. 하지만 간헐적이지 않고 지속적으로 발생한다면 그만큼 패킷 손실이 크다는 것입니다.정상이 아니다. 읽어.
이 패킷 손실은 ISP 측의 오류입니까, 아니면 이러한 유형의 네트워크가 구현되는 일반적인 방식입니까?
"이러한 유형의 네트워크가 구현되는 일반적인 방법"은 여기서 보고 공유하는 내용에 대한 가장 간단한 설명입니다. 기억하세요: 인터넷은 먼저 탄력성을 갖도록 구축되었으며 "손상"이 발생하면 속도가 뒷전으로 밀려납니다.
즉,일관된79% 패킷 손실은정상과는 거리가 멀다. 여기 미국에서 유사한 Traceroute를 수행하면 mtr명확한 문제가 없는 한 도로 충돌/패킷 손실 "블랙홀"이 실제로 없습니다.
Traceroute 출력을 보면 mtr( ) 문제가 있는 IP는 115.255.253.17ISP 단계를 훨씬 넘어서 더 큰 인터넷의 일부로 간주될 수 있는 것 같습니다. 그래서 나는 그것이 ISP 기반 조절인지 의심합니다. 특히 Traceroute는 ISP에 연결된 것으로 보이는 mtrISP의 .bol.net.in스위치( 59.180.210.201및 )를 지나 발생하는 문제를 보여주는 것 같습니다.59.180.210.202Mahanagar Telephone Nigam Limited (MTNL).
GeoIP 데이터를 자세히 살펴보면 115.255.253.17뭄바이 마하라슈트라에 기반을 둔 IP 주소임을 알 수 있습니다. 그렇다면 뭄바이 자체의 인터넷 일부에서 발생하는 인터넷 중단/“딸꾹질”을 볼 수 있습니까? 그리고 whois동일한 IP 주소에 대한 조회를 통해 추가 조사를 수행하면 115.255.253.17이것이 다음의 일부임을 알 수 있습니다.신뢰 그룹, 이는 인도의 대규모 인프라 제공업체인 것으로 보입니다.
저에게 묻는다면, 백본 인프라 제공업체가 이와 같이 특정 하위 수준 가입자 네트워크의 사용자로부터 트래픽을 제한할지는 의심스럽습니다. 왜 MTNL(Mahanagar Telephone Nigam Limited) 시스템의 모든 사용자가 Reliance Group 백본 네트워크에 의해 이와 같은 처벌을 받아야 합니까? 스위치 의 홉과 같은 즉각적인 스위치의 처음 몇 홉 주변에서 이러한 손실이 발생하는 경우 제한이 있다고 간주합니다 .bol.net.in.
여기 미국에서의 내 관점에서 볼 때 나는 이것을 정상적이고 간헐적인 인터넷 딸꾹질로 분류할 것입니다. 그리고 Traceroute가 완료되었다는 사실은 mtr이러한 문제를 해결할 수 있는 인터넷의 탄력성에 기인할 수 있습니다. 더도 말고 덜도 말고...하지 않는 한이 조건은간헐적이지 않음하지만 오히려일관된; 그렇다면 이상한 일이 일어나고 있으며 최종 사용자 측에서 이를 진단할 수 있는 쉬운 방법이 없습니다.
말한 대로, 난 그냥인도의 망 중립성 개념에 대해 읽어보세요인도에는 망 중립성을 규제하는 법률이 없는 것 같습니다. 따라서 여러분도 아시다시피 Reliance Group은 의도적으로 뭔가를 하고 있습니다. 하지만 솔직히 내 직감은 누군가 실수로 어딘가에서 데이터 스위치를 잘못 구성했고 당신만이 이를 알아차릴 수 있다는 것입니다. 그래서 저는 열린 마음으로 이 mtrTraceroute를 Mahanagar Telephone Nigam Limited(MTNL)의 기술 지원 담당자와 공유하여 그들이 말하는 내용을 확인하는 것이 좋습니다.
10번 중 9번은 컴퓨터에서의 실수, 그리고 솔직히 말해서 많은 실수가 악의적인 것이 아니라 오히려 무능력에 근거한 것입니다. 여기 미국의 기술 인프라에서 더 이상한 일이 일어나는 것을 본 적이 있으므로 이를 ISP에 보고하고 그들이 어떻게 반응하는지 확인해 볼 가치가 있습니다.