Rotating IPv6 Datacenter Proxy

RotatingProxy kataloğundaki rotating IPv4 ürünleri trafiği GB üzerinden ölçer ve süre sınırı koymaz; IPv6 datacenter ürünü ise portu birim alır ve aylık faturalar. Bu fark yalnızca fatura satırını değiştirmez, rotasyona bakışı da değiştirir. GB modelinde rotasyonun kendisi bedavadır: çıkış adresi her istekte değişse de hiç değişmese de ödediğiniz tutarı yalnızca aktarılan bayt belirler. Port modelinde ise ödediğiniz şey, ay boyunca elinizde tuttuğunuz kanal kapasitesidir. Rotasyon bu kanalların içinde işleyen bir davranıştır ve bedeli doğrudan para olarak değil, kanal zamanı olarak ortaya çıkar.

Kanal zamanını şöyle düşünebilirsiniz: 30 günlük bir ay varsayımıyla bir port yaklaşık 720 saat açıktır ve bu saatlerin her birinde ya yük taşır ya da boş durur. Çıkış adresinin değişmesi çoğu proxy altyapısında yeni bir bağlantı kurmak anlamına gelir. İstemci proxy ile TCP bağlantısı açar, HTTPS hedeflerde bir tünel kurulur ve TLS el sıkışması yapılır; bu sürede kanal faydalı veri taşımaz. Adres çok sık değişirse aynı port üzerinden tamamlanan istek sayısı azalır. Adres daha uzun tutulursa bağlantı yeniden kullanılabildiği için verim artar, ama hedefin tek bir adresten gördüğü istek sayısı da yükselir. Port modelinde rotasyon ayarı, bu iki uç arasında bilinçli bir denge kurmaktır.

Katalog bu ürünün rotasyonunu “oturum yapılandırmalı” olarak tanımlar; rotating IPv4 datacenter için ise istek başına veya oturum bazlı rotasyon ifadesini kullanır. Bu sayfadaki hesaplarda belirli bir rotasyon aralığı varsaymıyoruz. Katalogda yer almayan ve satın almadan önce panelde ya da sipariş adımında doğrulamanız gereken ayrıntılar şunlardır: portun aynı anda taşıyabildiği bağlantı sayısı, rotasyonun hangi olayla tetiklendiği, bir oturumun ne kadar korunabildiği, ülke seçiminin port veya bağlantı bazında yapılması ve yenileme ile paket değişikliği koşulları. Sayfanın devamında bu listeye başvuruyoruz.

Tablonun pratik sonucu şudur: GB modelinde verimlilik bayt tasarrufuyla, port modelinde ise kanal doluluğuyla sağlanır. Gereksiz görsel ve betik indirmemek GB modelinde doğrudan para kazandırır. Port modelinde aynı tasarruf faturayı değiştirmez, ama kanalın bir sonraki isteğe daha erken geçmesini sağladığı için dolaylı yoldan kapasite kazandırır. İki model arasında karar verirken bu farkı bilmek, yanlış yere optimizasyon emeği harcamayı önler.

Port bazlı ürünlerde en sık yapılan planlama hatası, üç farklı sayıyı tek bir sayıymış gibi okumaktır. Satın aldığınız port sayısı, aynı anda açabildiğiniz bağlantı sayısı ve hedefin zaman içinde gördüğü farklı adres sayısı birbirinden bağımsız olabilir. Katalog bunlardan yalnızca ilkini kesin olarak verir; diğer ikisini ölçmeniz gerekir.

IPv6 adresi 128 bittir ve IPv4’ün 32 bitlik alanıyla kıyaslanamayacak kadar geniştir. Bu genişlik, rotasyon hakkında sezgisel ama yanıltıcı bir beklenti doğurur: adres sayısı neredeyse sınırsızsa, her istekte yeni adres kullanmak hedefin gözünde her isteği yeni bir ziyaretçi yapacaktır. Gerçekte hedef sistemler IPv6 trafiğini değerlendirirken adresin yapısını dikkate alır ve bu beklenti büyük ölçüde boşa çıkar.

