1. GCC是如何進行帶寬評估的

GCC（Google Congestion Control）是一種專為實時音視頻傳輸設計的擁塞控制算法，它主要通過發送端和接收端的協同工作來進行帶寬評估。具體過程如下：
接收端處理
計算延遲梯度：接收端通過統計數據包到達時間的變化，即RTT（往返時間）波動，來計算網絡中的排隊延遲，這個排隊延遲的變化率就是延遲梯度。例如，若連續多個數據包的到達時間間隔逐漸增大，說明排隊延遲在增加，延遲梯度為正且數值可能逐漸變大。
反饋信息：接收端將計算得到的延遲梯度和丟包信息封裝到 ACK（確認）報文中，反饋給發送端。這些信息將作為發送端調整發送速率和進行帶寬評估的重要依據。
基于延遲的帶寬估計（部分版本）：在 REMB - GCC 版本中，接收端會通過一系列模塊進行基于時間延時梯度的帶寬評估。其中，Arrival filter 利用卡爾曼濾波器，通過測量得到的相鄰兩幀接收時間差和發送時間差的間隔（dm_i）以及兩相鄰包的大小差（dL_i），估算出網絡隊列延時深度變化估計（m_i）。Adaptive threshold 模塊根據 m_i 定時更新閾值 γi，Overuse Detector 模塊再根據 m_i 和 γi 評估當前網絡是否處于過載狀態，最后 Remote Rate Controller 模塊根據網絡過載狀態調整帶寬，并通過 REMB RTCP 包反饋到發送端。

發送端處理
基于丟包的帶寬估計：發送端根據從接收端反饋的 RTCP 協議的 Receive Report 包中的 lost fraction 字段獲取丟包率。當丟包率大于 10% 時，認為網絡有擁塞，降低帶寬；當丟包率小于 2% 時，認為網絡狀況好，向上提高 5% 的帶寬以探測是否有更多帶寬可用；丟包率在 2% 到 10% 之間時，保持當前碼率不變。
帶寬估計與速率控制：發送端持續測量網絡的可用帶寬，具體是通過接收端 ACK 的到達速率來維護一個帶寬估計值（BtlBw）。結合接收端反饋的延遲梯度信號，發送端動態調整發送速率。若延遲梯度增大，表明網絡擁塞，發送端降低發送速率；若帶寬估計提升且延遲穩定，發送端則嘗試增加速率以充分利用帶寬。
帶寬探測：發送端會通過發送 probe 數據包來探測網絡帶寬。發送端發送出 probe cluster（探測包集群），接收端通過 transport - wide congestion control rtcp feedback message（傳輸層擁塞控制 RTCP 反饋消息）告知發送端每個數據包的到達時間。發送端根據這些反饋，調用 probe bitrate estimator::handle probe and estimate bitrate 函數來計算探測包集群的發送間隔、接收間隔、發送速率和接收速率等。若接收速率明顯低于發送速率，說明可能達到了鏈路的真實容量，此時會將目標比特率設置得稍低一些。

2. udp在什么場景下連不通

UDP（用戶數據報協議）是一種無連接、不可靠的傳輸層協議，其 “連不通” 通常表現為數據包丟失、無法到達目標或通信中斷。這種情況可能由多種網絡環境、協議特性或配置問題導致，以下是常見的場景及原因分析：

一、網絡層或鏈路層故障
UDP 依賴底層網絡（如 IP 層、鏈路層）的正常工作，底層故障會直接導致通信失敗：
- 路由不可達：目標主機的 IP 地址在網絡中沒有有效路由（如路由表配置錯誤、跨網段通信缺少網關），數據包在傳輸過程中被丟棄，無法到達目標。
- 鏈路中斷：物理鏈路（如網線斷開、無線信號丟失）或數據鏈路層協議（如以太網沖突、PPP 鏈路斷開）故障，導致數據包無法在鏈路上傳輸。
- MTU 不匹配：若 UDP 數據包大小超過路徑 MTU（最大傳輸單元）且未開啟分片（或分片后重組失敗），數據包會被中間路由器丟棄。例如，發送一個 1500 字節的 UDP 包到 MTU 為 1400 的網絡，且未分片時，包會被直接丟棄。

