Düşük Gecikmeli Kripto Ticareti: Borsa Sunucu Konumları, Gerçek API Gecikmesi ve Botunuzu Nerede Barındırmalısınız Kasım 7, 2026 – Posted in: Arbitrage Software, cryptoarbitrage software

Kripto ticaretinde düşük gecikme ne anlama gelir

Kısa cevap: düşük gecikmeli kripto ticareti, bir borsadaki fiyat değişikliği ile emrinizin o borsanın eşleştirme motoruna ulaşması arasındaki süreyi kısaltmak demektir. Bu sürenin büyük kısmı fiziksel mesafedir: büyük borsalar motorlarını belirli bulut bölgelerinde, çoğunlukla Tokyo, Singapur ve Hong Kong’da çalıştırır ve başka bir kıtada barındırılan bir bot, motorun yanında barındırılan bir bottan 150 ila 250 milisaniye geridedir. İkinci en büyük kısım ise önlenebilir ek yüktür: soğuk bağlantılar, REST sorgulama (polling), kötü senkronize edilmiş bir saat ve yavaş kod.

Forex’te gecikme, Londra, New York ve Tokyo’daki birkaç iyi bilinen veri merkezi ve aracı kurumların likidite köprüleriyle ilgili bir konudur. Kriptoda tablo farklıdır. Ortak bir borsa kampüsü yoktur: her borsa kendi bulut bölgesini seçer, çoğu genel (public) bulut altyapısında çalışır ve API’lerinin önünde genellikle borsayı olduğundan daha yakın gösteren içerik dağıtım ağları (CDN) bulunur. Bu durum ölçümü hem kolaylaştırır (aynı bulut bölgesinde bir akşam yemeği fiyatına sunucu kiralayabilirsiniz) hem de daha yanıltıcı hale getirir (bariz testler yanlış şeyi ölçer).

Gecikmenin ne kadar önemli olduğu stratejiye bağlıdır:

Avantajınız fonlama oranı arbitrajı veya çekim ücretleri ve ağ onay süreleri ile sınırlı transferler gibi yavaş yapısal farklardan geliyorsa, istikrarlı bir sunucu dışında bu rehberdeki hiçbir şeye ihtiyacınız yoktur. Emir defterleri arasındaki fiyat farklarıyla işlem yapıyorsanız, gecikme emrin gerçekleşmesi ile fiyatın peşinden koşmak arasındaki farktır.

Gecikme bütçesi: milisaniyeler nereye gidiyor

"Gecikme" tek bir sayı değildir. Bir piyasa hareketine tepki veren emir bir dizi adımdan geçer ve her adım zaman ekler. Bütçe açısından düşünmek, hangi kısımları değiştirebileceğinizi ve hangilerini değiştiremeyeceğinizi gösterir.

Tablo nettir: kontrol ettiğiniz ve onlarca ya da yüzlerce milisaniyeyle ölçülen iki unsur sunucunuzun nerede olduğu ve bağlantılarınızın sıcak olup olmadığıdır. Geri kalan her şey ya borsaya aittir ya da yazılım makul şekilde yazıldığında küçüktür. Bu rehberin geri kalanının konum ve ölçüme odaklanmasının nedeni budur.

Kripto borsaları eşleştirme motorlarını nerede çalıştırıyor

Borsalar eşleştirme motorlarının tam konumunu nadiren yayınlar, ancak çoğu genel bulutta çalışır ve bölge, çok sayıda bulut bölgesinden yapılan gecikme ölçümlerinden çıkarılabilir. 2026’da üçüncü taraflarca yayınlanan bağımsız ölçümler büyük platformların çoğu konusunda hemfikirdir. Tablo, kamuya açık olarak bildirilen bölgeleri özetler. Bunu bir garanti olarak değil, kendi testleriniz için bir başlangıç noktası olarak görün: borsalar taşınabilir (örneğin BitMEX’in 2025’te motorunu Dublin’den Tokyo’ya taşıdığı bildirilmişti).

