ZSTD vs Brotli vs GZIP: API Sıkıştırması Seçimi

API Sıkıştırması Nedir (ve Ne Zaman Değer)

API yanıt sıkıştırması, sunucunuzun yanıt gövdesini (çoğunlukla JSON) ağ üzerinden göndermeden önce daha küçük bir bayt dizisine kodlaması demektir. İstemci (tarayıcı, mobil uygulama, SDK veya başka bir servis) sonra bunu açar. HTTP üzerinde bu, Accept-Encoding (istemcinin neyi desteklediği) ve Content-Encoding (sunucunun seçtiği) gibi başlıklarla müzakere edilir.

API'lere ne sağlar

Sıkıştırma size başlıca üç şey kazandırır:

• Daha az bant genişliği: Daha küçük yanıtlar uçtan uca daha az bayt tüketir.
• Sınırlı bağlantılarda daha düşük gecikme: Daha az bayt, mobil, yoğun Wi‑Fi ve bölge ötesi çağrılarda genellikle daha hızlı indirir.
• Daha düşük egress maliyeti: Giden veri için ücret ödüyorsanız, transfer boyutunu azaltmak faturayı düşürebilir.

Takas basit: sıkıştırma bant genişliğini kurtarır ama CPU (sıkıştırma/açma) ve bazen bellek (tamponlar) maliyeti getirir. Değerli olup olmadığı darboğazınıza bağlıdır.

Sıkıştırmanın en çok işe yaradığı durumlar

Sıkıştırma genellikle şu durumlarda parlar:

• Metin ağırlıklı ve tekrarlı içerikler (JSON, GraphQL yanıtları, HTML, loglar).
• Orta ya da büyük boyutlu yanıtlar; onlarca veya yüzlerce KB tasarrufu önemlidir.
• Yavaş veya pahalı ağlarda sunulan içerikler (mobil, uluslararası istemciler veya bölge ötesi trafik).

Büyük JSON listeleri (kataloglar, arama sonuçları, analizler) döndürüyorsanız, sıkıştırma genellikle kolay kazanımlardan biridir.

En az işe yaradığı durumlar

Sıkıştırma genellikle CPU için kötü bir kullanım olurken:

• Çok küçük yanıtlar (ör. birkaç yüz bayt). Başlık + CPU yükü tasarrufu gölgeleyebilir.
• Zaten sıkıştırılmış içerikler (JPEG/PNG, MP4, ZIP, birçok PDF). Yeniden sıkıştırma genelde az fayda sağlar veya boyutu artırabilir.
• CPU bağlı servisler (zaten hesaplama ile zorlanan uç noktalar). Sıkıştırma kuyruk gecikmesini artırabilir.

Bu rehber boyunca kullanacağınız karar eksenleri

ZSTD vs Brotli vs GZIP arasında seçim yaparken pratik karar genellikle üçe dayanır:

1. Boyut azaltma (sıkıştırma oranı)
2. Gecikme (sunucu time-to-first-byte artı istemci açma süresi)
3. İstemci desteği (çağıranlarınız ve ara katmanların güvenilir şekilde neyi desteklediği)

Bu makaledeki her şey, bu üçünü API'nizin ve trafik şeklinizin koşullarına göre dengeleme hakkındadır.

ZSTD vs Brotli vs GZIP: Hızlı Karşılaştırma

Üçü de yükü küçültür, ama farklı kısıtlamalar için optimize ederler—hız, sıkıştırma oranı ve uyumluluk.

Bir bakış özeti

• ZSTD (Zstandard): Düşük gecikme ve öngörülebilir CPU istediğiniz API'ler için genelde en iyi denge. Güçlü oran, ama yavaş değil.
• Brotli: Özellikle metin ağırlıklı yanıtlar için genelde en küçük baytları verir. Yüksek seviyeler daha fazla CPU maliyeti getirebilir.
• GZIP: “Her yerde çalışır” seçeneği. Geniş destekli ve işletilmesi kolay; modern alternatiflere göre genelde daha yavaş ve/veya daha büyük sonuç verir.