二、防火墻或安全策略攔截
UDP 無連接的特性使其更容易被防火墻攔截，這是實際應用中 “連不通” 的常見原因：
- 端口過濾：目標主機或中間防火墻（如路由器、企業防火墻）配置了端口封鎖策略，攔截了 UDP 目標端口（如未開放 5060 端口導致 SIP 協議通信失敗）。
- 協議禁用：部分嚴格的安全策略會直接禁用 UDP 協議（如某些內網為防止 DDOS 攻擊，禁止所有 UDP 流量），導致所有 UDP 數據包被攔截。
- 狀態檢測防火墻的限制：部分狀態檢測防火墻對 UDP 的 “無狀態” 特性不友好，若未配置 UDP 會話超時規則，可能誤判 UDP 流量為非法并攔截（如短暫通信后被防火墻切斷）。

三、網絡擁塞或 QoS 限制
- 擁塞丟包：UDP 不具備 TCP 的擁塞控制機制，在網絡擁塞時，路由器會優先丟棄 UDP 包（因 TCP 會重傳，而 UDP 丟包后無補救），導致通信中斷。例如，視頻會議的 UDP 流在網絡繁忙時可能頻繁卡頓甚至斷開。
- QoS（服務質量）優先級低：若網絡設備配置了 QoS 策略，UDP 流量可能被分配到低優先級隊列，當帶寬不足時，低優先級 UDP 包會被優先丟棄，導致 “連不通” 或丟包嚴重。

四、目標主機問題
- 端口未監聽：目標主機的 UDP 端口未被應用程序監聽（如服務未啟動、端口被占用），數據包到達后無進程處理，且不會返回任何響應（UDP 無 “連接失敗” 通知），表現為 “連不通”。
- 主機不可達：目標主機斷電、崩潰或處于離線狀態，數據包無法送達，此時可能收到 ICMP “目標不可達” 消息（但非所有場景都會返回）。

五、NAT 或代理的影響
- NAT 會話超時：在私有網絡（如家庭 WiFi）通過 NAT 訪問公網時，NAT 設備會為 UDP 會話維護臨時映射表。若 UDP 通信間隔超過 NAT 超時時間（通常幾十秒到幾分鐘），映射表被刪除，后續數據包會被 NAT 丟棄，導致通信中斷（如 VoIP 通話長時間靜音后斷線）。
- 代理服務器限制：部分代理服務器（如企業內網代理）可能不支持 UDP 轉發，或對 UDP 端口、流量大小有限制，導致數據包被代理攔截。

六、協議自身特性導致的 “感知不到的不通”
UDP 無確認機制，即使數據包丟失，發送端也不會收到通知，可能被誤認為 “連不通”：
例如，發送端向目標 UDP 端口發送數據，但數據包在傳輸中丟失，發送端無法得知失敗，僅表現為 “沒有響應”，類似 “連不通” 的效果。
若目標主機收到數據包但處理出錯（如應用程序崩潰），也不會返回錯誤信息，發送端同樣感知不到通信成功。

3. SDP 里面存儲了哪些內容

SDP（Session Description Protocol，會話描述協議）是一種用于描述多媒體會話的格式，主要用于協商會話的參數（如媒體類型、編碼格式、傳輸協議、網絡地址等），以便不同設備或應用之間建立多媒體通信（如音視頻通話、流媒體傳輸等）。

SDP 存儲的核心內容
SDP 由一系列 “鍵 = 值” 形式的字段組成，按功能可分為會話級描述（整個會話的通用信息）和媒體級描述（每個媒體流的具體信息），核心內容包括：
1. 會話級描述（適用于整個會話）

