Реалтайм-котирування OKX через WebSocket: чому просунуті стратегії відмовляються від REST-опитування

Покрутивши стратегію довше, ти, мабуть, наштовхнешся на таку незручність: логіка ніби правильна, а виконання на реалі завжди на пів кроку запізнюється. Вдивляєшся в код — проблема часто не в самій стратегії, а в тому, як ти береш котирування: усе ще REST-ом раз по раз питаєш «скільки зараз коштує». Таке опитування за природою має затримку, а на високій частоті ще й упирається в ліміт частоти. Щоб стратегія реагувала швидше, зазвичай варто перевести підключення котирувань з опитування на WebSocket-push.

У цій статті ми (команда MeowQuant) чітко пояснюємо, як користуватися WebSocket на OKX: чим він відрізняється від REST-опитування, чому просунуті стратегії його використовують, які канали є в OKX, як писати push через watch_ticker і watch_orders у ccxt.pro, як обробляти перепідключення й heartbeat і — дуже важлива фраза — кому це підходить. Скажемо висновок наперед: це просунутий матеріал, простим стратегіям новачка достатньо REST, не йди на WS зарано задля «вигляду професійності».

REST-опитування проти WebSocket-push

Різниця між ними стане ясною з одної життєвої аналогії. REST-опитування — це наче ти кожні кілька секунд дзвониш співрозмовнику й питаєш «є нові повідомлення?», і здебільшого чуєш «немає», дзвінок намарно; WebSocket — наче ти й співрозмовник з'єднані лінією, яку не кладуть: у нього з'явилося повідомлення — він одразу його тобі каже, а ти нічого й не питаєш.

На рівні техніки:

Коротко: REST простий, але повільний, WebSocket швидкий, але треба написати трохи більше коду. Що обрати — залежить від того, наскільки твоїй стратегії важлива «швидкість».

Чому стратегії варто використовувати WS

Стиснемо порівняння вище до трьох пунктів, від яких стратегія виграє:

• Низька затримка, швидка реакція. Ціна змінилася — її одразу штовхають тобі, стратегія реагує раніше. Для стратегій, що ловлять коливання й полюють на спред, ця різниця в затримці може бути межею між «заробив» і «ні».
• Економія запитів, не впираєшся в ліміт частоти. WS — це одне постійне з'єднання, не шле запити раз по раз, як опитування, тож природно менше тригерить ліміт частоти. Коли стежиш за багатьма парами, ця перевага особливо помітна.
• Реалтайм знаєш власний стан. Приватний канал сам штовхає тобі виконання ордерів, зміни позиції, зміни балансу, не треба раз по раз fetch_open_orders. Стратегія на цьому коригується вчасніше й економніше до інтерфейсу.

Але зверни увагу: «виграш» має передумову — твоя стратегія справді має бути чутливою до часу. Якщо ти крутиш низькочастотну сітку, що перевіряє раз на годину, та крихта переваги в затримці від WS для тебе нічого не варта, а складність ти додав дарма.

Канали WS OKX

Канали WebSocket OKX (API v5) приблизно поділяються на два типи; зрозумієш цей поділ — і код далі піде гладко:

Публічні канали (Public). Штовхають відкриті ринкові дані, підписатися може будь-хто, автентифікація не потрібна. Поширені:

• Котирування (tickers): остання ціна угоди, найкращі bid/ask, зміна за 24 години тощо.
• Свічки (candles): оновлення свічок різних періодів.
• Глибина стакана (books): глибина заявок на купівлю/продаж.
• Угоди по черзі (trades): кожна угода, що відбувається на ринку.

Приватні канали (Private). Штовхають дані твого рахунку, перед підпискою потрібна автентифікація через API-ключ (так само набір із трьох: apiKey, secret, Passphrase). Поширені:

• Ордери (orders): зміни статусу твоїх ордерів, звіти про виконання.
• Позиції (positions): зміни ф'ючерсних позицій.
• Рахунок (account): зміни балансу, маржі тощо.

Однією фразою: публічні канали — дивитися ринок, приватні — дивитися себе. Можеш підписатися лише на публічні для стратегії, керованої котируваннями, а можеш одночасно на приватні, щоб реалтайм відстежувати результати власних ордерів.

Підключаємо котирування через ccxt.pro (watch_ticker)

Найпростіший спосіб підключити WS — усе той самий ccxt: його WebSocket-розширення зветься ccxt.pro і нині вже влилося в основний пакет ccxt. Звичайний ccxt працює через REST, родину fetch_; ccxt.pro — через WS, родину watch_. Оскільки під капотом постійне з'єднання, код треба писати асинхронним (async) циклом.

Цей фрагмент підписується на котирування BTC/USDT і друкує, щойно ціна оновлюється:

import asyncio
import ccxt.pro as ccxtpro     # WS-версія, родина watch_

async def main():
    okx = ccxtpro.okx()        # публічні котирування не потребують автентифікації
    symbol = 'BTC/USDT'
    try:
        while True:
            ticker = await okx.watch_ticker(symbol)   # повертає лише за наявності нового котирування
            print(ticker['symbol'], ticker['last'])
    finally:
        await okx.close()       # при виході закриваємо постійне з'єднання

asyncio.run(main())

Ключова відмінність від REST — у await okx.watch_ticker(...): ти не сам тягнеш, а «висиш і чекаєш push», повертається лише за наявності нового котирування. Постав це в цикл while True — і вийде потік, що безперервно приймає котирування. Зверни увагу на await okx.close() у кінці — постійне з'єднання після використання треба активно закрити, не лишай його висіти.

