Tutte le posizioni attive · 99.99% uptime
Protocolli

Keep-Alive e pool di connessioni nei proxy

La singola modifica più efficace per migliorare le prestazioni di un proxy non è acquistare un proxy più veloce, bensì riutilizzare la connessione esistente. Un client che apre una nuova connessione per ogni richiesta paga continuamente il costo di apertura della connessione, e quel costo si moltiplica passando attraverso il proxy.

Il costo reale dell'apertura di una connessione

FIGURALe fasi della prima connessione attraverso un proxy
CONFIGURAZIONE01DNSrisoluzione~20 msIndirizzo del proxyper02handshake TCP~35 msClient ↔ proxy03Identità del proxy~35 ms407 → nuovoinvio04CONNECTtunnel~35 msApertura del tunnel05handshake TLS~70 msClient ↔ target06Prima richiestavariabileDati effettivicosto fisso totale ~200 ms

Questi 200 ms si pagano di nuovo a ogni nuova connessione. Se invii 1.000 richieste e apri ogni volta una nuova connessione, spendi 200 secondi solo per l'apertura.

Come funziona il Keep-Alive?

In HTTP/1.1 le connessioni sono persistenti per impostazione predefinita: dopo l'arrivo della risposta la connessione non si chiude e la richiesta successiva viene inviata sullo stesso socket. Tre cose rompono questo comportamento:

  • Il server Connection: close invia — la connessione viene chiusa.
  • Il client crea un nuovo oggetto sessione a ogni richiesta — il pool non entra mai in funzione.
  • Il tempo di inattività viene superato — il proxy o il server chiude la connessione.
L'errore più comune

Creare nel codice un nuovo oggetto Session, Client oppure Agent per ogni richiesta. Questo disabilita completamente il riutilizzo delle connessioni, qualunque sia la configurazione del pool.

Configurazione corretta

FIGURARiutilizzare la connessione
Configurazione del pool per linguaggio01# Python requests — la Session si crea una sola volta02import requests03session = requests.Session()04session.proxies = {"https": "http://kullanici:sifre@proxy.example.com:8080"}05adapter = requests.adapters.HTTPAdapter(pool_connections=16, pool_maxsize=16)06session.mount("https://", adapter)07for url in urls:08 r = session.get(url, timeout=25) # viene riutilizzata la stessa connessione0910# Python httpx — indica esplicitamente i limiti11import httpx12limits = httpx.Limits(max_connections=16, max_keepalive_connections=16,13 keepalive_expiry=60.0)14client = httpx.Client(limits=limits, proxy=PROXY, timeout=25.0)1516# Node.js undici17import { Agent, setGlobalDispatcher } from "undici";18setGlobalDispatcher(new Agent({ connections: 16, keepAliveTimeout: 60_000 }));

Mantieni la dimensione del pool appena al di sotto del limite di concorrenza del tuo provider. Se lo superi, le connessioni in eccesso vengono aperte e chiuse subito.

Quanto si guadagna?

FIGURATempo totale per 1.000 richieste
MISURAZIONE061122183244Senza pool (nuova connessione)Con pool (keep-alive)1002505007501000

Nella misurazione di esempio l'uso del pool riduce il tempo totale a circa un terzo. Il guadagno cresce all'aumentare della latenza verso il proxy.

Riutilizzo della sessione TLS

Accanto al pool di connessioni esiste una seconda fonte di guadagno: il ticket di sessione TLS. Riconnettendosi allo stesso target è possibile eseguire un handshake abbreviato invece di quello completo. La maggior parte dei client moderni lo fa in automatico; l'importante è riutilizzare l'oggetto client.

FIGURAHandshake TLS completo e abbreviato
TLSHandshake completoRiutilizzo della sessioneNumero di round trip2 RTT1 RTTTrasferimento del certificatoNoCalcolo delle chiaviTotaleAbbreviatoDurata tipica70–140 ms30–60 msCondizionePrima connessioneStesso oggetto client

Se ricrei l'oggetto client a ogni richiesta il ticket di sessione va perso e ogni volta viene eseguito un handshake completo.