• v=：SDP 版本號（目前固定為 0）。
• o=：會話發起者信息，包括用戶名、會話 ID、會話版本、網絡類型（通常是 IN 表示互聯網）、地址類型（IP4 或 IP6）、發起者 IP 地址。
• s=：會話名稱（如 “視頻會議 - 項目組周會”）。
• i=：會話描述信息（可選，如會話的詳細說明）。
• u=：會話相關的 URI（可選，如會議的網頁鏈接）。
• e=：會話聯系人郵箱（可選）。
• p=：會話聯系人電話（可選）。
• c=：連接信息，包括網絡類型、地址類型、連接地址（如 IP 地址），可被媒體級描述覆蓋。
• b=：帶寬限制（可選，如會話的總帶寬）。
• t=：會話的開始和結束時間（格式為 NTP 時間戳，0 表示永久會話）。
• r=：重復會話的規則（可選，如每天 9 點重復）。
• z=：時區調整（可選，用于修正開始 / 結束時間的時區偏移）。
• k=：加密密鑰（可選，用于會話加密）。

2. 媒體級描述（每個媒體流的具體參數）
每個媒體流通過 m= 字段開始，后續字段描述該媒體的細節：

• m=：媒體類型（如 audio 音頻、video 視頻、application 應用數據等）、傳輸端口、傳輸協議（如 RTP/AVP 表示 RTP 協議 + AVP 載荷格式）、支持的載荷類型（如 0 表示 PCMU 音頻編碼）。

  例如：
  m=audio 5004 RTP/AVP 0 8：表示一個音頻流，使用端口 5004，基于 RTP/AVP 協議，支持載荷類型 0（PCMU）和 8（PCMA）。
  m=video 5006 RTP/AVP 97 98：表示一個視頻流，使用端口 5006，支持載荷類型 97、98（對應具體視頻編碼，如 H.264）。
  

• i=：媒體的描述信息（可選，如 “麥克風音頻”）。
• c=：媒體的連接信息（覆蓋會話級的 c= 字段）。
• b=：媒體的帶寬限制（覆蓋會話級的 b= 字段）。
• k=：媒體的加密密鑰（覆蓋會話級的 k= 字段）。
• a=：屬性字段（最關鍵的擴展字段），用于補充媒體的細節，如：
  - 編碼格式（如 a=rtpmap:0 PCMU/8000 表示載荷類型 0 對應 PCMU 編碼，采樣率 8000Hz）。
  - 方向控制（如 a=sendrecv 表示發送和接收，a=recvonly 表示僅接收）。
  - 帶寬約束（如 a=bandwidth:AS=512 表示應用層帶寬 512kbps）。

M字段詳解：

m=<媒體類型> <端口> <傳輸協議> <載荷類型列表>

媒體類型（Media Type）
指定媒體流的類型，常見值包括：
- audio：音頻流（如麥克風輸入）
- video：視頻流（如攝像頭輸入）
- text：文本流（如實時字幕）
- application：應用數據（如控制信令）
- message：消息流（如即時消息）

端口（Port）
表示接收該媒體流的傳輸層端口號（通常是 UDP 端口，因多媒體傳輸常用 UDP）：
-若媒體使用 RTP 協議，此端口通常為 RTP 數據端口，對應的 RTCP 控制端口一般為該端口 +1；
-示例：m=audio 5004 … 表示音頻流通過端口 5004 接收，RTCP 可能使用 5005 端口。

傳輸協議（Transport Protocol）
指定傳輸該媒體流使用的協議，常見值包括：
- RTP/AVP：基于 UDP 的 RTP 協議（AVP 表示音頻 / 視頻載荷格式），是實時音視頻的主流選擇。
- RTP/SAVP：帶加密的 RTP 協議（用于需要安全傳輸的場景）。
- UDP：直接使用 UDP 傳輸（較少見，通常用于非 RTP 格式的媒體）

載荷類型列表（Payload Types）
一系列數字，代表該媒體流支持的載荷類型（每個數字對應一種編碼格式）。

• 這些數字需結合 SDP 中的 a=rtpmap: 屬性字段，才能映射到具體的編碼格式（如音頻的 PCMU、視頻的 H.264 等）。
• 示例：m=audio … 0 8 表示支持載荷類型 0 和 8，后續可通過 a=rtpmap:0 PCMU/8000 說明 0 對應 PCMU 編碼（8000Hz 采樣率）。