Tipik güçlü yönler (API açısından ne anlama gelir)

ZSTD hızı: API'niz uç gecikmeye duyarlıysa veya sunucular CPU açısından yoğun ise iyi bir seçimdir. Orta-büyük JSON yanıtları için yeterince hızlı sıkıştırabilir; genel olarak ağ zamanına karşı ihmal edilebilir bir ek yük oluşturur.

Brotli sıkıştırma oranı: Bant genişliği birincil kısıtlama ise (mobil istemciler, pahalı egress, CDN ağırlıklı dağıtım) ve yanıtlar çoğunlukla metinse Brotli kazandırır. Daha küçük payloadlar bile sıkıştırma maliyeti karşılığında değerli olabilir.

GZIP uyumluluğu: Maksimum istemci desteği gerektiğinde (eski SDK'lar, gömülü istemciler, miras proxy'ler) en güvenli seçimdir. En iyi performans olmasa bile genelde yanlış bir tercih değildir.

“Sıkıştırma seviyesi” gerçekten ne değiştirir

Sıkıştırma “seviyeleri”, CPU zamanı ile daha küçük çıktı arasında tercih yapar:

• Düşük seviyeler: Daha hızlı sıkıştırma, daha büyük çıktılar. Gerçek zamanlı API'ler için iyi.
• Yüksek seviyeler: Daha küçük çıktı, daha yavaş sıkıştırma (ve bazen daha fazla bellek). Önbelleğe alınabilir büyük yanıtlar için daha uygundur.

Açma genelde her üçü için sıkıştırmadan daha ucuzdur, ama çok yüksek seviyeler istemci CPU/batarya üzerinde etkili olabilir—mobil cihazları düşünün.

Basit bir başparmak kuralı

• Varsayılan seçim: Gecikmenin önemli olduğu çoğu JSON/REST/GraphQL API için ZSTD kullanın.
• Brotli'ye geçin: Eğer kullanılabilir en küçük bayt hedefinizse (metin ağırlıklı yanıtlar, CDN dağıtımı, yavaş ağlar) ve ekstra CPU'yu göze alabiliyorsanız.
• GZIP ile kalın: Daha eski veya çeşitli istemcilerle çalışıyorsanız veya altyapınız yeni kodlamaları desteklemiyorsa en geniş uyumluluk için.

Sıkıştırma Oranı vs Gecikme: Temel Takas

Sıkıştırma sıkça “daha küçük yanıtlar = daha hızlı API” olarak satılır. Bu çoğu zaman yavaş veya pahalı ağlarda doğrudur—ama otomatik değildir. Eğer sıkıştırma sunucu CPU zamanını yeterince artırırsa, ağda daha az bayt olsa bile isteğiniz daha yavaş olabilir.

Zaman nerede harcanıyor

İki maliyeti ayırmak faydalıdır:

• Sıkıştırma zamanı (sunucu tarafı): sunucu byte göndermeden önce yaptığı iş. Bu doğrudan TTFB'ye eklenir.
• Açma zamanı (istemci tarafı): gelen baytları aldıktan sonra yapılan iş. Genelde sıkıştırmadan ucuzdur ama düşük güçlü cihazlarda veya yüksek verimli istemcilerde önemli olabilir.

Yüksek sıkıştırma oranı transfer süresini azaltabilir, fakat sıkıştırma her isteğe 15–30 ms ekliyorsa, hızlı bağlantılarda kazandığınızdan fazlasını kaybedebilirsiniz.

Yük altındaki kuyruk gecikmesi tuzağı

Yük altındayken sıkıştırma p95/p99 gecikmesini p50'den daha çok bozabilir. CPU kullanımı tırmandığında istekler kuyruklanır. Kuyruklanma küçük isteğe bağlı maliyetleri büyük gecikmelere çevirir—ortalama iyi görünürken en yavaş kullanıcılar zarar görür.

