在janus中带族，websocket和 WebRTC之間是如何通信的

在 Janus 中，WebSocket 用于建立客戶端與服務(wù)器之間的連接蟀给，而 WebRTC 用于建立瀏覽器之間的實(shí)時(shí)通信蝙砌。具體來說，Janus 服務(wù)器會(huì)提供一個(gè) WebSocket 接口跋理，客戶端可以通過這個(gè)接口連接到服務(wù)器择克。連接建立后，客戶端可以向服務(wù)器發(fā)送命令前普，請(qǐng)求服務(wù)器執(zhí)行相應(yīng)的操作肚邢，例如創(chuàng)建一個(gè)新的房間、加入一個(gè)房間拭卿、發(fā)送一個(gè)消息等骡湖。

當(dāng)客戶端需要與其他瀏覽器建立實(shí)時(shí)通信時(shí)，Janus 服務(wù)器會(huì)扮演中轉(zhuǎn)的角色峻厚，將數(shù)據(jù)流從一個(gè)瀏覽器發(fā)送到另一個(gè)瀏覽器响蕴。具體來說，Janus 服務(wù)器會(huì)接收 WebRTC 的 ICE 交換信息惠桃，使用這些信息建立起 WebRTC 連接浦夷，并將數(shù)據(jù)流從一個(gè)瀏覽器傳遞到另一個(gè)瀏覽器辖试。這種中轉(zhuǎn)模式可以穿透防火墻、NAT 等網(wǎng)絡(luò)限制军拟，從而實(shí)現(xiàn)瀏覽器之間的實(shí)時(shí)通信剃执。Janus 還支持多種編解碼器和音視頻格式，可以適應(yīng)不同的場(chǎng)景需求懈息。

static struct janus_json_parameter incoming_request_parameters[] = { // 客戶端請(qǐng)求 Janus 服務(wù)器時(shí)所必須攜帶的信息肾档。
    {"transaction", JSON_STRING, JANUS_JSON_PARAM_REQUIRED},
    {"janus", JSON_STRING, JANUS_JSON_PARAM_REQUIRED},
    {"id", JSON_INTEGER, JANUS_JSON_PARAM_POSITIVE}
};

static struct janus_json_parameter attach_parameters[] = {
    {"plugin", JSON_STRING, JANUS_JSON_PARAM_REQUIRED}, // 加載的插件名稱，這是必須的參數(shù)
    {"opaque_id", JSON_STRING, 0}, // 用于標(biāo)識(shí)此次會(huì)話
    {"loop_index", JSON_INTEGER, JANUS_JSON_PARAM_POSITIVE}, // 此次會(huì)話的循環(huán)計(jì)數(shù)器
};

static struct janus_json_parameter body_parameters[] = { // 用于描述 Janus 協(xié)議中客戶端發(fā)送消息的參數(shù)
    {"body", JSON_OBJECT, JANUS_JSON_PARAM_REQUIRED}
};

static struct janus_json_parameter jsep_parameters[] = { // 用于描述 Janus 協(xié)議中客戶端發(fā)送的 SDP 信息
    {"type", JSON_STRING, JANUS_JSON_PARAM_REQUIRED}, // type 表示 SDP 的類型辫继， 這是必須的參數(shù)// audio：音頻流怒见、video：視頻流、application：應(yīng)用程序流姑宽、message：文本或二進(jìn)制消息流遣耍、data:數(shù)據(jù)量
    {"sdp", JSON_STRING, JANUS_JSON_PARAM_REQUIRED}, // sdp 表示 SDP 的內(nèi)容，也是必須的參數(shù)//協(xié)議版本(=)炮车、原點(diǎn)(=)舵变、
    {"trickle", JANUS_JSON_BOOL, 0},// 是否支持 Trickle ICE，是可選的參數(shù) // 啟用 Trickle ICE 可以加速 ICE 過程瘦穆，減少客戶端與服務(wù)器之間的延遲纪隙，提高 WebRTC 連接的建立速度
    {"rid_order", JSON_STRING, 0}, // 可選的 RTP 流 ID 順序，也是可選的參數(shù)//保證遠(yuǎn)端客戶端按照指定的順序接收到媒體流扛或，并正確解析其中的 RID
    {"force_relay", JANUS_JSON_BOOL, 0}, // 是否強(qiáng)制使用中繼绵咱，也是可選的參數(shù)
    {"e2ee", JANUS_JSON_BOOL, 0} // 是否啟用端到端加密，也是可選的參數(shù)
};

