Squid Web Cache Wiki

Squid Web Cache 文档

🔗 缓存管理器

它是 Squid 内部子系统，为注册、查找和触发管理操作提供了一种通用方式。它通过 HTTP 与外部世界进行交互，响应使用众所周知的 URL 路径 /squid-internal-mgr（例如 http://127.0.0.1:3128/squid-internal-mgr/menu）发出的请求，或者（直到 Squid 6.5）响应使用 cache_object: URL 方案发出的请求。

有时它会被与 缓存管理器 CGI 混淆。后者只是一个外部 CGI 应用程序，它读取 Squid 缓存管理器的数据并以 HTML 形式呈现。

该子系统维护一个包含现有操作的表。对于每个元组，它都会为特定操作提供一个唯一的名称、一个简短的描述以及在调用该项时要调用的处理程序。还可以设置一些标志，例如指示需要密码的标志。

🔗 访问管理器报告的方式

Squid 包附带了一些用于访问缓存管理器的工具。

鉴于缓存管理器使用纯 HTTP，开发自定义工具是可能的——事实上也很容易。最常见的是 curl，例如：

curl -u user:pasword http://127.0.0.1:3128/squid-internal-mgr/menu

🔗 控制对缓存管理器的访问

squid.conf 中的默认缓存管理器访问配置是：

http_access allow localhost manager
http_access deny manager

:information_source: 此默认设置已更新，以适应 Squid-3.2 中的更改。对于旧版 squid，squid.conf 条目可能看起来不同。

🔗 远程管理

默认 ACL 假定您的 Web 服务器与 squid 在同一台机器上。请记住，从缓存管理器 CGI 程序到 squid 的连接源自*Web 服务器*，而不是浏览器。因此，如果您的 Web 服务器位于其他地方，您应该确保已安装 cachemgr.cgi 的 Web 服务器的 IP 地址具有访问权限。

要允许远程管理员（即 cachemgr.cgi），请调整访问控制以包含远程 IP。

acl managerAdmin src 192.0.2.1

http_access allow localhost manager
http_access allow managerAdmin manager
http_access deny manager

🔗 管理操作的密码

执行诸如关闭或重新配置缓存之类的管理操作需要密码。出于安全考虑，默认未设置密码，这意味着这些命令操作在您为其设置密码之前不可用。

您可以设置 cachemgr_passwd 指令，为一项或多项管理器操作和/或报告访问设置特定密码。此指令允许您为每个报告设置不同的密码，或将它们分组，以便多个管理员获得不同的访问权限。

Squid 将使用 Basic Authentication 来检索访问报告所需的密码。如果配置了 auth_param，则会使用该辅助程序来验证用户名和密码是否正确。否则，将忽略用户名，并将密码与正在访问的报告的 cachemgr_passwd 进行比较。

刷新对象（即从其原始源再次检索它）需要 URL。

默认情况下，这些详细信息是访问缓存管理器中大多数报告的可选项。

其中 192.0.2.1 是安装了 cachemgr.cgi 的 Web 服务器或管理员工作站的 IP 地址。

🔗 SMP 考虑

当 Squid 在 SMP 模式下运行时，缓存管理器应提供“整个 Squid”的视图（受此处未讨论的可选 SMP 工作进程和进程范围限制）。在大多数重要情况下，它确实如此，但也有例外。本节详细介绍了每个报告的 SMP 支持级别。

要理解如何解释 SMP 缓存管理器响应，了解它们是如何计算的很有用。SMP 缓存管理器查询由一个操作系统选择的工作进程接收，就像任何其他 HTTP 请求一样。接收工作进程通过 IPC 将查询转发给协调器进程。协调器通过 IPC 一次一个地将相同的查询发送给每个子进程（包括原始查询接收者和协调器本身），并聚合子进程的响应。接收协调器请求的子进程 K 可以：

