Proxy Bant Genişliği Azaltma: Daha Az GB ile Aynı Veri

Proxy bant genişliği azaltma, GB bazlı bir rotating proxy ürününde aynı veriyi daha az baytla toplamak demektir ve işe nereye harcadığınızı bilmekle başlar. Gateway, üzerinden geçen her baytı sayar: gönderdiğiniz istek başlıkları, hedefin döndürdüğü yanıt gövdesi, TLS el sıkışması ve tünel kurulumu dahil. Siz yalnız HTML’deki fiyat alanını istiyor olsanız da ölçülen şey hedefin size gönderdiği her şeydir.

Bir ürün sayfasını tarayıcıyla açtığınızda HTML yanıtın küçük bir parçasıdır. Görseller, yazı tipleri, stil dosyaları, betikler, üçüncü taraf izleme kodları, sohbet eklentisi ve bazen otomatik oynayan bir video da aynı tünelden geçer. Bir örnek varsayım: HTML 150 KB, görseller 2 MB, betik ve stil 600 KB, yazı tipleri 200 KB olsun. Tarayıcı bu sayfayı yaklaşık 3 MB’ye yükler; düz bir HTTP isteği 150 KB çeker. Aynı veriyi almak için yirmi kat fark vardır ve bu fark doğrudan kotadan düşer.

İkinci büyük kalem tekrarlardır. Zaman aşımına uğrayıp yeniden denenen istek, yönlendirme zincirindeki her ara sayfa, aynı çalışmada iki kez ziyaret edilen URL ve değişmediği halde her saat yeniden indirilen liste sayfası, tek sayfalık işi birkaç sayfalık trafiğe çevirir. Üçüncü kalem başlıklardır: her istek kendi başlığını taşır, çerezler büyüdükçe bu kalem büyür. Yüz bin istekte istek başına bir kilobaytlık başlık varsayımıyla 100 MB eder; küçük bir pay, ama büyük çalışmalarda hesaba girer.

En büyük tasarruf, tarayıcıyı yalnız gerçekten gereken yerde kullanmaktır. Aradığınız veri sunucudan gelen HTML’in içindeyse düz bir HTTP istemcisi hem daha az bayt çeker hem daha hızlıdır. Sayfanın tarayıcısız açılıp açılmadığını anlamanın yolu, aynı URL’yi bir komut satırı istemcisiyle çekip yanıtta aradığınız alanı aramaktır; alan oradaysa tarayıcıya gerek yoktur. Scrapy ile Playwright’ı birlikte kuran rehberde bu ayrımın kurulum tarafı anlatılıyor.

Birçok modern sayfa HTML’i boş bir iskelet olarak gönderir ve veriyi sayfa açıldıktan sonra kendi arka uç adresinden JSON olarak çeker. Tarayıcının geliştirici araçlarındaki Ağ sekmesinde XHR ya da fetch türündeki istekleri süzdüğünüzde bu adresi görürsünüz. Aynı adrese doğrudan istek atmak, yalnız veriyi getirir, sayfanın yüklediği geri kalan her şey dışarıda kalır; yanıt çoğu zaman HTML’den de küçüktür ve ayrıştırması kolaydır.

Bu yöntemin sınırı açıktır: yalnız sayfanın herkese açık biçimde ve oturum açmadan yüklediği uç noktalar kullanılır. Giriş gerektiren, yetki anahtarı isteyen ya da hedefin kullanım koşullarında yasakladığı bir uç nokta bu yazının kapsamı dışındadır. Uç nokta sayfa sürümüyle birlikte değişebileceği için yanıt şemasını her çalışmada doğrulamak gerekir; bir alan kaybolduğunda bunu fark etmeyen scraper, aynı GB’yi harcayıp boş sonuç üretir.

