.NET Streams 的用途是什麼？它與串流有何關係？

如果你使用.NET，遲早會遇到以下概念： 串流和資料傳輸當然，隨之而來的問題還有，這與今天每個人都在談論的「如何契合」有何關係？ 流影片、音樂、雲端遊戲…雖然看起來只是“一些東西” Netflix公司 Spotify 等平台也遵循著相同的原則，這些原則與 .NET 用於高效行動數據的原則相同。

本文旨在將這兩個領域結合起來：一方面是總體思路… 串流媒體作為一種連續傳輸技術 （視訊、音訊、雲端遊戲、直播活動）以及另一方面，.NET，特別是，如何 SignalR 和 .NET Streams 他們利用這種模式在客戶端和伺服器之間即時或按需發送和接收訊息。

什麼是串流？為什麼在使用 .NET 進行程式設計時，串流媒體如此重要？

當我們談論串流媒體時，我們通常指的是… 即時播放音訊、視訊或其他多媒體內容 用戶無需事先將整個文件下載到設備，即可透過網路觀看影片。視訊內容以小片段的形式接收，暫時儲存在記憶體中，幾乎可以立即播放。

這種模式徹底改變了我們消費媒體的方式：現在我們可以 想看劇集、電影、聽音樂或Podcast就看。無需依賴廣播時間表或下載大量數據，即可透過手機、電腦或電視觀看。 Netflix、YouTube 等平台， Spotify Twitch和其他串流平台是這項技術的公眾形象。如果您正在尋找串流媒體工具，請查看… 串流節目.

從技術層面來說，這意味著數據（視訊、音訊、文字、事件等） 它們從伺服器向一個或多個客戶端發送連續的資料流。.NET 正是透過 Stream 的概念抽象化了「資料流」的概念，而 SignalR 則透過客戶端和伺服器之間的雙向流機制對其進行了擴展。

此外，串流媒體不僅限於娛樂：還有 線上培訓、網路研討會、會議、商業活動直播和 遊戲 在雲端這一切都依賴於能夠即時處理資料的架構，而無需等待獲得完整的資料集，這與 .NET 中的 Streams 模型非常吻合。

傳統廣播、下載和串流媒體之間的區別

為了充分理解串流媒體技術的優勢（以及.NET Streams所解決的問題），將這項技術與以下技術進行比較會很有幫助… 傳統廣播和文件下載每種模型都有其自身的資料分發和使用方式。

在傳統的廣播中，例如傳統廣播或電視，單一訊號源透過無線電波或電纜發送訊號； 所有調諧接收器同時接收到完全相同的內容。用戶必須適應播出時間：如果他們不在節目播出時觀看，就會錯過節目（或只能依靠錄製）。

下載時的邏輯截然不同：整個檔案會從伺服器傳輸到使用者的設備，而且 僅當下載完成後它可以離線運行。但這意味會佔用磁碟空間，下載大檔案需要較長時間，而且需要自行管理這些本機檔案。

另一方面，串流媒體則融合了兩種模式的元素：就像下載一樣，資料透過網路從伺服器傳輸到客戶端；但是，就像廣播一樣， 播放可能在全部內容可用之前就開始。資料以小塊形式接收，並在到達時立即進行處理，這減少了 El Temppo 等待時間並避免過載 存儲 本地。

從開發的角度來看，這就需要設計出能夠實現以下功能的系統： 增量式地產生和使用數據.NET Streams、IAsyncEnumerable 和 ChannelReader 剛好滿足了這項需求，它們提供的 API 可以處理逐步傳送或讀取的專案序列。

串流媒體的技術工作原理

當使用者在視訊或音訊串流平台上按下「播放」鍵時，會觸發一系列旨在生成內容的流程。 應以流暢、靈活且盡可能快速的方式呈現。 以現有網路連線的速度運轉。

一切都始於編碼：原始內容，無論是即時攝影機畫面、電影或音軌，都要進行編碼。 它將其壓縮並轉換為適合透過網路傳輸的數位格式。此步驟可減少檔案大小並使其適配標準編解碼器和容器（H.264、H.265、AAC 等）。諸如此類的工具 使用 HandBrake 轉換影片格式 它們在這個步驟中起到了幫助作用。

接下來，將編碼後的檔案切片成 幾秒鐘的碎片這種分段方式允許使用者的播放器下載並播放連續的片段，根據網路情況調整品質（稱為自適應位元率），並更好地應對頻寬的變化。

這些數據片段透過諸如以下協定從伺服器發送到用戶設備： HTTP 或 RTP依賴 TCP（更可靠，非常適合高品質視訊隨選）或 UDP（速度更快，通常用於視訊通話或廣播等對即時性要求極高的場景，即使會遺失一些資料包）。科技 遊戲和視訊通話的 QoS 它們有助於降低對延遲敏感場景下的延遲。

