Контроль потока — стоит ли его использовать?

Не могу не согласиться… Я выяснил, что одним из главных факторов, обеспечивающих «быструю» работу браузера, является очень быстрый DNS-кэш и то, чтобы все пользователи им действительно пользовались.

Согласен. Но как этого лучше добиться? Давным-давно я настроил так, чтобы все клиенты указывали на наш шлюз, который работал как DNS-кэш и перенаправлял запросы на серверы моего провайдера того времени. Потом мы заметили, что серверы OpenDNS работают намного лучше, чем DNS провайдера (Telefonica), и сменили адреса прямо на шлюзе. Потом однажды возникла проблема — http://www.google.com/es перестал открываться. Это решилось отключением MT-кэша (тогда на RB1100AHx2). На форуме было много обсуждений по этой теме.

С тех пор мы стали указывать каждому CPE и другим роутерам напрямую серверы OpenDNS, чтобы запросы обходили шлюз. В прошлом году мы снова попробовали схему «dst-nat re-route to itself» с DNS-кэшем на шлюзе, но уже через неделю у клиентов снова начали возникать проблемы с DNS. Многие сайты переставали открываться, поэтому мы снова отключили DNS-кэш на MikroTik и направили пересылку на сервера Google. Специальная тестовая программа показала, что для нас они работают быстрее, чем OpenDNS или любой другой DNS-сервер.

Текущая конфигурация такая:  
add action=dst-nat chain=dstnat comment="re-route dns requests to Google DNS" dst-port=53 protocol=udp to-addresses=8.8.8.8 to-ports=53  
add action=dst-nat chain=dstnat comment="re-route dns requests to Google DNS" dst-port=53 protocol=tcp to-addresses=8.8.8.8 to-ports=53

Может, лучше вообще настроить, чтобы CPE напрямую смотрели на сервера Google, но для этого нужно менять настройки на всех устройствах.

Проблема точно не в полосе пропускания. У нас есть симметричная линия 300/300 Мбит/с, и комбинированный трафик клиентов редко приближается к 200 Мбит/с. На моих компьютерах мы иногда проводим тесты, и при одновременном запуске нескольких загрузок, желательно на 2-3 ПК, получаем до максимума — около 295 Мбит/с на скачивание. Скорость загрузки по www.speedtest.net обычно близка к 300 Мбит/с.

Если есть узкие места, то они в сети. Но, как и у любого другого провайдера, у нас есть оверсубскрипшн, даже на уровне P2MP-сети. Не знаю, есть ли операторы, которые держат возможные максимальные нагрузки клиентов в пределах, которые может выдержать точка доступа (AP) (например, 100 Мбит-соединение AP может обслужить только 10 клиентов по 10 Мбит? Это плохо и очень редкая модель бизнеса). Каждый оператор продаёт больше трафика, чем может реально обеспечить, если бы все клиенты одновременно начали пользоваться своей максимальной скоростью. Это касается всех сетевых инфраструктур — интернета, электросетей, национальных дорог или водоснабжения.

Я знаю, что у национального провайдера ADSL около 10 миллионов клиентов, и им всем продают по 10 Мбит. Что будет, если они все одновременно начнут использовать эту скорость? Ни одна сеть такого не выдержит. Поэтому мы все работаем с оверсубскрипшеном на разных уровнях. Нам всем приходится делать обоснованные предположения о том, где первоочередно ликвидировать узкие места, чтобы постоянно улучшать общую пропускную способность.

Так что узкие места есть в любой сети. И, соответственно, смешанные по пропускной способности каналы — тоже часть сети. Как уже сказал, у нас есть 300/300 Мбит, приходящих через Cisco-роутер, который подключён гигабитом к нашему CCR. Оттуда по гигабитному Ethernet идут несколько радиоканалов для обратной транспортировки (бэкахолла). Некоторые из этих каналов работают на 80 МГц в режиме ac, другие — только 20 МГц в режиме n. На другой стороне есть радиоканалы с подключением по 100 Мбит к следующему радиоустройству (AP или новый канал), а есть и гигабитные соединения к следующим маршрутизаторам.

