요약

  • PTTH는 전송 계층 클라이언트가 먼저 채널을 열고 프록시가 HTTP 요청을 보내게 한다.
  • 제안 헌장은 인증과 요청 권한을 핵심 과제로 둔다. 아웃바운드 연결만으로 전체 접근이 허용되지는 않는다.

백엔드가 먼저 연결한다. 그다음 프록시가 요청을 되돌려 보낸다.

Protocol for Transposed Transactions over HTTP, 즉 PTTH의 구상이다. 엄격한 방화벽 뒤의 작업 서버가 프록시로 아웃바운드 연결을 만들고, 프록시는 열린 채널로 HTTP 요청을 보낸다. 전송 계층의 클라이언트가 변환된 요청에서는 HTTP 서버 역할로 받는다.

작업 서버마다 인바운드 포트를 열거나 백엔드 주소를 고정하는 수고를 덜 수 있다. 하지만 어려운 결정은 한 홉 옮겨갈 뿐이다. 채널이 열린 뒤 프록시가 작업 서버에 무엇을 요청할 수 있는가?

IETF 작업반 헌장 초안은 외부 검토 중이며 2026년 11월 5일 IESG 회의 안건에 올라 있다. 11월 2일 현재 제안 단계이며 승인된 PTTH 표준은 없다.

2025년 7월 IETF 123에서는 방화벽 뒤 백엔드, CDN 확장, 요청 우선순위, 제로 트러스트 접속, HTTP를 다른 프로토콜의 기반으로 쓰는 방안이 논의됐다. 제한된 경로만 받는 CDN 작업 서버와 범용 터널은 같은 권한 설계가 아니다.

회의록은 권한 문제를 남겼다. 작업 서버가 프록시에 설정을 보내면 요청 라우팅에 영향력을 얻을 수 있다. 참석자들은 인증 방법, URL 공간 제한, HTTP와 다른 프로토콜의 기반 사이 경계를 물었다. 표결은 추가 논의를 지지했지만 도입 수요를 측정하거나 범위를 결정하지 않았다.

2026년 7월 IETF 126에서는 채널 수립, 요청 권한, 용량·제어를 구분했다. 앞의 두 가지는 초기 작업에 필요하고, 용량·제어는 배치마다 달라질 수 있다고 봤다. 작업 서버가 프록시 설정에 영향력을 갖는 문제도 다시 제기됐다.

제안 헌장은 요청 수신 의사 표시, 양쪽 인증, 허용할 요청의 정의, 라우팅 안내를 과제로 삼는다. 양쪽이 같은 연결에서 요청할 수 있는지는 미정이다. 새 신원 체계, 전송 프로토콜, 서버 검색, 용량 요청과 HTTP 의미 변경은 제외한다.

연결은 도달성을 만들지만 승인, 경로, 권한 철회까지 정하지 않는다. 공급자마다 규칙이 다르면 운영자는 조각난 호환성을 맞춰야 한다. 표준이 지나치게 넓어지면 편리한 통로가 신뢰 경계를 넘는 지름길이 될 수 있다.

검토할 것은 한 묶음이다. 인증된 작업 서버, 허용 요청 범위, 프록시 결정, 만료·철회 규칙, 확인할 수 있는 감사 기록. 이게 없으면 터널 작동은 전송의 증거일 뿐 권한의 증거가 아니다.

출처: IETF PTTH 제안 헌장; IETF 123 회의록; IETF 126 회의록; 개별 PTTH 초안.