从sdp开始到webrtc的通信过程

发布于：2025-06-12 ⋅ 阅读:(14) ⋅ 点赞:(0)

1. SDP

1.1 SDP的关键点

SDP（Session Description Protocol）通过分层、分类的属性字段，结构化描述实时通信会话的 会话基础、网络连接、媒体能力、安全策略、传输优化 等核心信息，每个模块承担特定功能：

1. 会话级别描述（全局会话元信息）

  • v=：协议版本（固定为 0），标识 SDP 遵循的标准版本，确保解析兼容性。
  • o=：会话发起者信息，格式为 o=<用户名> <会话ID> <会话版本> <网络类型> <地址类型> <IP> ，用于唯一标识会话（如多终端复用场景区分会话实例）。
  • s=：会话名称/主题，简短描述会话内容（如 s=视频会议 ），便于业务层识别。
  • t=：会话时间范围，格式 t=<起始时间> <结束时间>（UNIX 时间戳），用于预约会议或控制会话有效期。
  • b=：带宽限制，格式 b=<类型>:<带宽值>（如 b=AS:1024 表示总带宽 1024kbps），控制会话资源占用。

2. 网络描述（连通性与地址协商）

  • c=：默认网络连接信息，格式 c=<网络类型> <地址类型> <IP> ，定义会话级默认网络参数（媒体流可覆盖此配置），如 c=IN IP4 0.0.0.0 表示 IPv4 地址。
  • a=candidate：ICE 候选地址，格式 a=candidate:<foundation> <component-id> <proto> <priority> <IP> <port> <type> ，用于交换 P2P 连接的候选地址（如主机地址、中继地址），实现 NAT 穿越。

3. 媒体级别描述（单流能力协商）

  • m=：媒体流基础定义，格式 m=<媒体类型> <端口> <传输协议> <编码Payload列表> ，如 m=video 9 UDP/TLS/RTP/SAVPF 96 97 表示视频流、端口 9、SRTP 传输、支持 Payload 96/97 。
  • a=rtpmap：编码映射，格式 a=rtpmap:<Payload> <编码名>/<采样率> ，关联 Payload 与具体编码（如 a=rtpmap:96 VP8/90000 表示 Payload 96 对应 VP8 编码，采样率 90000Hz ）。
  • a=fmtp：编码参数扩展，传递编码特定配置（如 a=fmtp:97 apt=96 表示 RTX 编码（Payload 97 ）关联主编码 VP8（Payload 96 ））。
  • a=extmap：RTP 扩展头定义，用于传递自定义元数据（如视频帧类型、时间戳修正）。
  • a=sendrecv/a=sendonly/a=recvonly/a=inactive：媒体流方向，控制收发策略（如订阅流用 recvonly ，推流用 sendonly ）。
  • a=ssrc：同步源标识，格式 a=ssrc:<SSRC> <属性> ，标记媒体流的唯一源（如 a=ssrc:1234 cname:user@domain 关联 SSRC 与用户标识）。

4. 安全描述（加密与身份验证）

  • a=crypto：加密算法配置，格式 a=crypto:<加密套件> <主密钥> ，定义 SRTP 加密参数（如 a=crypto:1 AES_CM_128_HMAC_SHA1_80 ）。
  • a=ice-ufrag/a=ice-pwd：ICE 认证信息，用于 ICE 连通性检查的身份验证（如 a=ice-ufrag:abc 、a=ice-pwd:def ）。
  • a=fingerprint：DTLS 证书指纹，格式 a=fingerprint:<哈希算法> <指纹值> ，验证 DTLS 证书合法性（如 a=fingerprint:sha-256 12:34:56... ）。

5. DTLS 角色（加密通道协商）

  • a=setup：DTLS 连接角色，取值 active（主动发起连接）、passive（被动监听）、actpass（自动协商） ，控制 DTLS 握手流程（如 a=setup:actpass 表示支持主动或被动模式）。