В целом я бы сказал, что пакеты клиентов, входящие с 300 Мбит симметричного канала, «проходят» через разные участки: гигабитные линии, 100-мегабитные, быстрое «ac» радио на 80 МГц, среднебыстрое «n» радио на 20 МГц к точке доступа, которая обычно соединяется с клиентами по «n» (некоторые ещё с одним радиоканалом). CPE у клиентов подключены к устройствам клиентов по 100 Мбит.

Так как скачивание — это большая часть трафика, стоит смотреть откуда идёт ingress трафик:

1. Первая ступень — 300 Мбит «труба» от провайдера к Cisco роутеру.
2. Вторая — гигабитный кабель к CCR. Предполагаю, здесь нет проблем с контролем потока?
3. Третья — новый гигабитный кабель к «ac» радио с каналом 80 МГц (мы можем «дать» по нему где-то 250–300 Мбит TCP. В общем это два канала с дуплексом на базе OSPF).
4. Четвёртая — сам радиоканал с пропускной способностью 250–300 Мбит.
5. Пятая — другое радио, соединённое по гигабиту с ещё одним CCR.
6. Шестая — этот CCR распределяет трафик на 4 новых бэкахола, все радио подключены по гигабиту к этому CCR.
6а. Этот же CCR через свитч обеспечивает питание 3 AP, которые обслуживают около 75 клиентов. Все соединения — гигабитные, но на радиоканалах скорость заметно ниже. В среднем скорость соединения — около 80 Мбит.
7. Новые бэкахолы к удалённым локациям. Некоторые с 40 МГц «n» каналами на скорости 270 Мбит, другие — с 130 Мбит на 20 МГц.
8. И так далее — больше каналов, больше AP.

Некоторые клиенты в нашей сети доступны только после того, как пакет прошёл через 5 беспроводных линов (в том числе AP — CPE) и по пути «увидел» минимум 15 роутеров Mikrotik, прежде чем попасть к Wi-Fi-роутеру или ПК клиента.

Маленькое количество клиентов использует VoIP. Сейчас 70 клиентов подключены через PPPoE, в течение месяца доля должна достичь 100%. Сервер PPPoE в нашем шлюзе создаёт отдельные очереди для каждого пользователя в зависимости от его тарифа. Максимальная скорость — 50 Мбит на скачивание, большинство — 20 Мбит, 40% клиентов — только по 10 Мбит.

Какой бы вы выбрали стратегию управления потоком данных в таких условиях?

@pukkita: У нас нет проблем с ошибками. Иногда бывает ошибка fcs, но обычно это связано с плохой кабельной разводкой, и недавно мы выяснили, что наши монтажники привязали кабель ftp к «коровьей проволоке», по которой идут тысячи вольт (низкий ток), которые индуцируются в наш сетевой кабель! Но для меня новшество — это радиочастотная энергия, которая может проникать в разъемы и кабели Ethernet. Такое правда может быть? Думаю, да. …

Мы по максимуму используем радиостанции в металлических экранированных корпусах и даже экранируем антенны, чтобы защититься от нежелательных радиоволн (из ненужных направлений). Для всех своих точек доступа и радиоканалов бэкхола используем кабель ftp и сейчас в процессе обновления заземлений, где только возможно. (Это довольно сложно, учитывая, что даже почва у нас летом очень сухая, и иногда у домов нет нормального заземления.) Сейчас мы также подключаем короткий заземляющий провод прямо от радиостанции к ближайшему устройству, плюс заземление башни, которое само по себе имеет свои заземления.

