Rotating IPv4 Datacenter Proxy

RotatingProxy kataloğundaki beş rotating ürün üç eksende ayrışır: çıkış IP’sinin hangi ağdan geldiği (veri merkezi, konut bağlantısı ya da mobil operatör), adres ailesi (IPv4 ya da IPv6) ve ödemenin neye göre yapıldığı (aktarılan GB ya da aylık port). Rotating IPv4 Datacenter bu üç eksenin en sade kesişimidir: veri merkezi kaynaklı IPv4 adresleri, istek başına veya oturum bazlı rotasyon ve süre sınırı olmayan GB paketleri. Katalogdaki diğer dört ürün, bu sade modelin belirli bir hedefte yetmediği durumlar için vardır. Bu yüzden datacenter rotasyonunu “ucuz alternatif” olarak değil, her yeni hedef için başlangıç noktası olarak düşünmek daha sağlıklıdır; başka bir ürüne geçiş ise ölçülmüş bir gerekçeye dayanmalıdır.

Tablodaki aralıkların alt ucu ya kampanya işaretli 2 GB giriş paketinden ya da 1000 GB kademesinden gelir. Datacenter tarafında 0,50 USD hem 2 GB paketin hem de 1000 GB paketin birim maliyetidir; aradaki altı paketin tamamı 0,60 USD’ye denk gelir. Residential tarafında birim maliyet 2 GB pakette 1,25 USD, 10–200 GB arasında 1,20 USD, 500 GB’ta 1,10 USD ve 1000 GB’ta 0,90 USD’dir. Mobile tarafında 10–50 GB arasında 2,50 USD olan birim maliyet 1000 GB’ta 2,10 USD’ye iner. Port bazlı IPv6 ürünlerinde ölçü birimi GB değil port olduğu için doğrudan karşılaştırma yapılamaz; katalogda 1 port aylık 29 USD, 5 port aylık 80 USD (port başına 16 USD) ve 10 port aylık 175 USD’dir (port başına 17,50 USD).

Rotasyon tanımları katalogda kısa ifadelerle verilir: datacenter için “istek başına veya oturum bazlı”, residential ve mobile için “sticky ve rotating oturum”, IPv6 ürünleri için “oturum yapılandırmalı”. İfadeler farklı olsa da pratikte her üründe IP’nin ne zaman değişeceğini iki şey birlikte belirler: seçtiğiniz rotasyon modu ve istemcinizin bağlantıları nasıl yönettiği. Modun nasıl seçildiği, oturumun ne kadar sürdüğü ya da oturumun hangi parametreyle işaretlendiği bu sayfada verilmez; bunları sipariş ekranında ve hizmet bilgilerinde doğrulayın.

Lokasyon tarafında da bir ayrım vardır. IPv4 Datacenter için kapsam notu 180+ ülkedir ve katalog bunların içinden 15 lokasyonu öne çıkarır. IPv6 Datacenter’ın doğrulanmış listesi ise sekiz ülkeden oluşur: Almanya, Amerika Birleşik Devletleri, Hollanda, Birleşik Krallık, Türkiye, Fransa, Kanada ve Polonya. İki liste karşılaştırıldığında Japonya, Hindistan, Brezilya, Avustralya, Portekiz, İspanya ve Avusturya yalnız IPv4 tarafının öne çıkan listesinde yer alır. Hedefiniz bu ülkelerden birinden çıkış gerektiriyorsa, port modelinin maliyet yapısı ne kadar cazip görünürse görünsün, bu katalogda doğal seçim IPv4 tarafıdır.

Ürün seçimini varsayımla değil, küçük bir pilotla yapmak gerekir. Pratik yöntem şudur: her hedef alan adından temsil edici birkaç düzine herkese açık adres seçin, bunları önce datacenter çıkışla çekin ve sonucu normal bir tarayıcıda gördüğünüzle karşılaştırın. Karşılaştırmada yalnız durum koduna bakmak yetmez; sayfada beklediğiniz veri alanlarının (fiyat, stok, başlık gibi) gerçekten dolu gelip gelmediğini de kaydedin. Bazı hedefler hata vermek yerine eksik ya da genelleştirilmiş içerik döndürür ve bu durum yalnız içerik kontrolüyle yakalanır. Aşağıdaki tablo, pilotta sık karşılaşılan gözlemleri katalogdaki karşılıklarıyla eşleştirir.