L'equilibrio del tempo di inattività

Anche tenere una connessione aperta troppo a lungo può creare problemi: il proxy o il server di destinazione possono chiuderla silenziosamente e il tuo client se ne accorge solo alla richiesta successiva. Da qui il tipico schema "la prima richiesta fallisce, la seconda riesce".

ImpostazioneConsigliatoPerché
keepalive_expiry30–60 sDeve essere inferiore al timeout del server
Dimensione del poolSotto il limite di concorrenzaL'eccesso è handshake sprecato
Retry1 voltaCompensa una connessione caduta
Limite di durata della connessione5–10 minLe connessioni troppo longeve diventano stantie
Consiglio pratico

Mantieni il tempo di inattività inferiore al timeout del server. Così sei tu a chiudere la connessione e non si verifica la situazione "il server ha chiuso ma io non lo so".

Il conflitto con la rotazione

Il riutilizzo delle connessioni e la rotazione degli IP sono naturalmente in conflitto: usare la stessa connessione significa restare sullo stesso IP di uscita. Non è un problema, è una scelta:

FIGURAPool o rotazione?
DECISIONERestare sullo stesso IP è un problema?No, serve la sessioneImposta il pool al massimo…NOGuarda sottoGuadagno di velocità massimoIn parte: per un certo tempo può essere lo stesso IPPool + rinnovo periodi…NOGuarda sottoIl punto di equilibrioSì, serve un IP diverso a ogni richiestaDisattiva il poolNOAccetta il costo in velocità…

Nella maggior parte degli scenari la seconda opzione è quella giusta: riutilizza la connessione per un certo periodo (ad esempio 30 richieste o 5 minuti), poi rinnovala.

Per le strategie di rotazione al nostro articolo sulle impostazioni di rotazione puoi consultarlo.

Riepilogo

Keep-alive e pool di connessioni sono la più grande leva singola sulle prestazioni del proxy. Crea l'oggetto client una sola volta e riutilizzalo, mantieni la dimensione del pool sotto il limite del provider, imposta il tempo di inattività più breve del timeout del server e aggiungi un singolo retry. Se hai bisogno di rotazione, invece di disattivare il pool preferisci un rinnovo periodico. Per la misurazione test del ping e controllo proxy i nostri strumenti.

Domande frequenti

01Il keep-alive funziona attraverso un proxy?

Sì. Una volta stabilito il tunnel CONNECT puoi far passare più richieste sullo stesso tunnel. Anche con un proxy HTTP semplice le connessioni persistenti sono supportate.

02Come devo scegliere la dimensione del pool?

Mantienila appena al di sotto del limite di concorrenza del tuo provider. Se lo superi, le connessioni in eccesso vengono aperte e chiuse subito e il costo dell'handshake va sprecato.

03La prima richiesta fallisce, le successive funzionano: perché?

La connessione nel pool potrebbe essere stata chiusa silenziosamente dal server. Mantieni il tempo di inattività inferiore al timeout del server e aggiungi un singolo tentativo di retry.

04Il pool di connessioni impedisce la rotazione degli IP?

Sì, la stessa connessione resta sullo stesso IP di uscita. Se ti serve la rotazione, invece di disattivare del tutto il pool rinnova la connessione dopo un certo numero di richieste o dopo un certo tempo.

05Cosa fa guadagnare il riutilizzo della sessione TLS?

Invece dell'handshake completo viene eseguito un handshake abbreviato; tipicamente si risparmia un round trip e 40–80 ms. È sufficiente riutilizzare l'oggetto client.

Articoli e pagine correlati

PROSSIMO PASSO

Potenzia oggi la tua infrastruttura proxy.

Inizia in pochi minuti con i pacchetti a pagamento oppure prova prima il nostro elenco di proxy gratuiti.

FREEPROXY.TR

Se cerchi proxy gratuiti, sei nel posto giusto

Una piattaforma proxy completa dove consultare indirizzi proxy gratuiti aggiornati, confrontare i tipi di proxy HTTP e SOCKS e verificare le tue connessioni proxy con strumenti gratuiti.