基于SFU架构的视频会议系统中，Simulcast是最主流的带宽自适应方案。发布端（Publisher）同时编码并发送多路不同分辨率的流（通常为小、中、大三路），订阅端（Subscriber）则根据自身网络带宽、设备性能、窗口大小等因素，选择订阅最合适的单路流。这种设计发布端与订阅端互不干扰： 发布端仅受自身上行带宽和编码负载影响 订阅端仅受自身下行带宽，解码能力，显示窗口影响 但在实际生产环境中，某些核心场景却需要订阅端能够“反向影响”发布端，即实现backpressure（反压）机制。 反压需求场景 按需推流 当会议中所有订阅端都处于小窗口显示（如宫格数较多、缩略图模式）时，大家只会订阅小流。此时发布端若仍持续推送大流，就会造成巨大的上行带宽浪费和服务器转发压力。理想状态是：订阅端集体选择小流 → SFU 通知发布端自动降档，只推小流即可。 SFU模拟点对点（P2P）通话 用SFU统一实现1对1通话（便于后续扩展多人）。此时必须达到原生P2P（ICE直连）的体验。 订阅端网络恶化时，不能仅靠切换Simulcast层（因为只有一层流），而应直接让发布端降低编码码率/分辨率 订阅端网络恢复后，发布端也要快速回升 在传统Simulcast中做不到这样的“端到端拥塞控制”。 SFU如何实现订阅端反压 核心思路：在SFU内部为每个发布源（Source）和每个订阅接收器（Sink） 建立反馈通道，让订阅客户端的带宽估计结果能够传递到发布客户端。 下面是实现原理图： 发布客户端 → RTP → SFU Source（发布源） SFU Sink（订阅接收器）收到订阅端发来的 Transport-CC报文，进行下行带宽估计 Sink通过onFeedback接口将估计带宽值传递给对应的Source Source封装REMB（Receiver Estimated Maximum Bitrate）RTCP报文，传回到发布客户端 发布客户端收到REMB后，强制限制自身带宽估计值 这样就实现了订阅端 → SFU → 发布端的完整反压闭环。 REMB RTCP报文复用 WebRTC早期就内置了REMB RTCP，用在最早的接收端带宽估计中，接收端的带宽估计就是通过REMB反馈到发布端。虽然现在是Transport-CC + Sendside BWE，但REMB仍然被支持。这里可以看下REMB报文格式： [crayon-69c6cd4123774134838947/] 对于SFU，带宽反馈处理只需在 Source 侧调用： [crayon-69c6cd4123785845089804/] 发布客户端中WebRTC收到REMB后的处理如下： [crayon-69c6cd412378b870293556/] 至此我们完成初步的反压实现。 遗留问题：弱网解除后带宽恢复速度慢 前面实现后还有个问题，就是订阅端弱网恢复后，恢复之前码率较慢。原因如下： 订阅端之前带宽差 → SFU反馈低REMB → 发布端码率被压得很低 订阅端网络恢复 → 其BWE想提升，但实际收到的码率仍然很低（受发布端限制） 订阅端BWE探测不到更高带宽 → 继续反馈低REMB → 发布端无法提升 → 形成“死循环” 这就像“受制于人”，恢复速度远慢于原生的P2P实现。 这时候我们可以在SFU的Sink（下行）侧中，主动注入探测流量，也就是引入探测（Padding）包。让订阅端能够获得额外码率进行更大带宽探测，打破死循环，加快恢复到之前码率。 总结 通过以上机制，SFU不仅保留了Simulcast的灵活性，还具备了端到端拥塞控制能力，让视频会议在复杂网络环境下也能提供接近原生P2P的流畅体验。