Buradan iki pratik sonuç çıkar. Birincisi, Tokyo, kriptonun merkezi bir ticaret merkezine en yakın şeydir: oradaki bir sunucu Binance’e ve diğer birkaç büyük platforma birkaç milisaniye uzaklıktadır; Hong Kong’a tek yönde yaklaşık 25 ms, Singapur’a ise tek yönde yaklaşık 35 ms uzaklıktadır. İkincisi, bir Asya borsasını Coinbase veya bir Avrupa platformuyla eşleştiren her stratejinin, kendi sunucunuzla ne yaparsanız yapın, iki motor arasında tek yönde 70 ila 120 ms’lik fiziksel bir alt sınırı vardır.

Belirli bir ülkede sunucu barındırmak, hangi borsaları kullanmanıza izin verildiğini değiştirmez. Her borsanın hizmet şartlarına ve kendi yargı bölgenizin kurallarına uyun; coğrafi kısıtlamaları aşmak için asla sunucu veya VPN kullanmayın.

CDN tuzağı: ping neden yanıltır

En yaygın hata, gecikmeyi ping ile veya API sunucu adına TCP bağlantısı açma süresiyle ölçmektir. Neredeyse her büyük borsa, genel REST ve WebSocket uç noktalarını dünya çapında uç konumları (edge) olan bir CDN’nin veya bulut yük dengeleyicisinin arkasına yerleştirir. Avrupa’dan veya Kuzey Amerika’dan api.binance.com adresine bağlandığınızda TCP el sıkışmanızı yanıtlayan sunucu, Tokyo’daki eşleştirme motoru değil, yakındaki bir şehirdeki uç düğümdür. El sıkışma birkaç milisaniye sürer; ardından uç düğüm isteğinizi sağlayıcının omurga ağı üzerinden gerçek kaynağa (origin) iletir ve zaman orada harcanır.

Yani bir borsa sunucu adına 5 ms’lik ping, 150 ms’lik gerçek bir istek süresiyle bir arada var olabilir. Anlamlı olan tek sayılar, kaynağa kadar olan yolculuğu içerenlerdir: zaten açık bir bağlantı üzerinde gerçek bir API yanıtının ilk bayta kadar geçen süresi, WebSocket’te borsanın kendi olay zaman damgası ile sizin alım zamanınız arasındaki gecikme ve bir emri göndermekten onayını almaya kadar geçen süre.

BJF Trading Group tarafından 7 Kasım 2026’da Montreal’deki bir web sunucusundan (Leaseweb) ölçülmüştür; genel zaman uç noktaları, her borsa için bir soğuk artı 20 sıcak istekten oluşan iki çalıştırma.

Montreal’deki bir sunucudan neler ölçtük

Etkiyi sağlayıcı iddiaları yerine gerçek rakamlarla göstermek için, bu siteyi barındıran Montreal’deki web sunucusundan küçük bir test çalıştırdık. Sekiz borsanın her biri için bir bağlantı açtı, bir istek gönderdi (soğuk), ardından aynı keep-alive bağlantısı üzerinden saniyede dört istek hızında 20 istek daha gönderdi (sıcak) ve tüm çalıştırmayı iki kez tekrarladı. Uç nokta, her borsanın neredeyse hiç iş yapmayan genel sunucu zamanı çağrısıydı; bu nedenle sonuç saf taşıma artı ağ geçidi süresine yakındır.

Bu küçük testten dört ders çıkıyor:

• Bir CDN arkasında bağlantı süresi anlamsızdır. OKX, TCP el sıkışmasını 3 ila 4 ms’de yanıtladı, ancak her gerçek istek yaklaşık 170 ms sürdü; çünkü asıl iş Hong Kong’da yapılıyor.
• Sıralama coğrafyayı izler. Montreal’den en hızlısı Coinbase (ABD doğu kıyısı), ikincisi Kraken (Avrupa) ve Asya borsaları 150 ila 225 ms aralığında toplanıyor. Tokyo’dan bakıldığında sıralama tersine dönerdi.
• Soğuk bağlantılar pahalıdır. Yakında bir uç düğüm olmadığında her el sıkışma gidiş-dönüşü Pasifik’i geçer: Gate.io’ya ilk istek yaklaşık 0.7 saniye, sonrakiler yaklaşık 0.18 saniye sürdü. Sinyali gördüğünde yeni bağlantı açan bir bot zaten kaybetmiştir.
• Kuyruklar önemlidir. Bybit’in medyanı 225 ms idi, ancak her on istekten biri 400 ms’den uzun sürdü. Bir arbitraj bacağı ancak yavaş durumları kadar hızlıdır; bu yüzden yalnızca medyana değil, her zaman p90 ve p99’a da bakın.