Снижение мощности — задача на будущее, потому что до недавнего времени у нас везде стояли стандартные настройки мощности. В попытке уменьшить общий шум и, соответственно, помехи, это наш последний проект. (У нас больше 50 работающих радиостанций AP в радиусе 12 км, и примерно по 20 в сети конкурентов, так что каждый канал используется много раз везде.)

Но тем не менее, у нас продолжается много жалоб от людей, которые показывают, что www.speedtest.net выдает им примерно вдвое меньшую скорость, чем мы утверждаем, что им обеспечиваем. При этом тесты пропускной способности TCP из клиентского оборудования (CPE) к нашему шлюзу всегда показывают полную скорость, назначенную в очереди клиента.

За последние полгода, пока мы обновляли каналы бэкхола на новые NetMetals от MT с лучшими (Jirious!) антеннами, и где возможно, использовали гигабитный Ethernet, гигабитные коммутаторы и роутеры, мы наблюдаем рост среднего трафика, реально видим улучшения как в задержках, так и в пропускной способности по тестам MT, а одновременно получаем всё больше жалоб на медленный интернет…

Поэтому сейчас мы ищем решения и причины, почему TCP на стороне клиента часто работает хуже, чем скорость, с которой мы можем отправить данные на его оборудование. Думаем, может, поможет анализ и управление трафиком? Но мнения по этому поводу сильно разнятся… так что пока не знаю.

@WirelessRudy: Да, заземление в Испании или в любой другой стране с очень жарким климатом может быть настоящей головоломкой… Лучше вообще не доверять тому, что уже установлено (если только вы не измеряли и не убедились, что всё нормально в сухой, жаркий летний день), и поставить собственное заземление. Всё необходимое можно взять у поставщика электроэнергии: специальные соли для проводимости и заземляющие стержни или пластины, которые лучше всего подходят для вашего типа грунта: http://www.dielectroindustrial.es/system/pdfs/164/original/Aplicaciones%20Tecnológicas%20Ca­tálogo%20Puesta%20a%20tierra%202011.pdf

Что касается speedtest, у вас есть свои собственные серверы? Большинство серверов установлены другими (W)ISP, поэтому замеры на них дадут довольно размытые результаты, ведь, как вы сами сказали, большинство из них работает с перегрузкой. Вы уверены, что проблема с задержкой обусловлена именно обратным давлением, а не проблемами с TCP-соединением или фрагментацией? Вы используете простые очереди на PPPoE AC для ограничения скорости? Полностью согласен… Я заметил, что одним из главных факторов, обеспечивающих ощущение «живого» и быстрого интернет-серфинга, является очень быстрый DNS-кэш и чтобы все ваши пользователи его действительно применяли.

Здесь идёт отличная дискуссия. Хотелось бы добавить одну деталь: если вы несколько раз переключаетесь между скоростями 100 Мбит/с и 1 Гбит/с по пути, это может вызвать проблемы, если оборудование не настроено должным образом. Допустим, роутер может передавать данные по гигабитному интерфейсу через коммутатор к какому-то устройству, но следующее устройство поддерживает только 100-мегабитный Ethernet. Представим такую схему: (R1) —гиг—> [switch] —фаcт—> {bridge} —фаcт—> [switch] —гиг—> (R2). R1 и R2 видят это как гигабитное соединение. Даже если вы ограничиваете очередь на 100 Мбит/с, могут возникать проблемы, потому что трафик всё равно проходит по линии с гигабитной скоростью, и в короткие промежутки времени вы можете превысить пропускную способность 100-мегабитных линий… А если {bridge} при этом испытывает перегрузку, помехи или имеет пониженные скорости передачи и приёма, ситуация ещё усугубится. В таком случае лучше использовать 100-мегабитные подключения от роутеров к коммутаторам, чтобы роутеры не могли «закидывать» пакеты в коммутаторы быстрее, чем те успевают обработать 100-мегабитные линейки. По моим наблюдениям, эту всю проблему называют «bufferbloat» (но могу ошибаться).