Центр удаленного доступа- Решение проблем  (раздел целиком)  (26.07.2026)(одним файлом)
Решение проблем

Для диагностики проблем в некоторых случаях помогает страница диагностики. Она доступна всем пользователям системы по url /.system/diag.html. Попросите удаленных пользователей воспользоваться возможностями этой страницы.


1. Проблема доставки запросов от клиента к серверу

Описание проблемы:

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

На сервере  - В отладочном мониторе появляются сообщения "Socket became inactive in first line" или "Bad first line".

Причины проблемы:

Проблема связана с особенностями провайдера клиента.  У провайдера установлено ограничение на длину любого http-запроса, либо POST-запроса в 1KB или немногим более.

Обычно проблема проявляется при использовании Microsoft (ISA) Internet Security and Acceleration Server на маршрутизаторе локальной сети.

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

Запуск файла производится из окружения интерпретатора командной строки Windows (cmd.exe)

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

Пути решения проблемы:

1. Обратиться к провайдеру с просьбой о снятии ограничения на размер запросов.

2. Использовать нестандартный TCP/IP порт, договорившись с провайдером о его открытии с серверной и клиентской стороны. Данный путь не гарантирует решения проблемы, но может помочь.

В данном случае "провайдером" может выступать как администратор локальной сети организации, так и ISP (интернет-провайдер), в зависимости от того, как организовано подключение конечного пользователя.

3. Использовать протокол https. В этом случае провайдер не сможет анализировать содержимое обмена и, следовательно, не сможет применять ограничения. Для использования протокола https необходимо иметь сертификат, а также внести изменения в настройки web-сервера.

Первые два пути могут способствовать быстрому решению проблемы. При этом стратегически правильным является путь 3 - использование протокола https.

Взаимодействие по протоколу https может быть организовано с использованием сертификатов двух видов:

1) Сертификат, выдаваемый уполномоченными организациями ("настоящий" сертификат).

Инструкция по получению "настоящего" сертификата включена в данное руководство, а также доступна по адресу: http://app.techmill.ru/paruspub/current/documentation/ED01679A80A74E999952269A89D95D36.html

 2) Самостоятельно сгенерированный сертификат.

Инструкция по генерации такого сертификата приведена Здесь. При использовании самостоятельно сгенерированного сертификата браузер пользователя будет выдавать предупреждение о сомнении в его достоверности. О том как избежать отображения такого предупреждения также написано Здесь. Действия по установке настроек web-сервера для работы по протоколу https описаны Здесь.


1.1. Сценарий проверки провайдера (пример)
Содержимое примера файла сценария проверки провайдера Testme.bat 
01@echo off
02IF "%1"=="" GOTO NOHOST
03
04echo Checking connection...
05AppServerFetch download %TEMP%\1.bin from http://%1/ >nul
06IF NOT %ERRORLEVEL%==0 GOTO ERROR
07echo passed.
08
09echo Checking DataMill Application Server....
10AppServerFetch download %TEMP%\1.bin from http://%1/.system/session.xml >nul
11IF NOT %ERRORLEVEL%==0 GOTO ERROR
12echo passed.
13
14echo Checking long GET....
15AppServerFetch download %TEMP%\1.bin from http://%1/.system/session.xml?data=0123456789^
160123456789012345678901234567890123456789012345678901234567890123456789^
170123456789012345678901234567890123456789012345678901234567890123456789^
180123456789012345678901234567890123456789012345678901234567890123456789^
190123456789012345678901234567890123456789012345678901234567890123456789^
200123456789012345678901234567890123456789012345678901234567890123456789^
210123456789012345678901234567890123456789012345678901234567890123456789^
220123456789012345678901234567890123456789012345678901234567890123456789^
230123456789012345678901234567890123456789012345678901234567890123456789^
240123456789012345678901234567890123456789012345678901234567890123456789^
250123456789012345678901234567890123456789012345678901234567890123456789^
260123456789012345678901234567890123456789012345678901234567890123456789^
270123456789012345678901234567890123456789012345678901234567890123456789^
280123456789012345678901234567890123456789012345678901234567890123456789^
290123456789012345678901234567890123456789012345678901234567890123456789^
300123456789012345678901234567890123456789012345678901234567890123456789^
310123456789012345678901234567890123456789012345678901234567890123456789^
320123456789012345678901234567890123456789012345678901234567890123456789^
330123456789012345678901234567890123456789012345678901234567890123456789^
340123456789012345678901234567890123456789012345678901234567890123456789^
350123456789012345678901234567890123456789012345678901234567890123456789^
3601234567890 > nul
37IF NOT %ERRORLEVEL%==0 GOTO ERROR
38echo passed.
39
40echo Checking POST....
41echo 01234567890 > %TEMP%\2.bin
42AppServerFetch download %TEMP%\1.bin from http://%1/.system/session.xml sending %TEMP%\2.bin >nul
43IF NOT %ERRORLEVEL%==0 GOTO ERROR
44echo passed.
45
46
47echo Checking long POST....
48for /L %%i in (1,1,100) DO echo 01234567890 >> %TEMP%\2.bin
49AppServerFetch download %TEMP%\1.bin from http://%1/.system/session.xml sending %TEMP%\2.bin >nul
50IF NOT %ERRORLEVEL%==0 GOTO ERROR
51echo passed.
52
53exit /B 0
54:ERROR
55echo Failed.
56exit /B 1
57:NOHOST
58echo Host not given.
59exit /B 2

