Dla 5% czytelników, którzy już wiedzą o Media over Quic, prawie na pewno masz własne zdanie na ten temat, więc nie zapomnij pominąć artykułu i przejść prosto do komentarzy, aby wyjaśnić, dlaczego się mylę. Dla pozostałych 95% jesteś prawdopodobnie tak teraz: Nie martw się, moi przyjaciele, dostaniemy się do Quic, jak wysyłasz media i jak to różni się od umieszczania RTC w Internecie. Czym jest WebRTC? Najpierw zróbmy szybki przegląd WebRTC. WebRTC jest API za większością aplikacji wideokonferencyjnych w Internecie. Jest również używany do wielu innych przypadków wykorzystania obejmujących strumieniowanie wideo w czasie rzeczywistym. Aby to wyjaśnić, rozważ aplikację na webinar: Stwórz aplikację Webinar Załóżmy, że chcesz zbudować aplikację internetową, aby hostować webinary.Potrzebujesz hosta, aby móc udostępniać swoje wideo i dźwięk z kamery internetowej, a potencjalnie udostępniać ekran w czasie rzeczywistym. Konieczne byłoby również, aby uczestnicy mogli korzystać z tych strumieni wideo od gospodarza i potencjalnie udostępniać własne wideo i dźwięk z kamery w celu zadawania pytań i / lub ogólnej interaktywności. Jak WebRTC umożliwia webinary Standardowym rozwiązaniem do budowania naszej aplikacji webinarowej byłoby użycie WebRTC, który jest API Web zaprojektowanym głównie w celu ułatwienia aplikacji konferencyjnych wideo.W aplikacjach WebRTC każdy uczestnik przesyła swój dźwięk i wideo jako strumienie w czasie rzeczywistym, w większości przypadków na centralny serwer zwany Selektywna jednostka przesyłania Każdy uczestnik otwiera połączenie z serwerem, pobiera własny lokalny strumień kamery, negocjuje z serwerem, aby koordynować wybór kodeków, prędkość bitów itp., A następnie zaczyna nadawać i subskrybować strumienie z serwera. W kodzie wyglądałoby to tak: // SFU WebRTC: Single connection to server async function joinWebinar() { // 1. Get your webcam const localStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true }); // 2. Create ONE peer connection (to the server, not to each participant) const peerConnection = new RTCPeerConnection({ iceServers: [{ urls: ['stun:stun.example.com'] } }); // 3. Add your local stream to the connection for (let track of localStream.getTracks()) { peerConnection.addTrack(track, localStream); } // 4. Exchange connection details with the server const offer = await peerConnection.createOffer(); const answer = await signalingServer.send({ offer }); await peerConnection.setLocalDescription(offer); await peerConnection.setRemoteDescription(answer); // 5. When the server sends you other participants' streams, display them peerConnection.ontrack = (event) => { const participantId = event.streams[0].id; displayRemoteVideo(participantId, event.streams[0]); }; } Serwer WebRTC Serwer nie tylko koordynuje połączenia między uczestnikami, ale także umożliwia selektywne przekazywanie strumieni pomiędzy uczestnikami. W przypadku webinaru z 100 uczestnikami oznacza to, że każdy uczestnik nie udostępnia swojego strumienia kamery 99 różnych razy, po prostu przesyła 1 strumień na serwer, który jest przekazywany do wszystkich. Każdy z 100 uczestników nie musi również subskrybować 99 innych źródeł wideo, aplikacja może stosować logikę biznesową, aby każdy uczestnik subskrybował tylko podzbiór dostępnych źródeł (takich jak być może każdy otrzymuje kamerę gospodarza i udostępnianie ekranu, a 5 losowych źródeł innych uczestników), zmniejszając przepustowość dla wszystkich. WebRTC w praktyce WebRTC został zbudowany dla konferencji wideo i sąsiednich przypadków użytkowania, takich jak nasz przykład webinar, więc stał się metodą defacto do wykonywania wymiany wideo w czasie rzeczywistym nawet dla platform bez przeglądarki, takich jak Android i iOS. Główne wyzwania dla WebRTC obejmują: Scalability - Server-side forwarding of many simultaneous video streams requires significant CPU and bandwidth, making it increasingly expensive to scale beyond a certain point (usually thousands) Control - WebRTC was built primarily with video conferencing in mind, and so while it is highly optimized for that use case, it lacks fine-grained control over media encoding & delivery (codecs, strings, packet-level control) that are relevant in other use cases like remote control or AI video pipelines. Czym jest Media over Quic? Media over Quic (MoQ) to nowy protokół do strumieniowania wideo w czasie rzeczywistym... jak WebRTC. A Media over Quic pozwala nam budować aplikacje wideo w czasie rzeczywistym, takie jak nasza aplikacja webinar, jak WebRTC... OK, więc jeśli WebRTC już istnieje i działa dobrze, dlaczego firmy takie jak i Wszyscy pracują nad nowym protokołem. CloudFlare Meta Najpierw porozmawiajmy o Quick Prawie każda normalna komunikacja, z którą możesz się zmierzyć jako programista sieciowy, ma formę żądania HTTPS, która obejmuje szereg kroków do przodu i do tyłu między siecią a serwerem, aby nawiązać połączenie. Te żądania HTTP i API, takie jak Websockets i czasami WebRTC, używają protokołu o nazwie TCP, protokołu do wymiany danych między siecią a serwerem, gdzie pakiety są wysyłane w kolejności. Jeśli jeden pakiet zostanie utracony, kolejne pakiety zostaną zatrzymane, co zachowuje porządek, ale może prowadzić do „blokowania linii głowy” QUIC jest alternatywnym protokołem i działa bardziej jak szybki kurier, który priorytetowo określa prędkość, może opuścić mniej ważne pakiety (takie jak ramka wideo), ale oznacza to, że reszta dostawy przebiega szybciej. Różnice między QUIC a normalnym TCP/HTTP Połączenia QUIC wymagają mniej instalacji QUIC może spuścić poszczególne pakiety inteligentnie zamiast spowalniać całe połączenie QUIC może utrzymywać połączenie podczas przełączania się między sieciami, np. przełączanie z WiFi na połączenie komórkowe QUIC jest zatem przydatnym protokołem sieciowym, który jest szczególnie odpowiedni do strumieniowania wideo, chociaż teoretycznie można wysyłać dowolne dane za pośrednictwem QUIC. Teraz, gdy mamy, QUIC, wyślijmy kilka mediów na ten temat Ideą Media over Quic jest, jak prawdopodobnie już się domyślacie, wysyłanie mediów przez połączenia QUIC. W szczególności jednak Media over Quic jest oficjalnym protokołem opartym na QUIC. Media over Quic działa jako system pub/sub, w którym wysyła strumienie zaszyfrowanych mediów do (w zasadzie CDN) oraz Otrzymuj te strumienie z relay: publisher relay subscribers Media za pośrednictwem relayów Quic są treściowo-agnostyczne, nie wiedzą, co dzieje się w sieci, czy to wideo, audio, tekst, czy po prostu losowy kod binarny. Innym kluczowym aspektem jest to, że przekaźniki Media over Quic mogą być łańcuchowane razem, dzięki czemu niektórzy subskrybenci mogą otrzymywać dane, które przeszły tylko 1 przekaźnik, a inni mogą otrzymywać dane, które przeszły 5 przekaźników. Media over Quic relay nie muszą również utrzymywać stanu ogólnego „streamingu”, działają tylko jako rury danych, nie zdając sobie sprawy z liczby wydawców i subskrybentów lub jak długo sesja była aktywna. Są to kluczowe funkcje, które pozwalają Media over Quic być uruchomione przez , który umożliwia strumieniowanie w czasie rzeczywistym do milionów widzów jednocześnie, co nie jest możliwe z WebRTC. CDNs Przykłady pseudokodu Aby obejrzeć strumień, to Media over Quic wyglądałoby coś takiego async function watchWebinarViaQuic() { // 1. Connect to the relay const connection = await Moq.connect("https://relay.moq.some-cdn.com"); // 2. Subscribe to the broadcast const broadcast = connection.consume("my-webinar"); // 3. Subscribe to the video and audio tracks const videoTrack = await broadcast.subscribe("video"); const audioTrack = await broadcast.subscribe("audio"); // 4. Decode and display/play the streams decodeAndDisplayVideo(videoTrack); decodeAndPlayAudio(audioTrack); } Aby nadać strumień wyglądałby coś takiego: async function joinWebinarViaQuic() { // 1. Get your webcam const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true }); const videoTrack = stream.getVideoTracks()[0]; const audioTrack = stream.getAudioTracks()[0]; // 2. Connect to a MoQ relay (instead of connecting to an SFU) const connection = await Moq.connect("https://relay.moq.some-cdn.com"); // 3. Create a broadcast (namespace for your streams) const broadcast = new Moq.Broadcast(); connection.publish("my-webinar", broadcast); // 4. Get video and audio tracks from the relay const videoMoqTrack = await broadcast.requested('video'); const audioMoqTrack = await broadcast.requested('audio'); // 5. Stream your camera to the relay encodeAndStreamVideo(videoTrack, videoMoqTrack); encodeAndStreamAudio(audioTrack, audioMoqTrack); } W rzeczywistości kodowanie / dekodowanie i wyświetlanie wideo obejmuje zupełnie inną rzecz o nazwie Ale są też Oto jak sobie z tym radzić... WebCodecs bibliotekarzy Strumienie vs połączenia Podstawową różnicą architektoniczną między WebRTC a Media over Quic jest to, że WebRTC działa jako seria aktywnych połączeń stanowych, podczas gdy MoQ działa jako seria niezależnych, równoległych strumieni. W WebRTC połączenia są z natury dwukierunkowe (czy to między rówieśnikami, czy z klienta na serwer), podczas gdy w MoQ operacje z równoległymi niezależnymi strumieniami jednostronnymi. No dobrze, ale dlaczego MoQ? Wiele firm i deweloperów jest podekscytowanych MoQ, ponieważ ma konkretne zalety w porównaniu z WebRTC (i innymi technologiami wideo internetowego). MoQ może dostarczać tego samego rodzaju doświadczenia wideo w czasie rzeczywistym jak oprogramowanie do wideokonferencji, ale ponieważ strumienie są wysyłane za pośrednictwem sieci CDN, jedna osoba z kamerą może przesyłać strumienie do milionów ludzi, co byłoby niemożliwe z WebRTC Scale: QUIC umożliwia bardziej niezawodne przesyłanie strumieniowe, pozwalając na utrzymanie połączeń nawet podczas przełączania się z sieci (np. mobilnego na WIFI), a także umożliwia opuszczanie ramek / pakietów w celu zapewnienia dostawy w czasie rzeczywistym. Efficient transport Ponieważ model infrastruktury jest tak prosty, znacznie upraszcza stos sieciowy, a jednocześnie zapewnia większą kontrolę niskiego poziomu nad kodowaniem i dekodowaniem wideo, co jest ważne dla niektórych aplikacji. Simple model Media o Quic w praktyce Od stycznia 2026 roku Media over Quic jest nadal na bardzo wczesnym etapie i opiera się na kilku komponentach, które wciąż są rozwijane: WebTransport - WebAPI, który umożliwia połączenia QUIC jest obsługiwany przez ~80% przeglądarek, ale nie jest jeszcze obsługiwany w Safari Biblioteki: podstawowe biblioteki Media over Quic istnieją tylko dla Rust (serwer) i JS (klient), a mobilne SDK nie są jeszcze dostępne Przekaźniki: Kilku dostawców CDN tworzy przekaźniki MoQ, a Cloudflare już ma jeden, ale są one nadal w „beta”, a najbardziej niezawodną metodą w tej chwili jest hosting własny Media over Quic ma wystarczająco dużo narzędzi i wsparcia dla wczesnych adoptorów, aby zacząć budować z nim, ale nadal wymaga wielu adaptacji i wdrożeń „DIY” i jest jeszcze za wcześnie na bezproblemowe doświadczenie dewelopera. Deweloperzy (w tym ja!) pracują nad podstawowymi bibliotekami dla Media over Quic, a firmy opracowują rozwiązania relay/hosted, więc spodziewaj się, że MoQ stanie się bardziej stabilny i gotowy do produkcji w nadchodzących miesiącach / latach. Czy zastąpi WebRTC? Dla ludzi w przestrzeni wideo w czasie rzeczywistym, Media over Quic było gorącym tematem, z dużą dyskusją na temat tego, czy Media over Quic zastąpi WebRTC. Do 5% czytelników już wiedziało o MoQ przed dotarciem do tego artykułu, prawdopodobnie już przyszedłeś do tego artykułu z pewną opinią na temat odpowiedzi, więc nie wahaj się komentować lub opublikować swój przeciwargument, mógłbym użyć SEO. Dla pozostałych 5% z was, którzy zrobili to przez cały artykuł (kudos!). możesz nie mieć konia w tym wyścigu, ale chcę podkreślić, że niezależnie od tego, jeśli pracujesz w rozwoju stron internetowych, prawdopodobnie dobrze jest być świadomym MoQ i że jest to nowy i nadchodzący standard dla strumieniowania mediów w czasie rzeczywistym. Zacząłem pomagać w rozwoju bibliotek MoQ nie dlatego, że mam jakieś szczególne zainteresowanie lub pragnienie zastąpienia WebRTC, ale raczej dlatego, że lubię i kontrolę niskiego poziomu, a to jest fajne, aby dostać się na parterze nowego protokołu. to powiedziawszy, niektóre z moich najbliższych kontaktów zawodowych są ekspertami WebRTC (wcześniej prowadziłem który sztuczna inteligencja filtruje SDK ukierunkowane na produkty WebRTC) i jako deweloper, po prostu patrząc na dokumentację MoQ jest jasne, że jest jeszcze zbyt surowy i wcześnie na powszechne użycie. WebCodecs Startupy Czy zastąpi WebRTC? Może WebRTC ma dobrze ugruntowany ekosystem i rozwiązał problem, który wcześniej nie miał dobrego rozwiązania.W przeciwieństwie do WebRTC, MoQ nie konkuruje z „niczym”, konkuruje z ugruntowanym, dobrze obsługiwanym protokołem. Mówiąc to, MoQ ma realne korzyści w stosunku do WebRTC i innych technologii strumieniowych, takich jak Oto prawdopodobnie niektóre przypadki użycia, w których zalety MoQ zapewniłyby przekonujący przypadek dla wczesnych adoptorów: Strumieniowanie HLS/DASH Too big for WebRTC, to small for HLS/DASH Słodkim punktem dla wczesnych adoptorów prawdopodobnie będą kategorie aplikacji, które nie są dobrze obsługiwane ani przez WebRTC, ani przez HLS / DASH (nie w czasie rzeczywistym, ale szczególnie na dużą skalę). Niektóre przykłady mogą obejmować: Oprogramowanie webinarowe, w którym webinaria wymagają interaktywności w czasie rzeczywistym, ale które również muszą się rozwijać do tysięcy lub dziesiątek tysięcy uczestników Transmisja wirtualnych wydarzeń, w których mówcy zwykle przesyłają mało=>wiele, ale często zawierają interaktywne pytania i odpowiedzi Narzędzia transmisji na żywo oparte na przeglądarce, które przesyłają wideo z przeglądarek na serwery i innych uczestników, a jednocześnie przesyłają na żywo platformy mediów społecznościowych, takie jak Facebook lub YouTube. More control and reliability than WebRTC Media over Quic byłoby również przydatne w scenariuszach, w których wymagane są solidne połączenia wideo lub kontrola niskiego poziomu dostarczania wideo, na przykład w scenariuszach z zdalnymi źródłami kamery (kamery bezpieczeństwa, drony, pojazdy zdalnie obsługiwane) lub w rurociągach wideo AI w czasie rzeczywistym. WebRTC jest często używany w tych scenariuszach, ale w tych przypadkach korzyść skali MoQ jest nieistotna, główne zalety pochodzą z bardziej wytrzymałej łączności HTTP3/Quic i kontroli ram niskiego poziomu, które sprawiają, że MoQ jest atrakcyjną opcją. For everything else Dla wszystkiego innego istnieje i WebRTC. Karty Mastercard Jeśli budujesz standardową konferencję wideo, WebRTC jest zdecydowanie lepszą technologią i prawdopodobnie nie będzie przypadku użycia, w którym MoQ ma sens, dopóki ekosystem MoQ nie osiągnie poziomu stabilności i dojrzałości WebRTC (może? ale nawet wtedy, może to zająć trochę czasu). Więcej zasobów Jeśli jesteś ciekawy Media over Quic, WebRTC lub po prostu strumieniowania mediów w czasie rzeczywistym w ogóle, oto kilka zasobów: Media over Quic Jeśli chcesz dowiedzieć się więcej o Media over Quic, możesz zagłębić się w Oficjalna strona MoQ. WebCodecsFundamentals, podręcznik open source z przykładami kodu MoQ nieporozumienia WebRTC Istnieje wiele tutoriali na temat WebRTC ( , ) i można również usłyszeć kilka innych ekspertów WebRTC mówią o MoQ vs WebRTC na Istnieje również świetna społeczność dyskordów dla programistów WebRTC o nazwie . Strona internetowa.dev MDN Webrczacki Pióro
