最近，一位系统 [Windows] 工程师就他的文件系统 ACL 与网络 ACL 的工作原理中更合乎逻辑的应用程序展开了辩论。
网络 ACL 通常通过按顺序（自上而下）应用 ACE 并在第一次匹配时停止来工作。文件系统 ACL（尤其是 NTFS）通过考虑所有 ACE 并授予最多权限来工作，除非遇到拒绝 ACE。
为什么网络 ACL 以它们的方式工作，为什么不应该将它们与我直观理解的文件系统 ACL 进行比较？
根据我的理解，网络 ACL 的工作方式如下：
不用说，您的想法是正确的，这一切都归结为速度和灵活性。这与您必须检查的运行时操作和参数的数量直接相关。我不是 Windows 文件系统 ACL 的专家，但从概念上讲，事实保持不变。
看一看Windows 文件系统 ACL的可扩展性，您是否可以看到，对于广泛的属性和安全级别，您有许多不同的选项。这些选项中的每一个都带有一定程度的内存和 CPU 损失。目标是提供一个灵活的、无缝的权限结构，同时仍然提供精细的控制。这包括不同文件系统、帐户类型和环境的功能。它是为特定目的而构建的，即文件控制，它不一定需要像 6509 那样以每秒超过1 亿个事件的速度运行。
在频谱的另一端，您拥有在设计时考虑到速度的网络 ACL 。当您创建 ACL 时，您不仅拥有一个执行这些比较的硬件优化平台，而且您还有一组严格的按位操作1。使用标准 ACL，您只需查看源地址和目标地址；不分青红皂白的任何其他 TCP/IP 变量。
从欧洲高级网络测试中心 (EANTC) 获取以下测试结果。他们以 90% 的线速对具有 32 个 10Gb 端口的 6500 进行压力测试，数据包大小为 64 字节（压力最大），来自完全唯一的地址，然后将其与在第 10,001 个条目处匹配的 10,000 线 ACL 进行比较。它产生最小的线速下降和零损耗。
EANTC：带有 Supervisor720 的 Cisco Catalyst 6500 — 10 千兆位以太网性能测试
虽然这并没有显示延迟，这将是这些平台速度的真正证明，但他们确实说继续说“Catalyst 性能不受添加增值服务（例如 ACL、QoS 流量分类和 NetFlow 统计）的影响搜集。”
一旦您希望增加额外的灵活性（例如扩展 ACL），您就需要对数据进行额外的检查。这增加了延迟。关键是您选择最适合您业务需求的应用程序。当标准 ACL 可以做到时，并不是每个人都需要扩展 ACL。
正如评论中大多数指出的那样，路由器每时每刻都需要执行的例程数量几乎在各个方面都使文件系统 ACL 相形见绌。这是否意味着他们更好？不必要。但他们的工作肯定更快，只是有限。
1这是假设没有发生日志记录，这依赖于 CPU 处理来记录消息。
正如评论中所指出的，这是为了速度。
在另一个生活中成为文件服务器老兄，并经历了内部合规性审计，使最糟糕的 PCI 检查看起来像野餐，让我还补充一点：
自上而下的网络 ACL 会强制您在实施/更新访问列表时真正投入更多的精力来组织访问列表，并且比文件系统 ACL 更清晰、更容易阅读。
文件系统 ACL 具有方便的优势，但会带来更大的意外后果。
当然，如果您的环境不担心安全性，那么这不是问题。