Bu rakamlar bir ticaret kurulumunu değil, tek bir öğleden sonra tek bir web sunucusunu tanımlar ve her borsanın ağ geçidi işlemesini içerir. Borsaların bir sıralaması değildir. Amaçları etkilerin büyüklüğünü göstermektir: uzaktaki bir botun yaşadığı gecikmenin %90’ından fazlası coğrafya ve bağlantı yönetiminden kaynaklanır.

Adım adım: borsa gecikmesini doğru ölçmek

Anlamlı bir ölçümü herhangi bir sunucudan bir saat içinde tekrarlayabilirsiniz. Aşağıdaki yöntem, bir barındırma bölgesi seçmeden önce veya altyapınızdaki herhangi bir değişiklikten sonra önerdiğimiz yöntemdir.

2. adım için başlangıçta basit bir curl yeterlidir. URL’yi tekrarlamak curl’ün tek bir bağlantıyı yeniden kullanmasını sağlar; ilk satır soğuk istektir, geri kalanlar sıcaktır:

curl -s –rate 4/s -w "%{num_connects} %{time_connect} %{time_starttransfer}\n" -o /dev/null URL -o /dev/null URL -o /dev/null URL

4. ve 5. adımlar için botunuzun kullandığı dilde birkaç satır koda ihtiyacınız vardır; çünkü ölçüm, canlı işlemlerle aynı istemci kütüphanesinden, aynı JSON ayrıştırıcısından ve aynı bağlantı ayarlarından geçmelidir. Farklı bir araçla elde edilen sayı size yalnızca o araç hakkında bilgi verir.

WebSocket piyasa verisi ve saat senkronizasyonu

Zamana duyarlı her şey için piyasa verisi REST sorgulamasından değil, WebSocket akışlarından gelmelidir. Emir defterini her 200 ms’de bir isteyen bir sorgulama döngüsü, istek süresine ek olarak bir değişikliği görmeden önce ortalama 100 ms bekleme ekler ve emirler için ihtiyaç duyduğunuz istek limiti bütçesini tüketir. Bir WebSocket akışı ise her güncellemeyi borsa yayınlar yayınlamaz iletir. Akışların, yerel emir defterlerinin ve sıra kontrollerinin ayrıntıları arbitraj için kripto borsa API’lerine bağlanma rehberimizde ele alınmıştır; burada zamanlamaya odaklanıyoruz.

Veri akışı gecikmesini ölçmek

Çoğu borsa WebSocket mesajı, borsa tarafından belirlenen bir zaman damgası taşır: genellikle milisaniye cinsinden bir olay zamanı, işlem zamanı veya mesaj zamanı. Bunu yerel alım zamanınızdan çıkardığınızda, borsanın dahili yayın gecikmesini ve ağ yolculuğunu içeren veri akışı gecikmesini elde edersiniz. Bunu yalnızca ortalama olarak değil, her akış için ayrı kaydedin: derinlik anlık görüntüleri, artımlı defter güncellemeleri ve işlem akışları farklı davranabilir; her 100 ms’de bir yayın yapan birleştirilmiş akışlar ise testere dişi bir desen gösterir.

Saat neden önemlidir

Tek yönlü ölçümler, ancak saatinizin borsanın saatiyle uyumu kadar iyidir. Sunucu saatiniz 15 ms geride ise, her veri akışı gecikmesi olduğundan 15 ms daha iyi görünür. Bir bulut sunucusunda chrony’yi sağlayıcının zaman hizmetine karşı çalıştırın ve chronyc tracking komutunu kontrol edin: yaklaşık bir milisaniye içindeki bir sapma, bölgeleri karşılaştırmak için sağlam bir temeldir. Birçok borsa ayrıca bir sunucu zamanı uç noktası sunar; ölçülen gidiş-dönüşün yarısını hesaba katarak bunu kendi saatinizle karşılaştırmak kaba bir çapraz kontrol sağlar. Bir alım penceresi (istek zaman damgasının izin verilen maksimum yaşı) kabul eden emir uç noktaları da saatiniz kaydığında emirleri reddeder; bu da saati senkronize tutmak için bir başka nedendir.

