▲

QUIC 기반 미디어 전송 MoQ CDN, Cloudflare에서 첫 출시

 (moq.dev)
8P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Cloudflare가 최초로 Media over QUIC(MoQ) 기반 CDN을 공식적으로 공개함
  • MoQ는 실시간 미디어 전송을 위한 새로운 표준으로, WebRTC, HLS/DASH, RTMP/SRT를 대체할 것으로 기대됨
  • 현재는 개발자 프리뷰 단계이며, Cloudflare의 퍼블릭 엔드포인트를 통해 여러 클라이언트 및 라이브러리로 테스트 가능함
  • 실시간 방송 송출과 시청, AI 기반 자막 등의 시범 기능들이 웹 및 Rust 클라이언리에서 제공됨
  • 아직 인증, Safari 지원, ANNOUNCE 등 주요 기능이 미구현 상태이며, 관심 있는 개발자는 직접 모큐 릴레이를 운영할 수도 있음

Cloudflare, 최초의 MoQ CDN 공식 출시

소개

  • Cloudflare가 Media over QUIC(MoQ) 표준 기반 CDN을 공식 출시함에 따라, 실시간 미디어 전송 분야에서 대규모 변화를 예고함
  • MoQ는 실시간 동영상, 음성 등 라이브 미디어 데이터 전송에서 기존 WebRTC, HLS/DASH, RTMP/SRT 프로토콜을 모두 대체하는 차세대 표준으로 주목받음
  • 이번 출시는 공식 제품 형태로, 전 세계 Anycast 네트워크 상에서 실제 사용자가 직접 테스트 가능함
  • Cloudflare는 최초의 MoQ CDN 사업자가 되었으며, 해당 기술은 실시간 미디어 전송 생태계에 혁신을 촉진할 것으로 예상됨

현재 제공되는 기능

  • 본 기술은 프리뷰 버전으로, 서비스 안정성과 기능 범위가 제한적임
  • Cloudflare는 relay.cloudflare.mediaoverquic.com이라는 공개 엔드포인트를 개방함
  • 아래와 같은 다양한 오픈소스 라이브러리 및 클라이언트를 통해 테스트할 수 있음
  • 웹 데모와 라이브러리를 사용해 브라우저 내에서 실시간 방송 송출 및 시청이 가능함
  • AI 기반 자막 처리 기능 시범 적용
    • 브라우저 내에서 [silero-vad], [whisper], [transformers.js], [onnxruntime-web], [WebGPU] 등 기술로 자막 생성 및 전송
  • Web Component 방식 API뿐 아니라, JavaScript API를 통한 고급 활용도 지원됨
  • Rust 라이브러리를 통한 MP4 임포트, ffmpeg 연동, gstreamer 기반의 방송 송출 및 시청 등 자바스크립트 비선호층을 위한 환경도 마련됨

미구현된 기능

  • 현재 제공 버전은 제한적 Draft-07 서브셋만을 지원함
  • 아직 제공되지 않는 주요 기능
    • 방송 인증 미지원: 각 방송마다 추측이 어려운 이름을 직접 지정해야 함
    • ANNOUNCE 미지원: 방송 시작/종료 탐지 기능 부재
    • Safari 브라우저 미지원: WebTransport 지원 이슈로 Safari 호환 불가
    • 최적화 미완료: 사용자 경험 등은 점진적으로 개선 예정임
  • 필요시, 직접 moq-relay 인스턴스를 구축해 고급 기능을 활용할 수 있음
    • JWT 기반 인증, Safari/TCP를 위한 WebSocket fallback 등 추가 기능 개발 중
    • terraform 모듈로 글로벌한 CDN 네트워크 구성도 가능함

