Последнюю неделю боремся с рядом моментов у заказчиков, которые можно описать фразой “А у меня загрузка не поднимается больше X мбит/с”. Или – “вечером появляется 2% потерь при достижении порога в Y мбит/с”.
Результаты разбирательств прогнозируемы. Причины проблем у заказчиков:
- перегрузка “роутера” на базе FreeBSD. Ресурсы кушает pf, не хватает буферов, прерывания и т.п. Результат – потери, деградация качества канала.
- промежуточное железо. Ставит заказчик ноутбук на интерфейс – все пучком. Включает свою инфраструктуру – чудеса. Причина – на трассе стоит свитч вендора “икс”, который почему-то не свитчит с необходимой производительностью.
- false negative. Мерять канал пингом или mtr для получения объективных данных – неверно в корне. Тот-же iperf – тоже не особая панацея, мы ведь живем не в зоопарке, не в замкнутой экосистеме. Реальный Интернет – это нечто другое, нежели лаба с парой свитчей и роутеров.
Подробнее о последнем. Если хочется померять мегабиты – можно сходить на speedtest.net, конечно. Но этот сервис предназначен для ориентировочной проверки скорости для бродбенд-пользователей, скорости между компьютером клиента и сервером speedtest’а. Здесь возникает масса моментов – антивирус на компьютере пользователя, операционные системы и настройки ip-стэка на сервере и у клиента, загруженность тестового сервера (мы, кстати, свой kharkiv.speedtest.net перевели на nginx и получили 20-25% прироста в скорости! Только заменой вэб-сервера!). Далее помним о зависимости расстояния (читай – времени, т.к. есть свои естественные задержки в связи со скоростью света и привнесенные задержки на каналообразующем и маршрутизирующем оборудовании) и TCP Window Size. Подробнее см. отличный материал на Wikipedia. Как ни крути, 10Мбит/с получить единичным TCP-соединением с достаточно удаленного источника (а именно поверх TCP ходят протоколы FTP и WWW – ведь именно скачкой/закачком обычно пытаются измерять) НЕВОЗМОЖНО в принципе.
То есть, если нужно померять более-менее реально, запускаем пару-тройку десятков закачек с разных серверов. Можно это сделать на FreeBSD с помощью fetch или curl:
# fetch -o /dev/null http://remote.server.tld/iso/big_DVD_image.iso
# curl -o /dev/null http://another.server.tld/iso/big_DVD_image.iso
Далее – о мнимых “потерях”. Запустим любимый в народе mtr на, допустим, yahoo.eu (извините, вырвалось :)):
Видим “страшные потери” на каком-то хопе. Звоним своему провайдеру и начинаем его ругать. А причина проста – там (как и у нас, собственно) стоит Juniper с отличной конструкцией в конфигурационном файле, в разделе filter:
term icmp {
from {
protocol icmp;
icmp-type [ echo-request echo-reply unreachable time-exceeded ];
}
then {
policer small-bw-policer;
accept;
}
term trace-route {
from {
protocol udp;
destination-port 33434-33523;
}
then {
policer small-bw-policer;
accept;
}
}
…где small-bw-policer выглядит как:
policer small-bw-policer {
if-exceeding {
bandwidth-limit 128k;
burst-size-limit 15k;
}
then discard;
}
Умеющим читать на английском вышеизложенные куски конфига понятны. Неумеющим читать – конфиг нам говорит, что если общее количество трафика icmp или udp (на диапазон портов), предназначенного маршрутизатору, будет больше 128К, трафик уничтожается, а mtr показывает “мнимые” потери.
А проверить по-настоящему просто:
# ping -s 1500 -q -c 100 yahoo.eu PING yahoo.eu (68.180.206.184): 1500 data bytes --- yahoo.eu ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 217.482/220.701/224.686/2.490 ms
То есть для корректного результата мы делаем icmp-эхо-запросы на хост, который нам интересен и смотрим на результат. И тогда в ряде случаев не прийдется паниковать и звонить провайдеру с сообщением, что “все пропало”.
Вышеизложенным я не в коей мере не хочу сказать, что у нас все идеально, что во всем мире интернет работает, как часы. Даже с учетом достаточно высокой надежности, к которой мы стремимся, интернет сложен и зависим от каждого – причем не только от каждого оператора/провайдера, но и от конечного пользователя или подключенного в интернет устройства. На моей памяти за последние два месяца были две или три достаточно неприятные проблемы со связностью у наших аплинков, причем это были проблемы вне их зоны влияния. Из-за роста нагрузки мы переводим бэкбон на Extreme – каталисты близки к потолку по надежной производительности и иногда выдают чудеса, о которых как-нибудь в другой раз. Просто хотелось бы видеть грамотную диагностику проблем. И не забываем о модели OSI 
nucleo
апреля 7, 2009 at 21:51
Time to live exceeded in transit – такие вообще все могут уничтожаться, а в соответствующем хопе будет 100% потерь.