IPv6 adres mimarisini tanımlayan RFC 4291’e göre tek yayın adreslerinin çoğunda son 64 bit arayüz tanımlayıcısıdır, ilk 64 bit ise ağ önekini oluşturur. Bu yüzden /64, IPv6 dünyasında tek bir yerel ağın standart büyüklüğüdür. Son kullanıcı sitelerine genellikle /48 ile /56 arasında daha geniş bloklar atanır; RFC 6177 bu atama boyutunda esneklik önerir. Daha önemlisi, sıradan cihazlar da adres değiştirir. RFC 8981’de tanımlanan geçici adres mekanizmasıyla bir dizüstü bilgisayar ya da telefon, aynı /64 içinde rastgele üretilmiş yeni arayüz tanımlayıcılarına düzenli olarak geçer. Yani aynı /64’ten gelen değişken adresler hedef açısından olağan bir kullanıcı davranışıdır ve tek başına yeni ziyaretçi işareti sayılmaz.

Bu nedenle sayım düzeyi sistemden sisteme değişir. İtibar değerlendirmesi ise çoğu zaman daha üst katmanlarda yapılır: adres bloğunun hangi kuruluşa atandığı, hangi otonom sistemden (ASN) duyurulduğu ve bu bloktan geçmişte nasıl trafik geldiği. Datacenter IPv6 adresleri barındırma ağlarından duyurulduğu için hedef, trafiğin bir veri merkezinden geldiğini adresin biçiminden değil, bu kayıtlardan anlar.

Coğrafi konum tarafında da bir ayrıntı vardır. Hedefler ülke tespitini çoğunlukla ticari konum veritabanlarıyla yapar ve bazı veritabanlarında IPv6 kayıtları IPv4 kadar ayrıntılı ya da güncel olmayabilir. Seçtiğiniz ülkeyle hedefin gösterdiği içerik uyuşmuyorsa sorun her zaman proxy tarafında değildir; aynı hedefin aynı ülke için IPv4 üzerinden ne gösterdiğiyle karşılaştırarak kaynağı ayırın.

Ürünün çıkış adreslerinin hangi önek boyutlarından geldiği katalogda yazmaz; bunu tahmin etmek yerine ölçmek mümkündür. Yöntem basittir: gelen isteğin kaynak adresini düz metin olarak döndüren küçük bir uç noktayı kendi sunucunuzda çalıştırın, proxy üzerinden bu uç noktaya belirli sayıda istek gönderin ve dönen adresleri /128, /64, /56 ve /48 düzeylerinde gruplayın. Kendi uç noktanızı kullanmak, ölçüm trafiğini üçüncü taraf bir servise yüklememenizi ve sonuçların başka bir sistemin önbelleğinden etkilenmemesini sağlar.

Aşağıdaki örnekte her istek için yeni bir oturum açılır; böylece bağlantı yeniden kullanılmaz ve rotasyonun etkisi gözlenebilir. Rotasyonun hangi olayla tetiklendiği panel ayarınıza bağlıdır, bu yüzden ayarı değiştirdiğinizde ölçümü tekrarlayın. HEDEF_URL burada, isteği yapan adresi döndüren kendi kontrol uç noktanızdır.

import ipaddress
from collections import Counter
import requests

PROXY = 'http://KULLANICI:ŞİFRE@GATEWAY:PORT'
KONTROL = 'HEDEF_URL'   # istemci adresini düz metin döndüren kendi uç noktanız
ORNEK_SAYISI = 200

adresler = []
for _ in range(ORNEK_SAYISI):
    # Her örnekte yeni oturum: bağlantı yeniden kullanılmaz
    with requests.Session() as s:
        s.proxies = {'http': PROXY, 'https': PROXY}
        r = s.get(KONTROL, timeout=15)
        adresler.append(ipaddress.ip_address(r.text.strip()))

v6 = [a for a in adresler if a.version == 6]
print('IPv6 olmayan yanıt:', len(adresler) - len(v6))

def blok(adres, uzunluk):
    return ipaddress.ip_network(str(adres) + '/' + str(uzunluk), strict=False)

