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