端到端通信的一个主要问题是，在许多情况下，这些端点并不在公共互联网中，而是位于网络（和端口）地址转换器（NAT）后面的专用地址空间中。随着互联网从DARPA项目发展成为全球范围的网络，很快就会明白IPv4的232地址空间早晚会用尽。
在20世纪90年代，开发了多种策略来延迟IPv4地址耗尽的时间，其中之一就是NAT的设计。NAT将端点的真实IP地址隐藏于世界其他地方，这使得端点之间建立端到端直接连接变得困难。这就是协助框架—包括STUN和TURN（或使用中继NAT穿越）—派上用场的地方。
平均约有30%的P2P会议有一个端点通过TURN服务器连接。如果没有TURN中继服务器的帮助，这些用户将无法进行通信。因此，开发者需要知道TURN服务器是什么，以及为什么它对WebRTC通话的重要性。
ICE和STUN
我周二登录了一次YouTube，注意到右上角有一个新的摄像头图标，并写着“Go Live（New）”，所以我点了一下它试试看会发生什么。事实证明，你现在可以直接从浏览器进行直播。这听起来真的很像WebRC，所以我加载了chrome://webrtc-internals来查看，并确定它就是WebRTC。我们总是对大规模部署很好奇，所以我立即请WebRTC逆向工程大师Philipp “Fippo” Hancke进行更深入的调查。本文剩下的部分就是他对此的分析。— 编辑：chad hart
NAT和点对点通讯：有何问题？
虽然客户端或服务器能够通过NAT /防火墙顺利连接，但这样的操作会对点对点通信造成严重破坏。点对点通信通常由端点应用程序打开，或用主机操作系统上的特定IP端口侦听。之后该端口可以与准备交换数据的另一台主机发信号或进行通信。应用程序中，点对点IP端口发出的指令通常用服务器或其他对等体发现机制来完成，与实际的点对点数据有所区分。示例如下：
什么是NAT？
NAT意为网络地址转换（https://en.wikipedia.org/wiki/Network_address_translation）。它是一种广泛使用的系统，多用于保留IPv4地址，或使本地网络管理员能够控制本地拓扑结构。实际上NAT技术多种多样，在此不多赘述。最常见的NAT设备通过改变通过它的数据包的IP报头信息得以运行。通常情况下NAT技术与防火墙结合完成，大多数家用路由器都如此，这些路由器通常在保证安全性的同时还保留了IPv4的地址空间，可谓一举两得。但正如我们所见，这也可能导致某些程序和协议出现问题，尤其是像WebRTC这样尝试进行点对点连接的。
常见的NAT 或者防火墙场景是私人或受保护的IP端点子网的场景，与公共互联网的环境不同。
WebRTC直播流中，大规模所带来的挑战
1:1 != 1:1,000,000
只要是关于WebRTC的问题，规模有影响。
人们常常有这种想法，如果我能够运行一个1对1的视频通话，那么把它改进成一个三方视频通话也很简单。如果有了三方通话，那么距离四方通话也只有一步之遥了。假如我们已经到了四个人同时通话的地步，既然4和10之间没差多少，所以10个人通话肯定也是一样的。如果我们可以进行10人通话了，那么50人，甚至100人是不是也没问题了？
处理多用户之间的互动通话的做法放在实时广播方面也是正确的。
1对1的广播与1对100不同，当然与1比10,000与1比1,000,000也不同。
一个字回答：要。
这是我这个星期经常被问到的问题。答案也很简单—是的，需要。
接着我收到了一个没有预料到的提问：
为什么需要？
这有点让我措手不及。倒不是因为我不知道答案。而是因为我不知道如何用简短的文字来回答他。我想这也不是一个简单的问题。
简单的答案是资源的限制，以及我们不控制大部分这些资源的事实。
在开发流媒体服务器时，rtp数据如何在服务器之间转发，对于降低音视频延时和丢包有很重要的影响。
我设想了一种可以降低音视频延时的转发方案。思想来源于IP协议的路由表选路算法。
我们经常说tcp和udp的区别是，tcp是有连接的，udp是无连接的。
网络视频直播存在已有很长一段时间，随着移动上下行带宽提升及资费的下调，视频直播被赋予了更多娱乐和社交的属性，人们享受随时随地进行直播和观看，主播不满足于单向的直播，观众则更渴望互动，直播的打开时间和延迟变成了影响产品功能发展重要指标。那么，问题来了：如何实现低延迟、秒开的直播？
先来看看视频直播的5个关键的流程：录制->编码->网络传输->解码->播放，每个环节对于直播的延迟都会产生不同程度的影响。这里重点分析移动设备的情况。受限于技术的成熟度、硬件环境等，我们针对移动场景简单总结出直播延迟优化的4个点：网络、协议、编解码、移动终端，并将分四期来一一解密UCloud直播云实现低延迟、秒开的技术细节。
本文主要讲述UCloud直播云实现接入网络优化的技术细节。
投屏技术已经被大量用在身边的产品, 比如电视投屏, 投影仪, 视频会议产品中. 在iOS平台外的其他平台中都已经有非常成熟的标准和实现. 但在封闭的苹果iOS和Mac系统中, 苹果使用私有的Airplay协议进行多屏互动,
只开放给自己生态中的产品. 对此相关技术限制比较严格，甚至在iOS9中加上了更严格的加密算法, 直接导致很多投屏的产品不可用.
iOS中的投屏方案:
1, ReplayKit
iOS9中引入了ReplayKit, 让开发者有了一定的获取屏幕数据的能力. 并在iOS10和iOS11中继续扩展了ReplayKit的能力. 但还是有很大的限制, 比如在使用ReplayKit的api时只能录制当前应用的应用, 无法在应用进入后
台之后继续录屏. 如果使用系统级别的屏幕录制,又无法获得每一帧的数据,只能获得最后录取的单个视频. 这样对第三方的开发有了非常大的限制.
2, Airplay
Airplay是苹果提供的一种多屏互动技术, 可以将音频照片,视频, 屏幕从iOS设备或者Mac电脑上投射到支持airplay接受的设备上，如Apple TV。这样可以将小屏映射到大屏，可以无线音乐，可以图片分享等等.
但是Airplay属于苹果私有协议方案，设备间的协商与传输过程都进行了加密处理，并不能用于其他平台中。我们已经完整的逆向了Airplay的全部协议栈，并破解了其加密方案，可以提供跨平台Airplay接收方案。
这样可以方便实现跨平台的多屏共享。
同时，通过研究，我们也可以通过Airplay Mirroring技术，做到在iPhone上把自己的屏幕的内容投送给当前iPhone，在某些情况下这种airplay的破解却非常有用处,比如手游直播。
这中投屏方案使用了iOS原生的投屏能力，并且是完全的软件方案，非常方便进行集成和使用。
下面将介绍Airplay Mirroring接收端的实现原理，并揭示相关协议交互过程。