Петербургская городская оптическая IP сеть «InterZet» Главная Mail Карта сайта и поиск
InterZet
О компании Лицензии Карта скидок Контакты
Интернет Телевидение Телефония Новости Акции Зона охвата Ресурсы сети Личный кабинет

Здравствуйте, гость ( Вход | Регистрация )

Новости: Уважаемые пользователи!

Напоминаем, что на форуме запрещен флуд и оффтопик в темах (см. Правила форума). Нарушителям будет запрещено оставлять сообщения и создавать новые темы в течение одной недели.

Обращаем Ваше внимание на то, что в целях защиты от спам-рассылок через ЛС введены ограничения: если Вы находитесь в группе "Новички", то можете отправлять не более 1 ЛС в течение 10 минут. По набору определённого кол-ва сообщений Вы автоматически будете переведены в другую группу, где данные ограничения не действуют.
Будьте внимательны: после регистрации воздержитесь от включения ссылок в ваши первые сообщения. Иначе форум примет вас за спамбота и вы будете забанены.

О любых фактах спама в ЛС просьба сообщать администрации форума.
 
Reply to this topicStart new topic
> Пинги, трейсы, скорость, Базовые знания
SeXsT
сообщение Oct 31 2011, 18:41
Сообщение #1





Группа: Пользователи
Сообщений: 3 512
Регистрация: 10.2.2008
Пользователь №: 19 507
Район: Кировский, СПб



Репутация:   81  


Тут, видимо потихоньку будут освещаться основные моменты, незнание которых позволяет многочисленным "гуру" орать про проблемы на форумах провайдеров. Дополнения и исправления по делу приветствуются, пишу по памяти, могу что-то наврать или упустить.

Потери и задержки icmp пакетов
Ситуация: все тормозит, для выяснения ситуации пингуется какой либо хост в сети интернет, или делается tracert, или mtr до него и видится, что промежуточные узлы дают огромный процент потерь icmp пакетов, из чего делается неправильный вывод о том, что что проблема на этих узлах.

Для понимания ниже написанного нужно знать что такое icmp, tcp, udp и чем они друг от друга отличаются. Если понимания нет, то изучайте например:
- http://ru.wikipedia.org/wiki/TCP
- http://ru.wikipedia.org/wiki/UDP
- http://ru.wikipedia.org/wiki/Icmp

Сеть компании, как и сети многих других, построена на аппаратных маршрутизаторах. Основной задачей марштутизатора является перекладывание ip (tcp,udp,icmp) пакетов с одного своего интерфейса на другой согласно настроенным в маршрутизаторе правилам. Причем это процесс происходит АППАРАТНО т.е. без участия ПРОЦЕССОРА маршрутизатора. А вот обработка всего остального, включая icmp запросы/ответы к самому маршрутизатору, происходит ПРОЦЕССОРОМ, причем процесс icmp имеет очень низкий приоритет и обрабатывается во время когда процессор СВОБОДЕН.

Из вышенаписанного следует:
- если вы пингуете шлюз, и видите огромные потери, это лишь означает, что процессор маршрутизатора занят чем-то более важным, чем обработка ваших icmp пакетов, причем на потери транзитных пакетов это не влияет.
- если вы видите потери на одном из транзитных узлов, но они отсутствуют на конечном узле, то потерь на самом деле нет.
- если вы видите задержки на одном из транзитных узлов, но они отсутствуют на конечном узле, то задержек нет.

Если Вы хотите узнать реальные потери ip пакетов до каких-то конкретных хостов, нужно отправить определенное количество tcp или udp пакетов из точки А в точку Б и в точке Б оценить количество потерянных пакетов.
Любителям он-лайн игр: он-лайн игры преимущественно используют udp пакеты, поэтому пингуя игровые сервера icmp пакетами вы занимаетесь ерундой.
Желающие точно потестировать свои каналы, идут на http://ru.wikipedia.org/wiki/Iperf Изучают софт и получают почти правильные результаты, т.к. 10% погрешности являются в данном случае нормой.
Из более доступных простым пользователям способов можно назвать скачку торрентов (только не с rutracker.org - тут ретрекер настроен). Можно посоветовать покачать релиз убунты с http://ubuntu.ru/get
Все онлайн мерилки скорости показывают малоадекватный результат.

