Внимание! Пожалуйста, уберите от экранов всех программистов в финансовой области с опытом менее 15 лет — мы будем обсуждать настоящие чудеса инженерии.

Введение

Протокол FAST (Financial Information eXchange) — это международный стандарт, используемый для обмена данными в реальном времени на финансовых рынках. Этот протокол был разработан для повышения эффективности и скорости обмена информацией между различными участниками рынка, такими как брокеры, биржи, банки и другие финансовые учреждения. Протокол FAST является ключевым элементом в инфраструктуре высокочастотной торговли (HFT) и продолжает оставаться актуальным, несмотря на его "почтенный" возраст.

История и Развитие

Протокол FAST был разработан организацией FIX Protocol Limited (FPL) в начале 2000-х годов как улучшенная версия протокола FIX (Financial Information eXchange). Основная цель разработки FAST заключалась в снижении объема передаваемых данных и увеличении скорости их передачи, что стало критически важным с ростом объемов торгов и появлением высокочастотной торговли (HFT).

Протокол FIX и его логическое продолжение — FAST — хоть и древние, но на удивление до сих пор актуальны. Даже его преемник, протокол SBE (Simple Binary Encoding), был внедрен в такую популярную биржу, как Binance. Статьи на Habr и Habr подробно описывают текстовый формат протокола, и у этих статей есть продолжения. Проблем с текстовым форматом практически нет.

Принципы Работы

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

1. Кодирование на основе шаблонов: FAST использует предварительно определенные шаблоны для кодирования повторяющихся структур данных. Это позволяет значительно сократить объем данных, передаваемых по сети.

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

3. Инкрементальные обновления: Вместо передачи полного объема данных при каждом обновлении, FAST отправляет только изменения, что значительно уменьшает трафик.

Протокол FAST настолько редкий, что простых материалов практически не существует, кроме спецификаций. В принципе, их более чем достаточно. Редкость обусловлена тем, что протокол работает, как правило, на базе UDP в интранет-зоне (называемой колокацией на бирже), что делает требования к программисту очень серьезными.

Об UDP и Multicast

Когда дело доходит до протокола FAST, UDP делает свою магию, но также приносит немного хаоса в виде потерь пакетов. В финансовом мире это не просто допустимо, но и решаемо с помощью multicast подписок на снэпшоты и инкрементальные обновления. Давайте разберемся, как это работает и что делать, когда данные решают сыграть в прятки.

Multicast подписки

1. Снэпшоты (Snapshots):

   • Представьте себе снэпшоты как семейные фотоальбомы — полные и красивые снимки состояния ваших данных в определенный момент времени. Они нужны, чтобы установить основу или восстановить её, если что-то пошло не так. Если вы потеряли несколько пакетов данных, снэпшоты помогут вернуть вас в строй, как старые добрые снимки помогут вспомнить, как вы выглядели до того, как начали терять волосы.

2. Инкрементальные обновления (Incremental Updates):

   • Инкрементальные обновления — это как обновление статуса в соцсетях: "Привет, я только что изменил цену акции на пару копеек!" Они поддерживают ваши данные свежими и актуальными без необходимости пересылать всё подряд каждый раз. Это значительно снижает нагрузку на сеть и ускоряет процесс.

Устойчивость к Потере Пакетов

Теперь о наших верных рыцарях — потоках A и B. Эти два потока передают одни и те же данные, потому что в мире UDP всегда есть шанс, что один из них заблудится.

• Поток A и Поток B:

  • Эти два потока работают как параллельные тросы безопасности. Если один поток упадет, другой подхватит. Если вы потеряете пакет в потоке A, он, вероятно, будет спасен в потоке B.

Что Делать, Если Пакеты Потерялись в Оба Потока

Теперь представьте, что оба потока решили взять выходной одновременно. Что ж, здесь снэпшоты снова приходят на помощь.

1. Определение потери пакета:

   • Система замечает, что пакеты потерялись в обоих потоках, и начинает паниковать. Ладно, не паниковать, но точно замечает.

2. Запрос повторной передачи:

   • Если в вашем арсенале есть функция повторной передачи, система отправит запрос на повторную отправку потерянных пакетов. Это как сказать: "Эй, можно еще раз? Я пропустил это!"

3. Использование снэпшота:

   • Если пакеты не могут быть повторно отправлены (может, они навсегда ушли в цифровой мир), система возвращается к последнему снэпшоту и начинает применять все последующие инкрементальные обновления, чтобы вернуться в настоящее.

Технические Детали

Теперь немного технических деталей, чтобы углубиться в специфику FAST.

Формат Заголовка

• Заголовок сообщения в FAST содержит информацию о типе сообщения и его длине.

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

Шаблоны Сообщений:

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

• Шаблон может выглядеть как таблица с полями, где для каждого поля указаны тип данных и способ сжатия.

