Connessioni simultanee
I proxy possono funzionare in modo affidabile con un carico leggero e iniziare a restituire errori quando più processi o programmi vengono eseguiti insieme. Una possibile causa è il superamento del numero di connessioni simultanee consentite.
Questo limite è uno dei limiti di utilizzo dei proxy. Per capire che cosa controlla e perché viene raggiunto, occorre prima spiegare che cos’è una connessione di rete e come funziona attraverso un proxy.
Che cos’è una connessione e come funziona
Una connessione di rete è un collegamento che due programmi stabiliscono per scambiarsi dati. Per esempio, un browser si collega a un server web per richiedere una pagina e riceverne il contenuto. La connessione fornisce il percorso per quello scambio; una richiesta e una risposta sono messaggi inviati attraverso di essa.
Considera una normale connessione TCP. L’applicazione contatta l’indirizzo IP del server e la porta del servizio richiesto. Le due parti si scambiano messaggi di controllo per stabilire la connessione. I dati viaggiano poi in piccole unità chiamate pacchetti. TCP segue la consegna, organizza la ritrasmissione dei dati persi e presenta i dati al destinatario nell’ordine corretto. Entrambe le parti conservano informazioni sullo scambio finché esiste la connessione.
Con un normale proxy TCP, l’applicazione si collega prima al server proxy. Il proxy stabilisce una connessione separata al sito di destinazione e passa i dati tra le due connessioni in entrambe le direzioni. Mantiene quindi la comunicazione sia con il client sia con la destinazione.
L’applicazione può inviare una richiesta, ricevere una risposta e utilizzare la connessione già stabilita per un altro scambio. Ricevere una pagina, per esempio, non chiude necessariamente la connessione: il browser può conservarla per altre richieste al server. Quando non è più necessaria, una parte la chiude; anche un errore o un timeout può terminarla. Finché non viene chiusa, una connessione può esistere senza trasferire continuamente dati.
Un programma può mantenere più connessioni di questo tipo contemporaneamente: ricevere dati su una, attendere una risposta su un’altra e tenerne una terza pronta per una richiesta successiva. Sono connessioni simultanee. Il numero descrive i canali di comunicazione aperti in quel momento, non il totale delle richieste effettuate dall’avvio del programma.
Che cosa misura il limite
Una connessione aperta occupa un posto nella quota pertinente. Quando viene chiusa e il servizio la rimuove dal conteggio, quel posto torna disponibile. È un limite dell’attività corrente, quindi raggiungerlo non esaurisce un saldo mensile di connessioni.
Il modo in cui le connessioni vengono conteggiate nella quota del cliente è una regola separata del servizio. I due tratti di rete del proxy non consumano automaticamente due unità della quota.
I fornitori fissano questi limiti perché le connessioni aperte consumano risorse del server anche quando trasferiscono pochi dati. Una connessione in attesa di risposta deve comunque essere mantenuta. Controllarne il numero aiuta il servizio a conservare capacità sufficiente per i carichi che si è impegnato a supportare.
Allo stesso servizio possono applicarsi diversi limiti:
| Limite | Che cosa controlla |
|---|---|
| Connessioni simultanee | Quante connessioni possono rimanere aperte insieme |
| Richieste simultanee | Quante richieste possono essere in corso insieme |
| Richieste al secondo | Con quale frequenza possono essere inviate o elaborate le richieste |
| Velocità di trasferimento | Quanti dati possono passare al secondo |
| Quota di traffico | Quanti dati possono essere trasferiti durante un periodo di fatturazione |
Il traffico illimitato non dice quindi nulla sul numero di connessioni simultanee. Può inoltre esserci un limite separato alla velocità di apertura di nuove connessioni. Aprirle e chiuderle rapidamente può raggiungere quel limite anche quando ne rimangono aperte poche in ogni momento.
Perché il numero di thread non equivale al numero di connessioni
Il numero di thread o processi di lavoro di un’applicazione descrive come organizza le attività. Non indica in modo affidabile quante connessioni verranno conteggiate dal proxy. Un’attività può contattare più server e uno script asincrono può gestire molte operazioni di rete senza creare un thread del sistema operativo separato per ciascuna.
Inoltre, non ogni richiesta HTTP richiede una nuova connessione. Un client può riutilizzare una connessione esistente e HTTP/2 può trasportare più richieste contemporaneamente su una sola connessione. Il numero di richieste è quindi diverso dal numero di connessioni.
Conta anche la terminologia del fornitore. Un limite descritto come «thread» o «sessioni» può riferirsi alle connessioni aperte oppure alle richieste in elaborazione. Una sessione persistente, che mantiene lo stesso IP proxy per richieste correlate, non rappresenta necessariamente una connessione di rete. La definizione utile è ciò che il servizio conteggia effettivamente.
Quali programmi condividono la quota?
Un limite può appartenere a un account, a un pacchetto acquistato, a un singolo IP proxy oppure a un determinato gateway. Per un limite dell’account o del pacchetto, somma le connessioni di tutti i programmi e dispositivi che utilizzano quella quota. Dividere un elenco di IP tra più computer non crea una quota separata per ciascun computer.
Con un limite per IP la distribuzione è diversa: un indirizzo molto utilizzato può raggiungere il proprio tetto mentre un altro ha ancora spazio. Spostare parte del lavoro sul secondo indirizzo può aiutare, purché il servizio non imponga anche un limite condiviso inferiore. Un pacchetto può avere sia una quota complessiva sia assegnazioni più piccole per singoli utenti o IP client.
Il numero di IP client autorizzati ad autenticarsi è un’altra impostazione. Controlla quali reti possono accedere ai proxy, non quante connessioni possono aprire. Più dispositivi dietro un unico IP pubblico possono condividere sia quella regola di accesso sia l’assegnazione di connessioni associata.
Cambiare l’IP proxy visto da un sito non azzera la quota di connessioni dell’account. Analogamente, cambiare il nome di una sessione persistente o il protocollo non fornisce automaticamente più capacità. Il limite rimane associato all’account, al pacchetto o all’endpoint utilizzato dal fornitore per il conteggio.
Perché le connessioni si accumulano
Le connessioni si accumulano quando le nuove vengono aperte più rapidamente di quanto vengano chiuse quelle esistenti. Può accadere caricando pagine, scaricando file o eseguendo altre attività di rete in parallelo: alcune connessioni stanno ancora trasferendo dati o attendendo una risposta mentre l’applicazione ne apre altre. Queste connessioni rientrano contemporaneamente nella quota e insieme possono esaurire il limite di connessioni proxy.
Le risposte lente mantengono occupate le connessioni più a lungo. Se un programma continua ad avviare nuovo lavoro allo stesso ritmo, le attività incomplete si accumulano. Se invece mantiene l’attività parallela a un livello fisso, un sito più lento comporta generalmente meno attività completate al minuto. Entrambe le situazioni possono verificarsi senza alcuna modifica al pacchetto proxy.
I download lunghi e le connessioni in attesa di un timeout possono avere lo stesso effetto. Un gran numero di connessioni aperte può quindi coesistere con una bassa velocità di trasferimento: molto tempo viene trascorso in attesa anziché nel trasferimento dei dati.
Alcune connessioni vengono mantenute intenzionalmente aperte tra le richieste. Questo viene solitamente chiamato keep-alive. Evita di stabilire ogni volta una nuova connessione, ma una connessione inattiva può comunque occupare un posto se il servizio conteggia le connessioni aperte. Una connessione restituita al pool dell’applicazione è disponibile per il riutilizzo; non è stata necessariamente chiusa presso il proxy.
Un problema separato è la gestione errata del rilascio delle connessioni. Può verificarsi sia in software pronti all’uso sia in script personalizzati. Per esempio, il codice può iniziare a leggere una risposta, incontrare un errore e avviare un’altra richiesta senza completare o chiudere la risposta precedente. Se continuano ad aprirsi nuove connessioni mentre le vecchie rimangono occupate, l’applicazione può esaurire la quota senza svolgere più lavoro utile. Per questo è opportuno verificare il rilascio dopo errori e annullamenti, non soltanto dopo richieste riuscite.
Una gestione corretta consente al client di riutilizzare una connessione adatta oppure chiuderne una non più necessaria. I timeout impediscono che operazioni abbandonate rimangano in attesa indefinitamente. Disabilitare ovunque il riutilizzo non è una soluzione generale: aggiunge il lavoro per stabilire connessioni e può aumentare la frequenza delle nuove aperture. L’obiettivo è un numero controllato di connessioni riutilizzabili, con quelle non necessarie rilasciate o chiuse correttamente.
Perché i proxy sembrano funzionare, poi fermarsi e poi ripartire
Gli errori intermittenti sotto carico sono un motivo per verificare presto il limite di connessioni. Alcuni indirizzi proxy sembrano funzionare mentre altri falliscono; poco dopo, lo schema cambia. Dal punto di vista dell’applicazione, può sembrare che parti diverse dell’elenco proxy continuino ad andare offline.
Una spiegazione è che la quota condivisa sia piena. Le connessioni esistenti possono proseguire, mentre i tentativi di aprirne altre vengono rifiutati o lasciati in attesa. Quando si chiudono connessioni precedenti, alcuni nuovi tentativi riescono a passare. Altri falliscono quando i posti disponibili si riempiono nuovamente. Il risultato variabile deriva dalla competizione per la stessa quota, non da un gruppo fisso di IP guasti.
Questo comportamento viene talvolta descritto come throttling. Qui la restrizione riguarda l’ammissione di nuove connessioni; non riduce necessariamente la velocità di ogni connessione già stabilita. La risposta precisa dipende dal servizio: può restituire un messaggio chiaro sul limite, rifiutare una connessione oppure lasciare che il client raggiunga il timeout. Non è garantita una coda di attesa.
Per verificare questa spiegazione, confronta gli errori con il numero di connessioni e riduci temporaneamente l’attività parallela dei programmi che condividono la quota. Se gli errori cessano quando l’attività scende sotto il limite e ricompaiono quando la quota si riempie, il tetto di connessioni è una causa probabile. Interruzioni simili possono provenire anche dal sito di destinazione o dalla rete. Un timeout oppure una risposta HTTP 429, 502 o 503, da soli, non dimostrano che sia stato raggiunto il limite di connessioni del proxy; contano l’origine e il testo dell’errore.
Come mantenere il lavoro utile entro il limite
Parti dai siti e dalle operazioni effettivamente necessari al software. Aumenta gradualmente l’attività parallela e osserva risultati riusciti, tempi di risposta e picchi di connessioni. Una prova breve su una pagina veloce potrebbe non rappresentare un’esecuzione completa con accessi, risposte grandi ed endpoint più lenti.
- Assegna a tutti i programmi un budget condiviso di connessioni. Lascia spazio per altre attività e brevi raffiche. Se più processi utilizzano lo stesso pacchetto, impostare ciascuno sull’intera quota del pacchetto può sovraccaricare il servizio quando vengono eseguiti insieme.
- Controlla sia le attività sia le connessioni. Un pool di connessioni conserva connessioni per il riutilizzo. Verifica se la sua impostazione di dimensione è un limite rigido oppure soltanto il numero conservato in seguito; alcuni client aprono connessioni aggiuntive se non viene attivata una modalità di attesa. Mantieni una gestione corretta delle risposte e i timeout anche quando un lavoro fallisce.
- Distribuisci nel tempo gli avvii e i nuovi tentativi. Avviare ogni browser contemporaneamente o ripetere subito ogni richiesta fallita crea un altro picco. Utilizza un numero limitato di nuovi tentativi con ritardi crescenti e mantienili nello stesso budget di carico. Inoltre, un timeout non dimostra che un’azione inviata sia fallita, quindi ripetere un acquisto o un aggiornamento richiede attenzione.
- Misura il lavoro completato. Più processi di lavoro sono utili soltanto finché aumentano la quantità di operazioni riuscite. Quando aggiungono soprattutto attese ed errori, un’impostazione inferiore può completare prima lo stesso lavoro. Se un pannello mostra medie dell’attività nel tempo, i picchi brevi possono risultare meno visibili che negli orari degli errori dell’applicazione.
Per le attività del browser, evitare download non necessari può ridurre anche l’attività di rete. Bloccare immagini o video può aiutare quando non servono all’attività; rimuovere script può invece interrompere l’operazione stessa. Valuta la modifica in base al corretto completamento dell’attività prevista.
Quando aiuta un limite più alto
Più capacità di connessione è utile quando l’applicazione gestisce correttamente le proprie connessioni e il carico richiesto raggiunge regolarmente il tetto del fornitore. Può permettere a più attività di essere eseguite insieme senza competere per la stessa piccola quota.
L’acquisto deve aumentare il limite effettivamente raggiunto. Aggiungere IP può aiutare con una restrizione per IP quando il lavoro viene distribuito tra loro. Per un limite condiviso del pacchetto, il nuovo pacchetto o componente aggiuntivo deve aumentare quella quota condivisa. Un aumento del solo numero di IP non dimostra che lo farà.
Esistono anche altri tetti. Il client può avere un pool più piccolo, il computer può esaurire le risorse di rete oppure la destinazione può limitare le richieste. Anche una singola connessione mobile ha la propria banda disponibile, indipendentemente dal numero di connessioni proxy consentite. Acquistare più simultaneità non elimina questi vincoli e non ripara uno script che continua a lasciare connessioni aperte inutilmente.
L’obiettivo pratico è uno spazio sufficiente per i picchi normali del carico, mantenendo pochi errori. Una volta stabilito questo, una quota di connessioni aggiuntiva può essere un utile aumento di capacità, anziché un modo per rinviare la correzione dell’applicazione.