WebRTC DataChannel流量/控制/背壓

RTCDataChannel API不提供任何類型的流量/控制或背壓，這是否意味着發件人理論上可能會使接收器的瀏覽器崩潰？在我看來，瀏覽器（Chrome，Firefox等都使用SCTP），從SCTP連接讀取數據並調度運行js回調消費數據包。如果事件隊列不能跟上發送者，瀏覽器基本上會連續讀取數據包，同時將數據包存儲在無限期增長的緩衝區中。所以當你連接兩個瀏覽器時，發送者實際上可能總是壓倒另一個瀏覽器，因爲沒有像TCP接收窗口或類似的東西的障礙。WebRTC DataChannel流量/控制/背壓

這也適用於websocket api。

我只是錯過了一些東西，或者這些API只是壞了嗎？如果我是對的，那麼在與未經身份驗證的瀏覽器進行交流時（例如在某種情況下），這將是一個嚴重的安全問題。

來源

2014-11-21 Kr0e

我會假設瀏覽器中的底層代碼會考慮到這一點，但你知道當你做出一個假設時會發生什麼...... – 2014-11-21 14:06:55

僅供參考：另一種方式也會產生問題。如果您嘗試發送數據，則可以儘可能快地發送。數據在內部進行緩衝。但是在某些時候，由於網絡無法跟上緩衝數據，因此您將耗盡內存。 WebRTC提供了bufferedamount信息，但這意味着您必須輪詢此變量以將緩衝區大小保持在高水位和低水位。瘋狂...這似乎只是破（或至少沒有完全想通） – Kr0e 2014-11-21 14:42:41

webrtc數據通道過去基於UDP。在此期間，瀏覽器實施了人工調節，以防止網絡氾濫。在我相信chrome v32之前，情況就是如此。如今的數據通道基於內置流量控制（FC）的SCTP，並且不再有瀏覽器節流（感謝上帝）。控制FC的參數不通過API公開，但這並不意味着沒有FC。

我不熟悉Chrome/FF中webrtc的實現，但我不認爲你可以通過簡單的洪水攻擊來使瀏覽器崩潰。「生產者比消費者更快」是一個相當古老的問題。

這就是說，我一直在使用數據通道，一年多的時間裏，我的瀏覽器崩潰幾乎每天都在發生，所以webrtc實現中可能存在很多錯誤。希望他們不會對安全構成任何線索。

發送使用webrtc數據通道的大塊數據並不是特別愉快的體驗。 API不提供「準備好寫入的通道」回調或類似的任何內容，所以，是的！您必須輪詢bufferedamount值，並嘗試將其保留在最佳窗口內。爲了增加侮辱傷害bufferedamount曾經在Windows版本的Chrome中被破壞，它始終是0.但我認爲他們在chrome v37或大約那段時間修復了這個問題。

恕我直言，webrtc API並沒有很好地思考，但它做的工作，老實說，我想不出任何通過深思熟慮的js API。

來源

2014-11-23 12:53:35

我明白了。據我所知，SCTP的實現絕對可以控制流量，但它只適用於瀏覽器內核。如果瀏覽器內核讀取速度不夠快，那麼是的。但瀏覽器必須繼續閱讀，因爲連接到同一主機的每個數據通道都由單個SCTP連接複用。因此，瀏覽器無法確定下一個數據包專用於哪個數據通道。 – Kr0e 2014-11-23 14:12:07

想象一下一個應用程序，它打開一個數據通道並讓用戶選擇一個目錄來存儲數據。如果用戶等待，另一方應該能夠繼續發送數據，這些數據必須由js應用程序處理。該應用程序不能說「停止它」！我希望他們真的在後面的版本中考慮這個問題。 – Kr0e 2014-11-23 14:12:41

如果「生產者」無意識地發送數據，而且「消費者」無法以任何理由消費它，那麼雙方的緩衝區將開始增加。然而發送端的緩衝區不能永遠增加。經過一定的閾值（我認爲它是幾兆字節）後，數據通道將被強制關閉，並丟棄所有緩衝數據。 – 2014-11-23 17:55:13

WebRTC DataChannel流量/控制/背壓

回答

相關問題