6. ICE 策略（P2P 连接优化）

  • a=ice-options:trickle：Trickle ICE 模式，允许分批次传输候选地址，加速会话建立（无需等所有候选生成再交换）。
  • a=ice-lite：轻量 ICE 模式，适用于服务端（如 SFU ），减少 ICE 检查开销（仅响应客户端检查）。
  • a=ice-option:renomination：ICE 提名优化，允许更换更优候选地址，动态调整传输路径。

7. QoS、Grouping 传输描述（流管理与优化）

  • a=rtcp-fb：RTCP 反馈机制，定义拥塞控制、丢包重传策略（如 a=rtcp-fb:96 transport-cc 启用传输层拥塞控制）。
  • a=group：多流复用，格式 a=group:<类型> <媒体标识> ，如 a=group:BUNDLE video audio 将音视频流复用同一传输通道。
  • a=rtcp-mux：RTP/RTCP 复用，使 RTP（媒体数据）和 RTCP（控制信令）共享同一端口，简化 NAT 配置。

1.2 核心模型 offer-answer模型

SDP（Session Description Protocol，会话描述协议 ）的 Offer - Answer 模型是实时多媒体通信（如结合 SIP、WebRTC 等场景）里用于协商会话参数的核心机制
一、是什么：模型基本定义与角色

  • 核心逻辑：
    两通信实体借助 SDP 交互，一方（提议方，Offerer）先发送包含自身期望会话参数的 Offer ，描述想建立的多媒体会话（如支持的媒体类型、编码、网络地址等）；另一方（应答方，Answerer）依据自身能力筛选匹配参数，回复 Answer ，最终达成双方都认可的会话参数共识。
  • 典型场景：常见于 SIP（会话初始协议）、WebRTC 等音视频通话流程，解决“通信双方如何协商媒体能力、网络参数”问题，让不同终端（浏览器、服务器、硬件设备）能统一“会话规则” 。

二、为什么需要：解决的通信痛点

  1. 终端能力差异：不同设备支持的媒体编码（如 VP8/H.264 ）、传输协议（UDP/TCP ）、网络环境（NAT 类型不同）千差万别。比如手机浏览器和 PC 浏览器，编码支持侧重不同，需通过协商找到“交集” 。
  2. 会话参数双向确认： unicast（单播）会话里，完整会话视图需要双方信息（如双端都要告知对方自己的网络地址 ）；而 multicast（组播）虽有全局视图，但单播场景必须双向协商才能建立连接，Offer - Answer 模型就是为补齐 SDP 在单播会话里的协商“语义和操作细节”而生 。
  3. 动态会话调整：通话中可能需要增减媒体流（如关闭视频保留音频 ）、修改编码（弱网切换低码率编码 ），模型支持通过再次交换 Offer - Answer 动态调整，让会话适配网络或需求变化。

三、怎么用：流程与规则（以简单音视频通话为例 ）
1. 基本流程（Unicast 单播场景）

  • Step 1：生成 Offer（Offerer 主动发起）
    提议方（如用户 A 的浏览器）构建 SDP Offer，包含会话基础信息（v= 版本、o= 发起者标识 ）、媒体流描述（m= ，如音频/视频类型、端口、支持的编码 ）、网络连接信息（c= ，自身 IP 等 ）、安全配置（如 DTLS 指纹 a=fingerprint ）等。示例片段：

    v=0
o=userA 12345 67890 IN IP4 192.168.1.100  # 会话发起者信息
s=-  # 会话名称（无内容用 - 占位）
c=IN IP4 192.168.1.100  # 网络连接默认地址
t=0 0  # 会话时间范围（永久有效）
m=audio 5000 RTP/AVP 97 98  # 音频流：端口5000，支持编码97（AMR）、98（AMR - WB）
a=rtpmap:97 AMR/16000/1  # 映射编码97为AMR，采样率16000
m=video 6000 RTP/AVP 32  # 视频流：端口6000，支持编码32（MPV）
a=rtpmap:32 MPV/90000  # 映射编码32为MPV，时钟频率90000

    通过信令协议（如 SIP 的 INVITE 消息、WebRTC 的信令服务器 ）发给应答方（用户 B ）。

  • Step 2：生成 Answer（Answerer 响应）
    应答方（如用户 B 的浏览器）解析 Offer，按规则筛选参数：

    • 媒体流数量与顺序：Answer 的 m= 行数量、顺序必须与 Offer 一致（保证双方对应媒体流匹配 ）。
    • 编码与端口：每个媒体流的编码选 Offer 里的子集，端口设为非 0 表示接受，设为 0 表示拒绝。
      假设用户 B 只接受音频流、选编码 97，回复 Answer 片段：
    v=0