Bu tablonun en önemli sonucu, ürün seçiminin hesap düzeyinde değil hedef düzeyinde yapılmasıdır. Çoğu veri ekibinde hedeflerin büyük kısmı datacenter çıkışla sorunsuz çalışırken birkaçı farklı davranır. Bütün trafiği bu birkaç hedef yüzünden residential’e taşımak maliyeti gereksiz yere katlar. Daha sağlıklı yapı, alan adı bazında tutulan bir yönlendirme haritasıdır: varsayılan rota datacenter olur, yalnız pilotta ve sonraki günlerde tekrar eden bir sorun gösteren hedefler residential ya da mobile rotaya alınır. Haritayı periyodik olarak tersine de test edin; hedeflerin davranışı değişir ve bir zamanlar residential gerektiren bir hedef yeniden datacenter çıkışı kabul edebilir.

Maliyet farkı bu disiplinin neden önemli olduğunu gösterir. 200 GB kademesinde datacenter GB’ı 0,60 USD, residential GB’ı 1,20 USD’dir; gereksiz yere residential’e taşınan her GB iki kat ödenir. 1000 GB kademesinde karşılaştırma 0,50 USD’ye karşı 0,90 USD’dir, yani fark yaklaşık 1,8 kat. Mobile tarafında aynı kademe 2,10 USD’dir; mobil operatör IP’si gerektirmeyen bir işi mobile rotada çalıştırmak, aynı trafiği dört kattan fazla pahalıya taşımak anlamına gelir.

Rotating bir üründe tek tek IP adresleriyle uğraşmazsınız. Bağlantı tek bir uç noktaya yapılır ve hangi çıkış IP’sinin kullanılacağına gateway karar verir. Datacenter ürünü bu kararı iki biçimde verebilir. İstek başına rotasyonda her yeni istek, prensipte havuzdan yeni bir çıkış alabilir. Oturum bazlı rotasyonda ise aynı oturuma ait istekler bir süre aynı çıkıştan gider. Rotasyon modunun nasıl seçildiğini ve oturum süresini sipariş ekranında ve hizmet bilgilerinde doğrulayın.

İki mod hedef tarafında farklı bir görüntü yaratır. İstek başına modda hedef, birbirinden bağımsız çok sayıda ziyaretçi görür; yük çıkışlar arasında dağılır ama hiçbir istek bir öncekinin bağlamını taşımaz. Dağıtım, hedefin koyduğu hız sınırını aşmanın yolu değildir; hedefe giden toplam istek hızı, kaç farklı IP kullanılırsa kullanılsın, hedefin kabul ettiği sınırın altında kalmalıdır. Oturum bazlı modda hedef tutarlı bir ziyaretçi görür; çerezler, sayfalama belirteçleri ve sunucu tarafındaki durum anlamını korur. Bunun bedeli, o oturumdaki tüm yükün tek bir IP’de toplanmasıdır. Hedefin IP başına uyguladığı hız sınırları artık oturumunuzun tamamına uygulanır. Bu yüzden oturum bazlı işlerde oturum başına istek hızını, istek başına moddaki tek bir işçinin hızından belirgin biçimde düşük tutmak gerekir; aksi halde tutarlılık kazanırken 429 yanıtlarıyla karşılaşırsınız.

Rotasyon modunu seçmenin en güvenilir yolu, önce iş birimini tanımlamaktır. İş birimi, hedefin gözünde tek bir ziyaretçiden gelmesi gereken en küçük istek grubudur. Bu grup tek bir istekse istek başına rotasyon doğal seçimdir; birbirine bağlı birkaç istekten oluşuyorsa oturum bazlı rotasyon gerekir. Aşağıdaki örnekler tipik iş birimlerini ve uygun modu gösterir.