Tarayıcı zorunluysa trafiği kesmenin yolu isteklerin tarayıcıdan hiç çıkmamasıdır. Playwright’ta bir yol kaydı tanımlayıp her isteğin kaynak türüne bakılır: tür görsel, medya, yazı tipi ya da stil dosyasıysa istek iptal edilir, değilse devam eder. İptal edilen istek proxy’ye ulaşmaz, dolayısıyla sayılmaz. Puppeteer’da aynı iş istek kesmeyi açıp her istekte kaynak türüne göre iptal ya da devam kararı vermekle yapılır. İki araçta da kaynak türü tarayıcının kendi sınıflamasından gelir; adres uzantısına bakmak gerekmez.

Hangi türlerin güvenle engellenebileceği hedefe bağlıdır. Görseller ve medya neredeyse her zaman engellenebilir; görselin kendisi değil adresi gerekiyorsa adres zaten HTML’deki öznitelikte durur. Yazı tipleri de güvenlidir. Stil dosyaları çoğu zaman engellenebilir, ama bazı sayfalar bir ögenin görünürlüğünü stile göre hesaplayan betikler çalıştırır; stil gelmeyince betik ögeyi gizli sanıp veriyi yüklemeyebilir. Bu yüzden stil engellemesini bir hedefte açmadan önce engelli ve engelsiz iki çalıştırmanın sonucunu karşılaştırmak gerekir.

Üçüncü taraf alan adları ayrı bir kalemdir: izleme kodları, reklam ağları, sohbet eklentileri ve analitik betikleri sayfanın verisine katkı vermez. Yalnız hedefin kendi alan adından gelen isteklere izin verip gerisini iptal etmek, görsel engellemesinin üstüne ikinci bir kesinti sağlar. Bir yan etki: Puppeteer’da istek kesmeyi açmak tarayıcı önbelleğini devre dışı bırakır; aynı tarayıcı oturumunda birçok sayfa dolaşıyorsanız ortak betik ve stil dosyaları her sayfada yeniden iner. Bu bedel çoğu zaman görsel tasarrufunun yanında küçüktür, ama ölçmeden varsaymayın.

Metin yanıtları sıkıştırılmış gelirse ölçülen bayt sayısı düşer. Tarayıcılar ve çoğu HTTP kütüphanesi kabul ettiği sıkıştırma biçimlerini kendiliğinden bildirir; komut satırındaki curl ise yalnız ilgili bayrak verilirse bildirir. Yanıt başlıklarında içerik kodlaması alanını görmüyorsanız ya istemciniz sıkıştırma istememiştir ya da sunucu uygulamamıştır. Birinci durum sizin elinizdedir ve HTML için birkaç kat fark yaratır.

Koşullu istek, sunucuya “bu sayfanın elimdeki sürümü şu, değiştiyse gönder” demektir. Sunucu yanıtla birlikte bir sürüm etiketi ya da son değişiklik tarihi vermişse, bir sonraki istekte bu değeri eşleşmeme ya da değişiklik koşulu başlığında geri gönderirsiniz; sayfa değişmemişse sunucu gövdesiz, 304 koduyla cevap verir ve tünelden yalnız başlıklar geçer. Her sunucu bunu desteklemez ve dinamik sayfalarda etiket her istekte değişebilir; destekleyip desteklemediğini aynı sayfaya iki ardışık koşullu istek atıp ikincisinin koduna bakarak anlarsınız.

Koşullu isteğin desteklenmediği yerde iki ara yol kalır. HEAD isteği yalnız başlıkları getirir; içerik uzunluğu ya da son değişiklik alanı önceki çalışmadakiyle aynıysa gövdeyi hiç çekmezsiniz. Her sunucu HEAD’e doğru cevap vermez, ama verdiğinde listeleme sayfaları için ucuz bir kapı bekçisidir. Aralık isteği ise sayfanın yalnız ilk bölümünü ister; aradığınız veri sayfa başındaki yapılandırılmış veri bloğundaysa ve sunucu aralığı kabul ediyorsa 206 koduyla yalnız o parça gelir. İkisi de bir denemeyle doğrulanır, varsayılarak kullanılmaz.

Yerel önbellek bu yöntemlerin tamamlayıcısıdır: sayfanın bir önceki gövdesinin özetini saklayıp yeni gövdeyle karşılaştırmak işlem tasarrufu sağlar ama GB tasarrufu sağlamaz, çünkü gövde zaten inmiştir. GB’yi düşüren tek şey indirmemektir; önbellek, hangi sayfanın ne sıklıkla değiştiğini ölçüp tarama aralığını ona göre seyreltmek için kullanılır.