o=userB 67890 12345 IN IP4 192.168.1.200  # 应答方会话标识
s=-  
c=IN IP4 192.168.1.200  
t=0 0  
m=audio 5001 RTP/AVP 97  # 接受音频流，端口5001（与Offer不同，协商双端收发端口），选编码97
a=rtpmap:97 AMR/16000/1  
m=video 0 RTP/AVP 32  # 拒绝视频流，端口设0

    同样通过信令回传给提议方。

  • Step 3：确认与建立连接
    提议方收到 Answer 后，验证参数是否符合预期（如媒体流接受/拒绝逻辑 ），双方基于协商的编码、网络地址，通过 ICE（Interactive Connectivity Establishment ，互动连接建立 ）完成网络连通性检查，最终建立媒体传输通道（如 RTP 传输音频视频 ）。

  1. 关键规则（RFC 3264 定义核心约束 ）
  • Offer 生成规则：
    必须包含 SDP 强制字段（v=、o=、s=、c=、t= ）；媒体流（m= ）按优先级列编码，若支持 codec 太多，优先列最可能被接受的。
  • Answer 生成规则：
    • m= 行数量、顺序严格匹配 Offer ，保证媒体流对应关系；
    • 端口 0 表示拒绝该媒体流，非 0 表示接受；
    • 编码必须是 Offer 编码的子集，动态编码（如 RTX ）双端编号可不同，但通常选一种编码。
  • 会话修改规则：
    双方可发起新的 Offer - Answer 交换调整会话（如增减媒体流、改编码 ）；修改时，o= 里的版本号要么不变（表示 SDP 未变 ）、要么 +1（表示新参数需解析 ）；新增媒体流放 m= 列表末尾，删除则设对应端口为 0 但保留 m= 行，方便后续协商。

一般是由信令服务器为中继服务器,来进行交换sdp

2 实战

#offer
v=0
o=- 2397106153131073818 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS
m=video 9 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:l5KU
a=ice-pwd:+Sxmm3PoJUERpeHYL0HW4/T9
a=ice-options:trickle
a=fingerprint:sha-256
7C:93:85:40:01:07:91:BE:DA:64:A0:37:7E:61:CB:9D:91:9B:44:F6:C9:AC:3B:37:1C:00
:15:4C:5A:B5:67:74
a=setup:actpass
a=mid:video
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=ssrc-group:FID 2527104241
a=ssrc:2527104241 cname:JPmKBgFHH5YVFyaJ
a=ssrc:2527104241 msid:gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS c7072509-df47-
4828-ad03-7d0274585a56
a=ssrc:2527104241 mslabel:gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS
a=ssrc:2527104241 label:c7072509-df47-4828-ad03-7d0274585a56
#answer
v=0
o=- 5443219974135798586 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS uiZ7cB0hsFDRGgTIMNp6TajUK9dOoHi43HVs
m=video 9 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:MUZf
a=ice-pwd:4QhikLcmGXnCfAzHDB++ZjM5
a=ice-options:trickle
a=fingerprint:sha-256
2A:5A:B8:43:66:05:B3:6A:E9:46:36:DF:DF:20:11:6A:F6:11:EA:D9:4E:26:E3:CE:5A:3A
:C6:8D:03:49:7B:DE
a=setup:active
a=mid:video
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=ssrc-group:FID 3587783331
a=ssrc:3587783331 cname:INxZnBV2Sty1zlmN
a=ssrc:3587783331 msid:uiZ7cB0hsFDRGgTIMNp6TajUK9dOoHi43HVs a3b297e7-cdbe-
464e-a32c-347465ace055
a=ssrc:3587783331 mslabel:uiZ7cB0hsFDRGgTIMNp6TajUK9dOoHi43HVs
a=ssrc:3587783331 label:a3b297e7-cdbe-464e-a32c-347465ace055