type:

audio：音頻流熙兔、video：視頻流悲伶、application：應(yīng)用程序流、message：文本或二進(jìn)制消息流住涉、data:數(shù)據(jù)量

sdp:

1麸锉、協(xié)議版本（v=）:描述 SDP 協(xié)議的版本號(hào)，一般為 0秆吵。
2淮椰、原點(diǎn)（o=）：描述會(huì)話的原點(diǎn)信息，包括用戶名纳寂、會(huì)話 ID主穗、版本號(hào)等。
3毙芜、會(huì)話名稱（s=）：描述會(huì)話的名稱忽媒。
4、時(shí)間描述（t=）：描述會(huì)話的起始時(shí)間和結(jié)束時(shí)間腋粥。
5晦雨、媒體描述（m=）：描述媒體流的類型架曹、端口號(hào)、傳輸協(xié)議等信息闹瞧。
6绑雄、媒體格式（a=rtpmap）：描述媒體流的格式，包括編碼器名稱奥邮、采樣率万牺、比特率等。
7洽腺、帶寬限制（b=）：描述媒體流的帶寬限制脚粟。
8、加密信息（a=）：描述媒體流的加密信息蘸朋，如加密算法核无、加密密鑰等。
9藕坯、會(huì)話層描述（a=）：描述會(huì)話層的特殊要求和限制团南，如目標(biāo)地址、傳輸速率等炼彪。

trickle： 是否支持Trickle ICE

Trickle ICE 是一種 ICE candidate 發(fā)送機(jī)制已慢，它允許 WebRTC 客戶端在 ICE 協(xié)商過程中逐步發(fā)送 ICE 候選地址，而不是等待所有候選地址收集完成后再一次性發(fā)送霹购。啟用 Trickle ICE 可以加速 ICE 過程，減少客戶端與服務(wù)器之間的延遲朋腋，提高 WebRTC 連接的建立速度齐疙。

如果開啟了 Trickle ICE，Janus 將在 ICE 協(xié)商期間持續(xù)收集和發(fā)送候選地址旭咽，直到所有候選地址都被收集到或者超時(shí)時(shí)間到達(dá)贞奋。如果不開啟 Trickle ICE，則需要等待所有候選地址都被收集到后穷绵，才會(huì)一次性將所有候選地址發(fā)送給遠(yuǎn)端客戶端轿塔。因此，開啟 Trickle ICE 可以縮短 WebRTC 連接的建立時(shí)間仲墨。

rid_order：

在 Janus WebRTC Gateway 中勾缭，rid_order 是用來控制傳輸 RID 的順序的字段。當(dāng)啟用了 rid_order 時(shí)目养，Janus 會(huì)按照 rid_order 中指定的順序?qū)?RID 進(jìn)行排序俩由，并將排序后的 RID 傳輸給遠(yuǎn)端客戶端。這個(gè)字段通常用于解決 Simulcast（多流發(fā)送）時(shí)的兼容性問題癌蚁，確保遠(yuǎn)端客戶端可以正確解析和處理多路媒體流幻梯。

例如兜畸，如果一個(gè)媒體流包含多個(gè) Simulcast Stream，并且每個(gè) Simulcast Stream 都有一個(gè)不同的 RID碘梢，但遠(yuǎn)端客戶端不支持 Simulcast咬摇，那么啟用 rid_order 就可以保證遠(yuǎn)端客戶端按照指定的順序接收到媒體流，并正確解析其中的 RID煞躬。

force_relay

