Администрирование · 12 мин
FastInfoset в 1С: что это такое и как с ним работать
FastInfoset в 1С — бинарный формат обмена данными веб-сервисов. Разбираем, что это, когда ускоряет обмен, как включить или отключить и какие ошибки бывают.
При публикации веб-сервисов 1С или подключении к ним в настройках можно встретить упоминание FastInfoset — и у администраторов, и у разработчиков возникает вопрос, что это за параметр и нужно ли его трогать. FastInfoset (сокращённо FI) — это стандартизированный бинарный формат представления XML-документов, описанный в спецификациях ITU-T X.891 и ISO/IEC 24824-1. Его задача — передавать те же самые XML-данные, но в компактном бинарном виде, без текстовой сериализации.
В контексте 1С FastInfoset применяется при работе SOAP-веб-сервисов: платформа умеет отдавать и принимать ответы в бинарном формате вместо обычного текстового XML. За счёт этого уменьшается объём трафика и сокращается время на разбор сообщений, что заметно при больших пакетах данных — например, при выгрузке каталогов товаров, прайсов или пакетной синхронизации между системами.
Важно понимать: FastInfoset не меняет логику обмена и структуру данных. Это только способ «упаковки» XML. Если обе стороны обмена поддерживают формат, всё работает прозрачно; если одна из сторон его не понимает, возникают ошибки разбора ответа, и именно в этот момент администратор впервые сталкивается с термином.
Как устроен FastInfoset и чем он отличается от обычного XML
Обычный SOAP-ответ — это текстовый XML: теги, атрибуты и значения передаются символами, часто с большим количеством повторяющихся имён элементов. FastInfoset кодирует те же данные в бинарном виде: повторяющиеся строки заменяются индексами из словаря, структура документа описывается компактными маркерами, а числовые значения не тратят место на текстовое представление.
Для прикладного разработчика разница проявляется в HTTP-заголовках. Ответ в формате FastInfoset передаётся с типом содержимого application/fastinfoset вместо text/xml или application/soap+xml. Клиент, запрашивая данные, сообщает через заголовок Accept, что умеет принимать бинарный формат, и сервер отвечает в нём.
Ключевое свойство формата — эквивалентность: любой XML-документ можно представить в FastInfoset и обратно без потери информации. Поэтому включение или отключение формата не влияет на состав передаваемых данных, только на объём и скорость их обработки.
Где встречается FastInfoset в экосистеме 1С
Чаще всего с параметром сталкиваются в трёх сценариях. Первый — публикация собственных веб-сервисов 1С на веб-сервере (Apache или IIS): при публикации формируются настройки, влияющие на форматы обмена. Второй — вызов внешних SOAP-сервисов из кода 1С через объекты WS-ссылки и WS-прокси, где платформа может согласовывать формат ответа. Третий — диагностика ошибок обмена, когда в тексте исключения или в логах встречается упоминание fastinfoset.
Также FastInfoset активно используется в стеке Java (например, в реализациях JAX-WS), поэтому при интеграции 1С с Java-сервисами вопрос совместимости форматов возникает особенно часто: Java-сторона может по умолчанию отдавать бинарный ответ, который клиентская часть обмена не готова разобрать, или наоборот.
Когда FastInfoset даёт реальный выигрыш
Эффект от бинарного формата зависит от характера обмена. Заметный выигрыш появляется при передаче крупных сообщений: выгрузки справочников на десятки тысяч позиций, пакетной передаче документов, обмене историческими данными. Чем больше в XML повторяющихся имён элементов и длинных текстовых значений, тем сильнее сжатие за счёт словарного кодирования.
Второй фактор — частота вызовов. При интенсивной интеграции, где сервис вызывается сотни раз в минуту, экономия на разборе каждого сообщения суммируется в ощутимое снижение нагрузки на процессор обеих сторон. Это важно для серверов 1С, где разбор XML выполняется в рабочих процессах кластера.
Если же обмен редкий, а сообщения небольшие (например, проверка статуса заказа раз в час), выигрыш от FastInfoset будет минимальным, и усложнять настройку ради него нет смысла. В таких случаях проще оставить текстовый XML — его легче читать в логах и отлаживать.
Сравнение вариантов
Универсальная совместимость, удобная отладка и чтение логов. Подходит для редких вызовов и небольших сообщений. Минус — больший объём трафика и затраты на разбор.
Компактный бинарный формат, меньше трафика и быстрее разбор. Подходит для частых вызовов и крупных пакетов. Требует поддержки формата обеими сторонами обмена.
Альтернатива SOAP в целом: легче по объёму, проще отладка, широкая поддержка. Требует переработки сервиса, если он уже построен на SOAP.
Как включить или отключить FastInfoset
На стороне сервера 1С формат определяется настройками публикации веб-сервиса и возможностями платформы: сервер 1С умеет отвечать в FastInfoset, если клиент запросил этот формат через заголовок Accept. Отдельного глобального «выключателя» в конфигураторе, как правило, нет — поведение управляется на уровне согласования контента между клиентом и сервером.
На клиентской стороне (когда 1С вызывает внешний сервис) поведение зависит от того, как формируется запрос. Если обмен идёт через стандартные WS-прокси платформы, согласование формата выполняется автоматически. Если запросы формируются вручную через HTTPСоединение, разработчик сам управляет заголовками Accept и Content-Type и может либо запросить бинарный формат, либо явно ограничиться текстовым XML.
Если внешняя система отдаёт FastInfoset, а ваша сторона его не разбирает, практичный путь — попросить интеграционную команду другой стороны отключить бинарный формат на их сервере либо явно запрашивать текстовый ответ, указывая в Accept только text/xml. Это самый быстрый способ восстановить обмен без переработки кода.
- 1Сохраните текст ошибки и, если возможно, сырой HTTP-ответ сервиса (заголовки и тело).
- 2Проверьте заголовок Content-Type ответа: значение application/fastinfoset указывает на бинарный формат.
- 3Определите, какая сторона инициирует бинарный формат: клиент через Accept или сервер по умолчанию.
- 4Настройте запрос текстового XML (Accept: text/xml) или попросите вторую сторону отключить FastInfoset.
- 5Повторите вызов и убедитесь, что ответ приходит в читаемом XML и обмен завершается без ошибок.
Типичные ошибки и их диагностика
Самый частый симптом — ошибка разбора ответа веб-сервиса: клиент получает бинарные данные и не может интерпретировать их как XML. В логах это выглядит как исключение при чтении ответа, «неожиданный символ» в начале документа или бессмысленный набор байтов вместо привычных тегов при просмотре трафика.
Вторая типичная ситуация — промежуточные прокси или шлюзы, которые некорректно обрабатывают бинарный контент: меняют заголовки, пытаются перекодировать тело как текст или обрезают данные. В результате даже корректный FastInfoset-ответ доходит до клиента повреждённым. Диагностируется это сравнением ответа напрямую от сервера и через прокси.
Третья группа проблем — несогласованность версий. Если одна сторона обновила ПО и у неё изменилось поведение по умолчанию (например, сервис стал отдавать FastInfoset без явного запроса), обмен ломается «сам по себе» после обновления. В таких случаях полезно фиксировать, какие версии платформы и внешних систем используются, чтобы быстро локализовать источник изменения.
Как проверить результат
text/xml или application/soap+xml — читаемый текстовый XML
application/fastinfoset при клиенте, который не умеет его разбирать
Начинается с XML-объявления или открывающего тега, читается как текст
Нечитаемый бинарный поток, ошибка разбора на первом байте
Метод возвращает данные, исключений нет
Исключение при чтении или десериализации ответа
Ограничения и когда формат лучше не использовать
Главное ограничение FastInfoset — требование поддержки с обеих сторон. Если в цепочке обмена есть система, которая не понимает бинарный формат (старый прокси, самописный парсер, внешний сервис без поддержки FI), включение формата приведёт к сбоям. Перед использованием стоит подтвердить совместимость всех участников обмена.
Второй момент — отладка. Текстовый XML можно прочитать глазами в любом логе, а бинарный ответ требует специальных инструментов декодирования. Для интеграций на этапе разработки и тестирования удобнее работать с текстовым форматом, а FastInfoset включать уже на продуктивном контуре после стабилизации обмена.
Наконец, не стоит рассматривать FastInfoset как способ «ускорить медленный сервис». Если узкое место — тяжёлые запросы к базе или неоптимальный код обработчика, бинарный формат сэкономит лишь доли процента общего времени. Сначала оптимизируется логика, потом — транспорт.
Практические рекомендации по внедрению
Начинайте с измерения: зафиксируйте текущий объём трафика и время ответа сервиса до включения бинарного формата. Без исходных замеров невозможно понять, дал ли FastInfoset эффект, и обоснованно решить, стоит ли его оставлять.
Внедряйте изменение поэтапно: сначала тестовый контур, затем ограниченный набор вызовов на продуктиве, затем полный перевод. На каждом этапе проверяйте не только успешность вызовов, но и корректность данных на принимающей стороне — формат не должен ничего менять, и любое расхождение означает проблему в интеграционном коде, а не в FI.
Задокументируйте финальную конфигурацию: какая сторона запрашивает формат, какие заголовки используются, как отключить FastInfoset при необходимости. Это сильно упростит диагностику, когда обмен сломается после очередного обновления одной из систем.
Самый быстрый способ понять, что происходит с обменом, — посмотреть сырой HTTP-трафик между системами. В большинстве случаев заголовок Content-Type и первые байты ответа сразу показывают, виноват ли FastInfoset в ошибке.
Как выбрать действие
Частые вопросы о FastInfoset в 1С
FastInfoset влияет на данные в информационной базе 1С?
Нет. Это исключительно транспортный формат упаковки XML-сообщений веб-сервисов. Состав и структура передаваемых данных не меняются, а в самой базе никаких следов использования формата не остаётся.
Как понять, что сервис отвечает в FastInfoset, а не в обычном XML?
Посмотрите заголовок Content-Type в HTTP-ответе: значение application/fastinfoset означает бинарный формат. Дополнительный признак — тело ответа не читается как текст и начинается не с XML-объявления, а с бинарных маркеров.
Обмен сломался после обновления, в ошибке упоминается fastinfoset. Что делать в первую очередь?
Зафиксируйте сырой ответ сервиса и проверьте его Content-Type. Затем принудительно запросите текстовый формат, указав в заголовке Accept значение text/xml, или попросите вторую сторону отключить бинарный ответ. Это восстановит обмен, а дальше можно спокойно разбираться с совместимостью версий.
Даёт ли FastInfoset выигрыш при небольших сообщениях?
Практически нет. На маленьких сообщениях основные затраты — установка соединения и обработка запроса, а не разбор XML. Формат окупается на крупных пакетах и высокой частоте вызовов.
Можно ли заменить SOAP с FastInfoset на что-то более простое?
Да, распространённая альтернатива — HTTP-сервисы 1С с JSON: они легче по объёму, проще в отладке и широко поддерживаются. Но переход требует переработки сервиса и клиентского кода, поэтому для уже работающего SOAP-обмена проще настроить формат, чем переписывать интеграцию.
Что важно запомнить
FastInfoset — бинарная упаковка XML для веб-сервисов: меньше трафика и быстрее разбор, но только при поддержке обеими сторонами. Диагностируйте проблемы по заголовку Content-Type и сырому трафику, включайте формат поэтапно и сначала на тестовом контуре.