Sunucudan Sıkıştırılmış Yanıt Nasıl Alınır: Trafik Tasarrufu İçin Adım Adım Rehber

HTTP isteğindeki tek bir başlık, indirilen veri miktarını birkaç kat azaltabilir. Konu, istemci ile sunucu arasındaki sıkıştırma anlaşmasıdır. Proxy ile çalışıyor ve her gigabayt trafik için para ödüyorsanız, bu konu doğrudan faturanızı etkiler. Bu rehberde, sunucudan sıkıştırılmış yanıt almayı, kendi görevinizdeki gerçek tasarrufu nasıl ölçeceğinizi ve sizi bekleyen tuzakları ele alacağız.

Giriş: Tek Bir Başlık Trafiği Birkaç Kat Kısabilir

HTTP sıkıştırma şaşırtıcı derecede basit çalışır. İstemci sunucuya hangi sıkıştırma algoritmalarını anladığını bildirir. Sunucu uygun olanı seçer, yanıtın gövdesini sıkıştırır ve gönderir. İstemci verileri kendi tarafında açar. Sonuç olarak, ağ üzerinden orijinal HTML veya JSON yerine, genellikle üç ila beş kat daha az yer kaplayan sıkıştırılmış hali iletilir.

Sonunda ne elde edeceksiniz. Bu rehberi okuduktan sonra, istemci tarafında sıkıştırmayı etkinleştirebilecek, sunucunun gerçekten sıkıştırılmış yanıt verip vermediğini kontrol edebilecek, trafik tasarrufunu bayt cinsinden öncesi ve sonrası ölçebilecek ve sıkıştırmanın bazı nedenlerle çalışmadığı durumları teşhis edebileceksiniz. Tüm bunlar, Proxeon proxy üzerinden trafik gönderip gigabayt başına ödeme yaptığınızda kritik önem taşır.

Bu rehber kimler için. Materyal, geliştiriciler, veri kazıma uzmanları, otomasyon mühendisleri ve proxy üzerinden HTTP ile çalışan istemciler yazan herkes için tasarlanmıştır. Seviye orta düzeydir. Genel olarak trafik tüketiminin nelerden oluştuğunu ayrıntılı olarak incelemeyeceğiz. Buna ayrı bir makale ayrılmıştır. Burada kesinlikle sıkıştırmaya odaklanacağız.

Önceden bilmeniz gerekenler. HTTP isteği ve yanıtının ne olduğu, başlıkların ne olduğu ve terminalde bir komutun nasıl çalıştırılacağı konusunda temel bir anlayış yeterlidir. Daha önce curl ile bir istek yaptıysanız veya Python ya da Node.js'de bir betik yazdıysanız, zorlanmadan başarırsınız.

Ne kadar süre gerekir? Tüm örnekleri okumak ve tekrarlamak yaklaşık altmış dakikanızı alır. İlk pratik sonuçları, sıkıştırılmış ve sıkıştırılmamış yanıtın boyutunu kendi gözlerinizle karşılaştırdığınızda on dakika içinde göreceksiniz.

Ön Hazırlık

Başlamadan önce ihtiyacınız olan her şeye sahip olduğunuzdan emin olun. Bu, zamandan tasarruf sağlar ve yolun ortasında hatalardan kaçınmanızı sağlar.

Gerekli Araçlar

• curl sürüm 7.72 veya daha yenisi. 2026 derlemelerinde brotli ve zstd çoğu sistemde kutudan çıktığı gibi desteklenir.
• Python sürüm 3.10 veya daha yenisi ve yüklü requests kütüphanesi; ayrıca brotli için ek olarak brotli veya brotlicffi paketi.
• Node.js sürüm 18 veya daha yenisi. zlib modülü yerleşiktir ve gzip, deflate, brotli bilir.
• Her gün çalıştığınız koşullarda tasarrufu ölçmek istiyorsanız Proxeon proxy erişimi.
• Betik yazmak için herhangi bir metin editörü.

Sistem Gereksinimleri

Windows, macOS veya Linux gibi herhangi bir modern sistem yeterlidir. Tüm örnekler platformlar arasıdır. İki gigabayt RAM yeterlidir. İşlemci için özel bir gereksinim yoktur, ancak büyük hacimlerde maksimum seviyede brotli algoritması tek bir çekirdeği gözle görülür şekilde yükleyebilir.

Kurulacaklar ve Kontrol Edilecekler

1. Terminali açın ve curl sürümünü kontrol etmek için şu komutu çalıştırın:

   curl --version

2. Çıktının ilk satırına bakın. Sürüm belirtilir. Özellikler listesinde brotli ve mümkünse zstd bulunduğundan emin olun.
3. Python'ı şu komutla kontrol edin

   python --version

   ve bağımlılıkları kurun:

   pip install requests brotli

