Bir cep telefonu veri merkezi değildir. Hücresel ağdaki tek bir Android cihaz rahatça birkaç düzine uzun ömürlü TCP bağlantısını tutabilir; bunun ötesine geçildiğinde radyo yığını paketleri düşürmeye, pil daha hızlı tükenmeye ve müşteriler sizi suçlamaya başlar. Çözüm, istemci başına eşzamanlılığa sert bir tavan koymaktır — her Proxy İstemcisi'ndeki Threads (İş parçacıkları) alanı tam olarak bu tavanı sağlar.
Bu rehber; sınırın neyi saydığını, reddedilen bağlantının ne gördüğünü, sayıyı cihaz türüne göre nasıl doğru boyutlandıracağınızı, thread'lerin kota ve son kullanma tarihi kontrolleriyle nasıl etkileşime girdiğini ve canlı kullanımı panelden nasıl okuyacağınızı açıklar. Genel erişim-kontrol modeline yeni başlıyorsanız, önce müşteri başına proxy istemcileri yazısına bakmanızı öneririz.
Threads sınırı tam olarak neyi sayar?
Panelden herhangi bir proxy'yi açın, Proxy İstemcileri bölümüne kaydırın ve bir istemci oluşturun ya da düzenleyin. Alan Threads olarak etiketlenmiştir. Sınırsız için boş bırakın; bir pozitif tam sayı girerek tavan belirleyin.
Sınır, o istemciye ait o anda açık tünelleri sayar — saniyedeki istek sayısını değil, aktarılan bayt miktarını değil, ziyaret edilen alan adı sayısını değil. threads = 20 olan bir istemci, yirmi paralel scraper çalışanını süresiz olarak çalıştırabilir. Mevcut yirmiden herhangi biri kapanmadan tünel açmaya çalışan yirmi birincisi anında reddedilir.
Bu, kota limitleri ve süreli son kullanma tarihi ile birlikte gelen "gürültülü komşu" sigortasıdır. Kota, bir müşterinin bant genişliği faturanızı yemesini durdurur. Threads, bir müşterinin donanımınızı tekelleştirmesini durdurur. İki sınır farklı sorunları çözer ve aynı istemci üzerinde birleştirilebilir.
Reddedilen bağlantının gördüğü şey
Bir istemci thread tavanına ulaştığında yanıt protokole göre değişir:
- HTTP/HTTPS — proxy auth katmanı, herhangi bir
CONNECTveya tünel kurulumu başlamadan önce gerçek bir429 Too Many Connectionsdöndürür. İstemci hedef sunucuya hiç dokunmaz. - SOCKS5 — bağlantı, karşılama aşamasında reddedilir; yine hedefe hiçbir trafik ulaşmaz.
Reddedilen bir bağlantı için her zaman geçerli olan üç şey vardır:
- Anlıktır — kuyruk yok, bekleme yok, yavaş zaman aşımı yok. Çağıran taraf tek haneli milisaniyeler içinde yanıt alır ve geri çekilebilir ya da başka bir oturumu deneyebilir.
- Deterministiktir — aynı istemci kimlik bilgileri, aynı proxy, aynı an: her seferinde aynı yanıt. "Bazen içeri sokulan" paylaşımlı bir havuz yoktur.
- Kota tüketmez — reddedilen bağlantılar herhangi bir bayt limitine sayılmaz. Müşteriniz, veri iletmeyen bir bağlantı için hakkından kaybetmez.
Müşterileriniz dönen sticky oturumlar (-session-XXXX kullanıcı adı eki) kullanıyorsa, her oturum thread sayımı açısından ayrı bir tünel olarak hesaplanır. Beş sticky oturum ve beş düz bağlantı çalıştıran bir istemci toplamda on thread kullanmaktadır.
Sınırı boyutlandırma: pratik rehber
Evrensel bir sihirli sayı yoktur — doğru sınır, proxynin arkasındaki cihaza, operatöre ve müşterinizin bağlantıyı ne kadar yoğun kullanmayı planladığına bağlıdır. Aşağıdaki tablo başlangıç noktası aralıkları vermektedir:
| Cihaz türü | Önerilen thread sayısı | Gerekçe |
|---|---|---|
| Orta seviye Android telefon, CGNAT operatörü | 10 – 20 | Rahat bir marj; modern cihazlar bunu radyo stresi olmadan kaldırır |
| Amiral gemisi telefon (Turkcell, Vodafone, Türk Telekom) | 30 – 50 | Daha büyük çekirdek arabelleği, daha hızlı radyo — her ikisi de bu yükte rahat çalışır |
| Kablolu bağlantıdaki PC agent | 100 + | Mobil radyo kısıtı yok; sınır OS soket limitleridir |
| Yalnızca upstream proxy (cihaz yok) | Upstream planıyla eşleştirin | Sınır, bir telefonu değil upstream kotanızı korur |
| Paylaşılan cihaz (birden çok istemci) | Toplam cihaz kapasitesini aşmamalı | Her istemcinin sınırı birikir; ilk yüklenen müşteri diğerlerini olumsuz etkiler |
Birden fazla ödeyen müşteri aynı fiziksel cihazı paylaşıyorsa, thread'leri bilinçli olarak tahsis edin. O cihazdaki tüm istemci sınırlarının toplamı, cihazın güvenilir şekilde sürdürebileceğini aşmamalıdır. Panel, istemci başına canlı açık bağlantı sayılarını gösterir; böylece marjı gerçek zamanlı olarak doğrulayabilirsiniz.
Thread'lerin diğer istemci kontrolleriyle etkileşimi
Thread'ler, bir Proxy İstemcisinde ayarlayabileceğiniz dört bağımsız sınırdan biridir. Bunlar AND mantığıyla birleştirilir — yeni bir bağlantının açılabilmesi için her sınırın karşılanması gerekir:
- Threads — eşzamanlı açık tünel maksimumu (bu rehber).
- Kota — aktarılan maksimum bayt. Bkz. istemci başına kota limitleri.
- Son kullanma tarihi — istemci belirli bir tarihten sonra çalışmayı durdurur. Bkz. süreli proxy istemcileri.
- IP ve domain kısıtlamaları — kaynak IP veya hedef domain'e göre erişime izin verin ya da reddedin. Bkz. IP izin/engel listeleri ve domain kısıtlamaları.
threads = 5, quota = 10 GB ve bir son kullanma tarihi olan bir istemci, hangisi önce tetiklenirse onla karşılaşır. Bunlar alternatif değildir — yeni bir bağlantı aynı anda dört engeli birden aşmak zorundadır.
Bu tasarım, kendi kodunuzda hiçbir özel mantık olmadan ayrıntılı bayi katmanları oluşturmanıza olanak tanır. Bir deneme istemcisi 5 thread, 2 GB kota ve 7 günlük son kullanma tarihine sahip olabilirken; premium bir istemci 50 thread, sınırsız kota ve son kullanma tarihine sahip olmayabilir. Panel, her şeyi sizin için uygular. Tam bayi modeli için bkz. müşteri başına proxy istemcileri.
Panelden canlı thread kullanımını okuma
Her Proxy İstemcisi satırı, thread sınırının yanında canlı açık bağlantıları gösterir. Sayaç gerçek zamanlı güncellenir — yeni bir tünel açıldığı anda artar, TCP kapanmasında azalır. Bir API'yi yoklamanıza veya logları kontrol etmenize gerek yoktur; panel yüzeyi en hızlı görüntüdür.
Bir istemcinin tavanında olup olmadığını doğrulamak istiyorsanız canlı sayacı izleyin. Sürekli olarak sınırda oturuyorsa, istemci istenenden daha fazla kısıtlanıyor olabilir — sınırı artırın, o müşteri için ek bir istemci oluşturun ya da paralelliği azaltmalarını isteyin.
Daha derin denetim izleri için — kimin ne zaman, hangi IP'den bağlandığı — bkz. denetim logları. Thread sınırı gerçek zamanlı uygulama içindir; denetim logu tarihsel hesap verebilirlik içindir.
Kaçınılması gereken yaygın hatalar
- Kullanım senaryosu için sınırı çok düşük ayarlamak. 30 paralel tarayıcı sekmesi açan bir scraper,
threads = 5olan bir istemcide sürekli 429 alır. Sınırı müşterinin gerçek iş yüküne göre belirleyin. - Paylaşılan cihaz toplamını göz ardı etmek. Aynı telefondaki her biri 30 thread sınırına sahip on istemci, 300 adede kadar eşzamanlı tünel anlamına gelir; bu herhangi bir akıllı telefonu ezer. Kimlik bilgilerini yayınlamadan önce toplamı denetleyin.
- Thread'leri bant genişliğiyle karıştırmak. Thread'ler açık tünelleri sayar; tek bir tünel birçok megabit itebilir. Yüksek verimli indirmeler pek çok thread gerektirmez — bant genişliği gerektirir. Bant genişliği kontrolü için kota sınırını kullanın.
- Deneme hesapları için thread'leri son kullanma tarihiyle birleştirmemek. Son kullanma tarihi olmayan ama thread sınırı olan bir deneme istemcisi süresiz açık kalabilir ve ücret biriktirebilir. Zaman sınırlı denemeler için thread'leri kısa bir son kullanma tarihiyle birleştirin.
Sonraki adımlar
Thread limitleri, tam çok kiracılı bir proxy işinin yapı taşlarından yalnızca biridir. Bunları yapılandırdıktan sonra şunları keşfedin:
- İstemci başına kota limitleri — thread limitlerinin bant genişliği-bütçe tamamlayıcısı.
- Süreli Proxy İstemcileri — denemelerin otomatik olarak sona ermesi için son kullanma tarihi belirleyin.
- Müşteri başına proxy istemcileri — proxy erişimini yeniden satmak için tam tasarım deseni.
- Nodetonet'te rotating proxies — token grupları, round-robin seçimi ve yük devretme.
- Ücretsiz hesap oluşturun ve ilk istemci limitlerini dakikalar içinde yapılandırın.