一個典型的 m= 字段示例：

m=video 5006 RTP/AVP 97 98
a=rtpmap:97 H264/90000
a=rtpmap:98 VP8/90000

- 含義：這是一個視頻流（video），通過端口 5006 接收，使用 RTP/AVP 協議傳輸，支持載荷類型 97 和 98。
- 結合 a=rtpmap 可知：97 對應 H.264 視頻編碼（90000Hz 時鐘頻率），98 對應 VP8 視頻編碼。

總結：m= 字段是 SDP 中描述媒體流的 “入口”，通過它可以快速了解媒體的基本傳輸屬性，后續再結合其他字段（如 a=）獲取更詳細的編碼、帶寬等信息。

4. ICE Candidate 里面存儲了哪些內容

ICE（Interactive Connectivity Establishment，交互式連接建立）中的 Candidate（候選地址）是用于在 NAT（網絡地址轉換）環境下建立點對點（P2P）連接的關鍵信息。每個 ICE Candidate 包含一組描述網絡端點的參數，用于協商兩端之間的最佳通信路徑。
ICE Candidate 存儲的核心內容如下：

• 基礎網絡信息
  - IP 地址：候選地址對應的 IP（IPv4 或 IPv6），可能是本地私有 IP、公網 IP 或 NAT 轉換后的 IP。
  - 端口號：用于通信的端口（通常是 UDP 端口，因 ICE 主要用于實時音視頻傳輸）。
  - 傳輸協議：通常為 UDP（ICE 優先使用 UDP，部分場景支持 TCP）。
• 候選類型（Candidate Type）
  標識候選地址的生成方式，決定了其在 NAT 穿透中的優先級，常見類型包括：
  • host：本地主機候選，基于設備自身網絡接口的 IP 和端口（如局域網 IP），優先級最高。
  • Reflexive：
    srflx（Server Reflexive）：服務器反射候選，通過 STUN 服務器獲取的公網 IP 和端口（NAT 映射后的地址），優先級次之。
    prflx（Peer Reflexive）：對等反射候選，在與對端通信過程中動態發現的 NAT 映射地址，優先級較低。
  • relay：中繼候選，通過 TURN 服務器轉發的地址（當 P2P 直連失敗時使用），優先級最低。
• 優先級（Priority）
  一個 32 位整數，用于排序候選地址的嘗試順序。數值越高，優先級越高，ICE 會優先嘗試高優先級的候選對建立連接。優先級計算通常基于候選類型、網絡接口等因素（如 host 候選優先級高于 relay）。
• 基礎地址（Foundation）
  一個字符串標識符，用于標識 “共享相同基礎傳輸地址” 的候選地址（如同一物理網卡生成的不同候選）。ICE 通過 foundation 避免對同一基礎路徑的重復檢查，優化連接建立效率。
• 組件 ID（Component ID）
  標識候選地址對應的媒體組件（如 RTP 音頻流為 1，RTCP 控制流為 2），確保不同媒體流（或控制流）使用正確的候選地址。
• 相關屬性
  - 用戶名片段（ufrag） 和 密碼（pwd）：用于 ICE 消息的認證，防止惡意攻擊。
  - 生成時間：候選地址的創建時間，用于管理候選的有效期（部分場景下候選可能過期失效）。

示例（SDP 格式中的 ICE Candidate）
在 SDP 協議中，ICE Candidate 通常以a=candidate:屬性字段表示，例如：

a=candidate:1 1 UDP 2130706431 192.168.1.100 5004 typ host

解析：這是一個 host 類型的候選，基礎 ID 為 1，組件 ID 為 1，傳輸協議 UDP，優先級 2130706431，IP 為 192.168.1.100，端口 5004。

總結：
ICE Candidate 通過包含 IP、端口、類型、優先級等信息，使通信雙方能夠在復雜網絡環境（尤其是 NAT 后）中找到可互通的路徑，是 P2P 實時通信（如 WebRTC）的核心機制之一。