Emir yolunu ayrıca ölçün

Veri akışı gecikmesi, piyasaya bakışınızın ne kadar eski olduğunu söyler. Emir gidiş-dönüşü ise buna göre hareket etmenin ne kadar sürdüğünü söyler. İkisi sıklıkla farklıdır: emir istekleri, piyasa verisi akışının geçmediği kimlik doğrulama, istek limiti hesabı ve risk kontrollerinden geçer. Aralarında Binance’in de bulunduğu bazı borsalar, imzalı bir emri eşleştirme motoruna göndermeden doğrulayan bir emir test uç noktası sunar; bu, ağ ve ağ geçidi kısmını ölçer. Borsa WebSocket veya FIX oturumu üzerinden emir girişi sunuyorsa bunu da ölçün; çünkü kalıcı bir oturum istek başına ek yükü ortadan kaldırır.

İki borsalı arbitraj için barındırma bölgesi seçimi

Tek bir borsa için cevap basittir: motoruyla aynı bulut bölgesinde bir sunucu kiralayın. İki borsa arasındaki arbitraj ise bir geometri problemidir; çünkü motorlar farklı yerlerdedir ve yalnızca birinin yanında olabilirsiniz.

Binance (Tokyo) ile Bybit (Singapur) arasında bir hedge arbitrajını ele alalım. İki bölge arasındaki gidiş-dönüş yaklaşık 70 ms, yani tek yönde kabaca 35 ms’dir. Başlıca seçenekleri değerlendirelim:

Gidiş-dönüş süreleri, genel bulut bölgeleri arasındaki yaklaşık tipik değerlerdir; sağlayıcınızın güncel bölgeler arası rakamlarını kontrol edin ve kendi sunucularınızdan ölçün.

Temel gözlem şudur: bilgi her zaman iki borsa arasındaki mesafeyi kat etmek zorundadır. Fiyat Binance’te hareket eder ve eski kotasyon Bybit’te durursa, Tokyo’daki bir sunucu hareketi anında görür ve emri Singapur’a 35 ms’de ulaşır; Singapur’daki bir sunucu ise hareketi 35 ms geç alır ve emri anında ulaşır. Toplam aynıdır. Değişen şey, zincirin hangi kısmının beklediğidir ve dolayısıyla seçime hangi kararın yön vermesi gerektiğidir:

• Emrin kazanması gereken platformun yanında barındırın. Kârınız bir borsada diğer trader’lardan önce bir kotasyonu yakalamaya bağlıysa, o sıranın belirlendiği yerde rekabet edin. Orada herkesin diğer borsa hakkındaki bilgisi aynı hızda gelir, ancak sizin emrinizin yol kat etmesi gerekmez.
• Hedge’i daha derin deftere koyun. Borsasına daha geç ulaşan bacak, birkaç milisaniyeye en az duyarlı olan bacak olmalıdır: hedge fiyatının fazla hareket etme olasılığının düşük olduğu daha likit defter.
• Gerçekleşme durumunu hızlı öğrenin. Kısmi gerçekleşmelerin yaygın olduğu borsanın yanında olmak, hedge büyüklüğünü doğru bilgiye göre belirlemenizi sağlar ve bu da hedge edilmemiş riski azaltır.
• Yalnızca kârlı olduğunda bölün. Her bölgede bir tane olmak üzere iki süreç, her biri yerel bir emir defteri tutup yerel olarak tepki verebilir, ancak aynı 70 ms’lik bağlantı üzerinden koordine olmaları gerekir. Bu karmaşıklık ve arıza senaryoları ekler ve esas olarak profesyonel kurulumlar için buna değer.

