摘要

  • PTTH 让传输层客户端先开通道，代理随后可沿通道向工作节点发送 HTTP 请求。
  • 拟议章程把认证和请求授权列为核心工作；出站连接本身不等于无限访问。

后端先拨出连接，代理再把请求送回来。

这就是 HTTP 转置事务协议（PTTH）的承诺：严格防火墙后的工作节点主动向代理建立出站连接，代理随后沿通道发送 HTTP 请求。传输层的客户端在转置事务中接收请求，扮演 HTTP 服务器。

这样或许不必给每个工作节点开入站端口，也不必固定每个后端地址。但困难的决定只是移动了一跳：通道接通后，代理可以要求工作节点做什么？

IETF 正在外部审议一份拟议工作组章程，议程日期为 2026 年 11 月 5 日。到 11 月 2 日，它仍是提案；IETF 尚未批准章程，也没有发布 PTTH 标准。

2025 年 7 月的 IETF 123 讨论了防火墙后的后端、CDN 动态扩容、请求优先级、零信任访问，以及用 HTTP 承载其他流量。这些不是同一类需求。CDN 节点只接收限定路径的请求，与通用隧道有不同的权限边界。

会议纪要记录了权力问题：如果工作节点能向代理推送配置，它就可能影响请求路由。参会者追问如何认证、能否只开放一部分 URL 空间，以及 HTTP 被用作其他协议底座时还剩多少 HTTP 工作。现场投票支持继续讨论，但没有测量部署需求，也没有确定范围。

2026 年 7 月的 IETF 126 把工作拆为建立连接、授权请求、管理容量与控制。前两项被视为初期工作所必需，容量与控制则更依赖具体部署。工作节点影响代理设置所带来的权限变化，再次引发讨论。

拟议章程明确纳入请求授权：如何声明愿意收请求、如何认证双方、工作节点获准接收哪些请求，以及路由如何获得指引。双方能否在同一连接上互发请求仍未决定。新身份系统、传输协议、服务器发现、容量请求和 HTTP 语义更改均不在范围内。

这些边界决定通道会止步于传输，还是长成控制面。连通性不会自动解决接入、路由或撤权。供应商各自保留规则，运营方就得拼接互通；标准若包揽太多，一条便利通道也可能越过原本分开的信任边界。

应审查完整的一组关系：已认证的工作节点、获准请求范围、代理决定、到期或撤权规则，以及可观察的审计记录。缺少这些，隧道可用只能证明传输成立，不能证明授权成立。

来源：IETF PTTH 拟议章程；IETF 123 会议纪要；IETF 126 会议纪要；PTTH 独立草案。