Кодирование Числовых Данных: В FAST протоколе (FAST - Fix Adapted for Streaming), который используется в финансовой индустрии для высокоскоростной передачи данных, числовые значения могут быть закодированы несколькими способами в зависимости от типа числа. В протоколе FAST применяется бинарная форма кодирования для обеспечения компактности и эффективности. Вот основные способы кодирования числовых значений:

• Целые числа (Integers):

  • Прямое кодирование (Raw Encoding): Число кодируется как байтовый массив в формате двоичного числа.

  • Зигзаг-кодирование (Zigzag Encoding): Используется для кодирования знаковых целых чисел. Неотрицательные числа умножаются на 2, а отрицательные числа умножаются на 2 и уменьшаются на 1. После этого результата применяется кодирование с переменной длиной (variable-length encoding).

  • Кодирование с переменной длиной (Variable-Length Encoding): Использует несколько байтов, чтобы закодировать целое число. Каждый байт, кроме последнего, имеет установленный старший бит (MSB) для указания, что число продолжается в следующем байте.

• Дробные числа (Decimals):

  • Дробные числа кодируются как пара (мантисса и экспонента). Мантисса кодируется как целое число с использованием описанных выше методов кодирования целых чисел, а экспонента кодируется аналогично, как знаковое целое число.

• Большие целые числа (Big Integers):

  • Используются для чисел, которые превышают диапазон стандартного целого числа. Они могут быть закодированы с использованием схемы кодирования с переменной длиной, где размер данных может изменяться в зависимости от величины числа.

Пример процесса декодирования целого числа, закодированного с использованием переменной длины:

Допустим, у нас есть закодированное целое число в следующем виде: 10010110 00000001.

1. Читаем первый байт: 10010110. MSB установлен, значит, продолжаем чтение.

2. Убираем MSB: 0010110 (22 в десятичном).

3. Читаем второй байт: 00000001. MSB не установлен, значит, это последний байт.

4. Конкатенируем и сдвигаем предыдущий результат: 22 << 7 + 1 = 2817.

Таким образом, закодированное значение 10010110 00000001 декодируется в 2817.

Применение

Протокол FAST широко используется в различных областях финансового сектора:

1. Биржевые платформы: Биржи используют FAST для передачи котировок в реальном времени, что позволяет трейдерам быстро реагировать на изменения рынка.

2. Брокерские фирмы: Брокеры используют FAST для получения актуальной информации о ценах и объемах торгов, что помогает в принятии решений и управлении рисками.

3. Банки и финансовые институты: Эти организации применяют FAST для обмена данными между различными системами и департаментами, что способствует улучшению внутренней координации и оперативности работы.

Если для FIX существует много дженерик библиотек, то протокол FAST настолько специфичен, что для него существует всего две основные библиотеки: OnixS и StockSharp. Первая — это общемировая компания, работающая с такими гигантами, как NYSE и NASDAQ. Вторая — наша отечественная разработка, работающая исключительно с Московской Биржей.

Требования к FAST обусловлены производительностью, поэтому почти всегда универсальные решения идут лесом. Кофе, монитор, постер со Страуструпом, удобное кресло и начало создания своего FAST коннектор - что может быть более лучшим началом рабочего дня? Реализация такого протокола, конечно же, требует языка C++ (и никаких шуток про Python здесь не будет). Если говорить о высокой производительности, то даже всплывает такое страшное слово, как FPGA. Для Московской Биржи таких решений честно не встречал, обычно писали на C++, но для этого и существуют комментарии, чтобы внести дополнительную информацию.

Открытые Реализации

Существует несколько открытых реализаций протокола FAST, таких как QuickFAST и OpenFAST.net (под C#, и снова никаких шуток про Python).

Преимущества и Недостатки

Преимущества:

1. Высокая скорость передачи данных: Благодаря сжатию и эффективному кодированию, протокол FAST обеспечивает быструю передачу больших объемов данных.

2. Снижение нагрузки на сеть: Инкрементальные обновления и сжатие данных уменьшают объем трафика, что снижает нагрузку на сеть и затраты на инфраструктуру.

3. Универсальность: FAST может быть адаптирован для различных типов данных и использоваться в различных финансовых приложениях.

Недостатки:

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

2. Зависимость от шаблонов: Необходимость использования предварительно определенных шаблонов может ограничивать гибкость системы и требовать частого обновления шаблонов при изменении структуры данных.

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

Будущее Развитие

С развитием технологий и увеличением объемов данных на финансовых рынках, протокол FAST продолжает эволюционировать. Протокол SBE (Simple Binary Encoding), который является современным продолжением FAST, уже внедрен в даже такие казалось бы совсем далекие от HFT компании, как Binance. SBE отличается от FAST более гибкой структурой и улучшенной эффективностью сжатия данных.

На этом этапе я дошел до стадии описания протокола FAST, что само по себе является небольшим подвигом, так как многие обычно останавливаются на FIX. Если у меня хватит пороха, я постараюсь также охватить и более современный протокол SBE. Так что оставайтесь на связи — впереди еще много интересного!