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

Question

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

Answer 1

Пакет ICMP и ответ для эхо-запроса имеют длину 32 байта, поэтому для одночасового пинга кажется, что для передачи каждого байта требуется почти минута.

Это объясняется только очень большим количеством повторных попыток ошибки (ваши действия?) В сочетании с очень медленным маршрутизатором и мучительным ожиданием или повторными попытками для каждого переданного байта.

Интернет-протокол (IP) передает данные дейтаграммами и пытается не отправлять частичные. Как только передача начнется, она будет ждать по умолчанию в течение 200 миллисекунд, пока в дейтаграмму будет добавлено больше байтов. После этого программное обеспечение / прошивка отправит все, что имеет, в виде одной дейтаграммы. В случае часового эхо-запроса полезная нагрузка пакета может составлять всего один байт. Пока данные все еще поступают, соединение не будет прервано двумя участвующими сторонами.

Что ты можешь сделать :

• Если к той же телефонной линии подключены другие телефоны, факсы или другие устройства, проверьте, защищены ли они фильтрами DSL. Убедитесь, что вы не поставили фильтр на линию, идущую к вашему DSL модему.
• Попробуйте другой маршрутизатор - если у вас плохое устройство, вы ничего не можете с этим поделать, кроме как выбросить его и получить что-то лучше.
• Если другой маршрутизатор недоступен, обратитесь к интернет-провайдеру - они могут выполнить полезные тесты со своей стороны.
• Если провайдер ничего не находит, попробуйте все равно потребовать замены маршрутизатора / модема.
• Если такая же проблема возникает с другим маршрутизатором, свяжитесь с телефонной компанией.

Найти проблемный коммутатор может быть довольно сложно, как это может быть в телефонной компании, но у провайдера также могут быть свои собственные коммутаторы. Обычно проблема с переключателем распространяется по всей области, что помогает найти неисправный переключатель. Но в сельской местности, где не так много абонентов используют этот переключатель, это может остаться незамеченным. Если некоторые соседи используют одного и того же провайдера, попытайтесь выяснить, на что похоже их соединение.

Answer 2

Я вижу, что этот случай очень сильно связан с управлением перегрузкой данных, хотя очень плохой по любой причине. Насколько я понимаю, в системе передачи имеется плохо управляемый буфер пакетов, который вызывает эту аномалию в пакетах запроса / ответа эха ICMP.

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

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