下表详细说明了每个缓存管理器对象或报告的 SMP 支持。除非另有说明，聚合统计信息是所有子进程的总和、算术平均值、最小值或最大值，以适合表示“整个 Squid”的视图。如果对于任何已记录的对象，“适当”的选择不明确，请更新表格以澄清或提交文档错误报告。

名称 组件 聚合？ 评论
menu all 是  
info 访问缓存的客户端数量 yes, poorly 协调器汇总每个子进程报告的客户端数量，这通常是错误的，因为大多数活动客户端将使用多个工作进程，导致值过高。请注意，即使没有 SMP，此统计信息也可能过高，因为当 Squid 清理内部客户端表时计数会下降，而不是在最后一个客户端连接关闭时。SMP 会放大这种效果。
  UP Time 是 报告所有子进程中的最大正常运行时间。
  other 是  
server_list all no, but can be 如果您正在聚合这些统计信息，请记住子进程可能有不同的对等集。发送到协调器的响应应包括每个对等体的名称，而不仅仅是其“索引”。
mem all no, but can be 如果您正在聚合这些统计信息，请记住子进程可能有不同的内存池集。发送到协调器的响应应包括每个池的名称，而不仅仅是其“索引”。完整的统计信息可能会超出典型的 UDS 消息大小限制（16KB）。如果可能发生溢出，最好创建响应消息，以便不包含溢出的项（按当前排序顺序）。另一种选择是将 mgr:mem 分成 mgr:mem（包含各种聚合的总计）和 mgr:pools（包含未聚合的每个池的详细信息）。
counters sample_time 是 报告所有子进程中的最新（最大）采样时间。
refresh all no, but can be  
idns queue no and should not be 子进程可能应该报告自己的队列，尤其因为 DNS 查询 ID 是子进程特有的。
  other no, but can be 如果您正在聚合这些统计信息，请记住子进程可能有不同的名称服务器集。发送到协调器的响应应包括每个名称服务器的地址，而不仅仅是其“索引”。
histograms all no, but can be 如果您正在聚合这些统计信息，请记住典型的 UDS 消息大小限制（16KB）。
5min sample_start_time 是 报告所有子进程中的最早（最小）采样时间。
  sample_end_time 是 报告所有子进程中的最新（最大）采样时间。
  *median* yes, approximately 报告子进程中位数的算术平均值。这不是真正的中位数。真正的中位数报告是可能的，但这需要添加代码来交换和聚合原始直方图。
  other 是  
60min all   有关组件详细信息，请参见 5min 行。
utilization all no, but can be 如果您正在聚合这些统计信息，请重用或模仿 mgr:5min/60min 聚合代码。
other all varies TBD。通常，"by kidK {...}" 块中的统计信息*不会*被聚合，而所有其他统计信息都会被聚合。

虽然以上所有信息都经过了某种程度的验证，但缓存管理器对象的数量（及其组件）以及 Squid 的持续更改几乎保证会存在一些错误和差异。您应该测试您依赖的统计数据（例如，在受控的实验室环境中）并根据需要提交错误报告。

🔗 安全 SMP 报告

当 Squid 在 SMP 模式下运行时，目前仅支持*不安全*的缓存管理器请求（即通过 http_port 收到的请求）。

如果您尝试向安全的 https_port 发送缓存管理器查询会发生什么？在安全连接上接收管理请求的 Squid 工作进程不会将响应发送回。相反，协调器和/或其他进程使用从安全工作进程接收的原始 TCP 套接字描述符直接将缓存管理器响应发送给安全客户端。由于这些 Squid 进程不知道连接应该是加密的，并且没有访问加密状态，因此它们会发送明文数据，这会让期望加密流的客户端感到困惑。

为了支持安全的缓存管理器请求（即通过 https_port 收到的请求），我们可能需要限制将缓存管理器响应写入安全工作进程，但这很困难，因为我们仍然希望支持大型（不可聚合）的缓存管理器响应，其中每个工作进程都应该产生自己的响应流。安全工作进程可能需要接收并将这些流转发给客户端。

