Работа с 1С:Предприятие в условиях удаленного доступа часто сопровождается жалобами на «зависания» и крайне медленный отклик интерфейса. Рассмотрим типичную ситуацию: когда база данных находится на сервере в локальной сети, а удаленный пользователь подключается через VPN. В этой статье мы разберем, почему стандартные методы подключения через общие папки не работают в интернете, и как правильно настроить систему для комфортной работы.
Проанализируем базовую ошибку многих администраторов: попытку прописать путь к базе через сетевую папку (протокол SMB/CIFS) поверх VPN-туннеля. Протокол SMB является крайне «разговорчивым» (chatty protocol). Для выполнения простейшей операции чтения файла 1С отправляет сотни мелких запросов, на каждый из которых требуется подтверждение.
В локальной сети с задержкой (пингом) менее 1 мс это незаметно. Однако в VPN-канале через интернет пинг возрастает до 30–50 мс и выше. Математика проста: если для открытия формы требуется 1000 мелких сетевых запросов, то при пинге 1 мс это займет 1 секунду, а при пинге 50 мс — уже 50 секунд. Именно поэтому автор темы сталкивается с трехминутным ожиданием окна авторизации. Выясним, как это исправить.
Самым эффективным способом работы тонкого клиента через интернет является использование веб-сервера. Веб-сервер выступает посредником, который общается с базой данных локально и передает клиенту только необходимые данные по оптимизированному протоколу HTTP/HTTPS.
Разберем алгоритм действий по шагам:
http://[адрес_сервера]/[имя_публикации].Это кардинально меняет принцип взаимодействия: тонкий клиент отправляет объемные пакеты данных, минимизируя количество обращений к серверу, что нивелирует влияние высокого пинга.
Проанализируем специфическую ошибку transferred a partial file. Она возникает, когда 1С пытается передать большой объем данных (например, кэш конфигурации), но пакеты «теряются» или «обрезаются» по пути. Причина кроется в параметре MTU (Maximum Transmission Unit).
Любой VPN-протокол (L2TP, PPTP, OpenVPN) добавляет свои служебные заголовки к каждому пакету. Если стандартный размер пакета в интернете 1500 байт, то после добавления заголовка VPN он может стать 1540 байт. Такой пакет не пролезет в канал провайдера и будет отброшен или фрагментирован, что вызывает зависания.
Для исправления ситуации на стороне клиента и сервера выполним команду в консоли CMD от имени администратора, чтобы принудительно уменьшить размер пакета:
netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "Название_Вашего_Подключения" mtu=1400 store=persistent
Установка значения 1400 или 1350 обычно полностью решает проблему «частичной передачи файлов» и обрывов сессии.
Посмотрим на настройки самого тонкого клиента. В окне выбора информационных баз, при нажатии кнопки "Изменить", на последней вкладке параметров есть флажок "Низкая скорость соединения".
Рекомендуем всегда включать этот режим при работе через VPN. Это заставляет платформу:
В обсуждении упоминаются протоколы L2TP и PPTP. Разберем их применимость. PPTP — самый быстрый за счет отсутствия сложного шифрования, но он считается небезопасным и часто блокируется провайдерами. L2TP/IPsec — тяжелый протокол, который создает большую нагрузку на процессоры роутеров (особенно Mikrotik), что увеличивает задержки.
Проанализируем современную альтернативу — WireGuard. Если ваше оборудование поддерживает его (например, Mikrotik с RouterOS v7), переход на него позволит получить:
Если вы выбрали Apache, стандартная публикация может работать не в полную силу. Выясним, как ускорить отдачу данных через конфиг httpd.conf. Нам нужно включить сжатие передаваемого контента, чтобы экономить трафик.
Рассмотрим пример настройки сжатия для Apache:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE application/x-1c-thin-client
</IfModule>
Также важно увеличить параметр KeepAliveTimeout до 15–30 секунд. Это позволит клиенту держать соединение открытым для серии запросов, не тратя время на повторное «рукопожатие» TCP при каждом клике мышкой в интерфейсе 1С.
Выясним причину долгого первого запуска. При первом подключении через веб-сервер тонкий клиент скачивает сотни мегабайт конфигурации во временные файлы (кэш). На нестабильном канале это может длиться бесконечно.
Практический совет: проведите первый запуск базы под пользователем в локальной сети предприятия. После того как кэш будет сформирован, отдайте ноутбук удаленному сотруднику. В последующем 1С будет докачивать только измененные объекты, что значительно ускорит старт.
Мы проанализировали ситуацию и пришли к выводу, что медленная работа 1С через интернет — это почти всегда проблема задержек и неправильной архитектуры подключения. Переход с «расшаренных папок» на веб-публикацию, коррекция MTU и использование режима низкой скорости соединения превращают работу в 1С из мучительного ожидания в комфортный процесс.