Ночью быстро, днём вдвое медленнее: как найти перегруженный стык между провайдерами

MAATRIX

Сервер отзывается за 15 мс в три часа ночи и за 40-60 мс в шесть вечера буднего дня — и так изо дня в день, почти по расписанию. CPU на сервере простаивает, диск не нагружен, а разница видна ровно в те часы, когда у сети — пик активности. Это не совпадение и не «интернет вообще так работает», а почти всегда конкретный перегруженный участок на стыке двух сетей, который не справляется с суммарным трафиком именно в часы пик. Разберём, как это выглядит технически, как поймать такой стык замерами по часам и что делать, когда он найден.

Симптом: ночью быстро, днём медленно — и это стабильно

Прежде чем искать перегруженный стык, стоит убедиться, что симптом действительно тот самый:

• задержка и потери коррелируют с часами суток, а не со случайными моментами — на графике по дням пики ложатся примерно на одно и то же время (например, 10:00-14:00 и 18:00-22:00);
• деградация воспроизводится изо дня в день, а не была разово — регулярная просадка каждый будний вечер отличается от единичного скачка в среду в 15:03;
• на сервере в эти же часы не растёт нагрузка CPU, память, число соединений — узкое место не в самом сервере;
• то же самое видно с разных устройств и сетей на вашей стороне, а не только с одного домашнего Wi-Fi.

Если картина такая, дело почти наверняка не в сервере и не в вашем интернете как таковом, а где-то на маршруте между вами и им. О том, как вообще устроена связность между сетями и почему один хостер быстрее другого при том же железе, — в статье про пиринг и транзит простыми словами.

Что такое перегруженный стык между двумя сетями

У любого соединения между двумя автономными системами (AS) — прямой пиринг или транзитный канал — есть физический потолок пропускной способности: конкретное число портов, конкретная суммарная скорость линков между сетями в этой точке. Величина фиксированная, пока кто-то из операторов не проапгрейдит порт или не добавит канал.

Пока суммарный трафик через стык — от всех клиентов обеих сетей, а не только ваш — укладывается в эту пропускную способность, пакеты форвардятся почти без очереди. Проблема начинается, когда спрос в конкретные часы превышает физическую ёмкость канала: на маршрутизаторе растёт очередь в буфере интерфейса, а очередь — это рост задержки для всех, кто идёт через этот интерфейс. Если очередь переполняется быстрее, чем разгребается, буфер начинает отбрасывать пакеты (tail drop) — и это уже не задержка, а прямая потеря.

Ключевая особенность: деградация происходит на одном конкретном узле маршрута, независимо от того, насколько хороши остальные участки пути. У вас может быть отличный домашний интернет, у сервера — щедрый порт и мощная сеть дата-центра, а трафик всё равно пройдёт через единственный перегруженный стык где-то посередине — и именно там вырастут задержка и потери, сколько бы запаса ни было на остальном маршруте.

Типичная причина — недостаточно проапгрейженный пиринг или транзит между двумя конкретными сетями. Обе сети по отдельности могут быть надёжными операторами с запасом ёмкости внутри себя, но именно этот стык между ними исторически рассчитывался на меньший объём трафика, чем идёт сейчас: трафик рос органически, а расширение канала требует отдельных переговоров с контрагентом, заказа оборудования и времени на ввод в эксплуатацию — и не всегда поспевает за спросом. Пока апгрейд не случился, стык остаётся узким местом именно в часы пика хотя бы одной из сторон.

Отсюда суточная закономерность: ночью, когда совокупный трафик через стык заметно ниже, канала хватает с запасом. Днём, в часы пик, тот же канал уже не справляется с совокупным спросом — и разница видна именно на этом участке маршрута, а не равномерно по всей трассе.

План диагностики: почасовые замеры несколько дней подряд

Единичный traceroute или ping ничего не докажет — нужна статистика по времени суток за несколько дней, чтобы отделить закономерность от шума. Как читать mtr и почему промежуточные потери — не всегда реальные потери трафика (роутеры экономят на ICMP-ответах), разобрано в статье про локализацию участка потерь — прочитайте её перед тем, как интерпретировать результаты ниже.

1. Настройте регулярный замер по расписанию. Раз в час — разумный компромисс между детализацией и объёмом логов:

#!/bin/bash
# hourly-mtr.sh — обёртка для cron с меткой времени
TARGET="203.0.113.10"
LOGDIR="/var/log/mtr-hourly"
mkdir -p "$LOGDIR"
{
  echo "=== $(date '+%Y-%m-%d %H:%M:%S %Z') ==="
  mtr -rwzc 200 --report "$TARGET"
} >> "$LOGDIR/$(date +%Y-%m-%d).log" 2>&1

# crontab -e
0 * * * * /usr/local/bin/hourly-mtr.sh

Флаг -z добавляет AS-номер каждого хопа — пригодится, чтобы понять, на границе каких сетей находится проблема. -w — широкий формат без обрезки имён хостов, -c 200 — 200 пакетов на цикл, вполне достаточно для статистики за один замер.

1. Дайте замерам накопиться минимум 3-4 суток подряд, включая хотя бы один выходной — трафик в выходные часто распределён иначе. Чем длиннее период, тем увереннее можно отличить закономерность от разовой аномалии (авария, плановые работы, внешний всплеск трафика).

1. Учитывайте часовой пояс обеих сторон. «Час пик» может определяться не вашим локальным временем, а временем той стороны, где физически больше трафика проходит через стык. Если не уверены — замеряйте полный суточный цикл, а не только «свои» рабочие часы.