前面文章介绍了抖动，今天我们来看下chrome://webrtc-internals/页面中的一个重要统计参数：往返时延（RTT）。 什么是RTT 往返时延(round-trip time，RTT) 是网络请求从起点到目的地然后再回到起点所花费的时长（不包括接收端的处理时间）。RTT是分析网络性能的一个重要指标，我们通常使用RTT来诊断网络连接的速度，可靠性以及拥塞程度。 ping命令是最常见的一种估计往返时延的方法。下面是ping Google的示例，底部显示了rtt的不同表示：最小，平均，最大，平均偏差。 [crayon-69c6cd412532a975015878/] RTT计算方式 WebRTC中目前有两种方式计算RTT： 基于媒体流发送端的计算（默认开启）。通过Sender Report（SR）与Receiver Report（RR）携带的信息。 基于媒体流接收端的计算。通过RTCP Extended ReportsRTCP（XR）携带的信息。 这两种方式计算RTT的原理都一样。至于为什么需要接收端计算方式，这是因为在一些场景，媒体流传输是单向的，两个端点间一个只发媒体数据，一个只接收，例如客户端与SFU服务器间。假设客户端与SFU服务器上行推流场景，客户端推流，服务端收流，这种场景下作为接收端的服务端并不会发送SR，导致无法计算RTT。于是就有了通过RTCP XR在接收端计算这种方式。 媒体流发送端RTT计算 WebRTC中媒体流发送端RTT的计算是根据SR以及RR中携带的时间信息。这里我们回顾下Sender Report与Receiver Report RTCP两种报文。 Sender Report [crayon-69c6cd4125334018655219/] NTP timestamp：64bits。记录着发送该SR的NTP时间戳。 Receiver Report [crayon-69c6cd4125339325185000/] last SR timestamp (LSR): 32 bits。64位NTP时间戳中间的32bit（NTP时间戳指绝对时间，相对1900年1月1日00:00:00经历的时间，单位为秒。完整NTP时间戳用64bits表示，左半32bits表示整数，右半32bits表示小数，一般为了紧凑，取中间32bits表示即可，这时整数与小数分别16bits表示）。记录着上次源SSRC_n发送SR的NTP时间，从收到的SR记录的NTP时间戳获取。如果没有收到SR，值为0。 delay since last SR (DLSR): 32 bits。以1/65536（2^16）秒为单位。记录着上次接收到源SSRC_n发送的SR到当前发送RR的间隔时间。如果没有收到SR，值为0。 计算原理 前面简单介绍了RR中记录的时间信息，下面我们看下如何根据这些时间信息计算RTT。 上图中\(T_{0}\)时刻媒体流发送端发送SR，SR中记录着send_time_ntp。媒体流接收端\(t_{0}\)时刻收到SR，\(t_{1}\)时刻回复RR，RR中记录着：1）从收到的SR中获取的send_time_ntp信息；2）接收端回复RR与收到SR的间隔时间delay_since_last_sr。发送端在\(T_{1}\)时刻收到回复的RR。可知： 代码导读 WebRTC中，发送端首先需要调用ModuleRtpRtcpImpl::OnSendingRtpFrame，这样才能触发发送SR。 接着收到反馈的RR后才能进行RTT计算。WebRTC中发送端RTT计算代码位于RTCPReceiver::HandleReportBlock。 主要代码流程如下： [crayon-69c6cd412533d680693842/] RTCPReceiver::HandleReportBlock中RTT计算代码如下： [crayon-69c6cd4125340777790112/] 结合前面的公式，上面代码应该很好理解。最后得到一个ms表示的RTT，chrome://webrtc-internals/中RTT的单位是秒。 媒体流接收端RTT计算 RTCP XR报文 WebRTC中媒体流接收端RTT的计算是根据XR中携带的时间信息。这里我们看下XR报文格式： [crayon-69c6cd4125343943469593/] 时间信息存放在report blocks中。report blocks格式如下： [crayon-69c6cd4125347398934380/] 接收端RTT计算主要用到了Receiver Reference Time Report Block与DLRR Report Block这两种report blocks。 Receiver Reference Time Report Block(RRTR) 由媒体流接收端发送。报文格式如下： [crayon-69c6cd412534a479115196/] NTP timestamp：64bits。记录着发送该Receiver Reference Time Report Block的NTP时间戳。 DLRR Report Block 由媒体流发送端发送。报文格式如下： [crayon-69c6cd412534d048804411/] last RR timestamp (LRR): 32 bits。记录着上次源SSRC_n发送Receiver Reference Time Report Block的NTP时间，从收到的Receiver Reference Time Report Block记录的NTP时间戳获取。如果没有收到，值为0。 delay since last RR (DLRR): 32 bits。以1/65536（2^16）秒为单位。记录着上次接收到源SSRC_n发送的Receiver Reference Time Report Block到当前发送DLRR Report Block的间隔时间。如果没有收到Receiver Reference Time Report Block，值为0。 计算原理 类似发送端RTT计算，只不过SR变为了Receiver Reference Time Report Block，由媒体流接收端发送。RR变为了DLRR Report Block，由媒体流发送端发送，最后在接收端计算。具体原理这里就不再啰嗦一次了。 代码导读 需要配置接收端ModuleRtpRtcpImpl中RtpRtcpInterface::Configuration的non_sender_rtt_measurement开启XR。 这里以视频为例，配置开启方式如下： [crayon-69c6cd4125350980635002/] 也就是检查SDP中某编码器"a=rtcp-fb"是否含有"rrtr"。例如： [crayon-69c6cd4125353849986322/] 最终这个receiver_reference_time_report配置会传给RtpRtcpInterface::Configuration中的non_sender_rtt_measurement配置项，最后传到RTCPSender中。 媒体流接收端首先发送RRTR，然后收到媒体流发送端反馈的DLRR Report Block进行RTT计算。WebRTC中接收端RTT计算代码位于RTCPReceiver::HandleXrDlrrReportBlock。 主要代码流程如下： [crayon-69c6cd4125356707579709/] RTCPReceiver::HandleXrDlrrReportBlock中RTT计算代码如下： [crayon-69c6cd4125359481851086/] 代码类似前面发送端RTT计算，就不分析了。 注意事项 WebRTC中RTCP XR总是附在SR或者RR后组成Compound RTCP包发送。 总结 本文简单介绍了RTT以及WebRTC中两种RTT的计算，RTT作为网络性能分析的一个重要指标，在WebRTC中扮演一个很重要的角色，至于具体用途，后面有空结合其它再分析。 参考 [1] RFC3550.https://tools.ietf.org/html/rfc3550. [2] RFC3611.https://tools.ietf.org/html/rfc3611.