Yeniden denemeler GB tüketir, çünkü başarısız isteğin inen kısmı da sayılmıştır. Zaman aşımına uğrayan bir istekte gövdenin yarısı gelmiş olabilir; yeniden denediğinizde aynı sayfa için bir buçuk sayfa ödersiniz. Bu yüzden yeniden denemeyi kaldırmak yerine hangi hatanın yeniden deneneceğini daraltmak gerekir: hedefin 404 ya da sabit bir 500 döndürdüğü istek üç kez tekrarlanırsa üç kez ödenir ve sonuç değişmez. Retry ve backoff rehberinde yeniden denenebilir hata tablosu bu ayrımı veriyor.

Yönlendirme zincirleri sessiz bir kalemdir. HTTP’den HTTPS’e, www’suzdan www’luya, eski kategori adresinden yeniye giden her adım kendi başlık turunu ve bazen küçük bir gövdeyi tüketir. Başlangıç URL listenizi tek bir ön çalıştırmada son adrese çevirip saklamak, her çalışmada aynı zinciri yeniden yürümeyi önler. Aynı mantık sayfalama için geçerlidir: liste sayfalarını baştan sona gezerken yeni öge gelmeyen ilk sayfada durmak, değişmemiş yüzlerce sayfayı çekmekten kurtarır.

Aynı çalışmada aynı URL’yi iki kez çekmek, sayfalar birbirine çapraz link verdiğinde kolayca olur. Ziyaret edilen URL’leri normalize edilmiş haliyle (sorgu parametresi sırası, sondaki eğik çizgi, büyük küçük harf) bir kümede tutmak basit ama etkili bir süzgeçtir. Hedef bir site haritası ya da besleme yayınlıyorsa, liste sayfalarını taramak yerine oradan URL ve tarih almak çoğu zaman en ucuz yoldur; site haritası tek dosyadır ve değişiklik tarihini taşır.

Aynı GB farklı ürünlerde farklı fiyattadır. RotatingProxy kataloğunda 10 GB paket rotating IPv4 datacenter’da 6 USD, rotating IPv4 residential’da 12 USD, rotating mobile’da 25 USD’dir. Yani aynı sayfayı residential üzerinden çekmek datacenter’ın iki katına, mobile üzerinden çekmek dört katından fazlasına mal olur. Hedef datacenter adresine 200 dönüyorsa residential kullanmak, tasarruf ettiğiniz her baytı fiyat farkıyla geri verir.

En ucuz düzen kademeli olandır: her istek önce datacenter gateway’den çıkar, yalnız 403, captcha ya da boş yanıt gibi tanınma belirtisi veren istekler residential kanala devredilir. Devredilen isteklerin oranı GB maliyetinin ana belirleyicisidir ve bu oran, görsel engelleme gibi tekniklerden bağımsız bir tasarruf kaynağıdır. Üç havuzun rotasyon davranışı ve hangi işe hangisinin yettiği havuz türü karşılaştırmasında anlatılıyor.

Hedef IPv6 ile erişilebiliyorsa GB sorusu başka bir biçim alır. Rotating IPv6 datacenter ve residential ürünleri port bazlı aylık paketlerdir: 1 port 29 USD, 5 port 80 USD, 10 port 175 USD. Bu paketlerde GB kotası yoktur; trafik azaltma tekniklerinin maliyet gerekçesi ortadan kalkar, hız gerekçesi kalır. Hedefin IPv6 adresine cevap verip vermediğini bir DNS sorgusu ve bir deneme isteğiyle anlarsınız; kota bazlı seçim rehberi bu testi ve paket boyutu kararını adım adım veriyor.

