요약

  • RFC 3340은 살아 있는 BEEP 채널에 묶인 트랜잭션 식별자와, APEX 서비스 데이터 안에 내장되어 요청 애플리케이션이 떠난 뒤에도 의미를 유지할 수 있는 식별자를 구분했습니다.
  • 두 번째 애플리케이션이 같은 엔드포인트로 연결(attach)하여 첫 애플리케이션의 응답을 받을 수 있었습니다. 엔드포인트 이름과 트랜잭션 식별자는 기록을 연관 지어 주었지만, 요청 소유권, 지속되는 의도, 행동 권한을 증명하지는 못했습니다.

이 불편한 문장은 회고적 비평이 아니라 RFC 3340의 6.1.1절에 등장합니다. 한 애플리케이션이 APEX 엔드포인트로 연결하고, 트랜잭션 식별자를 내장한 채 서비스에 데이터를 보낸 뒤, 나중에 연결을 해제(detach)할 수 있습니다. 두 번째 애플리케이션이 그와 같은 엔드포인트로 연결하여 자신의 요청을 보낼 수 있습니다. 그리고 나서 그 애플리케이션은 첫 애플리케이션의 요청에 대한 응답을, 첫 애플리케이션의 식별자를 그대로 지닌 채 서비스로부터 받을 수 있습니다.

이 작은 시나리오에는 완전한 승계 문제가 담겨 있습니다. 엔드포인트는 라우팅 가능한 이름으로서 남아 있습니다. BEEP 연결은 그렇지 않습니다. 첫 번째 프로세스는 사라졌습니다. 서비스에는 여전히 진행 중인 작업이나 응답이 있습니다. 대체 프로세스가 엔드포인트를 획득하고 도달 가능해집니다. 답이 도착하면 그것은 이전 요청과 정확히 연관 지어지고 현재 연결에 정확히 전달되지만, 어느 사실도 현재 프로세스가 이전 요청을 소유한다는 것을 입증하지 못합니다.

두 종류의 수명

APEX는 BEEP(Blocks Extensible Exchange Protocol) 위에서 동작했습니다. RFC 3340은 두 가지 범위를 구분합니다. 엔드포인트–릴레이 및 릴레이–릴레이 교환에서 트랜잭션 식별자는 BEEP 채널의 수명 동안에만 의미를 가집니다. 연결(attach) 작업이 이 규칙을 보여줍니다. BEEP 연결을 해제하면 채널은 존재하지 않게 되고, 애플리케이션은 더 이상 릴레이 메시에 연결되어 있지 않습니다.

서비스 트래픽은 달랐습니다. 그 식별자는 메시를 통해 전달되는data안에 내장될 수 있었습니다. 따라서 그 식별자는 “잠재적으로 수명이 길(potentially long-lived)” 수 있었습니다. 채널 범위의 연관관계를 끝내는 바로 그 경계를 넘을 수 있었던 것입니다. RFC는 모호성을 줄이기 위해 예측하기 어려운 값을 권장합니다. 이는 합리적인 상관관계 보호 장치입니다. 그러나 신원 시스템은 아닙니다. 추측하기 어려운 값은 어떤 프로세스가 그 값을 생성했는지, 어느 연결 세대가 권한을 유지하는지, 원래 요청이 취소되었는지, 후속 주체가 그 답을 적용해야 하는지를 말해 주지 않습니다.

이 구분이 중요한 이유는 엔드포인트 이름이 흔히 계속 존재하는 주체를 지칭하는 것처럼 다뤄지기 때문입니다. RFC 3340의 엔드포인트는 대신 애플리케이션이 연결될 수 있는 장소를 지칭했습니다. 그 뒤의 주체가 바뀌는 동안 이름은 안정적으로 남을 수 있었습니다. 그 장소로 보내진 응답은 따라서 올바르게 라우팅되어도, 되돌릴 수 없는 결정을 위해 잘못된 세대의 주체에게 도달할 수 있었습니다.

이른ok

데이터 경로에는 또 하나의 한정된 수신 확인이 있습니다. 4.4.4.1절에 따르면 릴레이는 먼저 자신의 BEEP 클라이언트가 명시된 발신자를 대신해 보낼 권한이 있는지 확인하고 데이터별 옵션을 처리합니다. 그런 다음ok를 반환합니다. 그 이후에야 발신자별 옵션과 각 수신자를 처리합니다.

다른 행정 도메인에 있는 수신자의 경우, 성공적인 처리란 해당 도메인의 릴레이로 세션이 수립되고 새 데이터가 전송되었으며 그 다음 릴레이가ok를 반환했음을 의미합니다. 로컬 수신자의 경우, 접근 서비스가 통신을 허용해야 하고 엔드포인트가 연결되어 있어야 하며, 애플리케이션이 애플리케이션별 처리를 마친 뒤ok를 반환해야 합니다. 이들은 의도적으로 서로 다른 확인 지점입니다. 첫 릴레이의 수락은 서비스의 최종 답이 아니며, 수신자 애플리케이션의 프로토콜 확인조차 비즈니스 동작이 성공했다는 증거가 아닙니다.

