🔗 Squid 架构
🔗 总体概述
Squid 在 OSI 数据模型 的第 4-7 层进行操作。因此，与大多数网络应用程序不同，数据包（第 3 层概念）与 Squid 接收的流量之间没有关系。与数据包不同，HTTP 是基于**消息**（在 OSI 模型定义中称为段）进行操作的，其中 HTTP 请求和响应都可以被宽泛地视为传输架构中的一个“数据包”。就像 IP 数据包一样，HTTP 消息是无状态的，并且进程可以完全选择不进行传输。请参阅 RFC 7230 文本，以获得关于 HTTP 细节及其操作方式的更详细描述。
总体而言，Squid 由五个通用处理区域组成：
- 面向客户端（曾称为“客户端”）部分，实现了 HTTP、HTTPS、PROXY、FTP、SFTP、ICP、HTCP、SNMP 和“其他协议”以与客户端通信，以及
- 面向服务器（曾称为“服务器端”）部分，实现了 HTTP、HTTPS、ICY、FTP、Gopher（直到 /Releases/Squid-6）、WAIS、URN-N2H，以及盲 TCP 隧道以与 Web 服务器（有或无上游代理/中继）通信，以及
- 它们之间是缓存存储。总的来说，它提供了数据传输的缓冲机制，并提供交换逻辑来确定数据源是磁盘、内存还是服务器端。
- 在面向客户端逻辑之后、面向服务器逻辑之前，存储的每一侧都有可选的重定向，以便将流量通过内容适应服务（URI 重写、重定向、ICAP、eCAP 或 HTTP 请求/响应修改器）。
-
还有一个执行额外支持任务的组件集。例如：安全性（身份验证和访问控制）、(m)DNS 客户端、IDENT 客户端、WHOIS 客户端、日志记录、QoS、WCCP、NAT 客户端、缓存/对等集成。有些是显而易见的，有些则不然——未作为直接面向服务器或客户端的协议实现通常属于此类。
- 
待办事项：图像已过时。
- 客户端现在包括 SNMP、PROXY、FTP、（有许多 bug 的）SFTP 协议和“其他”协议。
- 存储移除了 COSS 并添加了 CLP 缓存。
- 额外处理逻辑包括 URN、ICAP、eCAP。
- 服务器端缺少 URN N2H 翻译器。
🔗 通用概述
通用设计级别是 Squid-2 和 Squid-3 不同的地方。Squid-2 完全由事件回调链组成，而 Squid-3 增加了在 Job 中封装任务的模型。
待办事项：数据流的概览图。
待办事项：从源代码中提取 I/O 事件模型、AsyncJob 模型等的现有描述。
待办事项：包含颜色编码的数据处理图，用于显示 AsyncJob 与事件回调的覆盖范围。
🔗 事务处理
当 TCP 套接字被接受时，由类 `Comm::Connection` 开始一个**连接**，或者在接收到 UDP 数据包时开始。TCP 连接在调用 `Comm::Connection::close()` 方法时结束，该方法必须显式调用。UDP 连接在 `Comm::Connection` 对象最后一个引用被释放时关闭，注意 UDP 套接字是共享的，因此 UDP 事务不得使用 `Comm::Connection::close()`，它可能会关闭所有活动的 UDP 流量。
以下适用于仅基于 TCP 的协议
一个**主事务**（类 `MasterXaction`）管理在 HTTP 或 FTP 请求及其所有相关协议消息（例如相应的 HTTP/FTP/Gopher/etc. 协议响应和控制消息）以及由协议消息引起的 ICAP、eCAP 和辅助事务之间共享的信息。收集和共享这些信息所需的大部分代码尚未开发。
一个**流事务**是带有相应最终协议回复的 HTTP 或 FTP 请求。当协议请求到达连接时，它以类 `!Parser` 的 `successful parse()` 调用开始。来自其 `MasterXaction` 的详细信息被复制到 `AccessLogEntry` 中，该条目累积有关流的详细信息，并最终进入 `access.log`。
一个**ICAP 事务**（类 `Adaptation::Icap::Xaction`）是带有相应最终 ICAP 响应的 ICAP 请求。单个主事务可能发生许多 ICAP 事务，并且，我记得，ICAP OPTIONS 再验证事务在没有主事务的情况下发生。
一个**辅助事务**（类 `Helper::Xaction`）可能为 `squid.conf` 设置可能导致流事务使用的每个插件辅助程序而发生。
待办事项：修改**主事务**定义以适应涉及流和内容适应的 UDP 协议。例如 SNMPv3、HTTP/3、QUICK、CoAP、CoAPS、DNS、WebSockets3。
🔗 HTTP 请求
大多数 HTTP 请求都应用了以下一系列检查和调整。此序列在 Squid 解析请求头后开始，在 Squid 从缓存或源服务器开始满足请求之前结束。检查按执行顺序在此列出。
- Host 头伪造检查
- http_access 指令
- ICAP/eCAP 适应
- 重定向器
- adapted_http_access 指令
- store_id 指令
- clientInterpretRequestHeaders()
- cache 指令
- ToS 标记
- nf 标记
- ssl_bump 指令
- 回调序列错误处理
失败的检查可能会阻止后续检查运行。
一个典型的 HTTP 事务（即，一对 HTTP 请求和响应消息）会经历一次上述序列。然而，多个事务可能参与处理单个“网页下载”，这让 Squid 管理员感到困惑。虽然所有经验丰富的 Squid 管理员都知道单个网页可能包含数十甚至数百个资源，每个资源都会触发一个 HTTP 事务，但即使请求单个资源，甚至在使用 curl 或 wget 等简单的命令行工具时，也可能发生这些多个事务。
内部 Squid 请求可能会导致更多混淆。例如，当使用 SslBump 时，Squid 可能会为给定的 TLS 连接创建多个伪 CONNECT 事务，并且每个 CONNECT 可能都会经历上述过程。如果您使用 SslBump 来拦截端口 443 流量，那么在 Squid 接受新连接后不久，SslBump 会创建一个具有 TCP 级别信息的伪 CONNECT 请求，并且该 CONNECT 请求会经历相同的序列（匹配任何 SslBump1 ACL）。如果在第一个 SslBump 步骤中匹配了“ssl_bump peek”或“ssl_bump stare”规则，则 SslBump 代码会获取 SNI 并创建第二个伪 CONNECT 请求，该请求会再次经历相同的序列。
类似地，(S)FTP 原生服务将流事务中的每条消息转换为各种 HTTP 消息，这些消息应该会经历上述过程。
您的 Squid 指令和辅助程序必须准备好处理每个连接的多个CONNECT请求。
待办事项：记录转发目标选择。
待办事项：HTTP 响应回调处理序列。
待办事项：非 TCP 事务处理序列？
待办事项：非 HTTP 流事务？