一、会话级别字段解析

  1. 协议版本（v=）
  • 字段：v=0
  • 说明：固定值，表示 SDP 协议版本为 0，遵循 RFC 4566 规范。
  1. 会话发起者（o=）
  • 字段：o=- 2397106153131073818 2 IN IP4 127.0.0.1
  • 结构：
    • username：-（无用户名，用 - 占位）
    • sess-id：2397106153131073818（会话 ID，通常为 NTP 时间戳）
    • sess-version：2（会话版本，数据变更时递增）
    • nettype：IN（网络类型为 Internet）
    • addrtype：IP4（地址类型为 IPv4）
    • unicast-address：127.0.0.1（发起者 IP，本地回环地址，可能为测试环境）
  • 作用：唯一标识会话，确保多终端协商时的唯一性。
  1. 会话名（s=）
  • 字段：s=-
  • 说明：会话名称为空，用 - 占位，符合“无有意义名称时设为 -”的规范。
  1. 会话时间（t=）
  • 字段：t=0 0
  • 说明：会话永久有效（起始时间和结束时间均为 0），适用于实时通信场景。
  1. 附加属性（a=）
  • a=group:BUNDLE video
    • 作用：将视频流复用同一传输通道（BUNDLE 机制），减少 Candidate 数量和 NAT 配置复杂度。
  • a=msid-semantic: WMS gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS
    • msid-semantic：声明媒体源标识（MSID）的语义为 WMS（WebRTC Media Source）。
    • gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS：媒体源 ID，用于关联流与终端设备。

二、媒体级别字段解析（m=video）

  1. 媒体描述（m=）
  • 字段：m=video 9 UDP/TLS/RTP/SAVPF 96 97
  • 结构：
    • media：video（媒体类型为视频）
    • port：9（传输端口，在 WebRTC 中实际使用 ICE 候选地址，端口可能为占位符）
    • proto：UDP/TLS/RTP/SAVPF（传输协议为 UDP，基于 TLS 加密，使用 SRTP 协议，支持 RTCP 反馈）
    • fmt：96 97（Payload 类型列表，96 为 VP8 编码，97 为 RTX 重传编码）
  • 作用：定义视频流的基础参数，协商时接收方需从中选择支持的编码。
  1. 连接数据（c=）
  • 字段：c=IN IP4 0.0.0.0
  • 说明：网络类型为 IPv4，地址为 0.0.0.0（表示未指定具体地址，依赖媒体级或 ICE 候选地址）。
  1. RTCP 配置（a=rtcp:）
  • 字段：a=rtcp:9 IN IP4 0.0.0.0
  • 说明：RTCP（实时传输控制协议）端口为 9，与 RTP 端口相同，结合 a=rtcp-mux 可复用同一端口。
  1. ICE 相关属性
  • a=ice-ufrag:l5KU
    • ICE 用户名，用于身份验证，与对端 ice-pwd 配合使用。
  • a=ice-pwd:+Sxmm3PoJUERpeHYL0HW4/T9
    • ICE 密码，与用户名组成认证凭证。
  • a=ice-options:trickle
    • 启用 Trickle ICE 模式，允许分批次传输 Candidate，加速会话建立。
  1. DTLS 安全配置
  • a=fingerprint:sha-256 ...
    • DTLS 证书指纹（SHA-256 哈希值），用于验证证书合法性，防止中间人攻击。
  • a=setup:actpass
    • DTLS 角色为 actpass（主动/被动均可），由对端在 Answer 中确定最终角色。
  1. 媒体流方向与复用
  • a=mid:video
    • 媒体流唯一标识（mid）为 video，与 a=group:BUNDLE 配合实现流复用。
  • a=sendrecv
    • 流方向为双向传输（发送+接收），适用于视频通话场景。
  • a=rtcp-mux
    • 复用 RTP/RTCP 到同一端口，简化 NAT 穿越。
  1. 编码与反馈配置
  • a=rtpmap:96 VP8/90000
    • Payload 96 映射为 VP8 编码，采样率 90000Hz。
  • a=rtcp-fb:96 goog-remb
    • 启用 Google 拥塞控制反馈（goog-remb），优化弱网下的码率调整。
  • a=rtpmap:97 rtx/90000
    • Payload 97 映射为 RTX（重传编码），a=fmtp:97 apt=96 表示其关联主编码为 VP8（96）。
  1. SSRC 与媒体源标识
  • a=ssrc-group:FID 2527104241
    • SSRC 组类型为 FID（流标识），关联 SSRC 2527104241 与媒体流。
  • a=ssrc:2527104241 msid:...
    • MSID（媒体源 ID）为 gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS c7072509-df47-...，标识具体媒体源（如摄像头）。

