Kiedy reguły PAC oparte na czasie wybierają proxy
Reguła czasu w PAC wybiera proxy podczas oceny routingu. Nie obiecuje przeniesienia istniejącego połączenia na nowe wyjście w dokładnej sekundzie.
Możesz napisać regułę PAC, która rano zwraca jedno proxy, a później inne. Nie można jednak z tej reguły wnioskować, że każde istniejące połączenie przeglądarki zmienia wyjście w południe.
Funkcje takie jak timeRange() uczestniczą w decyzji o routingu. Nie są planistą działającym w tle, który zamyka tunele, migruje gniazda lub prosi dostawcę proxy o rotację publicznego IP.
Trzy zdarzenia należy rozdzielić:
- Przeglądarka ocenia PAC i otrzymuje trasę.
- Klient nawiązuje lub ponownie wykorzystuje połączenie zgodnie ze swoimi regułami sieciowymi.
- Wybrana usługa wybiera publiczny adres dla swojego dalszego połączenia.
Warunek czasu dotyczy bezpośrednio pierwszego zdarzenia. Już aktywne pobieranie lub długotrwałe połączenie to inna sprawa. Buforowanie po stronie klienta i ponowne wykorzystywanie połączeń oznaczają też, że „skrypt zawiera sprawdzenie zegara” nie jest wystarczającym dowodem precyzyjnego harmonogramu przełączania.
Jeśli zadanie wymaga nowego wyjścia dla każdej sesji, żądania lub okna czasowego, użyj interfejsu zaprojektowanego dla tego wymagania i zweryfikuj jego udokumentowane zachowanie. PAC może wybierać spośród punktów końcowych, ale nie definiuje, co te punkty końcowe robią ze swoimi adresami wyjściowymi.
Routing oparty na czasie nadal może być przydatny w zamierzonej polityce sieciowej. Opisuj go jako wybór trasy w momencie oceny, a nie jako gwarantowany mechanizm rotacji IP.