Внимание! Пожалуйста, уберите от экранов всех программистов в финансовой области с опытом менее 15 лет — мы будем обсуждать настоящие чудеса инженерии.
Введение
Протокол FAST (FIX Adapter for STreaming) — это международный стандарт, используемый для обмена данными в реальном времени на финансовых рынках. Этот протокол был разработан для повышения эффективности и скорости обмена информацией между различными участниками рынка, такими как брокеры, биржи, банки и другие финансовые учреждения. Протокол FAST является ключевым элементом в инфраструктуре высокочастотной торговли (HFT) и продолжает оставаться актуальным, несмотря на его "почтенный" возраст.
История и развитие
Протокол FAST был разработан организацией FIX Protocol Limited (FPL) в начале 2000-х годов как улучшенная версия протокола FIX (Financial Information eXchange). Основная цель разработки FAST заключалась в снижении объема передаваемых данных и увеличении скорости их передачи, что стало критически важным с ростом объемов торгов и появлением высокочастотной торговли (HFT).
Протокол FIX и его логическое продолжение — FAST — хоть и древние, но на удивление до сих пор актуальны. Даже его преемник, протокол SBE (Simple Binary Encoding), был внедрен в такую популярную биржу, как Binance. Статьи на Habr и Habr подробно описывают текстовый формат протокола, и у этих статей есть продолжения. Проблем с текстовым форматом практически нет.
Принципы Работы
Основное преимущество протокола FAST заключается в его способности эффективно сжимать данные. Этот протокол использует несколько ключевых технологий и методов, включая:
Кодирование на основе шаблонов: FAST использует предварительно определенные шаблоны для кодирования повторяющихся структур данных. Это позволяет значительно сократить объем данных, передаваемых по сети.
Сжатие данных: Протокол применяет различные методы сжатия, такие как устранение избыточных данных и использование компактных форматов представления числовых данных.
Инкрементальные обновления: Вместо передачи полного объема данных при каждом обновлении, FAST отправляет только изменения, что значительно уменьшает трафик.
Протокол FAST настолько редкий, что простых материалов практически не существует, кроме спецификаций. В принципе, их более чем достаточно. Редкость обусловлена тем, что протокол работает, как правило, на базе UDP в интранет-зоне (называемой колокацией на бирже), что делает требования к программисту очень серьезными.
Об UDP и Multicast
Когда дело доходит до протокола FAST, UDP делает свою магию, но также приносит немного хаоса в виде потерь пакетов. В финансовом мире это не просто допустимо, но и решаемо с помощью multicast подписок на снэпшоты и инкрементальные обновления. Давайте разберемся, как это работает и что делать, когда данные решают сыграть в прятки.
Multicast подписки
Снэпшоты (Snapshots):
Представьте себе снэпшоты как семейные фотоальбомы — полные и красивые снимки состояния ваших данных в определенный момент времени. Они нужны, чтобы установить основу или восстановить её, если что-то пошло не так. Если вы потеряли несколько пакетов данных, снэпшоты помогут вернуть вас в строй, как старые добрые снимки помогут вспомнить, как вы выглядели до того, как начали терять волосы.
Инкрементальные обновления (Incremental Updates):
Инкрементальные обновления — это как обновление статуса в соцсетях: "Привет, я только что изменил цену акции на пару копеек!" Они поддерживают ваши данные свежими и актуальными без необходимости пересылать всё подряд каждый раз. Это значительно снижает нагрузку на сеть и ускоряет процесс.
Устойчивость к потере пакетов
Теперь о наших верных рыцарях — потоках A и B. Эти два потока передают одни и те же данные, потому что в мире UDP всегда есть шанс, что один из них заблудится.
Поток A и Поток B:
Эти два потока работают как параллельные тросы безопасности. Если один поток упадет, другой подхватит. Если вы потеряете пакет в потоке A, он, вероятно, будет спасен в потоке B.
Что делать, если пакеты потерялись в оба потока
Теперь представьте, что оба потока решили взять выходной одновременно. Что ж, здесь снэпшоты снова приходят на помощь.
Определение потери пакета:
Система замечает, что пакеты потерялись в обоих потоках, и начинает паниковать. Ладно, не паниковать, но точно замечает.
Запрос повторной передачи:
Если в вашем арсенале есть функция повторной передачи, система отправит запрос на повторную отправку потерянных пакетов. Это как сказать: "Эй, можно еще раз? Я пропустил это!"
Использование снэпшота:
Если пакеты не могут быть повторно отправлены (может, они навсегда ушли в цифровой мир), система возвращается к последнему снэпшоту и начинает применять все последующие инкрементальные обновления, чтобы вернуться в настоящее.
Технические детали
Теперь немного технических деталей, чтобы углубиться в специфику FAST.
Формат заголовка
Заголовок сообщения в FAST содержит информацию о типе сообщения и его длине.
Например, тип сообщения может быть представлен одним байтом, а длина — двумя байтами. Таким образом, каждое сообщение начинается с трех байтов служебной информации.
Шаблоны сообщений:
Для каждого типа данных используется отдельный шаблон, который определяет структуру и формат данных. Эти шаблоны заранее известны как отправителю, так и получателю, что позволяет избежать передачи метаинформации.
Шаблон может выглядеть как таблица с полями, где для каждого поля указаны тип данных и способ сжатия.
Кодирование Числовых Данных: В FAST протоколе, который используется в финансовой индустрии для высокоскоростной передачи данных, числовые значения могут быть закодированы несколькими способами в зависимости от типа числа. В протоколе FAST применяется бинарная форма кодирования для обеспечения компактности и эффективности. Вот основные способы кодирования числовых значений:
Целые числа (Integers):
Прямое кодирование (Raw Encoding): Число кодируется как байтовый массив в формате двоичного числа.
Зигзаг-кодирование (Zigzag Encoding): Используется для кодирования знаковых целых чисел. Неотрицательные числа умножаются на 2, а отрицательные числа умножаются на 2 и уменьшаются на 1. После этого результата применяется кодирование с переменной длиной (variable-length encoding).
Кодирование с переменной длиной (Variable-Length Encoding): Использует несколько байтов, чтобы закодировать целое число. Каждый байт, кроме последнего, имеет установленный старший бит (MSB) для указания, что число продолжается в следующем байте.
Дробные числа (Decimals):
Дробные числа кодируются как пара (мантисса и экспонента). Мантисса кодируется как целое число с использованием описанных выше методов кодирования целых чисел, а экспонента кодируется аналогично, как знаковое целое число.
Большие целые числа (Big Integers):
Используются для чисел, которые превышают диапазон стандартного целого числа. Они могут быть закодированы с использованием схемы кодирования с переменной длиной, где размер данных может изменяться в зависимости от величины числа.
Пример процесса декодирования целого числа, закодированного с использованием переменной длины:
Допустим, у нас есть закодированное целое число в следующем виде: 10010110 00000001.
Читаем первый байт:
10010110. MSB установлен, значит, продолжаем чтение.Убираем MSB:
0010110(22 в десятичном).Читаем второй байт:
00000001. MSB не установлен, значит, это последний байт.Конкатенируем и сдвигаем предыдущий результат:
22 << 7 + 1 = 2817.
Таким образом, закодированное значение 10010110 00000001 декодируется в 2817.
Применение
Протокол FAST широко используется в различных областях финансового сектора:
Биржевые платформы: Биржи используют FAST для передачи котировок в реальном времени, что позволяет трейдерам быстро реагировать на изменения рынка.
Брокерские фирмы: Брокеры используют FAST для получения актуальной информации о ценах и объемах торгов, что помогает в принятии решений и управлении рисками.
Банки и финансовые институты: Эти организации применяют FAST для обмена данными между различными системами и департаментами, что способствует улучшению внутренней координации и оперативности работы.
Если для FIX существует много дженерик библиотек, то протокол FAST настолько специфичен, что для него существует всего две основные библиотеки: OnixS и StockSharp. Первая — это общемировая компания, работающая с такими гигантами, как NYSE и NASDAQ. Вторая — наша отечественная разработка, работающая исключительно с Московской Биржей.
Требования к FAST обусловлены производительностью, поэтому почти всегда универсальные решения идут лесом. Кофе, монитор, постер со Страуструпом, удобное кресло и начало создания своего FAST коннектор - что может быть более лучшим началом рабочего дня? Реализация такого протокола, конечно же, требует языка C++ (и никаких шуток про Python здесь не будет). Если говорить о высокой производительности, то даже всплывает такое страшное слово, как FPGA. Для Московской Биржи таких решений честно не встречал, обычно писали на C++, но для этого и существуют комментарии, чтобы внести дополнительную информацию.
Открытые Реализации
Существует несколько открытых реализаций протокола FAST, таких как QuickFAST и OpenFAST.net (под C#, и снова никаких шуток про Python).
Преимущества и недостатки
Преимущества:
Высокая скорость передачи данных: Благодаря сжатию и эффективному кодированию, протокол FAST обеспечивает быструю передачу больших объемов данных.
Снижение нагрузки на сеть: Инкрементальные обновления и сжатие данных уменьшают объем трафика, что снижает нагрузку на сеть и затраты на инфраструктуру.
Универсальность: FAST может быть адаптирован для различных типов данных и использоваться в различных финансовых приложениях.
Недостатки:
Сложность внедрения: Разработка и настройка системы, использующей протокол FAST, требуют значительных усилий и высококвалифицированного персонала.
Зависимость от шаблонов: Необходимость использования предварительно определенных шаблонов может ограничивать гибкость системы и требовать частого обновления шаблонов при изменении структуры данных.
Недостатки дженериков: Все борются за доли микросекунд, поэтому дженерик решения зачастую не подходят из-за их низкой производительности, и плохой адаптации под особенности конкретной биржи.
Будущее развитие
С развитием технологий и увеличением объемов данных на финансовых рынках, протокол FAST продолжает эволюционировать. Протокол SBE (Simple Binary Encoding), который является современным продолжением FAST, уже внедрен в даже такие казалось бы совсем далекие от HFT компании, как Binance. SBE отличается от FAST более гибкой структурой и улучшенной эффективностью сжатия данных.
На этом этапе я дошел до стадии описания протокола FAST, что само по себе является небольшим подвигом, так как многие обычно останавливаются на FIX. Если у меня хватит пороха, я постараюсь также охватить и более современный протокол SBE. Так что оставайтесь на связи — впереди еще много интересного!