Üç veya daha fazla Asya platformunu kapsayan stratejiler için, oradaki büyük borsaların sayısı nedeniyle Tokyo genellikle pratik merkezdir. Bir ABD veya Avrupa platformu içeren eşleşmelerde kıtalar arası bacak baskındır ve strateji tek yönde 70 ila 120 ms’ye dayanabilmelidir; bu da saf hız rekabetini dışlar ve daha büyük, daha uzun süren farkları öne çıkarır.

Gecikme nasıl paraya dönüşür

İki emir defteri arasındaki fiyat farkı sabit bir ödül değildir. Diğer trader’lar da onu görür, piyasa yapıcılar kotasyonlarını günceller ve fark, varlığa ve platforma bağlı bir süre içinde kaybolur. Bunu düşünmenin basit bir yolu, her fırsatın ortalama bir ömre sahip rastgele bir süre boyunca var olduğunu varsaymak ve emriniz ulaştığında fırsatın hâlâ orada olma olasılığını sormaktır.

Bu modelde, L milisaniyelik bir tepki süresinden sonra bir farkın hâlâ mevcut olma olasılığı exp(−L / τ) olup burada τ farkın ortalama ömrüdür. Kabaca aynı bölgedeki (5 ms), komşu bölgedeki (40 ms) ve başka bir kıtadaki (150 ms) sunucuya karşılık gelen üç tepki süresi için sonuçlar:

Şimdi buna para ekleyelim. Bir stratejinin günde 200 sinyal bulduğunu, 5,000 USDT’lik bir işlemde %0.10 net avantaj, yani yakalanan sinyal başına 5 USDT sağladığını ve kaçırılan bir sinyalin, bir bacak gerçekleşip geri alınması gerektiği için ortalama 1.5 USDT’ye mal olduğunu varsayalım. Ömrü 200 ms olan farklar için:

Rakamlar varsayımsaldır, ancak sonuç sağlamdır: bir botu başka bir kıtadan doğru bölgeye taşımak aynı stratejinin sonucunu katlayabilir; komşu bir bölgeden aynı bölgeye geçmek ise daha küçük ama yine de anlamlı bir iyileşme sağlar. Ayrıca sınırı da gösterir: bir saniye veya daha uzun süren farklar için gecikme pek önemli değildir ve sonucu ücretler, kayma (slippage) ve envanter belirler. Altyapıya para harcamadan önce, işlem yaptığınız farkların gerçekte ne kadar sürdüğünü kontrol edin; ücretsiz kripto arbitraj tarayıcısı borsalar arasındaki gerçek fiyat farklarını canlı izlemenizi sağlar.

Colocation, VPS ve bağımsız trader’lar için gerçekçi olan

Forex ve hisse senetlerinde colocation, borsanın veya aracı kurumun sunucularıyla aynı veri merkezinde kabin alanı kiralamak anlamına gelir ve başlıca merkezler iyi bilinir (bkz. forex arbitraj VPS ve colocation merkezleri rehberimiz). Kriptoda ise çoğu trader için bunun karşılığı basitçe borsayla aynı bulut bölgesindeki bir sanal sunucudur. Motorun kendisi o bulutta çalıştığı için, aynı bölgedeki bir sunucu ayda onlarca dolarlık bir maliyetle zaten ona bir iki milisaniye uzaklıktadır.

Bir bölge içinde erişilebilirlik bölgesi, milisaniyenin bir kesri kadar ek fark yaratabilir. Bu yalnızca en likit paritelerde profesyonel piyasa yapıcılarla rekabet ettiğinizde önemlidir ve ancak daha büyük kalemleri düzelttikten sonra test etmeye değer: bölge, sıcak bağlantılar, WebSocket verisi ve kendi kodunuz. Bir sunucunun ne kadar hızlı olması gerektiğine ve düşük gecikmenin neden yüksek donanım özelliklerinden daha önemli olduğuna dair genel ilkeler arbitraj için VPS’inizin ne kadar hızlı olması gerekir yazısında ele alınmıştır.

Kendi yazılımınızın içindeki gecikme

Sunucu doğru yerde olduğunda, geriye kalan gecikmeler çoğunlukla kendi kendinize yol açtıklarınızdır. Gördüğümüz sıklık sırasına göre olağan şüpheliler:

