🔗 功能：原生 FTP 代理
- 目标：将现有的访问控制和内容适应功能应用于原生 FTP (端口 21) 流量。为未来缓存原生 FTP 响应构建框架。
- 状态：已完成。
- 版本: 3.5
- 开发者：AlexRousskov 和 Dmitry Kurochkin
- 更多：lp 分支；squid-dev 讨论于 8 月 和 9 月 2012 年
🔗 功能
此项目为 squid.conf 添加了 ftp_port 选项。Squid 作为 FTP 到 FTP 的网关，处理发送到该端口的 TCP 流量。
- Squid 监听发送到配置端口的原生 FTP 请求。
- Squid 将收到的 FTP 命令转换为内部 HTTP 包装请求，
- Squid 将这些内部请求从客户端转发到服务器端（照常对其应用访问控制和可选内容适应）。
- 未来，Squid 甚至可能将这些 HTTP 包装请求转发给对等节点，但这超出了初始实现的范围。
- 在服务器端，Squid 将 HTTP 包装请求转换为 FTP 命令，并将这些命令转发给 FTP 服务器。
- 同样，FTP 服务器响应也会被包装在 HTTP 响应中转发回 FTP 客户端。
- Squid 使用 HTTP 包装和现有的访问日志代码记录 FTP 事务。
🔗 映射
🔗 FTP 命令到 HTTP 请求的映射
每个 FTP 命令（无论 Squid 是否理解）都映射到一个 HTTP 请求。
| HTTP 请求属性 | 映射算法 |
|---|---|
| 请求方法 | 对于 FTP STOR 使用“PUT”。否则 GET？ |
| 请求 URI | ftp://host/ （目前；参见未来增强功能） |
| 请求协议和版本 | HTTP/1.1 （对于 Squid 核心而言，这些包装消息就是这个。此外，一些 ICAP 服务可能无法处理 FTP/x.y） |
| Host 头部 | FTP 服务器名称，后跟非标准端口（如果存在） |
| FTP-Command | FTP 命令名称 |
| FTP-Arguments | FTP 命令参数（即，FTP 命令名称和 CRLF 之间的所有内容）。如果 CRLF 紧跟命令名称，则不存在。如果 SP CRLF 紧跟命令名称，则存在但为空。 |
🔗 FTP 回复到 HTTP 响应的映射
| HTTP 响应属性 | 映射算法 |
|---|---|
| 响应状态码和原因短语 | 对于任何被识别的 FTP 1xx 回复，为 100 Continue；对于任何其他被识别的 FTP 服务器回复，为 200 OK；否则为 500 Server Error。 |
| 请求协议和版本 | HTTP/1.1 （这样 ICAP 服务就不会因 FTP/x.y 而失败） |
| 日期 | FTP 回复开始日期 |
| Cache-Control | “private”（在跟踪请求 URI 之前，Squid 无法缓存这些） |
| Content-Length | 如果有关联的文件传输，则无；否则为零。 |
| FTP-Status | FTP 回复代码（例如，431） |
| FTP-Reason | FTP 解释性文本（例如，“目录不存在”）。 |
🔗 FTP 主体传输的映射
Squid 不使用 HTTP 构造在内部转发 HTTP 主体。代码将必须使用现有的 Squid 主体转发 API（请求主体的 BodyPipe 和响应主体的 Store）。
🔗 传输失败
像 HTTP 主体传输失败一样终止主体传输。对于回复主体，向客户端发送一个 1xx 控制消息，指示最终的 FTP 状态码。
🔗 映射示例
| 标签 | FTP-C | Squid-C | FTP-S | Squid-S |
|---|---|---|---|---|
| 发送内容 | FTP 命令 | HTTP 请求 | FTP 回复 | HTTP 响应 |
| 发送者和接收者 | 客户端到 Squid | Squid 客户端侧到服务器侧 | 服务器到 Squid | Squid 服务器侧到客户端侧 |
| Squid 到服务器 | Squid 到客户端 |
FTP client <--> Squid Squid client-side <--> Squid server-side Squid <--> FTP server
------------------------------- ------------------------------------------ -------------------------------
USER anonymous@ftp.example.com
GET ftp://ftp.example.com/ HTTP/1.1
Host: ftp.example.com
FTP-Command: USER
FTP-Arguments: anonymous@ftp.example.com
USER anonymous@ftp.example.com
331 User name okay, need password.
HTTP/1.1 200 OK
Date: ...
Cache-Control: private
Content-Length: 0
FTP-Status: 331
FTP-Reason: User name okay, need password.
331 User name okay, need password.
...
RETR test.gz
GET ftp://ftp.example.com/ HTTP/1.1
Host: ftp.example.com
FTP-Command: RETR
FTP-Arguments: test.gz
RETR test.gz
150 File status okay; about to open data...
HTTP/1.1 100 Continue
Date: ...
Cache-Control: private
FTP-Status: 150
FTP-Reason: File status okay; about to open data...
150 File status okay; about to open data...
🔗 日志记录
单独的 FTP 事务（命令和回复）被记录为 HTTP 事务（缺少 HTTP 特定信息），并使用现有的访问日志功能。访问日志中应包含以下详细信息：
-
客户端 IP 地址
-
远程服务器名称和 IP 地址
-
远程用户名
-
客户端发送的 FTP 命令（包括参数）（密码已剥离，就像 Squid 剥离 URI 查询项一样）
-
服务器发送给 Squid 的 FTP 状态
-
Squid 发送给客户端的 FTP 状态
-
FTP 事务响应时间（从开始接收 FTP 命令到结束发送回复）
-
传输文件的大小
请注意，Squid 不会在 HTTP 包装消息中将 FTP 状态码映射到 HTTP 状态码，因此 FTP 和/或日志代码可能需要调整记录的值，以反映真实的 FTP 状态，而不是包装 HTTP 消息的 HTTP 状态。
🔗 未来增强功能
一个非常有用的但难以支持的功能是跟踪通过 CD 等命令的 FTP 当前目录或请求目录。 such tracking would allow simple access controls based on request URIs. 虽然基本的跟踪并不难支持，但 FTP 目录链接使得正确支持非常棘手（在某些情况下甚至不可能）：在 FTP 中，“foo/bar/..”路径（即一系列“CD foo”、“CD bar”和“CD ..”命令）可能导致当前位置与“foo”不同（即，“PWD”命令不会打印“foo”）。最终，Squid 可能会使用一种或多种算法来跟踪 URI，但此项目不包含此类支持或决定实现哪种 URI 跟踪算法。
类别：功能
导航：站点搜索，站点页面，类别，🔼 向上