Використання ping google.com для перевірки з’єднання


11

Оскільки підключення до Інтернету в нашому будинку час від часу руйнується, я поставив невеликий експеримент:

Останні два місяці на одній із моїх машин півгодини почала працювати з google.com. Один вимір складається з 50 пінг.

Зараз я підрахував середній відсоток втрачених пакетів за кожну годину дня: відсотків втрачених пакетів

Мої запитання:

  1. Чи може цей пік увечері бути викликаний вибором google.com як пункту призначення пінг?
  2. Чи рекомендуєте ви використовувати інше місце призначення та яке?
  3. Чи вказує це, що щось не так у моєму зв’язку?
  4. Яка б була краща стратегія, щоб визначити, де саме проблема в нашому інтернет-зв’язку? Наш Інтернет-провайдер каже нам, що він працює нормально, тому я намагаюся зібрати деякі докази ...

З повагою!

Редагувати: я забув зазначити, що машина безпосередньо підключена до роутера (немає Wi-Fi). І маршрутизатор також пінг, без втрати пакетів взагалі.


Що саме ви маєте на увазі під "підключенням до Інтернету в нашому будинку час від часу руйнується"? Якщо «ламають» означає «стопа», відстеження втрати пакетів , коли він робить роботу навряд чи скаже вам що - небудь корисне.
Ісаак Рабінович

Це правильно, але мій інтерес полягає в тому, коли він руйнується і як часто / як довго .
Дірк

Відповіді:


10

На жаль, ви дійсно не надали достатньо інформації, щоб визначити, де проблема. Щоб відповісти якнайкраще, наскільки я можу, з обмеженою інформацією:

  1. Якщо з мого досвіду є що пройти, пінг з Google, як правило, є досить хорошою ставкою, оскільки вони проектують свою мережу якомога швидше. Оскільки ICMP надає пріоритет, вечірній пік, мабуть, не має суттєвої різниці - особливо в частині втрати пакету - що, на думку я, повинен бути 0.

  2. Google - це хороше місце призначення, але для того, щоб краще зрозуміти, що відбувається, ви можете додатково спробувати пінг-шлюз, і якщо вони дозволять це, ваші провайдери DNS, пошта чи веб-сервер. Це допоможе показати, куди плазує втрата пакету. Реально, однак, на рівні втрати пакету, який ви бачите, подивіться на завантаження MTR (або WinMTR) та запустіть це заглянути, щоб отримати краще уявлення про те, куди приходить втрата пакету. .

  3. Суб'єктивно 5% втрати пакетів є у верхньому кінці, прийнятним для мережі на основі Wifi - якщо ви не насичуєте свою мережу. Що стосується зворотного боку, я засмучуюся приблизно на 0,5% втрати пакетів на своїх з'єднаннях з волокнами - як орієнтир, слабко кажучи, менше 1% - це нормально для VOIP, що перевищує
    не так багато. Якщо ви очікуєте, що зможете використовувати Skype або Viber або що у вас підключення, втрата пакетів 5% не в порядку. Для простого перегляду веб-сторінок це може бути достатньо.

  4. Як ISP, я хочу бачити результати MTR, які показують затримки та втрати пакетів між пунктом призначення - це допомагає мені подивитися, де може бути вузьке місце і є хорошим першим кроком. Я також хотів би дізнатися, коли тест був зроблений, щоб я міг співвіднести його з іншим використанням клієнтів і тим, що відбувається в системі. Графіки втрат пакетів, які ви зробили, також корисні, але не поодиноко.

    Як клієнт, мій Інтернет-провайдер не зміг вибачити мої графіки, які відображають втрату пакету (я роблю це за 250 пінгв, раз на секунду протягом 5 хвилинних інтервалів, поєднуючись з мінімальними, середніми та максимальними затримками для цих пінгвів). У мене також є набір графіків, що показують моє використання посилання, і маю набори графіків, що показують місцеві (тобто дуже близькі мені), а для іншого POP вони мають особливий інтерес за кілька сотень КМ.

Інші спостереження:

Схоже, ваша затримка збільшується в другій половині дня, а це означає, що я б хотів шукати перші місця, якщо проблема - WIFI, коли всі навколо мене використовують це. Після вирішення цього питання я б почав розпитувати провайдера про переплату підключення.


Дякую за ваші відповіді. Машина безпосередньо підключена до маршрутизатора, а також пінг-маршрутизатор, що зовсім не показує втрати пакету. Здається, MTR - це те, що я шукав.
Дірк

6

Це більш ніж ймовірно є результатом заторів десь уздовж лінії. Це може бути ваш маршрутизатор, але швидше за все, постачальник послуг.

Ви не вказуєте, як ви робите 50 пінг, наприклад, який часовий проміжок, чи чекаєте, коли один вийде з ладу / досягне успіху до наступного, або вистрілив 50 з усіх одразу (повінь pinging).

Така втрата в періоди великої перевантаженості не є незвичною для мого досвіду. Це може знизитись до нижчої пріоритетності для трафіку ICMP, але більше шансів на те, що однаковий відсоток усіх з'єднань відбувається - це просто TCP витончено повторно відправить і упорядкує пакети, так що ви рідше помітите.

Для кращого уявлення про ситуацію я б запропонував вам здійснити наступне:

  1. Збільшити інтервал між вашими пінгами
  2. Введення IP-адреси для google не домену - google.com поверне кількість записів A, можливо, ви використовуєте різні кінцеві IP-адреси (а значить, інакше маршрутизацію), не знаючи про це
  3. Запишіть середній час відповіді; подивіться, чи це корелює зі збитком - якщо це так, ви побачите більший час піклування і більший збиток, то це вказує на перевантаженість. Тоді ви можете дослідити, зберігаючи замість цього журнали traceroute і побачити, чи є ймовірне вузьке місце десь, де ви бачите раптово збільшені рази
  4. Спробуйте pinging більше ніж Google. Коли я оцінював ефективність мережі в минулому, я робив це, використовуючи 4 або 5 хороших кінцевих точок (знову ж таки, IP-адреса, а не ім'я хоста), щоб ви могли виключити перевантаженість або певну проблему в мережі google, що викликає вас ставити під сумнів весь зв'язок

2

Це характерно для більшості резидентних облікових записів провайдера. Ви спостерігаєте пік через перевантаженість мережі, коли люди повертаються додому після роботи, а потім їдете в онлайні цілий вечір. Такий вечірній пік особливо яскраво виражений у високотехнологічних спільнотах з великою кількістю онлайн-ігор (наприклад, де я живу, тут, в Редмонд, будинок Microsoft.)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.