• Bağlantıları ihtiyaç anında açmak. REST bağlantılarını bir bağlantı havuzuyla canlı tutun, boştaki bağlantılar kapanmasın diye periyodik olarak hafif bir istek gönderin ve WebSocket’leri borsanın maksimum oturum süresinden önce proaktif olarak yeniden bağlayın.
• Akış yerine sorgulama. WebSocket piyasa verisi ve mümkün olduğunda WebSocket veya FIX emir girişi kullanın.
• Kritik yolda ağır iş. Günlükleri diske yazmak, büyük JSON mesajlarını alan alan ayrıştırmak veya her güncellemede tüm emir defterini yeniden hesaplamak milisaniyeler ekler. Emri göndermeden önce minimumu yapın, gerisini erteleyin.
• İstek limiti cezaları. İstek ağırlığı limitini aşan bir bot reddedilir veya geçici olarak engellenir; bu da sonsuz gecikme demektir. İstekleri her borsa için bütçeleyin ve limitten sonra değil, önce yavaşlayın.
• Çöp toplama ve CPU çekişmesi. Küçük bir paylaşımlı VPS’te diğer kiracılar ve bellek temizleme duraklamaları rastgele anlarda onlarca milisaniye ekleyebilir. Bu, ortalamalarda değil p99’da ortaya çıkar.
• Bacakların sıralı gönderimi. Bir hedge’in iki bacağı birbirinden bağımsızsa, ilk onayı beklemek yerine onları paralel gönderin.

BJF Trading Group’un VIP Crypto Arbitrage yazılımı, merkezi spot ve vadeli işlem borsalarına yerel API’leri üzerinden bağlanır ve sizin seçtiğiniz bir sunucuda çalışır; bu nedenle bu rehberdeki konum ilkeleri doğrudan ona da uygulanır. Gecikmeye dayalı stratejilerin mantığı için gecikme arbitrajı rehberimize, borsalar arası stratejilerin genel tablosu için ise kripto arbitraj genel bakışına göz atın.

Riskler ve sınırlamalar

• Gecikme tek başına bir avantaj değildir. Hızlı olmak yalnızca strateji ücretler, kayma ve envanter maliyetlerinden sonra kârlıysa işe yarar. Negatif avantajlı hızlı bir bot parayı daha hızlı kaybeder.
• Konumlar değişir. Borsalar motorlarını taşır ve CDN sağlayıcılarını değiştirir. Geçen yıl doğru olan bir bölge bugün doğru olmayabilir; düzenli olarak yeniden ölçün.
• Ölçümler yereldir. Montreal rakamlarımız ve yayınlanmış her tablo tek bir yeri ve tek bir anı tanımlar. Kararlarınız için yalnızca kendi sunucunuzdan, kendi yazılımınız üzerinden yapılan ölçümler geçerlidir.
• Stres anında borsa tarafındaki gecikmeler baskındır. Sert piyasalarda ağ geçitleri istekleri kuyruğa alır ve onaylar herkes için yavaşlar. Stratejiniz buna dayanabilmelidir; örneğin onay süreleri arttığında pozisyon büyüklüğünü sınırlayarak.
• Silahlanma yarışının sonu yoktur. En likit paritelerde profesyonel firmalar hıza bağımsız bir trader’ın yapabileceğinden çok daha fazla yatırım yapar. En kısa farklar için rekabet etmek yerine, kurulumunuz için yeterince uzun süren farkları arayın.
• Uyumluluk. Sunucu konumu yasal durumunuzu değiştirmez. Yalnızca size açık olan borsaları ve ürünleri kullanın, API şartlarına ve istek limitlerine uyun.

Sıkça Sorulan Sorular

Bu makale eğitim amaçlıdır ve finansal tavsiye niteliği taşımaz. Montreal tablosundaki gecikme rakamları BJF Trading Group tarafından 7 Kasım 2026’da tek bir sunucudan ölçülmüştür ve borsaların bir sıralaması değildir; bölge bilgileri kamuya açık olarak bildirilen üçüncü taraf ölçümlerine dayanır ve değişebilir. Açıklayıcı veya yaklaşık olarak işaretlenen rakamlar ve grafikler modeller ve tipik değerlerdir; belirli bir borsanın veya trader’ın ölçümleri değildir.