Când regulile PAC bazate pe timp aleg un proxy
O regulă de timp dintr-un PAC alege un proxy când rutarea este evaluată. Nu promite mutarea unei conexiuni existente către o ieșire nouă într-o secundă exactă.
Puteți scrie o regulă PAC care returnează un proxy dimineața și altul mai târziu. Dar nu puteți deduce din acea regulă că fiecare conexiune existentă a browserului își schimbă ieșirea la prânz.
Funcții precum timeRange() participă la o decizie de rutare. Nu sunt un planificator de fundal care închide tuneluri, migrează socketuri sau cere unui furnizor de proxy să își rotească IP-ul public.
Țineți trei evenimente separate:
- Browserul evaluează PAC-ul și obține o rută.
- Clientul stabilește sau reutilizează o conexiune conform regulilor sale de rețea.
- Serviciul ales selectează adresa publică pentru conexiunea sa ulterioară.
Condiția de timp privește direct primul eveniment. Un download deja activ sau o conexiune de lungă durată este altă chestiune. Cache-ul clientului și reutilizarea conexiunilor înseamnă și că „scriptul conține o verificare a ceasului” nu este o dovadă suficientă pentru un program precis de comutare.
Dacă o sarcină are nevoie de o ieșire nouă pe sesiune, cerere sau fereastră de timp, folosiți o interfață concepută pentru această cerință și verificați comportamentul ei documentat. Un PAC poate alege între puncte finale, dar nu definește ce fac acele puncte finale cu propriile adrese de ieșire.
Rutarea bazată pe timp poate fi în continuare utilă pentru o politică de rețea intenționată. Descrieți-o ca alegere a unei rute în momentul evaluării, nu ca mecanism garantat de rotație a IP-ului.