• Tek adreslik okuma: bir ürün sayfası, bir sitemap dosyası ya da bir kategori sayfası. İş birimi tek istektir; istek başına rotasyon ve her istek için yeni tünel uygundur.
• İmleçli sayfalama: sonraki sayfanın belirteci bir önceki yanıttan geliyorsa zincirin tamamı tek iş birimidir; oturum bazlı rotasyon ve tek istemci gerekir.
• Numaralı sayfalama: sayfa numarası adreste açıkça yer alıyor ve sunucu durum tutmuyorsa her sayfa bağımsız bir iş birimi olabilir; zincir kurmaya gerek yoktur.
• Arama sonrası detay: sonuç listesindeki bağlantılar kısa ömürlü imzalar taşıyorsa liste ve detaylar aynı birimde kalır; imza yoksa detaylar ayrı işlere bölünür.
• Kendi sistemlerinizde çok adımlı test: giriş, işlem ve doğrulama adımları tek bir senaryodur; oturum bazlı rotasyon kullanın ya da bu testi rotasyon dışında çalıştırın.
• Çapraz görünüm kontrolü: aynı herkese açık sayfanın farklı çıkışlardan nasıl göründüğünü karşılaştırmak. İş birimi tek istektir; her sonucun yanına çıkış ülkesini ve zamanını kaydedin.

Kararsız kaldığınızda iş birimini küçük tutun. Uzun oturumlar yükü tek IP’de toplar, ortasında bir şeyin ters gitme olasılığını artırır ve hata durumunda daha fazla trafiğin boşa gitmesine yol açar. Bir zinciri iki bağımsız parçaya bölebiliyorsanız bölün.

Datacenter kataloğunda sekiz paket bulunur ve fiyat yapısı ilk bakışta göründüğünden daha basittir. 2 GB paket kampanya işaretli bir giriş paketidir; koşulları sipariş adımında görünür ve uzun vadeli hesaba katılmamalıdır. 10 GB’tan 500 GB’a kadar altı paketin tamamında birim maliyet 0,60 USD’de sabittir: 200 GB 120 USD, 500 GB 300 USD. Birim maliyeti düşüren tek kademe, 500 USD’lik 1000 GB pakettir. Bu, 200 ve 500 GB paketlerin fiyat avantajı sağlamadığı ama operasyonel değer taşıdığı anlamına gelir: daha seyrek sipariş, daha geniş tampon ve büyük bir tek seferlik işin kota bitmeden tamamlanma güvencesi.

Aşağıdaki senaryo tamamen varsayımsaldır ve yöntemi göstermek için kurgulanmıştır. Bir veri ekibi üç iş yürütüyor ve pilot aşamasında bu işlerin tüm hedefleri datacenter çıkışla sorunsuz çalıştı. Sayfa boyutları, sıkıştırma açıkken başlıklar ve el sıkışma yükü dahil ölçülmüş ortalamalar olarak varsayılıyor. Birimler ondalık alındı (1 GB = 1.000 MB = 1.000.000 KB); panel ikili tanım (1024 tabanı) kullanıyorsa sonuçlar yüzde birkaç oranında değişir.

Aylık yaklaşık 88,3 GB, yılda yaklaşık 1.060 GB eder. İşlerden biri, ayda bir yapılan tam katalog dökümü, tek seferde 30 GB tüketir; bu ayrıntı kota uyarısını kurarken önem kazanacak. Yıllık toplam 830 GB eşiğinin üzerinde olduğu için 1000 GB kademesi ciddi bir aday. Aşağıdaki tablo aynı ihtiyacı farklı satın alma stratejileriyle karşılar.

