Proxy SOCKS e HTTP: differenze, velocità e scelta del protocollo

I proxy HTTP e SOCKS connettono un’applicazione a una destinazione attraverso un intermediario. Per un browser, uno scraper o un client API, un proxy HTTP con CONNECT è un punto di partenza pratico. SOCKS5 è utile quando l’applicazione richiede SOCKS, necessita di altri protocolli TCP o supporta l’inoltro UDP. Entrambi possono trasportare traffico verso siti HTTPS.

Il protocollo determina come il programma comunica con il proxy. L’origine dell’IP di uscita, la rotazione e l’accesso condiviso o dedicato sono scelte separate, spiegate nella guida ai tipi di proxy e alla scelta di una configurazione. Passare da HTTP a SOCKS non cambia di per sé nessuna di queste proprietà.

Come HTTP e SOCKS gestiscono una connessione

Inoltro HTTP: il proxy gestisce una richiesta web

Per una normale richiesta HTTP non cifrata, il client invia al proxy l’URL di destinazione, il metodo e le intestazioni. Il proxy elabora la richiesta e ottiene la risposta dalla destinazione. Può applicare regole HTTP, modificare le intestazioni o usare una cache, se configurato per farlo. Sono funzioni possibili di un proxy HTTP; un servizio non le abilita necessariamente tutte.

SOCKS5: il proxy apre una connessione per l’applicazione

Il client concorda un metodo di autenticazione, si autentica se richiesto e fornisce l’indirizzo e la porta di destinazione. Il proxy stabilisce poi la connessione TCP richiesta e inoltra i byte dell’applicazione. Lo stesso meccanismo può trasportare HTTPS, SSH o un altro protocollo applicativo TCP supportato. Il proxy non deve interpretare le richieste HTTP per inoltrarle.

HTTPS tramite CONNECT: i due approcci diventano più simili

Quando apre un sito HTTPS attraverso un proxy HTTP convenzionale, il client invia normalmente una richiesta CONNECT. Dopo che il proxy ha accettato il tunnel, il client stabilisce TLS con il sito al suo interno. Il proxy inoltra i dati cifrati. SOCKS5 può inoltrare lo stesso scambio TLS dopo la propria configurazione iniziale.

È importante nel confronto tra velocità e riservatezza: un proxy HTTP che trasporta HTTPS in un tunnel non analizza ogni richiesta di pagina cifrata. Entrambi i tipi inoltrano il traffico protetto. La sequenza e la distinzione tra inoltro HTTP e tunneling sono spiegate in Proxy HTTP e HTTPS.

HTTP e SOCKS5 in breve

Il confronto seguente usa SOCKS5. Le versioni precedenti SOCKS4 e SOCKS4a hanno meno funzionalità e sono rilevanti soprattutto quando le richiede un programma esistente.

Quale è più veloce: HTTP o SOCKS5?

Una nuova connessione HTTPS può essere pronta prima tramite HTTP CONNECT, perché la procedura iniziale abituale richiede meno scambi con il proxy. Il confronto seguente mostra le ipotesi su cui si basa la differenza. Una volta aperto un tunnel, un download lungo o richieste successive possono riutilizzarlo. Nessuno dei due protocolli ha un vantaggio fisso nella velocità di trasferimento sostenuta.

Nuove connessioni: conta gli scambi

Conta i messaggi iniziali dopo che la connessione TCP al proxy è pronta, con ogni richiesta che attende la propria risposta. Questo confronto non usa uno strato TLS fino al proxy. L’autenticazione HTTP non è necessaria oppure riesce con le credenziali incluse nella prima richiesta CONNECT.

Con queste ipotesi, SOCKS5 aggiunge quindi un percorso di andata e ritorno tra client e proxy senza autenticazione oppure due con l’autenticazione standard tramite nome utente/password. Il tempo di andata e ritorno, o RTT, è il tempo necessario a un messaggio per raggiungere il proxy e alla risposta per tornare. Con un RTT illustrativo di 50 ms, questi scambi aggiuntivi corrispondono a circa 50 o 100 ms. È una stima basata sulla sequenza del protocollo, non un benchmark di un servizio proxy o del tempo totale della richiesta.

Entrambi i percorsi richiedono anche che il proxy si connetta alla destinazione e il client completi la configurazione TLS del sito. Tempo DNS, elaborazione e congestione possono essere diversi. Una richiesta di autenticazione HTTP aggiunge scambi; TLS verso un proxy HTTPS aggiunge la propria procedura iniziale. Questi casi vanno inclusi nel confronto delle configurazioni effettive.

Connessioni riutilizzate: la differenza iniziale si distribuisce tra le richieste

Un pool di connessioni mantiene disponibili connessioni adatte per richieste successive. Riutilizzare una connessione HTTPS evita di ripetere TCP, la negoziazione del proxy e l’handshake TLS del sito per ogni richiesta. Con il supporto HTTP/2 nel client e nella destinazione, più flussi di richieste possono condividere una connessione stabilita. Può avvenire sia in un tunnel HTTP CONNECT sia in una connessione SOCKS5; il proxy non deve analizzare i messaggi HTTP/2 all’interno di TLS.