4. Node.js'i şu komutla kontrol edin

   node --version

İpucu: Sisteminizdeki curl brotli olmadan derlendiyse, işletim sisteminizin resmi paket yöneticisi aracılığıyla kurun. 2026 kurumsal derlemelerinde brotli neredeyse her zaman varsayılan olarak etkindir.

Yedekler. Bu rehberde üretim sunucularının yapılandırmasını değiştirmiyoruz veya canlı verilere dokunmuyoruz. Sadece istek gönderiyor ve yanıtları ölçüyoruz. Bu nedenle yedek gerekmez. Ancak daha sonra kendi web sunucunuzda sıkıştırmayı etkinleştirmeye karar verirseniz, düzenlemeden önce orijinal yapılandırma dosyasını mutlaka kaydedin.

✅ Kontrol: Her üç araç da sürüm kontrol komutuna yanıt verir ve bir numara gösterir. Hazırlık tamamlandı, devam edebiliriz.

Temel Kavramlar Basit Dille

Düğmelere basmadan önce terimleri anlayalım. Bu beş dakikanızı alır, ancak ileride kafa karışıklığını önler.

Sıkıştırma Anlaşması Nasıl Çalışır?

HTTP sıkıştırması üç başlığa dayanır. Rollerini anlamak çoğu sorunu çözer.

İstemcide Accept-Encoding. Bu, istemcinizin istekle birlikte gönderdiği başlıktır. İstemcinin açabileceği sıkıştırma algoritmalarını listeler. Örneğin,

Accept-Encoding: gzip, br, zstd

Yanıtta Content-Encoding. Bu, sunucunun kendi yanıtına eklediği başlıktır. Gövdenin hangi algoritmayla sıkıştırıldığını belirtir.

Content-Encoding: br

Sunucuda Vary. Vary başlığı, önbelleklere ve proxy'lere yanıtın isteğin belirli başlıklarına bağlı olduğunu söyler. Sıkıştırma için kritik değer

Vary: Accept-Encoding

Anlaşmanın Ana Fikri

Sırayı hatırlayın. İstemci Accept-Encoding ile ister. Sunucu karar verir ve Content-Encoding ile yanıt verir. Ara katmanlar Vary'ye göre yönlendirilir. Bu zincirin en az bir halkası bozuksa, sıkıştırılmamış bir yanıt alırsınız ve trafik için fazla ödersiniz.

İpucu: HTTP kütüphaneniz Accept-Encoding'i otomatik eklese bile, yanıtın gerçek başlığını her zaman kontrol edin. Otomasyon bazen sessizdir ve trafik akıp gider.

gzip, deflate, brotli, zstd: Algoritmaların Karşılaştırması

HTTP için dört yaygın sıkıştırma algoritması vardır. Sıkıştırma oranı ve işlemci yükü bakımından farklılık gösterirler. Her birini inceleyelim ve rakamları bir tabloya koyalım.

gzip

En eski ve en evrensel olanıdır. Her yerde desteklenir: her sunucu, her istemci, her proxy. Metin verilerinde orta düzeyde bir yük ile iyi bir sıkıştırma oranı sağlar. Ne seçeceğinizden emin değilseniz, gzip ile başlayın.

deflate

gzip'in yakın akrabasıdır, içeride aynı algoritmayı kullanır, ancak farklı bir sarmalayıcıyla. Pratikte daha az görülür ve bazen sunucularda hatalı uygulanır. Sıkıştırma oranı yaklaşık gzip ile aynıdır. deflate'i gzip yerine seçmek için özel bir neden yoktur.

brotli

Web için özel olarak geliştirilmiş modern bir algoritmadır. Metin verilerinde, özellikle HTML, CSS ve JSON'da gzip'ten belirgin şekilde daha iyi sıkıştırır. Bunun bedeli, maksimum seviyelerde sıkıştırma sırasında daha yüksek işlemci yüküdür. Açma hızlıdır. Başlıklarda br olarak gösterilir.

zstd

Esnek seviye ayarlarına sahip hızlı ve modern bir algoritmadır. Sıkıştırma oranı brotli seviyesindedir, ancak sıkıştırma hızı daha yüksektir. Web desteği artıyor, 2026 itibarıyla çoğu güncel sunucu ve istemci onu anlıyor. zstd olarak gösterilir.

Tipik Bir Metin Yanıtında Karşılaştırma Tablosu

Sıkıştırılmamış 1000 kilobaytlık bir JSON yanıtı varsayalım. Rakamlar yaklaşıktır, içeriğe bağlıdır, ancak büyüklük sırası doğru yansıtır.

