Рассмотрим распространенную проблему, с которой часто сталкиваются системные администраторы и специалисты 1С при организации работы удаленных филиалов. Сценарий выглядит следующим образом: в центральном офисе развернут производительный сервер 1С в клиент-серверном варианте (под управлением СУБД MS SQL Server). Все филиалы объединены в общую корпоративную сеть через VPN-каналы и находятся в одном домене Active Directory.
На одном из филиалов (назовем его Филиал А) пользователи жалуются на то то, что работать в 1С через локально установленный тонкий клиент физически невозможно. Каждое действие — будь то открытие формы списка заказов, проведение документа или добавление строки в табличную часть — занимает от одной до нескольких минут. При этом на другом филиале (Филиал Б), который может находиться даже дальше территориально, тот же самый тонкий клиент работает быстро и без нареканий. Более того, если пользователи проблемного Филиала А заходят в 1С через терминальный сервер (RDP или RemoteApps), то скорость работы интерфейса становится отличной.
Выясним причину такого странного поведения системы, разберем методику диагностики сетевого трафика и рассмотрим технические способы решения этой проблемы.
Проанализируем первичные данные. На первый взгляд поведение системы кажется парадоксальным:
О чем нам говорит расхождение реального времени ожидания и показателей замера производительности 1С? Замер производительности фиксирует исключительно чистое время выполнения серверных вызовов и работу кода на клиенте. Он не учитывает время, затраченное операционной системой на передачу пакетов по сети между клиентом и сервером. Это явный маркер того, что проблема кроется на транспортном (сетевом) уровне передачи данных. Для оценки работы сетевого канала и выявления узких мест в инфраструктуре 1С можно использовать методику и утилиту для тестирования сетевого интерфейса.
Разберем разницу в структуре сетевого трафика этих решений:
Протокол удаленного рабочего стола (RDP) устроен так, что он передает от сервера к клиенту преимущественно изменения графического интерфейса (картинку экрана), а обратно — нажатия клавиш и движения мыши. Этот трафик дробится на огромное количество очень мелких сетевых пакетов. Они легко преодолевают любые промежуточные узлы, так как их размер намного меньше стандартных ограничений сетевых интерфейсов.
Тонкий клиент 1С работает по совершенно иному принципу. При открытии форм, динамических списков или передаче больших табличных частей документов тонкий клиент обменивается с сервером 1С сериализованными структурами данных (в формате XML или JSON). При этом операционная система пытается отправить эти данные как можно быстрее, формируя пакеты максимально возможного размера. По умолчанию для сетей Ethernet стандартный размер пакета MTU (Maximum Transmission Unit) составляет 1500 байт.
Если мы выполним стандартную проверку связи с сервера филиала до сервера 1С обычной командой ping, мы можем увидеть отличный результат: задержка (RTT) составляет всего 12–15 мс, потерь пакетов нет. Именно это часто сбивает с толку администраторов, которые заявляют: "С сетью все в порядке, ищите проблему в самой 1С".
Однако обычный пинг отправляет очень маленькие пакеты (по умолчанию всего 32 байта). Чтобы выявить реальное положение дел, нам необходимо проверить прохождение пакетов максимального размера. Проведем тест, отправив большой пакет размером 10 000 байт, который гарантированно должен быть фрагментирован сетевым оборудованием.
Запустим командную строку на проблемной рабочей станции филиала и выполним следующую команду:
ping -l 10000 [IP_адрес_сервера_1С]
Здесь параметр -l (длина буфера) задает размер отправляемого пакета. Посмотрим на результаты этого теста:
Это подтверждает, что в сети между филиалом А и центральным офисом полностью заблокировано прохождение или фрагментация пакетов большого размера. Мы столкнулись с классической сетевой проблемой, которая в профессиональной среде называется "Черной дырой MTU" (Path MTU Discovery Black Hole).
Разберем детально физику этого процесса:
MTU для локальной сети).По правилам работы стека протоколов TCP/IP у роутера в этой ситуации есть два пути решения:
Путь фрагментации: Роутер разбивает большой пакет на несколько мелких фрагментов, отправляет их по отдельности, а принимающая сторона собирает их обратно. Однако в современных операционных системах для TCP-трафика по умолчанию устанавливается флаг DF (Don't Fragment — не фрагментировать).
Путь PMTUD (Path MTU Discovery): Если на пакете стоит флаг запрета фрагментации (DF=1), роутер обязан уничтожить этот пакет и отправить обратно отправителю служебное сообщение протокола ICMP (тип 3, код 4: "Необходима фрагментация, но установлен флаг DF"). Компьютер пользователя, получив это уведомление, автоматически уменьшает размер отправляемых пакетов до безопасного значения и повторяет отправку.
Суть проблемы "Черной дыры": Очень часто системные администраторы из соображений "безопасности" полностью блокируют прохождение любого ICMP-трафика на сетевых экранах. Когда служебные сообщения ICMP заблокированы, компьютер с тонким клиентом 1С отправляет большой пакет, VPN-роутер его молча сбрасывает (так как он превышает размер канала), а отправить уведомление обратно не может. Компьютер клиента ничего об этом не знает, ожидает подтверждения получения пакета, отправляет его повторно по таймауту и снова не получает ответа. Пользователь в этот момент видит "зависший" интерфейс 1С.
После того как проблема с прохождением больших пакетов локализована, системный администратор должен применить одно из следующих технических решений на сетевом оборудовании:
Это наиболее надежный, современный и часто используемый способ решения проблем с фрагментацией в VPN. Суть метода заключается в том, что маршрутизатор на границе сети перехватывает пакеты на этапе установления TCP-соединения (пакеты с флагом SYN) и принудительно уменьшает в них параметр MSS (Maximum Segment Size — максимальный размер сегмента данных).
Например, если стандартный MSS равен 1460 байт (при MTU 1500), роутер принудительно перезаписывает это значение в проходящем пакете на 1360 байт. В результате клиент и сервер изначально договариваются общаться пакетами меньшего размера. Эти пакеты гарантированно помещаются в VPN-туннель вместе со всеми служебными заголовками шифрования и никогда не требуют фрагментации.
Для маршрутизаторов MikroTik правило в брандмауэре выглядит следующим образом:
/ip firewall mangle
add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp out-interface=all-vti
Администратор может вручную понизить размер MTU на виртуальных интерфейсах VPN-соединения на обоих концах туннеля (до значений 1400, 1380 или даже 1360 байт в зависимости от типа шифрования). Это заставит сетевой стек роутера корректно обрабатывать пакеты, подстраиваясь под ограничения туннеля.
Необходимо проверить настройки межсетевых экранов (Firewall) на роутерах и разрешить прохождение пакетов ICMP Type 3, Code 4 (Destination Unreachable, Fragmentation Needed and DF set). Это позволит механизму Path MTU Discovery на конечных рабочих станциях работать штатно и автоматически определять безопасный размер сетевого пакета.
Даже при идеальной настройке параметров MTU и MSS в VPN-канале, прямое подключение тонкого клиента 1С к кластеру серверов по протоколу TCP чувствительно к задержкам сети (ping). Если пинг до удаленного офиса превышает 30-50 мс, интерфейс 1С все равно может ощущаться "тяжелым" из-за большого количества последовательных сетевых запросов при открытии форм.
Для обеспечения максимальной скорости и стабильности работы удаленных подразделений настоятельно рекомендуется использовать публикацию информационной базы на веб-сервере (под управлением IIS или Apache):
MTU на промежуточных узлах провайдеров.Таким образом, если вы столкнулись с необъяснимым замедлением работы тонкого клиента на удаленной точке — в первую очередь проведите диагностику прохождения крупных пакетов с помощью команды ping -l 10000. Это сэкономит вам массу времени и укажет верное направление решения проблемы силами сетевых администраторов.