MoQ와 Cloudflare의 의미

  • MoQ 표준화 작업은 3년 이상 진행 중이며, 실제 전세계적 채택에 상당한 시간이 소요될 전망임
  • Cloudflare는 RFC 채택 전 실제 제품을 신속하게 출시함으로써, 개발자·이용자의 실질적인 피드백을 끌어내는 과감한 결정을 내림
  • MoQ 기술은 WebRTC/HLS/RTMP 등 기존 미디어 프로토콜을 대체하는 잠재력을 지님
  • 표준 초안 및 코드 이슈 논의는 계속되겠지만, 실제 운영 경험이 표준 발전에 크게 기여할 것으로 전망됨
  • 향후 MoQ 기반 미디어 전송 시장에서 Google, Akamai, Fastly 등도 자체 네트워크와 서버에 코드를 배포해 실질적 필요사항을 파악할 필요가 있음

향후 계획과 커뮤니티

  • 앞으로 WebRTC 및 기존 프로토콜을 Web 기반 최신 API로 재구현하기 위한 많은 작업이 남아 있음
  • 현재 단계의 성능/기능만으로 MoQ 전체를 평가하지 않아야 하며, 적극적으로 테스트 및 피드백 참여 필요함
  • 커뮤니티(Discord)에 900명 이상이 활동 중이며, 질문 및 협력 제안 가능함
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • https://moq.dev/publish/에서 데모를 테스트해봤는데 정말 부드러운 느낌임. 아주 인상적임. 그리고 훌륭한 기술에 고마움을 느낌. https://moq.dev/watch/?name=bbb에서 Big Buck Bunny 데모를 모바일폰으로 보니 수평 검은 줄이 많이 생기는 현상이 있음 (이상하게도 같은 와이파이를 사용하는 PC에서는 정상임). 이게 버퍼 크기 때문인지 궁금함. 클라이언트 쪽에서 버퍼를 늘릴 수 있는지, 아니면 서버 쪽 설정이어야 하는지 질문하고 싶음. 그리고 "글로벌" CDN맵에서 South Korea를 빼먹지 않아 고마움을 느낌

    • 혹시 이것이 Chrome에서만 작동하는지 궁금함. Android Firefox에서는 지원되는 브라우저가 아니라는 메시지만 보임

    • 수평 검은 줄 현상에 대해 잘 모르겠음. <canvas> 요소로 렌더링해서 소스 영상 사이즈에 맞게 리사이즈하고, 다시 CSS로 윈도우 크기에 맞게 리사이즈함

    • OnePlus Ten에서 Chrome으로 재생하면 검은 줄이 자주 깜빡임. 특히 화면 위쪽에서 오른쪽 아래로 내려가는 모양이고, 혹시 화면 새로고침(refresh) 아티팩트(rolling shutter effect) 현상일지도 모르겠음

    • 페이지에 Rust 코드와 WASM이 많이 언급되어 있으므로, 혹시 폰 CPU가 WASM을 충분히 빠르게 실행하지 못해서 생기는 문제일 수 있음. 내 Samsung S20에서는 검은 줄이 전혀 안 보임

    • mac book air m4와 600mbps 연결에서 테스트했는데 즉각적인 반응과 놀라움이 있었음

  • 이 글에는 '왜 신경 써야 하는가?'라는 섹션이 있지만, Media over QUIC이 미디어 발행자나 엔드 유저 — 즉 이 교환에서 가장 중요한 (아마도 유일한) 두 당사자 — 에 어떤 이득을 주는지 설명이 없음. 그래서 왜 내가 이 기술에 신경 써야 하는지 궁금함

    • 내 실수임. 이전 블로그 글들과 중복되는 내용을 피하려다 보니 설명이 부족했음: https://moq.dev/blog/replacing-webrtc/ 그리고 사실 MoQ는 주로 개발자들에게 이득을 주는 기술임. 확장성이나 기능 구현이 훨씬 쉬워지므로 간접적인 이득만 있음

    • 종단간(유리잔에서 유리잔으로) 지연 시간이 상당히 더 좋아짐. 주로 프로토콜이 이제 request/response 방식이 아니기 때문임

  • 안녕! Cloudflare MoQ 개발자임, 질문 환영함. 그리고 상 주셔서 감사함, kixelated xD

    • "헤드 오브 라인 블로킹 없음: TCP와 달리 QUIC의 스트림은 독립적임. 하나의 스트림(예: 오디오 트랙)에서 패킷이 손실되어도 다른 트랙(예: 비디오 트랙)은 막히지 않음. RTMP에서 항상 발생하던 끊김 현상이 이걸로 사라짐" 설명이 있었는데, 이런 구조라면 오디오 트랙에서 패킷 손실이 생겨도 비디오 트랙이 멈추지 않고 계속 재생된다면, 오디오와 비디오 싱크가 어긋날 수 있지 않을까 궁금함. 이 부분이 기술에 익숙하지 않아 이해가 부족할 수 있음

    • 질문이 있음. TCP와 QUIC의 goodput 격차를 줄이기 위한 구체적인 계획이 있는지 궁금함[1]. 연결된 논문에서는 HTTP/2(TCP)에서 HTTP/3(QUIC)로 넘어갈 때 최대 9.8%의 비디오 비트레이트 감소를 보았다고 함. 물론 MoQ는 스택 구조가 조금 다르기 때문에 직접적인 일반화는 어렵지만, 비슷한 문제가 있을 것 같음. (개인적으로 지난 몇 달 동안 MsQuic의 AF_XDP datapath를 석사 논문의 일환으로 조사함. 결론적으로는 GSO/GRO가 더 나은 대안이고, QUIC에는 하드웨어 오프로드가 확실히 더 필요하다는 걸 느낌 :p)
      [1]: https://arxiv.org/pdf/2310.09423

    • 몇 가지 궁금한 점이 있음 :)
      QUIC이 브라우저에서 실제로 사용 가능한 단계(브라우저와 인프라 모두 지원, '그냥 된다' 레벨)에 어느 정도 가까워졌는지 궁금함
      그리고 QUIC은 NAT 문제를 어떻게 해결하는지 궁금함. WebRTC는 full cone NAT를 통과하기 위해 STUN/TURN이 꼭 필요한데, 특히 TURN이 문제임. 인프라를 많이 돌려야 하니까

    • getstream.io에서 WebRTC 스트리밍 작업을 하고 있음. WebRTC는 설정이 다소 번거롭지만, 연결만 되면 낮은 지연 시간이 장점임. MoQ도 연결이 완료된 이후에는 어떤 장점이나 이슈가 있는지, 즉 WebRTC와 비교해서 어떻게 느끼는지 궁금함

    • 릴레이의 로드밸런싱이 MoQ의 범위에서 벗어나는지 궁금함. 글에서는 이 부분이 다뤄지지 않은 것 같음

  • 이 프로젝트를 너무 좋아하고, 가끔씩 kixelated 블로그도 읽고 Github에서 팔로우하고 있음.
    일단 이렇게 멋진 작업을 해준 kixelated와 Cloudflare 모두에게 축하를 전하고 싶음.
    실시간 라이브 스트리밍이 궁금함. 보통 라이브 스트리밍은 수백, 수천 명이 동시에 시청하는데, MoQ에서 멀티캐스트(multicast)를 사용하거나 구현할 생각이나 가능성이 있는지 알고 싶음. HTTP/1.1, HTTP/2에서는 TCP 기반이라 어려웠던 점이 있지만, HTTP/3에서 UDP를 쓰니 이제는 현실적인 아이디어라는 생각임. 생각이 어떠신지 궁금함. Akamai와 BBC에서도 이 부분 연구 중인 것으로 앎

    • 고마움!
      멀티캐스트가 필요 없음! CDN이 실제로는 멀티캐스트를 L7(애플리케이션 계층)에서 구현한 것이나 마찬가지임. 라우터나 ISP가 L3에서 이를 직접 구현해야 할 필요가 없음. 이게 바로 Twitch에서 5년간 내가 하던 일이었음
      이론상 멀티캐스트는 CDN 엣지에서 ISP로 가는 트래픽만 줄여주겠지만, 이건 1년에 한 번 있는 초대형 방송(예: Super Bowl)에서나 해당하고, 대다수 이벤트에는 효과가 없음. 많은 CDN들은 CDN 엣지를 이미 ISP 내부에 설치해서 이 문제를 해결했고, 작은 이벤트는 두 시청자가 동일한 경로를 공유할 확률이 낮아 이득이 없음
      멀티캐스트에는 혼잡 제어나 암호화 등 다른 이슈도 있는데, 이건 연합 구조의 멀티캐스트라 더 어려움
      멀티캐스트가 제일 혜택을 줄 곳은 P2P이지만, 거대한 CDN 생태계에서는 채택이 어려울 것 같음
      WebRTC도 멀티캐스트에 제일 잘 맞고 RTP(원래 멀티캐스트용 설계)도 쓰지만, 실제로 멀티캐스트 지원에 관심이 없는 상태임
      단, Google이 자사 네트워크 내 Meet 서비스에 멀티캐스트를 쓴다는 소문이 있으니 혹시 모르겠음

  • "just announced" 링크가 이게 뭔지 전혀 모르는 사람한테도 아주 좋음: https://blog.cloudflare.com/moq/ (나도 처음 놓침)

    • "방송 수준에서 초저지연 (sub-second latency at broadcast scale)" 하지만 실제 멀티캐스트는 없음

    • "그냥 또 다른 프로토콜이 아니라, 새로운 설계 철학임"이라는 문구가 나와서 AI 감지 레이더가 반응함

  • MOQ가 실패 복구(페일백) 해상도와 점진적 품질 저하(그레이스풀 디그레이데이션)를 어떻게 다루는지 궁금함. 그리고 zed에서 전체 화면으로 해도 화면이 꽉 차지 않는 문제도 있음

  • Firefox 사용자이며 Cloudflare가 호스팅하고 HTTP/3을 쓰는 사이트를 방문했다면 참고하라는 의미로 공유하고 싶음:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1979683

    • 해피 아이볼(happy eyeballs) 문제일 수 있을 것 같아 보임? 더 잘 아는 분들께 전달할 생각임

    • 혹시 브라우저 내 DNS over HTTPS(DoH) 해상기를 쓰고 있는지 알고 싶음. 나 개인적으로는 이 현상을 재현하지 못했음. 1.1.1.1로 DoH 사용하는 중임
      Chrome과 Firefox 모두 시스템 DNS 대신 DoH 해상기를 사용할 때 HTTP/3 사용이 더 일관적인 걸 느꼈음. 시스템 해상기를 쓸 때는 HTTPS DNS 레코드를 일관적으로(혹은 전혀) 못 가져오는 경우가 많고,
      HTTP/3 서버 지원은 HTTPS DNS 레코드 아니면 이전 HTTP/2/1.1의 캐시된 Alt-Svc 헤더 중 하나로 브라우저에 광고가 되어야 동작함. 이미 열려있는 연결을 재활용하는 경향이 있어 새 연결을 잘 안 띄움
      Alt-Svc 헤더도 특히 Firefox에서 일관적으로 캐시되지 않음
      상황을 더 복잡하게 만드는 건, 브라우저가(특히 Chrome) 접속 실패가 일정 수준 누적되면 아예 HTTP/3 지원을 꺼버림. 내가 대학 와이파이 쓸 때 UDP 트래픽을 많이(불규칙하게) 막아서 그런 현상이 있었고, 그 후 집에서도 HTTP/3이 안 됨. 해결법은 chrome://flags에 가서 QUIC 지원을 수동으로 켜는 것 뿐임. 기본적으로 "enabled by default"로 보이더라도 실제 브라우저 상태는 다를 수 있음. Firefox도 유사하게 HTTP/3을 포기하지만, Chrome만큼 고집스럽지 않고 큰 문제는 없었음
      추가 디버깅을 원한다면 EncryptedClientHello(ECH)가 작동하는지 https://tls-ech.dev에서 확인해볼 것, 이건 ECH 키만을 위해 HTTPS 레코드만 사용하니 문제 격리가 됨.
      다음으론 Fastly의 HTTP/3 체크(https://http3.is)로 Alt-Svc 협상만 쓰는지 확인할 수 있음.
      Cloudflare 테스트 페이지(https://cloudflare-quic.com)는 HTTPS DNS 레코드와 Alt-Svc를 둘 다 쓰므로 바로 HTTP/3이 잡히면 HTTPS 레코드 해석이 잘 되는 것임
      테스트 결과 알려주시면 좋겠음. Firefox의 문제가 모두에게서 일관적이지 않은 건 이렇게 다양한 변수가 있어서임
      (Cloudflare 관계자에게 알리고 싶은 건, https://cloudflare-quic.com/favicon.ico가 뭔가 잘못 구성되어 있음. 그리고 https://www.cl...">https://web.archive.org/web/20230424015350im_/… 이미지를 Wayback Machine에서 불러와 페이지 로드에 지연이 생기는데, images는 "id_" 링크를 써야 rewrite가 안 돼서 더 빠름. 예전에 Cloudflare Workers와 연계해서 서버 마이그레이션 실패 때 사이트를 임시로 복구시킬 수 있었음. 또는, 그냥 https://www.cloudflare.com/img/nav/globe-lang-select-dark.svg 원본을 쓰면 됨. 현재 사이트에서도 여전히 살아있는 파일임)
      최근 몇 년간 HTTP/3의 다양한 특이한 구현 및 배포 이슈를 가지고 실험을 엄청 많이 해봤음. 훌륭한 프로토콜임. 하지만 이상하고 특이한 구현 및 배포 이슈가 많음

    • 혹시 macOS 한정인지 궁금. Windows의 FF 141, 142에선 재현이 안 됨

  • 정말 멋짐! 수고에 감탄함. 처음에는 QUIC CDN으로 읽고 "설마" 싶었는데, Media over QUIC이 별개의 개념이라는 걸 자세히 알아보니 꽤 흥미로움

  • 첫 번째 앱이 흥미로웠음. Show HN에 제출해보면 좋겠다는 생각임. 라이브 비디오 플랫폼에서 일한 경험이 있는데, MoQ가 다시 한번 이 개발을 하고 싶을 정도로 충분히 흥미로움

    • 곧 제출할 예정임. 하지만 조금 더 고칠 부분을 손볼 시간도 필요함

  • "기술이 내부적으로 동작한다면" 주요 브라우저 지원만 되면 무관하다고 생각함 (caniuse에 정보도 안 보임).
    그리고 Microsoft Edge WebView2 같은 웹뷰 엔진도 지원된다면 바로 개발 적용이 가능하다고 느낌.
    하지만 반대로 OBS나 YouTube 같은 쪽에서 지원을 해야 실제로 의미가 있을 것 같음

    • 그래서... MoQ는 WebRTC 같은 하나의 큰 "블랙박스" 웹 API로부터 약간 벗어나는 노선을 걷고 있음. 브라우저 관점에선 WebTransport API 지원이 관건임.
      WebTransport와 함께 MoQT를 쓰면, 예를 들어 영상 플레이어로 WebCodecs 같이 새로운 여러 방식이 생김. 약간의 지연을 감수하면 MSE로 재생하면서 DRM도 적용할 수 있음
      그리고 OBS에서 직접 퍼블리시할 수 있게 하는 작업은 Cloudflare 오기 전에도 했었는데, 이는 "스트리밍 포맷" 계층에서 미디어 관련 세부 구현을 어떻게 하느냐에 상당히 달려 있음. 업계에는 아직 이 계층의 사양이 꾸준히 발전 중인데, 현재 WARP가 주도적인 스펙임. WARP 규격이 점점 정착되는 대로 OBS 등에도 이 기능이 내장될 수 있음. 현재도 Norsk(https://norsk.video/)를 통해 fMP4 기반 예비 포맷으로 영상 퍼블리시가 가능함
      YouTube의 경우 구글이 MoQT에 적극적으로 기여하는 인력이 있지만, 이걸 YouTube 제품에 언제, 어떤 방식으로 적용할지는 내 판단으론 확신할 수 없음

    • https://caniuse.com/webtransport
      https://caniuse.com/webcodecs
      실제로 WebCodecs가 필수는 아니고, MSE로 렌더링할 수도 있지만 더 까다롭고 지연도 길어짐.
      Safari 지원을 위해 WebSocket 폴백과 WASM 기반 OPUS 인코더 작업 중임

답변달기