Tablo üç şey söyler. Birincisi, alım sıklığı fiyatı değiştirmez: her ay küçük paket almak da üç ayda bir orta boy paket almak da 0,60 USD birim maliyette kalır ve yılda 648 USD tutar. İkincisi, 1000 GB kademesi aynı ihtiyacı 536 USD’ye karşılar; fark 112 USD, yani yaklaşık yüzde 17’dir. Üçüncüsü, büyük kademenin sağladığı tasarruf, trafiğin bir kısmının residential’e kayması riskine karşı tampon görevi görür: hedeflerin yüzde 10’u residential gerektirmeye başlasa bile karma senaryonun toplamı 632 USD ile küçük paket stratejisinin altında kalır.

Büyük kademenin bedeli nakit akışı ve tahmin riskidir. 500 USD yılın başında ödenir; küçük paket stratejisinde ise yıl içinde ayda 54 USD ödenir. Tahmin şişkin çıkarsa ne olur? Gerçek yıllık tüketim 850 GB olursa küçük paketlerle 510 USD ödenecekti; 1000 GB yine daha ucuzdur. Tüketim 640 GB’ta kalırsa küçük paketlerle 384 USD yeterdi ve büyük kademede 116 USD fazla ödenmiş olur; ancak süre sınırı olmadığı için kalan 360 GB bir sonraki dönemde kullanılabilir. Gerçek kayıp başka bir yerdedir: hedeflerin datacenter çıkışı kabul etmemeye başlaması ve kotanın kullanılamaz hale gelmesi. Bu yüzden büyük kademe kararını tüketim tahmininden çok hedef portföyünün kararlılığına bağlamak gerekir.

Önceki bölümlerdeki hesapları tekrarlanabilir bir sürece dönüştürmek için aşağıdaki sırayı izleyin. Her adım bir öncekinin çıktısını kullanır; sıralamayı değiştirmek, özellikle sınıflandırmayı atlamak, kota planını yanlış hedeflerle şişirir.

1. Hedef portföyünü sınıflandırın: her alan adını pilot sonucuna göre “datacenter uygun”, “residential ya da mobile gerekli” veya “kapsam dışı” olarak etiketleyin. Kapsam dışı etiketi, kullanım koşulları ya da robots.txt nedeniyle otomasyona kapalı hedefleri de içerir.
2. Kota hesabına yalnız “datacenter uygun” hedeflerin trafiğini alın; diğer rotaların bütçesini ayrı tutun.
3. İş bazında aylık GB’ı ölçülmüş sayfa boyutu ve gerçek istek sayısıyla hesaplayın. Hata payını tahmin etmeyin; pilotta atılan iş birimlerinin ve yeniden denemelerin bayt oranından alın.
4. Planlama ufkunu belirleyin: işlerin aynı hedeflerle en az kaç ay süreceğinden eminsiniz? Aylık ihtiyacı bu sayıyla çarpın.
5. Toplamı 830 GB eşiğiyle karşılaştırın. Altındaysa ihtiyaç kadar küçük paket kombinasyonu alın; üzerindeyse 1000 GB kademesini seçin; eşiğe yakınsa ek kotanın GB başına maliyetine bakın.
6. Sipariş ekranında süre sınırı, paketlerin tek kotada birleşmesi ve ülke seçimi koşullarını okuyun.
7. Kota uyarı eşiğini en büyük tekil işten ve yeni kotanın devreye girme süresinden hesaplayın; yüzde bazlı uyarıya güvenmeyin.
8. Üç ayda bir sınıflandırmayı tekrarlayın; rota değiştiren hedefleri kota planından çıkarın ya da plana ekleyin.

Beşinci adımdaki karşılaştırmayı elle yapmak yerine küçük bir betikle yapmak hem hızlıdır hem de fiyatlar değiştiğinde tek bir listeyi güncellemenizi sağlar. Aşağıdaki örnek, katalogdaki paketlerle belirli bir ihtiyacı karşılayan en ucuz kombinasyonu bulur.

import math

# Rotating IPv4 Datacenter paketleri (GB, USD), katalog fiyatları
PAKETLER = [(10, 6), (20, 12), (50, 30), (100, 60), (200, 120), (500, 300), (1000, 500)]
ADIM = 10  # en küçük paket 10 GB; 2 GB kampanya paketi hesaba katılmadı