Bir performans özelliği gibi ölçün

Tahmin etmeyin. A/B testi veya kademeli açılış yapın ve karşılaştırın:

• p50 ve p95 gecikme (mümkünse p99)
• API instance'larında CPU kullanımı ve doygunluk
• Yanıt boyutları ve time-to-first-byte

Gerçekten “en iyi” seviye, toplam süreyi azaltandır, sadece baytları küçültmek değildir.

Sunucu ve İstemci Üzerindeki CPU ve Bellek Maliyetleri

Sıkıştırma “bedava” değildir—işi ağdan CPU ve belleğe kaydırır. API'lerde bu, daha yüksek istek işleme zamanı, daha büyük bellek tepe değerleri ve bazen istemci tarafında yavaşlamalar şeklinde görülür.

CPU nerede harcanıyor

Çoğu CPU sıkıştırmada yanıtları sıkıştırırken harcanır. Sıkıştırma desenleri bulur, durum/sözlük oluşturur ve kodlanmış çıktıyı yazar.

Açma genelde daha ucuzdur ama yine de önemlidir:

• Sunucular nadiren istekleri açar (JSON API'lerinde nadir, fakat yüklemeler veya toplu olaylarda daha yaygın).
• İstemciler yanıtları JSON parse etmeden önce açar.

API'niz zaten CPU sıkışmışsa (yoğun uygulama sunucuları, ağır kimlik doğrulama, pahalı sorgular), yüksek seviye sıkıştırma kuyruğu arttırabilir.

Bellek düşünceleri

Sıkıştırma bellek kullanımını birkaç şekilde artırabilir:

• Tamponlar: uygulamalar giriş/çıkış için tamponlara ihtiyaç duyar; büyük gövdeler daha büyük tampon demektir.
• Tam tamponlama vs akış: akış sıkıştırma büyük yanıtlar için daha erken göndermeyi sağlar ve tepe belleği düşürürken, tam tamponlama istekte tepe bellek artırır.

Konteyner ortamlarında daha yüksek tepe bellek OOM kill'lere veya sıkı sınırlara yol açarak yoğunluğu düşürebilir.

Autoscaling ve container limitlerine etkisi

Sıkıştırma her yanıt için CPU döngüleri ekler, bu da bir instance başına düşen iş hacmini azaltır. Bu autoscaling'i tetikleyebilir ve maliyetleri yükseltebilir. Yaygın desen: bant düşer ama CPU harcaması artar—doğru seçim, hangi kaynağın nadir olduğuna bağlıdır.

İstemciler için açma hızının önemi

Mobil veya düşük güçlü cihazlarda açma, render, JavaScript çalıştırma ve batarya ile yarışır. Bir format birkaç KB kurtarıyorsa ama açması daha uzun sürüyorsa, özellikle “kullanılabilir veri zamanı” önemliyse yavaş hissettirebilir.

ZSTD API'ler için: Güçlü Yanlar, Sınırlar ve Mantıklı Varsayılanlar

Zstandard (ZSTD) modern bir sıkıştırma formatıdır; iyi bir sıkıştırma oranı sunarken API'nizi yavaşlatmamak için tasarlanmıştır. Birçok JSON-ağırlıklı API için güçlü bir “varsayılan”tır: GZIP'e göre belirgin şekilde daha küçük yanıtlar, benzer veya daha düşük gecikme ve istemcide çok hızlı açma.

ZSTD hangi durumda en iyi

ZSTD, uçtan uca süreye (sadece en küçük baytlara değil) önem verdiğinizde en değerlidir. Hızlı sıkıştırma ve çok hızlı açma eğilimindedir—istek işleme sırasında her milisaniyenin önemi olduğu API'lerde yararlıdır.

Çeşitli payload boyutlarında da iyi çalışır: küçük-orta JSON anlamlı kazanç görür; büyük yanıtlar daha da fayda sağlar.

API'ler için mantıklı sıkıştırma seviyeleri

Çoğu API için düşük seviyelerle (genelde seviye 1–3) başlamak uygundur. Bunlar genelde en iyi gecikme/boyut dengesini verir.

Daha yüksek seviyeleri yalnızca şu durumlarda kullanın:

• Gövdeler büyük (yüzlerce KB–MB)
• Bant pahalı veya kısıtlı
• CPU bir darboğaz değilse ve ölçtünüz

Pragmatik yaklaşım: düşük global bir varsayılan, sonra birkaç “büyük yanıt” uç noktası için seçici yükseltme.

Akış ve sözlük modu

ZSTD akışları destekler; bu, büyük yanıtlar için tepe belleği azaltabilir ve daha erken veri göndermeyi sağlar.

Sözlük modu, birçok benzer nesne döndüren API'lerde (tekrar eden anahtarlar, sabit şemalar) büyük kazanç sağlayabilir. Etkili olduğu durumlar:

• Gövdeler nispeten küçük ama sık
• Versiyonlanmış sözlükleri güvenle yönetebiliyorsanız

Uyum sınırlamaları

Sunucu tarafı desteği birçok yığında basittir, ama istemci uyumluluğu belirleyici olabilir. Bazı HTTP istemcileri, proxy'ler ve gateway'ler Content-Encoding: zstd'i varsayılan olarak bildirmeyebilir veya kabul etmeyebilir.

Üçüncü taraf tüketicilere hizmet veriyorsanız bir yedek (genelde GZIP) tutun ve yalnızca Accept-Encoding açıkça içeriyorsa ZSTD etkinleştirin.

Brotli API'ler için: Ne Zaman Kazanır, Ne Zaman Kaybeder

Brotli metni çok iyi sıkıştırmak için tasarlanmıştır. JSON, HTML ve diğer “kelimeli” payloadlarda genelde GZIP'i geçer—özellikle yüksek sıkıştırma seviyelerinde.

Brotli nerede kazanır

Metin ağırlıklı yanıtlar Brotli'nin güçlü olduğu alandır. Büyük JSON dokümanları (kataloglar, arama sonuçları, yapılandırma blob'ları) gönderiyorsanız, Brotli baytları belirgin şekilde azaltabilir; bu yavaş ağlarda ve egress maliyetini düşürmede yardımcı olur.

