当后端服务躲在防火墙和 NAT 之后，却又希望由统一的反向代理对外暴露时，传统 HTTP 的“客户端发起连接、服务器被动响应”模式就会变得笨拙。

PTTH（Protocol for Transposed Transactions over HTTP）是 IETF 正在推进的一种 HTTP 扩展协议。它的核心目标很简单：在一条已经建立的连接上，把 HTTP 请求的发送方向“转置”过来，让原本作为传输层客户端的一方，可以在 HTTP 层面充当服务器，接收来自另一方的请求。

为什么需要“转置”HTTP 请求方向

在经典 HTTP 架构中：

• 客户端（浏览器、App、上游服务）主动发起 TCP/TLS 连接
• 服务器监听固定端口，等待连接并处理请求
• 请求方向始终是：客户端 → 服务器

这在公网服务上工作良好，但在以下场景中会遇到问题：

• 后端服务位于企业内网、云 VPC 或容器网络中，不允许外部直接入站连接
• 需要由一个或少量反向代理统一对外暴露服务，实现零信任访问、统一鉴权和流量治理
• 后端实例动态伸缩、IP 不固定，无法预先配置稳定的入站规则
• 希望避免为“反向推送请求”而引入大量私有隧道、长轮询或 WebSocket 封装

目前业界通常用各种“反向 HTTP”“服务器推送”“长轮询”“WebSocket 隧道”等方案临时解决，但缺乏统一标准，互操作性和安全模型也不一致。

PTTH 试图在 HTTP 协议层提供一个标准化、可互操作、安全可控的机制，让“服务器主动向客户端发 HTTP 请求”变成一种原生能力，而不是 hack。

PTTH 的核心思想

PTTH 的设计可以用一句话概括：

让后端（backend / worker）主动连接到反向代理（proxy），在这条连接上建立一个“转置通道”，之后反向代理可以像普通 HTTP 客户端一样，在这个通道上向后端发送 HTTP 请求。

从角色上看：

• Proxy（反向代理）
• 传输层：服务器（监听端口，接受连接）
• HTTP 层：客户端（在转置通道上发请求）
• Worker（后端 / 源站）
• 传输层：客户端（主动发起连接）
• HTTP 层：服务器（在转置通道上收请求并响应）

PTTH 不改变底层传输（TCP/TLS/QUIC），也不重新发明一套应用协议，而是在现有 HTTP 之上增加一种“角色转置”的协商机制。

典型应用场景

1. 零信任网络访问（ZTNA）

企业内部服务不希望开放任何公网入站端口，只允许被少数可信反向代理访问。

• Worker（内网服务）主动连接到 ZTNA 网关
• 网关通过 PTTH 建立转置通道
• 外部用户请求先到达网关，再由网关通过 PTTH 转发给内网服务

这样，内网服务始终只保持出站连接，却可以对外提供标准 HTTP 服务。

2. CDN / 边缘回源

CDN 边缘节点需要动态从源站拉取内容，或下发控制指令，但源站位于受限网络。

• 源站主动连接到 CDN 控制面
• 控制面通过 PTTH 向源站发起“拉取内容”“刷新缓存”等 HTTP 请求
• 避免为每个源站配置复杂的入站规则

3. 动态容器与 Serverless

容器或函数实例短暂存在、IP 不固定，不适合被外部直接寻址。

• 实例启动后主动连接到控制平面
• 控制平面通过 PTTH 向实例分发请求
• 实例销毁时关闭连接，控制平面自动停止路由

4. 统一出口与集中治理

企业希望所有对外服务都经过少量统一反向代理，实现集中鉴权、审计、限流和 WAF。

• 各业务服务作为 Worker 主动连接到统一代理
• 代理通过 PTTH 将外部请求转发到对应服务
• 无需为每个服务配置独立入站策略

协议机制概览

以下以 HTTP/2 或 HTTP/3 为例，描述 PTTH 的高层流程（具体细节以 IETF 草案为准）：

1. Worker 主动连接 Proxy

Worker 作为传输层客户端，向反向代理发起 TCP/TLS 或 QUIC 连接。

2. 使用扩展 CONNECT / Upgrade 协商 PTTH

• HTTP/2、HTTP/3：发送 CONNECT 请求，在 :protocol 伪头部中标记 ptth
• HTTP/1.1：使用 Upgrade: ptth 机制
• 同时通过 ALPN 等协商转置通道上使用的 HTTP 版本

