{"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\/de\/low-latency-crypto-trading\/","title":{"rendered":"Krypto-Trading mit niedriger Latenz: Serverstandorte der B\u00f6rsen, reale API-Latenz und wo Sie Ihren Bot hosten sollten"},"content":{"rendered":"

<\/p>\n

\n
\nBJF TRADING GROUP \u00b7 KRYPTO-INFRASTRUKTUR<\/span><\/p>\n

Krypto-Trading mit niedriger Latenz: Serverstandorte der B\u00f6rsen, reale API-Latenz und wo Sie Ihren Bot hosten sollten<\/span><\/h2>\n

Ein Krypto-Arbitrage-Bot kann ein gutes Signal haben und den Trade trotzdem verlieren, weil der gesehene Preis bereits verschwunden ist, wenn seine Order die B\u00f6rse erreicht. Dieser Leitfaden erkl\u00e4rt, wo die gro\u00dfen B\u00f6rsen ihre Matching-Engines tats\u00e4chlich betreiben, warum ein Ping an einen API-Host fast nichts aussagt, was wir von einem realen Server aus gemessen haben, wie Sie die Latenz von Ihrem eigenen Rechner aus korrekt messen und wie Sie eine Hosting-Region w\u00e4hlen, wenn Ihre Strategie an zwei B\u00f6rsen in verschiedenen L\u00e4ndern handelt.<\/p>\n<\/div>\n

\nIn diesem Leitfaden<\/strong><\/p>\n
    \n
  1. Was niedrige Latenz im Krypto-Trading bedeutet<\/a><\/li>\n
  2. Das Latenzbudget: wohin die Millisekunden gehen<\/a><\/li>\n
  3. Wo Krypto-B\u00f6rsen ihre Matching-Engines betreiben<\/a><\/li>\n
  4. Die CDN-Falle: warum Ping t\u00e4uscht<\/a><\/li>\n
  5. Was wir von einem Server in Montreal gemessen haben<\/a><\/li>\n
  6. Schritt f\u00fcr Schritt: B\u00f6rsenlatenz richtig messen<\/a><\/li>\n
  7. WebSocket-Marktdaten und Uhrensynchronisation<\/a><\/li>\n
  8. Die Hosting-Region f\u00fcr Arbitrage zwischen zwei B\u00f6rsen w\u00e4hlen<\/a><\/li>\n
  9. Wie Latenz zu Geld wird<\/a><\/li>\n
  10. Colocation, VPS und was f\u00fcr unabh\u00e4ngige Trader realistisch ist<\/a><\/li>\n
  11. Latenz in Ihrer eigenen Software<\/a><\/li>\n
  12. Risiken und Grenzen<\/a><\/li>\n
  13. H\u00e4ufige Fragen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Was niedrige Latenz im Krypto-Trading bedeutet<\/h2>\n

    Kurze Antwort:<\/strong> Krypto-Trading mit niedriger Latenz bedeutet, die Zeit zwischen einer Preis\u00e4nderung an einer B\u00f6rse und dem Eintreffen Ihrer Order bei der Matching-Engine dieser B\u00f6rse zu verk\u00fcrzen. Der gr\u00f6\u00dfte Teil dieser Zeit ist physische Entfernung: Die gro\u00dfen B\u00f6rsen betreiben ihre Engines in bestimmten Cloud-Regionen, \u00fcberwiegend in Tokio, Singapur und Hongkong, und ein Bot, der auf einem anderen Kontinent gehostet wird, liegt 150 bis 250 Millisekunden hinter einem Bot direkt neben der Engine. Der zweitgr\u00f6\u00dfte Teil ist vermeidbarer Overhead: kalte Verbindungen, REST-Polling, eine schlecht synchronisierte Uhr und langsamer Code.<\/p>\n

    Im Forex-Handel dreht sich Latenz um einige bekannte Rechenzentren in London, New York und Tokio sowie um die Liquidit\u00e4tsbr\u00fccken der Broker. Bei Krypto sieht das Bild anders aus. Es gibt keinen gemeinsamen B\u00f6rsen-Campus: Jede B\u00f6rse w\u00e4hlt ihre eigene Cloud-Region, die meisten laufen auf \u00f6ffentlicher Cloud-Infrastruktur, und ihre APIs liegen in der Regel hinter Content Delivery Networks (CDNs), die die B\u00f6rse nah erscheinen lassen, obwohl sie es nicht ist. Das macht die Messung zugleich einfacher (Sie k\u00f6nnen f\u00fcr den Preis eines Abendessens einen Server in derselben Cloud-Region mieten) und irref\u00fchrender (die naheliegenden Tests messen das Falsche).<\/p>\n

    Wie wichtig Latenz ist, h\u00e4ngt von der Strategie ab:<\/p>\n

    \n\n\n\n\n\n\n\n\n
    Strategie<\/th>\nWie lange die Gelegenheit \u00fcblicherweise besteht<\/th>\nLatenz, die "gut genug" ist<\/th>\n<\/tr>\n<\/thead>\n
    B\u00f6rsen\u00fcbergreifende Arbitrage mit Transfers zwischen B\u00f6rsen<\/td>\nMinuten (begrenzt durch Blockchain-Best\u00e4tigungen)<\/td>\nSekunden; Geb\u00fchren und Transferzeiten sind weit wichtiger<\/td>\n<\/tr>\n
    Funding-Rate- und Spot-Futures-Basis-Trades<\/td>\nStunden bis Tage<\/td>\nNicht kritisch; Ausf\u00fchrungsqualit\u00e4t ist wichtiger als Geschwindigkeit<\/td>\n<\/tr>\n
    Hedge-Arbitrage (zwei Legs) mit vorfinanzierten Guthaben an beiden B\u00f6rsen<\/td>\nHunderte Millisekunden bis Sekunden bei Mid-Cap-Paaren, weniger bei Majors<\/td>\nZweistellige Millisekunden zu jeder B\u00f6rse<\/td>\n<\/tr>\n
    Latenzarbitrage gegen einen langsameren Handelsplatz, im Wettbewerb mit Market Makern<\/td>\nMillisekunden<\/td>\nEinstellige Millisekunden zum gehandelten Handelsplatz, gleiche Cloud-Region<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Wenn Ihr Vorteil aus langsamen strukturellen L\u00fccken stammt, etwa bei Funding-Rate-Arbitrage<\/a> oder bei Transfers, die durch Auszahlungsgeb\u00fchren und Netzwerkbest\u00e4tigungszeiten<\/a> begrenzt sind, ben\u00f6tigen Sie aus diesem Leitfaden nichts au\u00dfer einem stabilen Server. Wenn Sie Preisunterschiede zwischen Orderb\u00fcchern handeln, entscheidet die Latenz dar\u00fcber, ob Sie ausgef\u00fchrt werden oder hinterherlaufen.<\/p>\n

    Das Latenzbudget: wohin die Millisekunden gehen<\/h2>\n

    "Latenz" ist keine einzelne Zahl. Eine Order, die auf eine Marktbewegung reagiert, durchl\u00e4uft eine Kette von Schritten, und jeder Schritt kostet Zeit. Wenn Sie in Budgets denken, erkennen Sie, welche Teile Sie \u00e4ndern k\u00f6nnen und welche nicht.<\/p>\n

    \"Anatomie
    Die Reaktionskette einer Arbitrage-Order. Die Entfernung wird zweimal bezahlt: einmal, bis die Marktdaten Sie erreichen, und einmal, bis Ihre Order die Engine erreicht.<\/figcaption><\/figure>\n
    \n\n\n\n\n\n\n\n\n\n\n\n\n
    Komponente<\/th>\nTypischer Bereich (ungef\u00e4hr)<\/th>\nWer es kontrolliert<\/th>\n<\/tr>\n<\/thead>\n
    Ver\u00f6ffentlichung der Marktdaten (Engine zum WebSocket-Gateway)<\/td>\nUnter einer Millisekunde bis mehrere Millisekunden; l\u00e4nger bei aggregierten oder gedrosselten Streams<\/td>\nB\u00f6rse; Sie w\u00e4hlen den Stream-Typ<\/td>\n<\/tr>\n
    Netzwerk, eine Richtung, gleiche Cloud-Region<\/td>\nUnter 1 ms bis etwa 2 ms<\/td>\nSie, durch die Wahl des Hostings<\/td>\n<\/tr>\n
    Netzwerk, eine Richtung, benachbarte asiatische Regionen (z. B. Tokio nach Hongkong)<\/td>\nEtwa 20 bis 35 ms<\/td>\nSie<\/td>\n<\/tr>\n
    Netzwerk, eine Richtung, \u00fcber Kontinente hinweg (z. B. Europa oder Nordamerika nach Tokio)<\/td>\nEtwa 70 bis 120 ms<\/td>\nSie<\/td>\n<\/tr>\n
    Verbindungsaufbau (TCP- und TLS-Handshakes) bei einer kalten Verbindung<\/td>\nEin bis drei zus\u00e4tzliche Netzwerk-Roundtrips<\/td>\nSie: Verbindungen warm halten<\/td>\n<\/tr>\n
    Ihr eigener Entscheidungscode<\/td>\nMikrosekunden bis einige zehn Millisekunden<\/td>\nSie<\/td>\n<\/tr>\n
    API-Gateway, Authentifizierung, Rate-Limit- und Risikopr\u00fcfungen<\/td>\nEinige Millisekunden bis einige zehn Millisekunden, mit Spitzen in volatilen M\u00e4rkten<\/td>\nB\u00f6rse<\/td>\n<\/tr>\n
    Matching<\/td>\nMikrosekunden bis wenige Millisekunden<\/td>\nB\u00f6rse<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Das Muster ist eindeutig: Die beiden Faktoren, die Sie kontrollieren und die in zehn oder hunderten Millisekunden gemessen werden, sind wo Ihr Server steht<\/strong> und ob Ihre Verbindungen warm sind<\/strong>. Alles andere geh\u00f6rt entweder der B\u00f6rse oder ist gering, wenn die Software vern\u00fcnftig geschrieben ist. Deshalb konzentriert sich der Rest dieses Leitfadens auf Standort und Messung.<\/p>\n

    Wo Krypto-B\u00f6rsen ihre Matching-Engines betreiben<\/h2>\n

    B\u00f6rsen ver\u00f6ffentlichen den genauen Standort ihrer Matching-Engines selten, doch die meisten laufen in der \u00f6ffentlichen Cloud, und die Region l\u00e4sst sich aus Latenzmessungen aus vielen Cloud-Regionen ableiten. Unabh\u00e4ngige Messungen, die 2026 von Dritten ver\u00f6ffentlicht wurden, stimmen f\u00fcr die meisten gro\u00dfen Handelspl\u00e4tze \u00fcberein. Die Tabelle fasst die \u00f6ffentlich berichteten Regionen zusammen. Betrachten Sie sie als Ausgangspunkt f\u00fcr Ihre eigenen Tests, nicht als Garantie: B\u00f6rsen ziehen um (BitMEX etwa soll seine Engine 2025 von Dublin nach Tokio verlegt haben).<\/p>\n

    \n\n\n\n\n\n\n\n\n\n\n\n
    B\u00f6rse<\/th>\n\u00d6ffentlich berichtete Engine-Region<\/th>\nZuerst zu testende Cloud-Region<\/th>\nVerl\u00e4sslichkeit<\/th>\n<\/tr>\n<\/thead>\n
    Binance<\/td>\nTokio<\/td>\nAWS ap-northeast-1<\/td>\nHoch: \u00fcbereinstimmend in unabh\u00e4ngigen Messungen<\/td>\n<\/tr>\n
    Bybit<\/td>\nSingapur<\/td>\nAWS ap-southeast-1<\/td>\nHoch<\/td>\n<\/tr>\n
    OKX<\/td>\nHongkong<\/td>\nAWS ap-east-1<\/td>\nHoch<\/td>\n<\/tr>\n
    Gate.io, KuCoin, Bitget, HTX<\/td>\nTokio<\/td>\nAWS ap-northeast-1<\/td>\nMittel bis hoch<\/td>\n<\/tr>\n
    Coinbase (Spot)<\/td>\nUSA, Ostk\u00fcste<\/td>\nAWS us-east-1<\/td>\nMittel: API hinter einem CDN, Orderbest\u00e4tigungen messen<\/td>\n<\/tr>\n
    Kraken<\/td>\nEuropa<\/td>\nLondon, Dublin und Frankfurt testen<\/td>\nNiedrig: ver\u00f6ffentlichte Quellen widersprechen sich<\/td>\n<\/tr>\n
    Deribit<\/td>\nRaum London<\/td>\nAWS eu-west-2<\/td>\nMittel bis hoch<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Daraus ergeben sich zwei praktische Schlussfolgerungen. Erstens: Tokio kommt einem zentralen Handelsplatz f\u00fcr Krypto am n\u00e4chsten<\/strong>: Ein Server dort liegt wenige Millisekunden von Binance und mehreren anderen gro\u00dfen Handelspl\u00e4tzen entfernt, etwa 25 ms in eine Richtung von Hongkong und etwa 35 ms in eine Richtung von Singapur. Zweitens: Jede Strategie, die eine asiatische B\u00f6rse mit Coinbase oder einem europ\u00e4ischen Handelsplatz kombiniert, hat zwischen den beiden Engines eine physikalische Untergrenze von 70 bis 120 ms in eine Richtung, ganz gleich, was Sie mit Ihrem eigenen Server tun.<\/p>\n

    Das Hosting eines Servers in einem bestimmten Land \u00e4ndert nichts daran, welche B\u00f6rsen Sie nutzen d\u00fcrfen. Halten Sie sich an die Nutzungsbedingungen jeder B\u00f6rse und an die Vorschriften Ihrer eigenen Rechtsordnung; nutzen Sie niemals Server oder VPNs, um geografische Beschr\u00e4nkungen zu umgehen.<\/p>\n

    Die CDN-Falle: warum Ping t\u00e4uscht<\/h2>\n

    Der h\u00e4ufigste Fehler besteht darin, die Latenz mit ping<\/code> oder mit der Zeit f\u00fcr den Aufbau einer TCP-Verbindung zum API-Hostnamen zu messen. Fast jede gro\u00dfe B\u00f6rse stellt ihre \u00f6ffentlichen REST- und WebSocket-Endpunkte hinter ein CDN oder einen Cloud-Load-Balancer mit Edge-Standorten auf der ganzen Welt. Wenn Sie sich aus Europa oder Nordamerika mit api.binance.com<\/code> verbinden, beantwortet ein Edge-Knoten in einer nahegelegenen Stadt Ihren TCP-Handshake, nicht die Matching-Engine in Tokio. Der Handshake dauert wenige Millisekunden; danach leitet der Edge-Knoten Ihre Anfrage \u00fcber das Backbone des Anbieters an den eigentlichen Ursprungsserver weiter, und dort vergeht die Zeit.<\/p>\n

    Ein Ping von 5 ms zu einem B\u00f6rsen-Hostnamen kann also mit einer realen Anfragezeit von 150 ms einhergehen. Aussagekr\u00e4ftig sind nur Werte, die den Weg zum Ursprungsserver einschlie\u00dfen: die Time to First Byte einer echten API-Antwort \u00fcber eine bereits offene Verbindung, die Verz\u00f6gerung zwischen dem eigenen Ereignis-Zeitstempel der B\u00f6rse und Ihrer Empfangszeit am WebSocket sowie die Zeit vom Senden einer Order bis zum Erhalt ihrer Best\u00e4tigung.<\/p>\n

    \n
    3 bis 15 ms<\/span>TCP-Verbindung zu einem CDN-Edge<\/span>Was Ping-\u00e4hnliche Tests aus Montreal f\u00fcr die meisten B\u00f6rsen-APIs zeigen. Gemessen wird nur die Entfernung zum n\u00e4chsten Edge-Knoten.<\/span><\/div>\n
    ~167 ms<\/span>TCP-Verbindung zu einem Ursprungsserver in Tokio<\/span>Die API von Gate.io antwortete direkt von einer AWS-Adresse in Tokio, ohne vorgeschalteten Edge. Das ist der reale Netzwerk-Roundtrip von Montreal nach Tokio.<\/span><\/div>\n
    +60 bis +130 ms<\/span>Kosten einer kalten Verbindung<\/span>Zus\u00e4tzliche Zeit f\u00fcr die erste Anfrage \u00fcber eine neue Verbindung (TLS-Handshake plus Anfrage) im Vergleich zu einer warmen, bei Endpunkten hinter einem CDN.<\/span><\/div>\n<\/div>\n

    Gemessen von BJF Trading Group am 7. November 2026 von einem Webserver in Montreal (Leaseweb), \u00f6ffentliche Zeit-Endpunkte, zwei Durchl\u00e4ufe mit je einer kalten und 20 warmen Anfragen pro B\u00f6rse.<\/p>\n

    Was wir von einem Server in Montreal gemessen haben<\/h2>\n

    Um den Effekt mit realen Zahlen statt mit Herstellerangaben zu zeigen, haben wir einen kleinen Test von dem Webserver in Montreal aus durchgef\u00fchrt, der diese Website hostet. F\u00fcr acht B\u00f6rsen wurde jeweils eine Verbindung ge\u00f6ffnet, eine Anfrage gesendet (kalt) und anschlie\u00dfend 20 weitere Anfragen \u00fcber dieselbe Keep-Alive-Verbindung gesendet (warm), mit vier Anfragen pro Sekunde; der gesamte Durchlauf wurde zweimal wiederholt. Als Endpunkt diente jeweils der \u00f6ffentliche Serverzeit-Aufruf der B\u00f6rse, der kaum Arbeit verursacht, sodass das Ergebnis nahezu reine Transport- plus Gateway-Zeit ist.<\/p>\n

    \"Balkendiagramm
    Reale Messung, ein Standort, ein Nachmittag. Die kurzen Balken (TCP-Verbindung) zeigen, was ein Ping-\u00e4hnlicher Test anzeigt; die langen Balken zeigen, was eine Trading-Anfrage tats\u00e4chlich kostet.<\/figcaption><\/figure>\n
    \n\n\n\n\n\n\n\n\n\n\n\n\n
    B\u00f6rse<\/th>\nFrontend aus Sicht von Montreal<\/th>\nTCP-Verbindung, ms<\/th>\nKalte erste Anfrage, ms<\/th>\nMedian warme Anfrage, ms<\/th>\nWarm p90, ms<\/th>\n<\/tr>\n<\/thead>\n
    Coinbase<\/td>\nCloudflare-Edge<\/td>\n4<\/td>\n119 bis 140<\/td>\n61<\/td>\n67<\/td>\n<\/tr>\n
    Kraken<\/td>\nCloudflare-Edge<\/td>\n3 bis 15<\/td>\n162 bis 179<\/td>\n108<\/td>\n118<\/td>\n<\/tr>\n
    Binance<\/td>\nCloudFront-Edge<\/td>\n11 bis 74<\/td>\n210 bis 277<\/td>\n148<\/td>\n152<\/td>\n<\/tr>\n
    Bitget<\/td>\nCloudflare-Edge<\/td>\n15 bis 37<\/td>\n226 bis 247<\/td>\n162<\/td>\n173<\/td>\n<\/tr>\n
    KuCoin<\/td>\nCloudflare-Edge<\/td>\n6 bis 23<\/td>\n220 bis 244<\/td>\n163<\/td>\n168<\/td>\n<\/tr>\n
    OKX<\/td>\nCloudflare-Edge<\/td>\n3 bis 4<\/td>\n217 bis 232<\/td>\n169<\/td>\n180<\/td>\n<\/tr>\n
    Gate.io<\/td>\nDirekt, AWS-Adresse in Tokio<\/td>\n167<\/td>\n668 bis 718<\/td>\n179<\/td>\n289<\/td>\n<\/tr>\n
    Bybit<\/td>\nCloudFront-Edge<\/td>\n8 bis 10<\/td>\n278 bis 281<\/td>\n225<\/td>\n407<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Aus diesem kleinen Test ergeben sich vier Lehren:<\/p>\n