• Sıkıştırma yok: 1000 KB, tasarruf yüzde 0, işlemci yükü minimum.
• gzip seviye 6: yaklaşık 190 KB, tasarruf yaklaşık yüzde 81, yük düşük.
• deflate seviye 6: yaklaşık 195 KB, tasarruf yaklaşık yüzde 80, yük düşük.
• brotli seviye 5: yaklaşık 165 KB, tasarruf yaklaşık yüzde 83, yük orta.
• brotli seviye 11: yaklaşık 140 KB, tasarruf yaklaşık yüzde 86, yük yüksek.
• zstd seviye 3: yaklaşık 175 KB, tasarruf yaklaşık yüzde 82, yük düşük.
• zstd seviye 19: yaklaşık 150 KB, tasarruf yaklaşık yüzde 85, yük orta.

Sonuç basittir. Metin verilerinde herhangi bir sıkıştırma trafiği yaklaşık beş kat azaltır. Algoritmalar arasındaki fark birkaç puan içindedir. Bu nedenle, proxy üzerinden trafik tasarrufu için önemli olan hangi algoritma olduğu değil, sıkıştırmanın açık olması gerçeğidir.

İpucu: Yalnızca veri indiriyor, göndermiyorsanız, işlemci yükünüz yalnızca açma işleminden gelir ve bu tüm algoritmalarda hızlıdır. Bu nedenle, sıkıştırma oranı en yüksek seçeneği rahatça isteyebilirsiniz.

✅ Kontrol: brotli ve zstd'nin metinde genellikle gzip'ten biraz daha verimli olduğunu, ancak gzip'in en uyumlu olduğunu anlıyorsunuz. Pratik için bu yeterlidir.

Adım 1: İstek Gönderin ve Yanıtın Sıkıştırılıp Sıkıştırılmadığını Görün

Bu aşamanın amacı. Content-Encoding başlıklarını ve gerçek gövde boyutunu görmeyi öğrenmek. Bu olmadan tasarrufu ölçmek imkansızdır.

curl ile Kontrol

1. Terminali açın.
2. Önce kaynağı sıkıştırmadan isteyerek orijinal boyutu öğrenin. Çalıştırın:

   curl -s -o /dev/null -w "%{size_download}" https://example.com/api/data

3. Sayıyı not alın. Bu, sıkıştırılmamış yanıtın bayt cinsinden boyutudur.
4. Şimdi sıkıştırma isteyin. --compressed bayrağı otomatik olarak Accept-Encoding ekler ve yanıtı açar:

   curl -s --compressed -o /dev/null -w "%{size_download}" https://example.com/api/data

5. İki sayıyı karşılaştırın. İkincisi, aynı içerikte belirgin şekilde daha küçük olmalıdır.

Önemli: curl'de --compressed kullanıldığında size_download göstergesi, zaten açılmış verinin boyutunu yansıtır, ağ üzerinden geçeni değil. Gerçek ağ hacmini görmek için yanıt başlığını ve ölçüm adımında bahsedeceğimiz ara ölçümleri kullanın.

Yanıt Başlıklarına Bakın

1. Başlıkları görüntüleme bayrağıyla istek yapın:

   curl -s -I --compressed https://example.com/api/data

2. Çıktıda Content-Encoding satırını bulun. Orada gzip, br veya zstd varsa, sunucu sıkıştırılmış yanıt göndermiştir.
3. Vary satırını bulun. İçinde Accept-Encoding olması, önbelleğe almanın doğru yapılandırıldığı anlamına gelir.

İpucu: İstediğiniz algoritmayı açıkça belirtmek için başlığı elle ekleyin:

curl -s -H "Accept-Encoding: br" -I https://example.com/api/data

Proxeon Proxy ile Çalışma

Gerçek koşullarda tasarrufu ölçmek için isteği proxy üzerinden yönlendirin. curl'de bu, -x bayrağıyla yapılır:

curl -s --compressed -x http://kullanıcı:şifre@proxeon_adresi:port -o /dev/null -w "%{size_download}" https://example.com/api/data

Böylece sıkıştırmanın proxy üzerinden geçip geçmediğini ve arada başlıkların kesilip kesilmediğini görürsünüz.

Beklenen sonuç. İki sayı görürsünüz: sıkıştırmasız boyut ve sıkıştırmalı boyut. Ve yanıtta Content-Encoding başlığını görürsünüz. Mekanizma çalışıyor demektir.

Olası sorun: Her iki sayı da aynıysa ve Content-Encoding yoksa, sunucu sıkıştırmayı vermemiştir. Nedenlerini ayrı bir bölümde ele alacağız.

✅ Kontrol: --compressed bayrağıyla yanıtta Content-Encoding satırı algoritmalardan biriyle mevcut. Adım tamamlandı.

Adım 2: Python'da Gerçek Tasarrufu Ölçün

