HTTP ve SOCKS5 Proxy Karşılaştırması: El Sıkışma Süreci ve İletişim Özellikleri

Bu iki protokolün karşılaştırıldığı hemen hemen her analizde hız ve güvenlik açısından puanlar veriliyor ve bu puanların neredeyse tamamı uydurma. Her iki protokol de bağlantının nasıl açılacağı konusunda anlaşmak için birkaç bayt harcıyor ve ardından tamamen arka planda kalıyor. Asıl fark, bu baytlar sırasında neler olduğunda ortaya çıkıyor — ve bilmeye değer tam olarak üç sonuç var.

HTTP Proxy Aslında İki Farklı Şeydir

“HTTP proxy” ifadesi, karşılaştırma makalelerinde genellikle birbirine karıştırılan iki davranışı ifade eder. Birincisinde, istemci, istek satırında yol yerine mutlak bir URI içeren sıradan bir istek gönderir ve proxy bu sürece tam olarak katılır: başlıklarınızı ayrıştırır, yanıtı önbelleğe alabilir, filtreleyebilir ve kendi başlıklarını ekleyebilir — kendisini belirten bir Via başlığı, adresinizi içeren bir X-Forwarded-For başlığı gibi. Bu bir yönlendirme proxy’sidir ve her şeyi okur.

İkinci durumda ise istemci, URL yerine bir ana bilgisayar ve bağlantı noktası bilgisi içeren bir CONNECT isteği gönderir ve proxy’den HTTP sürecine katılmamasını ister. RFC 9110, bundan sonra neler olacağını alışılmadık derecede sade bir dille tanımlar: 2xx yanıtından sonra proxy, mesajları değiştirmeden iki bağlantı arasında kör bir aktarıcı görevi gören bir tünel haline gelir ve tünel aktif hale geldiğinde HTTP iletişiminin bir tarafı olarak hiç kabul edilmez. Spesifikasyon, bu mekanizmanın temelini, paylaşılan bir güvenlik duvarı proxy'si üzerinden TLS'yi aktarmak olarak bile adlandırmaktadır.

> CONNECT example.com:443 HTTP/1.1
> Host: example.com:443
>
< HTTP/1.1 200 Connection established
<
  ... every byte after this line is relayed untouched ...

Bu ayrım, standart karşılaştırmanın ne kadarının geçerliliğini koruduğunu belirler. Artık esasen tüm trafik HTTPS olduğu için, aslında kullandığınız HTTP proxy'si, yönlendirme proxy'si değil, tüneldir — bu da, HTTP ile SOCKS5'i karşılaştıran çoğu makalenin HTTP tarafına atfettiği önbellekleme, başlık yeniden yazma ve içerik filtreleme işlemlerinin, gerçekte açacağınız bağlantıya hiç uygulanmayacağı anlamına gelir. Bunlar, düz metin taşıyan bir yönlendirme proxy'sinin gerçek yetenekleridir ve yapısı gereği bir tünelde ulaşılamazlar.

SOCKS5 El Sıkışma Süreci, Bayt Bayt

RFC 1928’de tanımlanan SOCKS5, taşıdığı protokolün ne olduğunu hiçbir zaman öğrenmez. İletişim, bir selamlama ile başlar: istemci bir sürüm baytı, desteklediği kimlik doğrulama yöntemlerinin sayısını ve yöntem kodlarını gönderir. Sunucu, sürüm ve seçtiği tek yöntem olmak üzere iki bayt ile yanıt verir. Eğer 0xFF yanıtı verirse, kabul edilebilir hiçbir yöntem bulunmamaktadır ve istemci bağlantıyı kapatmalıdır.

Ardından istemci, bir komutun adını belirten bir istek gönderir: Giden bir TCP bağlantısı için 0x01 CONNECT, gelen bir bağlantı için 0x02 BIND veya 0x03 UDP ASSOCIATE. Aynı istek, bir adres türü baytı (ATYP) içerir; bu bayt, dört oktetlik bir IPv4 adresi için 0x01, ilk okteti uzunluğu olan bir alan adı için 0x03 veya on altı oktetlik bir IPv6 adresi için 0x04 olabilir. Sunucu yanıt verir ve bu yanıttan itibaren bağlantı her iki yönde de ham baytlar halinde devam eder.