APEX는 그것이 같은 증거인 것처럼 꾸미지 않으면서 더 많은 증거를 제공했습니다.statusRequest옵션은 해당되는 각 릴레이가 나중에 보고 서비스(report service)를 통해statusResponse를 보내게 했습니다.targetHop이all로 설정되면 발신자는 메시를 통한 전달 경로를 추적할 수 있었습니다. 이 추적은 관찰의 연쇄였지, 초기ok의 확장이 아니었습니다. 여기에는 비용도 있었습니다. 관련 타이밍 옵션은 사설 토폴로지를 노출할 수 있었고, RFC 3342는 관리자가 행정 인그레스와 이그레스 외에는 이를 비활성화할 수 있다고 조언했습니다.

경계에서 멈춘 신원

이 아키텍처는 DNS SRV로 릴레이를 찾았습니다. 따라서 RFC 3340은 릴레이 무결성이 DNS와 DNS를 사용하는 애플리케이션에 의존하며, BEEP 개시자가 수신자(listener)에게 자신을 인증하도록 요구할 때 추가 보증이 얻어진다고 말했습니다. BEEP 피어 인증은 엔드포인트로 연결하거나 릴레이할 권한 부여를 지원할 수 있었습니다. 콘텐츠의 종단 간 인증이 필요하다면, 그것은 홉 단위 보호를 신뢰하는 대신 콘텐츠 자체에 서명하는 일에 속했습니다.

이러한 통제는 중요하지만 한정된 질문에 답합니다. 어느 수신자에 도달했는지, 어느 피어가 인증되었는지, 그 피어가 엔드포인트를 대신해 발신할 수 있었는지, 콘텐츠가 변경되지 않았는지. 이 통제들은 엔드포인트를 하나의 프로세스로 축소하지 않습니다. 내장된 트랜잭션 식별자를 하나의 워크로드 세대에 결합하지도 않습니다. 서명된 오래된 응답은 서비스가 무엇을 보냈는지에 대한 훌륭한 증거일 수 있으며, 여전히 내구성 있는 소유권 기록 없이 새로 연결된 프로세스가 그것을 실행하기에는 안전하지 않을 수 있습니다.

따라서 최소한으로 유용한 장부에는 엔드포인트와 트랜잭션 식별자 이상이 필요합니다. 인증된 피어, 채널과 연결 세대; 프로세스 또는 워크로드 신원; 요청의 해시; 서비스 목적지와 내구성 있는 수신 확인; 릴레이 확인 응답과 상태 보고; 해제(detach) 이벤트; 후속 주체의 연결(attach) 이벤트; 응답의 해시; 그리고 그것을 소비할지, 격리할지, 폐기할지에 대한 정책 결정이 필요합니다. 멱등성 상태와 관찰된 애플리케이션 결과는 그 결정 이후에 기록되어야 하며, 식별자 안에 있어서는 안 됩니다.

설계가 역사가 되다

RFC 3340은 2002년 7월에 Standards Track에 올랐습니다. 핵심, 접근 서비스, 옵션 컬렉션, 프레즌스 서비스에 해당하는 RFC 3340부터 3343까지의 네 편의 APEX 문서 중 하나였습니다. 10년 뒤 IETF의 Datatracker는 이 네 문서가 모두 Historic 상태로 이동한 이유를 기록했습니다. IETF가 아는 한 배포된 구현은 없었고, 그 기능은 광범위하게 배포된 XMPP(RFC 6120 및 RFC 6121로 대표됨)가 제공하고 있었습니다.

이 기록은 정확하게 읽어야 합니다. 그것은 IETF의 지식으로 한정된 비배포 진술과 XMPP의 배포와의 비교를 뒷받침할 뿐입니다. 수명이 긴 식별자 메커니즘이 APEX의 운명을 낳았다는 것을 증명하지 않습니다. Historic 상태가 이 수명 주기 사례를 낡게 만들지도 않습니다. 오히려 이 사례가 살아남는 이유는 작업 큐, 콜백, 오케스트레이션 시스템, 서비스 신원이 공유하는 문제, 즉 안정적인 주소가 교체를 숨길 수 있다는 문제를 이름으로 지적하기 때문입니다.

올바른 결론은 늦게 도착하는 응답이 무효하다는 것이 아닙니다. 그 유효성에는 여러 차원이 있다는 것입니다. 바이트는 예상한 서비스에서 왔을 수 있습니다. 식별자는 오래된 요청과 일치할 수 있습니다. 엔드포인트는 정확할 수 있습니다. 그럼에도 수신 프로세스는 소유권이나 현재 권한이 없을 수 있습니다. 안전한 소비자는 편리한 상관관계 키가 그 모든 것을 대변하도록 내버려두는 대신, 이러한 수신 확인들을 결합해야 합니다.

출처