Как, черт возьми, это часовое время пинга может быть реальным?

Недавно я проводил пасхальные выходные с моими родителями, которые живут в очень сельской местности в Великобритании. У них есть (ужасное) 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

— Landak
источник

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

— странный урод

Жадный маршрутизатор;) Просто поиграйте в это, когда заметите, что планируете подождать час, прежде чем пересылать пакет. youtube.com/watch?v=moSFlvxnbgk

— Cestarian

Возможно ли, что, поскольку вы сказали, что оставили его на ночь, ваш компьютер применил +1 час в начале перехода на летнее время, что не соответствует расчету RTT конкретного пакета?

— Кенх

@kenkh - Нет; Я определенно уверен, что день, когда часы изменились, был не тот. Кроме того, глядя на ping исходный код (из ~ 1761), я вижу, что часовые пояса игнорируются в последующих вычислениях ( gettimeofday(nv, NULL)возвращает микросекунды эпох). Это действительно заняло час!

— Ландак

если у вас есть доступ к системе, можете ли вы запустить pathping на ней? Примерно покажет, где замедление

— Мастер-подмастерье

Ответы:

Пакет ICMP и ответ для эхо-запроса имеют длину 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.

Таким образом, сочетание плохой политики управления перегрузкой с открытием сеанса пинга в течение нескольких часов может привести к такому странному сценарию.

Больше информации об управлении перегрузкой здесь .

— Tamadite
источник