for uzunluk in (128, 64, 56, 48):
    gruplar = Counter(blok(a, uzunluk) for a in v6)
    en_kalabalik = gruplar.most_common(1)[0][1] if gruplar else 0
    print('/' + str(uzunluk), 'farklı blok:', len(gruplar),
          'en kalabalık bloktaki örnek:', en_kalabalik)
# Çıktıdaki adresleri paylaşırken 2001:db8::/32 belgeleme bloğuyla maskeleyin

Çıktıyı yorumlarken şu durumları birbirinden ayırın:

• Farklı /128 sayısı yüksek, farklı /64 sayısı düşükse rotasyon büyük ölçüde aynı alt ağlar içinde gerçekleşiyordur. /64 düzeyinde sayım yapan bir hedef bu trafiği az sayıda kaynaktan geliyormuş gibi görür; hedef başına hız bütçenizi buna göre küçük tutun.
• Farklı /64 sayısı yüksek ama /48 sayısı düşükse dağılım daha geniştir, ancak sıkı bir hedef yine de trafiği birkaç blok olarak değerlendirebilir. Bütçeyi /48 başına düşünmek daha temkinli bir yaklaşımdır.
• En kalabalık bloktaki örnek sayısı toplamın büyük bölümünü oluşturuyorsa, rotasyon dengesiz bir dağılım üretiyordur. Bu bilgi, hedefe giden yükün pratikte tek bir bloktan geldiğini varsaymanız gerektiğini gösterir.
• Yanıtların bir kısmı IPv6 değilse, ya kontrol uç noktanız IPv4 üzerinden de yanıt veriyordur ya da istemci trafiği proxy dışından gönderiyordur. Uç noktayı yalnız IPv6 dinleyecek biçimde yapılandırıp ölçümü tekrarlayın.

Bu ölçümü tek port ile, günün farklı saatlerinde ve kullanacağınız her ülke için ayrı ayrı yapın. Sonuç ürünün genel bir özelliği değil, sizin hesabınız ve ayarlarınız için yapılmış bir gözlemdir; paket büyüttüğünüzde ya da lokasyon değiştirdiğinizde ölçümü yenileyin.

Port modelinde ölçek adres sayısından değil, iki sınırdan gelir: ödediğiniz kanal kapasitesi ve her hedefin kabul ettiği istek temposu. IPv6 desteği olan hedeflerde bu iki sınırı birlikte yöneten bir düzen kurmak, hem gereksiz port almayı hem de hedefleri yormayı önler. Aşağıdaki sıra, mevcut bir IPv4 iş yükünü port bazlı IPv6 ürününe taşırken izlenebilecek adımları verir.

1. Son 30 günün istek günlüğünden hedef host listesini çıkarın ve her host için istek sayısını ve aktarılan veri miktarını GB olarak yazın. Günlüğünüz yoksa kısa bir deneme çalışmasıyla bu tabloyu oluşturun.
2. Her host’u IPv6 yolunun gerçekten çalışıp çalışmadığına göre sınıflandırın. DNS’te AAAA kaydı bulunması ilk koşuldur; asıl kanıt, proxy üzerinden gönderilen isteğin başarılı yanıt almasıdır.
3. IPv6 sınıfına düşen hostların toplam aylık GB değerini hesaplayın ve aşağıdaki başabaş tablosuyla karşılaştırın. Bu toplam 1 port paketinin başabaşının altındaysa port modeline geçmenin ekonomik bir gerekçesi yoktur.
4. Her hedef için dakika başına bir istek bütçesi belirleyin. Hedefin yayımladığı limitler, robots.txt yönergeleri ve kendi gözleminiz bu bütçenin kaynağıdır; adres çeşitliliği bütçeyi büyütmez.
5. Tek port ile başlayıp çıkış dağılımını ve port başına sürdürülebilir verimi ölçün. Verim, hedef bütçelerinin toplamından düşükse port ekleyin; yüksekse port eklemek yalnızca boş kanal satın almak olur.
6. Rotasyon davranışını iş türüne göre ayarlayın: tek istekte biten durumsuz sayfalarda sık değişim, çok adımlı akışlarda oturumun korunması. Bu seçeneklerin panelde nasıl sunulduğunu kontrol edin.
7. IPv6 yolu bozulan hostlar için IPv4 GB ürününe giden bir yedek kuyruk tanımlayın ve host’u kalıcı olarak taşımadan önce birkaç ardışık hatayı bekleyin.
8. Haftada bir port doluluk oranını ve IPv6 kuyruğundan geçen trafiğin GB eşdeğerini raporlayın; bu iki sayı paket büyüklüğünün doğru olup olmadığını gösterir.