在客戶端，玩家執行著名的 緩衝它會在開始播放前預先暫時儲存幾個片段，以建立一個可以應對短暫連線中斷的緩衝區。如果網路速度變慢，播放器消耗緩衝區的速度超過了緩衝區補充的速度，就會出現我們都遇到過的卡頓和中斷。

最後，客戶端解碼壓縮資料並將其轉換為 即時影像和聲音從表面上看，這就像魔法一樣，但實際上，它是在幾毫秒內連續接收、儲存、解碼和回放資料包的過程。這種分塊切片、傳送、讀取和處理資料的模式，與 .NET 提供的用於處理順序資料的 Streams 模型完美契合。

我們在網路上可以找到的串流類型

串流媒體技術已經擴展到幾乎所有類型的數位內容。每種模式都有其自身的特點，但它們都秉持著相同的理念： 持續發送和消費數據我們可以使用 .NET 中的非同步流來完美地模擬這種現象。

最受歡迎的類型之一是 視頻流既有點播內容，也有直播內容。平台包括 YouTube、Netflix 等。 Amazon Prime 視訊或類似的OTT服務提供高清、4K及更高解析度格式的短片、電影和劇集。版權管理通常依賴地理限制，因此某些內容庫僅在特定地區可用。

El 流媒體音樂 這是另一個巨大的領域：像Spotify、Apple Music和Tidal這樣的服務讓你無需將歌曲實際儲存在裝置上即可收聽數百萬首歌曲。這導致CD銷量急劇下降。 下載 de MP3讓位於訂閱模式和對海量目錄的按需存取。

我們也有 視頻遊戲流媒體 以及一些應用程序，其中游戲運行在雲端，用戶在向伺服器發送操作（鍵盤、滑鼠、控制器）的同時，還能即時觀看遊戲影片。這種方法需要低延遲連接，是雙向串流媒體的典型範例，與 .NET 中 SignalR 管理的客戶端伺服器和伺服器端資料流非常相似。

不要忘記 現場活動 （例如網路研討會、會議、頒獎典禮、體育賽事、網紅直播等）以及線上教育或培訓內容。在所有這些情況下，用戶都會即時連接到正在產生的直播串流，但通常內容最終會被保存下來，以便稍後點播觀看。

與其他模型相比，串流媒體的優勢和挑戰

串流媒體的興起並非偶然：它對使用者和開發者都具有諸多優勢，使其成為內容消費的主流模式。最顯而易見的是… 無需下載整個文件即可近乎即時訪問你按下「播放」鍵，幾秒鐘之內就能看到或聽到你想看的內容或聽到你想聽的內容。

另一個重要優勢是 節省設備儲存空間由於未儲存完整文件，手機、平板電腦或其他裝置可能會出現問題。 手提 它們不會被電影或整張光碟塞滿，這點對於內部儲存空間較小的設備來說尤其重要。

此外，還有一個多樣性因素：使用者可以隨時獲取所需資訊。 龐大、可更新和可自訂的產品目錄這些服務會分析每個人的行為和喜好，從而推薦新的內容，增加使用時間和滿意度。

此外，串流媒體播放非常靈活：它可以 暫停、恢復、快轉、快退或切換設備 幾乎無縫銜接。所有這一切都未造成內容的不連貫性，這得益於伺服器和用戶端對資料片段和播放位置的高效管理。

不太令人愉快的是，有兩個明顯的挑戰：首先是… 完全依賴穩定且頻寬充足的互聯網連接另一方面，還存在地理限制、安全問題以及潛在風險。 惡意軟件 如果使用不可靠的服務，就會出現問題。從技術層面來說，這也迫使我們考慮資料流中的延遲、緩衝、丟包和錯誤處理——這些挑戰與我們在 .NET 中實現 Streams 時面臨的挑戰非常相似。

良好串流媒體播放的基本技術要求

雖然從使用者的角度來看，體驗可能很簡單，但實際上需要完成一系列步驟。 流暢播放的技術要求首先，也是最關鍵的一點，是連結的速度和穩定性。

對於串流音頻，大約需要連接數 1-2 Mbps的雖然標清影片建議使用 3-4 Mbps 的網速，但大多數平台建議高畫質影片至少使用 5-8 Mbps，而 4K 影片通常需要 25 Mbps 或更高的網速，尤其是在多個裝置分享網路的情況下。如果您不確定自己的網路連線速度，請進行網路速度測試。 網路速度測試.

擁有相容且最新的設備非常重要：平台的應用程式或 網頁瀏覽器 它們必須使用最新版本。 充分利用最新的編解碼器和協議這可以提高串流媒體播放的品質和效率。良好的 WiFi 覆蓋或穩定的有線連接也至關重要，建議使用。 串流節目 必要時進行優化。

