文件传输协议范文第1篇

黄河、黄河，这是长江，请开炮收到，正在汇报，正在汇报，完毕。

当时觉得他们说话特别嗦，重复呼叫名号、自报家门、重复对方要求，重复自己的话，最后还加个完毕，看着都着急。

很不幸，在网络世界，电脑和电脑之间的通讯，比这个“嗦”有过之而无不及。

这个所谓的“嗦”，是因为战场通讯和网络通讯有很多相似的地方：环境恶劣、距离遥远、干扰众多而又要内容不失真，所以通讯双方，都要反复验证信息传送的正确性。这一套通话的模式，在网络世界里称为协议，而上面那种通话模式―互相喊话、确认身份、确认发送的信息、确认发送结束，可以比拟为网络中最常用的TCP协议（见图1）。

小提示：

TCP协议是TCP/IP协议的一部分，而TCP/IP协议是互联网的基础。通俗地理解，TCP是“说话”的方式、IP协议用来“呼叫”通话的电脑。

QQ传输文件比MSN快?原因一

QQ、MSN在传文件时，将文件的数据分成很多小数据包，每个包里面再添加上这些嗦的“话”，以保证能可靠地接收，毫无疑问“一分钟也传不了几句话”。

后来，QQ改革了，换了一种通话协议―UDP协议，这个协议如同发电报，将数据一股脑地发给对方，对方只简单地回复“收到”即可。至于全不全、对不对就不管了。这个协议效率很高，传送文件的速度当然就快了（见图2）。

小提示：

UDP协议虽然可靠性差、错误率高，但在网络视频应用中效果良好，视频聊天软件均采用此协议。另外，QQ也采取了一些措施来克服它的缺点，如让文件断点续传(MSN无断点续传功能)。

原因二，选择最近的路线

网络还有一个复杂的情况：两台互传文件的电脑可能远隔“千山万水”，要通过许多服务器、路由器、网关和电缆中转，才有可能达到目的地。UDP协议为了加快连接速度，会选择尽量短的路线（称为UDP直连模式）。而MSN使用的TCP协议，却先将数据包发送到MSN服务器，服务器再转送到目的地（称为TCP中转模式），数据正确性虽有保证，但绕了路，也会受到服务器拥堵的影响。

原因三，礼让与加塞

TCP协议是一个“和谐”的协议，当它发觉网络堵塞，会自动减慢数据包发送，让互联网保持通畅。而UDP协议是一个“霸道”的协议，它想尽一切办法将数据传送出去，而不管是否加重网络拥堵。

用什么传输比较稳定

通过上面的分析，稳定传输文件非MSN莫属么？其实MSN虽使用TCP协议，但中转太多，服务器又在国外，掉线率不比QQ少，因此从连接的稳定性而言，QQ和MSN差不多，但MSN传输的文件，错误率会小一些。

小提示：

文件传输完成后，赶快测试传输的文件是否有错误。另外，传输不畅，可以使用新浪UC、网易泡泡（见图3）、百度Hi等类似工具。

传大文件用什么

这次推荐QQ么？传大文件，QQ容易掉线、大小受限制（2GB）、数据错误率较高，这次推荐一款称为Lava-Lava的软件（/）。该软件文件传输性能和QQ差不多，但它提供的离线传输功能，速度很快，常可以达到你的网络的最大上传、下载速度，稳定性高，离线传输的文件大小不受限制（QQ限制1GB）。有人还通过注册2个Lava-Lava号来当网络硬盘使用呢。

小提示：

离线传输就是先将文件传送到服务器，然后接收方再从服务器下载。Lava-Lava的离线传输操作非常方便，在聊天窗口，选择“文件传输通过离线服务器转发文件”即可（见图4），或直接拖动文件到未上线好友的聊天窗口中。

文件传输协议范文第2篇

关键词:TCP协议;Winsock控件;网络编程;

文件传输

一、Winsock控件基础

Winsock即Windows Sockets规范的简称,是目前最流行的网络通信应用程序接口之一。所谓Socket,通常也称作“套接字”,用于描述IP地址和端口,是一个通信链的句柄。应用程序通常通过“套接字”向网络发出请求或者应答网络请求。Socket是网络上运行的两个程序间双向通讯的一端,它既可以接受请求,也可以发送请求,利用它可以较为方便的编写网络上数据的传递。Winsock控件可以与远程计算机建立连接,并通过用户数据报协议UDP或者传输控制协议TCP进行数据交换,这两种协议都可以用来创建客户与服务器应用程序。与Timer控件和CommandDialog控件类似,Winsock控件在运行时是不可见的。在使用Winsock控件时,首先需要考虑使用什么协议。可以使用的协议包括UDP和TCP。两种协议之间的重要区别在于它们的连接状态:TCP协议控件是基于连接的协议,可以将它同电话系统相比。在开始数据传输之前,用户必须先建立连接。UDP协议是一种无连接协议,两台计算机之间的传输类似于传递邮件:消息从一台计算机发送到另一台计算机,但是两者之间没有明确的连接。到底选择哪一种协议通常是由需要创建的应用程序决定的。本文以TCP为例介绍文件传输。

TCP协议的全名为“传输控制协议(transfer control protocol)”,这是一种在Internet上使用的 主要协议。因此,当您使用TCP协议连接两个网络上的设备时,将可以在它们之间交换希望交换的数据。

同时,如果您开发的应用程序属于主从式应用架构应用系统时,将必须要知道应用系统主机的ip地址(利用RemoteHost属于取得)以及连接端口号(利用remoteport属于取得)。在这些数据完全备齐之后,您才可以进行进一步的调用、连接。

因此,如果正在建立主机端应用程序时,必须指定本机,必须指定本机(执行应用程序所在的计算机)所用的连接端口号(localport属于),接着将Winsock控件设置为“监听(listen)”,即可等候远程客户端进行调用与连接。因此,当主机端接收到客户端调用并且要求连接的信息时,将会触发“要求连接()”的事件,接着进行标准“允许”或是“拒绝”的程序。