这一步相当于告诉 Proxy：“我希望在这条连接上建立一个 PTTH 转置通道。”

3. Proxy 认证并建立转置通道

Proxy 对 Worker 进行身份验证，可能包括：

• TLS 客户端证书
• HTTP 认证方案（如 OAuth、mTLS、自定义 token）
• 基于 URI 的访问控制策略

验证通过后，Proxy 将该连接标记为 PTTH 通道，并记录该 Worker 可以接收哪些路径或域名的请求。

4. 在转置通道上发送 HTTP 请求

建立完成后：

• Proxy 可以在这条连接上，像普通 HTTP 客户端一样，向 Worker 发送 HTTP 请求
• Worker 作为 HTTP 服务器处理请求并返回响应
• 上层协议（HTTP/2、HTTP/3 的各种扩展）仍然正常工作

从应用视角看，这就像 Proxy “反向调用”了 Worker 的 HTTP 接口，而无需 Worker 开放任何入站端口。

设计目标与约束

根据 IETF 草案，PTTH 的设计重点包括：

1.    基于 URI 的端点标识
      建立通道的请求使用特定 URI，该 URI 同时限定了 Proxy 可以转发哪些请求到该 Worker。
2. 复用现有 HTTP 安全模型
      认证、授权、加密都尽量使用现有 HTTP/TLS 机制，而不是另起一套。
3. 转置通道上跑“原生 HTTP”
      PTTH 只负责建立转置通道，通道之上仍然是标准 HTTP，不需要为上层协议做特殊改造。
4. 尽量减少额外开销
      避免多层封装，让转置通道尽可能直接使用底层传输，降低延迟和带宽成本。

​与现有“反向 HTTP”方案的区别

“让服务器向客户端发请求”的想法并不新鲜，过去有多种实验性方案：

• 使用 Upgrade: PTTH/0.9 等头部进行协议升级，把 socket“反过来用”
• 通过长轮询、WebSocket 或自定义隧道模拟“服务器主动推送请求”
• 厂商私有的反向代理 + 隧道方案

PTTH 的不同点在于：

• 在 IETF 标准化框架 内设计，目标成为正式的 HTTP 扩展，而非某个厂商的私有协议。
• 明确聚焦于 HTTP 语义和现有扩展的兼容性，强调与 HTTP/2、HTTP/3 的无缝集成。
• 强调 统一的安全模型和授权机制，避免每个系统各自定义一套复杂且不一致的规则。

此外，还有一些相关草案（如 “Potato – Reverse HTTP for origin servers”）从不同角度探索类似空间，PTTH 希望在这些探索中收敛出一个共识方案。

当前标准化进展（截至 2026 年中）

• PTTH 首次在 IETF 123 以 BoF（Birds-of-a-Feather）形式讨论，随后在 IETF 126（2026 年 7 月，维也纳）再次召开 BoF，评估是否成立正式工作组。
• 已有个人草案，如 draft-kazuho-ptth-ptth-01（2026 年 7 月更新），描述协议细节和用例。
• 已建立非工作组邮件列表 ptth@ietf.org 和相关讨论渠道，用于收集用例、实现反馈和协议改进建议。
• 截至 2026 年中，PTTH 仍处于 标准化前期，尚未成为正式 RFC。

风险与挑战

尽管 PTTH 的概念清晰，但落地仍面临一些现实问题：

1. 实现复杂度
      反向代理和后端框架都需要支持 PTTH 扩展，包括 CONNECT/Upgrade 协商、通道管理、鉴权集成等。
2. 安全边界重定义
      传统上“谁发起连接谁就是客户端”的直觉被打破，需要在运维、监控和审计工具中重新建模信任边界。
3. 与现有生态的兼容
      如何与现有 API 网关、服务网格、WAF、可观测性平台协同，需要时间磨合。
4. 用例收敛
      不同组织对“反向 HTTP”的需求差异很大，PTTH 需要在通用性和专用性之间找到平衡，避免变成“什么都能做但什么都不精”的协议。

一句话总结

PTTH 是一种拟标准化的 HTTP 扩展协议，通过在已有连接上“转置”请求方向，让位于防火墙后的后端服务可以安全、低开销地接受来自反向代理的 HTTP 请求，从而用统一标准替代当前多种私有的“反向 HTTP”方案。

阅读原文：点击这里