Hangi tekniğin ne kazandırdığını ölçmeden bilemezsiniz. İstemci tarafında her istek için inen ve giden bayt sayısını kaydetmek, yanıt gövdesi artı başlıkların yaklaşık boyutunu almakla mümkündür; kütüphanelerin çoğu bunu doğrudan ya da ham soket seviyesinde verir. Bu sayıyı hedef alan adı, kaynak türü ve sonuç koduna göre toplayıp günlük bir tabloya yazdığınızda, GB’nin hangi hedefe, hangi türe ve hangi hatalara gittiği görünür. Çoğu projede ilk tablo tek bir hedefin ya da tek bir kaynak türünün tüketimin büyük kısmını aldığını gösterir.

Tam çalıştırmadan önce küçük bir pilot bütçeyi tahmin eder: yüz sayfa çekin, istemci tarafındaki toplam baytı sayfa sayısına bölün, planladığınız sayfa sayısıyla çarpın. Sonra panelinizdeki kullanım sayfasıyla kendi sayınızı karşılaştırın; ikisi arasında sabit bir oran olması normaldir (TLS ve tünel yükü istemci sayımında görünmez), oranın çalışmadan çalışmaya değişmesi ise bir şeyin kaçtığını gösterir. Fiyat izleme için GB hesaplama rehberi bu tahminin kampanya takvimiyle nasıl büyüdüğünü anlatıyor; burada yalnız tahmini doğrulama kısmı var.

Bütçe alarmı iki eşikten kurulur: günlük tüketim beklenenin belirli bir katını aşarsa bildirim, paketin kalan kısmı belirli bir seviyenin altına inerse işi yavaşlatma. İkinci eşik önemlidir, çünkü kota bittiğinde istekler başarısız olur ve başarısız isteklerin yeniden denenmesi kalan kotayı daha hızlı bitirir. Tüketim ölçümünü tek bir yerde, havuz ya da gateway sarmalayıcısında toplamak, her scraper’ın kendi sayacını tutmasından daha güvenilirdir.

Görselleri engellemek veri toplamayı bozar mı? Verinin kendisi HTML’de ya da JSON’daysa bozmaz; görselin adresi de HTML öznitelikleri içinde durur. Bozulma, sayfanın bir ögeyi görsel yüklendikten sonra çizdiği ya da stil gelmeyince betiğin veriyi yüklemediği durumlarda olur. Bir hedefte engellemeyi açmadan önce engelli ve engelsiz iki çalıştırmanın sonuç satırlarını karşılaştırın.

Datacenter proxy residential’a göre neden daha ucuz? Datacenter adresleri barındırma ağlarından toplu olarak gelir ve işletme maliyeti düşüktür; residential adresler gerçek kullanıcı cihazlarından geçer ve her GB o cihazın bağlantısını kullanır. Katalogdaki fiyat farkı bu maliyet farkını yansıtır. Hedef datacenter adresini kabul ediyorsa pahalı olanı seçmenin bir getirisi yoktur.

Değişmeyen sayfayı yeniden indirmeden nasıl anlarım? Sunucu sürüm etiketi ya da son değişiklik tarihi veriyorsa koşullu istekle; vermiyorsa HEAD isteğindeki içerik uzunluğu ve son değişiklik alanlarıyla. Her ikisi de desteklenmiyorsa, sayfanın değişme sıklığını birkaç gün ölçüp tarama aralığını ona göre seyreltmek tek yoldur; gövdeyi indirip karşılaştırmak GB kazandırmaz.

Yeniden denemeler GB tüketimini artırır mı? Evet, çünkü başarısız isteğin inen kısmı da sayılır. Yalnız geçici hataları (zaman aşımı, 429, 503) yeniden deneyin, kalıcı hataları (404, sabit 500) bir denemede bırakın ve yeniden deneme sayısına üst sınır koyun. Zaman aşımını kısa tutmak da yarım inen gövde payını küçültür.

Trafik azaltma tekniklerinin tamamı aynı anda gerekir mi? Hayır. Önce tüketimi ölçün, en büyük kalemden başlayın. Çoğu projede ilk iki adım (tarayıcı yerine düz istek ya da JSON uç noktası ve datacenter öncelikli kademe) tüketimin büyük bölümünü düşürür; görsel engelleme ve koşullu istek ondan sonra gelir.