Bu aşamanın amacı. Görevinize uygulayabileceğiniz çalışan bir betikle sıkıştırma öncesi ve sonrası ağ trafiğinin kesin rakamlarını elde etmek.

requests ile Basit Ölçüm

requests kütüphanesi varsayılan olarak Accept-Encoding'i ekler ve yanıtı açar. Ağ boyutunu tam olarak ölçmek için, açılmadan önceki ham içeriğin uzunluğuna bakarız.

1. measure.py dosyasını oluşturun.
2. Aşağıdaki kodu yapıştırın:

import requests
url = "https://example.com/api/data"
# Sıkıştırmasız istek
r_plain = requests.get(url, headers={"Accept-Encoding": "identity"})
size_plain = len(r_plain.content)
# Sıkıştırmalı istek
r_comp = requests.get(url, headers={"Accept-Encoding": "gzip, br, zstd"})
encoding = r_comp.headers.get("Content-Encoding", "yok")
size_wire = int(r_comp.headers.get("Content-Length", 0))
size_body = len(r_comp.content)
print("Sıkıştırmasız, bayt:", size_plain)
print("Sıkıştırma algoritması:", encoding)
print("Ağ üzerinden yaklaşık, bayt:", size_wire)
print("Açıldıktan sonra, bayt:", size_body)
if size_plain and size_wire:
saved = 100 - size_wire * 100 
print("Trafik tasarrufu, yüzde:", saved)

Dikkat: Content-Length değeri her zaman mevcut değildir, özellikle parçalı (chunked) aktarımda. Yoksa aşağıdaki daha doğru yöntemi kullanın.

Ağ Hacminin Hassas Ölçümü

Ağ üzerinden geçeni tam olarak ölçmek için otomatik açmayı kapatın ve ham akışın baytlarını sayın.

import requests
url = "https://example.com/api/data"
sess = requests.Session()
# Ham boyutu görmek için otomatik açmayı kapatın
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, stream=True)
raw_bytes = 0
for chunk in r.raw.stream(8192, decode_content=False):
raw_bytes += len(chunk)
print("Algoritma:", r.headers.get("Content-Encoding", "yok"))
print("Ağ üzerinden ham bayt:", raw_bytes)

raw_bytes'ı sıkıştırılmamış isteğin boyutuyla karşılaştırın. Fark, gerçek tasarrufunuzdur.

Proxeon Proxy ile Ölçüm

Gerçek koşullarda rakamları almak için proxies parametresini ekleyin:

proxies = {
"http": "http://kullanıcı:şifre@proxeon_adresi:port",
"https": &"http://kullanıcı:şifre@proxeon_adresi:port",
}
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, proxies=proxies, stream=True)

İpucu: Ölçümü birkaç kez yapın ve ortalamasını alın. Dinamik yanıtlar boyut olarak değişir, bu nedenle tek bir ölçüm yanıltıcı olabilir.

Beklenen sonuç. Betik, sıkıştırma algoritmasını ve sıkıştırılmamış yanıtın boyutundan daha küçük olan ham bayt sayısını yazdırır. Metin kaynağında tasarruf yüzde yetmiş ve üzeriyse, her şey doğru çalışıyor demektir.

✅ Kontrol: Çıktıda algoritma "yok" kelimesine eşit değil ve ham baytlar sıkıştırmasız baytlardan az. Harika.

Adım 3: Aynı Ölçümü Node.js'de Yapın

Bu aşamanın amacı. Node'da istemci yazanlar için JavaScript'te çalışan bir ölçüm aracı elde etmek.

Ham Akış Ölçümü

1. measure.js dosyasını oluşturun.
2. Açmadan önceki baytları sayan kodu yapıştırın:

const https = require('https');
const url = 'https://example.com/api/data';
function measure(acceptEncoding) {
 return new Promise((resolve) => {
const req = https.get(url, { headers: { 'Accept-Encoding': acceptEncoding } }, (res) => {
 let bytes = 0;
 res.on('data', (chunk) => { bytes += chunk.length; });
 res.on('end', () => {
resolve({ enc: res.headers['content-encoding'] || 'yok', bytes });
 });
});
req.end();
 });
}
(async () => {
 const plain = await measure('identity');
 const comp = await measure('gzip, br, zstd');
 console.log('Sıkıştırmasız, bayt:', plain.bytes);
 console.log('Algoritma:', comp.enc);
 console.log('Ağ üzerinden sıkıştırılmış, bayt:', comp.bytes);
 const saved = Math.round(100 - (comp.bytes * 100) / plain.bytes);
 console.log('Tasarruf, yüzde:', saved);
})();

Önemli: Bu örnekte res'ten ham akışı okuyoruz ve zlib'i bağlamıyoruz. Bu nedenle, bytes sayacı tam olarak ağ hacmini gösterir. Bu, proxy sağlayıcısına ödediğiniz şeydir.

