Оптимизация latency в HFT: от WebSocket до co-location

Что такое latency и из чего она складывается

Latency (задержка) в трейдинге — время от появления рыночного события до исполнения вашего ордера в ответ на него.

Полный путь:

1. Событие на бирже (сделка, изменение ордербука)
2. Биржа формирует сообщение и отправляет подписчикам
3. Сообщение идёт по сети до вашего сервера
4. Ваш код получает данные и обрабатывает их
5. Принимается торговое решение
6. Ордер формируется и отправляется на биржу
7. Биржа принимает и исполняет ордер

Каждый шаг — источник задержки. Оптимизация идёт снизу вверх: сначала убираем самые большие потери.

Уровень 1: Географическая близость

Самый большой источник latency — физическое расстояние. Скорость света в оптоволокне — около 200 000 км/с. Москва–Лондон — ~2 500 км. Минимальная задержка только на скорость света: ~12 мс в одну сторону. Реальная задержка с промежуточным оборудованием: 25–40 мс.

Для HFT это недопустимо много.

Решение: размещайте сервер в том же дата-центре, что и биржа. Если Binance использует AWS eu-west-1 (Ирландия) — ваш сервер тоже должен быть там. Внутри одного дата-центра latency: 0,1–1 мс.

Co-location — аренда стойки в дата-центре биржи — даёт преимущество даже перед другим облачным провайдером в том же городе. Прямое соединение через cross-connect кабель убирает все промежуточные узлы.

Уровень 2: Протокол передачи данных

WebSocket — хорошее решение для большинства задач. Но для экстремального HFT переходят на бинарные протоколы.

FIX API — старейший протокол для профессиональной торговли. Присутствует на Binance, Bybit, Coinbase. Бинарный формат даёт меньше накладных расходов по сравнению с JSON. Сложнее в реализации.

Проприетарные протоколы — некоторые биржи предлагают собственные бинарные форматы для институциональных клиентов. Детали — по договорённости.

Уровень 3: Сетевой стек ОС

Стандартный Linux-стек добавляет задержку за счёт прерываний, переключений контекста, системных вызовов. Для обычных приложений это незначительно. Для HFT — заметно.

Kernel bypass (DPDK): позволяет сетевому приложению работать с сетевой картой напрямую, минуя ядро ОС. Снижение latency: 20–50 мкс. Уровень проприетарных HFT-решений.

CPU pinning: закрепление критических потоков на конкретных ядрах CPU. Исключает overhead от планировщика ОС.

NUMA awareness: на многосокетных серверах сетевая карта и CPU-ядра должны быть на одном NUMA-узле.

Уровень 4: Язык программирования и код

Rust — оптимальный выбор для low-latency. Компилируется в машинный код, нет GC-пауз, полный контроль памяти. Многие HFT-компании переходят с C++ на Rust.

C++ — классика HFT. Максимальная скорость, но сложнее в разработке.

Go — хорошая средняя позиция. Значительно быстрее Python, проще C++. GC-паузы есть, но Go 1.21+ сделал их предсказуемее. До 1 мс требований — нормально.

Python — для прототипирования. GIL ограничивает параллелизм, для экстремального HFT не подходит.

Что важно в коде:

• Избегайте аллокаций памяти в hot path — используйте object pools
• Минимизируйте системные вызовы
• Lock-free структуры данных там, где нужен параллельный доступ
• Предварительно аллоцируйте буферы нужного размера

Ориентиры latency

Сколько всего этого нужно

Зависит от стратегии. Для арбитража на секундных таймфреймах — WebSocket в нужном регионе и хорошо написанный Python/Go. Серьёзная оптимизация не нужна.

Для маркетмейкинга или HFT-арбитража на миллисекундных таймфреймах — co-location, FIX API, оптимизированный Rust/C++.

Инфраструктура для серьёзного HFT — инвестиция от десятков тысяч долларов в год. Имеет смысл только если стратегия генерирует достаточно прибыли.

What latency is and where it comes from

Trading latency is the time from a market event to your order execution in response to it. Every step in the chain — event at exchange → network → your server → your code → order sent → exchange execution — is a source of delay. Optimisation goes bottom-up: address the largest losses first.

Level 1: Physical proximity

The biggest latency source. Speed of light in fiber is ~200,000 km/s. Moscow–London: ~2,500 km = minimum 12ms one-way. Real latency with routing: 25–40ms.

Solution: place your server in the same data centre as the exchange. Co-location in the exchange's data centre with a cross-connect cable eliminates all intermediate hops. Internal DC latency: 0.1–1ms.

Level 2: Protocol

WebSocket works for most tasks. For extreme HFT: FIX API (binary, less overhead than JSON) or proprietary binary protocols from the exchange for institutional clients.

Level 3: OS network stack

Kernel bypass (DPDK): direct NIC access bypassing the kernel. Typical improvement: 20–50 µs.

CPU pinning: bind critical threads to specific cores, eliminating OS scheduler overhead.

Level 4: Language and code

Rust: optimal for low-latency. No GC pauses, full memory control. Many HFT firms are migrating from C++ to Rust.

Go: significantly faster than Python, simpler than C++. GC pauses exist but manageable in Go 1.21+. Good for up to 1ms requirements.

Python: prototyping only. GIL limits parallelism.

Latency benchmarks