Криптобиржи с поддержкой кастодиальных API: методика теста скорости исполнения ордеров
До реальной сделки может пройти заметно больше времени.
Криптобиржи с поддержкой кастодиальных API нужно проверять по нескольким метрикам сразу: сетевому отклику, времени приёма ордера, задержке до подтверждения сделки и распределению хвостовых задержек. Один замер через curl или CCXT покажет в основном скорость сетевого стека. Для оценки торгового бота этого недостаточно.
Что именно измеряем: четыре разных времени
Кастодиальная модель означает, что активы хранятся на бирже, а API-ключ управляет торговыми операциями в этом аккаунте. Права ключа обычно разделяют: для теста достаточно разрешить чтение и создание ордеров, а вывод средств лучше оставить недоступным.
Архитектура кастодиальной биржи обычно разделена на два слоя. Масштабируемый API-слой принимает запросы, проверяет подпись, права, баланс и лимиты. Matching engine сопоставляет ордера по торговым парам. Эти процессы находятся в одном контуре, но пользовательский API rarely раскрывает, сколько времени заявка ждала именно внутри движка сопоставления.
Поэтому я разделяю замер на четыре уровня:
| Метрика | Что фиксируется | Что она показывает |
|---|---|---|
| RTT | От отправки запроса до получения полного ответа | Общая длительность сетевого запроса |
| TTFB | От отправки до первого байта ответа | Скорость установления соединения и возврата данных |
| Время приёма ордера | От отправки до подтверждения биржи | Прохождение шлюза, авторизации и очереди |
| Время исполнения | От отправки до события сделки | Путь конкретного ордера до фактического fill |
Эти показатели могут расходиться в разы. Например, получение сткана через общедоступный REST-эндпоинт занимает сравнительно мало времени, но ничего не говорит о задержке обработки торгового ордера. И наоборот: WebSocket может быстро доставить событие сделки, уже произошедшей на бирже.
Быстрый ответ на запрос данных ещё не означает быстрое исполнение ордера. Для торговли нужна трассировка всего пути заявки.
Для полноценного анализа нужны локальные метки времени и события жизненного цикла ордера: send, ack, accepted, filled или partially_filled, canceled. У разных бирж названия полей отличаются, поэтому ориентироваться следует на смысл события, а не на конкретный JSON-ключ.
Инфраструктура влияет на задержку сильнее, чем сама библиотека
Сетевой путь до биржи состоит из нескольких участков: компьютер трейдера, интернет-провайдер, магистральная сеть, входной шлюз биржи и внутренняя инфраструктура. Время ответа складывается из задержки на каждом участке, поэтому близкая географически точка не гарантирует быстрый отклик серверов.
В собранных бенчмарках через CCXT вызов получения биржевого стакана проверялся из восьми городов на шести континентах. TTFB составлял около 6–10 мс при близком расположении сервера, например в Токио или Сингапуре для соответствующих бирж, и превышал 300 мс при удалённом расположении. Само географическое расстояние до дата-центра способно добавлять от 10 до 100 мс сетевой задержки.
Но расстояние — лишь один из факторов. Инфраструктурный уровень определяет до 90% различий в задержке API. Здесь важно, где выполняется ваш код:
| Уровень инфраструктуры | Типичный диапазон задержки | Что это означает для теста |
|---|---|---|
| Общий инфраструктурный инстанс, REST или WebSocket | 50–500 мс | На результат заметно влияют соседние пользователи и общие очереди |
| Выделенный сервер или FIX API | 5–50 мс | Меньше конкуренция за ресурсы, короче сетевой путь |
| Колокация и прямое подключение | Менее 1 мс | Режим для высокочастотных решений, недоступный обычному розничному трейдеру через публичный REST API |
Эти диапазоны служат ориентиром для планирования теста. Они не являются гарантией для конкретного аккаунта, пары, рынка или времени суток.
Я всегда проверяю результат из двух точек: с основного рабочего сервера и, если позволяет бюджет, с сервера ближе к инфраструктуре биржи. Если результаты расходятся в разы, узкое место обычно находится в сети. Если расходятся слабо, смотреть нужно на саму биржу и способ подключения.
Отдельная мелкая деталь: для честного сравнения сервер должен использовать стабильный маршрут. Ночной переход на резервный канал, спутниковый интернет или мобильная сеть способны изменить задержку сильнее, чем смена биржи. Условия подключения следует фиксировать вместе с результатами.
REST, WebSocket и FIX: сравнение по реальной роли
Протокол выбирают под задачу. Для редких запросов и ручных сценариев достаточно REST. Боту, которому нужен постоянный поток котировок и событий ордера, обычно удобнее WebSocket. FIX ориентирован на профессиональный поток ордеров и высокую пропускную способность.
| Протокол | Сильная сторона | Подводной камень | Что измерять в первую очередь |
|---|---|---|---|
| REST | Простота, широкая совместимость, привычные HTTP-библиотеки | Сетевые накладные расходы и повторные запросы состояния | TTFB, полный RTT, код ответа, вес запроса |
| WebSocket | Постоянное соединение, поток обновлений и пользовательских событий | Сложнее reconnect, синхронизация состояния и возможный дрейф задержки | Задержку сообщения, разрывы, полноту событий |
| FIX | Компактные сообщения, сессия ордеров, высокая пропускная способность | Не каждый тариф и не каждая биржа предоставляют такой доступ | Подтверждение приёма, время до fill, пропускную способность |
В сравнительном бенчмарке медианная задержка FIX на локальном loopback-уровне находилась в диапазоне 0,177–0,263 мс. У REST медиана составляла 22–25 мс, а WebSocket показывал примерно 72–89 мс при более высокой вариативности.
Цифра FIX в 0,177–0,263 мс относится к локальному измерению. Её нельзя переносить на удалённое подключение обычного трейдера: физический маршрут, балансировщики, обработка на стороне биржи и доступность FIX-сессии здесь не учтены в том же смысле, что при loopback-замере.
WebSocket тоже нельзя автоматически считать более быстрым только потому, что соединение постоянное. В приведённом тесте его медиана была выше, а разброс значений — заметнее. Возможная причина — разная архитектура потоков, способ фиксации событий и нагрузка на обработку. Для конкретного бота смотрите percentile и разрывы соединения, а не только минимальное время.
Минимальная задержка хорошо выглядит в отчёте. Для торговли важнее P99: именно в худшей части распределения чаще возникает расхождение между графиком, исполнением и риском.
Пошаговая методика замера
1. Сформулируйте сценарий
Один универсальный тест для всех ботов не работает. Сначала выберите конкретную операцию:
- получение стакана и проверка свежести котировок;
- отправка лимитного ордера и получение подтверждения;
- отмена открытого ордера;
- получение события исполнения;
- проверка потока при заранее заданной частоте запросов.
Отдельно фиксируйте торговую пару, тип ордера, допустимую задержку и то, что считается успехом. Для сигнального бота важнее стабильный поток котировок. Для бота, выставляющего заявки по рынку, — очередь и fill. Для чувствительного к проскальзыванию алгоритма — хвостовые задержки и время подтверждения.
2. Подготовьте одинаковую среду
Для всех сравниваемых бирж используйте одну и ту же машину, один сетевой маршрут, одну версию клиентской библиотеки и одинаковый режим работы. Иначе сравнение будет смешивать скорость биржи с настройками тестового стенда.
Если проверяются разные биржи, запускайте тесты последовательно в сопоставимые рыночные интервалы. В период высокой волатильности и ликвидности очередь ведёт себя иначе, чем в спокойный период. На каждую серию нужны метки времени начала и окончания.
3. Зафиксируйте состояние локальных часов
Используйте монотонный таймер для измерения интервалов: он не перескочит назад при корректировке системного времени. Параллельно синхронизируйте часы с сервером времени и сохраняйте оценку смещения.
Смещение часов важно при сравнении локальной отправки с серверной меткой биржи. Часы двух разных систем редко совпадают идеально. Перед вычитанием меток нужно оценить offset и его колебания. Если синхронизация не гарантирована, безопаснее опираться на локальный round trip и события, полученные в одной клиентской сессии.
4. Измерьте базовую сеть
Прогрейте соединение и выполните серию одинаковых запросов к лёгкому публичному эндпоинту. Записывайте:
1. локальное время перед отправкой;
2. время получения первого байта;
3. время получения тела ответа;
4. HTTP-код;
5. размер и тип ответа;
6. DNS, TLS и сетевые ошибки.
Через CCXT удобно сравнивать однотипные вызовы разных бирж. Для точного TTFB понадобится измерение на уровне HTTP-клиента: многие библиотеки отдают итоговое время, скрывая момент появления первого байта.
Разделите результаты на серии. Первые запросы после запуска могут содержать DNS-кэширование, TLS-handshake и прогрев соединения. Их полезно сохранить отдельно, чтобы увидеть холодный старт.
5. Проверьте путь торгового ордера
Если у биржи есть тестовая среда или режим с имитацией исполнения, сначала используйте их. В реальной среде для проверки подходят минимальный по размеру лимитный ордер и последующая отмена, если такая операция допускается биржей и правилами аккаунта.
Ожидание мгновенного fill здесь ошибочно: выбранная цена может просто не встретить поток. Для измерения fill нужна контролируемая пара и заранее определённый сценарий, который можно повторить. Один случайный fill нельзя использовать как репрезентативную скорость исполнения.
Отдельно замеряйте отмену. Быстрое подтверждение выставления ордера и медленная отмена создают другой риск: заявка остаётся на рынке дольше, чем рассчитывает бот.
6. Сопоставьте четыре временные метки
Для каждой попытки сохраняйте:
| Метка | Что фиксировать |
|---|---|
t_send | Момент фактической отправки запроса |
t_ack | Получение первого ответа сервера |
t_accept | Серверное или клиентское подтверждение принятия ордера |
t_fill | Событие полного или частичного исполнения |
t_cancel | Подтверждение отмены, если она отправлялась |
Клиентский round trip считается как t_ack − t_send. Время до подтверждения приёма — t_accept − t_send. End-to-end задержка до сделки — t_fill − t_send.
Если биржа возвращает серверные метки, сохраняйте их отдельно. Не смешивайте локальное время получения события с серверным временем его формирования: разница между этими величинами включает очередь доставки.
7. Соберите хвост, а не только среднее
Для каждой серии рассчитайте P50, P90, P95, P99 и P999. Среднее значение для такого теста почти бесполезно: несколько сетевых сбоев способны размыть главный показатель.
P50 показывает типичную задержку. P95 помогает увидеть регулярные задержки. P99 и P999 показывают редкие хвосты, в которых обычно и возникают проблемы у торговых ботов. Ошибки, таймауты и отказы по лимиту учитывайте отдельно: усреднять их вместе с успешными запросами удобно для красивого отчёта и разрушительно для реальной картины.
8. Повторите серию в нагрузке
Сначала измерьте одиночный запрос. Затем постепенно увеличивайте частоту и число одновременных соединений, сохраняя шаг каждой серии. Так будет видно, где заканчивается запас биржи.
Не смешивайте тест пропускной способности с замером чистой задержки. Под нагрузкой P99 может резко вырасти из-за очередей, блокировок и конкуренции за общие ресурсы. Если именно этот режим соответствует торговому боту, он и должен попасть в итоговый отчёт.
Лимиты запросов: цифры без мелкого шрифта
У Binance базовый лимит REST API составляет 6 000 request weight в минуту на IP-адрес. Одна FIX-сессия ввода ордеров позволяет отправлять до 10 000 сообщений каждые 10 секунд.
Эти ограничения нельзя напрямую приравнивать. REST-лимит измеряет вес запросов, а FIX-лимит — количество сообщений в сессии. Один HTTP-вызов может иметь собственный вес, и у разных методов он различается. Конкретный вес следует брать из актуальной документации метода, иначе расчёт запасного потока будет неточным.
Во время теста сохраняйте:
- фактическое число запросов и их суммарный вес;
- число сообщений в каждой FIX-сессии;
- коды ответов и тексты отказов;
- момент первого ограничения;
- задержку после достижения лимита;
- число повторов и клиентских таймаутов.
Автоматический ретрай способен незаметно превратить тест в источник лишней нагрузки. Особенно опасен бездумный цикл при отказе по лимиту: клиент продолжает спрашивать биржу о коде ошибки и сам добивает лимит. После ограничения нужна пауза с контролируемым ростом нагрузки, а не новый плотный поток запросов.
Для сравнения бирж я заношу лимиты в одну таблицу и проверяю их непосредственно перед тестом. Условия меняются, тарифные уровни отличаются, а аккаунтные ограничения иногда оказываются строже базовых. Число из документации без даты проверки быстро устаревает.
Как читать результаты без самообмана
После сбора данных у биржи обычно остаётся не одна оценка, а профиль: типичная задержка, максимальный зарегистрированный хвост, частота ошибок, доступная пропускная способность и предсказуемость под нагрузкой.
| Задача | На что смотреть в первую очередь |
|---|---|
| Поток котировок | Стабильность WebSocket, задержка сообщений, reconnect и разрывы |
| Выставление лимитных заявок | Время приёма, подтверждение состояния, задержка отмены |
| Исполнение по рынку | End-to-end fill, проскальзывание, доля частичных исполнений |
| Высокочастотная стратегия | Dedicated-сервер или FIX, колокация, P99 и поведение под конкурентной нагрузкой |
Универсального порога «быстрая биржа» не существует. Общая инфраструктура с диапазоном 50–500 мс может подходить ботам, которым достаточно секундной реакции. Dedicated-контур с 5–50 мс будет избыточен для редких заявок, но важен там, где каждый пропуск сделки стоит денег. Субмиллисекундные результаты относятся к колокации и прямым подключениям, недоступным в стандартном розничном доступе.
Отдельно проверьте, что ваш тест не превратился в измерение блокчейн-подтверждения. Подтверждение транзакции в сети при on-chain swap и задержка исполнения заявки в книге заявок CEX относятся к разным процессам. Смешивать эти цифры нельзя.
Мой вердикт по методике простой: сначала разделяйте TTFB, RTT, приём и fill; затем фиксируйте инфраструктуру и географию; после этого проверяйте P99, ошибки и лимиты под нагрузкой. Для выбора кастодиальной биржи одного «быстрого» скриншота недостаточно. Нужен воспроизводимый журнал, в котором видно, где именно проведено измерение, что отправлялось и что биржа подтвердила в ответ. Только такой результат можно честно сравнивать и переносить в настройки торгового бота.