> 05 02 00 02              VER=5, 2 methods offered: none, user/pass
< 05 02                    server chose 02 (username/password)

> 05 01 00 03 0b 65 78 61  VER=5, CMD=01 CONNECT, RSV=00,
  6d 70 6c 65 2e 63 6f 6d  ATYP=03 domain, LEN=11 "example.com"
  01 bb                    port 443
< 05 00 00 01 ...          REP=00 succeeded, then raw bytes

Bu protokol bağımsızlığı, SOCKS5’in en büyük avantajıdır ve bu gerçek bir avantajdır. Yukarıdaki iletişimde HTTP'den hiç bahsedilmediğinden, aynı uç nokta bir SSH oturumu, bir SMTP iletişimi, bir oyun istemcisi veya bir HTTP proxy'sinin tanımlayamayacağı şirket içi bir ikili protokolü taşıyabilir. Bir HTTP proxy'sinin ayrıştırabileceği bir istek veya yerine getirebileceği bir CONNECT komutuna ihtiyaç duyduğu durumlarda, SOCKS5'in tek ihtiyacı bir adres ve bir bağlantı noktasıdır.

Üçüncü komut olan UDP ASSOCIATE, “ham TCP baytları”na ilişkin tek istisnadır ve RFC 1928, bu komutun bazı kısımlarını isteğe bağlı bırakmaktadır — parçalanmayı desteklemeyen bir uygulama, işleyemediği datagramları basitçe atmalıdır. Belirli bir sunucunun bu komutu uygulayıp uygulamadığı, bir spesifikasyonun size söyleyebileceği bir şey değildir; bu nedenle proxy denetleyicisi Bu, belirli bir son noktaya göre konuyu netleştirmek için uygun yerdir. Bu cümlenin ötesinde, bu sayfada yer almaz.

Aynı İki Değiş tokuşun Sözlü Anlatımı

HTTP CONNECT

1. İstemciden aracı sunucuya: CONNECT example.com:443

   İstek hedefi, yol içeren bir URL değil, bir yetki kaynağıdır — bir ana bilgisayar ve bir bağlantı noktası. Ad, yapısı gereği proxy'ye iletilir; dolayısıyla bunu çözümleyen taraf proxy'dir.

2. İsteğe bağlı olarak, proxy’den istemciye: 407, ardından istemciden proxy’ye: Proxy-Authorization

   Kimlik bilgilerini isteyen bir proxy, bir doğrulama mesajıyla yanıt verir ve istemci bu bilgileri girerek yeniden deneme yapar. İstemci bu bilgileri önceden göndermedikçe, bu işlem bir ek gidiş-dönüş gerektirir.

3. Proxy'den istemciye: HTTP/1.1 200 Bağlantı kuruldu

   Bu satırdan itibaren tünel devreye girer. Proxy, iletişimin bir parçası olmaktan çıkar.

4. İstemciden kaynağa, aracı sunucu üzerinden: TLS, ardından veri yükü

   Baytlar her iki yönde de değiştirilmeden iletilir. Proxy’de yalnızca ana bilgisayar adınız ve bağlantı noktanız bulunur; başka hiçbir bilgi yoktur.

SOCKS5

1. İstemciden vekile: sürüm 5 ve yöntemler listesi

   İstemcinin kullanmaya hazır olduğu tüm kimlik doğrulama yöntemlerini belirten bir selamlama; en yaygın olarak 0x00 (yok) ve 0x02 (kullanıcı adı/şifre) değerleri kullanılır.

2. Vekilden istemciye: seçtiği yöntem

   İki bayt. 0xFF değerindeki yanıt, sunulan hiçbir seçeneğin kabul edilebilir olmadığı anlamına gelir ve istemcinin bağlantıyı kapatması gerekir.

3. İsteğe bağlı olarak, RFC 1929 alt müzakeresi

   Kullanıcı adı/şifre seçeneği seçildiyse, istemci kimlik bilgilerini gönderir ve sunucu bir durum baytı ile yanıt verir. Bir gidiş-dönüş daha.