Node'da Elle Açma

İçeriği de okumanız gerekiyorsa, akışı yerleşik zlib modülüyle açın:

const zlib = require('zlib');
let stream = res;
const enc = res.headers['content-encoding'];
if (enc === 'gzip') stream = res.pipe(zlib.createGunzip());
else if (enc === 'br') stream = res.pipe(zlib.createBrotliDecompress());
else if (enc === 'deflate') stream = res.pipe(zlib.createInflate());

İpucu: zstd için güncel Node.js sürümlerinde zlib.createZstdDecompress vardır. Sürümünüz içermiyorsa, Node'u güncelleyin veya ayrı bir npm paketi kullanın.

Beklenen sonuç. Node, Python ve curl'de aldığınızla karşılaştırılabilir bir tasarruf yüzdesi yazdırır.

✅ Kontrol: Üç araç da yakın tasarruf rakamları verir. Ölçümleriniz doğru demektir.

Adım 4: Yanıt Neden Sıkıştırılmamış Geliyor?

Bu aşamanın amacı. Sıkıştırmanın neden çalışmadığını teşhis etmeyi ve nedeni gidermeyi öğrenmek. Pratikte en sık karşılaşılan sorundur.

Birinci Durum: İstemci İstemedi

En yaygın neden. HTTP istemciniz Accept-Encoding başlığını göndermedi ve sunucu dürüstçe sıkıştırılmamış yanıtı verdi. Bu, başlıkları elle oluşturup sıkıştırmayı unuttuğunuzda veya düşük seviyeli soket kullandığınızda olur.

1. Sunucuya tam olarak ne gittiğini kontrol edin. curl'de -v bayrağını ekleyin ve giden başlıklarda Accept-Encoding satırını bulun.
2. Satır yoksa, -H veya --compressed bayrağıyla açıkça ekleyin.
3. Python'da başlığı boş bir değerle geçersiz kılmadığınızdan emin olun.

Dikkat: Bazı kütüphaneler herhangi bir başlığı elle ayarladığınızda varsayılan değerlerini eklemeyi bırakır. User-Agent'ı elle ayarlıyorsanız, Accept-Encoding'in de kaybolmadığını kontrol edin.

İkinci Durum: Sunucu Bilmiyor

Sunucu sıkıştırmayı hiç desteklemeyebilir veya istenen algoritmayı desteklemeyebilir. Bu durumda, standarda göre kabul edilebilir olan sıkıştırılmamış yanıtı verir.

1. Farklı algoritmaları sırayla isteyin: önce gzip, sonra br, sonra zstd.
2. Hangisinde yanıtta Content-Encoding göründüğüne bakın.
3. Hiçbirinde yoksa, sunucu sıkıştırma vermiyor demektir. Yabancı bir sunucuda bunu değiştiremezsiniz, ancak varsa başka bir uç nokta veya API seçebilirsiniz.

İpucu: Birçok API, yalnızca belirli bir boyutun üzerindeki yanıtlar için sıkıştırma verir. Küçük yanıtları sunucular genellikle bilerek sıkıştırmaz çünkü sıkıştırma ek yükü faydadan fazladır.

Üçüncü Durum: Aracı Başlığı Kesti

Sizinle sunucu arasında önbellekleme düğümü, ağ geçidi veya proxy olabilir ve sıkıştırma başlıklarını kaldırabilir veya değiştirebilir. Bazen aracı, kendi ihtiyaçları için yanıtı açar ve size zaten açılmış haliyle verir.

1. Doğrudan ve proxy üzerinden istek yapın ve Content-Encoding başlıklarını karşılaştırın.
2. Doğrudan sıkıştırma varsa, proxy üzerinden yoksa aracı müdahale ediyor demektir.
3. Proxeon proxy ile çalışırken sıkıştırma şeffaf olarak iletilir, bu nedenle fark görürseniz sorunu hedef sunucuda veya CDN'sinde arayın.

Beklenen sonuç. Sıkıştırmanın üç halkadan hangisinde kaybolduğunu tam olarak bilirsiniz ve ne yapacağınızı anlarsınız.

✅ Kontrol: Belirli bir yanıtın neden sıkıştırılmamış geldiğini tek cümleyle açıklayabilirsiniz. Teşhis öğrenildi.

Adım 5: Sıkıştırmayla Çalışırken Tuzaklar

Bu aşamanın amacı. Verileri bozan veya ölçümleri çarpıtan ince hatalardan kaçınmak.

Çift Sıkıştırma

