Mixcloud Proxy: Uzun Yayınlar, Oran Sınırı ve Çıkış İtibarı

Mixcloud, tek parça hâlinde saatlerce süren karışım ve radyo programlarını barındırır. Bu içerik biçimi, proxy tarafında üç somut sonuç doğurur: bağlantı uzun süre açık kalır, aktarılan veri miktarı yüksektir ve yarıda kopan bir oturum kullanıcı açısından kısa bir parçanın kopmasından çok daha rahatsız edicidir.

İkinci konu genel API’dir. Platform, yayınlar ve kullanıcılar hakkında herkese açık bilgiyi JSON olarak döndüren okuma uç noktaları sunar. Bu uç noktalar programatik erişime uygundur, ancak her genel servis gibi istek sayısına sınır koyar. Sınırın nasıl davrandığını bilmeden yazılan bir betik, ilk yoğun çalıştırmada duvara çarpar.

Üçüncü konu kimliktir: çerezle taşınan web oturumu, uygulama adına verilen erişim jetonu ve tarayıcının ürettiği cihaz sinyalleri birbirinden bağımsız katmanlardır. Proxy bunlardan yalnızca birine, yani isteğin geldiği adrese dokunur.

İstemci hangi uç noktalara bağlanır?

Bir yayın sayfası açıldığında en az dört farklı hedef devreye girer. Birincisi web arayüzünün kendisidir: HTML belgesi, betikler ve stil dosyaları. Bu isteklerin toplam boyutu küçüktür ve tek seferliktir; sayfa bir kez yüklendikten sonra tekrar edilmez.

İkincisi genel API’dir. Arayüz, yayın listelerini ve meta verileri JSON olarak çeker; kendi betiğinizi yazdığınızda da konuştuğunuz yer burasıdır. Yanıtlar kompakttır, fakat sayfalama nedeniyle istek sayısı hızla artabilir.

Üçüncüsü ses akışıdır. Uzun-form içerik tek bir devasa dosya olarak indirilmez; oynatıcı ilerledikçe parça parça çekilir. Bu, oturum boyunca düzenli aralıklarla yeni istek açılması demektir. Dördüncüsü kapak ve profil görselleridir; görsel dağıtımı için ayrı adresler kullanılır ve bu istekler oturum bilgisi taşımaz.

Proxy kuralınız bu dört hedefin hepsini kapsamıyorsa ortaya melez bir tablo çıkar: arayüz bir ülkeden, akış başka bir çıkıştan gelir. Bölgesel bir doğrulama yapıyorsanız bu melez durum sonucunuzu doğrudan geçersiz kılar.

Genel API uç noktaları ve oran sınırı davranışı

Herkese açık okuma uç noktaları, kullanıcı adı ve yayın tanımlayıcısı üzerinden adreslenir ve yanıtı JSON olarak döndürür. Listeler sayfalanır; bir sayfa sonuç aldıktan sonra bir sonraki sayfaya geçmek için ek istek gerekir. Yüzlerce yayını taramak istiyorsanız bu, yüzlerce ayrı istek anlamına gelir.

Genel servisler istek sayısını sınırlar. Sınırın ölçüm birimi çoğunlukla belirli bir zaman penceresindeki istek adedidir ve sayaç genellikle istemci adresine ya da uygulama anahtarına bağlanır. Sınır aşıldığında servisler bir hız sınırı yanıtı döndürür; HTTP standardındaki karşılığı 429 Too Many Requests olsa da bazı servisler 403 döndürüp bekleme süresini yanıt gövdesinde bildirir. İstemciniz her iki biçimi de ele almalı ve bildirilen süreye uymalıdır. Yalnızca tek bir durum koduna bakan bir istemci, sınıra takıldığını hiç fark etmeden aynı isteği tekrarlar ve durumu uzatır; doğru davranış, beklenmedik her hata yanıtını gövdesiyle birlikte kaydedip hız sınırı olup olmadığına oradan karar vermektir.

