Sessioni persistenti

Una sessione persistente indica al servizio proxy di mantenere un IP di uscita per le richieste correlate. L’applicazione può aprire pagine, inviare dati e ricevere un risultato tramite quell’indirizzo finché l’assegnazione è valida e l’uscita disponibile. Quando l’attività termina, l’applicazione può avviare una sessione separata per quella successiva.

È comunemente una modalità di accesso a un pool a rotazione. Il confronto più generale è trattato in Proxy statici e proxy a rotazione. Qui la domanda è come mantenere un indirizzo per una singola attività, quanto dura l’assegnazione e che cosa può interromperla.

Come il servizio mantiene l’IP selezionato

Il servizio deve riconoscere quali connessioni appartengono alla stessa attività. Un metodo comune è un identificatore di sessione nelle impostazioni del proxy. Alla prima connessione, il servizio seleziona un’uscita e la associa all’identificatore. Le connessioni successive con le stesse impostazioni di sessione usano l’uscita assegnata finché la sessione rimane attiva.

Per esempio, un test nel browser usa il nome di sessione task1. La prima connessione riceve l’IP di uscita di esempio 198.51.100.27. Anche l’apertura della pagina successiva e l’invio di un modulo tramite la stessa assegnazione attiva usano quell’indirizzo. Il nome identifica l’assegnazione; non codifica l’IP e non lo riserva permanentemente.

L’identificatore di sessione può essere aggiunto al nome utente del proxy, selezionato tramite un’API o rappresentato da una porta configurata. Alcuni servizi forniscono anche una sessione predefinita senza nome separato. Sono modi diversi di gestire l’assegnazione, quindi non esistono un formato universale del nome utente o un numero di porta universale per l’accesso persistente.

Una sessione persistente può coprire più connessioni di rete. È diverso dal semplice riutilizzo di una connessione aperta: le richieste all’interno della stessa normale connessione TCP mantengono già il suo IP di uscita. Per capire se una sessione mantiene l’indirizzo tra connessioni diverse, è utile osservare che cosa succede quando si apre una nuova connessione con le stesse impostazioni di sessione.

Quando più richieste necessitano di un IP

Un test nel browser articolato in più passaggi è un esempio chiaro. Potrebbe effettuare l’accesso, aprire una pagina di impostazioni, inviare una modifica e verificarne il risultato. Mantenere stabile l’IP di origine elimina un cambiamento evitabile durante il test, soprattutto se il sito usa l’indirizzo tra i controlli della sessione.

Anche un test di acquisto o prenotazione può dipendere da un’esperienza regionale coerente. L’applicazione esegue una ricerca, sceglie un’opzione e controlla il passaggio successivo tramite la stessa uscita. Questo aiuta a mantenere coerente la posizione di rete tra i passaggi, anche se il sito può usare anche impostazioni dell’account, dati di consegna o cookie per decidere che cosa mostrare.

Un altro caso è una sequenza di chiamate API in cui il servizio di destinazione si aspetta azioni correlate da un indirizzo di origine coerente. L’assegnazione dovrebbe coprire l’intera sequenza, comprese pause e nuovi tentativi. Al contrario, consultazioni non correlate di pagine pubbliche non richiedono necessariamente un solo IP. Mantenere un indirizzo è utile quando la continuità conta per l’attività; non migliora di per sé la reputazione dell’indirizzo né garantisce che il sito accetti una richiesta.

Una sessione proxy non conserva l’accesso a un sito

Il servizio proxy controlla l’indirizzo di uscita. Il sito web controlla la propria sessione: lo stato di accesso, il carrello o l’avanzamento in un modulo. Un browser o un client HTTP trasporta normalmente quello stato tramite cookie o token di autenticazione. Entrambi i sistemi possono usare la parola sessione, ma mantengono informazioni diverse.

Questo significa che un accesso può scadere mentre l’IP di uscita rimane invariato. Anche eliminare i cookie può impedire al sito di riconoscere l’utente senza influire sull’assegnazione del proxy. È possibile anche il contrario: un sito può accettare un accesso valido dopo un cambio di IP. Il suo comportamento dipende dalle proprie regole.

Un oggetto sessione in una libreria HTTP memorizza spesso i cookie e riutilizza le connessioni. Creare quell’oggetto non attiva automaticamente l’accesso persistente nel servizio proxy. Per un flusso completo, l’applicazione deve mantenere insieme lo stato del sito e l’assegnazione proxy desiderata. Profili del browser separati o stati del client isolati restano necessari quando attività diverse non devono condividere i cookie.

Che cosa significa davvero la durata della sessione

Due timer possono essere entrambi descritti come durata di una sessione. Una durata fissa limita per quanto tempo esiste l’assegnazione dal suo punto iniziale. Un timeout di inattività limita la pausa dopo l’ultima richiesta valida per quel conteggio. Nuove richieste possono riavviare il timer di inattività senza prolungare una durata fissa separata.

Considera due sessioni illustrative con un limite di dieci minuti. Entrambe iniziano alle 14:00 e ricevono un’altra richiesta alle 14:08. Con una durata fissa, la scadenza resta alle 14:10. Con un timeout di inattività, quella richiesta sposta la scadenza per inattività alle 14:18. La stessa durata dichiarata può quindi produrre comportamenti molto diversi durante un’attività in corso.