Transport-cc指的是Transport-wide Congestion Control。WebRTC最新的拥塞控制算法（Sendside BWE）基于Transport-cc，接收端记录数据包到达时间，构造相关RTCP包，然后反馈给发送端，在发送端做带宽估计，从而进行拥塞控制。之所以基于Transport-cc，放到发送端进行带宽估计，除了方便维护，也增加了相关算法的灵活性，因为大多数处理逻辑都放到了发送端。WebRTC中为了使用Transport-cc，需要RTP报头扩展以及相关RTCP的配套支持。这里我们介绍下支撑Transport-cc的RTP以及RTCP。 RTP Header扩展 Transport sequence number 首先我们先来复习下RTP固定报头结构： [crayon-69c6cd4126c19251506426/] 可以看到有一个sequence number字段，用于记录RTP包的序列号。一般情况下我们一个传输通道（PeerConnection）只包含一路视频流，这个sequence number能满足大多数需求。但是在一些情况下，我们一个连接可能传输多个视频流，这些视频流复用一个传输通道，例如simulcast或者single PC场景，一个PeerConnection可能包含多个不同的视频流。在这些视频流中，RTP报头的sequence number是单独计数的。 这里举个例子，假设同一个PeerConnection下，我们传输两个视频流A与B，它们的RTP包记为Ra(n)，Rb(n)，n表示sequence number，这样我们观察同一个PeerConnection下，视频流按如下形式传输： Ra(1),Ra(2),Rb(1),Rb(2),Ra(3),Ra(4),Rb(3),Rb(4) 在对某条PeerConnection进行带宽估计时，我们需要估计整条PeerConnection下所有视频流，而不是单独某个流。这样为了做一个RTP session（传输层）级别的带宽估计，原有各个流的sequence number就不能满足我们需要了。 为此Transport-cc中，使用了RTP报头扩展，用于记录transport sequence number，同一个PeerConnection连接下的所有流的transport sequence number，使用统一的计数器进行计数，方便进行同一个PeerConnection下的带宽估计。 这里我们使用前面的例子，视频流A与B，它们的RTP包记为Ra(n，m)，Rb(n,m)，n表示sequence number，m表示transport sequence number，这样同一个PeerConnection下，视频流按如下形式传输： Ra(1,1),Ra(2,2),Rb(1,3),Rb(2,4),Ra(3,5),Ra(4,6),Rb(3,7),Rb(4,8) 这样进行带宽估计时，通过transport sequence number我们就能关心到这条传输通道下所有数据包的情况了。 RTP transport sequence number报头定义如下： [crayon-69c6cd4126c21600748208/] 由于属于RTP报头扩展，所以可以看到以0xBEDE固定字段开头，表示One-Byte Header类型的扩展。 One-Byte Header相关知识请参考：WebRTC研究：RTP报头扩展 transport sequence number占两个字节，存储在One-Byte Header的Extension data字段。由于按4字节对齐，所以还有值为0的填充数据。 对于同一个PeerConnection下的每个包，这个transport sequence number是从1开始递增的。这里我们看下Wireshark中对带transport sequence numberRTP报头扩展的解析： One-Byte Header中Extension data字段为0x0028，可知该RTP包的transport sequence number为0x0028。 代码导读 WebRTC中，要发送的数据都会经过Pacing模块，用于平滑发送处理，要发送数据会送到pacer thread，在pacer thread中的PacketRouter::SendPacket，对要发送的RTP数据包打上统一计数的TransportSequenceNumber扩展。 [crayon-69c6cd4126c26595816925/] TransportFeedback RTCP 允许接收端向发送端传递有关媒体流传输质量的信息，包括到达时间，丢包信息。 报文格式 Transport-cc中，收流客户端通过TransportFeedback RTCP向发送端反馈收到的各个RTP包的到达时间，丢包信息。首先我们看下TransportFeedback包格式定义： [crayon-69c6cd4126c29352698071/] FMT：5bits。Feedback message type(FMT)固定为15 PT：8bits。由于属于传输层的Feedback Messages，所以payload type(PT)为205 base sequence number:2字节，TransportFeedback包中记录的第一个RTP包的transport sequence number，在反馈的各个TransportFeedback RTCP包中，这个字段不一定是递增的，也有可能比之前的RTCP包小 packet status count:2字节，表示这个TransportFeedback包记录了多少个RTP包信息，这些RTP的transport sequence number以base sequence number为基准 ，比如记录的第一个RTP包的transport sequence number为base sequence number，那么记录的第二个RTP包transport sequence number为base sequence number+1 reference time:3字节，表示参考时间，以64ms为单位，RTCP包记录的RTP包到达时间信息以这个reference time为基准进行计算 feedback packet count:1字节，用于计数发送的每个TransportFeedback包，相当于RTCP包的序列号。可用于检测TransportFeedback包的丢包情况 packet chunk:2字节，记录RTP包的到达状态，记录的这些RTP包transport sequence number通过base sequence number计算得到 recv delta: 8bits，对于"packet received"状态的包，也就是收到的RTP包，在recv delta列表中添加对应的的到达时间间隔信息，用于记录RTP包到达时间信息。通过前面的reference time以及recv delta信息，我们就可以得到RTP包到达时间 packet chunk 首先先了解下RTP包状态，目前定义了如下四种状态，每个状态值2bits，用来标识RTP包的到达状态，以及与前面RTP包的时间间隔大小信息： 00-Packet not received 01-Packet received, small delta 10-Packet received, large or negative delta 11-[Reserved] packet chunk有两种类型，Run length chunk（行程长度编码数据块）与Status vector chunk（状态矢量编码数据块），对应packet chunk结构的两种编码方式。packet chunk的第一bit标识chunk类型。 Run length chunk 这里先来了解下Run length（行程长度）编码。Run length编码是一种简单的数据压缩算法，其基本思想是将重复且连续出现多次的字符使用“连续出现次数+字符”来描述，例如：aaabbbcdddd通过Run length编码就可以压缩为3a3bc4d。Run length chunk中就使用了Run length编码标识连续多个相同状态的包。 Run length chunk第一bit为0，后面跟着packet status以及run length。格式如下： [crayon-69c6cd4126c2c323959467/] chunk type (T):1 bit，值为0 packet status symbol (S):2 bits，标识包状态 run length (L):13 bits，行程长度，标识有多少个连续包为相同状态 下面举例子说明下。 [crayon-69c6cd4126c31776450764/] packet status为00，由前面包状态可知为"Packet not received"状态，run lengh为221（11011101），说明连续有221个包为"Packet not received"状态。 Status Vector Chunk 第一bit为1，后面跟着symbol size以及symbol list。格式如下： [crayon-69c6cd4126c35315959804/] chunk type (T):1 bit，值为1 symbol size(S):1 bit，为0表示只包含"packet not received" (0)以及"packet received"（1）状态，每个状态使用1bit表示，这样后面14bits的symbol list能标识14个包的状态。为1表示使用2bits来标识包状态，这样symbol list中我们只能标识7个包的状态 symbol list:14 bits，标识一系列包的状态, 总共能标识7或14个包的状态 下面举例子说明下。 例子1： [crayon-69c6cd4126c38985350108/] symbol size为0，这样能标识14个包的状态。第一个包状态为"packet not received"（0），接着后面5个包状态为"packet received"（1），再接着三个包状态为"packet not received"，再接着三个包状态为"packet received"，最后两个包状态为"packet not received"。 例子2： [crayon-69c6cd4126c4a108600873/] symbol size为1，这样只能标识7个包的状态。第一个包为"packet not received"（00）状态，第二个包为 "packet received, w/o timestamp"（11）状态，再接着三个包为"packet received"（01）状态，最后两个包为"packet not received"（00）状态。 Receive Delta 以250us(0.25ms)为单位，表示RTP包到达时间与前面一个RTP包到达时间的间隔，对于记录的第一个RTP包，该包的时间间隔是相对reference time的。 如果在packet chunk记录了一个"Packet received, small delta"状态的包，那么就会在receive delta列表中添加一个无符号1字节长度receive delta，无符号1字节取值范围[0,255]，由于Receive Delta以0.25ms为单位，故此时Receive Delta取值范围[0, 63.75]ms 如果在packet chunk记录了一个"Packet received, large or negative delta"状态的包，那么就会在receive delta列表中添加一个有符号2字节长度的receive delta，范围[-8192.0, 8191.75] ms 如果时间间隔超过了最大限制，那么就会构建一个新的TransportFeedback RTCP包，由于reference time长度为3字节，所以目前的包中3字节长度能够覆盖很大范围了 以上说明总结起来就是：对于收到的RTP包在TransportFeedback…