Bazen içerik uygulama seviyesinde zaten sıkıştırılmıştır ve sunucu tekrar sıkıştırır. Ya da tam tersi: istek gövdesini siz sıkıştırırsınız ve proxy veya kütüphane bunu tekrar yapar. Çift sıkıştırma neredeyse hiç kazanç sağlamaz, hatta bazen boyutu artırır ve kesinlikle işlemciyi boşa yorar.

1. Yanıtta Content-Encoding'de aynı anda iki değer olup olmadığını kontrol edin, örneğin br içinde gzip.
2. Kütüphanenin otomatik sıkıştıracağını elle sıkıştırmayın.
3. Kodlama zinciri görürseniz, ters sırayla açın.

Bozuk Akış

Bağlantı kopması veya aracı hatası, sıkıştırılmış akışın eksik gelmesine neden olabilir. Açarken hata veya kesilmiş veri alırsınız.

1. Açma işlemini her zaman hata işleme ile sarın.
2. Açma hatasında isteği tekrarlayın, bozuk veriyi okumaya çalışmayın.
3. Belirtilmişse, gerçek boyutu Content-Length ile karşılaştırın.

Dikkat: Kısmen açılmış verileri asla sonuç olarak kaydetmeyin. Bozuk JSON gerçekçi görünür, ancak boru hattının devamında gizli hatalara yol açar.

Kütüphane Yapmıyorsa Elle Açma

Hassas ölçüm için otomatik açmayı kapattıysanız veya düşük seviyeli bir istemci kullanıyorsanız, açmayı elle yapmanız gerekir. Python'da örnek:

import gzip, brotli, zlib
def decompress(data, encoding):
if encoding == "gzip":
return gzip.decompress(data)
if encoding == "br":
return brotli.decompress(data)
if encoding == "deflate":
return zlib.decompress(data)
return data

İpucu: deflate açma hata verirse, zlib.decompress'ı eksi on beşe eşit wbits parametresiyle çağırmayı deneyin. Bazı sunucular zlib sarmalayıcısı olmadan saf deflate verir.

Beklenen sonuç. Desteklenen formatlardan herhangi birini elle açabilir ve akış hatalarını doğru şekilde işleyebilirsiniz.

✅ Kontrol: Betiğiniz bozuk bir yanıtta çökmez, isteği tekrarlar. Dayanıklılık sağlandı.

Adım 6: Sıkıştırmanın Anlamsız Olduğu Durumlar

Bu aşamanın amacı. Zaten sıkıştırılmış olanı sıkıştırmak için işlemci ve zaman harcamamak. Bu, trafik faydası kaybetmeden kaynak tasarrufu sağlar.

Zaten Sıkıştırılmış Formatlar

Bazı veriler, içinde zaten sıkıştırma kullanan formatlarda saklanır. Bunları tekrar sıkıştırmaya çalışmak anlamsızdır: kazanç yüzde birin kesirleri kadar olur ve işlemci boşuna yorulur.

• Görseller: JPEG, PNG, WebP, AVIF kendi formatlarının içinde zaten sıkıştırılmıştır.
• Video: MP4, WebM, MKV yüksek oranda sıkıştırılmış video akışı içerir.
• Ses: MP3, AAC, OGG doğaları gereği sıkıştırılmıştır.
• Arşivler: ZIP, RAR, 7z, gz zaten sıkıştırılmış kaplardır.

Bu kaynaklar için Accept-Encoding gövdede tasarruf sağlamaz. Ayrıca, sunucular genellikle MIME türü listesine göre yapılandırıldıkları için bunları zaten tekrar sıkıştırmaz.

Sıkıştırmanın Anlamlı Olduğu Durumlar

• HTML, CSS, JavaScript.
• JSON ve XML API yanıtları.
• Düz metin, CSV, günlükler.
• SVG, çünkü aslında metindir.

İpucu: Ağırlıklı olarak medya dosyaları indiriyorsanız, sıkıştırmadan elde edilecek tasarruf sıfıra yakın olacaktır. Burada kazancı sağlayan şey, sıkıştırma değil, yalnızca ihtiyaç duyulan boyutları ve formatları istemektir. Ancak bu, sıkıştırma değil, trafik yönetimi konusudur.

Beklenen sonuç. İkili formatları sıkıştırmak için kaynak harcamazsınız ve sıkıştırmayı yalnızca gerçekten yardımcı olduğu yerde kullanırsınız.

✅ Kontrol: Belirli bir yanıt türünü sıkıştırmanın gerekli olup olmadığına bir saniyede karar verebilirsiniz. Anlayış oluştu.

Sonucu Kontrol Etme

Her şeyi doğru yapılandırdığınızdan emin olmanın zamanı geldi. Kontrol listesinden geçin.

Çalışma Kontrol Listesi

