Quand les règles PAC temporelles choisissent un proxy
Une règle temporelle dans un PAC choisit un proxy lors de l'évaluation du routage. Elle ne promet pas de déplacer une connexion existante vers une nouvelle sortie à une seconde précise.
Vous pouvez écrire une règle PAC qui renvoie un proxy le matin et un autre plus tard. Mais vous ne pouvez pas en déduire que chaque connexion de navigateur existante change de sortie à midi.
Des fonctions comme timeRange() participent à une décision de routage. Ce ne sont pas des planificateurs d'arrière-plan qui ferment des tunnels, migrent des sockets ou demandent à un fournisseur de proxy de faire tourner son IP publique.
Gardez trois événements distincts :
- Le navigateur évalue le PAC et obtient une route.
- Le client établit ou réutilise une connexion selon ses règles réseau.
- Le service choisi sélectionne l'adresse publique de sa connexion ultérieure.
La condition temporelle concerne directement le premier événement. Un téléchargement déjà actif ou une connexion longue durée est une autre affaire. La mise en cache côté client et la réutilisation des connexions signifient aussi que « le script contient une vérification d'horloge » ne prouve pas un calendrier de bascule précis.
Si une tâche exige une nouvelle sortie par session, requête ou fenêtre temporelle, utilisez une interface conçue pour cette exigence et vérifiez son comportement documenté. Un PAC peut choisir entre des points de terminaison, mais il ne définit pas ce que ces points de terminaison font de leurs propres adresses de sortie.
Le routage temporel peut encore être utile pour une politique réseau intentionnelle. Décrivez-le comme un choix d'itinéraire au moment de l'évaluation, non comme un mécanisme garanti de rotation d'IP.