一旦主机端与客户端连接完成之后,您将可以开始使用“传送数据(senddata)”方法,将数据传送给对方,并且利用“传送完成(sendcomplete)”事件,来检测数据是否传送完毕。同时,在数据传达对方的计算机时,将会触发对方计算的“接收数据(dataarrival)”事件。此时,您可以使用“取得数据(getdata)”方法,来去出这些接收到的数据。

二、Winsock控件工作原理

Winsock控件是基于Socket规范创建的,所以其通信的实质是对Socket接口进行数据的读写操作。如果两个应用程序需要通信,它们可以通过使用Socket类来建立套接字连接,可以将这个过程想象为一次电话呼叫过程:呼叫者通过拨号与被呼叫者连接,当电话接通时,双方都可以自由通话了,只不过这里的呼叫者被称为“客户”,被呼叫者则称为“服务器”,而号码则为“IP地址+端口”,但在建立连接之前,必须由“客户”发出呼叫,且此时的“服务器”正在监听。因此,基于TCP/IP协议的通信,需要分别建立客户端应用程序和服务器端应用程序。

三、基本实现方法

客户端要与服务器端进行通信,首先,必须知道服务器端的域名或IP地址(RemoteHost属性),就像要和某人打电话前,必须知道对方的电话号码;其次,还必须和服务器端约定相同的端口(RemotePort属性),用于数据的输入和输出;最后,调用Connect方法与服务器端建立连接。

四、实例实现

(一)实现原理

本文将实现的文件传输只有一个发送方和一个接收方,这是最基本的文件传输方式,运用的原理也比较简单:发送方先获取待传输文件的基本信息,主要是文件名及文件长度;然后,将其发送给接收方;接着,建立和文件一样大小的数据缓冲区,并将文件读入;最后,将数据缓冲区中的数据发送给接收方。与此同时,当接收方接收到文件名和文件长度之后,就为其创建新的文件和数据缓冲区;然后,接收传输的文件数据,并将其放在数据缓冲区中;最后,依次将数据缓冲区的数据写入新创建的文件中。这样便完成了不同计算机之间的文件传输。

(二)服务器端主程序主要代码

'发送文件名和文件长度代码:

Winsock1.SendData filename

Winsock1.SendData filelength

'发送文件的内容

Open filepath For Binary As #1'设置数据缓冲区

ReDim data(filelength)

For j = 1 To filelength

Get #1, j, data(j)

Next

send = filelength

Winsock1.SendData data

Close #1

End Sub

"客户端请求连接"事件代码:

Private Sub Winsock1_ConnectionRequest(ByVal requestID As Long)

If Winsock1.State 0 Then

Winsock1.Close

End If

Winsock1.Accept requestID '接受客户请求

End Sub

(三)客户端主程序主要代码代码

"连接"按钮事件的代码:

Private Sub connect_Click()

Winsock1.Protocol = sckTCPProtocol'以TCP方式进行通信

'设置远程服务器IP地址,为方便调试笔者使用的是自身的IP地址

Winsock1.RemoteHost = hostText.Text

'设置远程服务器通信程序端口号,与服务器端相同

Winsock1.RemotePort = Val(portText.Text)

Winsock1.connect'与服务器端建立连接

End Sub

"数据到达"事件的代码:

Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)

'状态栏显示提示文字

StatusBar1.SimpleText = "正在接收服务器发送的数据..."

'先接收文件名和文件的长度

If flag = True Then

Winsock1.GetData filename, vbString, bytesTotal - 4

Winsock1.GetData filelength, vbLong

'建立文件

Open filename For Binary As #1

flag = False

Else

'设置缓冲区

ReDim data(bytesTotal)

'接收数据并写入文件

Winsock1.GetData data, vbArray + vbByte

For j = received + 1 To received + bytesTotal

Put #1, j, data(j - received - 1)

Next

'更新接收到的数据

received = received + bytesTotal

ProgressBar1.Value = Int((received / filelength) * 100)

If ProgressBar1.Value >= 100 Then Close #1

End If

End Sub

从以上的实例中,基本了解了有关Winsock控件的使用方法和文件传输的过程。然而,当需要传送的数据比较大时,就不能像以上介绍的那样,直接将整个文件放入数据缓冲区中了,我们的内存是无法忍受用一个几百MB甚至上GB的空间去存储那些临时数据的。显然,这种做法已远不能满足我们的需求,这时可以将文件按照一定的大小,分成若干个数据包。首先,设置数据包的大小,根据文件的基本信息,计算出总共需要的数据包数;然后,依次读取同数据包一样大小的数据到数据缓冲区中;接着,将数据缓冲区中的数据,发送到指定的计算机上;同时在另一端,建立一个数据缓冲区,缓冲区的大小要根据接收到的数据来确定,依次接收客户端传输过来的数据包,并将数据缓冲区的数据写入相应的文件中,这样就很容易实现大文件的传输了。

五、小结

本文通过在VB中使用Winsock控件,实现网络之间的文件传输,更进一步理解了其工作原理。虽然本文重点介绍的是TCP协议的文件传输,但是UDP协议的文件传输实现与TCP是相似的。本文介绍的Winsock工作原理、实现方法、实例的展现还是有普遍的适用性的,能在一定的程度上有助于解决普遍的问题。

参考文献:

[1]黄玲玲,杨剀,王颖.在VB中使用Winsock控件实现局域网通信[J].信息技术,2005,6

[2]王晓平,钟军.VisualBasie网络通信协议分析与应用实现.2003

文件传输协议范文第3篇

关键词：Gstreamer； 流媒体； RTSP； RTP/RTCP

中图分类号：TN919.8 文献标识码：A 文章编号：1006-3315（2013）03-149-002

1．前言

流媒体技术以流的方式在网络中传输媒体，具有良好的实时性和交互性。随着3G、4G等高速移动通信技术的发展成熟和多媒体智能移动设备的普及，流媒体技术获得了广泛应用和迅速发展。本文基于GStreamer架构，采用RTP/RTCP协议实现数据传输，设计了一种流媒体播放器，处理芯片采用OMAP3430，操作系统为嵌入式Linux系统，借助高速网络，可以实现高质量的流媒体播放。

2．相关技术介绍

