요약

  • Mark Nottingham은 QUIC 위의 HTTP 의미 체계 매핑을 QUIC의 전송 역할과 구별되는 하나의 HTTP 프로토콜로 인식할 수 있도록 하기 위해 “HTTP/3”라는 명칭을 제안했습니다.
  • 그는 이 명칭 제안과 함께 거버넌스 제안을 결합했습니다. 즉, 출판 이후 HTTP/3와 QPACK의 유지보수는 HTTP 워킹그룹으로 넘어가야 한다는 것이었습니다. 이후 IETF 기록이 그 할당을 문서화하고 있습니다.
  • 이 경계는 책임 소재를 명확히 한 것입니다. 그러나 그렇다고 명칭이 기술적 보장이 되거나, 워킹그룹 논의가 Nottingham 개인의 결정으로 바뀌거나, 구현체가 프로토콜을 채택했음이 입증된 것은 아닙니다.

2018년 말 무렵, 하나의 라벨이 서로 다른 두 가지 개념을 담고 있었습니다. “QUIC”은 전송 프로토콜을 가리킬 수도 있고, 그 전송 위에서 만들어지고 있는 HTTP 매핑을 가리킬 수도 있었습니다. 작업을 면밀히 따라가지 않던 엔지니어들은 때때로 이 둘을 동일한 산출물로 여겼습니다. 이 혼란은 단순한 명명 문제 그 이상이었습니다. 어느 그룹이 전송 동작을 정의하고 어느 그룹이 HTTP의 미래를 소유해야 하는지를 흐리게 만들었기 때문입니다.

Mark Nottingham은 2018년 10월 QUIC 워킹그룹에 보낸 메시지에서, 그룹의 HTTP 문서를 “HTTP/3”로 부르고 최종 ALPN 식별자로h3를 사용하자고 제안했습니다. 그는 이 문서를 HTTP/2처럼 HTTP 의미 체계를 유선 프로토콜에 결합하는 또 하나의 바인딩으로 설명하며, 이 명칭이 QUIC과 분리된 것임을 사람들이 보게 도와줄 것이라고 말했습니다. 이 제안은 그의 메시지에 그대로 보존되어 있으며, 후대의 재구성이 아닙니다.

그는 첫 번째 제안에 두 번째 제안을 붙였습니다. QUIC 그룹이 매핑을 출판한 후에는 HTTP/3와 QPACK의 유지보수가 HTTP 워킹그룹으로 이동해야 한다는 것이었습니다. 이 구분은 중요합니다. 어떤 문서는 다른 그룹의 전송 작업에 의존하기 때문에 그 그룹에서 초안을 작성할 수 있지만, 장기적 결정은 애플리케이션 프로토콜을 책임지는 그룹이 내려야 할 수 있습니다. 문서의 이름을 붙이는 것과 유지보수를 배정하는 것은 연결되어 있었지만, 동일한 결정은 아니었습니다.

현장은 지지와 권한을 구분했습니다

IETF 103에서 QUIC 그룹은 이 명칭을 논의했습니다. 회의록에는 반대 의견과 상충하는 직관들이 기록되어 있습니다. 일부 참가자는 HTTP/3를 HTTP/2의 후속으로 보았고, 다른 이들은 새로운 명칭이 포크를 암시하는 것 아니냐고 의문을 제기했습니다. Nottingham은 HTTP/2가 HTTP/1.1을 폐기(deprecate)하지도 더 이상 사용하지 않게(obsolete) 하지도 않았으며, 중요한 구분은 HTTP 의미 체계와 그 아래의 유선 프로토콜 사이에 있다는 점을 지적했습니다.

기록에 남은 것은 구속력 있는 투표가 아니라 비공식 손 들기 또는 “hum”입니다. 명칭 변경 지지는 대략 70:30이었고, HTTPbis에 이 결정을 맡기자는 지지는 만장일치에 가까웠습니다. 두 번째 결과가 더 시사적입니다. 교차 계층 프로토콜이 QUIC 작업에서 등장했지만, 명명 권한은 HTTP 커뮤니티에 있었습니다. Nottingham의 짧은 개입은 이 문제를 QUIC 그룹이 HTTP 정체성의 상설 중재자가 되도록 두지 않고, HTTP를 유지보수하는 그룹에 붙잡아 두었습니다.

그는 이미 메일링 리스트 메시지에서 자신의 역할에 한계를 두었습니다. “Chair hat(의장 자격)” 표기 아래에서 그는 방콕에서 짧은 논의를 요청하고, 끝없는 명명 경쟁에는 반대했습니다. 그의 이유는 실용적이었습니다. 개발자와 사용자는 작업에 대한 명확한 설명이 필요했고, 그룹은 아직 완성해야 할 기술적 마일스톤을 갖고 있었습니다. 의장은 질문을 프레이밍하고 그를 위한 시간을 보호할 수 있었지만, 그 프레이밍을 합의로 대체할 수는 없었습니다.