Başabaş noktası, bir port paketinin aylık ücretinin aynı trafiği rotating IPv4 datacenter ürününde GB olarak satın almanın maliyetine eşit olduğu aylık trafik miktarıdır. Hesap için iki katalog fiyatı kullanılabilir. 10 GB ile 500 GB arasındaki IPv4 datacenter paketlerinde GB başına fiyat 0,60 USD’dir; örneğin 100 GB 60 USD, 500 GB 300 USD tutar. 1000 GB paketinde ise 500 USD karşılığında GB başına fiyat 0,50 USD’ye iner. Katalogda başlangıç kampanyasıyla işaretlenmiş 2 GB’lık 1 USD’lik paket, sürekli trafik karşılaştırmasına katılmamalıdır.

Tablonun son sütunu ilk bakışta gözden kaçan bir şeyi gösterir. 5 port paketinde her portun ayda yalnızca yaklaşık 26,7 GB taşıması, paketin GB modeline denk gelmesi için yeterlidir. 10 port paketinde port başına fiyat daha yüksek olduğu için bu eşik yaklaşık 29,2 GB’a çıkar; 1 port paketinde ise tek port yaklaşık 48,3 GB taşımak zorundadır. Port başına eşiğin düşük olması 5 port paketini IPv6 hacmi olan ekipler için esnek bir başlangıç noktası yapar, ama bu eşiğin her portta ve her ay gerçekten aşılması gerekir.

Hangi GB fiyatıyla karşılaştıracağınız, IPv4 tarafında nasıl satın aldığınıza bağlıdır. Aylık ihtiyacınızı 100 GB ve 200 GB gibi paketlerle karşılıyorsanız doğru karşılaştırma 0,60 USD’dir. 1000 GB paketini peşin alıp birkaç ayda tüketiyorsanız 0,50 USD’yi kullanın; bu durumda başabaş noktaları yükselir ve port modelinin avantajı ancak daha yüksek hacimde başlar.

GB cinsinden başabaş, günlük operasyonda doğrudan gözlenen bir sayı değildir; ekipler genellikle istek sayısını ve hızını izler. Başabaşı istek temposuna çevirmek için istek başına ortalama aktarım miktarını bilmek gerekir. Bu miktar yanıt türüne göre büyük farklılık gösterir: sıkıştırılmış küçük bir JSON yanıtıyla satır içi betikleri ve uzun ürün açıklamaları olan bir HTML sayfası aynı sınıfta değildir.

Varsayımlar: istek başına ortalama aktarım başlıklar ve TLS ek yükü dahil 40 KB, 120 KB ve 350 KB; 1 GB = 1.000.000 KB; ay 30 gün; tempo ay boyunca sabit; karşılaştırma fiyatı 0,60 USD/GB. Değerler yuvarlanmıştır.

Tablo, port modelinin hangi işe yaradığını açıkça gösterir. Yanıtları ağır olan işlerde başabaş düşük bir tempoyla aşılır: 350 KB’lık sayfalarda 5 port paketi için dakikada yaklaşık 9 istek yeterlidir. Hafif yanıtlarda ise aynı paket için dakikada 77 civarında sürekli istek gerekir. Bu tempo, hedeflerin kabul ettiği hız bütçeleriyle çatışabilir; hedeflerinizin toplam bütçesi dakikada 77 isteğe ulaşmıyorsa, hafif API yanıtları için GB modeli daha ucuz kalır. Kısacası port modeli bayt yoğun işlerde, GB modeli istek sayısı yüksek ama yanıtları hafif işlerde öne çıkar.