在 WebRTC 中肛鹏，通過 ICE（Interactive Connectivity Establishment）協(xié)議協(xié)商建立對(duì)等連接時(shí)，當(dāng)兩個(gè)端點(diǎn)不能直接相互通信時(shí)汰翠，就需要借助一個(gè) TURN（Traversal Using Relays around NAT）/relay 服務(wù)器進(jìn)行數(shù)據(jù)傳輸龄坪。默認(rèn)情況下，WebRTC 會(huì)盡可能地嘗試直接建立對(duì)等連接复唤，只有在無法直接通信時(shí)才會(huì)使用 TURN/relay 服務(wù)器進(jìn)行中轉(zhuǎn)健田。

如果將 force_relay 參數(shù)設(shè)置為 true，就會(huì)強(qiáng)制 WebRTC 使用 TURN/relay 服務(wù)器進(jìn)行中轉(zhuǎn)佛纫，而不嘗試直接建立對(duì)等連接妓局。這通常用于解決網(wǎng)絡(luò)環(huán)境較差或者防火墻設(shè)置比較嚴(yán)格的情況下，確保 WebRTC 可以正常通信呈宇。但是居砖，強(qiáng)制使用 TURN/relay 服務(wù)器會(huì)增加數(shù)據(jù)傳輸?shù)难舆t钾腺，并增加 TURN/relay 服務(wù)器的負(fù)載。因此，應(yīng)該在必要時(shí)才使用 force_relay 參數(shù)镶柱。

e2ee

啟用 e2ee 參數(shù)后，Janus 將在媒體流的 SDP 中添加 SDES（Session Description Protocol Security Descriptions）加密參數(shù)蛹锰，用于指定加密算法和密鑰掌猛。Janus 還會(huì)協(xié)商出加密所需的密鑰，并將其發(fā)送給客戶端融虽，客戶端使用該密鑰進(jìn)行加密和解密享完。

需要注意的是，啟用端到端加密會(huì)增加通信的延遲和復(fù)雜度有额，并且可能導(dǎo)致一些附加的負(fù)載般又，因?yàn)榧用芎徒饷苄枰加?CPU 和網(wǎng)絡(luò)資源。因此巍佑，應(yīng)該在必要時(shí)才使用 e2ee 參數(shù)茴迁，例如在需要保護(hù)通信內(nèi)容不被竊聽或篡改的敏感場(chǎng)景下使用。

static struct janus_json_parameter add_token_parameters[] = {
    {"token", JSON_STRING, JANUS_JSON_PARAM_REQUIRED}, // 表示要添加的身份驗(yàn)證令牌萤衰，類型為 JSON_STRING笋熬。這是一個(gè)必需參數(shù)，必須在 API 調(diào)用中指定該參數(shù)的值
    {"plugins", JSON_ARRAY, 0} // 示要授權(quán)給該身份驗(yàn)證令牌的插件列表
};

static struct janus_json_parameter token_parameters[] = {
    {"token", JSON_STRING, JANUS_JSON_PARAM_REQUIRED}
};

static struct janus_json_parameter admin_parameters[] = {
    {"transaction", JSON_STRING, JANUS_JSON_PARAM_REQUIRED},
    {"janus", JSON_STRING, JANUS_JSON_PARAM_REQUIRED}
};

static struct janus_json_parameter mnq_parameters[] = { // 用于設(shè)置 Janus WebRTC Gateway 中的最小 NACK 隊(duì)列長(zhǎng)度
    {"min_nack_queue", JSON_INTEGER, JANUS_JSON_PARAM_REQUIRED | JANUS_JSON_PARAM_POSITIVE}
};

NACK 隊(duì)列是用于存儲(chǔ)未收到的 RTP 數(shù)據(jù)包的緩沖區(qū)腻菇，以便在收到后重傳胳螟。通過設(shè)置最小 NACK 隊(duì)列長(zhǎng)度昔馋，可以控制在什么時(shí)候開始重傳 RTP 數(shù)據(jù)包。如果 NACK 隊(duì)列中存儲(chǔ)的未收到的 RTP 數(shù)據(jù)包數(shù)量小于指定的最小值糖耸，則不會(huì)進(jìn)行重傳秘遏。