4. İstemciden vekile: ATYP baytı içeren istek

   Komutun ardından bir adres türü gelir: 0x01, önceden çözümlenmiş dört okteti taşır; 0x03 ise alan adının kendisini taşır. Bu tek bayt, socks5 ve socks5h arasındaki ayrımı belirler.

5. Proxy’den istemciye: önce yanıt, ardından ham baytlar

   0x00 yanıt kodu, işlemin başarılı olduğu anlamına gelir. Bundan sonraki her şey, incelenmemiş olan protokolünüze aittir.

Host Adını IP Adresine Dönüştüren Kimdir?

Socks5 ile Socks5h arasındaki bu sorunun HTTP’de hiçbir karşılığı yoktur ve bu asimetri, iki protokol arasındaki en belirgin ve gerçek farktır. Bir HTTP proxy’sine, yapısı gereği bir ana bilgisayar adı verilir: CONNECT isteğinin hedefi bir otoritedir ve yönlendirme isteği satırı mutlak bir URI’dir. Her iki durumda da proxy bir ad alır ve herhangi bir bağlantı açmadan önce bu adı çözümlemesi gerekir. İstemcinin aramayı önceden yapmış olması ve bunun yerine bir adres iletmesi gibi bir HTTP proxy alışverişi senaryosu yoktur.

SOCKS5, bu ikisi arasında bu seçeneği sunan tek protokoldür ve bunu bir ayar yerine tek bir bayt olarak sunar. ATYP 0x01, takip eden dört oktetin istemci tarafından önceden çözümlenmiş bir adres olduğunu belirtir. ATYP 0x03 ise takip eden baytların bir ad olduğunu ve proxy'nin bunu çözümlemesi gerektiğini belirtir. Çoğu istemci kütüphanesi varsayılan olarak yerel çözümlemeyi kullanır; bu nedenle seçim genellikle bilinçli bir şekilde yapılmalıdır.

Aslında bu durum, hangi çözümleyicinin yanıt vereceğini değiştirir; çözümleyicilerin hepsi aynı yanıtı vermez. Bir CDN, sizi sorguyu gönderen kişinin yakınındaki bir uç noktaya yönlendirir; split-horizon yapılandırması ise sorgunun nereden geldiğine bağlı olarak tamamen farklı bir kayıt döndürebilir. Yerel olarak çözümleme yaparsanız, kendi konumunuz için yanıt alırsınız, ancak trafiğiniz başka bir yerden çıkar; bu da bir isteğin, çıkış IP'siyle eşleşmeyen bir uç düğüme ulaşmasına neden olur. Proxy'de çözümleme yaparsanız, cevap çıkış adresiyle uyumlu olur. Ayrıca, yerel olarak çözümlenen bir ad, trafiğin daha sonra nereye gittiğine bakılmaksızın ağınız tarafından görülen bir arama olduğu için, kendi ağınızın neyi gözlemleyebileceği de değişir.

Aynı baytın içinde bir sonuç daha gizlidir. ATYP 0x04, on altı oktetlik bir IPv6 adresi taşır; bu sayede, yerel olarak bir IPv6 kaydına çözümlenmiş bir SOCKS5 istemcisi bu adresi doğrudan iletebilir — bu ayrıntı, eğer şu ile çalışıyorsanız önemlidir: IPv6 mobil proxy'ler ve bağlantının hangi tarafının adres ailesini seçtiğini öğrenmek istiyoruz.

Kimlik Doğrulama ve Her İki Protokolün de Şifrelemediği Adım

Bu iki protokol, tamamen farklı mekanizmalarla kimlik doğrulaması yapar. Kimlik bilgilerini isteyen bir HTTP proxy’si, kimlik doğrulaması yapılmamış bir giriş denemesine 407 Proxy Authentication Required yanıtı ve talebi açıklayan bir Proxy-Authenticate başlığıyla yanıt verir; istemci ise Proxy-Authorization başlığıyla yeniden deneme yapar. Bu, reddedilme ve ardından yeniden deneme sürecidir; bu nedenle, istemci kimlik bilgilerini önceden gönüllü olarak sağlamadıkça bir gidiş-dönüş işlemine mal olur.

