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