三、Offer 的核心功能与协商目标

  1. 能力声明
    Offer 向对端展示本端支持的：
  • 编码能力：VP8 视频编码，支持 RTX 重传。
  • 网络策略：Trickle ICE 模式、BUNDLE 流复用、RTCP-MUX 端口复用。
  • 安全配置：DTLS 证书指纹、ICE 认证信息。
  1. 协商目标
  • 对端（Bob）需从 fmt 列表（96/97）中选择支持的编码，通常选首个优先级最高的编码（VP8）。
  • 确认 ICE 候选地址（通过信令单独交换，如 a=candidate），完成连通性检查。
  • 确定 DTLS 角色（如 Bob 在 Answer 中设为 active，本端则为 passive）。

四、与 Answer 的关键差异对比

字段 Offer（Alice） Answer（Bob） 说明
o= Alice 的会话 ID Bob 的会话 ID 标识应答方会话
ice-ufrag/ice-pwd l5KU/+Sxmm3Po... MUZf/4QhikLcmGX... 应答方 ICE 认证信息
setup actpass active Bob 确定 DTLS 角色为主动
ssrc 2527104241（Alice 的流） 3587783331（Bob 的流） 应答方媒体源 ID

3 总结

在这里插入图片描述

一、信令阶段（SDP 协商：Offer/Answer 模型）
核心目标：交换双方媒体能力（编码、分辨率等）和网络协商参数（ICE 策略、DTLS 安全配置），为后续连接做准备。

  1. Client 生成 Offer（SDP）
    Client（如浏览器）先构建 SDP Offer，包含：
  • 会话元信息：v=0（协议版本）、o=（会话 ID/发起者）、s=-（会话名）、t=0 0（会话时长）。
  • 媒体描述：m=video（视频流）、a=rtpmap:96 VP8/90000（支持 VP8 编码）、a=rtcp-fb（拥塞控制反馈策略）。
  • 网络与安全：a=ice-ufrag/a=ice-pwd（ICE 认证）、a=fingerprint:sha-256（DTLS 证书指纹）、a=setup:actpass（DTLS 角色协商）。

通过信令服务器（如 WebSocket 通道），将 Offer 转发给 Media Server。

  1. Media Server 回复 Answer（SDP）
    Media Server 解析 Offer 后，筛选双方共同支持的参数（如确认使用 VP8 编码、匹配 ICE 策略），生成 SDP Answer：
  • 媒体流确认：保留 m=video 结构，确认编码 96（VP8），拒绝不支持的编码（若有）。
  • 安全与网络响应：a=setup:active（确定 DTLS 角色为主动）、替换 ice-ufrag/ice-pwd 为自身认证信息。

通过信令服务器，将 Answer 回传给 Client。

  1. 信令服务器的作用
  • “中转站”：不处理 SDP 内容，仅负责转发 Offer/Answer，确保两端交换协商信息。
  • 状态协调：可辅助管理会话状态（如房间内用户列表、媒体流路由），但核心是传递 SDP 信令。

