Толстый и тонкий клиент в 1С: в чем разница для терминального сервера

Вы подняли RDS-ферму, завели на неё 30 пользователей 1С, всё работает - и вдруг в часы пик сервер начинает захлёбываться. CPU под 90%, пользователи жалуются на лаги, а машина с 64 ГБ оперативки не справляется с бухгалтерией. Скорее всего, железо тут ни при чём. Причина в том, какой клиент 1С вы поставили на терминал.

Разница между толстым и тонким клиентом в одном: где выполняется бизнес-логика. Толстый считает у себя - то есть в терминальной сессии, на процессоре и в памяти вашего RDS-хоста. Тонкий отдаёт вычисления серверу 1С, а сам рисует интерфейс и передаёт действия пользователя. Отсюда всё остальное: сколько сессий влезет на хост, сколько уйдёт трафика, как обновлять платформу и что будет при обрыве связи.

В каких режимах может работать клиент 1С

Режимов три, и путаница обычно начинается с того, что их считают двумя.

Толстый клиент (1cv8.exe) - полноценное приложение. Выполняет почти весь встроенный язык, работает с файловой и клиент-серверной базой, содержит конфигуратор. Это единственный режим, в котором можно разрабатывать и отлаживать конфигурации.

Тонкий клиент (1cv8c.exe) - появился в платформе 8.2 вместе с управляемым приложением. Умеет ограниченный набор возможностей встроенного языка: всё тяжёлое уезжает на сервер, клиент отвечает за интерфейс. Работает и с клиент-серверной, и с файловой базой - для файлового варианта при установке платформы ставится отдельный компонент.

Веб-клиент - тот же тонкий по логике, но живёт в браузере и не требует установки вообще. Появился одновременно с тонким, в 8.2; в 8.3 его довели до состояния, в котором на нём реально работают.

Для терминального сервера практически всегда выбор идёт между первыми двумя. Веб-клиент вообще снимает вопрос терминала - о нём в конце.

Как устроены оба режима

Главное различие - где выполняется бизнес-логика. Толстый клиент берёт на себя основную часть вычислений прямо на клиентской машине, а в RDS это одно и то же, что и в терминальной сессии. Тонкий клиент делегирует почти всю логику серверу 1С, а сам занимается отрисовкой интерфейса и передачей пользовательских действий.

В однопользовательском сценарии это почти незаметно. Но в терминальной ферме, где одновременно работают 30, 50 или 100 сессий, разница становится критической. Именно здесь выбор режима определяет, сколько пользователей вы сможете посадить на один хост без деградации.

Отдельно про файловые базы, потому что тут гуляет устойчивое заблуждение. Тонкий клиент работает с файловой базой - в дистрибутиве платформы для этого есть отдельный компонент «тонкий клиент, файловый вариант». Ограничение в другом: в файловом режиме тонкий клиент сам поднимает у себя серверную часть, и выигрыша по нагрузке на терминальный хост почти не остаётся. То есть технически можно, а смысла в RDS немного. Если у вас файловая база на 20+ пользователей в терминале - начинать надо с миграции на клиент-сервер, а выбор клиента обсуждать уже потом: разбор двух архитектур есть в статье про файл-серверную и клиент-серверную архитектуру.

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

Разница в пять-шесть раз по плотности пользователей напрямую влияет на стоимость инфраструктуры - и на то, сколько серверов вам придётся купить.

Что происходит в терминальной сессии

Когда пользователь открывает 1С через RDP, его сессия - это виртуальный рабочий стол на сервере. Толстый клиент в этой сессии ведёт себя ровно так же, как на физической машине: грузит отчёты локально (то есть на CPU сервера), кэширует данные в памяти сессии, обращается к базе напрямую.

Теперь умножьте это на 30 пользователей. Каждый открыл оборотно-сальдовую ведомость за квартал - и сервер одновременно обрабатывает 30 тяжёлых запросов прямо в оперативной памяти сессий. Никакое железо не спасёт, если архитектура не рассчитана на такой сценарий. Отсюда и 90% CPU при, казалось бы, нормальных характеристиках хоста.

Тонкий клиент в той же ситуации отправляет запрос на сервер 1С (отдельный процесс - rphost), тот обрабатывает его централизованно с использованием серверного кэша и возвращает клиенту только готовый результат. Нагрузка на терминальный хост - минимальная. Сервер 1С может быть отдельной машиной, и тогда вычислительная нагрузка уходит с RDS-хоста полностью.

