đầu ra mtr với mất gói cao trên một bước nhảy

Tôi đang điều tra một khiếu nại về hiệu suất kém từ người dùng cuối truy cập vào trang web tôi giúp duy trì.

Tôi có hai đầu ra mtr này cho người dùng cuối, đầu tiên từ trang web:

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 198.199.92.253                    0.0%   200    7.3   4.2   0.9  89.6   8.0
 2. 69.22.130.37                      0.0%   200    0.4   2.5   0.3  51.4   8.0
 3. 69.22.143.170                    42.5%   200    1.3   2.0   1.1  47.9   4.9
 4. 69.22.143.165                     0.0%   200    2.3   6.4   1.6  56.9   9.7
 5. 206.223.116.86                    0.0%   200    2.5   3.0   1.8  14.1   1.5
 6. 64.125.24.1                       0.0%   200    3.0   6.9   2.2  65.7   9.9
 7. 64.125.26.230                     0.0%   200   56.3  61.4  55.6 119.0  10.0
 8. 64.125.24.33                      0.5%   200   76.4  78.9  76.0 116.1   7.1
 9. 64.125.29.38                      0.0%   200   73.9  77.5  73.4 238.8  13.4
10. 64.125.31.181                     0.5%   200  160.0 159.4 156.2 181.4   4.3
11. 64.125.32.93                      0.0%   200  156.9 157.8 155.9 217.0   6.8
12. 62.253.174.190                    0.0%   200  166.0 166.5 165.6 172.8   1.2
13. 62.253.175.217                    0.0%   200  162.1 163.1 161.7 200.4   4.2
14. 213.105.159.194                   0.0%   200  163.8 165.0 163.4 241.2   8.3
15. 81.97.112.218                     0.0%   200  164.7 166.5 164.5 220.0   7.4
16. ???

và thứ hai từ mạng của tôi:

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 216.16.235.1                      0.0%   115    0.4   0.4   0.3   0.6   0.1
 2. 216.16.232.37                     0.0%   115    0.9   0.9   0.6  18.8   1.7
 3. 216.16.255.141                    0.0%   115    0.8   0.7   0.6   1.1   0.1
 4. 216.16.255.130                    0.0%   114    1.0   1.0   0.8   1.4   0.1
 5. 24.153.3.141                      0.0%   114    1.9   3.6   1.5   6.5   1.2
 6. 64.71.241.97                      0.0%   114    3.4   5.3   3.3   7.4   1.1
 7. ???
 8. 64.124.128.193                   34.5%   114   18.9  19.2  18.7  39.0   2.3
 9. 64.125.21.74                      0.0%   114   19.2  20.4  18.9  49.9   5.0
10. 64.125.29.38                      0.0%   114   19.3  23.1  19.2  48.3   7.6
11. 64.125.27.186                     0.9%   114  105.2 106.1 105.1 137.8   3.2
12. 64.125.32.93                      0.0%   114  106.3 107.1 106.1 163.3   5.8
13. 62.253.174.190                    0.0%   114  181.8 123.5 115.8 206.3  20.9
14. 62.253.175.217                    0.0%   114  113.8 114.8 113.6 144.3   4.2
15. 213.105.159.194                   0.0%   114  115.3 115.9 115.2 163.5   4.6
16. 81.97.112.218                     0.0%   114  113.3 114.4 113.2 140.7   4.5
17. ???

Làm thế nào tôi nên giải thích những bước nhảy với mất gói MASSIVE? Tôi có xu hướng nghĩ rằng những bước nhảy đó có một số loại định tuyến không đối xứng đang diễn ra và một trong những đường dẫn bị tắc nghẽn.

Điều này có thể gây ra bất kỳ vấn đề cho người dùng cuối?

MTR sử dụng ICMP, thường bị giới hạn tốc độ trên internet do làm thế nào nó có thể bị lạm dụng để tạo ra các vấn đề (CPU cao, băng thông lãng phí, DoS, v.v.).

Khi bạn thấy đầu ra như thế này, nói chung đây là một dấu hiệu giới hạn tỷ lệ cho ICMP. Với một tìm kiếm trên web nhanh, tôi đã tìm thấy tài liệu này liên quan đến việc sử dụng MTR. Mặc dù nó không chính thức nhưng nó có vẻ tốt (ít nhất là với quét nhanh) và cung cấp các ví dụ về một số vấn đề bạn có thể tìm thấy khi sử dụng MTR.

Vì @YLearn đã viết ICMP phê duyệt trên bộ định tuyến với packloss có thể là nguyên nhân, vì việc trả lời các yêu cầu ICMP được thực hiện trong CPU trong khi việc chuyển tiếp các gói thường được thực hiện trong ASIC. Vì vậy, điều này không cần phải là một vấn đề cả.

Một hướng dẫn rất tốt về diễn giải đầu ra traceroute (và MTR) đã được Richard Steenbergen viết cách đây vài năm. Anh ấy đã trình bày rất hay về nó tại NANOG.

Tôi sẽ mở đầu điều này bằng cách nói rằng có, định tuyến bạn đề cập có thể là một phần của nó. Đó sẽ là con đường TRỞ LẠI đến máy chủ của bạn từ bước nhảy đó đang đi trên một con đường tắc nghẽn mà những người khác không có.

Chàng trai của tôi nghĩ: nếu đây là một vấn đề trong mặt phẳng dữ liệu trên bộ định tuyến cụ thể đó, tôi sẽ thấy mất gói cho tất cả các bước nhảy sau bước nhảy này - nhưng bạn không thấy điều đó.

Khi chỉ số TTL của gói đạt 0, nó sẽ điều khiển mặt phẳng trên bộ định tuyến để tạo phản hồi ICMP trở lại máy chủ gửi. Tôi đoán là CPU của mặt phẳng điều khiển (tại thời điểm bạn đang thực hiện theo dõi) trên bộ định tuyến cụ thể đó được sử dụng rất nhiều và nó sẽ gửi một số phản hồi lại cho bạn bên ngoài giá trị hết thời gian chờ của MTR.