一：Mediasoup庫的JS部分（與C++交互）
整個Mediasoup庫通過Nodejs管理，比如整體邏輯、worker、router、producer、consumer...都是通過JS進行管理的。
其底層的數據傳輸是通過C++部分進行控制的，通過NodeJs來控制C++部分，以實現整體的數據傳輸效果。
（一）Mediasoup JS目錄---調用底層C++進行通訊
AudioLevelObserver.js 檢測聲音大小,通過C++部分測量出聲音之后，返回給該js文件中的對象，再返回給應用層展示音量
Channel.js 與C++部分進行信令通訊
Consumer.js 消費者
DataConsumer.js
DataProducer.js
DirectTransport.js
EnhancedEventEmitter.js EventEmitter的封裝，事件的處理
errors.js 錯誤信息
index.js mediasoup庫的索引
Logger.js 日志管理
ortc.js 與SDP對應，以對象的方式描述SDP信息
PayloadChannel.js
PipeTransport.js Worker之間router之間數據流的轉發
PlainTransport.js 普通的RTP數據傳輸通道
Producer.js 生產者
Router.js room相關操作
RtpObserver.js RTP觀察者
RtpParameters.js
scalabilityModes.js
SctpParameters.js
SrtpParameters.js
supportedRtpCapabilities.js 能力支持相關，媒體協商相關
Transport.js 所有transport的基類
types.js
utils.js 常見的工具函數
WebRtcTransport.js 瀏覽器使用的傳輸
Worker.js 進程
（二）Mediasoup JS類關系圖
1.幾乎所有類都繼承自EnhancedEventEmitter，每個對象都可以發送事件
2.每個worker代表一個節點，內部有多個Router，組成Routers結構。每個Worker中都有一個channel，與C++進行通訊
3.對於每一個Router房間來說，是包含Tranports和Produces
4.Transport包含Produces與Consumes，其包括多個子類，如WebRtcTransport（瀏覽器數據傳輸）、PlainRtpTransport（非音視頻）、PipeTransport（不同router之間數據流轉）
（三）Mediasoup JS作用
（四）實例createRouter：應用層-->JS層-->C++層
1.await this._channel.request('worker.createRouter', internal);
傳入字符串和參數，在request中構建json數據，傳給C++層
2.new Router在JS層產生邏輯關系，進行管理
二：Mediasoup C++庫類關系（核心）
包括基本管理，比如：流傳輸，數據加解密，數據安全驗證，流數據流轉，帶寬評估...
（一）Mediasoup核心類關系圖（與JS類圖相似）
1.最核心是Router類，房間概念，包含Consumer、Producer，Transport子模塊，關系對應1：n
2.Consumer中含有多種子類，如：SimpleConsumer（音視頻流）、PipeConsumer（Router之間數據流轉）、SvcConsumer（分層、增量）、SimulcastConsumer（分層）
3.Producer，接收共享者傳輸的流
4.Transport分為3種，同前面JS介紹一致，TransportTuple元組存放本地socket、遠端socket、IP、端口
（二）Mediasoup核心類關系詳細圖
1.對於4種消費者，都包含RtpStreamSend對象，消費者發送數據給客戶端，通過RtpStreamSend方法。RtpStreamSend繼承自RtpStream，這個類處理Rtp數據流的收發。RtpStream使用到了RtpPacket，這個包是用於對Rtp數據包的分析，Rtp數據有數據包頭，對於包頭每一個字段的定義都是在這個Packet里面操作的
2.因為要對整個數據進行處理，所以使用SeqManager，序列管理器。服務端推送給客戶端的數據流是會重新排序的，排序的時候便會依靠這個SeqManager，它會記錄某個SSRC所對應的Sequence，以此為起始位置，然后后面的每個包都向下遞增一個數
3.Producer作為服務端的生產者，它是用來接收共享者發送的數據流，所以它里面包含多個RtpStreamRecv，是一對多的關系（為什么是多個RtpStreamRecv呢？因為數據的接收有可能會丟包，丟包重傳的也算作一路流，對應的音頻的丟包也是需要重傳）
4.作為數據的接收端，RtpStreamRecv使用到了NackGenerator丟包產生器。接收端能夠知道有沒有丟包，因為數據包有Sequence，比如發送了100個數據，前50個數據是連續的，但假設當50之后是55，Recv端就知道丟了 51、52、53、54 這4個包了。丟包之后如何解決呢，有兩種方式：
-
Fec：在每個包增加一些冗余，它能計算 出丟失的音頻包或視頻包
-
Nack：它會告訴發送端丟了哪些包，發送端會根據策略，若時間比較短的話，會把丟失的包補上來，具體補哪些包就是根據NackGenerator產生的
5.Transport分為3種，WebRtcTransport（瀏覽器數據傳輸）、PlainRtpTransport（非音視頻）、PipeTransport（不同router之間數據流轉）。TransportTuple元組存放本地socket、遠端socket、IP、端口
6.最核心的是WebRtcTransport，與瀏覽器進行數據傳輸。首先其包含UdpScoket與TcpServer對應兩個鏈接，可以與客戶端連接通信
7.對於UdpSocket與TcpServere，其繼承自PortManager端口管理器，對於Mediasoup來說，默認是從40000到49999共一萬個端口號。UdpSocket和TcpServer通過PortManager進行對端口號的管理，首先確定端口號有沒有被占用，沒有被占用就使用該端口號對數據傳輸；若被占用，就根據PortManager的策略往后跳。注意Udp和Tcp的使用是互斥的
8.DtlsTransport：使用dtls對Rtp包進行數據加密的協議，同時在這里面還使用到了Srtp協議，Srtp協議分為數據的收與發，所以在WebRTCTransport中有Srtp send和recv這兩個Session
9.RembClient/RembServer：這兩個主要用於對帶寬的評估，既可用於client端也可用於server端。對於共享者來說，Mediasoup的WebRTCTransport就是RembClient端；對於消費者來說，就是RembServer端
10.IceCandidate：候選者包括Host、Server reflexive、Relay reflexive三種，對於WebRTC一般設置成Host，最高優先級
11.IceServer包括證書驗證、指紋識別等一系列安全驗證機制，它里面也包含了多個TransportTuple
12.TransportTuple：如果使用TCP連接，它里面便含有TcpConnection