用於通過多個套接字發送流數據的協議

Question

我正在設計一個用於從應用程序中消耗消息的API，該應用程序將生成大量的數據;即使對於較小的客戶，也可能有10+ GB/s。我正在尋找一種協議，使我能夠以易於客戶使用的方式提供這些數據。

對我來說，顯而易見的答案是：拆分消息，以便通過多個連接消耗。每個連接將佔用整個負載的一小部分。

但如果我這樣做，有幾件事我需要考慮：

• 用戶如何知道自己是落後的，需要推出更多的連接？
  • 微博說consumers should check timestamps，這可能對我們
• 工作，當他們推出一個新的連接要消耗更多的數據，他們如何指定這是同一消費會話的一部分？
  • 我們可以給會議的名稱，關聯與一個"direct" amqp queue，並讓我們的隊列做的辛勤工作
• 有我丟失的東西很重要。
  • 也許吧。

出於這個原因，我寧願一個已經存在的協議。

該協議將被視爲額外真棒，如果它：

• 是網頁套接字或流式HTTP友好
• 支持數據壓縮

Answer 1

你所描述的問題是幾乎相同視頻流必須處理的問題，你可能已經知道了。關鍵的HTTP友好流媒體協議是HLS（Apple），SmoothStreaming（微軟），HDS（Adobe）和MPEG-DASH（開放協議，但是新的）。

在考慮視頻流時，也值得了解您的數據流是更像是「實時」流還是「靜態」內容 - 前者是即時生成的，並且實時流的任何給定部分可能僅適用於一個集合的時間，而後者存儲在服務器上的全部和一般任何部分都可以在任何時候（直到內容被刪除）。如何流式傳輸和播放這些內容有細微的差別。

這可能是因爲您可以簡單地重複使用上述視頻流協議之一，方法是將數據包裝爲視頻（或者甚至是視頻），然後在接收端實現您自己的自定義客戶端。

另外，如果您想創建自己的更簡單的協議，這些協議可以提供一個很好的參考點 - 有幾個開源流媒體服務器，您可以尋找想法，甚至適應您的需求，如果這看起來像一個明智的路線：

• http://gstreamer.freedesktop.org
• http://icecast.org

視頻流媒體是相當複雜的，因爲你可能已經知道，但如果你的用例是簡單的，你可能能夠忽略或消除大部分複雜性 - 例如，您可能不需要查找，多格式和比特率流，伴隨流（用於字幕等）。如果能夠這樣簡化，可能需要努力根據您的需求修改上述內容之一，如果您無法使用它們即可。

最後一點 - 視頻和音頻流協議通常具有處理延遲或丟失數據包的內置方式。根據您的應用程序，這些可能不適用於您，因此如果重新使用視頻或音頻流協議或服務器，您應仔細查看此方面。例如，音頻客戶端通常容忍少量的數據包丟失，並且通常會丟棄延遲的數據包，而不是暫停音頻（在'抖動緩衝區'窗口外接收的數據包）。如果您的應用程序無法容忍任何數據包丟失，那麼您需要仔細查看底層解決方案和協議，以確保它確實滿足您在所有網絡條件下的需求。