Quando le regole PAC basate sul tempo scelgono un proxy
Una regola temporale in un PAC sceglie un proxy quando viene valutato l'instradamento. Non promette di spostare una connessione esistente su una nuova uscita in un secondo preciso.
Puoi scrivere una regola PAC che restituisce un proxy al mattino e un altro più tardi. Ma non puoi dedurre da quella regola che ogni connessione browser esistente cambi uscita a mezzogiorno.
Funzioni come timeRange() partecipano a una decisione di instradamento. Non sono un pianificatore in background che chiude tunnel, migra socket o chiede a un fornitore di proxy di ruotare il suo IP pubblico.
Tieni separati tre eventi:
- Il browser valuta il PAC e ottiene una route.
- Il client stabilisce o riutilizza una connessione secondo le sue regole di rete.
- Il servizio scelto seleziona l'indirizzo pubblico per la sua connessione successiva.
La condizione temporale riguarda direttamente il primo evento. Un download già attivo o una connessione di lunga durata è un'altra questione. La cache del client e il riutilizzo delle connessioni implicano anche che «lo script contiene un controllo dell'orologio» non è una prova sufficiente di un calendario di commutazione preciso.
Se un'attività richiede una nuova uscita per sessione, richiesta o finestra temporale, usa un'interfaccia progettata per quel requisito e verifica il suo comportamento documentato. Un PAC può scegliere tra endpoint, ma non definisce cosa fanno quegli endpoint con i propri indirizzi di uscita.
L'instradamento basato sul tempo può comunque essere utile per una politica di rete intenzionale. Descrivilo come scelta di una route al momento della valutazione, non come meccanismo garantito di rotazione IP.