如果用戶依賴行動數據，那麼就會出現以下情況： 數據計劃觀看高畫質影片會在短時間內消耗大量流量，因此最好調整解析度或盡可能使用 Wi-Fi。 5G 的普及顯著提升了使用者體驗，但並不能消除監控流量使用的必要性。

在開發層面，當使用 .NET Streams 和 SignalR 以連續流的方式傳送資料時，請務必牢記以下限制： 調整數據生產的節奏 根據客戶端的能力，實施取消操作，並透過避免生產速度超過接收方的消費速度來妥善管理記憶體壓力。

ASP.NET Core 中的 SignalR 是什麼？它如何引入串流？

在 .NET 生態系中，SignalR 是專為 ASP.NET Core 設計的函式庫。 伺服器與客戶端之間的即時通信 （Web、.NET、Java、JavaScript）。它允許雙向發送訊息，而無需客戶端持續查詢伺服器，可使用 WebSocket 或其他傳輸方式（取決於可用性）。

它最強大的功能之一恰恰是 支援資料流 這支援伺服器到客戶端和客戶端到伺服器的通訊。當資訊逐漸到達或動態產生時（例如，長時間進程的結果、定期更新、感測器事件或任何連續資料流），這非常有用。

在 SignalR Hub 上啟用串流功能時，每個資料都會傳送到另一端。 一旦可用無需等待整個資料集準備就緒，這與我們一直在討論的一般串流模式完美契合，但適用於任意資料（整數、字串、物件），而不僅僅是視訊或音訊。

要讓 Hub 方法被視為串流方法，只需滿足以下條件： 返回或使用專為非同步序列設計的類型例如 IAsyncEnumerable或 ChannelReader或將它們封裝在 Task 中。之後，SignalR 會負責將序列中的每個元素轉換為傳送給客戶端或從客戶端接收的獨立訊息。

這種方法允許進行設計 反應速度更快、效率更高的 API避免了手動設定尋呼協定或將資料分組到大型回應中，從而節省了準備和透過網路傳輸的時間。

使用 SignalR 中的 .NET Streams 實現伺服器到客戶端的串流媒體

最常見的情況是 從伺服器向客戶端傳輸數據在 SignalR 中，當 Hub 方法傳回 IAsyncEnumerable 時，它就變成了串流方法。或 ChannelReader這告訴框架，將接收一系列元素，而不是單一回應值。

實現這種模式最簡潔的方法就是使用 非同步迭代器方法 （非同步 IAsyncEnumerable） （帶有 yield 返回）。在每次迭代中，伺服器產生一個新值並立即將其傳送給客戶端，用戶端接收並處理該值，而無需等待循環結束。

這些方法可以接受一個特殊的 CancellationToken（具有對應的屬性），該令牌會在客戶端停止監聽串流時觸發。這使得伺服器能夠… 停止資料產生並釋放資源 如果用戶端已中斷連線或提前取消，則會阻止執行不必要的邏輯。

另一個選擇是使用 ChannelReader。建立通道並返回讀取器，同時輔助任務負責將元素寫入寫入器。每次將元素寫入 ChannelWriter 時，此操作都會執行。 商品會立即發送給客戶。當編劇完成寫作後，客戶就知道這一系列作品已經完成了。

這種基於通道的方法在我們需要更精確地控制資料產生方式和時間時非常有用，但我們也必須注意始終填充通道並妥善處理異常，以避免任何流程未完成。通常，使用 IAsyncEnumerable 的非同步迭代器可以大幅簡化這些細節。

使用 .NET Streams 實作客戶端到伺服器的串流傳輸

SignalR 的功能不僅限於外部串流媒體：它還允許 客戶端以連續資料流的形式向伺服器發送資料。為此，Hub 方法可以接收 IAsyncEnumerable 類型的參數。或 ChannelReader 。

Hub 方法從伺服器端取得數據，方法是從 ChannelReader 讀取資料或對 IAsyncEnumerable 使用 await foreach 迴圈。每次客戶端向其端寫入新元素時， 伺服器方法接收到該元素後，可以即時處理它。例如，透過註冊、轉換或將其儲存在資料庫中。

這種模式非常適合客戶端逐步產生資訊的場景：上傳 日誌這包括發送指標、部分結果、文件中的行、聊天訊息等。它不是將所有內容累積起來一次發送，而是分小段傳輸，伺服器在接收到這些小段內容後即可進行處理。

當客戶端使用 IAsyncEnumerable 時，序列會在生產者方法執行完成後立即結束。但如果它使用的是 ChannelWriter，則必須 呼叫 Complete() 明確關閉通道。在這兩種情況下，伺服器都會偵測到流程結束，並可根據需要進行清理或啟動其他邏輯。