2.1流媒体技术。流媒体是指以流的方式在网络中传输音频、视频和多媒体文件的形式。流媒体文件格式是支持采用流式传输及播放的媒体格式。流式传输方式是将视频和音频等多媒体文件经过特殊的压缩方式分成一个个压缩包，由服务器向用户计算机连续、实时传送。用户采用内容缓存的方式，只需要进行很短时间的缓冲，就可以一边播放一边下载，而不需要提前下载整个文件。

流媒体传输一般都是采用建立在udp协议上的rtp/rtsp实时传输协议。相对于注重传输质量的tcp协议来说，udp协议更加注重传输速度，这种协议对于实时性要求很高的流媒体文件来说，无疑是更加合适的。

2.2Gstreamer概述。GStreamer是一种流媒体应用框架，采用了基于插件（plugin）和管道（pipeline）的体系结构，框架中的所有的功能模块都被实现成可以插拔的组件（component），并且在需要的时候能够很方便地安装到任意一个管道上，由于所有插件都通过管道机制进行统一的数据交换，因此很容易利用已有的各种插件“组装”出一个功能完善的多媒体应用程序。其主要功能模块包括元件、衬垫、箱柜等。

元件(Elements)是Gstreamer框架中所有可用组件的基础，是组成管道的基本构件。元件可以分为数据源元件、过滤器元件、接收器元件等，实现数据的输入、处理和输出等功能。

衬垫（pad）是元件（element）与外界的连接通道，每个衬垫都带有特定的功能信息，通过将不同元件的衬垫依次连接起来构成一条媒体处理管道，使数据在流经管道的过程能够被各个元件正常处理，最终就可以实现特定的多媒体功能。

箱柜(Bins):箱柜是一个可以装载元件的容器，同时其自身也是一个GstElement对象，也能够被用来容纳其他的箱柜对象。

2.3实时传输协议（RTP/RTCP）。RTP/RTCP协议栈由两个相互紧凑的协议组成，其中RTP协议负责传送具有实时特征的多媒体数据，而RTCP协议负责反馈控制、监测QoS、监视和传递相关信息。由于流媒体数据传输对于传输实时性的要求远高于传输可靠性，RTP/RTCP数据通常采用UDP/IP封装，它们共同完成网络传输层的功能。

2.4实时流媒体协议（RTSP）。RTSP协议是一种对流媒体数据的传输进行控制的应用级协议。通过RTSP协议，可以实现音视频的控制、点播等功能。

3．流媒体播放器的实现

本文设计的流媒体播放器，可以分为以下几个模块：用户界面、RTSP控制模块、RTP/RTCP传输模块、数据转换模块、解码模块、视音频输出模块。如图1所示。用户通过用户界面与客户端交互，RTSP模块响应用户界面发送的命令，建立RTP数据传输会话，会话建立之后，由RTP/RTCP模块循环接收RTP数据包并进行排序，然后转换模块对RTP数据进行解包，转换成原始的音视频数据，然后送入解码模块进行解码，最后通过音视频输出模块将媒体展示给用户。

图1流媒体播放器架构

用户界面是客户端跟用户之间交互的界面，它包括两部分内容：一是媒体播放控制，比如暂停、快进等；二是媒体内容的展示，比如视频画面的显示等。在Linux系统下，本文利用GTK+库开发GUI框架。

RTSP模块用于会话的建立和控制，它提供响应界面操作的接口，直接响应界面发送的命令。RTSP也提供互联的双方或多方的一个传输方式和编码方式的协商操作，在网络允许的情况下，建立一条最佳的传输通道。当客户端用户选择服务器上某项流媒体内容的时候，播放器会通过RTSP协议，与服务器建立会话，通知服务器往本地RTP接收端口发送音视频数据。

RTP/RTCP模块为流媒体播放器的核心组成部分，当RTSP建立传输会话之后，RTP和RTCP会各使用一个端口，RTP端口会循环接收RTP数据包,同时RTCP端口会周期性的发送RTCP报，RTCP包中包含已发送的数据包的数量、丢失的数据包的数据等统计资料，因此，服务器可以利用这些信息动态的改变传输速率，甚至改变有效载荷类型。RTP包由RTP包头和RTP数据构成，RTP包头中包含了一些可以较好保证流数据连续性实时性的信息，如序列号、时间戳等。序列号可以保证到达客户端的RTP包的连续，而时间戳可以同步音视频包。根据包头中的时间戳接收的数据包进行重新排序，然后传送到转换模块进行处理。

4．小结

本文采用Gstreamer架构，对RTP/RTCP/RTSP协议进行了深入研究，设计了一种基于Linux系统的流媒体播放器，通过构建RTP/RTCP流媒体传输插件，实现了流媒体数据的实时传输和播放，在终端设备中可以取得良好的流媒体播放效果。

这种基于Gsreamer的媒体播放器具备良好的灵活性和可移植性，借助高速传播网络，特别适合在各种不同类型的智能终端实现流媒体的接收和播放等功能，在视频监控、远程会议、视频教学、多媒体娱乐等多种不同场合都可以获得广泛应用。

参考文献：

[1]孙弼阳，李虹，王颖．移动流媒体业务的技术与应用[J]现代电信科技，2008（06）：13-18

[2]陈丹，郭先会.RTP/RTCP协议在3GPP移动流媒体业务中的研究与应用[J]山西电子技术，2010(06):65-66

[3]陈洪敏．基于RTP/RTCP协议流媒体传输的研究[J]福建电脑.2010(02):93-94

[4]王蕊，刘卫东，王金童．基于GStreamer的媒体播放研究[J]电子设计工程.2012(03):34-36

文件传输协议范文第4篇

关键词：网络文件；传输机制；TCP；UDP

中图分类号：F49

文献标识码：A

文章编号：16723198（2013）01017001

0引言

网络信息技术的发展给我们的工作与生活带来了极大的便利，推动了信息在用户之间的快速流通。伴随着我们当前网络信息技术在日常生活中的普及，我们所需要的许多文件都是通过网络进行传输的。本文就对网络文件的传输机制问题进行了分析与讨论。

1TCP与UDP协议相关理论概述

1.1TCP相关理论概述

TCP是TCP/IP体系中面向连接的运输层协议，它提供全双工的和可靠交付的服务。所谓“面向连接”的含义就是在正式通信前必须要与对方建立起连接，否则通信就会无法进行。这种连接是实时的，只有双方都在时才能通信。

