Компания Inscale подключила 15 пользователей через спутниковый канал 1 Мбит/с с потерями пакетов. На один сеанс приходилось около 67 кбит/с: 1000 ÷ 15 ≈ 67. Для работы потребовалась настройка 27 параметров протокола доставки.
Это частный результат Inscale, а не норматив для любого филиала. Он показывает другое: если формы 1С открываются рывками, замена сервера может не помочь. Сначала нужно выбрать транспорт под характер сбоя.
Для обычного нестабильного канала начните с RDP через TCP и UDP. На перегруженном VPN, мобильной точке или спутниковой линии первым проверьте чистый TCP. Если связь пропадает на десятки секунд, сравнивайте уже не транспорты, а способность платформы сохранить сеанс.
TCP и UDP решают разные проблемы канала
TCP нумерует пакеты, подтверждает их получение и повторно передаёт потерянные. Пользователь получает данные в нужном порядке, но при потерях вынужден ждать повторной передачи. Такое поведение описывает руководство TSplus по настройке RDP.
UDP не отслеживает состояние соединения и не гарантирует доставку каждого пакета. Это не означает, что интерфейс 1С при любых потерях станет быстрее. Подтверждённых замеров с таким выводом в материалах нет.
В RDP 8.0, который появился в Windows 8 и Windows Server 2012, Microsoft добавила двойную транспортную модель. Сеанс начинает работу по TCP, согласует возможности и безопасность, затем пытается открыть параллельный UDP-канал. Если это не удалось, RDP продолжает работать через TCP.
Поэтому выбор «TCP или UDP» для RDP поставлен неточно. Практический выбор выглядит так: оставить двойной транспорт либо запретить UDP и проверить TCP отдельно.
| Что видит пользователь | Что проверить в сети | Какой режим испытать первым | Признак подходящего режима |
|---|---|---|---|
| Формы обновляются рывками, но сеанс не разрывается | Потери пакетов и колебания пропускной способности | TCP+UDP | Сеанс остаётся рабочим при изменении качества канала |
| Экран замирает на перегруженном VPN | Очереди и потери внутри туннеля | TCP | Формы продолжают открываться без повторного входа |
| Мобильная или спутниковая линия меняет качество в течение дня | Потери, доступность UDP и поведение туннеля | TCP, затем TCP+UDP | Выбранный режим выдерживает худший рабочий период |
| После короткого исчезновения связи сотрудник входит заново | Факт разрыва и сохранение состояния сеанса | Платформа с механизмом удержания сеанса | Пользователь возвращается в прежнюю сессию |
| 1С медленна и в локальном тесте рядом с сервером | Загрузку процессора, памяти, дисков и СУБД | Транспорт пока не менять | Локальный и удалённый сеансы дают разные симптомы |
Таблица отделяет транспортную проблему от серверной: TCP и UDP не исправят медленную базу, если локальный сеанс ведёт себя так же.
Для нестабильного канала базовый вариант — TCP+UDP
Двойной транспорт подходит для линии, где UDP доступен, но его работа не гарантирована. RDP попробует открыть параллельный канал, а при неудаче останется на TCP. Администратору не приходится поддерживать две отдельные схемы доступа.
Это хороший первый кандидат для филиала с меняющимся качеством связи. Современные протоколы доставки меняют качество изображения, частоту кадров и сжатие по состоянию канала. Inscale описывает такую адаптацию в своей системе удалённых рабочих мест.
Адаптация не создаёт пропускную способность из ничего. Она уменьшает объём передаваемых данных ценой качества картинки или частоты её обновления. Для форм, списков и текста 1С этот компромисс обычно уместнее, чем для видео или трёхмерной графики.
Настройка графического профиля требует отдельной проверки. Принудительный кодек может увеличить объём трафика на интерфейсе с большим количеством текста. Порядок испытания описан в материале про графический режим RDP для окон и списков 1С.
На перегруженном VPN сначала проверьте TCP
TSplus отмечает более стабильное поведение TCP на перегруженных VPN, мобильных точках и спутниковых каналах. Это не обещание одинакового результата на каждой сети. Это стартовая настройка пилота.
VPN добавляет собственную обработку и может ограничивать прохождение UDP. Даже если UDP формально разрешён, его поведение внутри конкретного туннеля нужно проверять под рабочей нагрузкой.
Не делайте вывод по одному успешному входу. Откройте типовую базу, найдите тяжёлую форму, проведите привычный документ и поработайте со списком. Затем повторите тот же маршрут через TCP+UDP.
Сравнивайте не ощущение «стало бодрее», а наблюдаемые признаки:
- сколько раз сотрудник заново входит в сеанс;
- зависает ли обновление формы при ухудшении связи;
- восстанавливается ли управление после потери пакетов;
- меняется ли симптом при локальном запуске рядом с сервером;
- сохраняется ли открытая сессия после краткого разрыва.
Если чистый TCP устраняет повторные входы, оставьте его для следующего этапа пилота. Если оба режима ведут себя одинаково, ищите ограничение не в выборе транспорта.
Задержку сети легко принять за нехватку серверных ресурсов. Разделить эти причины помогает проверка пути между филиалом и ЦОД: сначала измеряют сетевое ожидание, потом оценивают сервер.
Ширина канала влияет на качество, но не выбирает транспорт
Inscale приводит для 1С, почты и офисных программ минимальный диапазон 128–256 кбит/с на пользователя. Комфортный диапазон — от 512 кбит/с до 1 Мбит/с. Без тонкой настройки стандартный ориентир возрастает до 1–2 Мбит/с.
Эти значения описывают пропускную способность, а не выбор между TCP и UDP. Канал может быть широким, но терять пакеты. Узкий канал может работать предсказуемо, если его параметры стабильны.
Посчитаем филиал на десять одновременных пользователей. Берём верхнюю границу минимального диапазона — 256 кбит/с — и предполагаем работу с 1С, почтой и офисными программами без видео.
Нижняя расчётная точка:
10 × 256 кбит/с = 2560 кбит/с, то есть 2,56 Мбит/с.
Для комфортной точки берём нижнюю границу соответствующего диапазона — 512 кбит/с:
10 × 512 кбит/с = 5120 кбит/с, то есть 5,12 Мбит/с.
При другом количестве одновременных сеансов умножьте выбранный ориентир на их число. Если одновременно работают 20 человек, обе расчётные точки удвоятся. Если половина сотрудников подключается по очереди, считать всех штатных пользователей не нужно.
Видеосвязь в этот расчёт не входит. По данным Inscale, видеоконференция 720p требует ещё 1–2 Мбит/с. Если Teams или другое видео идёт по тому же каналу, его трафик нужно считать отдельно.
История с 15 пользователями на 1 Мбит/с не отменяет эти ориентиры. Inscale добилась результата после настройки 27 параметров доставки на конкретной спутниковой линии. Переносить полученные 67 кбит/с на другой филиал без пилота нельзя.
При обрыве на десятки секунд транспорт уже не спасает
Потеря пакетов и разрыв соединения выглядят похоже только первые секунды. В первом случае открытый сеанс продолжает жить. Во втором платформа должна удержать его состояние, пока сеть отсутствует.
В архитектурном сравнении протоколов удалённого доступа Артур Оглоз указывает, что Citrix CGP сохраняет состояние сеанса при потере сети до 180 секунд. Пользователь может вернуться к прежней работе после восстановления связи.
В том же сравнении у Microsoft RDP нет сопоставимого механизма сохранения сеанса. Автор также указывает, что RDP-UDP не переключает TCP и UDP во время уже открытой сессии.
Эти сведения взяты из сравнительного архитектурного разбора, а не из документации Microsoft или Citrix. Используйте их для отбора кандидатов в пилот, но не как замену проверке ваших версий и настроек.
| Сценарий связи | Требование к системе доступа | Что проверять | Подходящий первый кандидат |
|---|---|---|---|
| Канал теряет пакеты, но не исчезает | Адаптация графики и работа двух транспортов | Поведение TCP+UDP в худший период | RDP с TCP+UDP |
| VPN перегружен, UDP работает нестабильно | Предсказуемая доставка через туннель | Отдельный прогон на TCP | RDP через TCP |
| Спутниковая линия меняет качество | Адаптация картинки и сжатия | TCP, затем двойной транспорт | Режим, выдержавший пилот |
| Связь исчезает на десятки секунд | Удержание состояния открытого сеанса | Возврат в прежнюю сессию | Платформа с сохранением сеанса |
| Пользователям нужна изоляция рабочих столов | Отдельное окружение для каждого сотрудника | Ресурсы, лицензии и обслуживание | VDI после проверки требований |
| Все сотрудники работают в одинаковой 1С | Общая среда с меньшим числом рабочих машин | Нагрузка и границы изоляции | Терминальный сервер как базовый кандидат |
Главная граница проходит не между названиями продуктов. Сначала определите, теряет ли канал пакеты или исчезает целиком. Во втором случае функция сохранения сеанса весит больше настройки TCP и UDP.
Терминальный сервер и VDI не нужно смешивать с выбором транспорта
TCP, UDP и механизм сохранения сеанса отвечают за доставку удалённого рабочего места. Терминальный сервер и VDI определяют, где работает пользовательская среда и насколько она изолирована.
Если сотрудники запускают одну типовую 1С, отдельная виртуальная машина для каждого может добавить лишние лицензии и обслуживание. Если пользователям нужны разные приложения, права или версии, изоляция VDI приобретает смысл.
Перед выбором платформы сравните общую терминальную среду и отдельные VDI-машины. Транспорт проверяйте уже на той архитектуре, которую компания сможет обслуживать.
Не переносите всю инфраструктуру ради одной матрицы функций. Один рабочий сеанс покажет больше: на нём видны потери управления, повторные входы и реакция интерфейса на ухудшение линии.
Пилот должен воспроизводить рабочий день
Возьмите компьютер из проблемного филиала и типовую учётную запись. Тест из серверной рядом с ЦОД не воспроизведёт спутниковый маршрут, мобильную сеть или перегруженный VPN.
Сначала зафиксируйте исходный режим. Запишите, на каком действии появляется задержка, разрывается ли сеанс и требуется ли новый вход. Скриншот одной ошибки здесь менее полезен, чем точная последовательность действий.
Затем оставьте тот же компьютер, базу и пользовательский сценарий. Меняйте только транспорт:
- Проверьте чистый TCP.
- Включите TCP+UDP и повторите те же действия.
- Имитируйте обычное ухудшение канала, если это можно сделать без влияния на рабочую сеть.
- Проверьте возврат после реального краткого разрыва.
- Если платформа умеет сохранять сеанс, повторите испытание с этой функцией.
Такой порядок не даёт перепутать влияние транспорта, кодека и серверной нагрузки. Если одновременно заменить платформу, VPN и графический профиль, причина улучшения останется неизвестной.
К пилоту стоит привлечь сотрудника с типовой нагрузкой. Администратор, который только открывает конфигуратор или пустую базу, не воспроизводит проведение документов, длинные списки и печать.
Если поведение зависит от маршрута, версии клиента и политики VPN, одной таблицы сравнения мало. Для конкретного контура можно заказать оценку схемы удалённого доступа к вашей 1С после первичного пилота.
Удалённый доступ нельзя публиковать прямым RDP
VEK-IT рекомендует строить внешний доступ через VPN или RD Gateway. Прямо открытый RDP принимает сканирование портов и попытки подбора паролей.
Для RDP-подключений включите Network Level Authentication и TLS. VPN-сервер размещайте отдельно от хоста базы данных. Пользовательским компьютерам не нужен прямой сетевой доступ к самой базе.
Эти меры не ускоряют канал. Они закрывают другую задачу: не превращать тест транспорта в открытый вход к серверу.
После настройки проверьте путь снаружи. Пользователь должен попадать на терминальный узел или VDI-шлюз, а не подключаться к серверу СУБД.
Правило выбора для филиала с плохой связью
Если канал теряет пакеты, но не обрывается, начните с TCP+UDP. RDP установит TCP-соединение, попробует поднять UDP и останется на TCP, если второй канал недоступен.
Если сотрудники работают через перегруженный VPN, мобильную точку или спутниковую линию, первым испытайте TCP. Затем сравните его с двойным транспортом на том же сеансе и рабочем сценарии.
Если связь исчезает на десятки секунд, настройка транспорта задачу не закрывает. Выбирайте платформу по способности сохранить открытый сеанс и вернуть пользователя к прежней работе.
Для десяти одновременных пользователей заложите 2,56 Мбит/с как нижнюю расчётную точку. Комфортный расчёт начинается с 5,12 Мбит/с. Оба значения предполагают 1С и офисные программы без видео.
При меньшей полосе сначала уменьшите графическую нагрузку и проверьте адаптацию протокола. Сервер меняйте только после локального теста, который подтвердил нехватку его ресурсов.