需要注意的是，設(shè)置最小 NACK 隊(duì)列長(zhǎng)度可能會(huì)影響 Janus 的性能嘉竟。如果將該值設(shè)置得太小邦危，則可能會(huì)導(dǎo)致 Janus 在重新傳輸 RTP 數(shù)據(jù)包時(shí)變得更加頻繁，從而降低系統(tǒng)的性能舍扰。建議根據(jù)實(shí)際需要設(shè)置該值倦蚪，以確保 Janus 在保證視頻質(zhì)量的同時(shí)保持良好的性能。

static struct janus_json_parameter nopt_parameters[] = { // 用于設(shè)置 Janus WebRTC Gateway 中的 NACK 優(yōu)化功能
    {"nack_optimizations", JANUS_JSON_BOOL, JANUS_JSON_PARAM_REQUIRED}
};

NACK 優(yōu)化是一種在傳輸 RTP 數(shù)據(jù)包時(shí)減少網(wǎng)絡(luò)延遲和帶寬使用的技術(shù)边苹。在啟用 NACK 優(yōu)化功能時(shí)陵且，Janus 會(huì)在向客戶端發(fā)送 RTP 數(shù)據(jù)包時(shí)使用一些技巧，以便在接收到 NACK 請(qǐng)求時(shí)能夠更快地重新傳輸 RTP 數(shù)據(jù)包个束。這可以減少 RTP 數(shù)據(jù)包的傳輸延遲和帶寬使用慕购，并提高視頻質(zhì)量。

需要注意的是茬底，啟用 NACK 優(yōu)化功能可能會(huì)增加 Janus 的 CPU 和內(nèi)存使用量沪悲。建議根據(jù)實(shí)際需要啟用或禁用該功能，以確保 Janus 在保證視頻質(zhì)量的同時(shí)保持良好的性能阱表。

NACK：

NACK（Negative Acknowledgment）是一種數(shù)據(jù)包確認(rèn)機(jī)制殿如，用于檢測(cè)和處理丟失的數(shù)據(jù)包。當(dāng)接收方檢測(cè)到缺失的數(shù)據(jù)包時(shí)最爬，它會(huì)向發(fā)送方發(fā)送 NACK 請(qǐng)求握截，以便重新發(fā)送缺失的數(shù)據(jù)包。NACK 通常用于 RTP 數(shù)據(jù)包傳輸烂叔，特別是在實(shí)時(shí)音視頻應(yīng)用程序中，如視頻會(huì)議固歪、直播和網(wǎng)絡(luò)電話中蒜鸡。

當(dāng)發(fā)送方接收到 NACK 請(qǐng)求時(shí)，它會(huì)重新發(fā)送缺失的數(shù)據(jù)包牢裳。如果接收方繼續(xù)檢測(cè)到缺失的數(shù)據(jù)包逢防，它將發(fā)送另一個(gè) NACK 請(qǐng)求，直到所有丟失的數(shù)據(jù)包都被重新發(fā)送為止蒲讯。通過這種方式忘朝，NACK 可以減少數(shù)據(jù)包丟失對(duì)實(shí)時(shí)音視頻質(zhì)量的影響，提高音視頻應(yīng)用程序的穩(wěn)定性和性能判帮。

需要注意的是局嘁，NACK 機(jī)制需要額外的帶寬和處理能力來處理丟失的數(shù)據(jù)包溉箕，因此在設(shè)計(jì)實(shí)時(shí)音視頻應(yīng)用程序時(shí)需要考慮到這一點(diǎn)。除了 NACK 之外悦昵，還有一些其他的機(jī)制和協(xié)議可以用于實(shí)時(shí)音視頻數(shù)據(jù)包傳輸肴茄，如 FEC（Forward Error Correction）和 RTX（Retransmission-based Transmission Control Protocol Extension）等。

static struct janus_json_parameter nmt_parameters[] = {
    {"no_media_timer", JSON_INTEGER, JANUS_JSON_PARAM_REQUIRED | JANUS_JSON_PARAM_POSITIVE}
};