二、网络穿透阶段（ICE + STUN/TURN）
核心目标：找到 Client 与 Media Server 之间可连通的网络路径（穿透 NAT/防火墙），为媒体流传输铺路。

  1. 收集 ICE 候选地址
    Client 和 Media Server 各自生成候选地址（Candidate），包含：
  • Host 候选：设备内网 IP（如 192.168.1.100），优先级最高。
  • Srflx 候选：通过 STUN 服务器获取的公网映射地址（如 203.0.113.1），用于直连穿透。
  • Relay 候选：通过 TURN 服务器获取的中继地址（如 turn:xxx.com:3478），保底方案（直连失败时用）。

  1. 交换候选地址（Trickle ICE）
    双方通过信令服务器交换候选地址（a=candidate 字段），支持分批次传输（Trickle ICE 模式），加速连接建立。

  2. 连通性检查（ICE 打洞）
    Client 和 Media Server 基于候选地址，用 STUN 请求/响应 测试连通性：

  • 优先尝试 Host 候选（内网直连），若成功则无需中继。
  • 失败则尝试 Srflx 候选（STUN 打洞），获取公网映射地址直连。
  • 仍失败则用 Relay 候选（TURN 中继），确保复杂网络下连通。
  1. 选定最佳路径
    ICE 会为候选地址动态排序（直连地址优先级 > 中继地址），最终选定最优路径（如 Host 或 Srflx 候选），用于后续媒体流传输。

三、安全传输阶段（DTLS 握手 + SRTP 加密）
核心目标：建立加密通道，确保媒体流（音频/视频）传输安全，防止窃听/篡改。

  1. DTLS 握手（密钥协商）
    Client 和 Media Server 基于 SDP 中的 a=setup 和 a=fingerprint，进行 DTLS 握手：
  • Client 角色：Offer 中 a=setup:actpass，表示可主动或被动发起握手。
  • Server 角色：Answer 中 a=setup:active，主动发起握手。
  • 流程：
    1. Client 发送 Client Hello，携带加密套件、随机数。
    2. Server 回复 Server Hello，确认加密套件，返回证书指纹。
    3. 交换 Change Cipher（切换加密算法）和 Finished（握手完成），协商出对称加密密钥。
  1. SRTP 加密传输
    DTLS 握手生成的密钥，用于 SRTP（安全实时传输协议） 加密媒体流：
  • RTP 基础：媒体数据（如视频帧）封装为 RTP 包，携带时间戳、序列号。
  • SRTP 加密：在 RTP 包中嵌入加密数据和完整性校验信息，确保传输安全。
  1. SrsSecurityTransport 的作用
    图中 SrsSecurityTransport 是 Media Server（如 SRS）的安全传输模块，负责：
  • 处理 DTLS 握手，协商加密密钥。
  • 对 outgoing 媒体流用密钥加密（Send Key），对 incoming 媒体流解密（Recv Key）。
  • 实现 SRTP -> Security RTP 转换，保障端到端加密。

四、完整通信流程总结

  1. 信令协商（SDP Offer/Answer）：通过信令服务器交换媒体能力、网络策略、安全配置。
  2. 网络穿透（ICE + STUN/TURN）：交换候选地址，测试连通性，选定最优传输路径。
  3. 安全传输（DTLS + SRTP）：握手协商加密密钥，加密媒体流并传输。

核心逻辑：

  • 信令服务器是“协调员”，负责转发 SDP 和候选地址，但不处理媒体流。
  • ICE 解决“网络不通”问题，DTLS/SRTP 解决“传输不安全”问题，SDP 是“协商语言”，共同支撑 WebRTC 通信。

简单说，就是 “信令协商规则 → 网络打通路径 → 加密保障安全” 的三层协同，让实时音视频通信在复杂网络环境下稳定、安全运行～

网站公告

今日签到

点亮在社区的每一天
去签到

热门文章

最新发布