Kendi değerlerinizle hesap yapmak için aşağıdaki küçük betiği kullanabilirsiniz. Fiyatlar katalogdan alınmıştır; ortalama aktarım ve IPv6 payı sizin ölçümlerinizle değiştirilmelidir.

// Katalog fiyatları (USD): rotating IPv6 datacenter port paketleri, aylık
const PORT_PAKETLERI = [
  { port: 1, aylik: 29 },
  { port: 5, aylik: 80 },
  { port: 10, aylik: 175 },
]
// Rotating IPv4 datacenter: 10–500 GB paketlerde 0,60 USD/GB; 1000 GB paketinde 0,50
const GB_FIYATI = 0.6

// Varsayımlar: 1 GB = 1.000.000 KB, ay = 30 gün, tempo ay boyunca sabit
function basabasTemposu(ortalamaKb) {
  for (const p of PORT_PAKETLERI) {
    const gb = p.aylik / GB_FIYATI
    const aylikIstek = (gb * 1000000) / ortalamaKb
    const dakikada = aylikIstek / (30 * 24 * 60)
    console.log(p.port + ' port: ' + gb.toFixed(1) + ' GB/ay, ' +
      Math.round(aylikIstek).toLocaleString('tr-TR') + ' istek/ay, dakikada ' +
      dakikada.toFixed(1) + ' istek')
  }
}

// Karma düzen: IPv6 destekli pay porta, kalan trafik GB ürününe
function karmaMaliyet(toplamGb, ipv6Payi, paket) {
  const tumuGb = toplamGb * GB_FIYATI
  const karma = paket.aylik + toplamGb * (1 - ipv6Payi) * GB_FIYATI
  console.log('Tümü GB: ' + tumuGb.toFixed(2) + ' USD | karma: ' +
    karma.toFixed(2) + ' USD | fark: ' + (tumuGb - karma).toFixed(2) + ' USD')
}

basabasTemposu(120)                         // ölçtüğünüz ortalama KB
karmaMaliyet(300, 0.8, PORT_PAKETLERI[1])   // 300 GB, yüzde 80 IPv6, 5 port

Ortalama aktarımı ölçerken yalnızca yanıt gövdesini değil, istek ve yanıt başlıklarını, yönlendirmeleri ve başarısız denemeleri de hesaba katın. Kendi istemci günlüğünüzde her istek için aktarılan bayt sayısını kaydetmek, tahmin yerine gerçek bir ortalama elde etmenin en güvenilir yoludur.

Aşağıdaki senaryolar varsayımsaldır ve yöntemi göstermek içindir. Hepsinde hedeflerin IPv6 desteklediği, kullanım koşullarının izin verdiği ve hız bütçelerine uyulduğu kabul edilir. Fiyatlar katalogdandır; port başına verim bilinmediği için sonuçlar ölçüme bağlı koşullarla verilmiştir. Önce özet tabloyu, ardından her senaryonun hesabını bulacaksınız.

Başabaş tablosu tek bir ayı karşılaştırır; oysa iki model zaman içinde farklı davranır. IPv4 GB paketlerinde süre sınırı yoktur ve kullanılmayan kota sonraki aylarda tüketilebilir. Port paketleri ise aylık faturalanır; bir ayda boş geçen kanal saatleri geri gelmez. Bu asimetri, trafiği aydan aya dalgalanan ekipler için başabaş hesabını değiştirir.

Altı aylık düzenli bir örnekle başlayalım. Varsayım: IPv6 destekli hedeflerde ayda düzenli olarak 160 GB trafik var. Port tarafında 5 port paketi altı ayda 480 USD tutar. GB tarafında altı ayın toplamı 960 GB’tır; 1000 GB paketi 500 USD ile bu ihtiyacı karşılar ve 40 GB artar. İki seçenek neredeyse eşittir, ama nakit akışı farklıdır: GB modelinde 500 USD peşin, port modelinde ayda 80 USD ödenir. Aynı trafik her ay 100 GB, 50 GB ve 10 GB paketleriyle alınırsa ayda 96 USD, altı ayda 576 USD ödenir ve port modeli 96 USD öne geçer.