static struct janus_json_parameter st_parameters[] = {
    {"slowlink_threshold", JSON_INTEGER, JANUS_JSON_PARAM_REQUIRED | JANUS_JSON_PARAM_POSITIVE}
};

slowlink_threshold

參數(shù)用于檢測(cè)會(huì)話中的網(wǎng)絡(luò)連接速度但指，如果連接速度過慢寡痰，則會(huì)通知應(yīng)用程序進(jìn)行相應(yīng)的處理，例如啟用 FEC棋凳、降低分辨率或幀率等拦坠。通過配置 st_parameters 參數(shù)，可以設(shè)置 Janus Gateway 中 slowlink_threshold 的值剩岳，以控制網(wǎng)絡(luò)連接速度的檢測(cè)閾值贞滨。

具體來說，st_parameters 參數(shù)中包含一個(gè)名為 slowlink_threshold 的整數(shù)值卢肃，該值表示網(wǎng)絡(luò)連接速度的檢測(cè)閾值疲迂，以 bps（比特/秒）為單位。當(dāng)檢測(cè)到連接速度低于 slowlink_threshold 時(shí)莫湘，Janus Gateway 將發(fā)送 slowlink 通知到應(yīng)用程序尤蒿，以便應(yīng)用程序進(jìn)行相應(yīng)的處理。應(yīng)用程序可以根據(jù)通知的內(nèi)容采取不同的行動(dòng)幅垮，例如啟用 FEC腰池、降低分辨率或幀率等，以保證良好的媒體流質(zhì)量忙芒。當(dāng)網(wǎng)絡(luò)連接速度低于 slowlink_threshold 時(shí)示弓，應(yīng)用程序可以采取以下措施：
1、 啟用前向糾錯(cuò)（FEC）：通過添加冗余數(shù)據(jù)來提高數(shù)據(jù)傳輸?shù)目煽啃院侨瑥亩鴾p少數(shù)據(jù)包的丟失奏属。
2、降低視頻分辨率和幀率：降低視頻分辨率和幀率可以減少數(shù)據(jù)傳輸量潮峦，從而減少網(wǎng)絡(luò)傳輸時(shí)的帶寬占用囱皿。
3、降低音頻采樣率和編碼質(zhì)量：降低音頻采樣率和編碼質(zhì)量可以減少音頻數(shù)據(jù)的大小忱嘹，從而減少網(wǎng)絡(luò)傳輸時(shí)的帶寬占用嘱腥。

static struct janus_json_parameter ans_parameters[] = {
    {"accept", JANUS_JSON_BOOL, JANUS_JSON_PARAM_REQUIRED}
};

用于指示是否接受 offer 請(qǐng)求并向遠(yuǎn)程對(duì)等方發(fā)送 answer 響應(yīng)。
在 WebRTC 中拘悦，answer 是在收到 offer 后創(chuàng)建的齿兔，以向?qū)Φ确矫枋隹捎糜诿襟w會(huì)話的本地媒體資源（例如音頻和視頻）。因此，通過接受或拒絕 offer 請(qǐng)求分苇，answer 將確定本地資源在 WebRTC 會(huì)話中的使用方式添诉。ans_parameters 參數(shù)數(shù)組中的 accept 參數(shù)用于控制對(duì) offer 請(qǐng)求的響應(yīng)，從而在媒體會(huì)話的交互中起到關(guān)鍵作用组砚。

static struct janus_json_parameter querytransport_parameters[] = {
    {"transport", JSON_STRING, JANUS_JSON_PARAM_REQUIRED},
    {"request", JSON_OBJECT, 0}
};

-==-=-=-=-=-=-=-=-=
DSCP（Differentiated Services Code Point）是一種用于網(wǎng)絡(luò)流量管理的QoS（Quality of Service）技術(shù)吻商。它通過為數(shù)據(jù)包頭部指定一個(gè)特殊的DSCP值來標(biāo)記不同類型的網(wǎng)絡(luò)流量，以便網(wǎng)絡(luò)設(shè)備可以優(yōu)先處理高優(yōu)先級(jí)的流量糟红，從而提高網(wǎng)絡(luò)的可靠性和性能艾帐。

