Коли PAC-правила, засновані на часі, вибирають проксі
Правило часу в PAC вибирає проксі під час оцінювання маршрутизації. Воно не обіцяє перемістити наявне з'єднання на новий вихід у точну секунду.
Ви можете написати PAC-правило, яке вранці повертає один проксі, а пізніше інший. Але з цього правила не можна зробити висновок, що кожне наявне з'єднання браузера змінює вихід опівдні.
Функції на кшталт timeRange() беруть участь у рішенні про маршрутизацію. Вони не є фоновим планувальником, який закриває тунелі, переміщує сокети або просить постачальника проксі змінити його публічну IP-адресу.
Тримайте три події окремо:
- Браузер оцінює PAC і отримує маршрут.
- Клієнт встановлює або повторно використовує з'єднання за своїми мережевими правилами.
- Вибрана служба вибирає публічну адресу для свого подальшого з'єднання.
Умова часу безпосередньо стосується першої події. Уже активне завантаження або тривале з'єднання — це інше. Кешування на боці клієнта й повторне використання з'єднань також означають, що «скрипт містить перевірку годинника» не є достатнім доказом точного графіка перемикання.
Якщо завданню потрібен новий вихід для кожного сеансу, запиту або часового вікна, використовуйте інтерфейс, призначений для цієї вимоги, і перевірте його документовану поведінку. PAC може вибирати серед кінцевих точок, але не визначає, що ці кінцеві точки роблять зі своїми вихідними адресами.
Маршрутизація на основі часу все ще може бути корисною для навмисної мережевої політики. Описуйте її як вибір маршруту під час оцінювання, а не як гарантований механізм зміни IP.