Пример:

[natan@myhost ~]$ ping 10.204.212.1
PING 10.204.212.1 (10.204.212.1) 56(84) bytes of data.
64 bytes from 10.204.212.1: icmp_req=1 ttl=252 time=2.50 ms
64 bytes from 10.204.212.1: icmp_req=3 ttl=252 time=3.27 ms
64 bytes from 10.204.212.1: icmp_req=4 ttl=252 time=3.66 ms

[natan@myhost ~]$ ping ya.ru
PING ya.ru (87.250.250.203) 56(84) bytes of data.
64 bytes from www.yandex.ru (87.250.250.203): icmp_req=1 ttl=55 time=12.8 ms
64 bytes from www.yandex.ru (87.250.250.203): icmp_req=2 ttl=55 time=12.4 ms
64 bytes from www.yandex.ru (87.250.250.203): icmp_req=3 ttl=55 time=12.7 ms
64 bytes from www.yandex.ru (87.250.250.203): icmp_req=4 ttl=55 time=12.9 ms

Как видно, пингуем шлюз, время отклика большое и есть потери, пингуем хост в интернете, время отклика малое, потерь нет. Причины указаны выше. Во втором случае пакет был обработан аппаратно, т.к. он транзитный, а в первом случае обработан процессором маршрутизатора.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Трейсроут

Трейсроут это одна из самых малоинформативных софтин в мире.

По поводу взаимоотношений с трейсроутом Ричард Стинберген сделал на конференции NANOG-47 (2009) доклад, тезисы которого я и рекомендую к изучению всем заинтересованным лицам. A Practical Guide to (Correctly) Troubleshooting with Traceroute (PDF, 222 КБ) (на английском, разумеется, языке). Не стану пересказывать тут подробности (желающие да прочтут), остановлюсь лишь на своде аргументов и выводах, которые хорошо бы иметь в виду, прежде чем звать на помощь с криком «у меня трейс показывает, что…»

Некоторые факты (без углубления в детали)

Задержка прохождения любого пакета по сети складывается из нескольких факторов: сериализация, буферизация, распространение. Каждый из факторов сложнее, чем вы о нем думаете. А скорее всего вы о них и не знаете. Задержка, которую вам показывает трейсроут, — еще более комплексная величина: маршрутизаторы обрабатывают пакеты, адресованные самим себе, абсолютно иначе, чем транзитные пакеты. Данное обстоятельство приводит к специфической природе значений задержек, которые нам показывает трейсроут. Из этого не следует, что на них нельзя ориентироваться, но нужно уметь их читать.
Трафик в интернете почти всегда идет разными путями в направлениях от клиента к серверу и от сервера к клиенту. Трейсроут же всегда показывает суммарную задержку в обе стороны, а трассировку — только по одному направлению.
Использование L3-балансировки где-то на интернет-магистралях скорее всего заставит разные пакеты в рамках одной трассировки идти разными путями. Такое поведение приводит к сложноинтерпретируемому выводу, грамотно прочесть который может далеко не каждый.
Современные маршрутизаторы при ответе на трейсроут не соблюдают требования пункта 4.3.2.4 RFC1812, обязывающего устанавливать IP-адрес источника ICMP-ответов равным адресу исходящего интерфейса. Вместо этого они устанавливают его равным адресу интерфейса, на который был получен трейсроут-запрос (пакет с TTL=1). Впрочем, если б было наоборот, читать вывод трейсроута было бы куда тяжелее.
Наличие MPLS-коммутации внутри магистральных сетей (нынче это так у любого уважающего себя крупного провайдера) приводит к контруинтуитивному пути передачи ответов на трейсроут и еще менее очевидному способу вычисления задержек.

Некоторые наиболее важные выводы

