Иллюстрация расчёта: возьмите число активных пользователей, умножьте на средний объём трафика на пользователя и на долю одновременно активных сессий, затем умножьте на коэффициент пиковости 1,2–1,5. Например: 1 000 пользователей ? 2 Мбит/с ? 0,10 ? 1,3 = 260 Мбит/с. Бронируйте канал минимум на 20–30% выше этой цифры. Контрольные ориентиры для эксплуатации: задержка до шлюза <50 мс, потеря пакетов <0,1%, загрузка CPU маршрутизатора <70%.
Собирайте статистику по расписанию: SNMP/telemetry – интервал 60 с; экспорт потоков (NetFlow/sFlow) – интервал 60 с с коэффициентом выборки 1:1 000 на 10+ Гбит линках; для 40+ Гбит берите 1:10 000. Тесты пропускной способности делайте iperf3: длительность 60 с, 4 параллельных потока; для UDP задавайте целевую нагрузку и контролируйте потерю, для TCP смотрите retransmits и 95-й перцентиль скорости. На практике P95 задержки >100 мс или постоянный рост retransmits – сигнал к детальному исследованию.
Что хранить и как тревожить систему: метрики с шагом 1 мин – сохраняйте 30 дней, агрегируйте в 5?мин для годового архива. Наблюдайте за: битрейтом (бит/с), количеством одновременных сессий, TCP retransmits, P50/P95/P99 задержками, джиттером, потерями пакетов, ошибками интерфейсов, CPU/RAM устройств. Триггеры – устойчивое использование интерфейса >70% в течение 10 минут; retransmits >1%; потеря пакетов >0,5% – оперативная проверка линейки и конфигурации MTU.
Инструменты для контроля и анализа: Prometheus + Grafana для метрик, nfdump/ntopng или Flow Collector для потоков, Telegraf/Zabbix для SNMP. Да, иногда всё скачет – не паникуйте: вечерние трансляции могут поднимать пик на 40–60% пару часов. Хотите точнее? Запустите пассивный сбор 7 суток, посмотрите P95 и P99, затем повторите расчёт с учётом сезонности. А если сомневаетесь – начинайте с пилотного увеличения канала на 30% и отслеживайте поведение в реальном времени.
Расчет пикового трафика по физической линии: сбор профиля, формула и численный пример
Собирайте профиль линии с интервалом выборки ?60 с (лучше 1 с для критичных каналов), храните минимум 7 суток, оптимально – 30; фиксируйте байты вход/выход, пакеты и ошибки, отдельно по интерфейсам. Рекомендация: снимайте сырые счётчики через SNMP/NetFlow/IPFIX или зеркалирование порта и сразу переводите в бит/с по формуле r = (?bytes·8)/?t – прямо так и берите для последующего анализа.
Постройте временной ряд R[k] в бит/с, удалите шум через медианный фильтр и отсеките выбросы выше 99-го перцентиля (или помечайте их как эпизоды тестирования). Для оценки реального пика применяйте скользящее окно длиной T (например, 1 с для VoIP, 300 с для транзитных каналов) и рассчитывайте усреднённую скорость по окну; это покажет устойчивый пик, а не разовый скачок.
Формула (продолжительная и дискретная): P_T = max_t (1/T ?_{t}^{t+T} r(?) d?). Для дискретных замеров с шагом ?t: P_T = max_k (1/N ?_{i=0}^{N-1} R[k+i]), где N = T/?t, R в бит/с. Для проектирования берите запас H (headroom): Provision = P_T ? H, H обычно 1.2–1.5 в зависимости от допустимого риска; округляйте до ближайшего доступного канального размера.
Численный пример: ?t = 60 с, T = 300 с (N = 5). Снятые значения в Мбит/с: [10, 12, 50, 55, 60, 40, 20, 15, 10, 8]. Скользящие средние по 5 точкам: 37.4, 43.4, 45.0, 38.0, 29.0, 18.6 Мбит/с. Максимум P_T = 45 Мбит/с. При запасе H = 1.25 требуется Provision = 56.25 Мбит/с > округляем до 60 Мбит/с или выбираем ближайший коммерческий канал (например, 100 Мбит/с). Понравилось? Практично и прямо.
Учтите ловушки: 32?битные счётчики (bytes) переполняются за ~34 с при 1 Гбит/с (4 294 967 296 B / 125 000 000 B/s ? 34.36 s), при 10 Гбит/с – ещё быстрее; без паники – включайте 64?битные счётчики или повышайте частоту снятия, фиксируйте метки времени, коррелируйте с событиями (деплой, тесты). Шумы от зеркалирования, бэкапов и периодических тестов могут сильно искажать P_T – сверяйте с логами.
Короткий чек?лист для вас: ?t ?60 с (или 1 с для бурстов), хранение 7–30 суток, выбрать T по SLA и по типу трафика, очистка выбросов (медиана/99?й перцентиль), вычислить P_T по формуле и умножить на H=1.2–1.5, документировать и периодически пересматривать профиль. Что делать, если P_T почти равен доступной полосе? Подумайте об очередях, shaping?правилах, перераспределении трафика или апгрейде канала – иногда проще увеличить линию, чем постоянно дуть на холодные числа.
Моделирование нагрузки на сетевое устройство (маршрутизатор/коммутатор): учёт сессий, CPU и памяти с практическим расчётом
Рекомендую заложить запас 30% оперативки и 1–2 дополнительных ядер ЦП при планировании пиковых потоков. Формулы для быстрой оценки: ОЗУ = R0 + N ? S, где R0 – системная база (MB), N – одновременно активных сессий, S – состояние одной сессии (KB); CPU_требование (в циклах/с) = PPS ? C, где PPS = N ? p (p – среднее пакетов в секунду на сессию), C – циклы на пакет. Пример: N=120000, S=1.4KB, R0=512MB > ОЗУ?512 + 120000?1.4KB = 680MB, с запасом 30% ? 884MB > округлите до 1GB. Для CPU: p=2pps > PPS=240000; при C=2000 циклов > 240k?2000=480M циклов/с; одно ядро 1.6GHz даёт 1.6G циклов/с, значит одно ядро покрывает базовый трафик, но если включить NAT/ACL (C?10000) > нужно ?2 cores, при DPI (C?20000) ?3 cores. Учтите, что аппаратные ускорители и NPU снижают нагрузку на процессор, а короткие пакеты и всплески увеличивают потребление циклов и память сессий – ±10–20% вариабельность в реальных условиях.
План тестирования: шаговая нагрузка 10k>50k>120k с мониторингом: SNMP hrProcessorLoad (1.3.6.1.2.1.25.3.3.1.2), show processes cpu, show memory statistics, счётчики коннектов и падений пакетов; фиксируйте CPU%, RSS памяти, количество активных сессий и latency. Видите, что CPU прыгает до 80% при включённом NAT – значит либо добавить ядра, либо включить offload; не паникуйте, но готовьтесь к корректировке параметров – есть неопределённость в метриках из?за размера пакетов, времени жизни сессий и особенностей приложений. Хочешь, просчитаю под твою конфигурацию – кидай числа и договоримся, где ставить запас.
Оценка нагрузки беспроводной сети (Wi?Fi): расчёт плотности пользователей, время эфира и пример планирования каналов
Рекомендация: ограничьте число активных клиентов на одну точку доступа до 20–25 при 20 МГц в 2.4 ГГц и до 40–50 при 80 МГц в 5 ГГц для смешанного офисного трафика; для видеоконференций ставьте потолок 8–12 подключений на AP. Это реально уменьшит задержки и убьёт лишнюю латентность – да, звучит строго, но работает.
Формула для оценки плотности: плотность (польз./м?) = общее число клиентов / площадь помещения. Для планирования пропускной способности используйте: необходимая суммарная скорость = число клиентов ? средняя скорость на клиента. Далее число AP = ceil( (необходимая суммарная скорость ? запас) / практическая полоса AP ). Примеры средних скоростей: веб/почта 0.5 Мбит/с, стриминг SD 2 Мбит/с, HD 5–8 Мбит/с. Запас возьмите 1.2–1.5 для пиков и ретрансляций.
Время эфира (airtime): время одного кадра ? (размер_кадра_бит / PHY_rate) + протоколные задержки (преамбула, SIFS, ACK). Пример: кадр 1500 байт = 12 000 бит; при PHY 54 Мбит/с время передачи ? 0.222 мс, при 6 Мбит/с – ?2.0 мс. Итоговая загрузка эфира (%) = (сумма(время_передачи_всех_пакетов) / окно_измерения)?100. Практическое правило: держите занятость эфира < 40% для хорошей интерактивности; > 60% – начинаются таймауты и падение качества, нервно и грустно.
| Сценарий | Средняя, Мбит/с на клиента | Клиентов | Суммарная требуемая, Мбит/с | Goodput AP, Мбит/с | AP (по трафику) | Рекомендация по диапазону |
|---|---|---|---|---|---|---|
| Лёгкий офис | 0.5 | 100 | 50 | 150 | 1 (с запасом 1.3 > 2) | 5 ГГц, 20 МГц |
| Смешанный офис | 2.0 | 200 | 400 | 200 | ceil(400?1.3/200)=3 | 5 ГГц, 40–80 МГц (внимательно) |
| Видео?интенсив | 5.0 | 150 | 750 | 200 | ceil(750?1.3/200)=5 | 5 ГГц, 80 МГц (редко) |
Как распределять каналы: в 2.4 ГГц используйте только 1, 6, 11 (или 1/5/9 в регионах с другой политикой) – иначе перекрытия убьют эфир; в 5 ГГц отдавайте предпочтение 20 МГц в плотных зонах, 40 МГц там, где AP мало, и 80 МГц только в больших залах без соседних сетей. Правило на глаз: если плотность AP велика – сужайте полосу, иначе будете бороться с взаимной помехой – и это реально бесит.
Практическое планирование для офиса 2 000 м? с 200 пользователями: плотность = 0.1 пользов./м?; суммарный спрос при 2 Мбит/с = 400 Мбит/с; по трафику требуется ?3 AP (с запасом 1.3 > 4), но покрытие (один AP ? 150–250 м? при внутренней разводке) диктует ~10 AP. Выбирайте максимум(требований по трафику, покрытию). Разнесите каналы так: ряд A – 36/40/44 (20 МГц), ряд B – 44/48/52 с учётом DFS; избегайте соседних AP на одном канале ближе 15–30 м в 5 ГГц и 30–50 м в 2.4 ГГц. Поняли? Немного муторно, зато после этого нагрузка перестанет пугать.
Не всё идеально заранее: измеряйте после включения. Сканер спектра, мониторинг airtime, отчёты по ретрансмиссиям и pings – ваши друзья. Если видите airtime >50% или Jitter растёт – добавляйте AP, сужайте полосу, пересмотрите канал. Немного терпения, пара ночных вылазок с ноутом и вы получите рабочую картинку – да, есть сложности, но настройка оправдает усилия.