핑 결과 해석

yahoo.com을 핑 (ping)하고 있으며 결과에 당황합니다.

C:\Users\jon>ping -t yahoo.com

Pinging yahoo.com [98.138.253.109] with 32 bytes of data:
Reply from 98.138.253.109: bytes=32 time=195ms TTL=46
Reply from 98.138.253.109: bytes=32 time=230ms TTL=44
Reply from 98.138.253.109: bytes=32 time=175ms TTL=45
Reply from 98.138.253.109: bytes=32 time=208ms TTL=44
Reply from 98.138.253.109: bytes=32 time=180ms TTL=46
Reply from 98.138.253.109: bytes=32 time=206ms TTL=44
Reply from 98.138.253.109: bytes=32 time=209ms TTL=44
Reply from 98.138.253.109: bytes=32 time=173ms TTL=46
Reply from 98.138.253.109: bytes=32 time=170ms TTL=46
Reply from 98.138.253.109: bytes=32 time=224ms TTL=45
Reply from 98.138.253.109: bytes=32 time=200ms TTL=45
Reply from 98.138.253.109: bytes=32 time=172ms TTL=46
Reply from 98.138.253.109: bytes=32 time=258ms TTL=44

패킷이 대상에 도달하기 위해 통과하는 홉 수로 TTL 값을 모호하게 이해하지만 짧은 시간에 TTL이 어떻게 극적인 +/- 1 변화를 가질 수 있는지 이해하지 못합니다.

또한 Yahoo는 지속적인 ping이 약 20 개의 패킷 이후에 시간 초과되기 시작함에 따라 일종의 속도 제한을 구현 한 것으로 보입니다. 이것이 정상입니까? bing.com도 답장을하지 않습니다!

google.com을 핑 (ping)하면 TTL이 일관됩니다.

Twitter.com을 핑 (ping) 할 때 때때로 TTL = 249를 얻지 만 보통 TTL-58을 얻습니다.

무슨 일이야? 내 ISP가 좋지 않거나 불길한 설명이 있습니까?

여러 네트워크에서로드 밸런싱이 원인 일 가능성이 높습니다. 각 핑은 다른 경로를 사용하므로 차이 TTL 값이 있습니다.

또한 검색 엔진 제공 업체가 TTL로 이상한 일을했지만 다른 방식으로 다른 경로를 통과하는 것에 대해 읽었습니다.

TTL 값은 다른 운영 체제에서 제공 될 때 다릅니다.

• 윈도우 : 128
• 리눅스 : 64
• 시스코 : 255
• 솔라리스 : 255

예, 일정 시간이지나거나 속도 제한에 도달하면 일부 사이트는 ICMP에 응답하지 않습니다. 8.8.8.8의 Google DNS는 결국 잠시 후에 중단된다고 생각합니다.

다른 사람들은 지연 시간의 변화를 설명하기 위해 다중 경로 시나리오를 언급했습니다. ECMP (Equal Cost Multi Path) 링크를 사용하면 핑에서 Yahoo에 제공 한 출력에 따라 시나리오가 생길 수 있습니다.이 지연은 결과간에 지연이 발생하지만 합리적으로 일관됩니다. 따라서 트래픽이 길이 (지연)가 변하는 동일한 2 개 또는 3 개의 경로를 통해 해시되는 것처럼 보입니다 (추측 일 뿐이지 만 제공된 정보에 대해서는 아무도 확신 할 수 없습니다).

또한 Yahoo는 지속적인 ping이 약 20 개의 패킷 이후에 시간 초과되기 시작함에 따라 일종의 속도 제한을 구현 한 것으로 보입니다. 이것이 정상입니까? bing.com도 답장을하지 않습니다!

일부 네트워크는 ICMP 트래픽을 필터링하여 매우 귀찮습니다. 따라서 "Pings at no ping"시나리오를 설명 할 수 있습니다. 일부 회신 또는 제한된 회신이있는 시나리오의 경우 네트워크는 Cisco의 Control Plan Policing (또는 공급 업체에 상응하는) 과 같은 기술을 구현할 수 있습니다 .

Twitter.com을 핑 (ping) 할 때 때때로 TTL = 249를 얻지 만 보통 TTL-58을 얻습니다.

결과 변동이 덜 안정적인 경우 동일 비용 다중 경로 경로가 존재하거나 경로의 일부 위치에서 링크 문제로 인해 트래픽 엔지니어가 변경 될 수 있습니다. 주어진 정보로 다시 말할 수는 없습니다.

이러한 패킷에 대한 TTL의 분산은 패킷을 처리하는 데 시간이 오래 걸리는 라우터에 의해 설명 될 수 있습니다. 라우터를 통과하는 시간이 1 초 미만인 경우 TTL은 각 홉마다 하나씩 감소합니다. 라우터를 통해 걸린 시간이 1 초보다 큰 경우 TTL이 1 초가 아닌 2 초씩 감소합니다.

참조 RFC791의 29 페이지 :

살 시간

The time to live is set by the sender to the maximum time the
datagram is allowed to be in the internet system.  If the datagram
is in the internet system longer than the time to live, then the
datagram must be destroyed.

This field must be decreased at each point that the internet header
is processed to reflect the time spent processing the datagram.
Even if no local information is available on the time actually
spent, the field must be decremented by 1.  The time is measured in
units of seconds (i.e. the value 1 means one second).  Thus, the
maximum time to live is 255 seconds or 4.25 minutes.  Since every
module that processes a datagram must decrease the TTL by at least
one even if it process the datagram in less than a second, the TTL
must be thought of only as an upper bound on the time a datagram may
exist.  The intention is to cause undeliverable datagrams to be
discarded, and to bound the maximum datagram lifetime.

Some higher level reliable connection protocols are based on
assumptions that old duplicate datagrams will not arrive after a
certain time elapses.  The TTL is a way for such protocols to have
an assurance that their assumption is met.