Brotli, bir kez sıkıştırılıp birçok kez servis edilen içeriklerde (önbelleğe alınabilir yanıtlar, versiyonlanmış kaynaklar) de güçlüdür. Bu durumda yüksek seviyeli Brotli CPU maliyeti birçok isteğe amorti edilebilir.

Brotli neden hayal kırıklığı yaratabilir

Dinamik API yanıtları (her istekte üretilen) için Brotli'nin en iyi oranları genelde daha yüksek seviyelerde gelir ve bunlar CPU açısından maliyetli olabilir. Sıkıştırma süresini hesaba kattığınızda ZSTD veya iyi ayarlanmış bir GZIP'e karşı gerçek dünya avantajı beklenenden küçük olabilir.

Ayrıca iyi sıkışmayan payloadlar (zaten sıkıştırılmış veriler, bazı ikili formatlar) için çekici değildir—bu durumda sadece CPU yakarsınız.

Pratik seviye önerisi

• Çalışma zamanı sıkıştırması: CPU zirvesini önlemek için düşük seviyeler (genelde 1–4)
• Önceden sıkıştırılmış/statik: istek başına amorti edildiği zaman daha yüksek seviyeler (genelde 8–11)

İstemci desteği notları

Tarayıcılar HTTPS üzerinde Brotli'yi genelde iyi destekler; bu yüzden web trafiği için popülerdir. Tarayıcı dışı API istemcilerinde (mobil SDK'lar, IoT cihazlar, eski HTTP yığınları) destek tutarsız olabilir—dolayısıyla Accept-Encoding ile doğru müzakere edin ve bir yedek (genelde GZIP) tutun.

