SOCKS ve HTTP Proxy Sunucuları: Farklar, Hız ve Protokol Seçimi
HTTP ve SOCKS proxy sunucuları, uygulamayı aracı üzerinden hedefe bağlar. Tarayıcı, veri kazıma aracı veya API istemcisi için CONNECT destekli HTTP proxy pratik bir başlangıçtır. Uygulama SOCKS bekliyorsa, başka TCP protokolleri gerekiyorsa veya UDP iletimini destekliyorsa SOCKS5 yararlıdır. İkisi de HTTPS sitelerine trafik taşıyabilir.
Protokol, programın proxy sunucusuyla nasıl konuştuğunu belirler. Çıkış IP adresinin kökeni, rotasyon ve paylaşımlı ya da adanmış erişim, proxy türleri ve kurulum seçimi rehberinde açıklanan ayrı seçimlerdir. HTTP’den SOCKS’a geçmek tek başına bu özellikleri değiştirmez.
HTTP ve SOCKS bağlantıyı nasıl işler?
HTTP iletimi: proxy sunucusu web isteğini işler
Olağan şifrelenmemiş HTTP isteğinde istemci proxy sunucusuna hedef URL’yi, yöntemi ve başlıkları gönderir. Proxy sunucusu isteği işler ve hedeften yanıtı alır. Bu şekilde yapılandırılmışsa HTTP kuralları uygulayabilir, başlıkları değiştirebilir veya önbellek kullanabilir. Bunlar HTTP proxy’nin olası işlevleridir; hizmet hepsini etkinleştirmek zorunda değildir.
SOCKS5: proxy sunucusu uygulama için bağlantı açar
İstemci bir kimlik doğrulama yöntemi üzerinde uzlaşır, gerekiyorsa kimliğini doğrular ve hedef adresiyle portu sağlar. Proxy sunucusu istenen TCP bağlantısını kurup uygulamanın baytlarını aktarır. Aynı mekanizma HTTPS, SSH veya desteklenen başka TCP uygulama protokolünü taşıyabilir. İletmek için HTTP isteklerini yorumlaması gerekmez.
CONNECT üzerinden HTTPS: iki yaklaşım birbirine yaklaşır
Geleneksel HTTP proxy üzerinden HTTPS sitesi açarken istemci normalde CONNECT isteği gönderir. Proxy sunucusu tüneli kabul ettikten sonra istemci onun içinde siteyle TLS kurar. Proxy sunucusu şifrelenmiş veriyi aktarır. SOCKS5, kendi kurulumundan sonra aynı TLS alışverişini aktarabilir.
Hız ve gizlilik karşılaştırmasında bu önemlidir: HTTPS’yi tünelde taşıyan HTTP proxy, her şifrelenmiş sayfa isteğini ayrıştırmaz. Her iki tür korunan trafiği aktarır. İşlem sırası ve HTTP iletimiyle tünelleme arasındaki ayrım HTTP ve HTTPS proxy sunucuları makalesinde açıklanır.
Bir bakışta HTTP ve SOCKS5
Aşağıdaki karşılaştırma SOCKS5’i kullanır. Daha eski SOCKS4 ve SOCKS4a daha sınırlı yeteneklere sahiptir ve esas olarak mevcut yazılım bunları gerektirdiğinde önem taşır.
| Yetenek | HTTP / HTTPS proxy | SOCKS5 proxy |
|---|---|---|
| Web istekleri | HTTP iletimi; HTTPS genellikle CONNECT tüneli kullanır. | Uygulama kurulmuş bağlantıdan HTTP veya HTTPS gönderir. |
| Diğer TCP uygulamaları | İstemci destekliyorsa ve hedef porta izin veriliyorsa CONNECT üzerinden mümkündür. | SOCKS destekli uygulamalara doğal olarak uygundur; hizmet kuralları yine geçerlidir. |
| Hedef DNS çözümlemesi | Proxy sunucusu, istekte veya CONNECT hedefinde verilen ana makine adını çözümleyebilir. | İstemci uzaktan çözümleme için ana makine adını gönderebilir veya önce yerelde çözümleyebilir. |
| Proxy sunucusuna kadar koruma | HTTPS proxy bu bağlantıda TLS kullanır. Düz HTTP proxy kullanmaz. | Olağan kimlik doğrulamasız ve kullanıcı adı/parola modları bu bağlantıyı şifrelemez. |
| Erişim kontrolü | HTTP kimlik doğrulama yöntemleri ve/veya izin verilen IP adresleri listesi gibi hizmet erişim kuralları. | Üzerinde uzlaşılan kimlik doğrulama yöntemleri ve/veya izin verilen IP adresleri listesi gibi hizmet erişim kuralları. |
| UDP | Olağan CONNECT yeterli değildir. UDP için desteklenen ek tünelleme mekanizması gerekir. | Protokolde tanımlıdır, ancak istemci ve hizmet tarafından uygulanmalıdır. |
| Performans | Yeni HTTPS tünelinde kurulum daha az gidiş dönüş sürebilir. Aktarım hızı uygulamaya ve rotaya da bağlıdır. | Kendi kurulum alışverişleri vardır. HTTP ayrıştırmasının olmaması daha hızlı HTTPS aktarımı garantilemez. |
Hangisi daha hızlı: HTTP mi SOCKS5 mi?
Olağan kurulum proxy sunucusuyla daha az alışveriş gerektirdiği için yeni HTTPS bağlantısı HTTP CONNECT üzerinden daha erken hazır olabilir. Aşağıdaki karşılaştırma bu farkın arkasındaki varsayımları gösterir. Tünel açıldıktan sonra uzun indirme veya sonraki istekler onu yeniden kullanabilir. Hiçbir protokol sürekli aktarım hızında sabit bir üstünlüğe sahip değildir.
Yeni bağlantılar: alışverişleri sayın
Proxy sunucusuna TCP bağlantısı hazır olduktan sonraki kurulum iletilerini, her isteğin yanıtını beklediği durumda sayın. Bu karşılaştırmada proxy sunucusuna TLS katmanı yoktur. HTTP kimlik doğrulaması ya gereksizdir ya da ilk CONNECT isteğine eklenen erişim bilgileriyle başarılıdır.
| Bağlantı yöntemi | Tünel hazır olana kadarki alışverişler |
|---|---|
HTTP CONNECT | 1: CONNECT isteği ve başarılı yanıtı. |
| Protokol kimlik doğrulaması olmadan SOCKS5 | 2: yöntem seçimi, ardından bağlantı isteği ve yanıtı. |
| Kullanıcı adı ve parolayla SOCKS5 | 3: yöntem seçimi, kullanıcı adı/parola doğrulaması, ardından bağlantı isteği ve yanıtı. |
Dolayısıyla bu varsayımlar altında SOCKS5, kimlik doğrulamasız durumda istemci ile proxy arasında bir, standart kullanıcı adı/parola doğrulamasında iki ek gidiş dönüş getirir. Gidiş dönüş süresi, yani RTT, iletinin proxy sunucusuna ulaşıp yanıtının dönmesi için geçen süredir. Örnek RTT 50 ms olduğunda ek alışverişler yaklaşık 50 veya 100 ms getirir. Bu, protokol sırasından hesaplanan tahmindir; proxy hizmetinin kıyaslama testi veya toplam istek süresi değildir.
Her iki yol da proxy sunucusunun hedefe bağlanmasını ve istemcinin sitenin TLS kurulumunu tamamlamasını gerektirir. DNS süresi, işlem ve yoğunluk farklı olabilir. HTTP kimlik doğrulama sorgusu ek alışveriş getirir; HTTPS proxy sunucusuna TLS kendi kurulumunu ekler. Gerçek yapılandırmalar karşılaştırılırken bu durumlar dahil edilmelidir.
Yeniden kullanılan bağlantılar: ilk fark isteklere dağılır
Bağlantı havuzu, uygun bağlantıları sonraki istekler için kullanılabilir tutar. HTTPS bağlantısını yeniden kullanmak, her istek için TCP, proxy uzlaşması ve sitenin TLS el sıkışmasının tekrarlanmasını önler. İstemci ve hedef HTTP/2 destekliyorsa birden fazla istek akışı kurulmuş tek bağlantıyı paylaşabilir. Bu, HTTP CONNECT tünelinde de SOCKS5 bağlantısında da çalışabilir; proxy sunucusunun TLS içindeki HTTP/2 iletilerini ayrıştırması gerekmez.
Her URL için yeni HTTP istemci nesnesi oluşturmak bağlantı havuzunu kaybettirebilir. Burada istemciyi yeniden kullanmak, proxy sunucusundan çıkış IP adresini korumasını istemek değil, yazılım nesnesini ve bağlantılarını tutmaktır. Toplu iş aynı ana makinelere tekrar tekrar erişiyorsa bağlantıları yeniden kullanmak, proxy protokolü değiştirmekten daha fazla kurulum işini önleyebilir. Yeni hedefler, kapanmış bağlantılar ve değişen proxy ayarları yine yeni tünel gerektirebilir.
Büyük aktarımlar: kullanılabilir bant genişliğine bakın
Tünel kurulduktan sonra indirme hızı rotaya, paket kaybına, kullanılabilir bant genişliğine, proxy yüküne ve hizmet sınırlarına bağlıdır. HTTPS’yi CONNECT üzerinden aktarmak zaten bayt iletme işidir. SOCKS5’i “HTTP okumadığı” için daha hızlı diye tanımlamak bu durumu gözden kaçırır.
Şifrelenmemiş HTTP’de yapılandırılmış önbellekleme veya içerik işleme sonucu değiştirebilir. Önbellekteki yanıt, aynı içeriği kaynak sunucudan indirmekten farklı iş yüküdür. Adil karşılaştırma bu farkı hesaba katmalıdır.
Büyük bir web betiği hangi protokolü kullanmalı?
Web betiği SOCKS5 kullanırken de HTTP istekleri yapar; proxy seçeneği sunucuya nasıl ulaştığını değiştirir. Web sayfaları alan veya HTTPS API çağıran yeni betikte, belirli gereksinim başka yöne işaret etmiyorsa olgun bir HTTP istemcisi ve HTTP CONNECT ile başlayın. Aynı istek mantığıyla SOCKS5’i test edebilmek için proxy seçimini yapılandırmada tutun. Bu karşılaştırma proje için önemliyse ikisini de destekleyen kitaplık seçin.
| İş yükü | Pratik başlangıç noktası |
|---|---|
| Çoğu kez yeni ana makinelere çok sayıda kısa istek | Önce HTTP CONNECT deneyin. Sık yeni tünel açılıyorsa kısa uzlaşması yardımcı olabilir. Tamamlanan başarılı istekleri ölçün. |
| Küçük bir API veya site kümesine çok sayıda istek | Kalıcı istemci, bağlantı havuzu ve destekleniyorsa HTTP/2 kullanın. Yeniden kullanımı kontrol ettikten sonra HTTP ile SOCKS5’i karşılaştırın. |
| Büyük dosyalar veya uzun ömürlü TCP oturumları | İyi desteklenen protokolü seçip sürekli aktarım hızını ve kesintileri test edin. Kurulum süresi işin daha küçük bölümüdür. |
| Diğer TCP protokolleri veya gerekli UDP özelliği | Uygulama gereken modu destekliyorsa SOCKS5’i değerlendirin. UDP zorunluysa uygulama ve hizmetin proxy sunucusu üzerinden datagram alışverişi yapabildiğini doğrulayın. |
Hem HTTP hem SOCKS5 asenkron yazılımla kullanılabilir. İsteklerin eşzamanlı çalışıp çalışmadığını proxy protokolü belirlemez. İstemci kitaplığının seçilen proxy modunu eşzamanlı isteklerde kullanabildiğini, bağlantı havuzunu koruyabildiğini ve süren işlem sayısını sınırlayabildiğini kontrol edin. Tamamlanan işleri ve hataları izleyerek eşzamanlılığı artırın: Proxy sunucusu, ağ veya hedef sınırına ulaştığında daha çok bağlantı, daha uzun kuyruk ve daha çok yeniden deneme anlamına gelebilir.
Ölçeği büyütmeden önce hız nasıl karşılaştırılır?
- Aynı programı, hedef istekleri, yanıt boyutlarını ve eşzamanlılığı kullanın. Mümkünse protokol uç noktalarını aynı çıkış IP adresi ve rotayla karşılaştırın; değilse çıkış bölgesini ve hizmet sınırlarını karşılaştırılabilir tutup farkı kaydedin.
- Bir seriyi yeni bağlantılarla, diğerini ısınma sonrasında normal havuz kullanımıyla çalıştırın. DNS davranışını, TLS korumasını, kimlik doğrulamasını, HTTP sürümünü ve yeniden deneme politikasını eşdeğer tutun veya neden farklı olduklarını belgeleyin.
- Saniyede başarıyla tamamlanan işlemleri ve yeniden denemeler dahil tüm grubun süresini ölçün. Medyan ve 95. yüzdelik tamamlanma süresini, zaman aşımlarını ve başarısız işlemleri de kaydedin. 95. yüzdelik, ölçülen işlemlerin %95’inin tamamlandığı süreyi gösterir.
- İndirmelerde saniyede alınan yararlı baytları kaydedin. Kısa isteklerde bağlantı kurulumunu, ilk bayta kadar geçen süreden ve tam yanıt süresinden ayırın. İlk bayta kadar geçen süre, hedefin yanıt üretmesini beklemeyi de içerir.
- Her iki yapılandırmayı dönüşümlü çalıştırarak tekrarlayın ve amaçlanan proxy rotasını doğrulayın. Bir test farklı çıkış havuzu kullanıyor veya doğrudan bağlantıya dönüyorsa sonucu proxy protokolünü tek başına ölçmez.
Gerçek işi kabul edilebilir hata oranıyla daha hızlı tamamlayan yapılandırmayı seçin. Hızlı kimlik doğrulama hatası veya eksik yanıt, yararlı iş hacmi değildir. Performans benzerse seçilen uygulamada desteği daha basit olanı tercih edin.
Uygulama desteği neden önce gelir?
“Proxy” etiketli alan her protokolü veya kimlik doğrulama yöntemini vaat etmez. Örneğin Chrome’un yerleşik SOCKS5 desteği TCP isteklerini destekler, ancak SOCKS5 kullanıcı adı/parola doğrulamasını veya UDP iletimini uygulamaz. Bu özellikleri olan SOCKS5 hizmeti, desteklemeyen tarayıcı moduna bunları kullandıramaz.
SSH, dosya aktarımı veya başka TCP uygulamalarında yerleşik SOCKS desteği kullanışlı olabilir. Program tüneli oluşturabiliyorsa ve proxy sunucusu hedef porta izin veriyorsa HTTP CONNECT başka TCP protokollerini de taşıyabilir. Dolayısıyla “HTTP proxy” her zaman “yalnızca web trafiği” demek değildir.
Tarayıcı proxy ayarları başka programı veya tarayıcının her özelliğini otomatik kapsamaz. Dış bağdaştırıcıların kendi kapsam ve kısıtlamaları vardır. Sürüm farkları ve uzlaşma, SOCKS5 ve SOCKS4 proxy sunucuları makalesinde ele alınır.
Hedef ana makine adını kim çözümler?
SOCKS5’te uygulama hedefi yerelde çözümleyip IP adresi gönderebilir veya çözümlemesi için proxy sunucusuna ana makine adı gönderebilir. curl’de socks5:// yerel hedef çözümlemesini seçer, socks5h:// ise proxy üzerinden çözümleme ister. Ek harf istemci davranışını seçer; yeni SOCKS protokolü oluşturmaz.
HTTP proxy sunucuları da URL’lerde veya CONNECT isteklerinde aldıkları hedef adlarını çözümleyebilir. Dolayısıyla uzaktan hedef DNS çözümlemesi her iki protokolde vardır. Proxy tarafındaki sorgu farklı sunucu adresi döndürebilir ve o hedef için yerel sorguyu önler. İstemcinin proxy sunucusunun kendi ana makine adını yine çözümlemesi gerekebilir; diğer uygulamalar kendi DNS ayarlarını korur. DNS davranışını proxy protokolünden çıkarsamak yerine istemcide seçin.
Hangi bağlantı şifrelenir?
Site içeriğinin korunmasını proxy sunucusuna bağlantının korunmasından ayırın. HTTPS sitesi normalde her iki tünel türünde de uygulama verisini istemciyle site arasında şifreli tutar. Bu, normal sertifika doğrulamasını ve yapılandırılmış TLS müdahalesi bulunmamasını varsayar.
HTTPS proxy, istemciyle proxy sunucusu arasına TLS ekler. Rotanın bu bölümünde proxy isteğini ve erişim bilgilerini korur. Proxy adresindeki https:// normalde bu korunan bağlantıyı belirtir. Yalnızca “HTTPS siteleri için proxy” diye tanımlanan ayar ise CONNECT destekli düz HTTP proxy anlamına gelebilir.
Düz HTTP proxy sunucusuna gönderilen HTTP Basic erişim bilgileri ve standart SOCKS5 kullanıcı adı/parola alışverişi, korunmayan bu ağ yolunu gözlemleyebilen biri tarafından okunabilir. Sonradan web sitesine kurulan TLS bağlantısı proxy girişini geriye dönük korumaz. Bu koruma gerektiğinde olağan SOCKS5 ayrı güvenli taşıma gerektirir.
Proxy sunucusu kendi TLS bağlantısının bir ucu olmaya devam eder ve nereye bağlanmasının istendiğini bilir. Son hedef düz HTTP kullanıyorsa proxy sunucusuna kadar TLS, sonraki HTTP bağlantısını şifrelemez. Benzer şekilde SOCKS iletimi de proxy sunucusunun ayrıştırması gerekmediği için açık metin içeriği gizlemez.
UDP veya HTTP/3 seçimi değiştirir mi?
Gerçekten UDP gerektiren uygulamalar için SOCKS5 UDP ASSOCIATE tanımlar. İstemciyle hizmet bunu uygulamalı, ağ yolu da datagramları taşımalıdır. Olağan HTTP CONNECT TCP tüneli taşır. HTTP tabanlı UDP iletimi, CONNECT-UDP gibi ek mekanizmalarla mümkündür; ancak iki uç da bunları uygulamalıdır.
HTTP/3, UDP üzerinden QUIC kullanır. HTTPS sayfasının proxy üzerinden başarıyla yüklenmesi HTTP/3’ün çalıştığını kanıtlamaz: İstemci TCP üzerinden HTTP/2 veya HTTP/1.1 kullanmış olabilir. Bu geri dönüş web betiğine uygun olabilir; datagram gerektiren özellikte UDP’nin yerini alamaz. İletim yolları ve sınırlamaları için Proxy Üzerinden UDP ve QUIC makalesine bakın.
SOCKS istemciyi daha iyi gizler mi?
Şifrelenmemiş HTTP iletiminde proxy sunucusu, ilk istemci hakkında bilgi taşıyan Forwarded gibi başlık ekleyebilir. Geleneksel HTTPS CONNECT tüneli, sitenin TLS bağlantısını sonlandırmadan şifreli isteğe bu başlığı ekleyemez. SOCKS5 de otomatik HTTP başlıkları eklemez.
Bu, hiçbir protokolü anonimlik veya web sitesi tarafından kabul garantisi yapmaz. Proxy işletmecisi bağlantı meta verilerini gözlemleyebilir; hedef ise hesabı, çerezleri veya uygulama davranışını tanıyabilir. Çıkış IP itibarı ve onu paylaşan kullanıcı sayısı ayrı etkenlerdir. Aynı hizmette HTTP’den SOCKS’a geçmek engelleri otomatik kaldırmaz veya web sitesi oturumunu sıfırlamaz.
Son seçim nasıl yapılır?
Uygulamanın desteklediği protokoller ve erişim yöntemleriyle başlayın. Olağan web otomasyonunda HTTP CONNECT sağlam bir ilk seçenektir; SOCKS veya desteklenen UDP modu etrafında geliştirilmiş uygulamada SOCKS5 daha uygun olabilir. Ardından gereken DNS davranışını ve proxy sunucusuna kadar korumayı seçip gerçek iş yüküyle performansı karşılaştırın.
Seçilen protokol için hizmetin gerçek ana makine adını ve portunu kullanın. Yapılandırmada http:// yerine socks5:// yazmak, SOCKS sağlamayan sunucuda onu etkinleştirmez. Ölçeği büyütmeden önce isteklerin beklenen proxy üzerinden çıktığını ve proxy hatasının sessizce istenmeyen doğrudan rotayı tetiklemediğini doğrulayın.