作为一种变通方法，可以创建一个安全的隧道（使用 ssh 或 stunnel 等安全 TCP 隧道程序）到一个分配给环回地址的 Squid http_port，并通过该隧道安全地发送所有缓存管理器请求。这样 Squid 就无需处理加密，SMP 缓存管理器查询也能正常工作。当然，这种变通方法仅在可以认为未加密的环回流量是安全的地方才是安全的。

🔗 理解管理器报告

🔗 Squid TCP 连接和 Squid UDP 连接有什么区别？

浏览器和缓存使用 TCP 连接从 Web 服务器或缓存中检索 Web 对象。当另一个使用您作为兄弟或父缓存的缓存想要查找您缓存中是否有它正在寻找的对象时，将使用 UDP 连接。UDP 连接是 ICP 或 HTCP 查询。

🔗 它说存储过期将在 1970 年发生！

别担心。squid 的默认（也是明智的）行为是在对象被覆盖时将其过期。它不会显式地进行垃圾回收（除非您通过其他方式告诉它）。

🔗 元数据条目是什么意思？

基本上就像缓存目录中的日志文件一样。

如果squid 比此字段小很多，赶快跑！有什么不对劲，您可能需要重启squid。

🔗 AVG RTT 是什么意思？

平均往返时间。这是从发送 ICP ping 到收到回复的平均时间。

🔗 “Page faults with physical i/o: 4897” 是什么意思？

这个问题是在 ‘’squid-users’’ 邮件列表中提出的，并得到了三个极好的答复。

作者：*Jonathan Larmour*

当您的操作系统尝试访问实际上已交换到磁盘的内存时，您会遇到“页面错误”。“页面错误”这个词虽然在内核和 CPU 层面是正确的，但对用户来说有点误导，因为这并不是一个实际的错误——这是正常运行的特征。

另外，这并不一定意味着您的 squid 交换了那么多。大多数操作系统也为可执行文件实现了分页，因此只有实际使用的可执行文件部分才会被从磁盘读取到内存中。此外，每当 squid 需要更多内存时，内存被分配的事实就会显示在页面错误中。

但是，如果错误的数量异常高并且还在增加，这可能意味着 squid 正在交换。另一种验证方法是使用一个名为“vmstat”的程序，该程序在大多数 UNIX 平台上都可以找到。如果您将其运行为“vmstat 5”，它将每 5 秒更新一次显示。这可以告诉您整个系统是否正在大量交换（有关更多信息，请参阅您的 vmstat 本地手册页）。

Squid 交换非常糟糕，因为每个请求都会被阻塞，直到请求的数据被交换进来。最好调整 squid.conf 中的 cache_mem 和/或 memory_pools 指令，而不是允许这种情况发生。

作者：*Peter Wemm*

有两种不同的操作：分页和交换。分页是页面被重新排序（丢弃或交换到/从磁盘），而“交换”*通常*意味着整个进程被发送到/从磁盘。

不用说，交换进程是一个相当剧烈的事件，通常只保留在内存不足且分页无法足够快地释放足够内存时使用。此外，交换在不同操作系统上的实现方式也有所不同。有些根本不做，或者做分页和交换的混合。

正如您所说，分页不一定涉及磁盘 I/O，例如：文本（代码）页面是只读的，如果它们不被使用（并在需要时重新加载）就可以简单地丢弃。数据页面如果不修改也会被丢弃，如果修改了就会被分页出去。分配的内存（malloc）总是保存到磁盘，因为没有可执行文件可以恢复数据。mmap() 内存是可变的。如果它由文件支持，它遵循与文件数据段相同的规则——即，如果未修改则丢弃，或分页出去。

还有“需求零填充”页面，这也会导致错误。如果您 malloc 内存并调用 brk()/sbrk() 来分配新页面，那么您很可能分配了需求零填充页面。也就是说，这些页面还没有真正附加到您的进程，但是当您第一次访问它们时，页面错误会导致页面连接到进程地址空间并归零——这可以避免分配但从未使用过的页面的不必要归零。