GZIP API'ler için: Uyumluluk ve Pratik Performans

GZIP, API sıkıştırması için varsayılan cevap olmaya devam ediyor çünkü en evrensel olarak desteklenen seçenektir. Neredeyse her HTTP istemcisi, tarayıcı, proxy ve gateway Content-Encoding: gzip'i anlar; bu öngörülebilirlik üçüncü taraflarla çalışırken önemlidir.

Neden hâlâ yaygın

Avantajı GZIP’in “en iyi” olması değil—genelde yanlış seçim olmamasıdır. Birçok kuruluş uzun yıllardır operasyonel deneyime sahip, web sunucularında mantıklı varsayılanlar ve yeni kodlamaları kötü ele alan ara katmanlarla daha az sürpriz yaşar.

API'ler için pratik sıkıştırma seviyeleri

API yükleri (çoğunlukla JSON) için orta-düşük seviyeler tatlı nokta olur. Seviye 1–6 çoğunlukla makul boyut indirimi verirken CPU'yu makul tutar.

Çok yüksek seviyeler (8–9) biraz daha sıkıştırma verebilir ama dinamik istekte gecikmeyi genelde karşılamaz.

Modern CPU'lardaki karşılaştırma

Modern donanımda GZIP genelde benzer sıkıştırma oranındaki ZSTD'den daha yavaştır ve metin için Brotli'nin en iyi oranlarına genelde yetişemez. Gerçek API iş yüklerinde bu tipik olarak şunu gösterir:

• ZSTD genelde bayt-kaybı başına hızda kazanır.
• Brotli metin için boyutta kazanabilir ama ayarlarına bağlı olarak daha fazla CPU gerektirebilir.
• GZIP yoğun optimize edildiği için hâlâ rekabetçi kalır.

Uyumluluk kenar durumları

Eski istemcileri, gömülü cihazları, katı kurumsal proxy'leri veya miras gateway'leri desteklemeniz gerekiyorsa GZIP en güvenli tercihtir. Bazı ara katmanlar bilinmeyen kodlamaları çıkarabilir, iletimini bozabilir veya müzakerede hata yapabilir—GZIP ile bu sorunlar daha az görülür.

Ortamınız karışık veya belirsizse, GZIP ile başlayıp yalnızca tam yolu kontrol ettiğiniz yerlerde ZSTD/Brotli eklemek güvenli bir stratejidir.

Payload Tipleri: Ne İyi Sıkışır (ve Ne Sıkışmaz)

Sıkıştırma kazanımları sadece algoritmaya bağlı değildir. En büyük belirleyici gönderdiğiniz verinin türüdür. Bazı payloadlar ZSTD, Brotli veya GZIP ile dramatik şekilde küçülür; bazıları neredeyse hiç değişmez ve sadece CPU yakar.

Yüksek getiri adayları

Metin ağırlıklı yanıtlar tekrarlayan anahtarlar, boşluk ve öngörülebilir kalıplar içerdiği için çok iyi sıkışır:

• JSON (tipik REST yanıtları)
• GraphQL yanıtları (tekrar eden alan adları nedeniyle genelde hacimli)
• XML ve HTML
• Büyük düz metin logları ve API tarafından döndürülen hata izleri

Tekrarlama ve yapı arttıkça sıkıştırma oranı genelde artar.

İkili payloadlar: “ölçmeden karar verme”

Protobuf ve MessagePack gibi ikili formatlar JSON'dan daha kompakt olsa da genelde “rastgele” değildir. Yine de tekrar eden etiketler, benzer kayıt düzenleri ve öngörülebilir diziler içerebilirler.