Трейсроут — не такая простая штука, как кажется; ею нужно уметь пользоваться. А для этого надо понимать, как она работает.
Большинство админов и инженеров служб эксплуатации, не говоря уже о простых пользователях, не понимают и не умеют. Такое положение дел очень часто приводит к ложным тревогам, неправильной диагностике и т. п.
Трейсроут трейсроуту рознь. Стандартные утилиты tracert в Windows и traceroute в Линукс реализованы по-разному и могут давать разные результаты. Windows посылает ICMP, а Linux — UDP, файрволы на пути трассировки могут иметь неодинаковые настройки фильтрации для разных протоколов.
При интерпретации результатов трассировки требуется опыт и сообразительность. Бывает, что важные выводы можно сделать лишь путем догадки, опираясь на косвенные данные, а иные — и вовсе не однозначно, а лишь с точностью до «скорее всего».

Итого

Не донимайте техподдержку выводами трейсроута, если только вы не абсолютно уверены в ответе на вопрос «почему я именно так интерпретирую трассировку?» В лучшем случае вас просто проигнорируют или пошлют. В худшем — можете убедить неопытных сотрудников поддержки в справедливости своей неправильной версии, в результате чего они отправятся копать проблему совсем не в том месте, где нужно.

Если вы не видите проблем с сервисом (все работает), но в выводе трейсроута вам что-то не нравится — подумайте хорошенько, прежде чем подымать тревогу. Крайне вероятно, что вы просто неверно интерпретируете вывод. Очень нечасто по одному трейсроуту можно судить о наличии проблемы. А если проблема действительно есть, обычно ее проще продемонстрировать без трейсроута.
Цитата(lllop @ Feb 28 2012, 09:52) *
справедливости ради, следует отметить, что трассировка в *nix проходит по UDP

Таки да, забыл указать. По умолчанию линуксовая утилита tracert действительно пользуется udp датаграммами, что вызывает дикий батхерт у многих непосвященных. Поэтому при желании получить более-менее адекватную картину при известных прямых и обратных маршрутах пользуемся хотя бы убунтовским LIVECD. Хотя не исключаю существование аналогов под винду.
Только не забываем что это все равно обрабатывается на маршрутизаторах процом и подчиняется control plane со всеми вытекающими.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Падение скорости тема необъятная. Потихоньку будем заполнять.

Падение скорости до удаленных серверов

Данное явление является следствием устройства самого распространенного протокола в сети - TCP и большинста надстроев над UDP. Подробно можно прочитать хоть тут http://habrahabr.ru/blogs/internet/115527/ . Вкратце, TCP передает данные порциями, ожидая после каждой порции от принимающей стороны подтверждения о приеме. У принимающей стороны есть буфер, куда складируется вся порция пакетов, но при современных каналах и задержках его размер весьма неоптимален и поэтому используется далеко не вся полоса пропускания. Причем чем больше задержка (пинг до сервера), тем сильнее падает скорость соединения.
Оригинальная конфигурация TCP ограничивает скорость передачи буфером размером в 2^19 бит (до 64 КБайт). Максимальная пропускная способность в данном случае = 2^19/задержка (Мбит/с)

Пример:
У вас 100 мегабитное соединение к Интернету и до сервера задержка 100 мс.
Со стандартным стеком TCP, максимальная скорость передачи данных не превысит даже 10 Мбит/сек
( 524288 бит / 0.1 сек = 5.24 Мбит/сек не смотря на то что у вас 100 мегабитный линк).
Задержка 40 мс.
524288 бит / 0.04 сек ~ 13 Мбит/сек

В windows начиная с vista был введен ряд модификаций, направленных на улучшение работы в современных сетях. В частности размер буфера был увеличен до 2^30 бит, что положительным образом сказывается на средней скорости соединения.

Сообщение отредактировал SeXsT - Feb 29 2012, 21:26
Go to the top of the page
 
+Quote Post
RJ45
сообщение Nov 6 2014, 18:15
Сообщение #2





Группа: Новички
Сообщений: 3
Регистрация: 6.11.2014
Пользователь №: 65 977
Район: Невский, СПб