如今越来越多的音视频应用场景采用WebRTC技术，例如视频会议，在线教育，云游戏等。WebRTC包含一套强大的点对点（P2P）通信技术方案，用于音视频传输，本文我们来了解下背后的NAT穿透技术。 什么是NAT NAT(Network Address Translation)指的是网络地址转换，常部署在一个组织的网络出口位置。网络分为私网和公网两个部分，NAT网关设置在私网到公网的路由出口位置，私网与公网间的双向数据必须都要经过NAT网关。位于NAT后的是私网IP地址，分配给NAT的是公网IP地址。NAT通过将私网IP地址映射为公网IP地址，实现私网设备访问外部互联网的能力。组织内部的大量设备，通过NAT就可以共享一个公网IP地址，解决了IPv4地址不足的问题。同时NAT也起到隐藏内部设备，安全防护的作用。 如下图所示，有两个组织，每个组织的NAT分配一个公网IP，分别是1.2.3.4以及1.2.3.5。每个组织私网设备通过NAT将内网地址转换为公网地址，然后加入互联网。通过NAT每个私网设备就不必都需要分配公网IP了，就像图中，一个组织配一个公网IP即可。 NAT问题 虽然NAT解决了IPv4地址耗尽的问题，但是也存在一些问题。首先我们先说下不存在NAT时设备间点对点（P2P）通信情况： 1）位于同一个私网内，可以直接通过内网IP地址通信（例如192.168开头IP地址）； 2）通信双方都有独立的公网IP地址，可以直接通过公网IP地址通信。 但是NAT的存在就不能这样处理了，增加了点对点通信的复杂度。如下图所示： 左边私网地址为192.168.1.100的设备要跟右边组织内的设备进行通信，由于右边组织多台设备共享一个公网IP，所以不能直接通过公网IP地址端口号进行通信，数据发过去了，根本不知道送到哪台设备，这样两个组织内的设备就不具有点对点通信的能力。既然这样，数据要怎么穿过NAT到达私网内，NAT网关要如何转发数据到指定设备呢？ NAT穿透技术 现实生活中，大多数设备都位于NAT后。比如连着同一个基站的移动设备，同一个小区的宽带用户等。NAT的存在使得设备间不能直接进行点对点通信。有时候为了流量节省，以及安全等原因考虑，我们希望不同NAT后的设备也能进行点对点通信，不需要经过第三方的数据转发。为了进行设备间的点对点通信，我们需要使用相关技术检测设备间是否有点对点通信的可能性，以及如何进行点对点通信。这些相关技术就是NAT穿透(NAT traversal)。NAT穿透是为了解决使用了NAT后的私有网络中设备之间建立连接的问题。目前常见的NAT穿越技术、方法主要有： 应用层网关； 中间件技术； 打洞技术(Hole Punching)； Relay(服务器中转)技术。 没有一种完美的NAT穿透，常常是多种技术互相配合，最常见的一种方案是打洞配合中转，例如后面说到的ICE方案。 NAT打洞技术 工作在传输层，最为常见。下面说下基本原理。 NAT网关维护着一张关联表，进行公网/私网地址端口的转换，结构如下所示： 私网IP 公网IP 192.168.1.100:5566 1.2.3.4:9200 192.168.1.101:80 1.2.3.4:9201 192.168.1.102:4465 1.2.3.4:9202 如下图，左边组织的公网IP为1.2.3.4NAT网关收到发到1.2.3.4:1234的数据，假如关联表中还未存在映射关系，NAT对外部发来的数据包直接丢掉。 所以网络访问只能先由私网侧发起，公网无法主动访问私网主机，既然这样，就由私网侧主动点。如下图： 私网地址10.0.0.100的设备发送数据包到公网。NAT网关关联表中创建了该设备私网地址:端口到公网地址:端口的映射，即上图中的10.0.0.100:1234到1.2.3.4:1234。这相当于在NAT上打了一个洞，其它人就可以通过这个“洞”把数据传进来，这就是为什么叫打洞技术了。 接下来，通过某种方式将打好的洞信息：NAT映射后的公网地址：端口告诉要通信那方，要通信那方就向该洞：1.2.3.4:1234发数据。NAT收到发到1.2.3.4:1234的数据，NAT网关在关联表中找到映射，然后转发数据到对应私网设备（10.0.0.100:1234）。 这里我们总结下打洞技术： 1）首先位于NAT后的Peer1节点需要向外发送数据包，以便让NAT建立起私网Endpoint1(IP1:PORT1)和公网Endpoint2(IP2:PORT2)的映射关系； 2）然后通过某种方式将映射后的公网Endpoint2通知给对端节点Peer2； 3）最后Peer2往收到的公网Endpoint2发送数据包，然后该数据包就会被NAT转发给私网的Peer1。 Relay(服务器中转)技术 在有些情况下，打洞会失败（下节介绍），此时只能通过部署在公网的第三方服务器进行数据转发，间接实现通信。 NAT类型 由于存在不同的NAT部署方式，所以产生了不同类型的NAT。 完全圆锥型NAT（Full cone NAT），即一对一（one-to-one）NAT。 一旦一个内部地址（iAddr:port）映射到外部地址（eAddr:port），所有发自iAddr:port的包都经由eAddr:port向外发送。任意外部主机都能通过给eAddr:port发包到达iAddr:port（注：port不需要一样） 受限圆锥型NAT（Address-Restricted cone NAT） 内部客户端必须首先发送数据包到对方（IP=X.X.X.X），然后才能接收来自X.X.X.X的数据包。在限制方面，唯一的要求是数据包是来自X.X.X.X。 内部地址（iAddr:port1）映射到外部地址（eAddr:port2），所有发自iAddr:port1的包都经由eAddr:port2向外发送。外部主机（hostAddr:any）能通过给eAddr:port2发包到达iAddr:port1。（注：any指外部主机源端口不受限制，但是目的端口必须是port2。只有外部主机数据包的目的IP 为 内部客户端的所映射的外部ip，且目的端口为port2时数据包才被放行。） 端口受限圆锥型NAT（Port-Restricted cone NAT）。类似受限制锥形NAT（Restricted cone NAT），但是还有端口限制。 一旦一个内部地址（iAddr:port1）映射到外部地址（eAddr:port2），所有发自iAddr:port1的包都经由eAddr:port2向外发送。 在受限圆锥型NAT基础上增加了外部主机源端口必须是固定的。 对称NAT（Symmetric NAT） 每一个来自相同内部IP与端口，到一个特定目的地地址和端口的请求，都映射到一个独特的外部IP地址和端口。 同一内部IP与端口发到不同的目的地和端口的信息包，都使用不同的映射 只有曾经收到过内部主机数据的外部主机，才能够把数据包发回 如果NAT是完全圆锥型的，那么双方中的任何一方都可以发起通信。如果NAT是受限圆锥型或端口受限圆锥型，双方必须一起开始传输。若有一方位于对称NAT后，就无法打洞成功。由前面说明可知，对于对称NAT来说，客户端向STUN服务器（下节介绍，用于协助打洞）发包映射的公网IP：端口与向其它客户端发包映射的公网IP：端口是不一样的，一个连接创建一个公网的映射，也就是说其它客户端无法使用之前通过STUN服务器打好的洞，所以客户端双方无法成功打洞，只能使用中转方案。 ICE STUN STUN（Session Traversal Utilities for NAT，NAT会话穿越应用程序），是基于UDP的完整的穿透NAT的解决方案，属于我们前面说到的打洞技术。它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的公网端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。STUN是一种Client/Server的协议，也是一种Request/Response的协议，默认端口号是3478。 下面我们通过Wireshark抓包看下是如何Request/Response的。 如下图所示，首先客户端向地址为216.93.246.18的STUN服务器发送Binding Request。 服务器回了Binding Response： 接着我们向地址为216.93.246.15的STUN服务器执行同样操作： 我们看到Binding Response包MAPPED-ADDRESS属性里包含了客户端映射到公网的IP地址以及端口。上图可知两个STUN服务器返回的客户端映射到公网的端口不一样，说明客户端现在位于对称型NAT后，无法进行打洞。 四种主要NAT类型中有三种是可以使用STUN进行穿透：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT，对称型NAT则不能使用，原因前面也说到了。 TURN TURN（Traversal Using Relay NAT，通过Relay方式穿越NAT），是一种数据传输协议。允许通过TCP或UDP方式穿透NAT或防火墙。TURN是一个Client/Server协议。TURN的NAT穿透方法与STUN类似，都是通过取得应用层中的公网地址达到NAT穿透。但实现TURN client的终端必须在通讯开始前与TURN server进行交互，并要求TURN server产生"relay port"，也就是relayed-transport-address。这时TURN server会建立peer，即远端端点（remote endpoints），开始进行中继（relay）的动作，TURN client利用relay port将数据传送至peer，再由peer转传到另一方的TURN client。 TURN主要用在使用STUN无法穿透的场景下，例如前面说到的对称型NAT，只能通过TURN server进行数据中转。 ICE ICE（Interactive Connectivity Establishment，互动式连接建立）。ICE定义了穿越方法而不是协议。ICE整合了STUN与TURN。ICE使得两个NAT后的端点通信更加便捷。ICE使用STUN进行打洞，若失败，则使用TURN进行中转。 下面我们举个应用场景，说下ICE的大概流程。 场景 如下图的应用场景，用户Alice要与Bob进行通信，这两个用户都位于NAT后，公网部署了STUN与TURN服务器。 收集候选地址（candidate） 首先客户端要收集candidate。candidate表示候选地址，由IP地址与端口组成。收集的candidate要与对方的candidate组成candidate pair，进行连通性检查。candidate主要有三种： Host candidate（host）:从本地网卡上获取的地址 Server reflexive candidate（srflx）:STUN server 观察的该客户端的地址 Relay reflexive candidate（relay）:TURN server 为该客户端分配的中继地址 客户端通过向STUN服务器发送STUN数据包，STUN服务器做出回应，告知其在数据包中监测到的IP地址以及端口。 下图中，Alice与Bob通过STUN以及TURN服务器收集了三种类型的candidate。 连通性检查 收集candidate后把通过信令offer与answer方式双方交换candidate，进行candidate两两配对，然后ICE连通性检查。这个连通性检查按一定规则的。 本地的candidate与远端candidate构成的每一对都有一定的优先级，按优先级排序进行连通性检查。 数据传输 最后从有效的candidate组合中选择优先级最高的作为传输地址，用于数据传输。 Trickle ICE 在WebRTC中使用ICE框架进行P2P通信。前面说到ICE中第一步是收集candidate，需要遍历STUN以及TURN服务器，这一步需要耗费很多时间，导致双方建立通信时间很慢。为了解决这一问题，WebRTC引入了Trickle ICE，这样candidate收集以及连通性检查可以同时进行，加快双方建立通信的速度。 libnice库 若要让我们的程序支持ICE，我们可以借助第三方库。常见的支持ICE的库有Libjingle，Libnice。Libjingle集成在WebRTC里，不方便独立使用，这里我们推荐使用Libnice，常见的WebRTC服务器，例如janus，licode都是使用libnice进行P2P通信，具体可访问Libnice官网了解。 总结 本文主要介绍了NAT穿透技术，几种NAT类型，最后介绍了NAT穿透最常用的方案：ICE。通过本文，希望大家对音视频P2P传输中的NAT穿透有一定了解。 参考 [1] P2P技术详解(一)：NAT详解——详细原理、P2P简介.http://www.52im.net/forum.php?mod=viewthread&tid=50&highlight=p2p. [2] 网络地址转换.https://zh.wikipedia.org/zh-hans/网络地址转换. [3] Trickle ICE.https://tools.ietf.org/html/draft-ietf-ice-trickle-21.