Dalgalı trafikte durum değişir. Varsayım: altı ay sırasıyla 60, 220, 80, 200, 70 ve 210 GB trafik üretiyor; toplam 840 GB, aylık ortalama 140 GB. Ortalama, 5 port başabaşının (yaklaşık 133,3 GB) üzerinde görünür. Ancak kapasite ölçümü yoğun aylar için 10 port gerektiriyorsa ve paket zirveye göre sabit tutulursa altı ayda 1050 USD ödenir. GB modelinde aynı 840 GB, 0,60 USD/GB ile 504 USD; 1000 GB paketiyle 500 USD tutar ve 160 GB artar. Paket her ay ihtiyaca göre değiştirilebilse ve yoğun aylarda 10 port, sakin aylarda 1 port kullanılsa bile toplam 612 USD olur ve GB modelinin üzerinde kalır. Yoğun aylarda 5 port yetiyorsa toplam 327 USD’ye iner ve port modeli yeniden öne geçer. Dalgalı işlerde sonucu belirleyen, zirve ayın kaç port gerektirdiğidir.

Zaman boyutunu karara katmak için şu üç soruyu yanıtlayın:

• Trafiğin en az üç ay boyunca port başabaşının üzerinde kalacağını gösteren bir veriniz var mı?
• Yoğun dönemler ertelenip aya yayılabilir mi, yoksa belirli günlerde tamamlanması mı gerekiyor?
• Peşin ödeme mi, aylık sabit ödeme mi bütçe süreçlerinize daha uygun?

Port bazlı IPv6 kullanımında karşılaşılan sorunların bir kısmı bağlantı hatası olarak değil, beklenen verimin ya da tasarrufun gerçekleşmemesi olarak ortaya çıkar. Aşağıdaki tablo bu iki türü birlikte ele alır.

Tablonun ilk iki satırı parasal kayıpla doğrudan ilgilidir ve haftalık bir rapor olmadan fark edilmesi zordur, çünkü hiçbir hata mesajı üretmezler. Bu yüzden port doluluğunu ve hedef bazlı başarılı istek sayısını bağlantı hatalarıyla aynı panoda izleyin. Destek ekibine başvurmanız gerekirse sorunun yaşandığı zaman aralığını, hedef host’u, seçtiğiniz ülkeyi ve önek ölçümünüzün sonucunu birlikte iletin.

Port paketine geçmeden önce ve her ay sonunda aşağıdaki maddeleri gözden geçirin. Maddelerin çoğu bir sayıya bağlanır; sayı elinizde yoksa önce onu ölçün.

• Yukarıdaki 8 adım tamamlandı.
• Ortalama aktarım gerçek istemci günlüğünden, başlıklar ve yönlendirmeler dahil ölçüldü.
• Tek port ile ölçülen /64, /56 ve /48 dağılım sonucu kaydedildi.
• Gerekli lokasyonların katalogdaki sekiz IPv6 datacenter ülkesi içinde olduğu doğrulandı.
• İlk bölümdeki doğrulama listesi (bağlantı sayısı, rotasyon tetikleyicisi, yenileme ve paket değişikliği) panelde kontrol edildi.
• Ay sonu raporunda port doluluk oranı ve port başına başarılı istek sayısı yer alıyor.
• Kişisel veri içeren sayfalar toplanmıyor ya da toplamanın hukuki dayanağı belgelenmiş.

Ay sonu raporundaki GB eşdeğeri başabaşın altında kalıyorsa, port sayısını azaltmak ya da trafiği GB ürününe geri taşımak bir başarısızlık değil, modelin doğru kullanımıdır. Port bazlı rotating IPv6 datacenter, IPv6 uyumlu, bayt yoğun ve sürekli işlerde güçlüdür; bu koşullardan biri ortadan kalktığında süresiz GB paketleri daha esnek bir seçenek olarak kalır.