2. Медленная работа удаленного клиента через приложение Win32, в случае работы через прокси сервер

В случае работы сервиса за серверным прокси сервером и наблюдением медленной работы удаленного клиента, например есть задержки с получением ответа, в то время как на хосте сервиса видно, что данные отправились быстро, рекомендуется проверить нижеуказанные настройки сервиса:

  • Сжимать трафик - выключено, но только в том случае, если на прокси сервере можно настроить сжатие трафика независимо от настройки настоящего сервиса
  • Повторно использовать сессии - включено, но только в том случае, если прокси сервер может "эффективно" переиспользовать соединения между ним и сервисом, а не открывать для каждого внешнего клиента отдельное соединение между собой и сервисом
  • Отключать алгоритм Nagle для соединений - включено, но только в том случае, если имеется достаточный запас канала между сервисом и прокси сервером

Также стоит обратить внимание на настройки прокси сервера, касаемые буферизации ответов. Значение этих буферов должно быть как можно меньше или выключено совсем.

Именование настроек для некоторых прокси серверов:

  • в IIS - "Response buffer threshold" (Пороговое значение буфера ответов): Application Request Routing Cache > Proxy/Server Proxy Settings
  • в NGINX - proxy_buffering, proxy_buffers и proxy_buffer_size

3. Неустойчивый внешний канал

Вопрос:

- Не отображаются активные сессии в "Настройке сервиса" (используется протокол HTTP)

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

Ответ:

Причиной описанных проблем является неустойчивый внешний канал связи.

Для решения необходимо в параметрах сетевых настроек сервиса :

1. Включить сжатие трафика;

2. Снять галку "повторно использовать сессии"

3. Если предыдущие шаги не помогли, то увеличить значение параметра "Количество потоков прослушивателя" до 32. Если клиентов ожидается больше 300 (на неусточивом канале), то задать значение в 48 или даже 64 потока. Ставить большее значение не имеет смысла,  в этом случае необходимо расширять внешний канал.


4. Поддержка долгоживущих соединений между сервером приложений и сервером СУБД (Oracle или Postgres)

При длительном неиспользовании TCP соединения, роутеры между этими серверами могут начать оптимизировать использование своих ресурсов. Для этого они будут закрывать соединения, которые долго простаивали, обычно порогом является 2 ч. При этом ни сервер приложений, ни сервер СУБД не уведомляются о том, что их соединение оборвалось, и по-прежнему считают его активным.

