Rotating IPv4 mı IPv6 mı? Havuz, Rotasyon ve Paket Modeli

Rotating IPv4 mı IPv6 mı sorusunun cevabı hedefin adres ailesiyle başlar: hedef sunucu IPv6 üzerinden yanıt vermiyorsa IPv6 rotating proxy o iş için hiç seçenek değildir, ne kadar ucuz ya da geniş olursa olsun. Hedef iki aileyi de konuşuyorsa karar üç başlıkta verilir: havuzun adres yapısı, rotasyonun nasıl yönetildiği ve paketin GB mi port mu üzerinden ücretlendiği.

Adres ailelerinin teknik farkı burada konu değil; rotating kullanan bir toplayıcının hangi durumda IPv4, hangi durumda IPv6 havuzuna gideceği ve iki aileyi aynı projede nasıl birlikte kullanacağı ele alınır. RotatingProxy kataloğundaki dört ürün, IPv4 datacenter, IPv4 residential, IPv6 datacenter ve IPv6 residential, bu kararın somut karşılığıdır.

İlk adım ölçümdür. Hedef alan adının AAAA kaydı var mı diye bakın; dig ya da nslookup ile AAAA sorgusu boş dönüyorsa hedef yalnız IPv4 üzerinden erişilebilir. Kayıt varsa ikinci kontrol gelir: curl’ü yalnız IPv6 kullanmaya zorlayarak sayfayı isteyin. Bazı siteler AAAA kaydı yayınlar ama IPv6 tarafında ya zaman aşımı verir ya da farklı bir içerik döndürür.

Üçüncü kontrol çoğu kişinin atladığı yerdir: sayfanın kendisi IPv6 üzerinden gelse bile, verinin asıl kaynağı olan API uç noktası, görsel sunucusu ya da arama servisi ayrı bir alt alan adında olabilir ve o alt alan adı yalnız IPv4 dinliyor olabilir. Toplayıcının gerçekten istek attığı her ana bilgisayar adını ayrı ayrı test edin. Ana sayfası IPv6 destekleyen, arama ve filtre API’si desteklemeyen siteye sık rastlanır.

Testin sonucunu hedef başına bir tabloya yazın: alan adı, AAAA var mı, IPv6 üzerinden içerik aynı mı, API uç noktaları IPv6 mı. Bu tablo projenin havuz haritasıdır; sonraki bütün kararlar buradan okunur. Hedef listesi büyüdükçe tabloyu elle değil, toplayıcının başlangıcında çalışan küçük bir kontrol betiğiyle güncelleyin.

IPv6 havuzlarının en çok konuşulan özelliği adres sayısıdır; tek bir blok içinde milyarlarca adres bulunur. Ancak hedef sistemler bu adresleri tek tek değil, çoğunlukla blok düzeyinde değerlendirir. Aynı bloktan gelen on bin farklı adres, hız sınırı sayacında çoğu zaman tek bir kaynak olarak toplanır. Rotating IPv6 kullanırken havuzdaki adres sayısından çok dönen farklı blok sayısına bakın.

IPv4 havuzlarında durum tersidir. Adres sayısı sınırlıdır ama her adres bağımsız bir kimlik gibi davranır; hedefin sayacı adres bazında işler. Bu yüzden aynı istek hacmi için IPv4 rotating daha az adresle daha fazla bağımsız kimlik sağlayabilir. Hedef blok bazlı sayıyorsa IPv6 havuzunun büyüklüğü sizi yanıltmasın; hedef adres bazlı sayıyorsa IPv6 havuzu gerçekten çok daha geniş bir kimlik yelpazesi verir.

Pratikte iki tip hedef görülür. Büyük içerik platformları ve CDN arkasındaki siteler blok bazlı değerlendirme yapar; burada IPv6 rotating işe yarar ama blok çeşitliliğine bakılır. Kendi sunucusunda çalışan orta ölçekli siteler ise adres bazlı sayar; IPv6 destekliyorlarsa IPv6 rotating burada çok verimlidir, çünkü sayaç her adresi ayrı görür.

Dört ürün rotasyonu farklı yönetir ve bu fark adres ailesinden bağımsız olarak iş akışını belirler. IPv4 datacenter ürünü istek başına ya da oturum bazlı döner; her istek yeni bir çıkış adresinden gidebilir. IPv4 residential ürünü sticky ve rotating oturum seçeneklerini birlikte sunar; bir oturum kimliğiyle aynı adreste kalınır, kimlik değişince adres değişir. İki IPv6 ürünü ise oturum yapılandırmalı rotasyonla çalışır: rotasyon davranışı port bazında ayarlanır.

Bu modeller iş tipine göre eşleşir. Birbirinden bağımsız sayfaları toplayan, oturum tutmayan bir fiyat toplayıcısı istek başına rotasyonla en rahat çalışır. Giriş yapılmış bir hesabın sayfalarında gezen ya da çok adımlı bir arama akışı izleyen toplayıcı sticky oturum ister. IPv6 ürünlerindeki yapılandırmalı rotasyon ise port başına ayrı davranış tanımlamaya izin verir: bir port kısa aralıklı rotasyonla listeleri toplarken diğer port sabit kalıp ürün sayfalarını okur.