def en_ucuz_plan(ihtiyac_gb):
    hedef = math.ceil(ihtiyac_gb / ADIM)
    ust = hedef + 1000 // ADIM  # en fazla 1000 GB fazla kotaya kadar dene
    # en_iyi[i] = (toplam USD, paket adedi): önce fiyat, eşitlikte az paket
    en_iyi = [(0, 0)] + [(math.inf, 0)] * ust
    son_paket = [0] * (ust + 1)
    for i in range(1, ust + 1):
        for gb, usd in PAKETLER:
            k = gb // ADIM
            if k <= i:
                aday = (en_iyi[i - k][0] + usd, en_iyi[i - k][1] + 1)
                if aday < en_iyi[i]:
                    en_iyi[i], son_paket[i] = aday, gb
    secilen = min(range(hedef, ust + 1), key=lambda i: en_iyi[i])
    plan, i = [], secilen
    while i > 0:
        plan.append(son_paket[i])
        i -= son_paket[i] // ADIM
    return en_iyi[secilen][0], sorted(plan, reverse=True)


for ihtiyac in (700, 830, 834, 1060):
    usd, plan = en_ucuz_plan(ihtiyac)
    print(f"{ihtiyac} GB: {' + '.join(map(str, plan))} GB = {usd} USD")

# Çıktı:
# 700 GB: 500 + 200 GB = 420 USD
# 830 GB: 500 + 200 + 100 + 20 + 10 GB = 498 USD
# 834 GB: 1000 GB = 500 USD
# 1060 GB: 1000 + 50 + 10 GB = 536 USD

Betik 10 GB adımlarla ilerleyen basit bir dinamik programlama kullanır ve ihtiyacı en az karşılayan en ucuz kombinasyonu, 1000 GB’a kadar fazla kota alınmasına izin vererek arar. Fiyat eşit olduğunda daha az paketli planı tercih eder; böylece 700 GB için yetmiş tane 10 GB paket yerine 500 + 200 GB önerilir. Çıktıdaki 830 ve 834 GB satırları, eşiğin iki yanında kararın nasıl değiştiğini gösterir. Fiyatlar değiştiğinde yalnız PAKETLER listesini güncellemeniz yeterlidir; güncel değerleri ürün sayfasındaki paket bölümünden alın.

Büyük kademelerde kota uyarısını yüzdeyle kurmak yanıltıcıdır. 1000 GB paketin yüzde 10’u 100 GB’tır ve örnek senaryoda bu, günde ortalama yaklaşık 2,94 GB tüketimle 34 günlük trafiğe karşılık gelir; uyarı gereğinden erken gelir ama zararsızdır. Asıl tehlike küçük paketlerdedir. 100 GB paketin yüzde 10’u 10 GB’tır ve senaryodaki 30 GB’lık aylık döküm işi kalan kota 25 GB iken başlarsa uyarı eşiği henüz aşılmamıştır; iş yarıda kalır ve uyarı geldiğinde hasar çoktan oluşmuştur.

Daha sağlam bir eşik iki değerin büyüğü olarak hesaplanır: en büyük tekil işin hata payıyla birlikte tüketimi ve günlük ortalama tüketimin yeni kotanın devreye girmesi için gereken gün sayısıyla çarpımı. Senaryoda en büyük iş 30 GB’tır; yüzde 15 payla 34,5 GB eder. Günlük ortalama 2,94 GB iken sipariş ve onay için yedi gün ayırdığınızı varsayarsanız ikinci değer yaklaşık 20,6 GB olur. Eşik büyük olan değerdir, yani 34,5 GB; yuvarlayarak 40 GB kullanılabilir. Kalan kota bu değerin altına indiğinde büyük iş başlatılmadan önce yeni paket alınmalıdır.

