Ситуация проста и банальна: есть клиент, который утверждает, что тормозит интернет основываясь на визуальной загрузке страниц, на маленькой скорости загрузки с сайтов, делаются замеры с помощью команд “ping”, делается “traceroute”, замеряется все с помощью “winmtr” и, когда получаются результаты тестирования клиент делает неправильный вывод, что провайдер не хочет оказывать услуги соответствующие качеству. В итоге – клиент не доволен.
Итак, решение:
Сначала необходимо понять, что такое ICMP, TCP и UDP, а так же чем они друг от друга могут отличаться. Изучить можно тут:
– http://ru.wikipedia.org/wiki/Icmp
– http://ru.wikipedia.org/wiki/TCP
– http://ru.wikipedia.org/wiki/UDP
В сети оператора связи существуют маршрутизаторы, шлюзы, коммутаторы. Канал “в интернет” идущий через эти узлы имеет определенную пропускную способность и, поэтому, в часы пик на этом узле могут происходить потери пакетов в зависимости от потока этих самых пакетов и пропускной способности узлов. Если поток превышает пропускную способность узлов, то и происходят потери.
Маршрутизация трафика, который проходит через узлы происходит аппаратно (без участия процессора узла), а обработка запросов (icmp ответы/запросы, генерация netflow трафика и различные взаимодействия с биллингом) обрабатывается процессором. При том ICMP запрос (попросту говоря ПИНГ) имеет ОЧЕНЬ НИЗКИЙ ПРИОРИТЕТ и обрабатывается только тогда, когда процессор будет свободен. Иначе вместо обработки запроса к биллингу маршрутизатор только бы и отвечал на ICMP пакеты.
Исходя из этого можно сделать следующие выводы:
– Когда вы пингуете узел и наблюдаете потери это значит, что процессор узла занят чем-то другим (например запросом в биллинговую систему) и что ему некогда обрабатывать ICMP пакеты. При том это не влияет на прохождение ICMP и прочих пакетов через этот же узел на дальнейшие.
– пингуя игровой сервер (привет геймерам) вы ничего не добьетесь, ибо в основном игры используют UDP-пакеты. Пингуя игровые сервера UCMP пакетами вы будете “наблюдать погоду”.
– Если видите, что через какой-то узел НЕ ПРОХОДИТ большое количество пакетов на следующий узел, значит проблема в этом узле. Например:
------------------------------------------------------------------------------------------ WinMTR statistics Host - % Sent Recv Best Avrg Wrst Last ------------------------------------------------ ------ ------ ------ ------ ------ ------ 192.168.0.1 - 0 41 41 0 1 32 0 n225-104-1.cn.ru - 0 41 41 0 0 16 0 10.245.4.33 - 42 41 24 0 12 94 0 10.245.139.146 - 0 41 41 0 1 16 0 10.245.141.54 - 0 41 41 0 1 31 0 nsk15.transtelecom.net - 0 41 41 0 4 63 0 Megafon-gw.transtelecom.net - 5 41 39 109 118 141 140 85.26.205.119 - 3 41 40 93 112 156 110 athena.lumiro.net - 3 40 39 93 108 125 110 ________________________________________________
Это не значит, что узел оператора 10.245.4.33 начинает глючить (ведь 41 пакет на следующий узел ушли). Проблема заключается скорее в предпоследнем узле 85.26.205.119, который не пропустил один пакет на конечный узел и не является узлом оператора связи, который предоставляет клиенту услуги. А 10.245.4.33 всего лишь какой-то маршрутизатор, который занимался более важной работой, чем обработка ICMP запросов клиента при том пропустив тот же ICMP пакет на следующий узел.
– Как протестировать СКОРОСТЬ подробно описано здесь (спасибо коллеге)