← На главную

Рассмотрим весьма распространенную ситуацию, с которой сталкиваются многие разработчики и системные администраторы. Имеется сервер с базой 1С в локальной сети предприятия. Вы подключаетесь к этой сети удаленно через VPN. Скорость интернет-канала отличная (например, 20 Мбит/с и выше), выгрузка базы данных в виде файла происходит быстро. Однако, когда вы пытаетесь открыть Конфигуратор или запустить сложные запросы, система начинает невероятно "тормозить".

Проанализируем сетевой трафик в этот момент: мы увидим, что скорость передачи данных падает до 80-100 Кб/сек, а количество передаваемых пакетов фиксируется на отметке около 80 пакетов в секунду (в некоторых случаях мониторы показывают это как пакеты в минуту, но технически речь идет именно о секундах). Давайте разберем по шагам, почему так происходит, куда исчезает скорость и как мы можем решить эту проблему.

В чем кроется причина: особенности архитектуры 1С

Первое, что приходит в голову — системный администратор установил жесткие лимиты или "порезал" трафик в настройках VPN. Но чаще всего дело совершенно в другом. Выясним истинную причину.

Дело в том, что Конфигуратор и "Толстый клиент" платформы 1С используют синхронный метод обмена огромным количеством мелких пакетов, известный как Remote Procedure Call (RPC). Архитектура этого протокола подразумевает следующую логику работы:

1. Клиент (ваш Конфигуратор) отправляет небольшой пакет данных на сервер.
2. Клиент полностью блокируется и ждет подтверждения от сервера о том, что пакет успешно получен (ACK).
3. Только после получения подтверждения клиент отправляет следующий пакет.

В этой схеме ширина вашего канала (те самые 20 Мбит/с) практически не играет роли. Главным физическим ограничением становится latency (задержка или пинг). Посмотрим на простой математический пример. Если время прохождения сигнала туда-обратно (пинг) в вашем VPN-канале составляет около 12-13 миллисекунд, то за одну секунду (1000 мс) физически может пройти только около 80 таких циклов "запрос-ответ" (1000 / 12.5 = 80).

Именно поэтому объемные файлы, такие как резервные копии, скачиваются быстро — там данные летят сплошным асинхронным потоком. А вот открытие дерева метаданных в Конфигураторе упирается в жесткий лимит пакетов в секунду, продиктованный задержками сети.

Влияние фрагментации пакетов и MTU

Рассмотрим еще один важный сетевой аспект — фрагментацию пакетов в VPN-туннелях. VPN инкапсулирует ваш трафик, добавляя к каждому пакету свои служебные заголовки для маршрутизации и шифрования. Из-за этого максимальный размер полезных данных, который может поместиться в один пакет (параметр MTU — Maximum Transmission Unit), уменьшается.

Если сетевое оборудование или адаптер Windows не настроены с учетом этого уменьшения, происходит фрагментация. Один пакет данных от 1С не помещается в туннель и разбивается на два или более мелких пакета. Это кратно увеличивает количество пересылаемых пакетов и, как следствие, задержки.

Что мы можем сделать? Протестируем нашу сеть. Рекомендуется использовать команду ping с ключами запрета фрагментации. Откройте командную строку и выполните команду по аналогии с ping -f -l 1400 IP_сервера. Изменяя размер пакета (в данном примере 1400), вы можете опытным путем подобрать максимальный размер, при котором пакеты проходят без фрагментации, и жестко прописать этот MTU в настройках вашего VPN-клиента.

Тюнинг стека TCP в Windows

Иногда ускорить передачу мелких пакетов можно на уровне настроек операционной системы. По умолчанию Windows использует алгоритмы, оптимизирующие пропускную способность, но не задержки. Например, алгоритм Нейгла собирает мелкие пакеты в один большой перед отправкой, а система может задерживать отправку подтверждений (ACK).

Для ускорения работы RPC можно попробовать отключить эти оптимизации через реестр, настроив параметры TcpAckFrequency (установив значение 1) и TCPNoDelay. Это заставит систему отправлять пакеты и подтверждения мгновенно, не дожидаясь накопления данных.

Организационные и технические пути решения

Согласно официальным рекомендациям фирмы "1С", Конфигуратор и Толстый клиент не предназначены для работы по WAN-сетям (через интернет или VPN) именно из-за их высокой чувствительности к задержкам. Посмотрим, какие существуют реальные способы организации комфортной работы:

1. Терминальный доступ (RDP). Это золотой стандарт и самое правильное решение. Вы подключаетесь к удаленному рабочему столу на сервере (или специальной терминальной машине рядом с сервером базы данных) и запускаете Конфигуратор там. В этом случае по сети передается только картинка, а все тяжелые RPC-запросы выполняются внутри быстрой локальной сети (или внутри одного сервера). Если администратор запрещает RDP, это противоречит здравому смыслу эксплуатации 1С.
2. Разработка на локальной копии с использованием файлов .cf Если терминальный доступ получить категорически невозможно, организуйте работу иначе. Поднимите локальную копию базы данных на своем компьютере. Ведите всю разработку и отладку локально — отклик будет мгновенным. По завершении этапа разработки создавайте файл конфигурации (расширение .cf) или файл обновления (.cfu) и загружайте его на сервер через VPN. Загрузка файла происходит потоково и не страдает от задержек так сильно, как интерактивная работа в дереве конфигурации.
3. Использование 1C:EDT. Современной альтернативой стандартному Конфигуратору является среда разработки 1C:Enterprise Development Tools (на базе Eclipse). В этой парадигме разработка ведется полностью локально, а синхронизация изменений с сервером осуществляется через системы контроля версий (например, Git). Это решает проблему медленных сетей на архитектурном уровне.

Подводя итог, можно сказать, что ограничение скорости при работе Конфигуратора через VPN — это не злой умысел системного администратора и не настройка сервера 1С. Это фундаментальное ограничение протоколов связи, требующих минимального пинга. Выбирайте правильную архитектуру разработки: требуйте RDP или переходите на локальную разработку с переносом конфигурации.