4.2 拉流
5 最短回源路徑
6 業務系統
7 一些特性/問題
主要特性：
整體上這個系統是乙個典型的cdn結構，主要包含排程系統、cdn源節點和cdn邊緣節點。
節點服務列表：
服務功能
transfmtd
轉格式服務，主要負責webrtc的rtp流與rtmp流的互轉。
janus
webrtc流**服務，主要負責webrtc流的推、拉。
merge
合流服務，主要負責多個流的合流，用於使用mcu的場景。
segmentd
切片服務，用於推rtmp流時的轉封裝、切片，可以切成flv、hls、fmp4等格式。
controld
控**務，主要用於管理節點內的所有服務，流的管理，並負責與masterd服務的互動。
edged
邊緣服務，主要用於拉flv、hls、fmp4流。
所有節點內部的服務都由nginx**。
排程系統服務列表：
服務功能
named
流名服務，流名的生成、校驗。
masterd
主控服務，用於管理所有的節點，並自動生成最短回源路徑。
schedule
排程服務，用於管理使用者地域與節點的關係，管理流與節點的關係。
不同的推流模式由推流位址中攜帶的引數決定。
4.1.1 推webrtc
推流端請求named，請求、校驗流名，並獲得schedule位址；
推流端請求schedule，獲得地域、運營商匹配的推流janus；
推流端請求janus，開始推流；
janus請求controld，建立一路流，並開始傳輸rtp；
controld請求masterd，通知流資訊；
masterd請求schedule，通知流與節點資訊；
4.1.2 推rtmp
使用nginx rtmp模組接收rtmp流：
推流端請求named，請求、校驗流名，並獲得schedule位址；
推流端請求schedule，獲得地域、運營商匹配的推流位址；
推流端開始推流到推流位址，nginx rtmp模組收到rtmp流；
nginx 上的乙個自定義模組會請求segmentd服務，segmentd服務使用ffmpeg拉rtmp流並根據推流的引數進行切片；
segmentd請求controld，建立一路流，並開始傳輸切片資料(flv/hls/fmp4)；
controld請求masterd，通知流資訊；
masterd請求schedule，通知流與節點資訊。
4.1.3 推webrtc轉rtmp
推流端請求named，請求、校驗流名，並獲得schedule位址；
推流端請求schedule，獲得地域、運營商匹配的推流janus；
推流端請求janus，開始推流；
janus檢查推流引數判斷需要轉成rtmp，則請求transfmtd服務，傳遞sdp，開始進行轉換；
transfmtd使用ffmpeg，根據sdp以及轉換引數將rtp轉成rtmp，並推流給segmentd切片服務；
segmentd請求controld，建立一路流，並開始傳輸切片資料(flv/hls/fmp4)；
controld請求masterd，通知流資訊；controld請求masterd，通知流資訊；
masterd請求schedule，通知流與節點資訊；
4.1.4 推rtmp轉webrtc
推流端請求named，請求、校驗流名，並獲得schedule位址；
推流端請求schedule，獲得地域、運營商匹配的推流位址；
推流端開始推流到推流位址，nginx rtmp模組收到rtmp流；
nginx 上的乙個自定義模組會請求transfmtd服務，transfmtd服務使用ffmpeg拉rtmp流並根據推流的引數轉換成rtp；
transfmtd請求controld，建立一路流，並開始傳輸rtp；
controld請求masterd，通知流資訊；
masterd請求schedule，通知流與節點資訊。
4.1.1 拉webrtc
拉流端請求schedule，獲得地域、運營商匹配的拉流janus；
拉流端請求janus，開始拉流；
janus請求本地control，請求流資料，如果controld上已經快取該流，則直接返回資料，否則到5；
controld請求masterd，請求回源路徑，masterd將根據當前的整體網路路由狀態返回乙個最短路徑；
每個controld向路徑上的下一跳請求資料，直到請求到達某個命中的controld並返回資料，回源路徑上的所有controld都將快取該流。
4.2.2 拉flv/hls/fmp4
拉流端請求schedule，獲得地域、運營商匹配的拉流位址；
拉流端請求拉流位址，也就是edged，如果edged已經快取該流，則直接返回資料，否則到4；
edged請求本地control，請求流資料，如果controld上已經快取該流，則直接返回資料，否則到5；
controld請求masterd，請求回源路徑，masterd將根據當前的整體網路路由狀態返回乙個最短路徑；
每個controld向路徑上的下一跳請求資料，直到請求到達某個命中的controld並返回資料，回源路徑上的所有controld都將快取該流。
上面未涉及業務系統，業務系統主要包含：
延遲主要依賴於cdn的部署情況、使用者側的網路條件，據不完全測試，目前的端到端延遲可以達到250ms。
參考我這篇文章，在我們預設的業務環境下，所有平台端可以達到600ms的首開時間。
傳輸層面有以下加密措施。
直播為什麼不使用WebRTC？
webrtc直播現狀 現在使用webrtc技術的公司越來越多了，如果你密切關注直播領域的話，你會發現乙個很有趣的變化，隨著直播業務的增長，傳統的流 由於延時大不能滿足於各種應用場景的需求，一些可替代性的解決方案紛紛登場，而webrtc是這些技術解決方案中的佼佼者。目前很多數的公司使用webrtc做直...
直播軟體搭建技術原理 CDN 與直播
直播軟體搭建技術原理 cdn 與直播 很多直播都是基於 cdn 來實現的。而通過聲網的服務，或基於聲網sdk與 cdn 結合，還可以實現在直播中的連麥互動 白板同步等強調實時性的場景。本文源自社群投稿，介紹了該場景下的一些基礎知識。如大家存有疑問，可以與作者交流。所以為了確認範圍，可以先了解排查下b...
基於webrtc的資源釋放問題（一）
基於webrtc的資源釋放問題 一 重複釋放webrtc的相關資源 背景 最近一段時間在做基於webrtc的android應用在釋放資源時遇到一些問題，現在記錄下來用於備忘。1 釋放peerconnection資源的問題。現在b中終止通話 錯誤 在b終止通話之後，a端的程式程式會意外退出。分析 在a...