“Тормозит интернет!” и как с этим бороться

Ситуация проста и банальна: есть клиент, который утверждает, что тормозит интернет основываясь на визуальной загрузке страниц, на маленькой скорости загрузки с сайтов, делаются замеры с помощью команд “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 пакет на следующий узел.
Как протестировать СКОРОСТЬ подробно описано здесь (спасибо коллеге)