Creare un nuovo oggetto client HTTP per ogni URL può scartare il suo pool di connessioni. Qui riutilizzare un client significa mantenere l’oggetto software e le sue connessioni, non chiedere al proxy di mantenere un IP di uscita. Quando un lotto contatta ripetutamente gli stessi host, riutilizzare le connessioni può risparmiare più lavoro iniziale di un cambio di protocollo proxy. Nuove destinazioni, connessioni chiuse e impostazioni proxy modificate possono comunque richiedere nuovi tunnel.

Trasferimenti grandi: valuta la banda disponibile

Una volta stabilito il tunnel, la velocità di download dipende da percorso, perdita di pacchetti, banda disponibile, carico del proxy e limiti del servizio. Inoltrare HTTPS tramite CONNECT è già un’attività di inoltro di byte. Descrivere SOCKS5 come più veloce perché “non legge HTTP” ignora questo caso.

Per HTTP non cifrato, la cache configurata o l’elaborazione dei contenuti possono cambiare il risultato. Una risposta dalla cache è un carico di lavoro diverso dallo scaricare lo stesso contenuto dall’origine. Un confronto equo deve tenere conto della differenza.

Quale protocollo dovrebbe usare uno script web di grandi dimensioni?

Uno script web continua a effettuare richieste HTTP quando usa SOCKS5; l’opzione proxy cambia il modo in cui raggiunge il server. Per un nuovo script che recupera pagine web o chiama API HTTPS, inizia con un client HTTP maturo e HTTP CONNECT, salvo requisiti specifici che indichino un’altra scelta. Mantieni la scelta del proxy nella configurazione, così da poter testare SOCKS5 con la stessa logica di richiesta. Se il confronto conta per il progetto, scegli una libreria che supporti entrambi.

Sia HTTP sia SOCKS5 possono essere usati da programmi asincroni. Il protocollo proxy non determina se le richieste vengano eseguite contemporaneamente. Controlla che la libreria client possa usare la modalità proxy selezionata per richieste concorrenti, mantenere il pool di connessioni e limitare il numero di operazioni in corso. Aumenta la concorrenza osservando lavoro completato ed errori: quando proxy, rete o destinazione raggiungono il proprio limite, più connessioni possono significare code più lunghe e più nuovi tentativi.

Come confrontare la velocità prima di aumentare il carico

1. Usa lo stesso programma, le stesse richieste alla destinazione, dimensioni delle risposte e concorrenza. Dove possibile, confronta endpoint di protocolli con lo stesso IP di uscita e lo stesso percorso; altrimenti mantieni confrontabili la regione di uscita e i limiti del servizio e registra la differenza.
2. Esegui una serie con connessioni nuove e un’altra con il normale pool dopo il riscaldamento. Mantieni equivalenti comportamento DNS, protezione TLS, autenticazione, versione HTTP e politica dei nuovi tentativi, oppure documenta perché differiscono.
3. Misura le operazioni completate con successo al secondo e il tempo dell’intero lotto, inclusi i nuovi tentativi. Registra anche il tempo di completamento mediano e al 95° percentile, i timeout e le operazioni fallite. Il 95° percentile indica il tempo entro cui termina il 95% delle operazioni misurate.
4. Per i download, registra i byte utili ricevuti al secondo. Per le richieste brevi, separa la configurazione della connessione dal tempo al primo byte e dal tempo di risposta completo. Il tempo al primo byte include anche l’attesa che la destinazione generi una risposta.
5. Ripeti le esecuzioni alternando le due configurazioni e verifica il percorso proxy previsto. Se un test usa un pool di uscita diverso o ripiega su una connessione diretta, il risultato non isola il protocollo proxy.

Scegli la configurazione che completa più velocemente il lavoro reale con un tasso di errore accettabile. Un errore di autenticazione rapido o una risposta incompleta non sono traffico utile. Se entrambe hanno prestazioni simili, preferisci quella più semplice da supportare nell’applicazione scelta.

Perché viene prima il supporto dell’applicazione

Un campo etichettato “proxy” non promette tutti i protocolli o metodi di autenticazione. Per esempio, la gestione SOCKS5 integrata in Chrome supporta richieste TCP ma non implementa l’autenticazione SOCKS5 con nome utente/password né l’inoltro UDP. Un servizio SOCKS5 dotato di queste funzioni non può farle usare a una modalità del browser che non le supporta.

Per SSH, trasferimento di file o un’altra applicazione TCP, il supporto SOCKS nativo può essere comodo. Anche HTTP CONNECT può trasportare altri protocolli TCP, purché il programma possa creare il tunnel e il proxy consenta la porta di destinazione. “Proxy HTTP” non significa quindi sempre “solo traffico web”.

Le impostazioni proxy del browser non coprono automaticamente un altro programma o ogni funzione del browser. Gli adattatori esterni hanno una propria copertura e restrizioni. Differenze tra versioni e negoziazione sono trattate in Proxy SOCKS5 e SOCKS4.