1.2UDP相关理论概述

UDP是面向非连接的用户数据包协议。“面向非连接”的含义是指在正式通信前不必与对方先建立连接，不管对方状态如何直接发送数据。UDP协议适用于可靠性要求不高的应用环境，或者根本不需要建立可开连接的情况。所以说，UDP协议能够快速的发送数据，降低系统连接时的消耗。

表面上看起来，UDP好像比TCP的速度更快，因为相比较UDP协议而言，TCP协议更加复杂一些，但是实际上并不完全是这样，特别是针对那些具有较强可靠性的应用，它们所需要的就是网络文件传输的稳定性与可靠性。在这种情况下，我们往往就会选择TCP协议。

2网络文件传输机制中的多线程技术应用

2.1多线程技术的定义

所谓多线程技术指的就是这样一种机制，它允许在程序中并发执行多个指令流，每个指令流都称为一个线程，各个线程之间彼此互相独立。它和进程一样拥有独立的执行控制，由操作系统负责调度，二者的区别在于线程没有独立的存储空间，而是和所属进程中的其它线程共享一个存储空间，这使得线程间的通信远较进程简单。

2.2文件传输中多线程技术的引入

为了能够让文件在网络传输过程中能够更快速，我们有必要应用多线程技术。使用多线程传输文件时，发送端和接收端在读写文件时必须把文件共享属性设置为Cfile：：shareDentNone。这是因为在发送端会有多个线程同时只读一个文件。

3影响网络文件传输速度的因素分析

要想实现网络文件传输的最优状态，就应当充分掌握影响网络文件传输速度的各项因素。笔者通过分析现有理论以及自身的亲身实践，认为能够给网络文件传输速度带来较大影响的因素主要有以下两个方面：

3.1单词读取文件的大小

网络发送端每一次所读取的文件所包含的字节数以及网络接收端每一次写入文件所包含的字节数都会对网络文件的传输速度产生极大的影响。基于硬盘的读写性质，我们在进行读盘以及写盘的时候最好读入或者写入N个字节的数据（N为扇区的大小）。通过这种操作方式，能够加速文件被读入缓冲区以及写入磁盘的速度。

3.2套接字的个数

网络文件在传输过程中，通常状况下都是一个线程单独获取一个套接字。在这种模式下，套接字的数量也就等于传输线程的数量。这样就会产生这样一个问题：套接字的个数越多是不是就意味着网络文件的传输速度就会随着而增长呢？实践证明，而这并不是成比例增长的。比如，当我们在开展“一个线程单独获取一个套接字”的编程过程中，当套接字的个数（同线程的个数相等）到达一定规模时，如果再使套接字的数量持续上升，那么所表现出来的对于传输速度的提升就会越来越弱。在套接字的数量达到临界值以后，甚至还会降低传输速度。

通过上述分析可以看到，通过综合分析系统性能以及传输性能，假如选择“一个线程单独获取一个套接字”的模式进行编程，那么套接字数量的选择应当同处理器的能力相适应，不能设置的太高。

4结束语

通过上述几个部分的分析与论述，我们可以看到，将TCP应用于网络文件的传输具有更强的稳定性以及可靠性。在应用TCP开展网络文件传输过程中，为了更高效的促进网络文件的传输，还需要将多线程技术引入进来。本文在分析过程中涉及到了网络文件传输过程中的一些影响因素，希望能够对我国当前网络文件传输机制的不断完善提供一点可借鉴之处。

参考文献

[1]王国忱，娄丽娜.TCP服务器端程序的一种实现[J].内蒙古民族大学学报（自然科学版），2009，（06）.

文件传输协议范文第5篇

    流式媒体服务具有广阔的应用领域，可以广泛应用于局域网、广域网、宽带综合接入网（利用光纤基带网、 ADSL 双绞线通信和改造后的双向有线电视网等）。它能在众多领域中使用：如电视台、广播电台节目查询、节目制作，出版社多媒体网上出版，音像公司产品制作，展览馆、博物馆的信息查询、信息，以及娱乐、交互式教学、网络会议和其他商业运作。

    较于传统的电视，网络媒体文件信息形式和来源丰富，有良好的互动性，具有索引结构的媒体文件能随意快进或快退到希望的位置。不受地域限制，没有节目时间限制，提供在线增加频道和更新播放列表等诸多优点。观众可以在电视和网络之间比较灵活地切换，例如可以在观看球赛的同时，从有关球队的万维网网址上阅览比赛和球员的背景资料，以及其它媒体相关信息。提供信息的同时，它能够对信息本身的安全性加以控制，对不同用户建立不同的安全级别和权限。

    目前，流式媒体点播较为常见，称为 VOD （ Video on Demand ）技术。节目点播系统 VOD （ Video on Demand ）是伴随着视频、音频处理及计算机网络技术的发展而迅速兴起的一门综合性技术。网络结构中的多媒体数据以实时数据流的形式传输，与传统的文件数据不同，多媒体数据流一旦开始传输，就必须以稳定的速率传送到桌面电脑上，以保证其平滑地回放，视频、音频数据流都不能有停滞和间断；网络拥堵、 CPU 争用或 I/O 瓶颈都可能导致传送的延迟，引起数据流传输阻塞。 VOD 服务是综合技术，它包括多媒体数据压缩技术、多媒体网络技术、多媒体数据库技术等专业技术。

    第一部分 基本概念

    整个系统所围绕的核心是如何安全快速高效地传输数据，并流畅的播放数据流。为此，提出了一种流式传送数据的方式。