5. 組包/解包時RTP和RTCP是如何處理的，RTP和RTCP是一個怎么樣的關系

在實時音視頻傳輸中，RTP（Real-time Transport Protocol，實時傳輸協議）和 RTCP（Real-time Transport Control Protocol，實時傳輸控制協議）是一對協同工作的協議，分別負責媒體數據傳輸和傳輸質量監控與控制。兩者在組包 / 解包流程上有明確分工，且存在緊密的依賴關系。
一、RTP 的組包與解包處理
RTP 的核心功能是封裝實時媒體數據（如音頻采樣、視頻幀）并在網絡中傳輸，其組包和解包圍繞 “高效傳輸媒體數據” 和 “提供時序 / 同步信息” 設計。

• RTP 組包（發送端）
  發送端在組包時，會將媒體數據（如一段音頻、一幀視頻的分片）與 RTP 頭部結合，形成 RTP 數據包。

  • RTP 頭部結構（固定 12 字節，可擴展）：
    版本（V）：RTP 版本（目前為 2）。
    payload 類型（PT）：標識媒體編碼格式（如 0=PCMU 音頻，97=H.264 視頻），接收端據此解析數據。
    序列號（Sequence Number）：16 位遞增整數，接收端用于檢測丟包和排序。
    時間戳（Timestamp）：32 位值，基于媒體采樣時鐘（如音頻 8000Hz、視頻 90000Hz），用于同步播放和抖動補償。
    SSRC（同步源標識符）：32 位唯一標識，區分同一會話中的不同媒體流（如同一設備的音頻和視頻）。

  • 組包流程：
    對原始媒體數據分片（若超過 MTU，如大視頻幀拆分為多個 RTP 包）。
    為每個分片添加 RTP 頭部（填充版本、PT、序列號、時間戳、SSRC 等）。
    通過 UDP（或其他傳輸層協議）發送封裝后的 RTP 包。

• RTP 解包（接收端）
  接收端通過解析 RTP 頭部，還原媒體數據并處理時序問題：
  1.接收 RTP 包后，先提取頭部信息（序列號、時間戳、PT 等）。
  2.基于序列號檢測丟包（如發現序列號跳變），并對亂序包重新排序。
  3.基于時間戳計算播放時間（結合本地時鐘），解決網絡抖動導致的播放卡頓（通過抖動緩沖區 Buffer）。
  4.根據 PT 字段識別編碼格式，將凈荷數據（Payload）提交給解碼器（如 H.264 解碼器）。

二、RTCP 的組包與解包處理
RTCP 不傳輸媒體數據，而是收集和傳遞傳輸質量信息（如丟包率、延遲、帶寬），用于發送端調整策略（如碼率、發送間隔），其組包和解包圍繞 “控制信息交換” 設計。

• RTCP 組包（發送端 / 接收端）
  RTCP 包有多種類型（如 SR、RR、SDES、BYE 等），不同類型封裝不同的控制信息，組包時需按對應格式填充內容：
  • 常見 RTCP 包類型：
    SR（Sender Report，發送者報告）：由媒體發送端發送，包含發送統計（如 NTP 時間戳、已發送包數 / 字節數），幫助接收端同步時鐘。
    RR（Receiver Report，接收者報告）：由接收端發送，包含對每個發送端的接收統計（如丟包率、累計丟包數、延遲抖動），是發送端擁塞控制的核心依據。
    SDES（Source Description，源描述）：傳遞參與者信息（如用戶名、郵箱），用于標識會話中的節點。
  • 組包流程：
    1.收集本地傳輸統計信息（如發送端統計發送量，接收端統計丟包和延遲）。
    2.根據角色（發送端 / 接收端）選擇 RTCP 包類型（如發送端發 SR，接收端發 RR）。
    3.按對應包類型的結構封裝信息（如 SR 包含 NTP 時間戳、RTP 時間戳、發送計數等）。
    4.定期發送（RTCP 發送間隔通常為 5-10 秒，與 RTP 共享網絡路徑，但使用不同端口）。
