Яким чином може бути справжнім цей повідомлений годинний пінг?

Нещодавно я провів свято великоднього банку з батьками, які живуть у дуже сільській місцевості у Великобританії. У них є (жахливий) інтернет-з'єднання ADSL, яке проходить через кілька кілометрів хитрої міді і періодично переривається, коли сусідні фермери переводять свої трактори на телефонні лінії.

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

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
U.S. Robotics Wireless MAXg ADSL Gateway
Login: ***********
Password: 
> sh


BusyBox v1.00 (2006.02.17-20:30+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

# adsl configure --snr 200; exit 
Connection closed by foreign host.

Це покращило питання, і річ отримала (дещо) стабільну, якщо неймовірно повільну, трубу до зовнішнього світу:

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=3236.679 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=3699.541 ms
...

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

Зведена підсумкова статистика враховувала мене:

--- 8.8.8.8 ping statistics ---
103074 packets transmitted, 100564 packets received, 2.4% packet loss
round-trip min/avg/max/stddev = 32.986/3034.479/3600577.732/87527.276 ms

Як бачимо, максимальний записаний час відповіді для пакету ICMP, який здійснює короткий трансатлантичний перехід на DNS-сервер Google, становить 3600577,732 мс . Це майже рівно годину , і, звичайно, набагато довший, ніж час pingочікування за замовчуванням.

Як на Землі це може бути? Це точно? Який маршрутизатор із задоволенням триматиметься за пакет шістдесят хвилин, перш ніж відправити його в дорогу? Чому цей пакет не випав? Це результат переповнення 8-бітового лічильника пакетів у поєднанні з великими затримками?

Нарешті, мені було б цікаво дізнатись, чи є у Великобританії якийсь кодекс поведінки, який говорить про те, що очікується, що споживачі ADSL мають менші затримки та краще управління трафіком, ніж у RFC 1149 та RFC 2549 ;-).

networking routing adsl

— Ландак
джерело

маршрутизатор, який не перевантажений спамом.

— храповик виродка

Жадібний маршрутизатор;) Просто треба це зіграти, коли помітите, що плануєте зачекати годину, перш ніж переслати пакет. youtube.com/watch?v=moSFlvxnbgk

— Cestarian

Чи можливо, оскільки ви сказали, що ви залишили його протягом ночі, ваш комп'ютер застосував +1 годину на початку літнього часу, і це зіпсувало обчислення RTT певного пакету?

— кенх

@kenkh - Nope; Я точно впевнений, що день зміни годинників був не таким. Крім того, дивлячись на ping вихідний код (від ~ l 761), я бачу, що часові пояси ігноруються при наступному обчисленні ( gettimeofday(nv, NULL)повертає епохальні мікросекунди). Це дійсно зайняло годину!

— Ландак

якщо у вас є доступ до системи, чи можете ви запустити шлях до неї? Приблизно покаже, де знаходиться уповільнення

— Journeyman Geek

Відповіді:

Пакет ICMP та відповідь для ping - це довжина 32 байти, тому для пінг-погляду здається, що кожен байт займає майже хвилину.

Це можна пояснити лише дуже великим підрахунком помилок (ваш твір?) У поєднанні з дуже повільним маршрутизатором і болісним очікуванням або повторними спробами для кожного переданого байта.

Інтернет-протокол (IP) передає дані дейтаграми і намагається не надсилати часткові. Після запуску передачі за замовчуванням вона чекатиме 200 мілісекунд, щоб до дейтаграми було додано більше байтів. За цей час програмне забезпечення / програмне забезпечення надсилатиме все, що є, як одну дейтаграму. У випадку часу пінг-години, що завантажується в пакет, можливо, навантаження пакета було б мало одного байта. Поки дані все ще надходять, з'єднання не буде припинено двома сторонами-учасницями.

Що ви можете зробити:

Якщо інші телефони, факс або інші пристрої підключені до тієї ж телефонної лінії, перевірте, чи захищені вони фільтрами DSL . Не забудьте поставити фільтр на лінії, що переходить до вашого DSL-модему.
Спробуйте інший маршрутизатор - як тільки ви отримаєте поганий пристрій, ви нічого з цим нічого не зробите, окрім як викинути його та отримати щось краще.
Якщо іншого маршрутизатора немає, зв’яжіться з вашим провайдером - вони можуть проводити корисні тести зі своєї сторони.
Якщо провайдер нічого не знаходить, спробуйте все-таки вимагати роутер / модем для заміни.
Якщо така ж проблема виникає з іншим маршрутизатором, зв’яжіться з телефонною компанією.

Знайти проблемний комутатор може бути досить складним, як це може бути з телефонною компанією, але у провайдера також можуть бути свої комутатори. Зазвичай проблема з вимикачем є в масштабі області, що допомагає знайти несправний вимикач. Але в сільській місцевості, де не дуже багато підписників використовує цей перемикач, це може залишитися непоміченим. Якщо деякі сусіди використовують той же провайдер, спробуйте з’ясувати, що таке їх зв’язок.

— harrymc
джерело

Я б обернув 2 і 3 навколо. Набагато простіше спочатку зателефонувати в Інтернет. Вони можуть зробити тест. Якщо вони побачать проблеми, вони відправлять новий модем (не обов’язково маршрутизатор). Якщо новий модем не вирішує проблему, провайдер повинен звернутися до телефонної компанії. Ось так це працює тут, але у Великобританії може бути інакше.

— SPRBRN

Я мав на увазі, що слід виконати якомога більше точок вище, паралельно. У моєму випадку мій провайдер може вирішити надіслати техніку, але якщо проблема настільки тривіальна, як і невикористані фільтри DSL, він може вирішити стягнути плату.

— harrymc

Тьфу. У коментарях йдеться про номери в нумерованому списку. Потім, афіша відповіді відредагувала відповідь, щоб видалити номери, тим самим зробивши коментарі здаються невідповідними. Цск цк.

— TOOGAM

200 мс : Це вбудовано в програмне забезпечення Windows / Linux. Я виявив це, аналізуючи, чому продукт моєї компанії мав занадто низьку пропускну здатність TCP / IP на малих дейтаграмах, а потім виявив системні виклики, які "негайно надсилаються" на сокет. Корисне навантаження пакетів : це не узгоджено, швидше, занадто велика дейтаграма TCP / IP буде розрізана на частини, коли вона зустріне шлях, де MTU занадто малий. DSL-модем : можливо, що зміна параметрів дещо компенсує погану телефонну лінію / комутатор, але її слід виправити, а не компенсувати.

— harrymc

Ще одна настройка: відключіть ADSL2 + і залишайтеся з ADSL1 для стабільності. Який би маршрутизатор ви не купували, запевняйте, що ви можете правильно налаштувати поля SNR (трохи інформації тут ). Мільярд маршрутизаторів - це добре, як і Netgear (я віддаю перевагу моделям, які підтримують DD-WRT з простою установкою). Ця стаття може дати більше ідей - і ознайомитися з діаграмою відстані / швидкості.

— harrymc

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

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

Більше інформації про управління заторами тут .

— Тамадит
джерело