{"id":16016,"date":"2026-11-07T16:13:38","date_gmt":"2026-11-07T16:13:38","guid":{"rendered":"https:\/\/bjftradinggroup.com\/?p=16016"},"modified":"2026-11-07T16:13:38","modified_gmt":"2026-11-07T16:13:38","slug":"low-latency-crypto-trading","status":"publish","type":"post","link":"https:\/\/bjftradinggroup.com\/it\/low-latency-crypto-trading\/","title":{"rendered":"Trading crypto a bassa latenza: dove si trovano i server degli exchange, latenza API reale e dove ospitare il tuo bot"},"content":{"rendered":"

<\/p>\n

\n
\nBJF TRADING GROUP \u00b7 INFRASTRUTTURA CRYPTO<\/span><\/p>\n

Trading crypto a bassa latenza: dove si trovano i server degli exchange, latenza API reale e dove ospitare il tuo bot<\/span><\/h2>\n

Un bot di arbitraggio crypto pu\u00f2 avere un buon segnale e perdere comunque il trade, perch\u00e9 quando il suo ordine raggiunge l’exchange il prezzo che aveva visto \u00e8 gi\u00e0 sparito. Questa guida spiega dove i principali exchange fanno girare davvero i loro motori di matching, perch\u00e9 un ping verso un host API non ti dice quasi nulla, cosa abbiamo misurato da un server reale, come misurare correttamente la latenza dalla tua macchina e come scegliere una regione di hosting quando la tua strategia opera su due exchange in paesi diversi.<\/p>\n<\/div>\n

\nIn questa guida<\/strong><\/p>\n
    \n
  1. Cosa significa bassa latenza nel trading crypto<\/a><\/li>\n
  2. Il budget di latenza: dove vanno i millisecondi<\/a><\/li>\n
  3. Dove gli exchange crypto fanno girare i motori di matching<\/a><\/li>\n
  4. La trappola della CDN: perch\u00e9 il ping mente<\/a><\/li>\n
  5. Cosa abbiamo misurato da un server a Montreal<\/a><\/li>\n
  6. Passo dopo passo: misurare correttamente la latenza degli exchange<\/a><\/li>\n
  7. Dati di mercato via WebSocket e sincronizzazione dell’orologio<\/a><\/li>\n
  8. Scegliere la regione di hosting per l’arbitraggio tra due exchange<\/a><\/li>\n
  9. Come la latenza si trasforma in denaro<\/a><\/li>\n
  10. Colocation, VPS e cosa \u00e8 realistico per i trader indipendenti<\/a><\/li>\n
  11. La latenza dentro il tuo software<\/a><\/li>\n
  12. Rischi e limiti<\/a><\/li>\n
  13. Domande frequenti<\/a><\/li>\n<\/ol>\n<\/div>\n

    Cosa significa bassa latenza nel trading crypto<\/h2>\n

    Risposta breve:<\/strong> il trading crypto a bassa latenza consiste nel ridurre il tempo tra una variazione di prezzo su un exchange e l’arrivo del tuo ordine al motore di matching di quell’exchange. Gran parte di questo tempo \u00e8 distanza fisica: i principali exchange fanno girare i loro motori in specifiche regioni cloud, soprattutto a Tokyo, Singapore e Hong Kong, e un bot ospitato in un altro continente \u00e8 indietro di 150-250 millisecondi rispetto a un bot ospitato accanto al motore. La seconda parte pi\u00f9 grande \u00e8 un overhead evitabile: connessioni fredde, polling REST, un orologio mal sincronizzato e codice lento.<\/p>\n

    Nel forex la latenza \u00e8 una storia di pochi data center ben noti a Londra, New York e Tokyo e dei bridge di liquidit\u00e0 dei broker. Nel mondo crypto il quadro \u00e8 diverso. Non esiste un campus di borsa condiviso: ogni exchange sceglie la propria regione cloud, la maggior parte si appoggia a infrastrutture cloud pubbliche e le loro API sono di solito servite tramite content delivery network (CDN) che fanno sembrare l’exchange vicino quando non lo \u00e8. Questo rende la misurazione sia pi\u00f9 facile (puoi noleggiare un server nella stessa regione cloud al prezzo di una cena) sia pi\u00f9 ingannevole (i test ovvi misurano la cosa sbagliata).<\/p>\n

    Quanto conta la latenza dipende dalla strategia:<\/p>\n

    \n\n\n\n\n\n\n\n\n
    Strategia<\/th>\nQuanto dura di solito l’opportunit\u00e0<\/th>\nLatenza "sufficiente"<\/th>\n<\/tr>\n<\/thead>\n
    Arbitraggio cross-exchange con trasferimenti tra exchange<\/td>\nMinuti (limitati dalle conferme on-chain)<\/td>\nSecondi; commissioni e tempi di trasferimento contano molto di pi\u00f9<\/td>\n<\/tr>\n
    Operazioni su funding rate e sulla base spot-futures<\/td>\nDa ore a giorni<\/td>\nNon critica; la qualit\u00e0 di esecuzione conta pi\u00f9 della velocit\u00e0<\/td>\n<\/tr>\n
    Arbitraggio hedge (a due gambe) con saldi gi\u00e0 depositati su entrambi gli exchange<\/td>\nDa centinaia di millisecondi a secondi sulle coppie mid-cap, meno sulle major<\/td>\nDecine di millisecondi verso ciascun exchange<\/td>\n<\/tr>\n
    Arbitraggio di latenza contro una piattaforma pi\u00f9 lenta, in concorrenza con i market maker<\/td>\nMillisecondi<\/td>\nPochi millisecondi (una cifra) verso la piattaforma su cui operi, stessa regione cloud<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Se il tuo vantaggio deriva da gap strutturali lenti, come l’arbitraggio sul funding rate<\/a> o trasferimenti limitati dalle commissioni di prelievo e dai tempi di conferma della rete<\/a>, non ti serve nulla di questa guida oltre a un server stabile. Se fai trading sulle differenze di prezzo tra book degli ordini, \u00e8 la differenza tra essere eseguito e inseguire il prezzo.<\/p>\n

    Il budget di latenza: dove vanno i millisecondi<\/h2>\n

    La "latenza" non \u00e8 un numero solo. Un ordine che reagisce a un movimento di mercato attraversa una catena di passaggi e ognuno aggiunge tempo. Ragionare in termini di budget ti dice quali parti puoi cambiare e quali no.<\/p>\n

    \"Anatomia
    La catena di reazione di un ordine di arbitraggio. La distanza si paga due volte: una perch\u00e9 i dati di mercato arrivino a te, una perch\u00e9 il tuo ordine arrivi al motore.<\/figcaption><\/figure>\n
    \n\n\n\n\n\n\n\n\n\n\n\n\n
    Componente<\/th>\nIntervallo tipico (approssimativo)<\/th>\nChi lo controlla<\/th>\n<\/tr>\n<\/thead>\n
    Pubblicazione dei dati di mercato (dal motore al gateway WebSocket)<\/td>\nDa meno di un millisecondo a diversi millisecondi; di pi\u00f9 per stream aggregati o limitati<\/td>\nExchange; il tipo di stream lo scegli tu<\/td>\n<\/tr>\n
    Rete, sola andata, stessa regione cloud<\/td>\nDa meno di 1 ms a circa 2 ms<\/td>\nTu, con la scelta dell’hosting<\/td>\n<\/tr>\n
    Rete, sola andata, regioni asiatiche vicine (es. da Tokyo a Hong Kong)<\/td>\nCirca 20-35 ms<\/td>\nTu<\/td>\n<\/tr>\n
    Rete, sola andata, tra continenti (es. dall’Europa o dal Nord America a Tokyo)<\/td>\nCirca 70-120 ms<\/td>\nTu<\/td>\n<\/tr>\n
    Apertura della connessione (handshake TCP e TLS) su una connessione fredda<\/td>\nDa uno a tre round trip di rete aggiuntivi<\/td>\nTu: mantieni le connessioni calde<\/td>\n<\/tr>\n
    Il tuo codice decisionale<\/td>\nDa microsecondi a decine di millisecondi<\/td>\nTu<\/td>\n<\/tr>\n
    Gateway API, autenticazione, controlli di rate limit e di rischio<\/td>\nDa pochi millisecondi a decine di millisecondi, con picchi nei mercati volatili<\/td>\nExchange<\/td>\n<\/tr>\n
    Matching<\/td>\nDa microsecondi a pochi millisecondi<\/td>\nExchange<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Lo schema \u00e8 chiaro: le due voci sotto il tuo controllo che si misurano in decine o centinaia di millisecondi sono dove si trova il tuo server<\/strong> e se le tue connessioni sono calde<\/strong>. Tutto il resto o appartiene all’exchange o \u00e8 piccolo se il software \u00e8 scritto con buon senso. Ecco perch\u00e9 il resto di questa guida si concentra su posizione e misurazione.<\/p>\n

    Dove gli exchange crypto fanno girare i motori di matching<\/h2>\n

    Gli exchange pubblicano raramente la posizione esatta dei loro motori di matching, ma la maggior parte gira su cloud pubblico e la regione si pu\u00f2 dedurre da misurazioni di latenza effettuate da molte regioni cloud. Le misurazioni indipendenti pubblicate da terze parti nel 2026 concordano sulla maggior parte delle grandi piattaforme. La tabella riassume le regioni riportate pubblicamente. Considerala un punto di partenza per i tuoi test, non una garanzia: gli exchange si spostano (BitMEX, per esempio, avrebbe trasferito il suo motore da Dublino a Tokyo nel 2025).<\/p>\n

    \n\n\n\n\n\n\n\n\n\n\n\n
    Exchange<\/th>\nRegione del motore riportata pubblicamente<\/th>\nRegione cloud da testare per prima<\/th>\nAffidabilit\u00e0<\/th>\n<\/tr>\n<\/thead>\n
    Binance<\/td>\nTokyo<\/td>\nAWS ap-northeast-1<\/td>\nAlta: coerente tra misurazioni indipendenti<\/td>\n<\/tr>\n
    Bybit<\/td>\nSingapore<\/td>\nAWS ap-southeast-1<\/td>\nAlta<\/td>\n<\/tr>\n
    OKX<\/td>\nHong Kong<\/td>\nAWS ap-east-1<\/td>\nAlta<\/td>\n<\/tr>\n
    Gate.io, KuCoin, Bitget, HTX<\/td>\nTokyo<\/td>\nAWS ap-northeast-1<\/td>\nDa media ad alta<\/td>\n<\/tr>\n
    Coinbase (spot)<\/td>\nStati Uniti, costa orientale<\/td>\nAWS us-east-1<\/td>\nMedia: API dietro una CDN, misura le conferme degli ordini<\/td>\n<\/tr>\n
    Kraken<\/td>\nEuropa<\/td>\nTesta Londra, Dublino e Francoforte<\/td>\nBassa: le fonti pubblicate non concordano<\/td>\n<\/tr>\n
    Deribit<\/td>\nArea di Londra<\/td>\nAWS eu-west-2<\/td>\nDa media ad alta<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Ne derivano due conclusioni pratiche. Primo, Tokyo \u00e8 quanto di pi\u00f9 simile a un hub di trading centrale esista nel mondo crypto<\/strong>: un server l\u00ec \u00e8 a pochi millisecondi da Binance e da diverse altre grandi piattaforme, a circa 25 ms di sola andata da Hong Kong e a circa 35 ms di sola andata da Singapore. Secondo, qualsiasi strategia che abbini un exchange asiatico a Coinbase o a una piattaforma europea ha un limite fisico di 70-120 ms di sola andata tra i due motori, qualunque cosa tu faccia con il tuo server.<\/p>\n

    Ospitare un server in un determinato paese non cambia gli exchange che puoi utilizzare. Rispetta i termini di servizio di ogni exchange e le regole della tua giurisdizione; non usare mai server o VPN per aggirare restrizioni geografiche.<\/p>\n

    La trappola della CDN: perch\u00e9 il ping mente<\/h2>\n

    L’errore pi\u00f9 comune \u00e8 misurare la latenza con ping<\/code> o con il tempo di apertura di una connessione TCP verso il nome host dell’API. Quasi tutti i grandi exchange mettono i loro endpoint pubblici REST e WebSocket dietro una CDN o un load balancer cloud con nodi edge in tutto il mondo. Quando ti connetti a api.binance.com<\/code> dall’Europa o dal Nord America, il server che risponde al tuo handshake TCP \u00e8 un nodo edge in una citt\u00e0 vicina, non il motore di matching a Tokyo. L’handshake richiede pochi millisecondi; poi il nodo edge inoltra la tua richiesta lungo la dorsale del provider fino all’origine reale, ed \u00e8 l\u00ec che se ne va il tempo.<\/p>\n

    Quindi un ping di 5 ms verso il nome host di un exchange pu\u00f2 convivere con un tempo reale di richiesta di 150 ms. Gli unici numeri che hanno senso sono quelli che includono il viaggio fino all’origine: il tempo al primo byte di una risposta API reale su una connessione gi\u00e0 aperta, il ritardo tra il timestamp dell’evento dell’exchange e il tuo tempo di ricezione sul WebSocket, e il tempo dall’invio di un ordine alla ricezione della sua conferma.<\/p>\n

    \n
    3-15 ms<\/span>Connessione TCP a un nodo edge della CDN<\/span>Ci\u00f2 che i test tipo ping mostrano da Montreal per la maggior parte delle API degli exchange. Misura solo la distanza dal nodo edge pi\u00f9 vicino.<\/span><\/div>\n
    ~167 ms<\/span>Connessione TCP a un’origine a Tokyo<\/span>L’API di Gate.io ha risposto direttamente da un indirizzo AWS di Tokyo senza alcun nodo edge davanti. Questo \u00e8 il reale round trip di rete tra Montreal e Tokyo.<\/span><\/div>\n
    da +60 a +130 ms<\/span>Il costo di una connessione fredda<\/span>Tempo extra per la prima richiesta su una nuova connessione (handshake TLS pi\u00f9 richiesta) rispetto a una connessione calda, sugli endpoint dietro CDN.<\/span><\/div>\n<\/div>\n

    Misurato da BJF Trading Group il 7 novembre 2026 da un web server a Montreal (Leaseweb), endpoint pubblici dell’orario, due esecuzioni da una richiesta fredda pi\u00f9 20 calde per exchange.<\/p>\n

    Cosa abbiamo misurato da un server a Montreal<\/h2>\n

    Per mostrare l’effetto con numeri reali anzich\u00e9 con le dichiarazioni dei fornitori, abbiamo eseguito una piccola sonda dal web server che ospita questo sito, a Montreal. Per otto exchange ha aperto una connessione, inviato una richiesta (fredda), poi altre 20 richieste sulla stessa connessione keep-alive (calde), a quattro richieste al secondo, e ha ripetuto l’intera esecuzione due volte. L’endpoint era la chiamata pubblica dell’orario del server di ciascun exchange, che non fa quasi nessun lavoro, quindi il risultato \u00e8 vicino al puro tempo di trasporto pi\u00f9 il tempo del gateway.<\/p>\n

    \"Grafico
    Misurazione reale, una sola localit\u00e0, un solo pomeriggio. Le barre corte (connessione TCP) sono ci\u00f2 che mostra un test tipo ping; le barre lunghe sono quanto costa davvero una richiesta di trading.<\/figcaption><\/figure>\n
    \n\n\n\n\n\n\n\n\n\n\n\n\n
    Exchange<\/th>\nFront end visto da Montreal<\/th>\nConnessione TCP, ms<\/th>\nPrima richiesta fredda, ms<\/th>\nMediana richieste calde, ms<\/th>\np90 calde, ms<\/th>\n<\/tr>\n<\/thead>\n
    Coinbase<\/td>\nNodo edge Cloudflare<\/td>\n4<\/td>\n119-140<\/td>\n61<\/td>\n67<\/td>\n<\/tr>\n
    Kraken<\/td>\nNodo edge Cloudflare<\/td>\n3-15<\/td>\n162-179<\/td>\n108<\/td>\n118<\/td>\n<\/tr>\n
    Binance<\/td>\nNodo edge CloudFront<\/td>\n11-74<\/td>\n210-277<\/td>\n148<\/td>\n152<\/td>\n<\/tr>\n
    Bitget<\/td>\nNodo edge Cloudflare<\/td>\n15-37<\/td>\n226-247<\/td>\n162<\/td>\n173<\/td>\n<\/tr>\n
    KuCoin<\/td>\nNodo edge Cloudflare<\/td>\n6-23<\/td>\n220-244<\/td>\n163<\/td>\n168<\/td>\n<\/tr>\n
    OKX<\/td>\nNodo edge Cloudflare<\/td>\n3-4<\/td>\n217-232<\/td>\n169<\/td>\n180<\/td>\n<\/tr>\n
    Gate.io<\/td>\nDiretto, indirizzo AWS di Tokyo<\/td>\n167<\/td>\n668-718<\/td>\n179<\/td>\n289<\/td>\n<\/tr>\n
    Bybit<\/td>\nNodo edge CloudFront<\/td>\n8-10<\/td>\n278-281<\/td>\n225<\/td>\n407<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Da questo piccolo test emergono quattro lezioni:<\/p>\n