流媒体是一种新的媒体传输方式，而非新的媒体形式；如果矫情地说，流媒体并不是一种技术，而是采用了流式传输技术的视频实现手段。流媒体（SM，Stream Media）技术就是把连续的影像和声音信息经过压缩处理后放到网络服务器上，让终端用户能够一边下载一边观看、收听，而不需要等到整个多媒体文件下载完成才观看的技术。
流媒体的核心在于流式传输技术。流，在《说文解字》里的意思为“流，水行也”，也就是说，水运动的方式为“流”。因此，流式传输技术就是指让互联网的信息表现形式如同水流一样传输的技术。水流的特点是什么呢？源源不断，“逝者如斯，不舍昼夜”。传统互联网上的媒体是以包的方式由服务器向客户端进行传输的，媒体内容先进行拆包，分发到各个路由器上，传输到终端后再按照规则合并，这就造成了无法形成“源源不断”的播放。因此，人们想出了应用于互联网的流式传输技术，在这个技术中定义了专门的规则协议、文件格式和服务器，通过这些规则协议来保证媒体传输的“源源不断”。
这里，为了方便读者理解，可以用一个很有意思的比方来解释流式传输与分组传输的区别，即当前国际上的石油运输：传统互联网服务就好比将石油输出国的石油分包到一艘艘油轮，然后经过航道(航道就代表了互联网络)运送到用油国家的港口，之后再卸货运送到精炼厂或储油厂；而流式技术则是在两个国家之间建立一条输油管，这样石油就可以“源源不断”流向用油国家(管道中间的关键控制开关以及石油精炼厂、储油厂等设施就好比协议和服务器等要素)。流式传输技术存在两种实现方法：顺序流传输、实时流传输。
一、顺序流传输(Progressive Streaming)
顺序流传输也称渐进流式传输，实际上是顺序下载，并在下载文件的同时可让用户观看在线媒体。这种技术实现方式并不需要增加任何协议和新的服务器，而是沿用了互联网的HTTP服务器及Web服务器，利用了现存的基础设施。其与完全下载后播放的差别在于客户端播放器的运作，顺序流传输可以在下载的同时启动播放器播放媒体。由于标准的HTTP服务器可发送这种形式的文件，也不需要其他特殊协议，因此它经常被称做HTTP流式传输。因此，这种流式传输技术并没有对传输通道和传输协议做改动，而只是在末端采用了渐进下载播放的功能，从用户角度看上去好像实现了“流”的感觉，而实际上传输机制并未实现真正意义的“源源不断”。
因此顺序流传输的问题自然浮出水面，其表现详见下表1中的三个方面。于是，技术设计师们会自然而然地想到了一个新的问题：能否在互联网上采用新的办法来真正实现“流”的传输，以提供给用户真实的“流”的感受？21世纪初，3个重量级公司Microsoft、Apple和Real Networks设计了构思巧妙的实时流传输技术。
表1：顺序流传输的问题表现
二、实时流传输(Realtime Streaming)
实时流传输通过采用一系列手段(协议、文件格式、服务器端)保证了媒体的实时性和连续性。实时流与顺序流传输不同，它需要专用的流媒体服务器与传输协议。
1、流媒体服务器
流媒体服务器比当前普遍使用的Web服务器更熟悉流媒体的特点，拥有符合流媒体特点的技术，采用适合流媒体特点的协议。这就好比一个饭店原来由鲁菜厨师掌勺，但是发现顾客爱吃麻辣口味，初期可以让鲁菜厨师先做川菜，但是这种做法往往不能满足顾客的胃口(鱼香肉丝做出了京酱肉丝的味道)，因此必须再聘请一个川菜师傅才能让顾客满意，因为川菜师父这个“服务器”拥有符合麻辣口味的技术。
流媒体服务器具备采用多种应用层协议(OSI的第4层)的能力，特别是可以使用UDP(用户数据报协议)之类的协议，这样便能极大提高流的体验。UDP与TCP的差别在于，UDP是快速简单的协议，不具有重传和数据速率管理能力，不能恢复丢失的数据，也不能应付可变数据速率通道。但是对于实时的音频视频数据而言，其特点在于可以容忍一些数据丢失，因此采用针对这样特点的UDP协议可以通过牺牲无关紧要的包来实现传输的连贯。(相反，TCP协议在数据重传和数据管理方面的能力就很强，这让我们想到了“塞翁失马”的故事。)
2、流媒体相关协议
同时，流媒体服务器采用了专门为流式传输所建立的RTP、RTCP、RTSP和RSVP协议，这些协议保证了传输的音频视频数据与传输控制信息分别遵守各自对应的协议，并做到了对带宽的匹配，同时为客户端提供了控制能力(快进、快倒、跳至某段、暂停)。下述协议的分层如图1所示。
图1：流媒体协议分层
1）实时传输协议(RTP)
RTP (Real-time Transport Protocol)是在Internet上针对多媒体数据流的一种传输协议，工作于一对一或一对多的传输情况，可提供时间信息和实现流同步。RTP与HTTP和FTP等一样都位于应用层。RTP与HTTP最大的不同在于RTP是基于UDP的应用层协议。RTP并不将整个媒体文件下载到客户端，而是在经过初始会话和数据缓存延迟之后，以事先协商好的速率播送数据流。一旦播放器播放完数据，数据就会被丢弃，这样本地硬盘中并没有文件保留，当用户需要再次收看时，只好再和服务器请求协商。RTP只保证数据传输，其他诸如拥塞控制、流量控制等传输保障一概不管，由此需要再引入RTCP来进行控制。这种设计与当前通信融合中的控制与承载相分离颇有几分相像。
2）实时传输控制协议(RTCP)
在RTP会话期间，流媒体服务器对基于UDP的RTP协议并不放心，万一丢包太多造成质量严重恶化就会无计可施。于是设置了RTCP协议来协助RTP以提供流量控制和拥塞控制服务。RTCP让网络上的所有参与者周期性地传送RTCP包，这些包中含有已发送数据包的数量、丢失数据包的数量等统计数据，流媒体服务器就可根据这些信息动态地改变传输速率和有效载荷类型。RTP与RTCP组合成搭档，一个负责执行，一个负责监控，干活的竭尽全力，监工的毫不懈怠，保证了传输流的源源不断。
3）实时流协议(RTSP)
尽管设计了近乎完美的RTP/RTCP，但仍旧存在一些缺憾。RTP/RTCP确实保证了播放的“源源不断”，但是流媒体内容存在明显的时间线（开始时间、结束时间、中间段时间），于是，用户就存在控制所收看的内容时序的愿望，他们想在收看开始时就知道故事的结局，还想快进或慢进来找到自己想要的内容。而这些都是RTP/RTCP满足不了的。于是Real Networks、Netscape又共同设计了RTSP (Real-time Streaming Protocol)。RTSP在体系结构上位于RTP/RTCP之上，它使用TCP完成数据传输。RTSP做到双向服务，在服务器与客户端播放器之间传递请求和响应。RTP/RTCP两个协议可以把流媒体的内容顺利播放，RTSP则作为更高层的管理，保证了播放内容的可控制性。
4）其他辅助协议：会话描述协议(SDP)和资源预留协议(RSVP)。
之所以称为辅助协议，实际上这两个协议对实现一个实时流媒体并不必要，但是针对特定的情景和问题这两个协议会协助流媒体方便传输。SDP (Session Description Protocol)规定了对描述会话的必要信息进行编码的方法。SDP协议实际上更多地服务于“邀请类”业务(这类业务有时会用到流媒体技术)。RSVP(Resource Reserve Protocol)是为了保障流媒体QoS而在互联网传输层规定的协议，其根本作用是通过在每个传输流媒体的节点上预留资源而保证客户侧的实时“流”感受。
三、流媒体编码格式
视频业务的技术实现形式是面向通道的，但是面向源的编码格式是流媒体通道技术可以在互联网及未来的
四、流媒体播放器
流媒体播放器就是针对流媒体的客户端。播放器的作用就是将压缩文件解码、呈现视频和音频(就是“播放”)，因此不同类型的播放器只能解适合自身类型格式的编码。
