近年来，科技发展蓬勃。网络由原先的56k modem，演进为ADSL甚至光纤。带宽造成了需求的逐步升级，从纯文本的telnet数据、混着midi与图片的www网站、到现在的mp3音乐以及flash。这份影响也造成了以影片为主的数字服务渐渐普及， Youtube为首的影片分享服务已随处可见，而我们对各公司网站中使用flash动画也早已习以为常。在这同时，只要你有Web Cam，你就可以透过各种软件来做双向的视讯交谈。
RTSP/RTP/RTCP[1][2]三种协议所提供的也是种网络应用。除了预录像片外，他们还可以实时传输实况，或做为数字监控系统之用。另外，这些协议也支持网络会议／多方会谈。
RTSP等一开始出现是在1998年。经过数年的培养，此协议已经获得各方的采用以及承认，连微软都在近几年将Windows Media Player预设接收的协议由MMS改为RTSP。但在使用RTSP的应用逐渐增加的此时，如何避免在一对多的大量单向Streaming传输中浪费带宽，就成为重要的课题。此文的目的即为阐述设想出来的问题，并列出目前可见之改善方法。
以下首先将简述RTSP/RTP/RTCP等协议的功用以及行为模式，并描述一个普通的RTSP/RTP/RTCP Unicast联机的流程。接着，讲述Unicast的缺点，以及数个Multicast的作法以及其优缺点。
RTSP/RTP/RTCP概要
Real Time Streaming Protocol (RTSP)
RTSP是种控制Session的协议，由rfc2326订定详细内容，作用为提供访客关于此uri的相关资源明细、设定联机使用的port、控制RTP等协议起始／终止传输动作。传输通常使用port 554，内容使用明文编码，语法则类似HTTP（但是有部分为RTSP特有）。由于需要正确性且不强求实时性，RTSP通常使用TCP来传递。
RTSP本身没有加密的机制，但是有额外的认证作法。由于语法极其相似，rfc2617描述的HTTP Authentication[3]同样适用于RTSP。HTTP Authentication包括两种Scheme，Basic与Digest。前者的认证缺乏防盗等等安全措施，但后者可使用md5来加强保密性，并且有机制避免各种常见的网络攻击方法。
Real-time Transport Protocol (RTP)
相对于RTSP是种控制session的协议，RTP就是实际在运送影音数据的协议，而RTCP的工作是确认RTP传输中途封包是否疑失等细节。两者皆由rfc3550制定。
由于要求影音数据的实时性，RTP跟RTCP通常使用UDP来传输。为了穿越防火墙，spec中也有订定关于如何使用TCP来传递RTP/RTCP（但是是制定于rfc2326，也就是RTSP的Spec[1]）。现在似乎有称之为SRTP的加密过之RTP协议，但尚未普及。
RTP与RTCP的port，在UDP下为Client与Server透过RTSP协商决定。TCP时，所有的RTP/RTCP与RTSP共享同一个port与socket。
各厂商对RTSP/RTP的采用
Microsoft原本有自己的Microsoft Media Server (MMS)，但于2003年起Microsoft已将建议优先采用RTSP而非MMS，且在联机时若没有指明连接协议，则先尝试RTSP后MMS[4]。Apple的Darwin Streaming Server从1999年开始释出，为功能完整的Open Source RTSP/RTP Server，支持H264/MPEG-4 AVC, MPEG-4 Part 2跟3GP[5]。Real的Helix DNA Server与DNA Client目前也都支持RTSP/RTP[6]。
目前主流大厂的Streaming Server / Client几乎都支持，即使原本有自家独有格式的也于后来采纳RTSP/RTP，可看出这些协议已被广为采用。
Unicast与各种Multicast
以下为4种:
以RTSP/RTP/RTCP联机时之基本流程
一个最基本的RTSP/RTP/RTCP联机之流程如下。首先，Client以RTSP之DESCRIBE指令或HTTP等管道得知此uri的资源详细（比如：有无Video/Audio、压缩格式等等）。
接着Client以SETUP指令跟Server沟通，设定传输的ip跟port。注意这边的IP可以不用跟Client相同，而且可以是后述的IP Multicast地址。
再来下PLAY指令，Server开始传送RTP封包运送影音媒体数据至Client所指定的地址与port，并以RTCP来侦测封包lost等状况。当Client想要结束时，他送出TEARDOWN来指示Server停止并结束这个Session。
由此流程可以看出，RTSP/RTP/RTCP的基本沟通流程是
1. 先以RTSP沟通，确认传输模式，而后开始RTP/RTCP。
2. 主从（Client-Server）式，由Client提出要求，Server接受与响应。
Unicast
Unicast指的是一对一单向的传输模式。以Server-Client架构来说，Server对每个Client都有一个联机，并都传输一份数据。SETUP阶段指定的IP即为Client自己的IP。
这种作法的优点是Server可以轻易对每个Client进行认证，并在传输的数据上进行微调。但是缺点是每增加一个Client，Server对外的流量就得增加一份。假设Server每秒对各个Client送300k的资料，则一个有1000个Client的Server就需要每秒300MB的上传带宽。在送给每个人的数据完全相同的状况下，这是非常浪费的。
Unicast在很多状况下还是很好的作法，但是若一个Streaming Server有大量的Client且需要传输的数据都相同，无谓消耗的带宽可能让人头痛不已。
由于一份Unicast只牵扯一个Client跟一个Server，可以说是最容易实做的联机方式，目前VLC、QuickTime都有支持RTSP/RTP/RTCP的Unicast。微软的Windows Media Player也有支持，但是接受的Video/Audio格式是他们自家的wmv/wma。
IP Multicast
相对于Unicast，IP Multicast则是种一对多的传递方式。IP Multicast在网络上有众多的Group，Client可透过IGMP这种Protocol来加入／离开各Group。只要SETUP阶段要求将封包送往Group的代表地址，Group就会把这些封包自动送至各Client。
由于Server送往Group的数据只会有一份，所以IP Multicast是解决了 Server无谓浪费带宽的状况，但也有一些其他的问题。姑且不论Scalability方面的困难，IP Multicast在商业上最大的问题就是：Server无法管制Client的数目与身份，甚至无法得知现在有多少Client正在收取封包。既然无法管制Client的加入或离开以及确定目前有哪些人在收听，就无法确立收费机制，也无法防止白吃白喝。
由于这种机制很早就已出现，所以RTSP等的Spec也有提供对IP Multicast的支持。另外虽然说在商业层面上有上述缺点，但IP Multicast在小型封闭网络中仍旧是个相对容易实做且低成本的Multicast作法。
Peer to Peer (P2P)
P2P代表的是Peer to Peer，亦即数据并非完全从Server直接传至Client，Client也可能互相索取数据。Server可能只把数据传给几个主要的Client，再由这些Client散拨出去。
P2P最大的问题是可能会有较大的延迟，以及不稳定性。由于很多情况下数据需要从其他Client要过来，而每个Client上线下线进进出出是很正常的，如何确保“即使原先作为来源的Client断线依旧能稳定传输”就变成一个很重要的问题。
一种作法是，数据收到不是马上拨，而是储存一小段时间的影音数据做为缓冲。比如说，假设缓冲里面有10秒的数据，则一旦原本来源的Client断线，就有10秒的时间去寻找新的来源Client。这种作法在观看预录像片很实用，但在观看实时影像时会多少受到点限制，因为实时影像能够使用的“缓冲”量比起预录像片明显不足。预录像片也许可以先为未来10分钟甚至更久的影音先去找人要到数据，但实时影像就不行－数据是实时产生的。如果延迟太久，就会降低实时的意义。
另一个问题是P2P这种结构跟RTSP默认的Server-Client架构格格不入－RTSP并没有Client互相传送数据的行为模式。要达到P2P，Client跟Server都得有大幅度的变动。
但P2P的优点就是成本：带宽需求较unicast小，而且也不需要额外的硬件成本。另外只要在软件上小心的设计，是可以建立一套可行的收费机制的（比如说，Client必须付月费才能连到主Server得知附近其他Client的位置，才能跟他们要数据…这样）。
Relay Server
最后一种作法是所谓的Relay Server。一个Relay Server位于一块局域网络之中（比如：公司内部网络、电信业者的手机的内部网络）。数据首先由主Server送至Relay Server，然后若局域网络内的Client想要联机的话，就跟他范围内的Relay Server要，由Relay Server将数据送给各Client。
这种做法看似很像IP Multicast，不过不一样的是Relay Server不是一个网络已经固定的机制，可以依照Server撰写者的意思来执行。比如说：该局域网络的认证机制，以及实时的Transcoding都由Relay Server来进行。亦即它拥有IP Multicast的优点，但是有更好的弹性。而虽然这样Relay Server出去的流量依旧很大，但是是在局域网络内，可以避免消耗在Internet上的流量。另外事实上主Server到Relay Server，以及Relay Server到Client都是unicast，现行的Client可以不用修改即可联机，而Server也可某种程度重复利用现有产品。
Relay Server的问题就是－建构成本。既然Relay Server有如此高的弹性，那该Server就一定得由主Server的建构厂商去分布，而不像IP Multicast可以利用网络现有资源。另外Relay Server不架在局域网络内，就没有省流量的意义了，因此在Internet上并不容易适用。
优劣总结
总合来讲，目前Multicast的3种作法：
● IP Multicast：低成本，Spec已有明确定义，但难以确认使用者状况，很难找出商业模式。仍旧能适用于小型封闭的网络。
● P2P：低成本，需克服延迟与不稳定性的问题。另外RTSP无法直接套用在P2P上，无法利用现有的Player与Server。
● Relay Server：相对来讲高成本，且适合局域网络，直接在Internet上使用对节省流量来讲效果不彰。但由于传输上都是Unicast的接口，可使用现有的Player以及部份Server。适用于RTSP的Spec，且可兼作认证以及影音数据的再处理。
并没有哪种完全的优于其他的作法。有可能得依照环境、应用需求以及顾客状况来决定使用哪种会比较好。
RTSP/RTP/RTCP[1][2]三种协议所提供的也是种网络应用。除了预录像片外，他们还可以实时传输实况，或做为数字监控系统之用。另外，这些协议也支持网络会议／多方会谈。
RTSP等一开始出现是在1998年。经过数年的培养，此协议已经获得各方的采用以及承认，连微软都在近几年将Windows Media Player预设接收的协议由MMS改为RTSP。但在使用RTSP的应用逐渐增加的此时，如何避免在一对多的大量单向Streaming传输中浪费带宽，就成为重要的课题。此文的目的即为阐述设想出来的问题，并列出目前可见之改善方法。
以下首先将简述RTSP/RTP/RTCP等协议的功用以及行为模式，并描述一个普通的RTSP/RTP/RTCP Unicast联机的流程。接着，讲述Unicast的缺点，以及数个Multicast的作法以及其优缺点。
RTSP/RTP/RTCP概要
Real Time Streaming Protocol (RTSP)
RTSP是种控制Session的协议，由rfc2326订定详细内容，作用为提供访客关于此uri的相关资源明细、设定联机使用的port、控制RTP等协议起始／终止传输动作。传输通常使用port 554，内容使用明文编码，语法则类似HTTP（但是有部分为RTSP特有）。由于需要正确性且不强求实时性，RTSP通常使用TCP来传递。
RTSP本身没有加密的机制，但是有额外的认证作法。由于语法极其相似，rfc2617描述的HTTP Authentication[3]同样适用于RTSP。HTTP Authentication包括两种Scheme，Basic与Digest。前者的认证缺乏防盗等等安全措施，但后者可使用md5来加强保密性，并且有机制避免各种常见的网络攻击方法。
Real-time Transport Protocol (RTP)
相对于RTSP是种控制session的协议，RTP就是实际在运送影音数据的协议，而RTCP的工作是确认RTP传输中途封包是否疑失等细节。两者皆由rfc3550制定。
由于要求影音数据的实时性，RTP跟RTCP通常使用UDP来传输。为了穿越防火墙，spec中也有订定关于如何使用TCP来传递RTP/RTCP（但是是制定于rfc2326，也就是RTSP的Spec[1]）。现在似乎有称之为SRTP的加密过之RTP协议，但尚未普及。
RTP与RTCP的port，在UDP下为Client与Server透过RTSP协商决定。TCP时，所有的RTP/RTCP与RTSP共享同一个port与socket。
各厂商对RTSP/RTP的采用
Microsoft原本有自己的Microsoft Media Server (MMS)，但于2003年起Microsoft已将建议优先采用RTSP而非MMS，且在联机时若没有指明连接协议，则先尝试RTSP后MMS[4]。Apple的Darwin Streaming Server从1999年开始释出，为功能完整的Open Source RTSP/RTP Server，支持H264/MPEG-4 AVC, MPEG-4 Part 2跟3GP[5]。Real的Helix DNA Server与DNA Client目前也都支持RTSP/RTP[6]。
目前主流大厂的Streaming Server / Client几乎都支持，即使原本有自家独有格式的也于后来采纳RTSP/RTP，可看出这些协议已被广为采用。
Unicast与各种Multicast
以下为4种:
以RTSP/RTP/RTCP联机时之基本流程
一个最基本的RTSP/RTP/RTCP联机之流程如下。首先，Client以RTSP之DESCRIBE指令或HTTP等管道得知此uri的资源详细（比如：有无Video/Audio、压缩格式等等）。
接着Client以SETUP指令跟Server沟通，设定传输的ip跟port。注意这边的IP可以不用跟Client相同，而且可以是后述的IP Multicast地址。
再来下PLAY指令，Server开始传送RTP封包运送影音媒体数据至Client所指定的地址与port，并以RTCP来侦测封包lost等状况。当Client想要结束时，他送出TEARDOWN来指示Server停止并结束这个Session。
由此流程可以看出，RTSP/RTP/RTCP的基本沟通流程是
1. 先以RTSP沟通，确认传输模式，而后开始RTP/RTCP。
2. 主从（Client-Server）式，由Client提出要求，Server接受与响应。
Unicast
Unicast指的是一对一单向的传输模式。以Server-Client架构来说，Server对每个Client都有一个联机，并都传输一份数据。SETUP阶段指定的IP即为Client自己的IP。
这种作法的优点是Server可以轻易对每个Client进行认证，并在传输的数据上进行微调。但是缺点是每增加一个Client，Server对外的流量就得增加一份。假设Server每秒对各个Client送300k的资料，则一个有1000个Client的Server就需要每秒300MB的上传带宽。在送给每个人的数据完全相同的状况下，这是非常浪费的。
Unicast在很多状况下还是很好的作法，但是若一个Streaming Server有大量的Client且需要传输的数据都相同，无谓消耗的带宽可能让人头痛不已。
由于一份Unicast只牵扯一个Client跟一个Server，可以说是最容易实做的联机方式，目前VLC、QuickTime都有支持RTSP/RTP/RTCP的Unicast。微软的Windows Media Player也有支持，但是接受的Video/Audio格式是他们自家的wmv/wma。
IP Multicast
相对于Unicast，IP Multicast则是种一对多的传递方式。IP Multicast在网络上有众多的Group，Client可透过IGMP这种Protocol来加入／离开各Group。只要SETUP阶段要求将封包送往Group的代表地址，Group就会把这些封包自动送至各Client。
由于Server送往Group的数据只会有一份，所以IP Multicast是解决了 Server无谓浪费带宽的状况，但也有一些其他的问题。姑且不论Scalability方面的困难，IP Multicast在商业上最大的问题就是：Server无法管制Client的数目与身份，甚至无法得知现在有多少Client正在收取封包。既然无法管制Client的加入或离开以及确定目前有哪些人在收听，就无法确立收费机制，也无法防止白吃白喝。
由于这种机制很早就已出现，所以RTSP等的Spec也有提供对IP Multicast的支持。另外虽然说在商业层面上有上述缺点，但IP Multicast在小型封闭网络中仍旧是个相对容易实做且低成本的Multicast作法。
Peer to Peer (P2P)
P2P代表的是Peer to Peer，亦即数据并非完全从Server直接传至Client，Client也可能互相索取数据。Server可能只把数据传给几个主要的Client，再由这些Client散拨出去。
P2P最大的问题是可能会有较大的延迟，以及不稳定性。由于很多情况下数据需要从其他Client要过来，而每个Client上线下线进进出出是很正常的，如何确保“即使原先作为来源的Client断线依旧能稳定传输”就变成一个很重要的问题。
一种作法是，数据收到不是马上拨，而是储存一小段时间的影音数据做为缓冲。比如说，假设缓冲里面有10秒的数据，则一旦原本来源的Client断线，就有10秒的时间去寻找新的来源Client。这种作法在观看预录像片很实用，但在观看实时影像时会多少受到点限制，因为实时影像能够使用的“缓冲”量比起预录像片明显不足。预录像片也许可以先为未来10分钟甚至更久的影音先去找人要到数据，但实时影像就不行－数据是实时产生的。如果延迟太久，就会降低实时的意义。
另一个问题是P2P这种结构跟RTSP默认的Server-Client架构格格不入－RTSP并没有Client互相传送数据的行为模式。要达到P2P，Client跟Server都得有大幅度的变动。
但P2P的优点就是成本：带宽需求较unicast小，而且也不需要额外的硬件成本。另外只要在软件上小心的设计，是可以建立一套可行的收费机制的（比如说，Client必须付月费才能连到主Server得知附近其他Client的位置，才能跟他们要数据…这样）。
Relay Server
最后一种作法是所谓的Relay Server。一个Relay Server位于一块局域网络之中（比如：公司内部网络、电信业者的手机的内部网络）。数据首先由主Server送至Relay Server，然后若局域网络内的Client想要联机的话，就跟他范围内的Relay Server要，由Relay Server将数据送给各Client。
这种做法看似很像IP Multicast，不过不一样的是Relay Server不是一个网络已经固定的机制，可以依照Server撰写者的意思来执行。比如说：该局域网络的认证机制，以及实时的Transcoding都由Relay Server来进行。亦即它拥有IP Multicast的优点，但是有更好的弹性。而虽然这样Relay Server出去的流量依旧很大，但是是在局域网络内，可以避免消耗在Internet上的流量。另外事实上主Server到Relay Server，以及Relay Server到Client都是unicast，现行的Client可以不用修改即可联机，而Server也可某种程度重复利用现有产品。
Relay Server的问题就是－建构成本。既然Relay Server有如此高的弹性，那该Server就一定得由主Server的建构厂商去分布，而不像IP Multicast可以利用网络现有资源。另外Relay Server不架在局域网络内，就没有省流量的意义了，因此在Internet上并不容易适用。
优劣总结
总合来讲，目前Multicast的3种作法：
● IP Multicast：低成本，Spec已有明确定义，但难以确认使用者状况，很难找出商业模式。仍旧能适用于小型封闭的网络。
● P2P：低成本，需克服延迟与不稳定性的问题。另外RTSP无法直接套用在P2P上，无法利用现有的Player与Server。
● Relay Server：相对来讲高成本，且适合局域网络，直接在Internet上使用对节省流量来讲效果不彰。但由于传输上都是Unicast的接口，可使用现有的Player以及部份Server。适用于RTSP的Spec，且可兼作认证以及影音数据的再处理。
并没有哪种完全的优于其他的作法。有可能得依照环境、应用需求以及顾客状况来决定使用哪种会比较好。
