Proxy'm neden yavaş: teşhis ve hız optimizasyonu

Proxy yavaşlığı genellikle coğrafi mesafeden kaynaklanan yüksek gecikmenin, TLS el sıkışması sırasındaki protokol yükünün veya residential peer-to-peer ağdaki tıkanıklığın birleşiminden doğar. Bu performans darboğazlarını çözmek, ağ üzerindeki transit süreleri sunucu tarafındaki işleme gecikmelerinden ayıran sistematik bir teşhis yaklaşımı gerektirir; ancak böylece en iyi veri aktarım hızına ulaşılır.

Temel metrikleri anlamak: gecikme ve aktarım hızı

Yavaş bir proxy'yi teşhis etmek için önce gecikme (latency) ile aktarım hızını (throughput) birbirinden ayırmanız gerekir. Bu iki metrik sık sık birbirine karıştırılır ama proxy ortamında farklı teknik zorlukları temsil eder.

• Gecikme (Ping): Tek bir paketin istemcinizden proxy sunucusuna, oradan hedef siteye ve tekrar geri dönmesi için geçen süredir. Milisaniye (ms) cinsinden ölçülür. Yüksek gecikme, "ağır ilerleyen" gezinmenin veya otomatik betiklerdeki yavaş yanıt sürelerinin başlıca nedenidir.
• Aktarım hızı (Bant genişliği): Belirli bir sürede aktarılan veri miktarıdır, genellikle Mbps veya MB/s cinsinden ölçülür. Düşük gecikmeli bir bağlantınız olmasına rağmen aktarım hızınız kötü olabilir; bu, residential bir düğümün yükleme hızı sınırlı olduğunda sık görülür.
• Time to First Byte (TTFB): Web scraping ve otomasyon için en kritik metrik budur. İlk HTTP isteğinden sunucudan ilk veri baytının alınmasına kadar geçen süreyi ölçer.

GProxy gibi bir hizmet kullanırken gecikme çoğu zaman verinizin yaptığı "sıçramalardan" (hop) etkilenir. Standart bir bağlantıda veriniz doğrudan hedefe gider. Proxy ile yolculuğa en az iki ek ayak eklersiniz: İstemci → Proxy ağ geçidi → Çıkış düğümü → Hedef site. Çıkış düğümü Tokyo'da, istemciniz Londra'da ve hedef sunucu New York'ta ise ışık hızı, hiçbir yazılım optimizasyonunun tümüyle aşamayacağı fiziksel bir sınıra dönüşür.

Proxy performans düşüşünün kök nedenleri

Bir proxy'nin neden beklenenin altında çalıştığını belirlemek, bağlantı yığınının dört ayrı katmanına bakmayı gerektirir: yerel ortam, proxy sağlayıcısının altyapısı, çıkış düğümünün sağlığı ve hedef sunucunun sınırlamaları.

1. Coğrafi uyumsuzluk

Proxy çıkış düğümü ile hedef sunucu arasındaki fiziksel mesafe, yüksek gecikmenin başlıca nedenidir. Hindistan'ın kırsalında bulunan bir residential proxy ile ABD merkezli bir perakende sitesinden veri çekiyorsanız, gidiş-dönüş süresi (RTT) doğal olarak 300-400ms'yi aşacaktır. Yüksek hızlı işlemler için her zaman hedef sunucunun veri merkeziyle aynı bölgede veya ülkede bulunan çıkış düğümlerini seçin.

2. Protokol yükü (HTTP ve SOCKS5)

Seçtiğiniz protokol, verinin nasıl paketleneceğini belirler. HTTP proxy'ler üst seviyedir ve genellikle proxy sunucusu düzeyinde daha fazla işlem gerektirir. SOCKS5 ise her türlü trafiği (TCP/UDP) taşıyan daha alt seviye bir protokoldür ve ağ geçidi düzeyinde HTTP başlıklarını ayrıştırmak zorunda olmadığı için yüksek eşzamanlılık gerektiren görevlerde genelde daha iyi performans sunar.

3. Residential düğüm kararlılığı

Residential proxy'ler gerçek hanelere atanmış IP adreslerini kullanır. Kontrollü ortamlarda yüksek hızlı fiber hatlar üzerinde duran veri merkezi proxy'lerinin aksine, residential düğümler ev tipi ISP bağlantılarına dayanır. IP'yi sağlayan "peer" tıkalı bir Wi-Fi ağı kullanıyorsa veya yükleme bant genişliği sınırlıysa, sağlayıcının omurga kapasitesi ne olursa olsun proxy hızınız düşecektir.

4. ISP kısıtlaması ve peering sorunları