명칭은 계층이 계속 보일 때만 유용합니다

최종 사양은 이 구분을 구체화합니다. RFC 9114는 HTTP/3를 QUIC 위의 HTTP 의미 체계 매핑으로 기술합니다. RFC 9110은 HTTP 의미 체계를 정의하고, RFC 9000은 QUIC을 전송으로 정의합니다. HTTP/3는 전송의 스트림별 신뢰성 있는 순차 전달과 보안 속성을 사용하면서 HTTP의 메시지 및 애플리케이션 의미를 유지합니다. 이 명칭은 매핑을 식별하지만, 계층을 무너뜨리지는 않습니다.

h3ALPN 토큰은 공개 명칭과 관련되어 있지만 상호 교환 가능하지는 않습니다. 이는 프로토콜 협상에서 선택되는 유선 식별자입니다. 공개 명칭은 사람들이 사양과 작업을 분류하는 데 도움을 줍니다. Nottingham의 이메일은 이 두 기능을 명시적으로 구분하며, 출판 전까지 이 명칭이 공식화되거나 유선에서 사용되지 않을 것이라고 말했습니다. 이는 식별자가 호환성 기대를 형성하기 전에 제안을 수정할 여지를 남겼습니다.

거버넌스 이관은 슬로건으로 남지 않았습니다. 2018년 HTTPbis 헌장은 QUIC이 HTTP/3를 출판하면 HTTPbis가 필요에 따라 QPACK을 포함한 확장을 유지보수하고 개발할 것이라고 명시했습니다. 현재 HTTP 헌장은 HTTP/3와 QPACK을 핵심 HTTP 사양 중으로 나열합니다. 현재 QUIC 헌장은 자신의 그룹이 이 매핑과 QPACK을 최초로 만들었으며 이 사양들이 현재 HTTP 워킹그룹에서 유지보수된다고 밝힙니다. 이 사례에서 제안된 경계는 그룹들의 문서화된 권한 범위의 일부가 되었습니다.

그렇다고 해서 이 경계가 벽이 되는 것은 아닙니다. QUIC 워킹그룹은 여전히 HTTP/3 qlog 이벤트 정의 작업을 나열하고 있는데, 여기서 관측 가능성은 전송과 애플리케이션 계층을 가로지릅니다. 더 정확한 구분은 HTTP의 핵심 매핑을 유지보수하는 일과, 근거나 메커니즘이 QUIC 경계에 있는 작업을 처리하는 일 사이에 있습니다. 조율이 여전히 필요한 이유는 바로 계층들이 실제 운영되는 시스템 안에서 만나기 때문입니다.

출판에는 여전히 운영 주체가 필요합니다

프로토콜을 HTTP/3라고 부른다고 해서 클라이언트가 이를 제공하거나, 서버가 수락하거나, 네트워크 경로가 성공적으로 전달하는 것은 아닙니다. RFC 출판과 등록된 ALPN 값은 공통 참조 지점을 확립합니다. 구현체는 여전히 협상하고, 상호 운용하고, 폴백을 처리하고, 자체 배포 결정을 내려야 합니다. 명칭은 범주 오류를 줄일 수 있지만, 채택이나 성능을 보고할 수는 없습니다.

이 한계는 동시에 이 제안의 가장 강력한 설계 선택이기도 합니다. 공통 사양은 HTTP 메시지가 무엇을 의미하고 QUIC 위에 어떻게 매핑되는지를 말할 수 있습니다. 전송 사양은 전달, 혼잡 제어, 전송 보안을 정의할 수 있습니다. 워킹그룹 헌장은 지속적인 유지보수 위치를 배정할 수 있습니다. 그리고 운영자와 구현자는 이 사양들을 배포할지, 어떻게 배포할지 결정합니다. 각 기록은 서로 다른 질문에 답합니다.

Nottingham의 기여는 그가 개인적으로 HTTP/3의 명칭을 붙이거나 이전했다는 것이 아닙니다. 그는 공개 라벨을 미래 책임의 위치에 연결한 뒤, 명칭은 HTTP 커뮤니티가 결정해야 한다고 주장했습니다. 그룹들의 회의록과 헌장은 그 결정들이 어떻게 처리되었는지 보여줍니다. 그 결과는 표준 작업에 유용한 시험 기준이 됩니다. 어떤 제안이 새로운 바인딩을 도입할 때, 독자들은 무엇이 공유되고 무엇이 새로운지, 누가 각 부분을 유지보수하는지, 구현이 입증해야 할 것이 무엇인지 알 수 있습니까?

출처