第一节文件传递方式

    流式媒体能够通过“下载”和“流式播放”两种方式将数字媒体文件传递到客户端，供用户使用。这两种方式各有优缺点，但是这里推崇使用“流式播放”的方式对远程用户提供服务。下面对这两种方式作简单介绍。

    下载：为了通过使用下载方法将内容传递给用户，通常需要将内容保存到 Web 服务器并通过在网页上添加指向该内容的链接来向用户提供指向内容的链接。于是用户可单击链接，将文件下载到其本地硬盘上，然后使用播放机播放内容。

    但是下载需要用户首先将既耗费时间又耗费磁盘空间的整个文件复制到其计算机中，然后才能播放。另外，因为整个文件必须在下载之后才能播放，因此，下载不能用于实况流。下载不能高效地使用可用带宽。当客户端开始下载数字媒体文件时，所有可用网络带宽用于尽可能快地传输数据。因此，其他网络功能可能会减慢或被中断。

    流式播放：要通过使用流式播放方法将内容传递给用户，您可以将内容保存到 Windows Media 服务器，然后将该内容分配给点。然后，您可以通过创建公告文件或通过向用户提供点的 URL （ Uniform Resource Locator ） 来向用户提供对该内容的访问。您可以将公告文件或 URL 嵌入到网页中或将其以电子邮件形式发送。当用户单击链接或公告文件时，播放机就打开并连接到相应的流。

    因为流式播放只以客户端正确呈现它所必需的速度通过网络发送数据，实现边下载、边解码、边播放，所以它比下载更高效地使用带宽。这有助于防止网络变得过载并有助于维持系统的可靠性。因为播放机必须首先缓冲数据以防在流中存在延迟或间歇，所以在播放机接收流的时间和它开始播放流的时间之间通常有一个延迟。因为对数据进行流式播放和呈现是同时发生的，所以流式播放还允许您传递实况内容。

    可看出两种传输方式都有一定的缺点，但是就多媒体服务来说，它对数据的实时性要求较高，强调查询和浏览，不要求对数据存储，不要求数据传输中百分之百的完整性，所以使用流式播放能够在满足用户需求的基础上，更有效的减少带宽的占用，提高网络效率。

    另外，值得一提的是“快速流式播放”，“快速流式播放”结合了流式播放和下载的优点的功能。服务器可使用快速启动功能来确保客户端可以在传输开始之后尽可能快地开始播放内容。该功能允许播放机在开始播放内容之前，以网络所允许的最快速度从服务器下载和缓存一小部分内容。当在播放机上建立了缓冲区之后，服务器减慢流的传输，直到与播放机的呈现速度一致。

    当服务器使用快速缓存功能时，服务器以尽可能高的比特率将所有内容传输到播放机，以使网络阻塞或中断所带来的影响降到最小。与普通的流式播放一样，当缓存了所需数量的数据之后，播放机立即开始呈现内容。数据的其余部分存储在客户端上的临时缓冲区中。

第二节系统结构组成

    我们以基于 Windows Media 技术的流式播放媒体系统为例，详细介绍流式播放媒体系统组成结构。

    基于 Windows Media 技术的流式播放媒体系统通常由运行编码器（如 Microsoft Windows Media 编码器）的计算机、运行 Windows Media Services 的服务器和播放机组成。

    编码器允许您将实况内容和预先录制的音频、视频和计算机屏幕图像转换为 Windows Media 格式。运行 Windows Media Services 的服务器名为 Windows Media 服务器，它允许您通过网络分发内容。用户通过使用播放机（如 Windows Media Player ）接收您分发的内容。

    系统主干包括如下几个部分： Web 服务器、流媒体服务器、客户端。（如图一）

    用户首先从 Web 服务器那里获得流媒体文件的相关信息，从中搜索自己需要的链接；用户点击链接之后， Web 服务器响应消息，将请求定位到流媒体服务器（ Media Services ）；用户端播放器连接流媒体服务器，流媒体服务器提供相应服务，以流方式传送数据到用户计算机，用户计算机播放器流文件。以上是最简单的流媒体服务系统。

    除此之外，该系统中还可以加入视频采集系统、文件服务器和分发服务器，其中视频采集系统又包括摄像机和编码器。如图二：

    编码器是指一台计算机，它使用软件（例如 Windows Media 编码器）将压缩 / 解压缩 (codec) 算法和流格式应用到采用模拟或数字音频和视频格式的内容上，然后将内容重新生成为数字文件或流。该过程称为编码。对内容进行编码后，即可通过 Windows Media Services 进行分发。大多数情况下，用于内容编码的软件安装在不同于 Windows Media Services 的一台单独的计算机上，以 确保流式媒体系统稳定、冗余并且能够承受预期负载 。

