- Cloudflare đã chính thức công bố CDN dựa trên Media over QUIC(MoQ) đầu tiên
- MoQ là một tiêu chuẩn mới cho truyền tải media thời gian thực, được kỳ vọng sẽ thay thế WebRTC, HLS/DASH, RTMP/SRT
- Hiện đang ở giai đoạn developer preview, có thể thử nghiệm với nhiều client và thư viện thông qua endpoint công khai của Cloudflare
- Các tính năng thử nghiệm như phát và xem livestream thời gian thực, phụ đề dựa trên AI được cung cấp trên web và trong client Rust
- Một số tính năng quan trọng như xác thực, hỗ trợ Safari, ANNOUNCE vẫn chưa được triển khai; các nhà phát triển quan tâm cũng có thể tự vận hành moq relay
Cloudflare chính thức ra mắt MoQ CDN đầu tiên
Giới thiệu
- Cloudflare đã chính thức ra mắt CDN dựa trên tiêu chuẩn Media over QUIC(MoQ), báo hiệu một thay đổi lớn trong lĩnh vực truyền tải media thời gian thực
- MoQ đang được chú ý như một tiêu chuẩn thế hệ tiếp theo có thể thay thế toàn bộ các giao thức hiện có như WebRTC, HLS/DASH, RTMP/SRT trong việc truyền dữ liệu media trực tiếp như video và âm thanh thời gian thực
- Lần ra mắt này có dạng một sản phẩm chính thức, cho phép người dùng thực tế trực tiếp thử nghiệm trên mạng Anycast toàn cầu
- Cloudflare đã trở thành nhà cung cấp MoQ CDN đầu tiên, và công nghệ này được kỳ vọng sẽ thúc đẩy đổi mới trong hệ sinh thái truyền tải media thời gian thực
Các tính năng hiện có
- Công nghệ này hiện là bản preview, nên độ ổn định dịch vụ và phạm vi tính năng còn hạn chế
- Cloudflare đã mở endpoint công khai
relay.cloudflare.mediaoverquic.com - Có thể thử nghiệm thông qua nhiều thư viện và client mã nguồn mở như sau
- Có thể phát và xem livestream thời gian thực ngay trong trình duyệt bằng web demo và thư viện
- Ứng dụng thử nghiệm tính năng xử lý phụ đề dựa trên AI
- Tạo và truyền phụ đề ngay trong trình duyệt bằng các công nghệ như [silero-vad], [whisper], [transformers.js], [onnxruntime-web], [WebGPU]
- Không chỉ hỗ trợ API theo kiểu Web Component mà còn hỗ trợ sử dụng nâng cao qua JavaScript API
- Cũng đã chuẩn bị môi trường cho những người không ưu tiên JavaScript, như import MP4 qua thư viện Rust, tích hợp ffmpeg, phát và xem luồng dựa trên gstreamer
Các tính năng chưa được triển khai
- Phiên bản hiện tại chỉ hỗ trợ một tập con Draft-07 giới hạn
- Các tính năng quan trọng hiện vẫn chưa có
- Chưa hỗ trợ xác thực luồng phát: phải tự chỉ định tên khó đoán cho từng luồng
- Chưa hỗ trợ ANNOUNCE: thiếu khả năng phát hiện bắt đầu/kết thúc luồng
- Chưa hỗ trợ trình duyệt Safari: không tương thích do vấn đề hỗ trợ WebTransport
- Chưa tối ưu hoàn chỉnh: trải nghiệm người dùng và các phần khác sẽ được cải thiện dần
- Khi cần, có thể tự triển khai instance moq-relay để dùng các tính năng nâng cao
- Đang phát triển thêm các tính năng như xác thực dựa trên JWT, WebSocket fallback cho Safari/TCP
- Cũng có thể xây dựng mạng CDN toàn cầu bằng module terraform
Ý nghĩa của MoQ và Cloudflare
- Công việc tiêu chuẩn hóa MoQ đã diễn ra hơn 3 năm, và sẽ còn cần khá nhiều thời gian để được chấp nhận rộng rãi trên toàn cầu
- Cloudflare đã đưa ra một quyết định táo bạo khi nhanh chóng phát hành sản phẩm thực tế trước khi RFC được thông qua, nhằm thu hút phản hồi thực tiễn từ nhà phát triển và người dùng
- Công nghệ MoQ có tiềm năng thay thế các giao thức media hiện có như WebRTC/HLS/RTMP
- Việc thảo luận về bản thảo tiêu chuẩn và các issue trong mã nguồn sẽ vẫn tiếp tục, nhưng kinh nghiệm vận hành thực tế được kỳ vọng sẽ đóng góp lớn cho sự phát triển của tiêu chuẩn
- Trong tương lai, Google, Akamai, Fastly và các bên khác trong thị trường truyền tải media dựa trên MoQ cũng sẽ cần triển khai mã lên mạng và máy chủ riêng để xác định các nhu cầu thực tế
Kế hoạch tiếp theo và cộng đồng
- Vẫn còn rất nhiều việc phải làm để tái hiện thực WebRTC và các giao thức cũ bằng các API hiện đại trên nền web
- Không nên đánh giá toàn bộ MoQ chỉ dựa trên hiệu năng/tính năng ở giai đoạn hiện tại; cần tích cực tham gia thử nghiệm và phản hồi
- Hiện có hơn 900 người đang hoạt động trong cộng đồng (Discord), nơi có thể đặt câu hỏi và đề xuất hợp tác
1 bình luận
Ý kiến trên Hacker News
Tôi đã thử demo tại https://moq.dev/publish/ và cảm giác thực sự rất mượt. Rất ấn tượng. Và tôi rất biết ơn vì công nghệ tuyệt vời này. Khi xem demo Big Buck Bunny trên điện thoại ở https://moq.dev/watch/?name=bbb, tôi thấy hiện tượng xuất hiện nhiều sọc đen ngang (lạ là trên PC dùng cùng Wi‑Fi thì lại bình thường). Tôi tự hỏi có phải do kích thước bộ đệm không. Có thể tăng bộ đệm ở phía client không, hay đây là thiết lập phía server? Và cảm ơn vì đã không bỏ quên South Korea trên bản đồ CDN “toàn cầu”
Tôi muốn hỏi liệu cái này chỉ chạy trên Chrome thôi phải không. Trên Firefox Android chỉ hiện thông báo rằng đây không phải trình duyệt được hỗ trợ
Tôi không rõ về hiện tượng sọc đen ngang. Chúng tôi render bằng phần tử <canvas>, resize theo kích thước video nguồn rồi lại resize bằng CSS để khớp kích thước cửa sổ
Trên OnePlus Ten, khi phát bằng Chrome thì các sọc đen nhấp nháy khá thường xuyên. Đặc biệt chúng xuất hiện theo kiểu từ phía trên màn hình đi xuống góc dưới bên phải, nên có thể đây là hiện tượng tạo tác do làm tươi màn hình (rolling shutter effect)
Vì trên trang nhắc nhiều đến mã Rust và WASM, có thể CPU của điện thoại không chạy WASM đủ nhanh nên mới xảy ra hiện tượng đó. Trên chiếc Samsung S20 của tôi thì hoàn toàn không thấy sọc đen nào
Tôi đã thử trên mac book air m4 với kết nối 600mbps và phản hồi gần như tức thì, rất đáng kinh ngạc
Bài viết có phần “tại sao nên quan tâm?”, nhưng lại không giải thích Media over QUIC mang lại lợi ích gì cho nhà phát hành nội dung hay người dùng cuối — tức hai bên quan trọng nhất (và có lẽ là duy nhất) trong trao đổi này. Vì vậy tôi muốn biết vì sao mình nên quan tâm đến công nghệ này
Lỗi của tôi. Tôi cố tránh lặp lại những gì đã viết trong các bài blog trước nên phần giải thích bị thiếu: https://moq.dev/blog/replacing-webrtc/ Và thực ra MoQ chủ yếu mang lại lợi ích cho các nhà phát triển. Nó giúp việc mở rộng quy mô và triển khai tính năng dễ hơn nhiều, nên lợi ích với người dùng là gián tiếp
Độ trễ đầu-cuối (glass-to-glass) tốt hơn đáng kể. Chủ yếu là vì giao thức giờ đây không còn theo kiểu request/response nữa
Xin chào! Tôi là một trong các nhà phát triển Cloudflare MoQ, cứ thoải mái đặt câu hỏi. Và cảm ơn vì giải thưởng, kixelated xD
Có đoạn giải thích rằng: “Không có head-of-line blocking: khác với TCP, các stream trong QUIC là độc lập. Nếu mất gói ở một stream (ví dụ track âm thanh), các track khác (ví dụ track video) sẽ không bị chặn. Hiện tượng giật khựng vốn luôn xảy ra với RTMP sẽ được loại bỏ nhờ điều này”. Với cấu trúc như vậy, tôi tự hỏi nếu track âm thanh bị mất gói nhưng video vẫn tiếp tục phát mà không dừng lại, thì âm thanh và hình ảnh có thể bị lệch sync không? Có thể tôi chưa hiểu rõ phần này vì không quá quen với công nghệ
Tôi có một câu hỏi. Có kế hoạch cụ thể nào để thu hẹp khoảng cách goodput giữa TCP và QUIC không[1]? Bài báo được liên kết nói rằng khi chuyển từ HTTP/2 (TCP) sang HTTP/3 (QUIC), bitrate video có thể giảm tới 9.8%. Tất nhiên MoQ có cấu trúc stack hơi khác nên khó khái quát trực tiếp, nhưng có vẻ vẫn sẽ có vấn đề tương tự. (Cá nhân tôi đã nghiên cứu AF_XDP datapath của MsQuic vài tháng qua như một phần luận văn thạc sĩ. Kết luận của tôi là GSO/GRO là lựa chọn tốt hơn, và QUIC rõ ràng cần thêm hardware offload hơn nữa :p)
[1]: https://arxiv.org/pdf/2310.09423
Tôi có vài điều muốn hỏi :)
Tôi muốn biết QUIC hiện đã tiến gần đến mức thực sự dùng được trong trình duyệt tới đâu rồi (cả trình duyệt lẫn hạ tầng đều hỗ trợ, kiểu “cứ thế là chạy”)
Và QUIC xử lý vấn đề NAT như thế nào? WebRTC bắt buộc phải có STUN/TURN để đi qua full cone NAT, nhất là TURN thì rất phiền vì phải vận hành rất nhiều hạ tầng
Tôi đang làm về streaming WebRTC tại getstream.io. WebRTC hơi rườm rà trong khâu cấu hình, nhưng khi đã kết nối được thì ưu điểm là độ trễ thấp. Tôi muốn biết MoQ sau khi thiết lập kết nối xong thì có ưu điểm hay vấn đề gì, tức là cảm giác so với WebRTC như thế nào
Tôi muốn hỏi liệu cân bằng tải cho relay có nằm ngoài phạm vi của MoQ không. Có vẻ bài viết không đề cập đến phần này
Tôi rất thích dự án này, thỉnh thoảng cũng đọc blog của kixelated và theo dõi trên Github.
Trước hết tôi muốn chúc mừng cả kixelated lẫn Cloudflare vì công việc tuyệt vời này.
Tôi tò mò về live streaming thời gian thực. Thông thường một buổi phát trực tiếp sẽ có hàng trăm hoặc hàng nghìn người xem cùng lúc, nên tôi muốn biết liệu MoQ có kế hoạch hay khả năng sử dụng/triển khai multicast hay không. Với HTTP/1.1 và HTTP/2 thì điều đó khó vì dựa trên TCP, nhưng với HTTP/3 dùng UDP thì tôi cảm thấy đây đã trở thành một ý tưởng thực tế hơn. Tôi rất muốn biết mọi người nghĩ gì. Tôi biết Akamai và BBC cũng đang nghiên cứu phần này
Không cần multicast! CDN về bản chất đã gần như là multicast ở tầng L7 (tầng ứng dụng). Không cần router hay ISP phải trực tiếp triển khai điều này ở L3. Đó chính là công việc tôi đã làm suốt 5 năm ở Twitch
Về lý thuyết, multicast chỉ giúp giảm lưu lượng từ edge của CDN sang ISP, nhưng điều đó chỉ thực sự có ý nghĩa với các sự kiện siêu lớn kiểu một năm mới có một lần như Super Bowl, còn với phần lớn sự kiện thì không hiệu quả. Nhiều CDN đã giải quyết chuyện này bằng cách đặt sẵn edge bên trong mạng của ISP, còn với sự kiện nhỏ thì xác suất hai người xem đi cùng một tuyến là thấp nên lợi ích gần như không có
Multicast còn có các vấn đề khác như kiểm soát tắc nghẽn và mã hóa, mà trong mô hình multicast liên hiệp thì mọi thứ còn khó hơn
Nơi multicast có thể mang lại lợi ích lớn nhất là P2P, nhưng trong hệ sinh thái CDN khổng lồ thì có lẽ rất khó được chấp nhận
WebRTC cũng là nơi multicast hợp lý nhất và còn dùng RTP (vốn ban đầu được thiết kế cho multicast), nhưng trên thực tế hiện vẫn không có nhiều quan tâm tới hỗ trợ multicast
Tuy vậy, tôi có nghe đồn Google dùng multicast cho dịch vụ Meet bên trong mạng riêng của họ, nên cũng chưa biết được
Link “just announced” này rất tốt cho cả những người hoàn toàn không biết đây là gì: https://blog.cloudflare.com/moq/ (lúc đầu tôi cũng bỏ sót)
“Độ trễ dưới một giây ở quy mô phát sóng” nhưng lại không có multicast thực sự
Câu “đây không chỉ là một giao thức khác, mà là một triết lý thiết kế mới” khiến radar phát hiện AI của tôi bật lên
Tôi muốn biết MOQ xử lý độ phân giải fallback và suy giảm chất lượng một cách uyển chuyển như thế nào. Và trong zed cũng có vấn đề là chuyển sang toàn màn hình mà màn hình không được lấp đầy
Tôi là người dùng Firefox, và muốn chia sẻ điều này như một lưu ý cho những ai truy cập các trang được Cloudflare host và dùng HTTP/3:
https://bugzilla.mozilla.org/show_bug.cgi?id=1979683
Có vẻ như có thể là vấn đề happy eyeballs? Tôi sẽ chuyển cho những người hiểu rõ hơn
Tôi muốn hỏi bạn có đang dùng trình phân giải DNS over HTTPS (DoH) trong trình duyệt không. Cá nhân tôi không tái hiện được hiện tượng này. Tôi đang dùng DoH với 1.1.1.1
Tôi thấy cả Chrome lẫn Firefox đều dùng HTTP/3 ổn định hơn khi dùng trình phân giải DoH thay vì DNS hệ thống. Khi dùng trình phân giải hệ thống thì nhiều trường hợp không lấy được bản ghi HTTPS DNS một cách nhất quán (hoặc hoàn toàn không lấy được),
mà hỗ trợ HTTP/3 của server chỉ hoạt động khi được “quảng bá” cho trình duyệt thông qua bản ghi HTTPS DNS hoặc header Alt-Svc đã được cache trước đó từ HTTP/2/1.1. Trình duyệt cũng có xu hướng tái sử dụng kết nối đang mở nên không hay tạo kết nối mới
Header Alt-Svc cũng không được cache nhất quán, đặc biệt là trên Firefox
Mọi thứ còn phức tạp hơn ở chỗ trình duyệt (đặc biệt là Chrome) sẽ tắt luôn hỗ trợ HTTP/3 nếu số lần kết nối thất bại tích lũy vượt một ngưỡng nào đó. Tôi từng gặp vậy khi dùng Wi‑Fi ở trường đại học, nơi lưu lượng UDP thường xuyên bị chặn khá thất thường, và sau đó ngay cả ở nhà HTTP/3 cũng không hoạt động. Cách khắc phục duy nhất là vào chrome://flags và bật QUIC thủ công. Dù mặc định có hiện là “enabled by default” thì trạng thái thực tế của trình duyệt vẫn có thể khác. Firefox cũng có từ bỏ HTTP/3 theo kiểu tương tự, nhưng không cứng đầu như Chrome nên không quá nghiêm trọng
Nếu muốn debug thêm, bạn có thể kiểm tra xem EncryptedClientHello(ECH) có hoạt động không tại https://tls-ech.dev, vì trang này chỉ dùng bản ghi HTTPS cho khóa ECH nên giúp cô lập vấn đề.
Sau đó có thể dùng công cụ kiểm tra HTTP/3 của Fastly (https://http3.is) để xem có phải chỉ đang dùng thương lượng Alt-Svc hay không.
Trang test của Cloudflare (https://cloudflare-quic.com) dùng cả bản ghi HTTPS DNS lẫn Alt-Svc, nên nếu HTTP/3 được bắt ngay thì nghĩa là việc phân giải bản ghi HTTPS đang hoạt động tốt
Sẽ rất hữu ích nếu bạn chia sẻ kết quả thử nghiệm. Việc lỗi của Firefox không xuất hiện đồng nhất với tất cả mọi người có lẽ là vì có quá nhiều biến số như vậy
(Điều tôi muốn báo với phía Cloudflare là https://cloudflare-quic.com/favicon.ico có vẻ đang bị cấu hình sai. Và việc tải hình ảnh https://web.archive.org/web/20230424015350im_/https://www.cloudflare.com/img//nav/globe-lang-select-dark.svg từ Wayback Machine làm chậm quá trình tải trang; với images thì nên dùng link “id_” để tránh bị rewrite và sẽ nhanh hơn. Trước đây tôi từng dùng nó kết hợp với Cloudflare Workers để tạm thời khôi phục một site khi việc di chuyển server thất bại. Hoặc chỉ cần dùng bản gốc https://www.cloudflare.com/img/nav/globe-lang-select-dark.svg là được. File này hiện trên site vẫn còn sống)
Tôi đã thử nghiệm rất nhiều với đủ loại vấn đề triển khai và phát hành kỳ quặc của HTTP/3 trong vài năm gần đây. Đây là một giao thức tuyệt vời. Nhưng cũng có rất nhiều vấn đề triển khai và vận hành lạ lùng, khác thường
Tôi muốn hỏi liệu chuyện này có chỉ xảy ra trên macOS không. Trên FF 141, 142 của Windows thì tôi không tái hiện được
Thật sự rất hay! Tôi rất khâm phục công sức bỏ ra. Lúc đầu tôi đọc thành QUIC CDN và nghĩ “không thể nào”, nhưng sau khi tìm hiểu kỹ hơn rằng Media over QUIC là một khái niệm khác, tôi thấy nó khá thú vị
Ứng dụng đầu tiên rất thú vị. Tôi nghĩ nên đăng lên Show HN. Tôi từng làm trong lĩnh vực nền tảng video trực tiếp, và MoQ đủ hấp dẫn khiến tôi muốn phát triển lại trong mảng này thêm một lần nữa
Nếu “công nghệ vận hành ở hậu trường” thì tôi nghĩ chỉ cần hỗ trợ các trình duyệt chính là đủ (thậm chí còn không thấy thông tin trên caniuse).
Và nếu các engine webview như Microsoft Edge WebView2 cũng được hỗ trợ thì tôi cảm thấy có thể áp dụng ngay vào phát triển.
Nhưng ngược lại, có lẽ phải được những bên như OBS hay YouTube hỗ trợ thì mới thực sự có ý nghĩa
Vậy nên... MoQ đang đi theo hướng hơi tách khỏi kiểu một web API “hộp đen” lớn duy nhất như WebRTC. Từ góc nhìn trình duyệt, điểm mấu chốt là hỗ trợ WebTransport API.
Khi dùng MoQT cùng WebTransport, sẽ có nhiều cách tiếp cận mới như dùng WebCodecs làm trình phát video chẳng hạn. Nếu chấp nhận thêm một chút độ trễ thì cũng có thể phát bằng MSE và áp dụng DRM.
Còn việc cho phép publish trực tiếp từ OBS là thứ tôi đã làm từ trước khi vào Cloudflare, nhưng điều này phụ thuộc khá nhiều vào cách triển khai các chi tiết media ở tầng “streaming format”. Trong ngành, đặc tả cho tầng này hiện vẫn đang tiếp tục phát triển, và hiện WARP là spec dẫn đầu. Khi đặc tả WARP dần ổn định hơn, tính năng này có thể được tích hợp vào OBS và các công cụ tương tự. Ngay lúc này cũng đã có thể publish video bằng một định dạng dự phòng dựa trên fMP4 thông qua Norsk(https://norsk.video/)
Với YouTube thì Google có người đang tích cực đóng góp vào MoQT, nhưng theo tôi rất khó nói khi nào và theo cách nào họ sẽ áp dụng nó vào sản phẩm YouTube
https://caniuse.com/webtransport
https://caniuse.com/webcodecs
Thực ra WebCodecs không phải bắt buộc, cũng có thể render bằng MSE, nhưng sẽ phức tạp hơn và độ trễ cũng cao hơn.
Chúng tôi đang làm WebSocket fallback và bộ mã hóa OPUS dựa trên WASM để hỗ trợ Safari