• RTCP 解包（接收端 / 發送端）
  接收端（或發送端）解析 RTCP 包后，提取控制信息并用于決策：
  1. 接收 RTCP 包后，根據包類型字段（PT）識別具體類型（如 SR 的 PT=200，RR 的 PT=201）。
  2. 解析包內統計信息（如從 RR 中提取丟包率，從 SR 中提取發送端時間戳）。
  3. 基于解析結果執行對應操作：
     發送端：若 RR 顯示丟包率過高，降低發送碼率；若延遲抖動增大，調整發送間隔。
     接收端：用 SR 的 NTP 時間戳校準本地時鐘，解決音視頻同步問題。

三、RTP 與 RTCP 的關系
RTP 和 RTCP 是互補且協同的關系，共同保障實時媒體傳輸的質量，核心關系如下：

1. 功能分工：數據傳輸 vs 質量控制
   RTP 是 “數據通道”：專注于高效傳輸媒體數據，提供時序（時間戳）、順序（序列號）和標識（SSRC）信息，但不保證可靠性（無重傳機制）。
   RTCP 是 “控制通道”：專注于監控傳輸質量，收集并反饋丟包、延遲等信息，為 RTP 的傳輸策略調整提供依據（如擁塞控制、碼率自適應）。
2. 依賴關系：RTCP 依賴 RTP 數據，RTP 依賴 RTCP 反饋
   RTCP 的統計信息基于 RTP 數據：接收端的 RR 報告中，丟包率、延遲抖動等指標均來自對 RTP 包的統計（如序列號跳變計算丟包，時間戳間隔計算抖動）。
   RTP 的傳輸策略依賴 RTCP 反饋：發送端通過 RTCP 的 RR/SR 信息調整 RTP 發送（如 GCC 擁塞控制算法基于 RTCP 的延遲和丟包反饋，動態調整 RTP 的發送碼率）。
3. 傳輸關聯：共享會話但端口分離
   兩者屬于同一實時會話（由 SDP 協商的 SSRC、端口等參數關聯）。
   通常使用相鄰端口：RTP 使用偶數端口（如 5004），RTCP 使用奇數端口（如 5005，即 RTP 端口 + 1），便于區分數據和控制流。
4. 協同目標：平衡實時性與可靠性
   實時傳輸的核心矛盾是 “實時性”（低延遲）與 “可靠性”（無丟包）的沖突。RTP 通過簡化頭部、無重傳實現低延遲，而 RTCP 通過反饋機制讓發送端動態適配網絡（如網絡擁塞時降低碼率減少丟包），兩者協同在保證實時性的前提下最大化傳輸質量。

總結
RTP：負責媒體數據的封裝與傳輸，提供時序和順序信息，是實時傳輸的 “數據載體”。
RTCP：負責傳輸質量的監控與反饋，提供丟包、延遲等統計，是實時傳輸的 “質量控制器”。
兩者缺一不可：沒有 RTP，媒體數據無法高效傳輸；沒有 RTCP，發送端無法感知網絡狀態，難以保證傳輸質量。

6. NACK和RTX 是如何進行丟包、延遲處理的

在實時音視頻傳輸中，NACK（Negative Acknowledgment，否定確認）和 RTX（RTP Retransmission，RTP 重傳）是一對協同處理丟包恢復的機制，主要用于在 UDP 傳輸（無重傳機制）場景下，通過主動請求重傳丟失的數據包來提升傳輸可靠性。同時，兩者也會通過特定策略平衡重傳帶來的延遲，避免影響實時性。
一、NACK：丟包的 “通知機制”
NACK 的核心作用是讓接收端告知發送端哪些 RTP 數據包丟失了，為后續重傳提供依據。其處理流程如下：

1. 丟包檢測（接收端）
   接收端通過 RTP 包的序列號（Sequence Number） 檢測丟包：
   • RTP 序列號是 16 位遞增整數，每個 RTP 包的序列號依次 + 1（如包 1 的序列號為 100，包 2 為 10