Cirrus翻译.docVIP

Cirrus翻译Adobe Flash Player 10 and Adobe AIR 1.5 采用了一个新的通信协议，实时媒体流协议（RTMFP），因为它的低延迟，点对点的能力，安全和可扩展性，非常适合开发实时协同应用程序，能极大的提高用户体验和降低费用。 早期的版本的 Flash Player 使用了实时消息协议 (RTMP)和Flash媒体服务器Adobe Flash Media Server (FMS)来进行协同应用程序的音频视频流的交互，比如 Adobe Acrobat Connect Pro)。虽然实时消息协议对媒体流，共享对象和远程对象来说，是一个优秀的选择，但对于实时会议的音频和视频交互还是很有局限性的。 为了使用RTMFP，Flash Player终端必须连接到实时媒体流服务器RTMFP-capable server，之前版本的实时媒体流服务器叫Stratus，先以改名为Cirrus，新版的Flash Media Server 4也具有实时媒体流服务器功能。两个Flash Player终端通信服务在Cirrus处汇合，Cirrus于FMS不同是地方是，Cirrus不提供媒体延时，共享对象，脚本等等。所以使用Cirrus，开发出来的程序只能实现两个Flash Player终端直接通信的功能。 Flash Player在网络视频市场上已经占据了绝对的领导地位，借助于实时媒体流协议和高级视频压缩技术， Flash Player 10也同样定位于领导实时通信上。 下面的章节，将首先强调RTMFP在实时通信程序里的优势，然后描述用于管理直接点对点的RTMFP连接的新的ActionScript 3 API 。最后会有一个实例。 RTMFP的优势 Real-Time Media Flow Protocol (RTMFP)实时媒体流协议是一个包含在Flash Player 10和AIR 1.5环境里的新的通信协议，它与实时消息协议 (RTMP),最大的区别在于，RTMP是构筑在传输控制协议层TCP，而RTMFP是构筑在用户数据协议层UDP。 TCP提供可靠的数据传输，点对点的数据传输不能有延时。在TCP里的可靠数据传输采用往返时延机制实现对丢失数据的重新传输。TCP为了保证不发生丢包，就给每个字节一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。实时通信是以最小化的延时为的目标的，几百微妙的延时将造成一个会议没法进行，而TCP对于这点来说是不适合的。并且通信错误的复原和恢复的一个主要部分，高级音视频压缩算法，像Speex音频和 H.264视频编码都已经包含在Flash Player 10里面，因此TCP提供的可靠传输已经不需要了。所以，UDP能提供有效和快速的数据传输，别广泛的用于了以最小延迟为主要目标的实时协同程序里。UDP的另外一个优势在于它能穿透路由让两个终端之间直接进行数据传递。 于实时消息协议相比，实时媒体流协议在实时通信方面有着以下优点：低延迟：RTMFP是建立在UDP层，实时通信是有着最小的延迟，值得注意的是，RTMFP能提供可靠和不可靠的服务，当在两个Flash Player之间发送数据时，如果使用NetStream.send()时，使用的是可靠传输。当在两个Flash Player之间发送Speex音频时，使用的是不可靠传输，尽可能保证最小的延迟。 点对点媒体传输：媒体在实体之间直接传递，而不需要经过中间层服务器的路由。于RTMP相比，所有的数据都是通过FMS中转的。RTMFP 不仅是减少终端和终端之间的延迟，而且可以消除中间数据传输所造成的延迟，同时它的配置可伸缩性也很强。 数据优化：音频传输会优先于视频传输和其他数据(如即时消息)，在有限带宽的条件下，能有效的增强用户体验。 所有这些特性显示了对于实时通信的极大好处，于以前版本所达到效果上相比，这对用户体验无疑是一个很大的提高。 防火墙穿越 RTMFP建立在UDP基础之上，能在两客户端直接建立连接，甚至是位于NAT或是防火墙之后。要使用RTMFP，你必须把你的防火墙配置成允许外部UDP通行。事实上很多用户，办公室或家庭的防火墙，很多的公司的防火墙都阻止UDP通行。 我们的解决方案是配置Flash Player使用代理(利用中继穿行NAT)，Flash Player支持IETF互联网草案而不需要认证。 如果网络管理员设置代理允许放行UDP，Flash Player可以如下配置。 RTMFPTURNProxy = ip_address_or_hostname_of_TURN_proxy 直接U