第三节建立点

    当您已经获取了内容之后，下一步就是设置运行 Windows Media Services 的服务器以便分发该内容。设置 Windows Media 服务器的基本步骤包括：添加和配置点以标识打算传输的内容；通知用户该内容可用。

    媒体服务器上必须首先设置点，点是向用户分发内容的途径。内容可通过创建将客户端重定向到点的公告文件来，也可通过分发指向点的 URL 来。 Windows Media 服务器使用点将客户端对内容的请求转换为安置该内容的服务器的物理路径。

    简单形容，点就是在媒体服务器中预先存放的，一个填写了所要提供给客户的媒体文件的一个列表，列表的某一项指明了该媒体文件的具体位置，相关属性（如文件名、位置、文件大小、播放时间等）。

    点类型与内容

    点有不同的类型，一个服务器上可设置若干个点，服务器根据点的类型，向用户提供不同的服务。您可以向 Windows Media 服务器添加两种类型的点：点播点和广播点。

    点播是传递内容的一种方法，该方法只有在客户端向服务器发出请求时，才通过单播传输来播放相应内容。每个请求流的客户端通常都可完全控制流，可以快进、倒回、暂停和重新启动内容。这是因为点播点为请求内容的每个客户端提供了一个唯一的数据路径。

    广播是一种同时向大量观众传输数据的方法。在 Windows Media Services 中，广播是通过使用广播点来实现的。接收广播的客户端不能控制内容的开始和播放，也不能让流快进或倒回。该流由服务器控制。在客户端可从广播点接收内容之前，必须启动点。

    所以，如果要传输编码器的实况内容，则最好选择广播点。如果打算传输文件且希望允许用户控制内容的播放（例如，暂停、倒回或快进），则最好选择点播点。

    就点的内容来说，点可以用多种不同的内容来源，播放列表、文件和编码器都可以作为内容的来源。

    •  播放列表提供一种将不同片段的数字媒体内容组织成单个用户体验的方法

    •  可通过配置广播或点播点传输目录中的单个文件

    •  可通过配置广播或点播点传输目录中的文件

    •  当编码器为广播提供流时，它可以将流 “ 推送 ” 到服务器，而服务器也可以从编码器 “ 提拉 ” 所需的流

    •  可将另一台 Windows Media 服务器上的点用作点播点或广播点的源

    •  可将远程多播广播用作广播点的内容源，也可以创建存档文件以备以后点播或广播播放

    •  将加密目录作为来源

    •  使用动态源

    流传递方式

    在选择要使用的点类型时，您应当考虑如何传递内容；例如，是以单播流方式还是以多播流方式传递内容。利用单播流，客户端连接到 Windows Media 服务器以访问内容。利用多播流，服务器向网络上的单个多播 IP 地址传输内容，所有客户端都访问该 IP 地址（而不是连接到服务器）以接收流。因为单个流能够满足多个客户端请求，所以这将降低网络上所需的带宽量。

    以单播流方式传递内容时既可以采用点播点又可以采用广播点。以多播流方式传递内容时只能采用广播点。

    单播是一种通过网络传输数据包的方法，该方法要求在客户端和传输数据的服务间进行点对点通信。单播也称为定向通信，这是因为数据被定向到网络上的特定客户端。

    单播是向单个客户端传输单个数据流的一种方法。单播传递从服务器为每一个客户端提供单个流。通过单播传递接收内容的客户端可以使用任何可支持的连接协议连接到服务器。

    一旦客户端连接到服务器，内容便可以通过用户数据报协议 (UDP) 或传输控制协议 (TCP) 进行传递。这两个协议之间的区别在于客户端确认收到数据包的方式不同。

    多播是一种在网络上传输数据的方法，这种方法允许许多个客户端接收相同的数据流。该方法可将向一组网络客户端传输数据所需的带宽降至最低。多播传输要求网络上的路由器和交换机必须启用多播，这意味着它们必须能够传输 D 类 Internet 协议 (IP) 地址并可解释多播信息数据包。

    D 类 IP 地址第一个字节以“ lll0 ”开始，它是一个专门保留的地址。它并不指向特定的网络，目前这一类地址被用在多点广播（ Multicast ）中。多点广播地址用来一次寻址一组计算机，它标识共享同一协议的一组计算机。 D 类地址用于多点广播（ Multicast ）。

    多播 IP 地址是位于下列两个范围内的 D 类地址： 224.0.0.0 至 239.255.255.255 以及 FF00:0000:0000:0000:0000:0000:0000:0000 至 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF 。第一个范围中的地址是 Internet 协议版本 4 (IPv4) 地址，该版本是 Internet 协议的当前版本。第二个范围中的地址是 IPv6 地址，该版本是此协议的新版本。

    用在 Intranet 上时，建议您使用范围 239.*.*.* 中的 IPv4 地址。端口号可以介于 1 至 65535 之间。用来传输内容的网络上的路由器必须启用多播，也就是说路由器必须能够解释 D 类地址，否则将无法向客户端（如果一个程序 / 计算机连接到另一个程序 / 计算机，或者请求另一个程序 / 计算机的服务，那么发起连接或发出请求的程序 / 计算机就称为客户端。另外，客户端还可以指赋予该程序 / 计算机连接能力的软件。）转发多播信息。

    如图四，多播需要在网络中安装多播路由器，增加了系统成本，但可以有效减少服务器的负荷。

    多播是一种向多个客户端传输单个数据流的方法。多播是无连接的，客户端通过监视从服务器接收内容流的特定多播 IP 地址和端口来接收多播内容。

    要在服务器上成功地使用多播传递，您的网络必须使用多播路由器。多播路由器能够解释 D 类 IP 地址，并使用 Internet 组管理协议 (IGMP) 将客户端路由到多播 IP 地址。

    所有多播内容都必须具有指定的生存时间值，该值限制了多播内容在到期之前能够穿过的路由器数量。

    多播流通过网络上指定数量的路由器进行分发，该数量是由生存时间值 (TTL) 决定的。生存时间值在内容每次通过一个路由器时都减 1 。当该值为零时，多播流就不能继续前进。基于分发类型， WMS 多播数据写入器插件的预设生存时间值如下：

     1 ：本地网络

    32 ： Intranet

    64 ： Internet ，洲内

    128 ： Internet ，洲际

    255 ：允许的最大值

第四节向用户发送内容公告

    在已经添加了点和标识了要从中传输的内容之后，您需要通知用户该内容可用。可通过为该内容创建公告来方便地完成通知操作。

    在设置 Windows Media 服务器和要传输的内容之后，需要让用户知道该内容可用以及如何访问。用户可以通过在其播放机中键入指向内容的 URL 来访问该内容。但是，用户并不总是知道该 URL ，或者甚至不知道内容已存在。为了便于用户访问内容，您可以创建一个公告。公告是扩展名为 .asx 的 Windows Media 元文件，它向播放机提供连接到 Windows Media 服务器所需的信息。