Репутация:   0  


1. Хорошо, tracerote малоинформативна, согласен; есть особенности в расшифровке результатов — и тут полностью согласен, отбросим, что ТП сами просят результаты этой команды. Но косвенную информацию она даст.
2. C ping давайте-ка поподробнее. Да, может стоять низкий приоритет на протокол ICMP, да, если маршрутизатор загружен, то можно получить некорректные данные.
Но, это не говорит о том, что команда бессмысленна, а утверждение "вы занимаетесь ерундой" вовсе не следует из приведенных вами фактов.
Цитата
Любителям он-лайн игр: он-лайн игры преимущественно используют udp пакеты, поэтому пингуя игровые сервера icmp пакетами вы занимаетесь ерундой.


Следующие выводы я понимаю иначе, все-таки эта утилита для диагностики и доступна всем пользователям:
Цитата
- если вы пингуете шлюз, и видите огромные потери, это лишь означает, что процессор маршрутизатора занят чем-то более важным, чем обработка ваших icmp пакетов, причем на потери транзитных пакетов это не влияет.

Во-первых, как бы ни был загружен маршрутизатор, как низок бы ни был приоритет протокола команды, он должен укладываться в отведенное время. Скорее это может указывать на повреждение кабеля или на проблемы самого маршрутизатора (неполадки аппаратного или програмного обеспечения, переполнение буфера). В случае переполнения буфера пакеты, которым не хватило памяти будут отброшены и их приоритет маршрутизатор ни капельки не волнует.
Цитата
- если вы видите потери на одном из транзитных узлов, но они отсутствуют на конечном узле, то потерь на самом деле нет.
Хорошо, пингуем несколько узлов. Однако это уже намекает на проблемы в сети с нагрузкой, на не правильную настройку.

Цитата
- если вы видите задержки на одном из транзитных узлов, но они отсутствуют на конечном узле, то задержек нет.
А выходит, что есть некорректная настройка.

Готов к конструктивному диалогу, однако пока я вижу лишь попытку отобрать у пользователей инструменты, которые дают представление о состоянии сети в определенный момент времени. А игроки онлайн игр со своим пингом обеззаружены и больше не могут являтся головной болью провайдера. Им не важна ваша скорость, им важна стабильность (потеря пакетов ощущается мгновенно, а многие играют подолгу), а стабильнасть обеспечить в разы труднее, чем скорость...
Да, указаны интересные особенности, но выводы притянуты за уши. Будь вы журналистом, я легко бы повесил на статью ярлык "заказная".

Сообщение отредактировал RJ45 - Nov 6 2014, 18:40
Go to the top of the page
 
+Quote Post
SeXsT
сообщение Nov 6 2014, 18:56
Сообщение #3





Группа: Пользователи
Сообщений: 3 512
Регистрация: 10.2.2008
Пользователь №: 19 507
Район: Кировский, СПб



Репутация:   81  


Цитата(RJ45 @ Nov 6 2014, 20:15) *
Но, это не говорит о том, что команда бессмысленна, а утверждение "вы занимаетесь ерундой" вовсе не следует из приведенных вами фактов.

Ерундой-ерундой. Нужные для игрушек протоколы TCP и UDP находятся с ICMP аж на разных уровнях стека. И практически всегда на них настроены разные приоритеты. Короче говоря, по адекватно сделанной сети конкретно ICMP ECHO даже при транзите может в очереди подождать пока его обгонит целая куча трафика. В итоге ложное восприятие "проблемы" и жалобы.
Цитата(RJ45 @ Nov 6 2014, 20:15) *
Следующие выводы я понимаю иначе, все-таки эта утилита для диагностики и доступна всем пользователям:

Эта утилита вообще была написана господином Муусом когда ему было лень ручками разобраться в странном поведении сети. И почему-то прижилась. Диагностического смысла в ней в эпоху аппаратных железок и повального MPLS почти ноль.
Цитата(RJ45 @ Nov 6 2014, 20:15) *
Во-первых, как бы ни был загружен маршрутизатор, как низок бы ни был приоритет протокола команды, он должен укладываться в отведенное время. Скорее это может указывать на повреждение кабеля или на проблемы самого маршрутизатора (неполадки аппаратного или програмного обеспечения, переполнение буфера). В случае переполнения буфера пакеты, которым не хватило памяти будут отброшены и их приоритет маршрутизатор ни капельки не волнует.

А я вот сейчас настрою политику для ICMP ECHO с узенькой неприоритетной полосой к процессору и огромным ведром под пакеты (что по странному стечению обстоятельств нынче почти дефолт у кучи вендоров железа). А еще по пути транзита политиками в самый низ задвину. Вот вам и задержки. Или пакет попал в очередь к процессору, но тот на добрых полсекунды отвлекся на компиляцию acl, управляющий трафик, ospf перестройку наконец. Опять задержки.
Цитата(RJ45 @ Nov 6 2014, 20:15) *
Хорошо, пингуем несколько узлов. Однако это уже намекает на проблемы в сетис нагрузкой, на не правильную настройку.
А выходит, что есть некорректная настройка.

Не намекает.
Цитата(RJ45 @ Nov 6 2014, 20:15) *
Готов к конструктивному диалогу, однако пока я вижу лишь попытку отобрать у пользователей инструменты, которые дают представление о состоянии сети в определенный момент времени. А игроки онлайн игр со своим пингом обеззаружены и больше не могут являтся головной болью провайдера. Им не важна ваша скорость, им важна стабильность (потеря пакетов ощущается мгновенно, а многие играют подолгу), а стабильнасть обеспечить в разы труднее, чем скорость...
Да, указаны интересные особенности, но выводы притянуты за уши. Будь вы журналистом, я легко бы повесил на статью ярлык "заказная".

Все адекватные инженеры предпочитают чтобы железки делом занимались а не отвечали многочисленным любителям попинговать. Поэтому мировая best practice телекома - задвигать ненужный в общем-то обычным пользователям ICMP в самое дно. А еще все провайдеры ARP подрезают, представляете!!!! И UDP с бОльшим приоритетом нежели TCP гонят. А могут вообще DPI поставить. Везде ущемление прав.
Go to the top of the page
 
+Quote Post
RJ45
сообщение Nov 6 2014, 21:55
Сообщение #4





Группа: Новички
Сообщений: 3
Регистрация: 6.11.2014
Пользователь №: 65 977
Район: Невский, СПб



Репутация:   0  


Допустим, спору ради. В итоге? Мы отметаем прижившуюся диагностику. А что взамен? Серьезно, если у меня проблемы с сетью, я прибегаю к этим утилитам не ради праздного интереса, а именно потому, что ни черта не работает или работает некорректно, а провайдер тыкает вашей статьей.
Нет цели обличить провайдера: не ту скорость даёте, не качественно услуги предоставляете. Как рядовому пользователю, знакомому с понятиями IP-адрес, DNS и ping узнать, что с Интернетом что-то не так?
Вариант со скачиванием файла с торрента малоинформативен, вариант взаимодействия со знакомым не реален, особенно, в случае внезапности проблемы, тем более, что нужны два знакомых: один на этом же провайдере, а второй на другом.
Да, существуют погрешности в измерениях. В измерениях скорости, в том числе. Но что слепо верить провайдеру, что все соответствует? У меня был случай, когда спустя час ТП (другого провайдера) выяснили, что у них порт стоит на 10 Mbit, в другом человек два дня бился с IPTV, а оказалось, что на порту, по словам ТП, опять иного провайдера, был запрещен multicast, а ему два дня вежливо говорили, что он осёл и должен вызвать специалиста.

В ТП сидят люди, физически нереально выявить своевременно все неполадки. Если пользователь будет молчать, то да, есть большой шанс, что проблема разрешиться сама собой: разгрузится буфер маршрутизатора, его зачем-то перезагрузят или пропадет питание, заметит специалист или обратится иной пользователь\пользователи.