總而言之，使用 .NET Streams 進行客戶端到伺服器的串流允許您構建 靈活的數據通道在這種模式下，伺服器無需等待客戶端完成其工作即可開始執行操作，從而降低整體延遲並提高系統回應速度。

.NET 用戶端上的串流：流的消耗與發送

在客戶端（以 .NET 編寫），SignalR 提供了幾種方法。 呼叫與串流處理相關的 Hub 方法對於伺服器到客戶端的流程，API 公開了 StreamAsync。和 StreamAsChannelAsync在 HubConnection 類別中。

使用 StreamAsync客戶端取得一個 IAsyncEnumerable 對象它代表伺服器發送的資料序列。開發者可以使用 `await foreach` 來處理每個到達的值，逐步加入展示邏輯、日誌記錄或資料操作。

如果您喜歡使用通道，請使用 StreamAsChannelAsync。返回一個 ChannelReader這樣，客戶端就可以等待資料可用（WaitToReadAsync），並在再次等待之前讀取所有已準備就緒的資料項目（TryRead）。這是一種等級稍低的模型，但可以更精細地控制讀取週期。

也可以將 CancellationToken 傳遞給這些呼叫。如果用戶端對 CancellationTokenSource 呼叫 Cancel 方法，則會向伺服器傳送訊號，表示用戶端正在呼叫 CancellationTokenSource。 在 Hub 方法中啟動對應的令牌使其能夠停止資料產生並以有序的方式關閉資料流。

對於從 .NET 到客戶端的串流傳輸，可以傳遞一個 IAsyncEnumerable。或 ChannelReader作為 SendAsync、InvokeAsync 甚至 StreamAsChannelAsync 呼叫中的參數。每次生成器函數產生元素或寫入資料到 ChannelWriter 時，伺服器都會在其輸入流中接收到該元素。

完成後，如果使用 IAsyncEnumerable，則當產生方法完成時，流程會自動完成；對於通道，則需要手動完成。 使用 Complete() 關閉寫入器與伺服器端的這種對稱性使得思考模型變得簡單：伺服器生產，客戶端消費，反之亦然。

使用 JavaScript 和 Java 中的 SignalR 進行串流傳輸

SignalR 不僅限於 .NET 生態系統：它還提供 JavaScript 和 Java 用戶端 支援串流傳輸，保持資料流的整體思路，但使其適應每種語言和環境的典型範式。

在 JavaScript 中，客戶端可以使用 `connection.stream` 呼叫伺服器到客戶端的串流方法。此方法接受 Hub 方法的名稱及其參數，並傳回一個公開了 `subscribe` 方法的物件。訂閱時，會提供 `next`、`error` 和 `complete` 回調，這與以下模式非常契合： 程序設計 激活.

每次伺服器傳送新資料項時，都會執行 `next` 函數。流程結束時，會呼叫 `complete` 函數；如果出現任何問題，則會處理錯誤回呼。如果用戶端想要停止接收數據，可以透過呼叫訂閱物件的 `dispose` 方法來取消訂閱，此操作也會將取消訂閱資訊傳遞給伺服器代幣。

在 JavaScript 的客戶端到伺服器串流中，Subject 物件被用作 send、invoke 或 stream 方法的參數。每次呼叫 subject.next(item) 都會向 Hub 的方法傳送一個新項，Hub 會在另一端接收該項。當客戶端呼叫 subject.complete() 時， 序列結束處已標明。 伺服器停止等待更多資料。

在 Java 中，SignalR 用戶端可以與 RxJava 生態系統或其他響應式方法無縫整合：HubConnection 的 stream 方法傳回一個 Observable 對象，然後可以使用 subscribe 方法定義 onNext、onError 和 onCompleted 事件。要從 Java 向伺服器發送流，只需傳遞一個要發送或調用的 Observable 物件（例如 ReplaySubject），使用 onNext 寫入元素，並使用 onCompleted 關閉流即可。

在所有情況下，模式都相同：.NET 伺服器使用 IAsyncEnumerable 或 ChannelReader 公開串流方法，而客戶端（無論是 .NET、JavaScript 或 Java） 它們連接到這些資料流，使用這些資料和/或產生資料。 遵循其所處環境的語言模式。

由於這種集成，我們在視訊和音訊領域看到的串流概念可以擴展到客戶端和伺服器之間傳輸的任何類型的資料：集合、訊息、狀態、日誌，或任何我們需要的資料。而這一切都得益於 .NET Streams、非同步性和現代響應式工具的強大功能。

了解串流的一般概念以及 .NET 如何透過 Streams 和 SignalR 實現串流傳輸，可以幫助您設計出更有效率的應用程式。 高效、反應迅速且可擴展能夠自然地處理連續的資訊流，而不是局限於舊的一次性請求和靜態回應模式。