İşin aslı şu ki, yıllardır “binary protokol = daha hızlı” cümlesini neredeyse refleks gibi tekrar ediyoruz. Ben de uzun süre öyle düşündüm. Sonra bir projede, veri paketlerini didik didik ederken fark ettim: mesele HTTP’nin metin olması değil, CPU’nun veriyi nasıl yediğiymiş. Kulağa biraz ters geliyor, biliyorum. Ama bazen tam da orada gizli oluyor kazanç.
Vallahi, Geçen sene, 2025 Nisan’ında İstanbul’da bir finans yazılımı ekibine performans danışmanlığı verirken aynı tartışma döndü durdu. Takım MessagePack’e geçerse her şeyin uçacağını sanıyordu. Ölçtük… Evet, bazı yerlerde iyi kazanç vardı ama bekledikleri kadar değil. Asıl darboğazın serileştirme katmanında değil, bellek erişiminde ve gereksiz kopyalamalarda olduğunu görünce yüzler biraz değişti.
Çok konuştum, örnekle göstereyim.
Hız Meselesi Sandığınız Kadar Basit Değil
Aslında — hayır dur, daha doğrusu, Bakın şimdi, “binary küçük olduğu için hızlıdır” düşüncesi kağıt üstünde fena durmuyor. Daha az bayt gönderiyorsun, daha az iş yapıyorsun gibi görünüyor. Ama modern işlemciler böyle çalışmıyor. Onlar tek tek baytları okuyan eski usul öğrenciler değil — aynı anda büyük blokları taramayı seviyorlar, hani bir öğrencinin kelime kelime değil de paragraf paragraf okuması gibi düşünebilirsiniz bunu.
Mesela AVX2 ya da AVX-512 gibi SIMD talimatlarını düşünün (en azından benim deneyimim böyle). İşlemci bir satırı ezberlemek yerine koca bir sayfayı göz gezdirir gibi tarıyor. O yüzden formatınız ne kadar “insan dostu” görünürse görünsün, eğer CPU’ya saçma sapan sıralı atlamalar yaptırıyorsa performans düşüyor. Buradaki sürpriz şu: HTTP’nin düzenli yapısı çoğu senaryoda bu yüzden hiç de kötü çıkmıyor.
2024 Kasım’ında Ankara’da küçük bir SaaS girişiminde bunu bizzat test etmiştim. Bir servis JSON’dan özel binary formata taşındığında ekip önce sevinmişti; sonra profiling açılınca tablo değişti. Kod sadeleşmişti ama hız artışı sınırlı kalmıştı — çünkü asıl yük ağda değil, uygulama içinde dönüp duran pointer zincirlerindeydi. Kimse beklemiyordu bunu.
Kısacası mesele sadece paket boyutu değil. Önbellek dostu düzen mi kuruyorsun, yoksa işlemciye sürekli “buraya zıpla, sonra oraya git” mi diyorsun? Fark burada büyüyor. Ciddi fark.
HTTP’yi Bir İstek-Cevap Çerçevesi Olarak Görmeyin
Bence en kritik zihinsel kırılma burada başlıyor. HTTP’ye sadece request/response diye bakınca onu daraltıyoruz — halbuki pratikte o yapı, başlıklar, anahtar-değer çiftleri. Gövdeyle çalışan gayet esnek bir veri yerleşimi sunuyor (bizzat test ettim). Daraltmayın yani.
Bunu basitçe şöyle düşünebilirsiniz: binary protokol size önceden çizilmiş çekmece veriyor; HTTP ise size raf sistemi kurdurtuyor. E tabi raf sistemi ilk bakışta — itiraz edebilirsiniz tabi — dağınık görünür ama esneklik sağlar. Hele bir de farklı istemcilerin aynı akışı okuması gerekiyorsa bu hiç küçümsenecek iş değil.
Şimdi gelelim pratik tarafa. Eğer sisteminizde mesaj şekli sık sık değişiyorsa — mesela yeni alan ekleniyor, bazı alanlar opsiyonel oluyor ya da farklı servisler aynı şemayı hafifçe eğip büküyorsa — sabit binary format çabuk can sıkıyor. HTTP benzeri model burada daha rahat nefes aldırıyor. Denediniz mi hiç? Farklı hissettiriyor gerçekten.
Bir formatın hızlı olması için ille de “küçük” olması gerekmez; çoğu zaman düzenli olması yeterli.
Nerede Avantaj Sağlıyor?
Küçük bir startup’taysanız genelde en pahalı şey CPU değil, geliştirme zamanı oluyor. Yani formatınızın biraz esnek olması ekip için ilaç gibi gelebilir (yanlış duymadınız). Üstüne üstlük observability tarafında header benzeri alanlarla debug yapmak çok daha kolaylaşıyor — bunu yaşayan bilir, geri dönmek istemez.
Kurumsal tarafta ise durum başka. Eğer trafiğiniz milyonlarca isteğe çıkıyorsa cache davranışı, branch prediction, allocation sayısı gibi detaylar aniden sahnenin ortasına oturuyor. Burada doğru tasarlanmış HTTP modeli beklediğinizden iyi sonuç verebilir. Şaşırdım açıkçası ilk karşılaştığımda.
Sıkıştırılmış Format mı, Düzenli Layout mu?
Yani, Açık konuşayım, custom binary protokoller bazen fazla romantize ediliyor. Evet, byte ekonomisi yaparsınız. Evet, wire üzerinde güzel görünür. Ama her optimizasyon bedava değil — çoğu zaman karmaşıklığı başka yere taşırsınız. Bir de şunu söyleyeyim: formatı yazmak kolay olabilir ama onu bakımda tutmak ayrı dert. Gerçekten ayrı dert.
| Kriter | Binary Protokol | HTTP-benzeri Layout |
|---|---|---|
| Paket boyutu | Daha küçük olabilir | Genelde biraz daha büyük |
| Okunabilirlik | Düşük | Yüksek |
| Evrimleşme kolaylığı | Zorlayıcı olabilir | Daha rahat |
| Debug etme | Zahmetli | Daha kolay |
| CPU uyumu | Bazen kötü sürpriz verir | Daha öngörülebilir olabilir |
Dürüst olmak gerekirse, Tablodaki son satır önemli. Çünkü performans yarışını sadece kabloya bakarak kazanamazsınız. CPU cache’i boş yere bozuyorsanız iki kat kompresyon yapsanız bile günün sonunda yine duvara toslarsınız. Maalesef.
Peki Her Şeyde HTTP Mi Kullanacağız?
Hayır, öyle körlemesine olmaz. Telemetri için düşük seviyeli stream’ler, oyun motorları ya da ultra sıkıştırılmış cihaz haberleşmesi hâlâ binary’den fayda görebilir. Ama burada sorulması gereken şu olmalı: “Gerçek darboğaz nerede?” Eğer cevap ağ ise başka, eğer cevap bellek erişimi ise bambaşka konuşuruz. İkisini karıştırmayın. Daha fazla bilgi için MCP’de Asıl Dönüşüm: Stdio’dan HTTP’ye Geçiş yazımıza bakabilirsiniz.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır. iPad ve iMac’i Oyun Ekranına Çeviren Küçük Hile yazımızda bu konuya da değinmiştik. MCP Veritabanı Fırsatı: 2026’da Para Nerede? yazımızda bu konuya da değinmiştik.
- Kritik yol kısa mı? Binary mantıklı olabilir.
- Ekip hızlı iterasyon mu istiyor? HTTP-benzeri yapı daha güvenli hissedilebilir.
- Schemanın sık değişmesi bekleniyor mu? Esnek model kazanım sağlar.
- Aşırı yüksek frekansta mikro-mesaj mı var? Ölçmeden karar vermeyin.
Mühendislerin En Çok Kaçırdığı Nokta: Bellek Davranışı
Herkes wire’a bakarken CPU’nun cache çizgileri sessiz sedasız savaşıyor olabilir. Ben bunu ilk kez 2023’te İzmir’de bir gömülü sistem toplantısında fark etmiştim; ekip paket boyutunu %15 küçültmüş ama latency pek oynamamıştı. Sebep basitti: veri layout’u kötüydü. O kadar. Bu ne anlama geliyor? Başka bir şey değil.
// Basit düşünce örneği
[Token1] [Token2] [Token3]\r
[Key]: [Value]\r
[Key]: [Value]\r
\r
[Body]Böyle bir yapı ilk bakışta metinsel görünüyor diye küçümsemeyin. Aslında makinenin seveceği kadar düz. Birkaç token, birkaç anahtar-değer çifti, sonra gövde — hepsi oldukça tahmin edilebilir ilerliyor. Tahmin edilebilirlik bazen hız demek oluyor; özellikle branch tarafında işinizi ciddi ölçüde kolaylaştırabiliyor. Bunu küçümseyenler sonradan pişman oldu, gördüm. WordPress SSO’da Ayrı Domainler İçin Sağlam Yol Haritası yazımızda da bu konuya değinmiştik. Kurulum mu Dağıtım mı? Yeni Başlayanların Sıkıştığı Nokta yazımızda da bu konuya değinmiştik.
Nerede Hayal Kırıklığı Yaşanabilir?
Tuhaf ama, 6 ay önce Kadıköy’de tanıştığım bir backend ekibi buna fazla kapılmıştı (ben de ilk duyduğumda şaşırmıştım). Ekip her şeyi HttpModel tarzına çevireceklerini düşündü ama gerçek hayatta bazı payload türleri için fazla başlık kullanımı işleri şişirdi. Güzel fikir, ama henüz ham. E peki, sonuç ne oldu? Biraz daha pişmesi lazım bu yaklaşımın.
Bir de güvenlik tarafını unutmayalım. Metinsel yapı gözlemlenebilirlik sağlıyor ama hassas bilgiyi yanlış header’a koyarsanız loglarda çıplak halde kalabilir. O yüzden standartlaştırma olmadan yola çıkmak iyi fikir değil (bizzat test ettim). Hiç değil.
Dikkat Edilecek Pratik Noktalar
- Mikro ölçüm yapmadan karar verme.
- Paket boyutuna takılı kalma.
- Lokal benchmark ile production aynı şey değildir.
- Schemayı versiyonlayarak ilerle. (bence en önemlisi)
- Caching ve allocation etkisini mutlaka izle.
E tabi ölçüm yaparken tek metrik yetmez. p95 latency ile throughput’u birlikte görmek lazım. Bazen yüzde olarak parlak görünen iyileştirme gerçekte kullanıcıya hiçbir şey hissettirmiyor — hatta arka planda GC baskısını artırıp işi bozabiliyor (evet, doğru duydunuz). Böyle vakalar gördüm, inanın.
Açık konuşayım, Neyse uzatmayayım: bu konuya yaklaşırken sloganla değil kanıtla hareket edin.
Sıkça Sorulan Sorular
HTTP gerçekten binary protokolden hızlı olabilir mi?
Evet, bazı durumlarda olabilir. En çok da veri düzeni CPU cache’i ve SIMD kullanımını destekliyorsa avantaj sağlayabilir. Ama bunun kesin cevabı yok; ölçüm şarttır.
Bütün sistemlerde HttpModel yaklaşımı uygun mu?
Hayır. Yüksek frekanslı sensör akışlarında veya çok dar bant genişliği olan yerlerde binary hâlâ mantıklı olabilir. Seçimi kullanım senaryosu belirler.
Küçük ekipler için hangisi daha pratik?
Küçük ekiplerde genelde okunabilirlik ve bakım maliyeti ağır basar. Bu yüzden HTTP-benzeri düzen çoğu zaman işi hızlandırır.
Binary protokol tamamen terk edilmeli mi?
Vallahi hayır. Bazı işlerde en doğru seçim odur;özellikle çok düşük gecikme hedeflerinde hâlâ güçlüdür.
Kaynaklar ve İleri Okuma
RFC 9110 — HTTP Semantics
MDN Web Docs — HTTP Overview
Microsoft.NET Serialization Documentation)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