Теперь реальный пример.
У меня вчера проблема была на протяжении 7-ми часов. Хорошо, я бы не использовал ping, загружать файлы? — так загрузка обрывается, источник не важен, Интернет работает, но попробуй посмотреть видео и опять-таки подгрузка в кэш браузера обрывается. Да менеджеры закачек работать могли. Попросили проверить скорость на speedtest — не может завершиться тест, да ерунда... что первая половина теста прошла? Этого достаточно! В итоге, мне ответили, что проблема вне сети. Жалоб других абонентов нет, шлите результаты трассеровки через сообщения в ЛК (странное требование, но очень настаивали). Всё! Приятного вечера! Иначе говоря, у меня все должно работать, ваш ping ерунда, а дальнейший разговор не имеет смысла. Проверил не приписался ли мне прокси, прошерстил антивирусами, глянул драйвера, откопал старый ноут, проверил сеть с него — все так же.

Теперь вопрос, как провести диагностику сети правильно, дабы ТП сказали, — "Хм, действительно есть проблема, сейчас попробую разобраться"?!

Чем закончилось? Дозвонился до ТП в очередной раз. Сонный сотрудник (3 часа ночи) перегрузил маршрутизатор или что он там сделал и все заработало! Нет, претензий нет, но задаю вопрос из любопытства, — "Что вы сделали?". На что получаю ответ, — "Я? Ничего!"...странная политика пошла скрывать свои действия, столкнулся с ней за эти 7 часов и ранее. Выходит, Вы Уважаемый Пользователь , осёл, который просто так потратил 7 часов своего времени, в том числе и от сна, а ничего не было и мы ничего не делали, а если что и было, что вряд ли, то оно само прошло! (это впечатление общее от ответов специалистов от первого до последнего).

Сообщение отредактировал RJ45 - Nov 6 2014, 22:43
Go to the top of the page
 
+Quote Post
RJ45
сообщение Nov 8 2014, 13:10
Сообщение #5





Группа: Новички
Сообщений: 3
Регистрация: 6.11.2014
Пользователь №: 65 977
Район: Невский, СПб



Репутация:   0  


Я прочел о проблемах этих способов по предоставленным ссылкам, бегло, но прочел. Не вызывает доверие место их публикации и хранения, но все равно пробежался. Да, я не достаточно компетентен в этих вопросах, я готов признать ошибочность своих убеждений, даже подкреплённых опытом, но во-первых, нельзя мыслить двоично: true и false, во-вторых все приведенные доказательства лишь говорят, что измерения не всегда отражают реальность, но тем не менее остаются актуальными средствами по сей день и неважно по какой причине, при каких обстоятельствах и как давно был написан код программы ping, если он работает до сих пор и помогает миллионам IT- специалистам в выявлении и решении проблем с сетью. И не важно, что с еще кучей неполадок справляются иными методами.

Вывод: пока ответа нет, продолжаем использовать ping, трассировку и измерение скорости со спокойной душой, с поправкой на неточность измерений двух последних. Также следует учесть, что данные пинга не бесполезны для игроманов. Множество онлайн игр встраивают монитор пинга в клиент игры и эти данные профессиональные игроки используют не только для выбор сервера и смены провайдера, но и для поправок на пинг, как снайпер делает поправки на ветер и это работает wink.gif
Я пингом, например, даже узнаю, что человек за Интернет не заплатил и не важно, что InterZet сообщает об этом в браузере, так делают не все провайдера и не все люди помнят дату оплаты и следят за балансом счета. Этот пример я привел лишь с целью, чтобы вы поняли как разнообразно может быть применение чего-то стандартного и говорить об неактуальности пока рано.

Сообщение отредактировал RJ45 - Nov 10 2014, 18:31
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



RSS Текстовая версия Сейчас: 19 January 2018 - 04:17
194044, Санкт-Петербург, Финляндский проспект, дом 4а, бизнес-центр "Петровский Форт"
Контактный телефон: (812) 640 5 640
Copyright © 2005-2014