"более специфичный" -- это искуственно внесенное правило для возможности паралельной обработки. собственно для файрвольных правил это тоже может работать (хоть и не всегда и вообще предмет для дискурсии). шлюз, кстати, не конкретный -- бывает и в интерфейс (даже езернетовский и я этим пользовался) и бывает несколько шлюзов.
А про синтаксис - автоматически однозначно оптимизировать можно только линейный набор правил. Но линейный набор правил не годится для очень многих практических задач.
пфф. основная проблема к производительности файрволов -- то, что они медленно отрабатывают тысячу другую правил. которые скорее будут типа
permit from {список} to host dst-port 443 deny from any to host dst-port 443
и так для 100500 разных хостов и портов, а вовсе не цепочкой из 100500 дивертов и нетграфов. т.е. они тоже могут встретиться, но их не будет 100500 последовательных и это никак не мешает 100500 линейных обрабатывать паралельно. но более другой синтаксис мог бы эту задачу облегчить и/или избавить от глупых ошибок типа
permit 10.0.0.0/8 to host deny 10.0.1.0/24 to host
no subject
собственно для файрвольных правил это тоже может работать (хоть и не всегда и вообще предмет для дискурсии).
шлюз, кстати, не конкретный -- бывает и в интерфейс (даже езернетовский и я этим пользовался) и бывает несколько шлюзов.
пфф. основная проблема к производительности файрволов -- то, что они медленно отрабатывают тысячу другую правил. которые скорее будут типа
permit from {список} to host dst-port 443
deny from any to host dst-port 443
и так для 100500 разных хостов и портов, а вовсе не цепочкой из 100500 дивертов и нетграфов. т.е. они тоже могут встретиться, но их не будет 100500 последовательных и это никак не мешает 100500 линейных обрабатывать паралельно. но более другой синтаксис мог бы эту задачу облегчить и/или избавить от глупых ошибок типа
permit 10.0.0.0/8 to host
deny 10.0.1.0/24 to host
второе правило никогда не сработает.