第五节传输协议

    为实现流式播放， Windows Media Services 通过使用控制协议插件支持 Microsoft Media 服务器 (MMS) 协议、实时流式传输协议 (RTSP) ，以及超文本传输协议 (HTTP) 。

    数据传输协议是指在两台设备之间传输数据的标准化格式。协议类型可以确定诸如错误检查方法、数据压缩方法，以及文件结束确认之类的变量。如果所有的网络都是以同一方式构建的，并且所有网络软件和设备的行为都类似，那么只需要一种协议即可处理所有的数据传输需求。而在现实中， Internet 是由数百万运行各种软硬件组合的不同网络组成的。因此，为了以可靠方式向客户端传输数字媒体内容，需要有一组设计良好的协议。

    图五描述了 Windows Media Services 如何使用不同的协议在 Windows Media 服务器、编码器、内容源，以及 客户端 之间协商连接。

    MMS 协议

    Microsoft Media 服务器 (MMS) 协议是 Microsoft 为 Windows Media Services 的早期版本开发的专有流式媒体协议。在以单播流方式传递内容时，可以使用 MMS 协议。此协议支持快进、倒回、暂停、启动和停止索引数字媒体文件等播放机控制操作。如果要支持使用 Windows Media Player 早期版本的客户端，您需要使用 MMS 或 HTTP 协议满足其流请求。

    MMSU 和 MMST 是 MMS 协议的专门化版本。 MMSU 基于用户数据报协议 (UDP) ，是流式播放的首选协议。 MMST 基于传输控制协议 (TCP) ，用在不支持 UDP 的网络上。

    RTSP 协议

    可以使用实时流式传输协议 (RTSP) 以单播流方式传递内容。这是一个应用程序级别的协议，是为控制实时数据（如音频和视频内容）的传递而专门创建的。此协议是在面向纠错的传输协议基础上实现的，支持停止、暂停、倒回及快进索引 Windows Media 文件等播放机控制操作。可以使用 RTSP 将内容传输到运行 Real Player 系列 或 Windows Media Player 9 系列或 Windows Media Services 9 系列的计算机。 RTSP 是一个控制协议，该协议与数据传递实时协议 (RTP) 依次发挥作用，实现向客户端提供内容。

    RTSPU 基于用户数据报协议 (UDP) ，是流式播放的首选协议。 RTSP 基于传输控制协议 (TCP) ，用在不支持 UDP 的网络上。

    HTTP 协议

    通过使用超文本传输协议 (HTTP) ，您可以将内容从编码器传输到 Windows Media 服务器，在运行 Windows Media Services 的不同版本的计算机间或被防火墙隔开的计算机间分发流，以及从 Web 服务器上下载动态生成的播放列表。 HTTP 对于通过防火墙接收流式内容的客户端特别有用，因为 HTTP 通常设置为使用端口 80 ，而大多数防火墙不会阻断该端口。

    协议翻转

    Windows Media Services 依据客户端的具体环境为其选择适当协议的能力称为协议翻转。如果要支持多种客户端版本，支持通过防火墙连接的客户端或通过不同类型的网络连接的客户端，那么协议翻转将很有用。如果服务器上所有可用的服务器控制协议插件（包括 WMS HTTP 服务器控制插件）都已启用，那么协议翻转的效果会达到最佳。

    Windows Media 服务器使用协议翻转的目的是为了与客户端建立最佳的连接。客户端在尝试连接服务器时，会发送有关自身类型以及能支持哪些协议的信息。 Windows Media 服务器将该信息与已启用的协议进行比较，然后使用适用于当时情况的最佳协议。通常，服务器和客户端之间的第一次连接尝试是成功的，不需要采取进一步行动。如果该连接请求不成功，那么客户端将尝试使用其他可支持的协议连接到服务器。在每一次协议翻转尝试期间，客户端会经历一段非常短暂、通常不易察觉的延迟时间。

    建议您使用协议翻转，以确保客户端享受到最佳的流式播放体验。如果客户端使用带有 mms:// 前缀的 URL 连接到流，那么协议翻转将在必要时进行。请注意，用户可以在播放机的属性设置中禁用协议。如果播放机只支持一个协议，那么翻转就无法进行。协议翻转中使用的具体逻辑取决于连接服务器的客户端类型。

    如图九，在使用 RTSP 协议时，启用快速缓存时，系统首先使用基于传输控制协议的 RTSPT 协议，如果连接请求不成功，则使用基于用户数据报协议的 RTSPU 协议，当请求再次失败时，使用 HTTP 协议。

    禁用快速缓存的系统中，系统会首先使用 RTSPU 协议，失败时才会尝试使用 RTSPT 协议。

    对于 Windows Media Player 的早期版本，如 Windows XP 中的 Windows Media Player ，不支持 RTSP 协议。然而， MMS 协议为这些播放机提供了协议翻转支持。因此，当早期版本的播放机尝试使用带有 mms:// 前缀的 URL 连接到服务器时，服务器将自动为播放机协商最佳的协议。服务器将首先尝试使用 MMSU （即采用基于 UDP 的传输方式的 MMS ）连接到客户端。如果不支持该协议，那么服务器将尝试使用 MMST （即采用基于 TCP 的传输方式的 MMS ）进行连接。如果该连接也不成功，则在启用了 WMS HTTP 服务器控制协议插件的情况下，服务器将尝试使用 HTTP 协议进行连接。如图十：

第六章使用分发服务器

    分发服务器从另一个流式源（如另一个 Windows Media 服务器）接收到的内容。运行 Windows Media Services 的任何计算机都可以作为分发服务器运行。源服务器是分发服务器播放内容的来源。客户端可以像连接源服务器一样连接到分发服务器。分发服务器位于内容流中的源服务器和客户端之间，因此能够执行多种功能：

    负载平衡。 分发服务器是一种降低 Windows Media 服务器的客户端负载的简单方式，因为您可以将客户端的内容请求分布到网络上的多个服务器上。

     网络安全策略。 分发服务器可以放在网络防火墙内，将位于防火墙之外的源服务器作为来源，向防火墙内的客户端提供内容，因而无需打开额外的端口。或者，分发服务器可以放在网络防火墙之外，将防火墙内的源服务器作为来源，向防火墙外的客户端提供内容。

    服务器翻转。 在向位于多播网络上的客户端多播内容时可以使用分发服务器。不在多播网络上的客户端可以重定向到另一个分发服务器，以便进行标准的内容单播传递。

    第二部分 服务器管理

    使用 Windows Media Services ，可以将 Windows Media 服务器配置为通过 Intranet 或 Internet 传输内容。在开始传输内容之前，必须为运行 Windows Media Services 的服务器配置设置，添加并配置点，然后设置内容。

第一节服务器配置设置

    通过使用 Windows Media Services 管理单元或用于 Web 的 Windows Media Services 管理器，可以对 Windows Media 服务器进行管理。如果您使用的是 Windows Media Services 管理单元，那么可以将运行 Windows Media Services 的任何服务器添加到控制台，但前提是您具有该服务器的管理权限。即使从管理单元中删除了某个服务器，您仍可以通过用于 Web 的 Windows Media Services 管理器来管理该服务器。此外 , 使用通过 Windows Media Services 9 系列软件开发工具包 (SDK) 创建的命令行脚本和自定义程序也可以管理服务器。

    您可能还希望实施通过 Windows Media Services 使用的一些更高级的功能。例如，您可以修改设置以限制客户端连接数、设置安全措施以保护内容、记录有关客户端活动的数据以及设置分发服务器。

    服务器配置设置包括如下几项：

    1. 允许或拒绝单播客户端连接

    2. 设置服务器限制

    限制播放机连接数

    限制传出分发连接数

    限制播放机总带宽

    限制传出分发总带宽

    限制单一播放机单个流的带宽

    限制单个传出分发流的带宽

    限制每秒连接数

    限制播放机不活动超时时间

    限制连接确认时间