Bazen darboğaz kendi ISP'nizdir. Bazı internet servis sağlayıcıları şifreli trafiği kısıtlar veya proxy ağ geçitlerinin barındırıldığı veri merkezleriyle kötü peering anlaşmalarına sahiptir. Bu durum "paket kaybına" yol açar; TCP protokolü verileri yeniden göndermek zorunda kalır ve algılanan hızınız fiilen yarıya iner.

Teşhis yöntemi: proxy hızınızı nasıl test edersiniz

Proxy etkinken tarayıcı tabanlı hız testlerine (Speedtest.net gibi) güvenmeyin. Bu testler doğrudan ISP bağlantıları için tasarlanmıştır ve çok iş parçacıklı indirmeleri ele alma biçimleri nedeniyle çoğu zaman yanıltıcı sonuçlar verir. Bunun yerine ham veriyi almak için komut satırı araçlarını ve kendi betiklerinizi kullanın.

Hassas ölçüm için cURL kullanımı

curl komutu, belirli zamanlama değişkenlerini çıktı olarak verebildiği için proxy hızını teşhis etmede altın standarttır. Gecikmenin nerede oluştuğunu görmek için aşağıdaki komutu kullanın:

# Bu bir shell komutudur, netlik için biçimlendirilmiştir
curl -x "http://username:[email protected]:8000" \
     -o /dev/null -s -w \
     "Connect: %{time_connect}\nTTFB: %{time_starttransfer}\nTotal: %{time_total}\n" \
     "https://api.target-website.com/v1/data"

Bu çıktıda:

• time_connect: Proxy ağ geçidine TCP bağlantısı kurmak için geçen süre.
• time_starttransfer: İlk baytın gelmesine kadar geçen süre (proxy'nin hedefe olan yolculuğunu da içerir).
• time_total: İsteğin toplam süresi.

Python ile otomatik kıyaslama

Büyük proxy havuzlarını yönetenler için tek bir test yeterli değildir. Birden fazla düğüm genelinde istatistiksel ortalamayı ölçmeniz gerekir. Aşağıdaki Python betiği, birden fazla proxy'nin performansını eşzamanlı ölçmek için aiohttp kullanır.

import asyncio
import time
import aiohttp

async def test_proxy(session, proxy_url):
    start = time.perf_counter()
    try:
        async with session.get('https://httpbin.org/ip', proxy=proxy_url, timeout=10) as resp:
            status = resp.status
            await resp.text()
            end = time.perf_counter()
            return end - start, status
    except Exception as e:
        return None, str(e)

async def main():
    proxies = [
        "http://user:[email protected]:8000",
        "http://user:[email protected]:8000",
        # Buraya daha fazla proxy ekleyin
    ]

    async with aiohttp.ClientSession() as session:
        tasks = [test_proxy(session, p) for p in proxies]
        results = await asyncio.gather(*tasks)

        for i, (duration, status) in enumerate(results):
            if duration:
                print(f"Proxy {i}: {duration:.2f}s (Status: {status})")
            else:
                print(f"Proxy {i}: Failed ({status})")

if __name__ == "__main__":
    asyncio.run(main())

Yüksek performanslı proxy kullanımı için optimizasyon stratejileri

Yavaşlığın kaynağını teşhis ettikten sonra, hızı geri kazanmak için belirli mimari değişiklikler uygulayabilirsiniz. Optimizasyon nadiren tek bir "sihirli ayar" meselesidir; daha çok bağlantının birikmiş yükünü azaltmakla ilgilidir.

1. Bağlantı havuzu (Keep-Alive) uygulayın

Bir proxy isteğinin en maliyetli kısımlarından biri ilk el sıkışmadır. Bu; DNS çözümlemesini, TCP bağlantısının kurulmasını ve TLS (SSL) el sıkışmasını içerir. Her istek için yeni bir bağlantı açıyorsanız, her seferinde 200-500ms boşa harcıyorsunuz demektir.

HTTP Keep-Alive kullanarak aynı alttaki TCP bağlantısını birden fazla istek için yeniden kullanırsınız. Python'un requests kütüphanesinde bu, bir Session() nesnesi kullanılarak otomatik olarak yapılır. Yüksek eşzamanlılık ortamlarında bağlantı havuzunuzun yükü yeni el sıkışmalara zorlamadan karşılayacak kadar büyük olduğundan emin olun.

2. Coğrafi hedefleme ve yönlendirme

GProxy ayrıntılı hedeflemeye izin verir. Hedef sunucunuz AWS us-east-1'de (Kuzey Virginia) barındırılıyorsa, özellikle Virginia'daki veya komşu eyaletlerdeki proxy'leri talep etmelisiniz. Bu, "backhaul" gecikmesini azaltır.

3. Web dışı trafik için SOCKS5 kullanın

Proxy'leri HTTP/HTTPS dışındaki protokoller için (FTP, SMTP veya özel soket tabanlı araçlar gibi) kullanıyorsanız SOCKS5 zorunludur. SOCKS5 daha verimlidir çünkü uygulama katmanında paket başlıklarını yeniden yazmaz. Web trafiğinde bile bazı geliştiriciler, binlerce eşzamanlı iş parçacığı yönetilirken SOCKS5'in istemci tarafındaki CPU yükünü azalttığını görür.

4. Veri aktarımını en aza indirin

Çoğu zaman "yavaş proxy'ler" aslında sadece "büyük sayfalardır". Scraping yapıyorsanız algılanan performansı şöyle hızlandırın:

• Headless tarayıcılarda (Puppeteer/Selenium) görsel yüklemeyi kapatın.
• CSS ve font dosyalarını engelleyin.
• Veri yükünü sıkıştırmak için Accept-Encoding: gzip, deflate başlıklarını kullanın.
• Tam HTML sayfasını render etmek yerine yalnızca ilgili API uç noktalarını talep edin.

İleri düzey teknik düzeltmeler: TCP ayarı ve eşzamanlılık

Kurumsal ölçekli dağıtımlarda darboğaz, işletim sisteminizin ağ soketlerini ele alma biçimi olabilir. Varsayılan olarak birçok Linux dağıtımı, büyük ölçekli proxy operasyonlarının gerektirdiği on binlerce eşzamanlı bağlantı için optimize edilmemiştir.

File descriptor sayısını artırma

Her proxy bağlantısı Linux gözünde bir "dosyadır". Limitiniz varsayılan 1024'te kalırsa, betiğiniz soketlerin kapanmasını beklerken takılır veya yavaşlar. Bu limitleri /etc/security/limits.conf dosyasında artırın:

* soft nofile 100000
* hard nofile 100000

DNS optimizasyonu

Bazen "yavaşlık" yalnızca yavaş bir DNS sorgusudur. Proxy'niz için bir hostname veriyorsanız (örneğin proxy.gproxy.com), sisteminiz her bağlantıdan önce bu IP'yi çözmek zorundadır. Ağ geçidi IP adresini sabit yazmak veya dnsmasq gibi yerel bir DNS önbelleği kullanmak her yeni bağlantı denemesinden 20-50ms kazandırabilir.

Eşzamanlılık ve hız sınırlama

Eşzamanlılığın bir ideal noktası vardır. Tek bir residential düğüm üzerinden çok fazla istek gönderirseniz, düğümün yerel yönlendiricisi paketleri düşürmeye başlayabilir (Bufferbloat). Daha yüksek hıza ihtiyacınız varsa tek bir IP'den daha fazla veri geçirmeye çalışmayın; bunun yerine rotasyon sıklığınızı artırın. Yükü aynı anda 500 GProxy residential IP'ye dağıtarak, tek bir IP'yi veri merkezi hattı gibi davranmaya zorlamaktan çok daha yüksek bir toplam aktarım hızı elde edersiniz.

Önemli çıkarımlar

Proxy hızını teşhis etmek bir eleme sürecidir. Bağlantının her bir bölümünü sistemli biçimde test ederek "yavaş" demekten "çıkış düğümünde 300ms gecikme var" demeye geçebilirsiniz. Optimizasyon; fiziksel mesafeyi azaltmak, bağlantıları yeniden kullanmak ve iş için doğru aracı seçmektir.

• Coğrafyayı eşleştirin: Verinin kat etmesi gereken fiziksel mesafeyi en aza indirmek için her zaman hedef sunucuyla aynı bölgedeki proxy çıkış düğümlerini seçin.
• Bağlantıları yeniden kullanın: Her istekte zaman alan TCP/TLS el sıkışmasından kaçınmak için kodunuzda oturum nesneleri aracılığıyla HTTP Keep-Alive uygulayın.
• TTFB'yi izleyin: Özellikle scraping ve otomasyonda, toplam indirme hızı yerine birincil performans metriği olarak Time to First Byte'a odaklanın.

Pratik ipucu 1: Hız mutlak önceliğinizse ve agresif bot tespitiyle karşılaşmıyorsanız, ham aktarım hızında 5-10 kat artış için GProxy'nin residential proxy'lerinden veri merkezi veya ISP proxy'lerine geçin.

Pratik ipucu 2: Proxy havuzunuzun sağlığını kıyaslamak için cURL teşhis komutunu haftalık olarak kullanın. time_connect değerindeki ani sıçramalar genellikle yerel ağ sorunlarına veya ISP kısıtlamasına işaret ederken, time_starttransfer değerindeki sıçramalar proxy sağlayıcısının ağının veya hedef sitenin tıkalı olduğunu gösterir.