1. İstemciniz gerekli algoritmalarla Accept-Encoding başlığını gönderiyor.
2. Metin kaynaklarında yanıtta bu algoritmalardan biriyle Content-Encoding mevcut.
3. Ölçüm betiği, metin için ağ hacminin sıkıştırmasız halinden en az yüzde yetmiş daha az olduğunu gösteriyor.
4. Proxeon proxy üzerinden sıkıştırma korunuyor, rakamlar doğrudan istekle eşleşiyor.
5. Açma hata vermiyor ve veriler doğru okunuyor.
6. İkili formatları sıkıştırmaya çalışmıyorsunuz.

Nasıl Test Edilir

1. Üç farklı uç nokta alın: biri JSON, biri HTML, biri görsel içeren.
2. Her birini ölçüm betiğinizle çalıştırın.
3. İlk ikisinde tasarrufun yüksek olduğundan, üçüncüsünde sıfıra yakın olduğundan emin olun.

Başarı göstergeleri. Metin API'si için tutarlı olarak yüzde yetmiş ila doksan arasında tasarruf görürsünüz. Medya için tasarruf minimumdur ve bu normaldir. Proxy üzerinden rakamlar kötüleşmez.

✅ Kontrol: Kontrol listesinin altı maddesi de tamamlandı. Sıkıştırma doğru yapılandırıldı ve ölçüldü.

Tipik Hatalar ve Çözümleri

Aşağıda sık karşılaşılan sorunlar, sorun, neden, çözüm formatında toplanmıştır.

Yanıt, Accept-Encoding gönderilmesine rağmen sıkıştırılmıyor

Neden: Sunucu bu içerik türü veya bu boyuttaki yanıtlar için sıkıştırmayı desteklemiyor. Çözüm: Farklı bir algoritma deneyin ve kaynağın metin ve yeterince büyük olduğundan emin olun.

curl'de tasarruf görünmüyor, size_download değişmiyor

Neden: --compressed bayrağı açılmış boyutu gösterir. Çözüm: Ağ hacmini, Python ve Node adımlarındaki gibi otomatik açma olmadan ayrı bir betikle ölçün.

Kütüphane metin yerine çöp veriyor

Neden: Otomatik açmayı kapattınız, ancak akışı elle açmadınız. Çözüm: Content-Encoding'i belirleyin ve ilgili açma işlevini uygulayın.

defalte açarken hata

Neden: Sunucu sarmalayıcı olmadan saf deflate verdi. Çözüm: Açmayı eksi on beş wbits parametresiyle çağırın.

Proxy üzerinden sıkıştırma kayboluyor

Neden: Yolda, genellikle hedef sitenin CDN'si olan ve başlıkları değiştiren bir düğüm var. Çözüm: Doğrudan ve proxy'li isteği karşılaştırın ve halkayı belirleyin. Proxeon proxy başlıkları şeffaf olarak iletir, bu nedenle sorun genellikle sunucu tarafındadır.

Tekrarlanan ölçümlerde farklı yanıt boyutu

Neden: İçerik dinamiktir ve istekten isteğe değişir. Çözüm: Birden fazla ölçümün ortalamasını alın ve aynı istek parametrelerinde karşılaştırın.

Content-Length yok

Neden: Parçalı (chunked) aktarım uzunluğu önceden belirtmez. Çözüm: Betik örneklerinde olduğu gibi, akışı okurken baytları elle sayın.

Çift sıkıştırma işlemciyi şişiriyor

Neden: İçerik farklı seviyelerde iki kez sıkıştırılıyor. Çözüm: Kütüphanenin veya sunucunun yaptığı yerde elle sıkıştırmayı kaldırın.

Ek Olanaklar

Temel senaryoyu öğrendikten sonra geliştirilecek yerler var.

Algoritma Önceliği Seçimi

Accept-Encoding başlığında q-değerleriyle ağırlık belirtebilir, sunucuya tercihlerinizi söyleyebilirsiniz. Örneğin

Accept-Encoding: zstd;q=1.0, br;q=0.9, gzip;q=0.8

Açılmış Verileri Önbellekleme

Aynı kaynağa birden çok kez erişiyorsanız, açılmış sonucu kendi tarafınızda önbellekleyin. Bu hem trafiği hem de tekrar açmanın işlemci yükünü azaltır.

URL Listesi Üzerinde Toplu Ölçüm

Ölçüm betiğini uç nokta listesi üzerinde bir döngüye sarın ve bir tasarruf tablosu oluşturun. Böylece projenizdeki en ağır sıkıştırılmamış yanıtları bulur ve önce onlarla ilgilenirsiniz.

İpucu: Günlük tasarrufu bayt cinsinden bir günlük tutun. Gigabayt fiyatıyla çarptığınızda, proxy üzerinden çalışırken sıkıştırmanın somut parasal faydasını görürsünüz.