Un servizio può applicare entrambi i limiti. In quel caso, l’assegnazione termina quando viene raggiunto uno dei due. Anche il valore predefinito ordinario può essere diverso dalla durata massima disponibile nelle impostazioni. Mantenere il traffico attivo può evitare la scadenza per inattività, ma non elimina una durata massima separata.

La scadenza termina l’assegnazione alla vecchia uscita. Una connessione successiva può ricevere un altro indirizzo anche con lo stesso nome di sessione. Una connessione aperta può essere lasciata terminare oppure chiusa, a seconda del servizio. Il timer non trasferisce uno scambio TCP incompleto su un altro IP.

Scegli una finestra che includa l’intera attività, le risposte lente e le pause previste. Avviare un nuovo flusso verso la fine di un’assegnazione precedente lascia meno tempo di quanto suggerisca la durata configurata. Anche le richieste inviate soltanto per mantenere attiva una sessione inattiva restano traffico reale e possono consumare le richieste o il traffico inclusi nel servizio.

Tenere separate le attività parallele

Quando attività indipendenti necessitano ciascuna di un indirizzo stabile, assegna a ognuna un identificatore di sessione e mantienilo nei suoi passaggi. Un processo che carica la pagina successiva dovrebbe riutilizzare la sessione dell’attività invece di generare un nuovo nome per ogni richiesta. Un nuovo tentativo nella stessa attività non dovrebbe passare silenziosamente a impostazioni proxy non correlate.

Supponiamo che due test nel browser siano eseguiti contemporaneamente. Il primo usa task1, il secondo task2 e ciascuno mantiene i propri cookie. Assegnare lo stesso nome di sessione a entrambi chiederebbe al servizio di condividere un’assegnazione quando coincidono anche le altre impostazioni. Aprire una normale nuova scheda non crea di per sé impostazioni proxy o un archivio di cookie separati.

Identificatori diversi richiedono assegnazioni separate, ma non garantiscono universalmente IP di uscita diversi. La promessa del servizio di fornire indirizzi distinti è una proprietà separata del prodotto. L’accesso persistente non rende neppure un’uscita esclusiva del tuo account: altri clienti possono usare quell’indirizzo se appartiene a un pool condiviso.

Dove è supportato, più connessioni possono usare contemporaneamente la stessa sessione. Condividono la sua uscita e rimangono soggette ai limiti di connessioni e utilizzo dell’account. Un numero maggiore di nomi di sessione non aumenta quei limiti. Prima di un’esecuzione completa, controlla sia il numero di attività parallele sia il numero di connessioni aperte da ogni attività.

Perché l’indirizzo può cambiare prima del previsto

Un timer valido non può mantenere funzionante un’uscita indisponibile. Un dispositivo residenziale può andare offline, una connessione mobile può ricevere un IP pubblico diverso o un server può diventare irraggiungibile. La durata richiesta descrive le regole temporali dell’assegnazione; da sola non garantisce che l’uscita originale resti disponibile.

Alla perdita di un’uscita sono possibili due risposte. Un servizio può selezionare una sostituta affinché le richieste successive continuino oppure restituire un errore e mantenere il requisito di usare l’uscita originale. Alcuni prodotti permettono di scegliere. La sostituzione automatica dà priorità a stabilire un’altra connessione; un errore permette all’applicazione di fermarsi prima di proseguire da un indirizzo diverso.

Un nome invariato non dimostra che il resto delle impostazioni di sessione sia rimasto uguale. Passare a un altro gateway o cambiare il filtro del paese può creare un’assegnazione diversa. L’ambito pertinente dipende dal servizio: una sessione può appartenere a un account, prodotto o server d’ingresso specifico anziché essere disponibile ovunque sotto quel nome.

Se l’indirizzo cambia durante un’attività, la decisione successiva riguarda lo stato dell’attività. Un passaggio di sola lettura può essere sicuro da ripetere. Un’azione che ha inviato un ordine o modificato dati richiede più attenzione: perdere una risposta non dimostra che l’azione sia fallita. Stabilisci che cosa sia stato completato prima di riavviare o continuare tramite un’altra uscita.

Quando basta una continuità temporanea

L’accesso persistente si adatta a un’attività con inizio e fine chiari quando un IP è necessario soltanto durante quell’esecuzione. Verifica tre cose: che l’assegnazione superi le pause previste, duri per tutta l’attività e gestisca la perdita dell’uscita nel modo richiesto. Includi nel test una nuova connessione dopo una pausa normale; l’attività su una connessione già aperta non dimostra che l’assegnazione sopravviverà alla connessione successiva.

Se lo stesso indirizzo deve rimanere nell’elenco degli IP consentiti di un server o essere nuovamente disponibile domani, usa un servizio che offra un’assegnazione fissa per quello scopo. Riutilizzare il nome di una sessione persistente dopo la scadenza non garantisce di recuperare il vecchio indirizzo. Il mantenimento temporaneo e un IP assegnato duraturo risolvono requisiti di continuità diversi.