Есть ещё момент, который часто упускают: сетевой трафик внутри фермы. Толстый клиент гоняет данные между базой и сессией в сыром виде - таблицы, объекты, регистры. Тонкий передаёт только управляющие команды и готовые результаты. На ферме из 50 пользователей экономия трафика получается порядка 50-70%, и это ощутимо даже при гигабитном линке между хостами, особенно если серверы стоят в разных стойках.

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

Безопасность и данные

Тонкий клиент в терминальной среде выигрывает принципиально - особенно если в компании есть BYOD или удалённые пользователи. Вся бизнес-логика и данные находятся исключительно на сервере 1С. На терминальной сессии хранится только состояние интерфейса. Даже если пользователь работает с личного ноутбука через RDP, он видит только экран, данные физически никуда не уходят с периметра компании.

Толстый клиент кэширует часть данных локально, внутри сессии. При компрометации сессии (перехват RDP-трафика, уязвимость в хосте) эти данные потенциально доступны злоумышленнику. Для офлайн-аудита иногда удобно, но с точки зрения ИБ-политики и требований регуляторов это дополнительный риск, который нужно закрывать отдельными инструментами. Если инфраструктура готовится к проверке, стоит заранее разобраться, как подготовить серверную инфраструктуру к ИБ-аудиту.

Деплой и обслуживание

Это тема, которую часто недооценивают при выборе архитектуры - и потом жалеют. Толстый клиент нужно ставить на каждую машину или сессию отдельно, следить за синхронизацией версий платформы со стороны сервера 1С. Рассинхронизация версий - распространённая причина загадочных ошибок подключения, которые потом несколько часов разбирают в поддержке.

Тонкий клиент в терминальной ферме разворачивается один раз на хосте. Обновление платформы - одна операция, которая сразу применяется ко всем сессиям. Через GPO и MSI-пакет это делается за считаные часы на парк из полусотни машин. Без ручной беготни по рабочим местам, без рассинхронизации версий, без звонков «у меня 1С не открывается» на следующий день после обновления.

Для Proxmox-кластеров или гибридных RDS-ферм централизованный деплой - стандартная практика, которая экономит часы работы при каждом релизе платформы. Если добавить автоматизацию через Ansible или скрипты PowerShell для управления сессиями, обслуживание фермы на 100+ пользователей превращается из рутины в набор повторяемых процедур. Как поднять сам терминал, если его ещё нет, разобрано отдельно: настройка терминала для 1С с нуля.

Как понять, какой клиент запущен прямо сейчас

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

Самый быстрый способ на терминальном хосте - диспетчер задач: отсортируйте процессы по имени и посмотрите, чего у вас больше. Если в ферме, которую вы считали тонкой, висит десяток 1cv8.exe по 400 МБ каждый - вы нашли причину нагрузки. Такое обычно случается, когда пользователи запускают базу старым ярлыком, оставшимся с прошлой инсталляции.

Когда толстый клиент всё-таки нужен

Было бы нечестно говорить, что тонкий клиент - универсальный ответ. Есть сценарии, где толстый незаменим.

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

Нестабильный канал связи - второй сценарий, но с важной оговоркой про терминал. Если 1С запущена локально на машине пользователя и работает с файловой базой, толстый клиент переживёт обрыв сети. Если же пользователь сидит в RDS, при обрыве канала у него отвалится сама RDP-сессия - и режим клиента тут уже ничего не меняет. Так что этот аргумент работает против терминального доступа как такового, а не в пользу толстого клиента внутри него. Для филиалов с плохим интернетом иногда честнее локальная установка, чем терминал.

Третий сценарий - массовые операции загрузки и обработки данных. Загрузка прайс-листов, обмен с внешними системами, групповая переработка документов: толстый клиент обрабатывает данные у себя, убирая часть сетевых обращений. Актуально прежде всего для файловых баз; в клиент-серверной архитектуре разница сглаживается серверным кэшем 1С, а тяжёлые обработки правильнее вообще выносить в регламентные задания на сервере.

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

Требования к серверу 1С в терминальной среде

Переход на тонкий клиент переносит нагрузку с терминального хоста на сервер 1С - и это обязательно нужно учитывать при планировании железа. Экономия на терминальном хосте не должна обернуться недостаточно мощным сервером приложений, иначе узкое место просто переедет.

Ниже - ориентиры по железу для сервера 1С при 50+ пользователях в тонком режиме. Если вы ещё на этапе выбора конфигурации, посмотрите разбор идеальной конфигурации терминального сервера для 1С - там про терминальный хост, здесь про сервер приложений:

• CPU. Минимум 8 физических ядер, комфортно от 16. Важнее количества - частота: значительная часть кода конфигурации исполняется последовательно, и сервер 1С плохо разгоняется добавлением ядер сверх нужного. Берите линейки с высокой базовой частотой - у Intel это старшие Xeon Gold, у AMD высокочастотные EPYC. Если бюджет ограничен и вы смотрите на восстановленное оборудование, EPYC 7003 или Xeon Scalable третьего поколения ещё уверенно тянут такие задачи, просто это уже не выбор для новой закупки.
• RAM. 32 ГБ на 50 пользователей - стартовая точка. При работе с тяжёлыми отчётами и аналитикой закладывайте 64 ГБ и выше. Серверный кэш 1С живёт в памяти, и его нехватка сразу чувствуется на времени открытия отчётов.
• Дисковая подсистема. SSD или NVMe без компромиссов. Серверный кэш 1С и журналы транзакций СУБД активно работают с диском. HDD здесь - прямой путь к деградации под нагрузкой, особенно в часы пик.
• Сеть. Гигабитный линк между сервером 1С и терминальным хостом - базовый минимум. При 100+ активных сессиях разумно рассмотреть 10GbE, особенно если база и сервер приложений разнесены по разным узлам.

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

Мониторинг через Zabbix для таких конфигураций обязателен. Метрики нагрузки на rphost-процессы, объём рабочих процессов кластера 1С, время выполнения серверных вызовов, очереди на сервере СУБД: по ним узкое место видно раньше, чем пользователи начнут звонить. Реагировать на жалобы всегда дороже, чем предотвращать деградацию заранее.

Куда движется платформа

Веб-клиент появился ещё в 8.2, вместе с тонким, но по-настоящему рабочим стал в 8.3. Он живёт в браузере, не требует установки клиентской части вообще и хорошо подходит для удалённых филиалов и мобильных пользователей. Нагрузка на терминальный хост практически нулевая - всё уходит на сервер 1С и веб-сервер (Apache или IIS). Терминальный доступ при этом просто исчезает из уравнения.

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

RDP-сервер для 1С останется актуальным ещё долго: не все конфигурации готовы к веб-клиенту, не у всех есть инфраструктура и компетенции для его поддержки. Но вектор понятен - чем меньше логики на клиенте, тем проще управлять инфраструктурой в масштабе. Тонкий клиент сегодня остаётся нормальной инженерной архитектурой для большинства рабочих сред. Веб-клиент - следующая итерация, которая уже доступна.

Вопрос только в том, когда ваша конфигурация будет к ней готова.

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

Могут ли толстый и тонкий клиент работать одновременно с одной базой?
Да. Режим запуска задаётся для каждого пользователя и сеанса отдельно, база от этого не меняется. Типовая схема как раз такая: бухгалтерия сидит в тонком, программист - в толстом.

Что даёт меньше трафика: RDP или тонкий клиент напрямую?
Однозначного ответа нет, и мерить надо на своей конфигурации. RDP передаёт изменения картинки: много прокрутки и перерисовки форм - трафик растёт, пользователь читает один документ - почти ничего не идёт. Тонкий клиент передаёт данные и команды, и его расход зависит от того, сколько записей тянут формы. На практике решающий фактор другой: где должны остаться данные. При прямом подключении тонкого клиента они попадают на устройство пользователя, при RDP остаются в периметре.

Конфигуратор - это толстый клиент?
Конфигуратор запускается тем же исполняемым файлом 1cv8.exe, что и толстый клиент, и в тонком его нет. Поэтому машине разработчика толстый клиент нужен всегда.

Нужен ли терминальный сервер, если у всех тонкий клиент?
Не обязательно. Тонкий клиент умеет подключаться к серверу 1С напрямую, в том числе через веб-сервер. Терминал берут ради других вещей: единой точки обновления, контроля периметра, работы со слабых машин и с медленных каналов, где отдельные серверные вызовы идут дольше, чем картинка RDP.

Как перевести пользователей с толстого клиента на тонкий?
Проверить, что конфигурация на управляемых формах, поставить тонкий клиент на терминальный хост, поменять ярлыки и режим запуска в списке баз, а старые ярлыки на 1cv8.exe убрать - иначе часть людей продолжит запускать толстый по привычке. Отдельно проверьте внешние обработки: часть из них может быть написана под обычные формы.

Тонкий клиент работает с файловой базой?
Работает - для этого в дистрибутиве платформы есть отдельный компонент «тонкий клиент, файловый вариант». Но в файловом режиме серверная часть поднимается на стороне клиента, поэтому в терминальной ферме нагрузка с хоста никуда не уходит. Для RDS это аргумент за переход на клиент-серверную схему.

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