“带物理 I/O 的页面错误”来自操作系统，通过 getrusage()。它的含义高度依赖于操作系统。通常，这意味着进程访问了一个不在内存中的页面（无论出于何种原因），并且有磁盘访问来获取它。许多操作系统也通过需求分页加载可执行文件，因此启动 squid 本身就会导致带磁盘 I/O 的页面错误——但是，许多（但不是所有）操作系统都使用“预读”和“预填充”启发式来简化加载。一些操作系统维护“意图队列”，以便页面可以提前被选为页面输出候选。当（例如）squid 触摸新分配的需求零填充页面并且需要一个时，操作系统可以立即页面输出候选队列中的一个，导致带物理 I/O 的错误，而这在许多其他操作系统上不会发生。（其他操作系统通常会让进程休眠，直到页面输出守护进程找到一个页面给它）。

“交换”的含义各不相同。例如，在 FreeBSD 上，交换实现为解锁 upages、内核堆栈、PTD 等以进行积极的页面输出，进程只剩下‘struct proc’。FreeBSD 的分页系统具有高度适应性，可以以等同于传统交换风格操作（即整个进程）的方式进行分页。FreeBSD 还尝试从活动进程中窃取页面，以便为磁盘缓存腾出空间。我怀疑这就是为什么在 FreeBSD 上为非 NOVM squids 设置‘memory_pools off’效果更好的原因——VM/缓冲区系统可能正在与 squid 竞争缓存相同的页面。可惜 squid 不能使用 mmap() 来在其内存池中进行 4K 块的文件 I/O（我知道这并不容易，但这不会阻止我许愿:-）。

作者：*John Line*

到目前为止的评论都集中在“传统”意义上的分页/交换数字的含义，但值得记住的是，在某些系统（至少是 Sun 的 Solaris 2）上，虚拟内存和文件系统处理是统一的，用户进程读取或写入文件的行为，系统只是将其视为从磁盘分页入或页面更新需要分页出。（我猜您可以将其视为操作系统在后台将文件内存映射）。

其结果是，在 Solaris 2 上，分页数字也包括文件 I/O。或者更确切地说，vmstat 中的数字似乎确实包括文件 I/O，我猜测（但无法快速测试）Squid 引用的数字也包括文件 I/O。

为了确认上述内容（这代表了我阅读和观察到的印象，而不是 100% 确定的事实…），我在一个完全空闲的 Sun Ultra 1 系统上尝试使用 cat（小巧，不需要分页）将（a）一个文件复制到另一个文件，（b）一个文件复制到 /dev/null，（c）/dev/zero 复制到一个文件，以及（d）/dev/zero 复制到 /dev/null（后两个在一段时间后用 Control-C 中断！），同时用 vmstat 观察。在读取或写入文件（而不是设备）时，每秒有 300-600 次页面读取或页面输出，其他情况（以及未 cat 时）则几乎为零。

所以……请注意不要假设所有系统都相同，并且分页数字*仅*代表程序代码和数据在磁盘之间的移动——它们也可能包括读取/写入您访问过的所有文件的操作…

好的，那么什么是异常高的呢？

您可能需要将页面错误的数量与 HTTP 请求的数量进行比较。如果这个比例接近或超过 1，那么 Squid 就分页太多了。

🔗 “缓存服务器列表”中的 IGNORED 字段是什么意思？

这指的是 Squid 忽略的 ICP 回复，原因如下：

🔗 内部

在初始化时，只会注册少数几个操作。其中最重要的是 menu，它负责枚举表中当前可用的操作。在此初始化之后，各种代码片段将使用 Mgr::RegisterAction API 注册不同的新处理程序和描述。

内部，处理程序是具有通用原型的 C 函数。

🔗 另请参阅

导航： 网站搜索， 网站页面， 类别， 🔼 向上