1. По возможности запустите встречный замер и с сервера (если есть SSH-доступ) — полезно убедиться, что путь «туда» и «обратно» ведёт себя схоже, а не так, что проблема есть только в одном направлении.

Как локализовать конкретный хоп

Когда логов накопилось на несколько дней, задача — найти конкретный хоп, чья деградация коррелирует с часами пик, пока остальные хопы стабильны в любое время суток.

1. Возьмите один и тот же час за несколько дней (например, 19:00) и сравните с тем же часом ночью (например, 04:00). Смотрите не на итоговую задержку до цели, а на Loss% и Avg по каждому хопу отдельно.

1. Убедитесь, что маршрут (список IP-хопов) в дневных и ночных замерах одинаковый. Если хопы отличаются — между замерами перестроился BGP-маршрут, и сравнивать задержку по позиции хопа некорректно: возможно, днём трафик вообще идёт другим путём. Ищите пары замеров с идентичным списком хопов.

1. Найдите хоп, где разница между днём и ночью максимальна и устойчиво повторяется изо дня в день. Пример структуры сравнения (условная иллюстрация метода, а не реальные измеренные цифры):

Важны два признака сразу: деградация появляется резко на одном хопе, а не растёт равномерно по трассе, и она переносится на все последующие хопы вплоть до цели, а не гаснет сразу после проблемного узла. Это отличает реальную потерю от диагностического шума ICMP — критерий подробно разобран в статье про локализацию участка потерь.

1. Обратите внимание на пару AS-номеров вокруг подозрительного хопа. Хоп, где меняется AS-номер, — это и есть граница между сетями, потенциальная точка пиринга или транзита. Если деградация начинается ровно на переходе из одной AS в другую и коррелирует с часами пик — это и есть перегруженный межсетевой стык.

Как отличить перегруженный стык от других объяснений

Прежде чем писать в поддержку, стоит исключить соседние по симптомам причины:

• ICMP rate-limiting на конкретном роутере. Если хоп теряет пакеты стабильно что днём, что ночью примерно одинаково, а следующие хопы всегда чистые — это экономия control plane на диагностических ответах, а не перегрузка. Признак настоящей суточной перегрузки — разница именно между днём и ночью на одном и том же хопе.
• Смена маршрута между замерами. Если днём и ночью список хопов разный, сравнение по позиции хопа некорректно — сначала убедитесь, что путь одинаков.
• Проблема на вашей стороне в определённые часы (домочадцы грузят канал, соседи по Wi-Fi). Тогда деградация видна с самого начала трассы, а не начинается на промежуточном хопе на границе сетей.
• Перегрузка на самом сервере или в локальной сети дата-центра, а не на межсетевом стыке. Если деградация начинается только на последнем хопе-двух перед целью и не связана с переходом между AS — это вопрос к хостинг-провайдеру, а не к пирингу с внешним оператором.

Если после проверки картина по-прежнему указывает на один хоп на границе двух AS, с деградацией, устойчиво привязанной к часам пик и повторяющейся несколько дней подряд, — данных достаточно для предметного обращения.

Что делать дальше: к провайдеру с данными, потом — обходной путь

Идите в поддержку своего провайдера с конкретными данными, а не с жалобой «у меня медленно». Формулировка с приложенными логами mtr за несколько дней, конкретным хопом, AS-номерами по обе стороны стыка и повторяющимся временным окном — это техническая заявка, по которой NOC может сразу проверить загрузку конкретного порта или обратиться к контрагенту. У обычного клиента обычно нет прямого канала связи с чужой транзитной или пиринговой сетью — но у провайдера или у хостинга сервера есть коммерческие отношения с апстримами, и они могут эскалировать проблему через NOC контрагента либо переключить трафик на резервный канал.

Дайте время отреагировать, но не бесконечно. Апгрейд пирингового или транзитного канала — не быстрая операция: заказ ёмкости, согласование с контрагентом, физическая работа на оборудовании занимают недели, иногда месяцы. Разумно попросить провайдера подтвердить, что проблема на их стороне (или у контрагента) признана, и уточнить примерные сроки.

Если провайдер не может или не готов чинить конкретный стык — рассмотрите альтернативный маршрут:

• Другой транзитный путь, если есть выбор между несколькими провайдерами связи (второй канал на сервере, другой ISP на вашей стороне) — трафик через другую сеть может обходить перегруженный стык, если у неё другая топология пиринга.
• VPN через третью сеть — туннель до промежуточного узла, соединённого с вашей сетью и с сетью сервера иначе, чем прямой маршрут, так что трафик физически пойдёт через другой набор межсетевых стыков. Манёвр рабочий, но не бесплатный: туннель добавляет свой накладной расход, и промежуточную точку стоит выбирать осознанно — иначе есть риск упереться в ещё один узкий стык на новом маршруте.
• Смена дата-центра или локации сервера. Если проблема системная и упирается именно в связность конкретного дата-центра с нужным регионом, иногда практичнее не бороться с чужим пирингом, а перенести сервер туда, где связность устроена лучше изначально. Показательный пример того, как локация сервера сильнее физического расстояния влияет на реальную задержку, — в статье про Франкфурт быстрее Москвы для москвичей.

Ни один из обходных путей не заменяет апгрейда самого стыка — это временная компенсация. Но пока провайдеры договариваются и заказывают оборудование, обходной маршрут снимает боль здесь и сейчас, если проект не может позволить себе ждать неделями.

Частые вопросы