我是靠谱客的博主 兴奋音响，最近开发中收集的这篇文章主要介绍流媒体协议分析之webrtc之rtcp4.RTCP RTP Feedback5WebRTC RTCP XR，觉得挺不错的，现在分享给大家，希望可以做个参考。
概述
TCP作为RTP控制协议，对于弱网下音视频质量和会话控制具有重要的作用。
1. RTCP Header
V：RTCP的版本号，一定等于2；
P：如果设置，填充位表示数据包包含末尾的附加填充八位字节，不属于控制信息，但包含在长度字段中；
FMT：反馈消息类型，并根据PT类型的不同而含义不同。比如当PT=200时，表示ReportBlock的个数；当PT=205时，表示反馈包的类型，1：NACK丢包重传，15：TWCC拥塞控制
PT：负载类型，详细请看下表
length：此数据包的长度（以32位字节为单位减去1），包括Header和任何填充。
2、RTCP Payload
RTCP 主要涉及到 3 个 RFC 文档
- RFC3550 → SR/RR/BYE/APP/SDES
- RFC4585 → RTPFB/PSFB
- RFC3611 → XR
3.RTCP发送端报告（SR）
官方文档：RFC 3550 - RTP: A Transport Protocol for Real-Time Applications
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| FMT | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender | NTP timestamp, most significant word |
info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+- FMT：在SR中，FMT表示后面跟的report block个数，可以是0个（只发送流），也可以是多个。
- SSRC of sender：同步源标识符，SR数据包的发起者的编号
- NTP timestamp：64位无符号整型，表示该SR报文发送的时刻的系统NTP时间；
- RTP timestamp：32位无符号整型，表示该SR报文发送的时刻的RTP时间，RTP时间戳初始值是随机的，是相对时间，加到最大值后会翻转从0开始；
- packet count：发送端发送的包总的个数；
- packet octet：发送端发送的总的字节数；
- report block相关参数和RR一致，放后面介绍。
3、RTCP接收端报告（RR）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| FMT | PT=RR=201 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+- FMT：在RR中，FMT同样表示后面跟的report block个数
- SSRC of sender：同步源标识符，RR数据包的发起者的编号
- SSRC_1：接收报告块中的信息所属的源的SSRC标识符
- fraction lost：丢包率，表示来自源 SSRC_n 的 RTP 数据包在上一个 SR 或 RR 包被发送后丢失的部分，表示为一个定点数，二进制点位于字段的左边缘。
- cumulative number of packets lost：丢失数据包的累积数量，表示自接收开始以来丢失的来自源SSRC_n的RTP数据包的总数。
- extended highest sequence number received：接收到的扩展最高序列号，低16位表示接收到的RTP包最大序列号，高16位表示RTP包序列号翻转次数。
- interarrival jitter：到达间隔抖动，指RTP数据包到达间隔时间的统计方差估计值。
- 计算公式如下：
- 定义到达间隔抖动值：J，定义偏差值：D，
- 如果Ri是数据包i以RTP时间戳为单位的到达时间，Si是数据包i的RTP时间戳，那么对于两个数据包i和j，D可以表示为
- D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
- J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
- 增益参数1/16 提供了良好的降噪比，同时保持了合理的收敛速度
- LSR：最后接收的SR包里的NTP时间戳，只截取了中间的32bit。如果还没有收到SR，则该字段设置为0。
- DLSR：自最后接收SR包以来到发送RR包之间的延迟，以 1/65536 秒为单位
4.RTCP RTP Feedback
作为WebRTC RTCP消息中的一种，RTP Feedback包含的内容很多，所以这里单独介绍。
在RTCP Header中，这类消息的负载类型Payload Type=205，反馈消息类型FMT如下：
| FMT | Name | Long Name | Description | Reference |
| 1 | NACK | Generic negative acknowledgement | 丢包重传请求 | RFC4585 |
| 3 | TMMBR | Temporary Maximum Media Stream Bit Rate Request | 临时最大媒体流比特率请求 | RFC5104 |
| 4 | TMMBN | Temporary Maximum Media Stream Bit Rate Notification | 临时最大媒体流比特率通知 | RFC5104 |
| 7 | TLLEI | Transport-Layer Third-Party Loss Early Indication | 传输层第三方丢失早期指示 | RFC6642 |
| 8 | ECN | Explicit Congestion Notification | 显式拥塞通知 | RFC6679 |
| 15 | TWCC | Transport Wide Congestion Control | 传输宽拥塞控制 | draft-holmer-rmcat-transport-wide-cc-extensions-01 |
4.1.丢包重传请求（NACK）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=1 | PT=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- PID：数据包ID， 指丢失的RTP包的序列号。
- BLP：丢失数据包的位掩码，表示从PID开始往后16个RTP包是否有丢失。如果第i位为1，则说明序列号为PID+i的RTP包丢失，若未丢包该位为0。
4.2 临时最大媒体流比特率请求（TMMBR）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=3 | PT=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- MxTBR Exp：指数
- MxTBR Mantissa：系数
- Measured Overhead：测量的平均数据包开销值（以字节为单位）
- 说明：TMMBR用于流控，接收方向发送方请求按指定的最大比特率传输数据流，通常用于网络抖动情况下保证VOIP通信的流畅性（临时降低质量）。最大比特率 = 系数 * 2^指数。
4.3 临时最大媒体流比特率通知(TMMBN)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=4 | PT=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+说明：此反馈消息用于通知TMMBR消息的发送者已收到一条或多条TMMBR消息
4.4 传输层第三方丢失早期指示（TLLEI）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=7 | PT=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- PID：数据包ID， 指丢失的RTP包的序列号。
- BPL：丢失数据包的位掩码，表示从PID开始往后16个RTP包是否有丢失。如果第i位为1，则说明序列号为PID+i的RTP包丢失，若未丢包该位为0。
4.5、显式拥塞通知（ECN）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=8 | PT=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Highest Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lost Packets Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Extended Highest Sequence Number：扩展最大序列号，表示此报告相关的最大 RTP 序列号。
- ECT (0) Counter ：
- ECT (1) Counter：
- ECN-CE Counter：
- not-ECT Counter：
- Lost Packets Counter：
- Duplication Counter：
4.6 传输宽拥塞控制（TWCC）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=15 | PT=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| base sequence number | packet status count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reference time | fb pkt. count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packet chunk | packet chunk |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packet chunk | recv delta | recv delta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| recv delta | recv delta | zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- base sequence number：此反馈中的第一个RTP包序列号
- packet status count：本次反馈包含的RTP包的总数
- reference time：表示参考时间，以64ms为单位
- feedback packet count：反馈数据包计数，用于接收方检测反馈包是否有丢失
- packet chunk：数据包块，记录RTP包的到达状态，记录的这些RTP包序列号通过base sequence number计算得到
- recv delta：对于每个“已收到数据包”的状态，也就是收到的RTP包，在recv delta列表中添加对应的的到达时间间隔信息，用于记录RTP包到达时间信息。通过前面的reference time以及recv delta信息，我们就可以得到RTP包到达时间。
5WebRTC RTCP XR
RTCP扩展报告(XR)用于补充RTCP 的发送方报告 (SR) 和接收方报告 (RR) 数据包的报告块中的六个统计信息。
| Value | Name | Name | Description | Reference |
| 1 | RRT | Receiver Reference Time | 接收方参考时间 | rfc3611#section-4.4 |
| 2 | DLSR | Delay since the last Sender Report | 自上次发送方报告以来的延迟 | rfc3611#section-4.5 |
5.1 接收方参考时间（RRT）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=4 | reserved | block length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- block type(BT)：块类型，该报告块为常数4
- block length：块长度，2*32bit
- NTP timestamp：64bit的NTP系统时间
5.2 自上次发送方报告以来的延迟（DLSR）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=5 | reserved | block length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| last RR (LRR) | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last RR (DLRR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+- block type(BT)：块类型，该报告块为常数5
- block length：块长度，3*32bit
- last RR(LRR)：最后接收的RRT包里的NTP时间戳，只截取了中间的32bit。如果还没有收到RRT，则该字段设置为0。
- delay since last RR(DLRR)：自最后接收RRT包以来到发送DLSR之间的延迟，以 1/65536 秒为单位
接收方发送RTCP-XR RRT后，发送方在下次的RTCP中携带RTCP-XR DLSR，可以使接收方估算出网络的RTT参数。
最后
以上就是兴奋音响为你收集整理的流媒体协议分析之webrtc之rtcp4.RTCP RTP Feedback5WebRTC RTCP XR的全部内容，希望文章能够帮你解决流媒体协议分析之webrtc之rtcp4.RTCP RTP Feedback5WebRTC RTCP XR所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。
发表评论 取消回复