Результат подобных обрывов соединений является нежелательным ни для сервера приложений, ни для сервера СУБД и будут приводить к многочисленным проблемам, например:

  • при необходимости воспользоваться соединением, вызывающая сторона не сразу узнает, что соединение уже неактивно, и будет выжидать таймаут, особенно длительный в ОС Linux (около 15 мин. - см. параметр tcp_retries2) 
  • когда сервер приложений поймет, что соединение неактивно, то будет установлено новое соединение, но все данные сброшенного соединения будут потеряны:
    • все активные транзакции текущего соединения, начавшиеся, но еще не завершенные, будут отменены. А это значит, что все выполненные, но еще не подтвержденные действия будут отменены. А также, при последующих запросах клиента в рамках текущей транзакции, он получит ошибку, и будет вынужден выполнять запрос заново.
    • недофетченные селективные запросы сброшены, как на стороне СУБД, так и на стороне сервера приложений. А это значит, что при запросе клиента следующей порции данных из длительных селективных запросов, которые клиент еще не дофетчил до конца, он получит ошибку, и будет вынужден выполнять запрос заново.

Для того чтобы избежать подобных нежелательных обрывов соединений, предлагается ряд административных мер по настройке сервера СУБД для поддержания соединений в активном состоянии.

Проверка и поддержание соединения активным осуществляется следующим образом.
На серверной стороне СУБД, по истечению какого-то времени, клиенту посылаются специальные пакеты определенное количество раз. Как только клиент ответит на эти пакеты проверки соединения, то сервер признает это соединение живым и останавливает этот механизм на определенное время, через которое проверка осуществляется снова. Если клиент не отвечает на проверочные пакеты, то сервер отправляет эти пакеты в течение определенного времени, а затем, если ответ так и не поступил, признает соединение разорванным и закрывает его со своей серверной стороны.

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

В Oracle, начиная с 12-й версии для этой механики используется настройки TCP соединений, которые хорошо описаны в следующей документации Oracle - Dead connection detection:

  • TCP_KEEPIDDLE - время простоя соединения после которого начинаются попытки проверки соединения (отправка спец. пакетов). Значение берется из параметра SQLNET.EXPIRE_TIME, умолчательное значение 0, измеряется в минутах.
  • TCP_KEEPCNT - количество попыток проверки соединения (отправка спец. пакетов). Зафиксированное значение (нельзя задать вручную) в Oracle - 10 раз.
  • TCP_KEEPINTVL - интервал времени между попытками проверки соединения (отправка спец. пакетов). Зафиксированное значение (нельзя задать вручную) в Oracle - 6 сек.

Таким образом, в Oracle всем этим можно управлять только через настройку SQLNET.EXPIRE_TIME. Умолчательное значение 0, т.е. выключено. Для случаев когда необходимо включить механику поддержки активности соединений, рекомендуемое значение 10 минут.

В Postgres, (в 9.6 эти настройки точно уже присутствуют) есть аналогичные настройки в файле postgres.conf:

  • tcp_keepalives_idle - измеряется в секундах. Умолчательное значение 0, в таком случае используется системное значение, которое в Linux и в Windows равняется 2-м часам.
  • tcp_keepalives_count - умолчательное значение 0, в таком берется системное значение, которое в Linux равняется 9 раз
  • tcp_keepalives_interval - измеряется в секундах. Умолчательное значение 0, в таком берется системное значение, которое в Linux равняется 75 сек.

Таким образом, в Postgres всем этим можно управлять через вышеуказанные настройки в файле конфигурации postgres.conf. Для случаев, когда необходимо включить механику поддержки активности соединений, рекомендуется начать со значений, применяемых Oracle, т.к. они более продуманные и приближенные к жизни, а именно:

  • tcp_keepalives_idle - 600 сек, т.е. как и в SQLNET.EXPIRE_TIME, рекомендуется 10 мин
  • tcp_keepalives_count - 10 раз
  • tcp_keepalives_interval - 6 сек

Важно!
 Применять вышеуказанные настройки необходимо на серверной стороне СУБД, для того чтобы сразу охватить все клиентские соединения.