🔗 内容适应
代理服务器可以分析、捕获、阻止、替换或修改其代理的消息。这类操作通常被称为内容适应，尽管其中一些操作实际上并未更改任何内容。
Squid 可以配置或修改以执行某些形式的内容适应。本文档重点介绍 Squid 支持的内容适应方法。
🔗 用例
以下是典型的内容适应需求。下面列出的几乎所有适应都已通过本文档中描述的一种或多种机制实现。
- 添加、删除或修改 HTTP 标头字段（例如，Cookie）
- 基于请求 URL 阻止消息
- 基于内容阻止消息
- 将某些请求重定向到自定义页面或服务器
- 用自定义页面响应某些请求
- 修改页面以插入新内容（例如，警告或广告）
- 修改页面以删除现有内容（例如，图片或广告）
- 缩放嵌入式图像（例如，用于移动设备）
🔗 适应机制
🔗 ICAP
Internet Content Adaptation Protocol (RFC 3507, subject to errata) 规定了 HTTP 代理（ICAP 客户端）如何将内容适应外包给外部 ICAP 服务器。包括 Squid 在内的大多数流行代理都支持 ICAP。如果您的适应算法驻留在 ICAP 服务器中，它将能够在各种环境中工作，并且不会依赖于单一的代理项目或供应商。使用 ICAP 进行大多数内容适应时，不需要修改代理代码。
优点：独立于代理，面向适应的 API，无需修改 Squid，支持远程适应服务器，可扩展。
缺点：通信延迟，协议功能限制，需要独立的 ICAP 服务器进程或设备。
一个代理可以访问多个 ICAP 服务器，一个 ICAP 服务器可以被多个代理访问。ICAP 服务器可以与 Squid 驻留在同一物理机器上，也可以运行在远程主机上。根据配置和上下文，某些 ICAP 故障可以被绕过，从而对代理最终用户不可见。
请参阅 功能：ICAP
🔗 Client Streams
Squid 提供了专为嵌入式服务器端包含（ESI）设计的 ClientStreams 类。Client Streams 节点可以访问从源服务器接收到的 HTTP 响应消息，或从缓存中获取的消息。通过修改 Squid 代码，可以添加执行自定义内容适应的新节点。Client Streams 仅限于响应修改。
优点：速度快，集成度高。
缺点：API 文档有限，缺乏支持，无法适应请求，依赖于 Squid（安装、代码、许可证）。
不幸的是，Client Streams 的创建者已经有一段时间没有积极参与 Squid 的开发了，可用的 API 文档很少，并且代码的长期可持续性尚不确定。与 Squid 集成的自定义 Client Streams 代码可能需要根据 GPL 获得许可。
🔗 eCAP
eCAP 服务类似于嵌入到 Squid 中的 ICAP 服务。eCAP 是一种接口，它允许 Squid 和其他服务器使用动态或静态加载到宿主应用程序中的嵌入式适应模块。这种方法实现了快速的内容适应，而无需紧密依赖 Squid 源代码。其他代理甚至 ICAP 服务器也可以选择支持相同的 API，从而消除了对 Squid 的依赖。
优点：速度快，集成度高，面向适应的 API，无需修改 Squid。
缺点：依赖于 Squid 的安装（至少在初期）
从 Squid 3.1 开始提供对 eCAP 的初步支持。您可以在 Features/eCAP 中找到更多详细信息。
🔗 Squid.conf ACLs
简单的 HTTP 请求标头适应无需编写任何代码即可实现。Squid 支持一些配置选项，允许管理员添加、删除或替换指定的 HTTP 请求标头：request_header_add、request_header_access 和 request_header_replace。类似的指令可用于适应响应标头。
优点：速度快，集成度高，面向适应的 API，无需修改 Squid。
缺点：仅限于简单的标头适应，依赖于 Squid 的安装。
标头操作支持的程度取决于 Squid 版本：某些版本不允许添加新标头，而某些版本不允许替换旧响应标头，例如。
🔗 代码修改
可以通过修改 Squid 源代码来实现自定义内容适应，而无需使用上面描述的 Client Streams 机制。简单的通用适应（例如标头操作）可能会被接受到官方 Squid 代码库中，从而最大限度地减少长期的维护开销。
优点：速度快，集成度高。
缺点：必须研究 Squid 源代码），支持有限，依赖于 Squid（安装、代码、许可证）。
不幸的是，大多数适应都相对复杂，不仅限于标头，或者高度定制化，因此不太可能被接受。消息正文适应尤其困难，因为 Squid 不会缓冲整个消息正文，而是一次处理一块半随机的内容。
关注 Squid 代码质量和膨胀的开发人员可能不愿意帮助您解决特定的编码问题。另一方面，您可能需要在每次 Squid 发布时修改您的代码，并根据 GPL 对您的软件进行许可。该代码将无法与其他代理一起使用。
🔗 总结
某些适应机制的范围有限。下表总结了这些机制可以适应的消息和消息部分。
| 机制 | 请求标头 | 请求正文 | 响应标头 | 响应正文 |
|---|---|---|---|---|
| ICAP | 是 | 是 | 是 | 是 |
| 客户端流 | 是 | 是 | ||
| eCAP | 是 | 是 | 是 | 是 |
| ACLs | 是 | del | ||
| 代码修改 | 是 | 是 | 是 | 是 |
每种适应机制都有其优势和劣势。下表试图使用常用的评估标准对机制进行排序。
| 评估标准 | 机制大致从“最佳”到“最差”排序 |
|---|---|
| Squid 独立性 | ICAP, eCAP, ACLs, Client Streams, 代码修改 |
| 处理速度 | eCAP 或 Client Streams 或 ACLs 或 代码修改, ICAP |
| 开发工作量（标头适应） | ACLs, 代码修改, Client Streams, eCAP, ICAP |
| 开发工作量（内容适应） | eCAP, ICAP, Client Streams, 代码修改 |
| 多功能性 | 代码修改, eCAP, ICAP, Client Streams, ACLs |
| 维护开销 | ACLs, eCAP, ICAP, Client Streams, 代码修改 |
🔗 附加资源
🔗 警告
某些形式的内容适应被 IETF 视为有害（例如，参见 RFC 3238）。许多形式的内容适应会惹恼内容所有者、生产者、消费者，或所有上述人员。并非所有技术上可行的事情都是符合道德、可取或合法的。在适应他人内容之前请三思！
回到 FAQ 索引
导航： 网站搜索、网站页面、分类、🔼 向上