DTLS（Datagram Transport Layer Security）是一種基于UDP（User Datagram Protocol）的安全傳輸協(xié)議，它提供了與TLS（Transport Layer Security）類似的加密和認(rèn)證機(jī)制盆偿，用于保護(hù)數(shù)據(jù)在不可信網(wǎng)絡(luò)上的傳輸安全性柒爸。DTLS-MTU指的是DTLS協(xié)議中的最大傳輸單元（MTU），即一次傳輸?shù)臄?shù)據(jù)包的最大長(zhǎng)度事扭。在DTLS通信中捎稚，由于UDP協(xié)議本身的限制，數(shù)據(jù)包的大小受到MTU的限制求橄，超過MTU的數(shù)據(jù)需要分片傳輸今野，會(huì)導(dǎo)致額外的延遲和開銷。因此罐农，了解DTLS-MTU的大小条霜，可以更好地優(yōu)化和管理DTLS通信的性能。

=-==-=-=-=-=-=-=-=-=-=-=-=-=--=-=-
"full trickle" ICE機(jī)制是一種用于NAT遍歷的技術(shù)涵亏，在WebRTC中經(jīng)常使用宰睡。

Full Trickle是一種ICE傳輸機(jī)制，可以提高ICE協(xié)商的速度和成功率气筋。

在常規(guī)的Trickle ICE中拆内，當(dāng)一個(gè)peer首次向另一個(gè)peer發(fā)出ICE候選項(xiàng)時(shí)，它只會(huì)發(fā)送一個(gè)宠默，然后等待回復(fù)麸恍。如果該候選項(xiàng)未能導(dǎo)致連接，則發(fā)送下一個(gè)候選項(xiàng)搀矫，然后等待回復(fù)抹沪。這個(gè)過程需要很長(zhǎng)時(shí)間，因?yàn)樾枰来螄L試每個(gè)候選項(xiàng)艾君，等待回復(fù)并決定下一個(gè)候選項(xiàng)。

Full Trickle可以一次性發(fā)送所有候選項(xiàng)肄方，從而大大縮短協(xié)商時(shí)間冰垄。當(dāng)有多個(gè)ICE候選項(xiàng)可用時(shí)，F(xiàn)ull Trickle可以通過在多個(gè)網(wǎng)絡(luò)接口（例如Wi-Fi和以太網(wǎng)）之間選擇最佳的候選項(xiàng)來提高成功率。

Full Trickle的工作流程如下：

客戶端發(fā)送包含所有候選項(xiàng)的ICE SDP offer虹茶。
服務(wù)器收到ICE SDP offer并決定最佳候選項(xiàng)逝薪。
服務(wù)器將選擇的候選項(xiàng)包含在ICE SDP answer中，然后將其發(fā)送回客戶端蝴罪。
客戶端收到ICE SDP answer董济，并在SDP中找到所選候選項(xiàng)。
客戶端使用所選的候選項(xiàng)建立連接要门。
Full Trickle相比常規(guī)的Trickle ICE可以更快地建立連接虏肾，并提高成功率，但它可能會(huì)增加帶寬使用和延遲欢搜。因此封豪，F(xiàn)ull Trickle通常用于網(wǎng)絡(luò)環(huán)境較好的情況下。

-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-
JSEP (JavaScript Session Establishment Protocol) offer 類型的消息炒瘟。JSEP 是一個(gè)用于建立 WebRTC 會(huì)話的協(xié)議吹埠，offer 和 answer 是其中的兩種類型。這段代碼首先將 offer 標(biāo)記為 true疮装，表示處理的是一個(gè) offer 消息缘琅。然后設(shè)置 JANUS_ICE_HANDLE_WEBRTC_PROCESSING_OFFER 和 JANUS_ICE_HANDLE_WEBRTC_GOT_OFFER 標(biāo)志位，表示正在處理一個(gè) offer廓推，并且已經(jīng)接收到了一個(gè) offer刷袍。同時(shí)清除 JANUS_ICE_HANDLE_WEBRTC_GOT_ANSWER 標(biāo)志位，表示還沒有接收到 answer 消息受啥。