第二节点类型和公告形式的选择

    点是向用户分发内容的途径。内容可通过创建将客户端重定向到点的公告文件来，也可通过指向点的 URL 来。

    创建什么类型的点，要根据您的具体需求来选择。

    如果您希望用户能够控制正传输的内容的播放，则最适于从点播点传输内容。这种类型的点最常用于安置以文件、播放列表或目录为来源的内容。当客户端连接到该点时，将从头开始播放内容，最终用户可以使用播放机上的播放控件来暂停、快进、倒回、跳过播放列表中的项目或停止。

    如果您希望创造与观看电视节目类似的体验，则最适于从广播点传输内容 — 在源或服务器上控制和传输内容。这种类型的点最常用于从编码器、远程服务器或其他广播点传递实况流。当客户端连接到广播点时，客户端就加入了已在传递的广播中。例如，如果公司范围内的会议在上午 10:00 进行广播，在上午 10:18 连接的客户端将错过会议的前 18 分钟。客户端可以启动和停止流，但是不能暂停、快进、倒回或跳过。

    为了使用户知道哪些点可以使用，最简单的方式是通过指向点的 URL 来。那么究竟什么是 URL 呢？

    URL （ Uniform Resource Locator ：统一资源定位器）实际上是 Web 页的地址，它从左到右由下述部分组成：

    Internet 资源类型（ scheme ）：指出 Web 客户程序用来操作的工具。如“ http ： // ”表示 Web 服务器，“ ftp ： // ”表示 FTP 服务器，“ gopher ： // ”表示 Gopher 服务器，而“ new ：”表示 Newsgroup 新闻组。

    服务器地址（ host ）：指出 Web 页所在的服务器域名。

    端口（ port ）：有时（并非总是这样），对某些资源的访问来说，需给出相应的服务器提供端口号。

    路径（ path ）：指明服务器上某资源的位置（其格式与 DOS 系统中的格式一样，通常有目录 / 子目录 / 文件名这样结构组成）。与端口一样，路径并非总是需要的。

    URL 地址格式排列为： scheme ： //host ： port/path

    例如 http ： //51itworld.com/domain/HXWZ 就是一个典型的 URL 地址。

    另一种方法，也是使用最广的方法是通过公告文件点。

    公告是带有 .asx 扩展名的 Windows Media 元文件，该文件为播放机提供在连接到 Windows Media 服务器接收内容时需要的信息。您可以在网页上插入指向公告的链接，将公告放在共享文件中，或用电子邮件发送出去。用户可以通过单击网页上的公告链接或直接打开公告来访问您的内容。位于 Windows Media Services 管理单元“公告”选项卡上的公告向导可帮助您创建公告文件（ .asx 文件）和多播信息文件（ .nsc 文件），播放机可以使用这些文件连接到内容。向导还可以帮助您创建带有嵌入式 Windows Media Player 控件的网页，或者提供在个人的网页中嵌入播放机的语法。

    因为很多浏览器不能直接访问流式媒体内容，所以使用公告文件作为链接，使得大部分用户都可接收数据。

    举个例子，如果用户使用微软的 IE 浏览器访问点时，是使用“ URL ”还是“公告文件”效果是相同的，浏览器会自动启动 Windows Media Player 控件来播放点的内容。用户甚至可以选择是在 IE 浏览器内播放或是启动 Windows Media Player 来播放；然而对于其他浏览器的使用者，如果该浏览器不支持直接访问流式媒体内容，那么该用户就不能连接 URL 指定的点。只有当他点击公告文件时，用户的系统才能自动启动 Windows Media Player 。

    其实公告文件与 URL 的本质是一样的，都是对点位置的描述，是一个 Web 地址。比较一下二者的具体内容就会非常明显的看出其中的相同之处。

    公告文件示例

    <asx version = "3.0"> <entry> <ref href = "mms://servername/publishingpointname/filename.wmv"/>

    </entry>

    </asx>

    URL 示例

    mms://my_server/mypub_pt/my_file.wmv

第三节配置安全选项

    如果您希望对点内容的安全性作进一步设置， Windows Media Services 提供的安全选项完全可以满足您的要求。它包括如下几项：

    身份验证 是保证运行 Windows Media Services 的服务器的安全性的最基本方面。它将对试图访问 Windows Media 服务器资源的任何用户进行身份确认。

    身份验证是对尝试连接到服务器的客户端的凭据进行验证的过程。此过程包括从客户端向服务器发送凭据，以及使用身份验证方案识别用户。

    授权 是验证是否允许客户端连接到服务器的过程。授权在身份验证成功之后进行。在授权过程中，服务器对照为用户试图连接的资源设置的访问权限对用户进行检查。

    向用户授予权限的目的在于定义一个特定用户可以在系统上执行什么操作，以及向不同的用户授予不同的权限级别。可以为系统上的单个用户、计算机和服务器定义权限。

    配置防火墙。 如果您计划从网络上的 Windows Media 服务器向 Internet 上的播放机传输内容，那么可能需要在防火墙上打开更多端口以防止播放机在接收内容时遇到问题。

    可以为单播流配置防火墙、为多播流配置防火墙，允许防火墙之外的编码器进行访问。

    日志管理。 Windows Media 服务器包括内置的监视和日志记录功能，您可以利用它们收集有关流式媒体会话及其观众的有价值的信息。

    总结

    随着技术发展、新协议制定，其内核将被不断被重新设计，流式媒体服务系统日渐完善。智能流式播放逐渐发展成熟， Media 服务器与 Media Player 一起检测网络状况并自动调整流的属性以最大限度地改善播放质量的方法。通过智能流式播放，用户可以收到根据特定的连接速度定制的连续内容流。