Rotasyon kararının adres ailesinden önce gelmesi gerekir. Hedef IPv6 destekliyor diye IPv6 havuzuna geçip sonra sticky ihtiyacını fark eden bir ekip, oturum ayarlarını baştan kurmak zorunda kalır. Önce iş akışının rotasyon biçimini yazın, sonra o biçimi sunan ürünler arasından adres ailesini seçin. Rotasyonun nasıl kurulduğu rotating ve static farkı rehberinde ayrıntılı anlatılır.

IPv4 rotating ürünler GB bazlıdır ve süre sınırı yoktur; kota bitene kadar kullanılır. IPv6 rotating ürünler port bazlı aylık modeldir; port sayısı kadar eşzamanlı çıkış kiralanır, trafik miktarı ayrıca ölçülmez. Bu iki model aynı işte çok farklı maliyet eğrileri çizer ve karar hedefin adres ailesi kadar trafiğin şekline bağlıdır.

Varsayımla hesaplayalım: bir sayfa ortalama 400 KB olsun ve günde 50.000 sayfa toplansın. Günlük trafik yaklaşık 20 GB, aylık 600 GB eder. GB bazlı modelde bu hacim doğrudan kotadan düşer ve aylık maliyet trafikle birlikte doğrusal büyür. Port bazlı modelde ise maliyet port sayısına bağlıdır; 600 GB da 6 TB de aynı portlardan geçer, sınır kota değil portun eşzamanlı bağlantı kapasitesidir. Trafik büyük ve hedef IPv6 destekliyorsa port modeli öngörülebilir; trafik küçük ya da düzensizse, ayda birkaç gün çalışan bir kampanya takibi gibi, GB modeli boş ay ödemeyi önler.

Hesabın ikinci boyutu yanıt boyutudur. HTML yerine JSON döndüren bir API uç noktasından sayfa başına 20 KB çekiyorsanız aynı 50.000 sayfa günde 1 GB bile etmez; GB modelinde kota aylarca yeter ve port modeli gereksiz olur. Büyük HTML, görsel ya da PDF toplayan işlerde ise denge port modeline kayar. Kota seçimini kota bazlı rotating proxy rehberinde adım adım işledik; burada yalnız iki modelin kırılma noktasını göstermek yeterli.

Hedef listesi karışıksa tek aile seçmek zorunda değilsiniz. Havuz haritasındaki tabloya göre istekleri yönlendirin: IPv6 destekleyen ve adres bazlı sayan hedefler IPv6 portlarına, geri kalanlar IPv4 GB havuzuna gider. Yönlendirme toplayıcının proxy seçici katmanında hedef alan adına göre yapılır; kodda her hedef için ayrı yapılandırma tutmak yerine haritadan okunur.

Karma düzende bir geri dönüş kuralı tanımlayın. IPv6 portundan giden istek bağlantı zaman aşımı ya da sıfırlama alırsa aynı istek bir kez IPv4 havuzundan tekrarlanır ve o hedef haritada geçici olarak IPv4’e işaretlenir. Bir hedef art arda belirli sayıda geri dönüş tetiklerse, örneğin bir saatte on, haritadaki IPv6 işareti kaldırılır ve ertesi gün kontrol betiği yeniden test eder. Bu kural, IPv6 tarafını bir gece kapatan bir hedefin toplama turunu bozmasını önler.

İki aileyi birlikte kullanırken loglarda adres ailesini ayrı bir alan olarak tutun. Hata oranı, yanıt süresi ve doğrulama sayfası sıklığı aile bazında raporlanınca hangi hedefin hangi havuzda daha iyi çalıştığı bir hafta içinde görülür. Bağlantı hatalarının proxy katmanından mı hedeften mi geldiğini ayırt etme yöntemi bağlantı sorunları rehberinde ayrıntılı anlatılır.

Birincisi AAAA kaydına güvenip içerik testini atlamaktır; kayıt var diye IPv6 portu kiralanır, sonra hedefin IPv6 tarafında boş sayfa döndürdüğü anlaşılır. İkincisi IPv6 adres sayısını kimlik sayısı sanmaktır; blok bazlı sayan bir hedefte on bin adres tek bir sayaç paylaşır ve hız sınırı IPv4’tekinden daha erken gelir.

Üçüncüsü paket modelini trafiğe bakmadan seçmektir; yanıtı küçük bir API için port kiralamak ya da günde yüzlerce GB çeken bir iş için GB paketi almak, aynı işi iki kat pahalıya çıkarır. Dördüncüsü karma düzende geri dönüş kuralı tanımlamamaktır; IPv6 tarafı bir gece kesildiğinde bütün tur başarısız olur ve sabah hangi hedeflerin eksik kaldığı elle bulunur.

Dört hatanın ortak çözümü aynı sıradır: önce hedef başına test tablosu, sonra iş akışının rotasyon biçimi, en son paket modeli; adres ailesi bu üç adımın sonunda belli olur.