Kalan gün tahmininde de bir tuzak vardır. Son yedi günün ortalaması, içinde aylık döküm işi bulunan bir haftada yüksek, bulunmayan bir haftada düşük çıkar. Tahmini otuz günlük ortalamayla yapın, eşiği ise en büyük patlamanın boyutuyla belirleyin. Senaryodaki ekip yılı 1000 GB kotayla açtığında otuz günlük ortalamaya göre kota yaklaşık 340 gün yeter; bu da yıllık hesapla tutarlıdır. Tahminin güvenilir olması için her iş birimi için en az şu alanları kaydedin:

• İş adı ve iş birimi kimliği
• Hedef alan adı ve kullanılan rota (datacenter ya da residential)
• Rotasyon modu (istek başına ya da oturum bazlı)
• İstek sayısı, tamamlanan ve atılan birim sayısı
• Aktarılan bayt; başarılı ve başarısız denemeler ayrı ayrı
• Hedef başına sayfa boyutunun haftalık ortalaması

Hedef başına sayfa boyutu trendi özellikle değerlidir. Bir hedef sayfa tasarımını yenilediğinde istek sayısı aynı kalsa da tüketim sessizce artar. Bu artış ancak ay sonunda fark edilirse yıllık planın tamamı kayar; haftalık bir trend grafiği ise sorunu ilk haftada gösterir.

Aşağıdaki tablo genel bağlantı hatalarını değil, rotasyon modunun ve kota planının yol açtığı sorunları ele alır. Kimlik doğrulama ve genel bağlantı hatalarının çözümü sitedeki bağlantı sorunları rehberinde ayrıca işlenir.

Bu belirtilerin ortak noktası, çoğunun hata kodu üretmemesidir. Aynı IP’nin tekrar etmesi, başa dönen sayfalama ya da büyüyen sayfa boyutu 200 yanıtıyla birlikte gelir. Yalnız durum koduna bakan bir izleme bu sorunları göremez; iş birimi düzeyinde içerik kontrolü ve bayt kaydı gerekir.

Aşağıdaki maddeler, 500 ya da 1000 GB gibi büyük bir datacenter kademesine geçmeden önce cevaplanması gereken soruları toplar. Her madde, bu sayfada anlatılan bir rotasyon ya da kota riskine karşılık gelir.

• Her iş için rotasyon modu (istek başına ya da oturum bazlı) ayrı ayrı seçildi ve modun nasıl seçildiği sipariş ekranında ve hizmet bilgilerinde doğrulandı.
• Yirmi istek testi kendi yankı uç noktanızla HTTPS üzerinden yapıldı; bağlantı yeniden kullanımının çıkış IP’sine etkisi biliniyor.
• Her iş birimi atomik; yarıda kalan birim baştan alınıyor ve kontrol noktası yalnız birim sonunda yazılıyor.
• Paralel işçiler istemci nesnesini ve bağlantı havuzunu paylaşmıyor.
• Hedef alan adları pilotta sınıflandırıldı; kota hesabına yalnız datacenter uygun olanlar girdi.
• Aylık GB ihtiyacı iş bazında ölçüldü; hata payı pilotta ölçülen orandan alındı.
• Planlama ufkuyla çarpılan toplam ihtiyaç 830 GB eşiğiyle karşılaştırıldı.
• Süre sınırı, paketlerin birleşmesi ve ülke seçimi koşulları sipariş ekranında okundu.
• Kota uyarı eşiği, en büyük tekil işi ve sipariş süresini karşılayacak şekilde kuruldu.
• Hedeflerin robots.txt yönergeleri, kullanım koşulları ve yayımlanmış hız sınırları gözden geçirildi; kişisel veri toplanmıyor ya da hukuki dayanağı belgelendi.
• Üç aylık sınıflandırma tekrarının sorumlusu belli.

Bu listenin tamamı işaretlendiğinde büyük kademe bir kumar olmaktan çıkar ve ölçülmüş bir ön ödemeye dönüşür. Listede açık kalan madde varsa önce o maddeyi küçük bir paketle kapatın; 0,60 USD birim maliyetle yapılan birkaç haftalık ölçüm, yanlış hedeflere bağlanmış 500 USD’lik bir kotadan her zaman daha ucuzdur.