使用RTP协议封装数据时，我们可以通过RTP报头的序列号连续性判断是否丢包。但由于RTP报头序列号只有两字节表示，值范围[0,65535]，存在回绕问题（参考之前文章：WebRTC研究：RTP中的序列号以及时间戳比较，建议先阅读一遍此文章）。所以判断序列号连续性时得考虑回绕问题。下面我们就结合WebRTC这相关源码，讲下如何有效地根据序列号进行丢包判断。 首先看下这块代码，代码位于jitter_buffer.cc中： [crayon-69c6cd4128527773450339/] IsNewerSequenceNumber函数以及latest_received_sequence_number_介绍在之前文章说过，读者可参考前面给的文字链接。上述代码丢包判断用到的相关定义如下： IsNewerSequenceNumber：判断是否是最新的序列号 sequence_number：当前收到的包序列号 latest_received_sequence_number_：上一次收到的最新RTP包序列号 missing_sequence_numbers_：存储丢包序列号 丢包判断流程如下： 首先IsNewerSequenceNumber传入当前收到的包序列号sequence_number以及之前收到的最新RTP包序列号latest_received_sequence_number_，判断当前RTP包是否是新的数据包，而不是重传包或者乱序包 在for循环中，从latest_received_sequence_number_ + 1开始判断（因为如果丢包了，两个包序列号间隔大于1），满足IsNewerSequenceNumber(sequence_number, i)则说明i为丢失的RTP包序列号，插入missing_sequence_numbers_中，接着++i继续判断，否则退出 通过如上方法，我们就可以获取那些丢失的包序列号，是不是很简单。

