webrtc直播現狀
現在使用webrtc技術的公司越來越多了，如果你密切關注直播領域的話，你會發現乙個很有趣的變化，隨著直播業務的增長，傳統的流**由於延時大不能滿足於各種應用場景的需求，一些可替代性的解決方案紛紛登場，而webrtc是這些技術解決方案中的佼佼者。目前很多數的公司使用webrtc做直播的架構圖是採用圖1中的結構：
如何使用webrtc來做直播？
這個架構還是借助傳統直播的方案，只是利用了webrtc的特性將推流端到服務端之間的流傳進行優化，這樣做的最大問題是服務端的效能消耗和直播分發的延時，我們知道類似hls這樣的協議通常延時在15s+。
而當前這種架構不能勝任實時直播的工作，因為在傳統直播架構中快取，分片等設計方式保障了直播的流暢性，但是卻犧牲了直播的實時性。
webrtc能做什麼
由於傳統直播方案無法應對低延時直播場景，這就是為什麼需要乙個全新的直播架構，當然低延時和實時性是必需的。但是由於乙個協議的標準化和實施需要很長時間，因此目前最佳的可選方案就是webrtc，今年(2023年6月)webrtc 1.0規範正式發布，各大廠商均表現出很高的積極性，而且現在大多數瀏覽器中已經原生支援，這對webrtc未來更加廣泛的應用打下了非常夯實的基礎。
圖2是webrtc做直播的架構，所有的流**都會走webrtc通道，這樣可以保證整個流**從推流端到**端的每個環節都能使用webrtc的特性。
當然使用webrtc做直播有很多難點需要攻克，廣播伺服器需要具備大容量，大併發，低延時，可動態伸縮，可災備等一些列高階特性，而不僅僅是簡單的**流**。
要做到這些，我們需要乙個完全不同的伺服器架構來實現webrtc流**的**，這與當今市場上的一些方案（開源和商業方案）有所不同。因為現有的方案伺服器上的webrtc實現幾乎是背靠背的實現——它們在服務端對每個連線模擬乙個完整的客戶端來接收或**webrtc的**流。這樣實現沒有問題，但是它很難應對上千、幾萬或數百萬的大併發連線。
anyrtc如何實現
anyrtc一直主推webrtc技術方案對原有的直播系統進行公升級改造。anyrtc採用的是微服務分離架構，流**服務只對信令和**包進行**，這些我們定義為輕任務；而類似**處理、編譯碼等重任務由單獨的業務服務進行處理。
同時服務端之間的流分發如何保障低延時，單機最大容量，系統容災，**流過防火牆，跨國分發流，流路徑跟蹤等等一些列問題也需要考慮。由於篇幅有限這些問題我們將在後續的文章中再做詳細討論。
結語那麼直播為什麼不使用webrtc呢，其中的緣由很多，可能是覺得webrtc方案還不夠成熟，可能是因為技術難度較高實現較複雜，可能是因為需求不迫切，可能你認為這本身就是偽命題，也有可能是因為你還不知道。無論因為什麼原因，webrtc近幾年的發展勢頭都是不能夠忽略的，不久的將來webrtc會在更多場景中廣泛應用，而不僅僅是直播行業。
人們為什麼不使用Python3？
關於python 3 python 社群的朋友和開發者們，咱們一起聊聊python3吧。python3在2008年12月3日首次發布。當時廣泛的說法是 程式設計師接受python3將是乙個漫長的過程，這個過程被預期為五年。現在，我們剛剛度過了這個標誌性的5年。在python 3發布起初以及隨後的幾年...
直播行業為什麼要使用TTCDN？
1.直播平台突發性的流量增長成為常態，短時間內如何擴容扛過流量高峰，成為各大網路直播平台必須正視的問題。尤其是在移動直播領域，無線網路和移動寬頻在穩定性方面無法與固定寬頻比擬，cdn及雲服務商的技術支援已經成為當下直播平台在內容傳播層面最重要的保障，同時也為其拓展業務形態保駕護航。2.直播一直對網路...
進擊的WebRTC 我們為什麼需要它？
有人說 2017 年是 webrtc 的轉折之年，2018 年將是 webrtc 的爆發之年。去年，webrtc 1.0 標準草案出爐，並將於今年正式發布。與此同時，越來越多的瀏覽器和廠商都開始對它進行廣泛的支援，webrtc 即將成為網際網路的基礎設施了。越來越多的創業者都在思考如何將線下互動的場...