Bu yüzden bunlar çoğunlukla halen sıkıştırılabilir, özellikle büyük yanıtlar veya liste ağırlıklı uç noktalar için. Kesin cevap, gerçek trafiğinizle test etmektir: aynı endpoint, aynı veri, sıkıştırma açık/kapalı ve boyut ile gecikmeyi karşılaştırın.

Genelde sıkıştırmaya değmeyenler (zaten sıkıştırılmış)

Birçok format zaten dahili olarak sıkıştırılmıştır. HTTP düzeyinde tekrar sıkıştırma genelde çok az kazanç sağlar veya yan etkilere yol açar:

• Görüntüler: JPEG, PNG, WebP
• Video/ses: MP4 vb.
• Arşivler: ZIP, gzip dosyaları
• PDF: çoğu zaman zaten sıkıştırma kullanır

Bunlar için içerik türüne göre sıkıştırmayı devre dışı bırakmak yaygındır.

Pratik kestirme kuralları (basit tutun)

Basit bir yaklaşım: yanıtlar belirli bir minimum boyut eşiğini aştığında sıkıştırın.

• Minimum yanıt boyutu eşiği belirleyin (örneğin birkaç KB)
• Büyük metin yanıtlarını her zaman sıkıştırın; küçük JSON'larda başlık maliyeti baskınsa atlayın

Bu, CPU'yu gerçekten bant genişliği kazandıran yüklerde tutar.

HTTP Başlıkları ve Müzakere: Doğru Yapmak

Sıkıştırma istemci ve sunucunun bir kodlamada anlaşmasıyla düzgün çalışır. Bu anlaşma Accept-Encoding (istemci) ve Content-Encoding (sunucu) ile olur.

Accept-Encoding ve Content-Encoding (basit örnekler)

Bir istemci hangi kodlamayı açabileceğini belirtir:

GET /v1/orders HTTP/1.1
Host: api.example
Accept-Encoding: zstd, br, gzip

Sunucu birini seçer ve ne kullandığını bildirir:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: zstd

Eğer istemci Accept-Encoding: gzip gönderip siz Content-Encoding: br ile yanıt verirseniz, istemci gövdeyi işleyemeyebilir. İstemci Accept-Encoding göndermediyse en güvenli varsayılan genelde sıkıştırma olmamasıdır.

Sunucu tarafı öncelik sırası seçmek

API'ler için pratik bir öncelik genelde şudur:

• önce zstd (hız/oran dengesi iyi)
• sonra br (genelde daha küçük, bazen daha yavaş)
• sonra gzip (en geniş uyumluluk)

Yani: zstd > br > gzip.

Bu evrensel bir kural değildir: trafiğiniz büyük oranda tarayıcılardan geliyorsa br daha yüksek öncelik alabilir; eski mobil istemciler yoğunsa gzip daha güvenli olabilir.

Vary: Accept-Encoding ve önbellekleme

Eğer bir yanıt birden fazla kodlama ile sunulabiliyorsa, ekleyin:

Vary: Accept-Encoding

Bunu yapmazsanız CDN veya proxy gzip (veya zstd) versiyonunu önbelleğe alıp bunu ilgili başlığı istemeyen istemcilere sunabilir.

Kenar durumlar ve güvenli geri dönüşler

Bazı istemciler destek bildirir ama hatalı çözücülere sahiptir. Sağlam kalmak için:

• zstd için decode hataları artarsa geçici olarak gzip'e geri dönün.
• “Problemli” kullanıcı ajanları veya SDK sürümleri için beyaz listeler/dışı bırakmalar düşünün.
• Kritik uç noktalar (auth, webhook) için sıkıştırmayı devre dışı bırakmayı veya en uyumlu seçeneği kullanmayı düşünün.

Müzakere, her baytı sıkıştırmaktan çok istemciyi kırmamaya odaklıdır.

HTTP/2, HTTP/3, CDN'ler ve Gateway'ler

API sıkıştırması tek başına çalışmaz. Taşıma protokolünüz, TLS yükü ve aradaki CDN veya gateway gerçek dünya sonucunu değiştirebilir—ve yanlış yapılandırıldığında işleri bozabilir.