Chi risolve l’hostname della destinazione?

Con SOCKS5, l’applicazione può risolvere localmente la destinazione e inviare un indirizzo IP oppure inviare un hostname che verrà risolto dal proxy. In curl, socks5:// seleziona la risoluzione locale della destinazione, mentre socks5h:// richiede la risoluzione tramite il proxy. La lettera aggiuntiva seleziona il comportamento del client; non crea un nuovo protocollo SOCKS.

Anche i proxy HTTP possono risolvere i nomi di destinazione ricevuti negli URL o nelle richieste CONNECT. Il DNS remoto della destinazione è quindi disponibile con entrambi i protocolli. Una ricerca dal lato proxy può restituire un indirizzo server diverso ed evita la ricerca locale per quella destinazione. Il client potrebbe comunque dover risolvere l’hostname del proxy stesso e altre applicazioni mantengono le proprie impostazioni DNS. Scegli il comportamento DNS nel client invece di dedurlo dal protocollo proxy.

Quale connessione è cifrata?

Distingui la protezione dei contenuti del sito da quella della connessione al proxy. Un sito HTTPS mantiene normalmente cifrati i dati applicativi tra client e sito attraverso entrambi i tipi di tunnel. Si presuppongono la normale verifica dei certificati e l’assenza di intercettazione TLS configurata.

Un proxy HTTPS aggiunge TLS tra client e proxy. Protegge la richiesta proxy e le credenziali su quella parte del percorso. In un indirizzo proxy, https:// indica normalmente questa connessione protetta. Un’impostazione descritta soltanto come “proxy per siti HTTPS” può invece indicare un normale proxy HTTP che supporta CONNECT.

Le credenziali HTTP Basic inviate a un normale proxy HTTP e lo scambio standard SOCKS5 di nome utente/password sono leggibili da chi può osservare quel percorso di rete non protetto. La connessione TLS successiva al sito non protegge retroattivamente l’accesso al proxy. Il normale SOCKS5 richiede un trasporto sicuro separato quando serve questa protezione.

Il proxy resta un estremo della propria connessione TLS e sa dove gli viene chiesto di connettersi. Se la destinazione finale usa HTTP non cifrato, TLS fino al proxy non cifra la connessione HTTP successiva. Allo stesso modo, l’inoltro SOCKS non nasconde contenuti in chiaro soltanto perché il proxy non deve analizzarli.

UDP o HTTP/3 cambiano la scelta?

Per un’applicazione che necessita realmente di UDP, SOCKS5 definisce UDP ASSOCIATE. Client e servizio devono implementarlo e il percorso di rete deve trasportare i datagrammi. Il normale HTTP CONNECT trasporta un tunnel TCP. L’inoltro UDP basato su HTTP è possibile tramite meccanismi aggiuntivi come CONNECT-UDP, che devono essere implementati da entrambi gli estremi.

HTTP/3 usa QUIC su UDP. Il corretto caricamento di una pagina HTTPS tramite un proxy non dimostra che HTTP/3 funzioni: il client potrebbe avere usato HTTP/2 o HTTP/1.1 su TCP. Questo ripiego può essere adatto a uno script web, ma non può sostituire UDP per una funzione che richiede datagrammi. Consulta UDP e QUIC tramite proxy per i percorsi di inoltro e i loro limiti.

SOCKS nasconde meglio il client?

Nell’inoltro HTTP non cifrato, un proxy può aggiungere un’intestazione come Forwarded contenente informazioni sul client originale. Un normale tunnel HTTPS CONNECT non può inserire quell’intestazione nella richiesta cifrata senza terminare la connessione TLS del sito. Neppure SOCKS5 aggiunge automaticamente intestazioni HTTP.

Questo non rende nessuno dei due protocolli una garanzia di anonimato o di accettazione da parte di un sito. L’operatore del proxy può osservare i metadati della connessione, mentre la destinazione può riconoscere account, cookie o comportamento dell’applicazione. La reputazione dell’IP di uscita e il numero di utenti che lo condividono sono fattori separati. Passare da HTTP a SOCKS nello stesso servizio non elimina automaticamente i blocchi né azzera la sessione di un sito.

Come fare la scelta finale

Inizia dai protocolli e metodi di accesso supportati dall’applicazione. Per la normale automazione web, HTTP CONNECT è una buona prima opzione; per un’applicazione costruita attorno a SOCKS o a una modalità UDP supportata, SOCKS5 può essere più adatto. Scegli poi il comportamento DNS e la protezione fino al proxy richiesti e confronta le prestazioni con il carico di lavoro effettivo.

Usa l’hostname e la porta reali del servizio per il protocollo selezionato. Sostituire http:// con socks5:// nella configurazione non abilita SOCKS su un server che non lo fornisce. Prima di aumentare il carico, conferma che le richieste escano dal proxy previsto e che un errore del proxy non attivi silenziosamente un percorso diretto indesiderato.