在使用RTP协议时，如果需要网络对抗，保障QoS（Quality of Service，服务质量），我们需要通过序列号以及时间戳的比较，进行丢包判断。但是有个问题，比如一个RTP包，序列号为number1:5000，另一个RTP包序列号为number2:60000，可以说60000一定比5000大，是个更新的RTP包吗？ 当然不是了，首先我们先重温下RTP数据包的结构。 在RFC3550中RTP固定报头结构按如下定义： [crayon-69c6cd41298d9943553206/] 可以看到，RTP序列号sequence number用两字节表示，时间戳timestamp用四字节表示。所以序列号以及时间戳就存在一个取值范围。由于是无符号数，所以序列号范围为：[0,2^16-1]，时间戳范围为：[0,2^32-1]。当达到最大值时，将发生所谓的回绕。例如，序列号到了2^16-1，下个包序列号就将是0。所以我们不能直接根据数学意义上的大小进行序列号以及时间戳的比较。 在WebRTC中定义了一个大小比较算法，包含数字回绕处理，判断是否是更新的数字。下面说下算法原理： 1）假设有两个U类型的无符号整数：value, prev_value； 2）定义一个常量kBreakpoint，为U类型取值范围的一半； 3）value > prev_value，满足value - prev_value = kBreakpoint时，value大于prev_value； 4）value与prev_value不相等，满足(U)(valude - prev_value) < kBreakpoint时，value大于prev_value。 总结起来就是value与prev_value距离小于取值范围的一半且不相等或者value与prev_value距离等于取值范围的一半，value大于prev_value，就可以说明value大于prev_value。 在modules\include\module_common_types_public.h，相应代码如下： [crayon-69c6cd41298e2924247677/] 顺便也说下如上函数的一个应用。在WebRTC丢包重传判断中（jitter_buffer模块），需要保存上一次收到的最新RTP序列号latest_received_sequence_number_，以便用于丢包判断（请参考：WebRTC研究：丢包判断），这个RTP包必须是新的数据，不能是重传的旧数据。所以每来一个RTP包时，可以将该RTP包序列号传入如上函数，与之前收到的最新RTP序列号进行对比，从而判断当前RTP包是不是最新的。相应代码如下： [crayon-69c6cd41298e7476477251/] 参考 [1].rfc1982.https://tools.ietf.org/html/rfc1982