-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-

FEC是Forward Error Correction（前向糾錯(cuò)）的縮寫做个，是一種數(shù)據(jù)傳輸錯(cuò)誤糾正技術(shù)。在FEC中滚局，發(fā)送方將原始數(shù)據(jù)加上冗余數(shù)據(jù)（也稱為冗余碼字或校驗(yàn)碼字）居暖，并一起發(fā)送給接收方。接收方在接收到數(shù)據(jù)時(shí)藤肢，通過校驗(yàn)冗余數(shù)據(jù)來恢復(fù)原始數(shù)據(jù)太闺。

FEC的實(shí)現(xiàn)方式有多種，最常見的是使用糾刪碼（Reed-Solomon Code）嘁圈。糾刪碼通過增加校驗(yàn)碼字省骂，使得在接收方收到的數(shù)據(jù)發(fā)生錯(cuò)誤時(shí)，可以通過校驗(yàn)碼字來檢測(cè)并糾正錯(cuò)誤最住。例如钞澳，如果發(fā)送方發(fā)送了一個(gè)包含10個(gè)數(shù)據(jù)塊和2個(gè)校驗(yàn)碼塊的數(shù)據(jù)包，接收方在接收到這個(gè)數(shù)據(jù)包時(shí)涨缚，如果發(fā)現(xiàn)其中1個(gè)數(shù)據(jù)塊有錯(cuò)誤轧粟，可以使用另外兩個(gè)校驗(yàn)碼塊來糾正該錯(cuò)誤，從而恢復(fù)原始數(shù)據(jù)。

FEC的優(yōu)點(diǎn)是可以提高數(shù)據(jù)傳輸?shù)目煽啃岳家鳎档蛿?shù)據(jù)丟失率通惫。與重傳機(jī)制相比，F(xiàn)EC可以在數(shù)據(jù)包丟失的情況下直接恢復(fù)原始數(shù)據(jù)混蔼，而不需要進(jìn)行重傳履腋，從而降低了網(wǎng)絡(luò)延遲和帶寬占用。因此惭嚣，F(xiàn)EC在實(shí)時(shí)傳輸應(yīng)用中得到了廣泛的應(yīng)用遵湖，例如視頻會(huì)議和流媒體等。

=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-
RTX（Retransmission TeXt）是一種基于RTP協(xié)議的重傳機(jī)制料按，用于解決網(wǎng)絡(luò)丟包等問題奄侠。RTX的通信原理與過程如下：

首先，發(fā)送方在RTP報(bào)文中添加RTX相關(guān)的信息载矿，包括原始媒體數(shù)據(jù)的SSRC（同步信源）標(biāo)識(shí)垄潮、重傳數(shù)據(jù)的新的SSRC標(biāo)識(shí)、以及原始媒體數(shù)據(jù)的序列號(hào)和時(shí)間戳闷盔。
接收方收到RTP報(bào)文后弯洗，根據(jù)報(bào)文中的信息進(jìn)行處理。如果發(fā)現(xiàn)丟失了某個(gè)報(bào)文逢勾，則發(fā)送NACK（Negative ACKnowledgement）給發(fā)送方牡整，告訴其需要重傳丟失的報(bào)文。
發(fā)送方接收到NACK后溺拱，根據(jù)其中的信息逃贝，重傳相應(yīng)的報(bào)文。這些重傳的報(bào)文以原始媒體數(shù)據(jù)的SSRC標(biāo)識(shí)為SSRC迫摔，以重傳數(shù)據(jù)的新的SSRC標(biāo)識(shí)為PT（Payload Type）值沐扳，以原始媒體數(shù)據(jù)的序列號(hào)和時(shí)間戳為基礎(chǔ)，重新生成RTP報(bào)文并發(fā)送給接收方句占。
接收方收到重傳的報(bào)文后沪摄，根據(jù)其序列號(hào)和時(shí)間戳進(jìn)行排序和處理，并進(jìn)行后續(xù)的媒體處理纱烘。
需要注意的是杨拐，RTX只能重傳最近發(fā)送的幾個(gè)RTP報(bào)文，因此如果發(fā)送方發(fā)送數(shù)據(jù)的速度過快擂啥，可能會(huì)導(dǎo)致某些報(bào)文已經(jīng)被清除哄陶，無法進(jìn)行重傳。此外哺壶，RTX也會(huì)帶來一定的延遲和帶寬開銷屋吨，因此需要根據(jù)具體情況進(jìn)行權(quán)衡和選擇舱痘。