Buradan çıkan uygulama kuralı basittir: isteği yavaşlatmak, adresi değiştirmekten daha doğru bir çözümdür. Sayaç adres başına işliyorsa çok sayıda adres arasında dolaşmak sınırın etrafından geçmek anlamına gelir ve bu, servisin kullanım koşullarıyla çatışabilir. Bunun yerine eşzamanlılığı düşürün, istekler arasına bekleme koyun ve aldığınız yanıtı yerelde saklayarak aynı kaydı iki kez istemeyin.

Bir diğer ayrıntı yanıtların önbelleklenebilirliğidir. Yayın meta verisi sık değişmez; aynı kaydı saat başı yeniden istemek yerine yerelde tutup yalnızca değişiklik kontrolü yapmak istek sayısını belirgin biçimde düşürür. Sunucu koşullu isteği destekliyorsa değişmemiş bir kayıt için çok küçük bir yanıt döner; böylece hem sayaç hem bant genişliği korunur.

Erişim jetonu, çerez ve cihaz sinyalleri

Hesap adına işlem yapan çağrılar bir erişim jetonuyla yetkilendirilir. Jeton uygulamaya ve hesaba bağlıdır; çıkış adresine değil. Bu yüzden proxy’yi değiştirmek jetonu geçersiz kılmaz, jetonu yenilemek de çıkışı değiştirmez. İki mekanizma bağımsızdır ve arıza ararken ayrı ayrı sınanır.

Tarayıcı tarafında kimliği çerez taşır ve çerez profile yazılır. Bir profilde tek bir çıkış kullanmak, sorun giderirken değişken sayısını azalttığı için önerilir. Aynı profili gün içinde farklı ülkelerdeki çıkışlarla kullanmak, arayüzün bölgesel davranışını yorumlamayı imkânsız hâle getirir.

Üçüncü katman proxy’nin hiç dokunmadığı katmandır: tarayıcı sürümü, saat dilimi, dil tercihi, ekran ölçüleri ve benzeri sinyaller. Çıkışınızı Singapur’a alıp saat diliminizi yerel bırakırsanız ortaya tutarsız bir tablo çıkar. Bu katmanın nasıl hizalandığı antidetect tarayıcı ve proxy yazısında ele alınıyor. Pratikte yapılacak iş sıralıdır: önce çıkış ülkesini seçin, sonra tarayıcının saat dilimini ve dil tercihini aynı ülkeye çekin, en son oturumu açın.

• Jeton ve çerezi ayrı ayrı test edin; ikisini aynı anda değiştirmeyin.
• Bir profil için tek çıkış, tek ülke kuralını koruyun.
• Saat dilimi ve dil tercihini çıkış ülkesiyle uyumlu tutun.
• Yetkilendirme bilgilerini betiğin içine gömmeyin, ortam değişkeninde tutun.

Hangi çıkış hangi işe oturur?

Bu platformda üç ayrı iş vardır ve üçü farklı özellik ister. Genel API’den herkese açık meta veri okumak hız ve düşük maliyet ister; uzun bir yayını baştan sona dinlemek kararlı ve bol kapasiteli bir hat ister; hesapla giriş yapıp içerik yönetmek ise tutarlı ve sabit bir adres ister.

Veri merkezi adresleri birinci iş için en verimli seçenektir: bağlantı kurulumu hızlıdır, aktarım kapasitesi yüksektir ve maliyeti düşüktür. Uzun akış dinlemede de sorunsuz çalışırlar; asıl sınırları oturum açılan senaryolardadır, çünkü adresin hangi otonom sisteme ait olduğu açıkça görünür.

Sağlayıcı ağında barındırılan sabit adresler ile gerçek abone havuzları, oturumlu kullanımda en tutarlı sonucu verir. Bunların veri ücreti daha yüksektir, bu yüzden saatlerce akış dinlemek için kullanmak pahalıya mal olur. Operatör ağı adresleri ise mobil davranışın doğrulanması gereken durumlarda anlamlıdır; yüksek hacimli okuma için ekonomik değildir.

Aşağıdaki matris bu üç işi üç çıkış ailesiyle eşleştiriyor. Aynı sağlayıcıda birden fazla tür varsa işi türe göre bölmek, tek bir türe her işi yaptırmaktan hem daha ucuz hem daha kararlıdır.