Между Екатеринбургом и Москвой пакет идёт около 35 мс в одну сторону. Обратный путь поднимает минимальный RTT до 70 мс. Если форма 1С последовательно обращается к серверу пять раз, пользователь ждёт сеть не меньше 350 мс — ещё до обработки запроса сервером и СУБД.
Покупка нового сервера эту паузу не уберёт. Сначала нужно выяснить, где задерживается операция, затем разделить трафик филиала: 1С и RDP оставить на защищённом маршруте к ЦОД, SaaS выпустить через ближайший интернет-шлюз, обновления кэшировать на месте.
Сравните одну операцию в ЦОД и филиале
Начните с одинакового действия: откройте заказ, добавьте строку, проведите документ. Выполните его рядом с сервером, затем из филиала. Сравнивайте не общее впечатление, а время одной операции.
Если оба сеанса медленные, длинный маршрут не главный подозреваемый. Проверяйте сервер 1С, SQL и диски. Если рядом с сервером форма отвечает быстро, а в филиале зависает после каждого поля, ищите задержку в RDS, VPN и WAN.
WeProf предлагает вести такую проверку по цепочке: рабочее место → RDS → VPN → сеть → сервер 1С → SQL → диски. Порядок не даёт перескочить сразу к покупке железа, пока причина сидит на предыдущем участке.
| Что видит пользователь | Вероятный участок | Как проверить | Следующее действие |
|---|---|---|---|
| Одна операция медленная и в ЦОД, и в филиале | Сервер 1С, SQL или диски | Сопоставить время операции с ожиданиями СУБД и нагрузкой дисков | Перейти к серверной диагностике |
| В ЦОД операция быстрая, из филиала задерживается | VPN или WAN | Измерить RTT, потери и колебание задержки на рабочем маршруте | Проверить маршрут и политику инспекции трафика |
| Курсор и окна RDP запаздывают даже вне 1С | RDS или кодек удалённого сеанса | Сравнить отклик интерфейса 1С с обычными окнами Windows | Проверить профиль RDP и видеокодек |
| Файловая база открыта через сетевую папку | Файловый доступ через WAN | Запустить клиент рядом с каталогом базы и повторить действие | Перенести запуск ближе к базе или перейти на клиент-серверный режим |
| Медленно открываются файлы и печатные формы | Антивирус на рабочем месте или RDS | Сопоставить паузы с журналом проверки файлов | Пересмотреть контролируемые каталоги по политике безопасности |
| Задержка растёт при одновременной работе пользователей | RDS или канал филиала | Разнести по времени пользовательскую нагрузку и загрузку обновлений | Отделить интерактивный трафик от массовых загрузок |
Вывод из таблицы простой: новый сервер не сокращает путь пакета через VPN, ЦОД и фаервол.
Для более широкой проверки пригодится маршрут диагностики от пользовательской операции до серверной инфраструктуры. Он нужен, если задержка повторяется и рядом с сервером.
Почему пять вызовов дают заметную паузу
RTT — время пути запроса до сервера и ответа обратно. Последовательные обращения складываются: следующий вызов не начинается, пока не завершился предыдущий.
Возьмём маршрут из статьи независимого эксперта по ИТ и ИБ Андрея Бирюкова: 35 мс в одну сторону между Екатеринбургом и Москвой. Для расчёта примем симметричный путь без потерь. Получаем минимальный RTT:
35 мс × 2 = 70 мс
Если ввод одной строки вызывает пять последовательных обращений к серверу, нижняя граница сетевого ожидания составит:
70 мс × 5 = 350 мс
Это только дорога. К ней добавятся обработка на сервере 1С, запросы к SQL, сериализация формы и передача данных. При другом RTT результат меняется линейно: умножьте измеренное время кругового пути на число последовательных вызовов.
В разборе Confaster приведён близкий сценарий: при RTT 80 мс пять контекстных вызовов во время ввода строки создают задержку 500–800 мс. Там же указан объём полного контекста формы при вызове &НаСервере: от 50 до 500 КБ. Эти значения относятся к описанной методике Confaster, а не к замерам нашей лаборатории.
Стандарт разработки 1С «Минимизация количества серверных вызовов и трафика» требует сокращать число обращений, передавать только нужные данные и объединять операции в пакеты. Это полезнее попытки компенсировать лишние вызовы широким каналом: пропускная способность ускорит передачу большого блока, но не отменит ожидание каждого RTT.
Администратор не исправит архитектуру формы настройкой маршрутизатора. Но он может доказать разработчику, что проблема связана с числом вызовов. Для этого сопоставьте одну пользовательскую операцию, события технологического журнала и сетевую задержку. Подробный порядок есть в материале про связь операции 1С с APDEX, техжурналом и метриками сервера.
Не возвращайте весь трафик филиала в ЦОД
Филиал часто отправляет через центральный фаервол всё подряд: 1С, RDP, Microsoft 365, видеосвязь, обновления Windows и антивирусные базы. Такой маршрут упрощает одну сетевую политику, но добавляет расстояние даже тем потокам, которым ЦОД не нужен.
Разделяйте трафик по назначению. Корпоративные приложения остаются на контролируемом маршруте. Разрешённые облачные сервисы выходят в интернет ближе к пользователю. Повторяющиеся загрузки распространяются внутри филиала.
| Поток | Рекомендуемый маршрут | Что контролировать |
|---|---|---|
| Тонкий клиент 1С | Филиал → защищённый туннель → ЦОД | RTT, потери, число серверных вызовов |
| RDP-сеанс с 1С | Филиал → защищённый туннель → RDS в ЦОД | RTT, потери, кодек, обрывы сеанса |
| Внутренние веб-сервисы | Филиал → туннель → корпоративный контур | Доступ по ролям, DNS и симметрию маршрута |
| Разрешённый SaaS | Филиал → локальный шлюз или ближайшая PoP-точка → интернет | Список приложений, аутентификацию и журналирование |
| Обновления Windows | Локальный интернет с Delivery Optimization либо филиальный кэш | Объём внешней загрузки и обмен блоками внутри сети |
| Антивирусные базы и образы ОС | Филиальный кэш, если продукт поддерживает такой режим | Срок обновления кэша и остаточную нагрузку на WAN |
Эта схема убирает из центрального канала повторяющиеся загрузки, но сохраняет контролируемый путь к 1С и внутренним сервисам.
Прямой выход для SaaS нельзя превращать в обход средств защиты. При асимметричном маршруте фаервол видит только часть соединения, поэтому его таблица состояний перестаёт соответствовать реальному сеансу. Андрей Бирюков также предупреждает: настройка uRPF в loosen mode помогает принять обратный трафик, но расширяет поверхность атаки.
Заранее определите, где завершится соединение, какой узел проверит сертификат и по какому пути пойдёт ответ. Политика должна описывать приложение и пользователя, а не только диапазон IP-адресов.
Если новая схема затрагивает место размещения базы, сопоставьте контроль, расходы и риски разных площадок для 1С. Маршрутизация не компенсирует неудачное расстояние между клиентом, сервером приложений и СУБД.
Кэш обновлений освобождает канал, но не лечит форму 1С
Кэш полезен там, где компьютеры филиала загружают одинаковые блоки. Обновления Windows подходят под это условие. Запросы работающих пользователей 1С — нет: состав данных зависит от формы, прав, параметров и текущего состояния базы.
В обзоре GSE режим BranchCache Distributed Cache рекомендован небольшим офисам без локального сервера. Части загруженного содержимого хранят рабочие станции и передают друг другу. Для этого компьютеры филиала должны видеть соседей по сети.
Hosted Cache складывает содержимое на выделенном филиальном узле. GSE относит этот режим к площадкам от 30 компьютеров с частыми волнами обновлений. Объём хранилища предлагают считать по размеру одной-двух крупнейших волн загрузки.
Это расчёт, а не готовая ёмкость. Допустим, крупная волна обновлений занимает 80 ГБ. При запасе на две волны получаем 80 ГБ × 2 = 160 ГБ полезного места. Если ваша крупнейшая волна занимает 200 ГБ, по тому же правилу потребуется до 400 ГБ без учёта резерва файловой системы.
Delivery Optimization распространяет блоки обновлений Windows между компьютерами без отдельного сервера. Состояние доставки проверяют командой:
Get-DeliveryOptimizationStatusПосле настройки убедитесь, что рабочие станции получают часть блоков от соседей, а не скачивают каждую копию через WAN. Если внешний трафик не снизился, проверьте границы группы, обнаружение узлов и прохождение пирингового обмена через сеть филиала.
Кэш не уменьшит число обращений формы 1С к серверу. Для интерактивной операции нужны короткий и стабильный путь, а также меньше последовательных вызовов.
SD-WAN не заменяет классификацию трафика
SD-WAN пригодится, когда у филиалов несколько каналов, облачные приложения и разные требования к маршрутам. Агент на рабочей станции может поднимать WireGuard- или IPsec-туннель до ближайшей точки присутствия провайдера — PoP. Там политика отделяет SaaS от корпоративного трафика.
В схеме Андрея Бирюкова решение можно привязать к сертификату пользователя и метке приложения. SaaS выходит в интернет через PoP, а корпоративное приложение уходит по IPsec в ЦОД. Такой подход точнее статического маршрута по IP-подсети, если сервисы меняют адреса.
Перед внедрением проверьте сценарий отказа PoP. При его недоступности активные TCP-сессии обрываются. Для RDP это означает потерю текущего подключения, даже если резервный маршрут поднимется через несколько секунд.
В статье Бирюкова перечислены варианты резервирования: Anycast с BGP, Multipath TCP и два WireGuard-endpoint с переключением. Это варианты архитектуры, а не универсальный рецепт. Выбор зависит от операторов связи, оборудования и допустимого перерыва.
После переключения проверяйте не только доступность адреса. Откройте существующий RDP-сеанс, запустите операцию 1С и оборвите основной путь. Так вы увидите, сохраняется ли работа пользователя или резервирование лишь создаёт новое соединение.
Если RDP остаётся медленным при нормальной работе базы, отделите передачу изображения от серверной операции. Для этого используйте проверку режима видеокодека в сеансе тонкого клиента.
Схема маршрутизации для типового филиала
Оставьте 1С, RDP и внутренние сервисы на защищённом маршруте к ЦОД. Для них измеряйте RTT, потери и стабильность, а не только доступную полосу.
Разрешённый SaaS выпускайте через локальный шлюз или ближайшую PoP-точку. Перед запуском проверьте симметрию маршрута, аутентификацию, журналирование и возвратный путь.
Обновления Windows раздавайте через Delivery Optimization. Если в филиале от 30 компьютеров и загрузки приходят волнами, оцените Hosted Cache по объёму одной-двух крупнейших волн.
Файловую базу не открывайте через сетевую папку по WAN. Запускайте клиент рядом с каталогом либо переносите базу в клиент-серверный режим.
После изменений повторите исходную операцию рядом с сервером и из филиала. Если разница исчезла, задержку создавал маршрут. Если тормозит только конкретная форма, считайте серверные вызовы и сопоставляйте их с технологическим журналом. Если медленно в обеих точках, возвращайтесь к SQL, дискам и серверу 1С.