Firefox WebTransport, UDP가 막히면 HTTP/2로 연결될까?

Firefox 158은 HTTP/2로 자동 전환하지 않는다

UDP가 막힌 네트워크를 고려해 WebTransport를 도입한다면, Firefox 158에서도 HTTP/2 대체 연결을 전제로 삼을 수 없다. Mozilla의 158 개발자 릴리스 노트는 HTTP/2를 통한 WebTransport를 아직 지원하지 않으며 WebTransport.supportsReliableOnly가 항상 false를 반환한다고 명시한다.

새로 생긴 것은 브라우저가 신뢰성 있는 전송만 제공하는 세션을 지원하는지 묻는 인터페이스다. 앱이 이미 별도의 대체 연결을 운영하고 있다면, 속성이 추가됐다는 이유만으로 그 경로를 제거해서는 안 된다.

속성이 있는지보다 어떤 값을 반환하는지 본다

supportsReliableOnly는 개별 연결이 아닌 WebTransport 클래스의 정적 속성이다. true이면 HTTP/2 같은 reliable-only 전송을 이용한 세션을 브라우저가 지원한다는 뜻이다. 현재 네트워크에서 특정 서버에 접속해 본 결과는 아니다.

다음 예는 API 없음, 새 속성 없음, 명시적 지원 여부를 구분한다. 서버에 연결하거나 방화벽을 시험하는 코드는 아니다.

if (typeof WebTransport === "undefined") {
  console.log("WebTransport unavailable");
} else if (!("supportsReliableOnly" in WebTransport)) {
  console.log("Reliable-only support cannot be queried here");
} else {
  console.log(WebTransport.supportsReliableOnly);
}

Firefox 158은 마지막 분기로 들어가 false를 반환한다. API 이름이 존재한다는 검사와 기능을 지원한다는 판정을 같은 것으로 처리하면 이 차이를 놓친다.

requireUnreliable: false는 HTTP/2를 켜는 스위치가 아니다

생성자 옵션인 requireUnreliable의 기본값은 false다. 이를 true로 지정하면 HTTP/3 연결이 불가능할 때 HTTP/2 연결로 진행할 수 없다. 앱이 비신뢰성 전송을 요구한다는 조건이다.

반대로 false는 그런 요구를 걸지 않는다는 뜻이다. 브라우저에 구현되지 않은 HTTP/2 전송을 추가하지는 않는다. HTTP/2 대체 연결을 구현한 환경에서도 WebTransport 명세가 요구하는 서버 지원과 연결 설정을 만족해야 한다. 일반 웹 페이지를 HTTP/2로 잘 불러온다는 사실만으로 WebTransport 세션까지 연결된다고 볼 수 없다.

연결된 뒤에는 reliability, 실패하면 앱의 대체 경로를 확인한다

실제 세션의 성격은 인스턴스의 reliability에서 읽는다. 브라우저의 능력을 묻는 정적 속성과 역할이 다르다.

ready Promise가 이행된 뒤 세션을 사용하고 상태를 읽는다. 연결이 실패하는 경우도 처리해야 하며, 실패 자체가 UDP 차단의 증거는 아니다.

앱의 대체 경로로 WebSocket 등을 쓴다면 클라이언트와 서버 양쪽에 그 경로가 구현돼 있어야 한다. WebTransport가 자동으로 앱의 다른 프로토콜에 접속해 주지는 않는다. Firefox 158을 대상으로 한 배포 판단은 속성의 존재 확인에서 끝내지 말고, 필요한 네트워크 환경에서 연결 성공과 앱의 실패 처리가 모두 동작하는지까지 이어져야 한다.