✅ Kontrol: Betiğin tek çalıştırmasıyla birden fazla kaynak için özet bir tasarruf tablosu toplayabilirsiniz.

SSS

Her zaman gzip yerine brotli mi istemeliyim?

Yalnızca indiriyorsanız, tüm algoritmalarda açma hızlıdır, bu nedenle en etkili olanı isteyebilirsiniz. Pratikte Accept-Encoding'e üçünü de ekleyin: gzip, br, zstd. Sunucu mevcut en iyisini seçer.

Metin API'sinde sıkıştırma ne kadar trafik tasarrufu sağlar?

Genellikle yüzde yetmiş ila doksan arası. Yani bir gigabayt ağırlığındaki yanıt, ağ üzerinden yüz elli veya iki yüz megabayt olarak geçer. Gigabayt başına ödeme yaparken tasarruf doğrudan ve belirgindir.

Sıkıştırma yanıt hızını etkiler mi?

Daha az veri, özellikle yavaş kanallarda daha hızlı iletilir. Sunucudaki sıkıştırma gecikmesi, iletim süresindeki kısalma ile genellikle fazlasıyla telafi edilir.

curl neden sıkıştırma bayrağıyla aynı boyutu gösteriyor?

Çünkü --compressed, açılmış gövdenin boyutunu gösterir. Gerçek ağ hacmi daha azdır. Ham akışı ayrı bir betikle ölçün.

POST isteğinin gövdesi sıkıştırılabilir mi?

Evet, istemci istekte Content-Encoding ayarlar, ancak sunucunun onu açabilmesi gerekir. Tüm sunucular bunu desteklemez, bu nedenle API belgelerini kontrol edin.

Sıkıştırma Proxeon proxy ile çalışıyor mu?

Evet. Proxy, Accept-Encoding ve Content-Encoding başlıklarını şeffaf olarak iletir, bu nedenle tüm tasarruf korunur. Bu yüzden, gerçek koşullarda doğrudan proxy üzerinden ölçmek avantajlıdır.

Sunucu sıkıştırma vermezse ne yapmalıyım?

Sıkıştırma istediğinizden ve kaynağın metin olduğundan emin olun. Sunucu hâlâ vermiyorsa, yabancı bir sunucuyu değiştiremezsiniz, ancak başka bir uç nokta seçebilir veya verileri kendi önbellek katmanınızda sıkıştırabilirsiniz.

Accept-Encoding ile görselleri sıkıştırmalı mıyım?

Hayır. JPEG ve WebP gibi formatlar zaten sıkıştırılmıştır. Ek sıkıştırma kazanç sağlamaz ve yalnızca işlemciyi yorar.

zstd ve brotli arasında nasıl seçim yapmalıyım?

İndirme için trafik farkı birkaç puan içindedir. İkisini de Accept-Encoding'e ekleyin ve sunucunun karar vermesine izin verin. Sunucu yalnızca birini destekliyorsa, onu alırsınız.

İstemci tarafında Vary gerekli mi?

İstemci olarak Vary'yi siz ayarlamazsınız, onu sunucu koyar. Ancak anlamak faydalıdır: önbelleğin neden bazen sıkıştırılmış, bazen sıkıştırılmamış bir sürüm verdiğini açıklar.

Sonuç

Teoriden çalışan ölçümlere kadar bir yol kat ettiniz. Artık sıkıştırmanın Accept-Encoding, Content-Encoding ve Vary üzerinden nasıl anlaşıldığını anlıyorsunuz. curl, Python ve Node.js'de sıkıştırma istemeyi ve en önemlisi öncesi ve sonrası gerçek ağ hacmini ölçmeyi biliyorsunuz. Yanıtın neden bazen sıkıştırılmamış geldiğini ve üç tipik nedeni nasıl teşhis edeceğinizi biliyorsunuz. Çift sıkıştırma, bozuk akış ve elle açma gibi tuzakları çözdünüz. Ve artık görselleri, videoları ve arşivleri sıkıştırmak için kaynak harcamıyorsunuz.

Şimdi ne yapmalısınız. Ölçüm betiğini projenizin tüm ana uç noktalarında çalıştırın. Sıkıştırmanın açık olmadığı yerleri bulun ve açıkça isteyin. Proxeon proxy ile çalışırken parasal faydayı görmek için tasarruf edilen baytların bir günlüğünü tutun. Temel senaryoyu öğrendikten sonra, URL listesi üzerinde toplu ölçüme ve q-değerleriyle algoritma önceliklerine geçin.

Sıkıştırma, trafik faturasını azaltmanın en ucuz yollarından biridir. Doğru gönderilen tek bir başlık, veri hacmini birkaç kat azaltabilir. Artık bu araç sizin elinizde ve onu bilinçli ve kesin rakamlarla uygulayabilirsiniz.