SOCKS5 hiçbir zaman reddetmez ve yeniden dener. Yöntem, başka herhangi bir işlem gerçekleşmeden önce belirlenir: istemci desteklediği yöntemleri listeler, sunucu bunlardan birini seçer ve bu yöntem 0x02 ise her iki taraf da RFC 1929 alt müzakeresini yürütür — 0x01 değerinde bir sürüm baytı, ardından kullanıcı adı uzunluğu ve kullanıcı adı, sonra da şifre uzunluğu ve şifre, her biri 1 ile 255 oktet arasında olup, yanıt olarak 0x00’ın başarı anlamına geldiği iki baytlık bir durum bilgisi gönderilir. RFC 1928 ayrıca, RFC 1961’de ayrı olarak belirtilen GSSAPI için 0x01 değerini tanımlar; ancak bu, ticari bir proxy tarafından nadiren sunulur.

Farklı mekanizmalar, aynı güvenlik durumu: Her iki protokol de siz ile proxy arasındaki bağlantıyı şifrelemiyor. RFC 1929, kendi yöntemi hakkında bunu açıkça belirtir ve isteğin şifresiz metin olarak şifreyi taşıdığı için, dinlemenin mümkün ve pratik olduğu ortamlarda alt müzakerenin tavsiye edilmediğini uyarır. HTTP de daha iyi değildir — Basic şeması ile yapılan Proxy-Authorization, aktarım güvenliği için seçilmiş bir kodlama olan base64’tür; bu bir şifreleme yöntemi değildir ve yol üzerindeki herhangi bir şey tarafından kolayca geri dönüştürülebilir.

Bu aynı zamanda, protokol meselesi ile gizlilik meselesinin neden aynı şey olmadığını anlamanın en net yoludur. Eğer asıl bilmek istediğiniz şey, bir proxy’nin neyi ve kimden gizlediği ve bunun, tasarım gereği ilk atlamayı şifreleyen bir tünelden nasıl farklı olduğu ise, bu karşılaştırma hâlâ geçerliliğini korumaktadır proxy ve VPN karşılaştırması burada değil de.

Hız: Neler Ölçülebilir, Neler İflah Olmaz Bir İnanış?

Genel olarak, SOCKS5’in trafiğinizi ayrıştırmadığı için daha hızlı olduğu iddia edilir. Bu iddia, el sıkışma aşaması sırasında geçerliliğini yitirir. Her iki protokol de tam olarak aynı anda — kurulumun tamamlandığı anda — ayrıştırmayı durdurur ve bundan sonra her ikisi de aynı TCP bağlantısı üzerinden aynı kaynağa aynı baytları ileten “kör” aktarıcılara dönüşür. Her iki tarafta da bayt başına işleme yapılmadığından, ölçülebilecek bir bayt başına işleme farkı yoktur.

Kurulum gecikmesi konusunda sıralama, yaygın inanışın tam tersidir. HTTP CONNECT, ilk veri baytını almadan önce bir gidiş-dönüş süresi gerektirir: CONNECT gönderilir, 200 yanıtı alınır. SOCKS5 ise iki gidiş-dönüş süresi gerektirir: selamlama, yöntemin alınması, isteğin gönderilmesi, yanıtın alınması. Kullanıcı adı/şifre kimlik doğrulaması eklendiğinde SOCKS5 üç tur gerektirirken, HTTP ise istemci kimlik bilgilerini önceden göndermek yerine kimlik doğrulama talebini beklediği takdirde iki tur gerektirir. Bu hesaplama RFC'lere değil bize aittir, ancak her bir spesifikasyonun gerektirdiği mesaj sayısından doğrudan ortaya çıkmaktadır.