Приватний канал ордерів (watch_orders)

Окрім публічних котирувань, просунутий прийом — одночасно стежити за власними ордерами. watch_orders штовхатиме тобі, щойно статус твого ордера змінюється (часткове виконання, повне виконання, скасування), набагато вчасніше за повторні fetch_open_orders. Це приватний канал, тож потрібні облікові дані:

import asyncio
import ccxt.pro as ccxtpro

async def main():
    okx = ccxtpro.okx({
        'apiKey':   'твій_apiKey',
        'secret':   'твій_secret',
        'password': 'твій_Passphrase',   # приватний канал потребує автентифікації
    })
    try:
        while True:
            orders = await okx.watch_orders()    # щойно твій ордер змінився — push
            for o in orders:
                print(o['symbol'], o['side'], o['status'], o.get('filled'))
    finally:
        await okx.close()

asyncio.run(main())

З цим твоя стратегія в мить виконання ордера отримає звіт і на його основі одразу виставить наступний ордер чи скоригує позицію, а не чекатиме наступного раунду опитування, щоб дізнатися «о, той ордер виконався». Для стратегій на кшталт сітки чи маркетмейкінгу, що потребують швидкого естафетного виставлення ордерів, це дуже важливо. Приватний канал використовує все той самий твій реальний API-ключ (створення ключа — у статті Квант на OKX API), права лише «Читання» й «Торгівля», без «Виведення».

Перепідключення й heartbeat

Найбільша реальна проблема постійного з'єднання: воно рветься. Мережа колихнулася, біржа планово перезапустилася — з'єднання немає. Наскільки надійно написана WS-стратегія, значною мірою залежить від того, як ти обробляєш обрив. Дві речі обов'язкові:

Heartbeat / keep-alive. Протокол WebSocket покладається на періодичні ping/pong, щоб підтверджувати, що з'єднання живе. Якщо певний час немає активності, біржа визнає це з'єднання мертвим і відрубає. На щастя, ccxt.pro усередині зазвичай сам опікується keep-alive, тобі головне — не давати програмі надовго блокуватися й застрягати на прийомі/відправці повідомлень.

Перепідключення + перепідписка. Обірвалося з'єднання — треба вміти автоматично перепідключитися, а після цього заново підписатися на канали й одноразово звірити поточний реальний стан (наприклад, перетягнути поточні відкриті ордери й позицію), бо push, що сталися під час обриву, ти не отримаєш. Поширений підхід — обгорнути виклик watch_ у try/except, перехопити винятки з'єднання й перепідключитися-перепідписатися:

import asyncio
import ccxt.pro as ccxtpro

async def main():
    okx = ccxtpro.okx()
    symbol = 'BTC/USDT'
    while True:
        try:
            ticker = await okx.watch_ticker(symbol)
            print(ticker['last'])
        except ccxtpro.NetworkError as e:
            print('Помилка з'єднання, скоро перепідключуся й перепідпишуся:', e)
            await asyncio.sleep(2)          # відступи перед перепідключенням, не бий шалено
            # після перепідключення за потреби звір поточну позицію/відкриті ордери
        except Exception as e:
            print('Інший виняток:', e)
            await asyncio.sleep(2)

asyncio.run(main())

Головне тут не краса коду, а той принцип: після обриву не припускай, що стан не змінився, спершу звір, потім продовжуй. Це те саме, що ми говорили в статті Ризик-менеджмент у кванті — «після відновлення спершу перевір статус, потім дій»: під час втрати зв'язку ринок міг уже зрушити, продовжувати наосліп — легко наробити хаосу.

На практиці: порівняння затримки

Кому це підходить

Повернімося до головного запитання: чи потрібен тобі WebSocket. Наш критерій простий —

Раджу спершу REST, якщо: ти новачок; стратегія низькочастотна (перевірка раз на кілька хвилин чи навіть годин); логіка проста й до затримки нечутлива. REST синхронний, наочний, легко відлагоджуваний — для цих сценаріїв його цілком достатньо, та ще й без пасток асинхронності й перепідключення, ти зможеш зосередитися на самій стратегії.

Варто йти на WS, якщо: стратегія чутлива до затримки (ловить коливання, маркетмейкінг, арбітраж на спреді); ти стежиш за багатьма парами одночасно, й опитування починає впиратися в ліміт частоти; тобі потрібен реалтайм-звіт про виконання ордера для естафетного виставлення. У цих сценаріях реалтайм і ефективність WS варті того зайвого асинхронного коду й перепідключення.

Одною фразою: не йди на WS зарано задля вигляду професійності. Спершу REST-ом доведи стратегію до робочого стану, а коли справді впрешся в стелю опитування — повільно чи ліміт частоти — тоді й переходь на WebSocket; цей порядок найекономніший зусиль і найменше ризикує, що технічна складність зіб'є тебе ще до того, як ти розберешся зі стратегією. Хоч що використовуєш, новий код спершу кидай у демо на перевірку.

Поширені запитання

WebSocket — гарний інструмент, але він для тих, хто «вже знає, навіщо він потрібен». Якщо ти ще закладаєш фундамент, спершу доведи до робочого стану Квант на OKX API, постав ризик-менеджмент — це набагато важливіше за перехід на WS. А коли стратегія справді перестане встигати, тоді й повертайся до цієї статті.