-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-

在janus庫中，ice.c文件中的這段代碼定義了一個(gè)名為twcc_period的變量离赫，它的作用是指定TWCC（Transport Wide Congestion Control）周期的默認(rèn)值為200ms。TWCC是一種流量控制機(jī)制塌碌，用于幫助在網(wǎng)絡(luò)擁塞情況下保持流量穩(wěn)定渊胸，提高實(shí)時(shí)通信質(zhì)量。

在Janus中台妆，twcc_period的值將用于確定TWCC報(bào)告的發(fā)送頻率翎猛。默認(rèn)情況下，Janus每200ms發(fā)送一次TWCC報(bào)告接剩，以便及時(shí)地檢測(cè)網(wǎng)絡(luò)擁塞情況切厘，并相應(yīng)地調(diào)整傳輸速率，以避免在實(shí)時(shí)通信過程中出現(xiàn)質(zhì)量下降或丟包等問題懊缺。

在ice.c文件中疫稿，通過定義DEFAULT_TWCC_PERIOD和twcc_period變量，可以方便地修改TWCC周期的默認(rèn)值鹃两，并通過twcc_period變量在代碼中引用遗座，以確保TWCC報(bào)告的發(fā)送頻率與所需的實(shí)時(shí)通信質(zhì)量相匹配。

-=-=-=-=-=-=-=-=-=--=-=-=-=-=-
在Janus庫的ice.c文件中俊扳，這段代碼定義了三個(gè)宏：

DEFAULT_MIN_NACK_QUEUE：指定NACK隊(duì)列/重傳的最小值途蒋，單位為毫秒，默認(rèn)為200毫秒馋记。
DEFAULT_MAX_NACK_QUEUE：指定NACK隊(duì)列/重傳的最大值号坡，單位為毫秒，默認(rèn)為1000毫秒梯醒。
MAX_NACK_IGNORE：指定重傳后最大的忽略計(jì)數(shù)宽堆，單位為微秒，默認(rèn)為200000微秒（即200毫秒）冤馏。
這些宏的作用是為了幫助調(diào)節(jié)Janus庫在丟包情況下進(jìn)行重傳的行為日麸。當(dāng)Janus檢測(cè)到有數(shù)據(jù)包丟失時(shí)，它將會(huì)在NACK隊(duì)列中等待一段時(shí)間（DEFAULT_MIN_NACK_QUEUE）逮光，以等待丟失的數(shù)據(jù)包到達(dá)代箭。如果這段時(shí)間內(nèi)沒有收到數(shù)據(jù)包，則Janus將會(huì)發(fā)送NACK請(qǐng)求涕刚，要求重新發(fā)送數(shù)據(jù)包嗡综。在DEFAULT_MIN_NACK_QUEUE到DEFAULT_MAX_NACK_QUEUE之間，Janus會(huì)進(jìn)行一系列的NACK和重傳杜漠，以盡量保證數(shù)據(jù)的完整性极景。

而MAX_NACK_IGNORE則指定了一個(gè)時(shí)間上限察净，當(dāng)重傳次數(shù)達(dá)到一定數(shù)量后，Janus將停止進(jìn)行重傳盼樟，并認(rèn)為數(shù)據(jù)包已經(jīng)永久丟失氢卡。這個(gè)時(shí)間上限的設(shè)置是為了避免Janus在某些極端情況下陷入死循環(huán)，同時(shí)也可以幫助控制網(wǎng)絡(luò)擁塞和延遲晨缴，提高通信質(zhì)量译秦。