Bu da, veri aktarım hızınızı gerçekte belirleyen değişkenlerin, her iki protokolün de kontrol edemediği unsurlar olduğu anlamına gelir: proxy ile kaynak sunucu arasındaki rota, çıkış ağının koşulları — mobil çıkışta sinyal kalitesi ve eşleşme durumu, herhangi bir çıkıştaki tıkanıklık — ve istemcinizin bağlantıları ne kadar verimli bir şekilde yeniden kullandığı. Uzun süreli bir oturumda kurulum maliyeti bir kez ödenir ve istatistiksel bir gürültü niteliğindedir. Her istek için yeni bir bağlantı açan veri toplama iş yükünde ise bağlantı başına maliyet her şeyin önüne geçer ve çözüm, farklı bir protokol kullanmak yerine bağlantıları yeniden kullanmaktır.

Bir toplama iş yükünde rakamları gerçekten etkileyen unsurlar — ana bilgisayar başına eşzamanlılık, yeniden deneme davranışı ve isteklerin kendilerinin yapısı — şunlardır: Python ile veri kazıma kılavuzu herhangi bir protokol karşılaştırmasından daha faydalı bir sayfadır.

Müşterinizin Aslında Hangisini İstediği

Protokol seçimi iki şeye bağlıdır: trafiğinizin gerçekte ne olduğu ve istemcinizin yardım almadan nasıl yapılandırıldığı. Bu seçim genel bir kararla belirlenmez; zira en yaygın durumda, karar verilmesini gerektirecek anlamlı bir fark yoktur.

Son iki sütunu baştan sona okuduğunuzda, HTTPS trafiği açısından bu iki ürünün aslında aynı olduğu sonucuna varırsınız. Trafiğiniz bir tarayıcıdan, veri toplama çerçevesinden veya bir HTTP kütüphanesinden gelen HTTPS trafiği ise, her ikisi de bu trafiği aynı şekilde tüneller ve doğru seçim, aracınızın yerel olarak yapılandırdığı seçenektir.

SOCKS5 Ne Zaman Çözüm Olur?

• Trafik hiç de HTTP değildir — SSH, SMTP, bir veritabanı istemcisi, bir oyun istemcisi veya kurum içi bir ikili protokol olabilir. Bir CONNECT tüneli teknik olarak bunların herhangi birini taşıyabilir, ancak bu, istemcinin bunu nasıl talep edeceğini bilmesi durumunda mümkündür ve HTTP dışındaki istemcilerin çoğu bunu bilmez.
• Birçok uygulamanın farkında olmadan göz ardı ettiği uygulama bazlı HTTP proxy ayarları yerine, makinedeki her şeyin yönlendirilebileceği tek bir sistem genelinde geçerli giriş noktası istiyorsunuz.
• SOCKS yolunda bu özelliği sunan bir istemciden proxy tarafında ad çözümlemesi yapmanız gerekiyor; bu yaygın bir durumdur — ayar SOCKS tarafında bulunur ve HTTP tarafında buna karşılık gelen bir ayar yoktur.
• UDP aktarımına ihtiyacınız var; bunu hiçbir HTTP proxy sunmaz. Belirli bir SOCKS5 sunucusunun bunu destekleyip desteklemediği ise ayrı bir sorudur ve buna ancak canlı bir testle cevap verilebilir.

Bu durumlar dışında, daha ucuz ya da daha basit seçenek gerçekten de uygundur ve müşterinizin halihazırda desteklediği seçeneği tercih etmenin size ölçülebilir bir maliyeti yoktur. PXM2, her ikisini de ayrı bağlantı noktalarında sunar; dolayısıyla bu seçim, bir satın alma kararı olmaktan ziyade istemci tarafında yapılan bir tercih olarak kalır. Hala protokoller yerine proxy kategorileri arasında karar veriyorsanız — ki bu, gerçek maliyet sonuçları olan farklı bir sorundur — şuradan başlayın: proxy türlerinin açıklaması ya da proxy türleri merkezi.

HTTP ve SOCKS5 Mobil Proxy'lerini Kurma

Her PXM2 mobil proxy, özel bağlantı noktalarında hem HTTP hem de SOCKS5 uç noktaları sunar:

Sık Sorulan Sorular

İlgili Kılavuzlar

Vekil sunucularının temel kavramları

Temel mobil proxy kılavuzları