HTTP/2 ve HTTP/3: çoklu akış, başta sıra bekleme ve sıkıştırmanın etkisi

HTTP/2 ile tek bir TCP bağlantısı üzerinden birden çok istek gider. Bu bağlantı yükünü düşürür ama paket kaybı tüm akışları durdurabilir (TCP head-of-line blocking). Sıkıştırma, yanıt gövdelerini küçülterek paket kaybı arkasında “takılı kalan” veriyi azaltmaya yardımcı olabilir.

HTTP/3 QUIC (UDP) üzerinde çalışır ve akışlar arasında TCP seviyesinde head-of-line blokajı yaşamaz. Yine de payload boyutu önemlidir; kayıp cezası bağlantı başına genelde daha azdır. Pratikte sıkıştırma hâlâ değerlidir—fayda daha çok bant tasarrufu ve daha hızlı “time to last byte” olarak görünür.

TLS etkileşimi: CPU bütçesini unutmayın

TLS zaten CPU tüketir (el sıkışmalar, şifreleme/şifre çözme). Yüksek seviyede sıkıştırma eklemek CPU limitlerini aşmanıza neden olabilir. Bu yüzden üretimde genelde “hızlı sıkıştırma ve makul oran” ayarları maksimum oran hedefleyen ayarlardan daha iyi işler.

CDN'ler ve API gateway'ler: otomatik sıkıştırma, geçiş veya başlıkları silme

Bazı CDN/gateway'ler belirli MIME türlerini otomatik sıkıştırır; bazıları origin'in gönderdiğini olduğu gibi geçirir. Birkaçı yanlış yapılandırıldığında Content-Encoding'i normalleştirebilir veya kaldırabilir.

Her rota için davranışı doğrulayın ve Vary: Accept-Encoding başlığının korunmasını sağlayın.

Önbellekleme stratejisi: edge vs origin

Edge'de önbelleğe alıyorsanız, her kodlama için ayrı varyantlar saklamayı (gzip/br/zstd) düşünün; her istekte yeniden sıkıştırmak yerine. Origin'de önbellek varsa, edge yine müzakere edip birden fazla kodlamayı önbelleğe alabilir.

Anahtar nokta tutarlılıktır: doğru Content-Encoding, doğru Vary, ve sıkıştırmanın nerede yapıldığının net olması.

Önerilen Varsayılanlar ve Ayar Kılavuzu

Senaryoya göre önerilen varsayılanlar

• Tarayıcıya bakan API'ler: İstemci Accept-Encoding ile bildiriyorsa Brotli tercih edin. Tarayıcılar Brotli'yi genelde verimli çözer ve metin yanıtlarında daha iyi boyut indirimi sağlar.
• Servisler arası dahili API'ler: Her iki taraf da kontrolünüz altındaysa ZSTD varsayılan yapın. ZSTD genelde GZIP'e göre hız-per-bayt açısından daha iyidir.
• Çeşitli SDK'lar kullanan herkese açık API'ler: Evrensel temel olarak GZIP tutun; destekleyen istemciler için isteğe bağlı ZSTD ekleyin.

Muhafazakâr başlangıç seviyeleri

Başlamak için ölçülmesi kolay ve sürpriz yapma ihtimali düşük seviyeler:

• Brotli: dinamik API yanıtları için seviye 4–6 (daha yüksek seviyeler sunucu CPU'sunu artırabilir)
• ZSTD: genel API yükleri için seviye 3–5
• GZIP: iyi bir varsayılan için seviye 5–6

Daha güçlü oran gerekiyorsa, üretime benzer örneklerle doğrulayın ve p95/p99'u izleyin.

Minimum boyut eşiklendirmesi (ve ayarlama)

Küçük yanıtları sıkıştırmak CPU'yu bayt kazancından daha pahalıya mal edebilir. Pratik başlangıç:

• Çoğu API için 1–2 KB'nin altında sıkıştırma yapmayın
• Eğer CPU kıt ya da çok sohbet eden bir servisiniz varsa 4 KB düşünün

Bunu, (1) kaydedilen baytlar, (2) ek sunucu zamanı ve (3) uçtan uca gecikme değişimi ile karşılaştırarak ayarlayın.

Kontrolleri güvenli şekilde açma yolları

Sıkıştırmayı bir özellik bayrağı arkasında açın, sonra rota bazlı konfigürasyon ekleyin (örn. /v1/search için aç, küçük uç noktalar için kapat). Sorun giderme ve uç istemciler için Accept-Encoding: identity ile istemci-taraflı opt-out sağlayın. Önbellek doğruluğu için her zaman Vary: Accept-Encoding ekleyin.

Modern geliştirme ve dağıtım iş akışlarında görünen yer

Hızla prototip çıkartan ekiplerde sıkıştırma, genelde “küçük bir konfigürasyon, büyük etki” düğmesidir. Koder.ai üzerinde ekipler bu noktaya daha erken gelir çünkü tam yığın uygulamaları hızlıca dağıtıp gerçek trafikle ayarları (sıkıştırma ve önbellek başlıkları dahil) inceleyebilirler. Sonuç: sıkıştırmayı bir performans özelliği olarak ele alın, bayrakla açın ve p95/p99'u ölçün.

Dağıtım, İzleme ve Sorun Giderme

Sıkıştırma değişiklikleri kolay gönderilebilir ama üretimde yanlış yapılması da kolaydır. Bunu bir özellik gibi ele alın: kademeli dağıtın, etkisini ölçün ve geri almayı basit tutun.

Güvenli dağıtım planı

Önce bir canary ile başlayın: yeni Content-Encoding (ör. zstd)'i küçük bir trafik dilimine veya tek bir dahili istemciye açın.

Sonra kademeli arttırın (ör. %1 → %5 → %25 → %50 → %100), kritik metrikler tersine dönerse duraklayın.

Hızlı geri alma yolları bulundurun:

• Gateway/servis üzerinde sıkıştırmayı devre dışı bırakma veya gzip'e düşürme için özellik bayrağı
• Belirli uç noktaları hariç tutma (dosya indirme, zaten sıkıştırılmış medya)
• Konfigürasyon değişikliğinin kod deploy gerektirmemesi

İzlenecek metrikler (ve nedenleri)

Sıkıştırmayı hem performans hem güvenilirlik değişikliği olarak izleyin:

• CPU (sunucu ve mümkünse istemci)
• Gecikme yüzdeleri (p50/p95/p99) ve TTFB
• Yanıt boyutları: uç nokta başına ağ baytları ve sıkıştırılmış vs sıkıştırılmamış farkı
• Hata oranları: 4xx/5xx, istemci açma hataları, zaman aşmaları

Sorun giderme kontrol listesi

Bir şey bozulduğunda sık görülen nedenler:

• Çift sıkıştırma: upstream sıkıştırdı, gateway tekrar sıkıştırdı
• Yanlış başlıklar: Content-Encoding var ama gövde sıkıştırılmamış (veya tersi)
• Kötü müzakere: Accept-Encoding yok sayıldı veya istemcinin bildirmediği bir kodlama döndürüldü
• Bozulmuş akışlar: kesik gövdeler, yanlış Content-Length, proxy/CDN müdahalesi

İstemci beklentilerini dokümante edin

Desteklenen kodlamaları belgelerinizde net yazın, örneklerle:

• İstemcilerin göndermesi gereken: Accept-Encoding: zstd, br, gzip
• Alacakları: Content-Encoding: zstd (veya yedek)

SDK'lar gönderiyorsanız, küçük yapıştır-kullan açma örnekleri ekleyin ve Brotli veya Zstandard desteği için gereken minimum sürümleri belirtin.