Bir parser başlatıyorsunuz veya proxy üzerinden hesapları ısıtıyorsunuz, sayfa boyutuna göre harcamayı hesaplıyorsunuz — ve beklediğinizden 2-3 kat daha yüksek bir fatura alıyorsunuz. Sorun sağlayıcının sizi kandırmasında değil: trafik, kanaldan gerçekten geçen her şeyi içeriyor — istek başlıkları, TLS el sıkışması, bağlantı denemeleri ve kontrol paketleri. Trafik için "fatura" nın neye dayandığını ve kalite kaybı olmadan harcamayı nasıl azaltabileceğinizi inceliyoruz.
Sağlayıcı gerçekten trafiği ne olarak sayıyor
Harcamayı "göz kararı" ile değerlendirirken, genellikle aklınızda bir formül vardır: HTML sayfasının boyutu artı resimler. Ancak proxy sağlayıcısı, kanalın her iki yönünden geçen toplam veri hacmini hesaplar — çıkış (istek) ve giriş (yanıt). Bu hacme yalnızca faydalı yük değil, aynı zamanda tüm kontrol trafiği de dahildir: protokol başlıkları, TLS meta verileri, TCP ACK paketleri, zaman aşımında bağlantı denemeleri.
Normal bir sayfaya yapılan bir istek için "faydalı veriler" ile "kontrol verileri" arasındaki oran 80/20 olabilir. Ancak, yanıtların küçük olduğu (birkaç kilobayt JSON) ve başlıkların ve el sıkışmaların çok olduğu bir API ile çalışıyorsanız — oran kolayca tersine dönebilir. Bu nedenle, reklam API'lerine veya pazar yerlerine on binlerce küçük istek gönderen aracıların faturaları sık sık şaşırtıcı olur: her istek, faydalı yükün boyutuna bakılmaksızın sabit bir "vergi" taşır.
Bir diğer önemli nokta: sağlayıcı, trafiği proxy sunucusu seviyesinde hesaplar, yani IP üzerinden gerçekten geçen tüm trafiği — başarısız denemeleri, yönlendirmeleri, sayfadaki kaynakların (stil, script, izleyiciler) otomatik olarak talep edilmesini, sadece metin isteseniz bile.
HTTP/HTTPS başlıkları: her isteğin gizli ağırlığı
Her HTTP isteği ve her yanıt, User-Agent, Cookie, Accept-Language, Referer, Content-Type ve diğer birçok başlıktan oluşan bir set taşır. Modern tarayıcılarda ve anti-detect araçlarında (Dolphin Anty, AdsPower, Multilogin) başlık seti, bir istek için 500 bayttan 2-3 KB'ye kadar yer kaplayabilir — özellikle çerezlerde onca değerin biriktiği durumlarda.
Örnek: Eğer bir pazar yerinin API'sine 1.5 KB oturum çerezleri ile 10.000 istek yapıyorsanız, yalnızca başlıklar için yaklaşık 15 MB trafik harcayacaksınız — bu, yanıtın gövdesi hariç. Birkaç hesap ve profil ile ölçeklendiğinde bu rakam lineer olarak artar.
| Başlık Türü | Ortalama Boyut | Trafiğe Etkisi |
|---|---|---|
| User-Agent | 100-150 bayt | Düşük, ama ölçeklendikçe birikir |
| Cookie (oturum) | 500-2000 bayt | Uzun oturumlarda yüksek |
| Referer / Origin | 50-200 bayt | Düşük |
| Accept-* başlıkları | 150-300 bayt | Düşük |
| Sunucu yanıt başlıkları | 300-800 bayt | Orta, sizinle ilgili değil |
Pratik sonuç: Eğer Wildberries veya Ozon'da fiyat izleme için bir script yazıyorsanız, çerezleri kullanılmayan değerlerden temizleyin ve "her ihtimale karşı" DevTools tarayıcısından kopyalanmış gereksiz başlıkları isteğe dahil etmeyin.
TLS el sıkışması: şifreleme ne kadar trafik tüketiyor
Modern webin neredeyse tamamı HTTPS üzerinden çalışıyor, bu nedenle her yeni bağlantı bir TLS el sıkışması ile başlıyor — sertifika, şifreleme anahtarları ve protokol parametrelerinin değişimi. Bir tam TLS el sıkışması (TLS 1.2 veya 1.3) site sertifikasının boyutuna ve kullanılan protokol uzantılarına bağlı olarak 4 ile 8 KB arasında yer kaplar.
Her istek için yeni bir bağlantı açıyorsanız (ve sürekli bağlantı kullanmıyorsanız), TLS el sıkışması her seferinde tekrarlanır. 10.000 istek için bağlantıyı yeniden kullanmadan, yalnızca şifreleme için ek olarak 40-80 MB trafik alırsınız — bu, faydalı içeriğin kendisinden daha fazla olabilir.
TLS 1.3, daha az round-trip sayısı sayesinde TLS 1.2'ye göre biraz daha hafif, ancak fark, yalnızca çok sayıda bağlantı olduğunda hissedilir. Mobil proxyler için, operatörün kendi gecikmesini ve oturum yeniden kurma süreçlerini eklediği durumlarda, TLS yükü özellikle belirgin hale gelir — bu, sık kısa istekler için mobil proxy seçerken dikkate alınmalıdır.
Yeniden denemeler: tekrar eden istekler harcamayı nasıl iki katına çıkarıyor
Yeniden denemeler — trafiğin en görünmez ve en pahalı harcama kalemidir. Eğer parser'ınız veya scriptiniz zaman aşımı veya 429/503 hatası durumunda otomatik olarak yeniden denemeye ayarlandıysa, her başarısız istek, bağlantı kurma, TLS el sıkışması ve başlıklar için zaten trafik harcamıştır — ve ardından bu süreç yeniden tekrarlanır.
SMM otomasyonu ve pazar yerlerinde scraping yaparken sık yapılan bir hata — agresif yeniden deneme politikasıdır; script, IP'nin engellendiğinin ilk belirtisinde ardışık 5 deneme yapar. Sonuç olarak, bir "faydalı" yanıt için beş başarısız denemenin yanı sıra nihai başarılı isteğin trafiği harcanır.
Bu özellikle, Avito veya büyük pazar yerleri gibi agresif koruma sistemine sahip sitelerde veri merkezi proxyleri ile çalışırken kritik hale gelir; bu tür siteler, "sıcak" IP'lerden gelen çoğu isteğe CAPTCHA veya engelleme dönebilir. Bu durumda, rezidans proxylerine göz atmak mantıklı olabilir — bunlar, ilk istekte daha az engellenir, bu da yeniden deneme sayısını azaltır ve dolayısıyla gerçek trafik harcamasını düşürür.
Keep-Alive vs yeni bağlantılar
HTTP Keep-Alive, birden fazla istek için tek bir TCP/TLS bağlantısını yeniden kullanmanıza olanak tanır, böylece yeniden el sıkışmaktan kaçınılır. Bu, neredeyse tüm HTTP istemcilerinde ve anti-detect tarayıcılarında mevcut olan en etkili trafik optimizasyonlarından biridir.
Eğer sürekli bağlantı ile oturum belirtmeden scraping için kütüphaneler (requests, httpx, axios) kullanıyorsanız, her istek varsayılan olarak yeni bir TCP bağlantısı açabilir. Proxy ile birlikte bu, proxy sunucusuna yeni bir bağlantı, hedef siteye yeni bir TLS bağlantısı anlamına gelir ve tüm yük her çağrıda tekrar eder.
| Bağlantı Modu | 1000 istekteki Overhead |
|---|---|
| Her istek için yeni bağlantı | 4-8 MB (sadece TLS) |
| Keep-Alive, 50 istekte bir oturum | 0.1-0.2 MB (bir grup için bir el sıkışma) |
Fark kat kat — ve bu, isteklerin faydalı yükünde herhangi bir değişiklik olmadan saf trafik tasarrufu.
Farklı proxy türleri trafiği nasıl hesaplıyor
Trafik faturalandırma modeli, proxy türüne bağlıdır. Veri merkezi proxylerinde genellikle trafik hacmine veya IP/port sayısına göre faturalandırma yapılır — altyapı daha hızlıdır ve yönlendirme için minimum overhead ekler. Rezidans ve mobil proxylerde trafik genellikle daha sıkı bir şekilde faturalandırılır, çünkü gerçek kullanıcı IP'leri daha pahalı ve sınırlı bir kaynaktır ve operatör veya ev sağlayıcısı üzerinden geçen yol ek hoplar ekler ve dolayısıyla biraz daha fazla kontrol verisi ekler.
Mobil proxyler bu anlamda en "pahalı" olanlardır: mobil ağlar, oturum yeniden kurma, NAT çevirisi ve bazen operatör seviyesinde trafik sıkıştırma/aydınlatma gibi kendi mekanizmalarını ekler, bu da sabit bir ağ üzerinden aynı isteğe kıyasla geçen veri sayacını artırır.
Eğer görev, minimum overhead ile istikrarlı yüksek bir istek hacmi ise (örneğin, Wildberries veya Ozon'da toplu fiyat scraping), bunun için en iyi seçenek veri merkezi proxyleridir — bunlar daha hızlıdır ve benzer görevlerde trafik harcamasını daha öngörülebilir hale getirir.
Pratikte trafik harcamasını nasıl azaltabilirsiniz
Gerçek trafik harcamasını işlevsellik kaybı olmadan azaltan belirli adımları inceleyelim.
1. Gereksiz kaynakların yüklemesini kapatın. Eğer yalnızca sayfanın metnine veya API'nin JSON yanıtına ihtiyacınız varsa, görüntülerin, yazı tiplerinin, analiz scriptlerinin ve reklam izleyicilerinin yüklemesini anti-detect tarayıcı veya headless aracın ayarlarında kapatın. Bu, scraping görevleri için trafik harcamasını genellikle %60-80 oranında azaltır.
2. Keep-Alive ve bağlantı havuzu kullanın. HTTP istemcisini, bir ana makineye bir grup isteği için oturumu yeniden kullanacak şekilde ayarlayın — bu, TLS el sıkışması sayısını keskin bir şekilde azaltır.
3. Mantıklı bir yeniden deneme politikası ayarlayın. Üç deneme ile sınırlı, agresif 5-10 ardışık deneme yerine üssel gecikme (1sn → 2sn → 4sn) gereksiz isteklerden gelen trafiği azaltır ve aynı zamanda IP'nin ek bir engellenme riskini azaltır.
4. Çerezleri ve oturum başlıklarını temizleyin. Kullanılmayan çerez değerlerini periyodik olarak temizleyin — bu, özellikle Instagram veya TikTok'ta hesapları ısıtma için uzun oturumlar için önemlidir.
5. Statik yanıtları önbelleğe alın. Eğer veriler (örneğin, ürün kataloğu) her dakika değişmiyorsa, her izleme döngüsünde proxy üzerinden yeniden istek yapmak yerine yanıtı yerel olarak önbelleğe alın.
6. Sıkıştırma kullanın. Accept-Encoding: gzip başlığının gönderildiğinden ve sunucunun gerçekten sıkıştırılmış bir yanıt verdiğinden emin olun — bu, çok fazla metin veya JSON içeren sayfalarda gelen trafik hacmini azaltır.
Trafiği izleme araçları
Trafiğin gerçekten nereye gittiğini anlamak için, yalnızca sağlayıcının sayaçlarına değil, aynı zamanda isteklerin ayrıntılı dökümüne de bakmak faydalıdır. Bunun için uygun olanlar:
- Charles Proxy / Fiddler — her isteğin ve yanıtın boyutunu, başlıkları da dahil olmak üzere gösterir, bu da "ağır" çerezleri veya gereksiz kaynakları bulmaya yardımcı olur.
- Wireshark — gerçek el sıkışma ağırlığını değerlendirmek için TCP/TLS yükünü derinlemesine analiz etmek için kullanılır.
- Anti-detect tarayıcılardaki yerleşik trafik sayaçları (Dolphin Anty, AdsPower, GoLogin) — çoğu, her profil için ayrı ayrı harcamayı gösterir, bu da hesaplar arasında bütçeyi dağıtmak için uygundur.
- HTTP istemcisi seviyesinde günlükleme — kendi scraping scriptlerinizi yazarken, her çağrı için istek/yanıt boyutunu günlüklemek, anormallikleri bulmak için faydalıdır.
Araçlarınızın göstergelerini proxy sağlayıcısının sayacı ile karşılaştırmak, trafiğin nerede kaybolduğunu hızlı bir şekilde anlamanıza yardımcı olur — yeniden denemelerde, TLS'de veya gereksiz kaynakların yüklenmesinde.
Başlatmadan önce optimizasyon kontrol listesi
Büyük bir parser, SMM otomasyonu veya reklam hesaplarını ısıtma başlatmadan önce kısa bir listeyi kontrol edin:
- Gereksiz yerlerde görüntülerin, yazı tiplerinin, analizlerin yüklemesi kapatılmış;
- Bir ana makineye bir dizi istek için Keep-Alive / oturum yeniden kullanımı ayarlanmış;
- Yeniden deneme politikası, sonsuz tekrar yerine 2-3 deneme ile sınırlı;
- Oturum çerezleri, kullanılmayan değerlerden periyodik olarak temizleniyor;
- Yanıtların sıkıştırılması (gzip/deflate/br) etkinleştirilmiş;
- Tekrarlayan statik istekler için yerel önbellekleme mevcut;
- Proxy türü, göreve uygun olarak seçilmiş: hız ve hacim için veri merkezi, engellemeleri aşmak için rezidans, sosyal medya ve reklam platformları için mobil.
Sonuç
Proxy üzerinden trafik harcaması, yalnızca sayfanın faydalı verileri değil, aynı zamanda tüm kontrol yükü: başlıklar, TLS el sıkışmaları, hata durumlarında yeniden denemeler. Bu mekanizmayı anlamak, proxy bütçesini daha doğru bir şekilde planlamanıza ve özellikle pazar yerlerinde scraping, SMM otomasyonu veya reklam hesaplarını ısıtma sırasında hoş sürprizlerden kaçınmanıza yardımcı olur.
Eğer amacınız, öngörülebilir trafik harcaması ile istikrarlı bir scraping ise, veri merkezi proxylerine dikkat edin. Sosyal medya ve reklam platformları ile çalışırken, düşük engelleme sıklığı önemliyse, mobil proxyler daha iyi bir seçenek olacaktır. Eğer sitelerin koruma sistemlerini aşmak için anonimlik ve istikrar arasında bir denge arıyorsanız — daha az engelleme ile yeniden deneme sayısını azaltan rezidans proxylerine göz atın.