giải thích kết quả ping

Tôi đang làm phiền yahoo.com và tôi cảm thấy bối rối trước kết quả này.

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

Tôi mơ hồ hiểu giá trị TTL là số bước nhảy mà gói đi qua đích đến của nó, nhưng tôi không hiểu làm thế nào TTL có thể có phương sai +/- 1 kịch tính như vậy trong một khoảng thời gian ngắn như vậy.

Ngoài ra, có vẻ như Yahoo có một số loại giới hạn tỷ lệ được triển khai vì ping liên tục sẽ bắt đầu hết thời gian sau khoảng 20 gói. Điều này có bình thường không? bing.com thậm chí không trả lời tôi!

Khi ping google.com, các TTL là nhất quán.

Khi ping Twitter.com đôi khi tôi nhận được TTL = 249, nhưng thường là TTL-58.

Chuyện gì đang xảy ra vậy? Là ISP của tôi không tốt hoặc có một lời giải thích ít độc ác hơn?

Nhiều khả năng điều này là do cân bằng tải trên nhiều mạng. Mỗi ping sẽ có một đường dẫn khác nhau và theo đó sẽ có giá trị TTL khác nhau.

Tôi cũng đọc về các nhà cung cấp công cụ tìm kiếm làm những điều kỳ lạ với TTL, nhưng nó chỉ đi qua một tuyến đường khác.

Giá trị TTL khác nhau khi có nguồn gốc từ các hệ điều hành khác nhau:

• Windows: 128
• Linux: 64
• Cisco: 255
• Năng lượng mặt trời: 255

Và có, một số trang web sẽ ngừng phản hồi ICMP sau một khoảng thời gian nhất định hoặc khi đạt đến giới hạn tỷ lệ. Tôi tin rằng DNS của Google vào ngày 8.8.8.8 cuối cùng sẽ dừng lại sau một thời gian.

Những người khác đã đề cập đến kịch bản đa đường để giải thích sự thay đổi trong thời gian trễ. Với các liên kết ECMP (Chi phí nhiều đường dẫn bằng nhau), bạn có thể có một kịch bản theo đầu ra mà bạn đã cung cấp trong ping tới Yahoo, trong đó độ trễ thay đổi giữa các kết quả nhưng hợp lý nhất quán. Vì vậy, có vẻ như lưu lượng truy cập của bạn đang được băm trên cùng hai hoặc ba đường dẫn, với độ dài khác nhau (độ trễ) (mặc dù đó chỉ là suy đoán, tôi không ai có thể nói chắc chắn với thông tin được cung cấp).

Ngoài ra, có vẻ như Yahoo có một số loại giới hạn tỷ lệ được triển khai vì ping liên tục sẽ bắt đầu hết thời gian sau khoảng 20 gói. Điều này có bình thường không? bing.com thậm chí không trả lời tôi!

Một số mạng lọc lưu lượng ICMP mà tôi thấy cực kỳ khó chịu! Vì vậy, điều đó có thể giải thích cho kịch bản "không ping tất cả". Đối với các tình huống trong đó bạn có một số phản hồi hoặc trả lời hạn chế, mạng có thể đang triển khai một công nghệ như Chính sách kiểm soát kế hoạch kiểm soát của Cisco (hoặc nhà cung cấp tương đương của họ).

Khi ping Twitter.com đôi khi tôi nhận được TTL = 249, nhưng thường là TTL-58.

Khi bạn có biến thể kết quả kém ổn định hơn, các tuyến đường đa đường có chi phí không bằng nhau có thể xuất hiện hoặc thay đổi kỹ sư giao thông do sự cố liên kết ở một nơi nào đó trong đường dẫn. Một lần nữa, không thể nói với thông tin được đưa ra.

Phương sai của TTL trên các gói này có thể được giải thích bởi (các) bộ định tuyến đang mất nhiều thời gian để xử lý các gói. TTL giảm dần sau mỗi lần nhảy nếu thời gian qua bộ định tuyến nhỏ hơn một giây. Nếu thời gian thực hiện qua bộ định tuyến lớn hơn thì một giây sẽ bị giảm xuống bởi hai chứ không phải một.

Xem RFC791 trang 29:

Thời gian để sống

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.