UDP协议和RTP协议分析报告（关于VR设备）

UDP协议是User Datagram Protocol的简称，中文名是用户数据报协议，是一种无连接的传输层协议，提供简单不可靠的信息传送服务。在网络中它与TCP协议一样用于处理 UDP数据包。UDP不提供数据包分组、组装、不能对数据包进行排序，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。UDP用来支持那些需要在计算机之间传输数据的网络应用。包括网络视频会议系统在内的众多的客户/服务器模式的网络应用都需要使用UDP协议。
RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。
一. UDP协议
1.1 UDP协议报头
1.1.1面向报文的UDP
送方 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。
应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文。
接收方 UDP 对 IP 层交上来的 UDP 用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。应用程序必须选择合适大小的报文。
1.1.2 UDP协议报文的组成
UDP报头由4个域组成，其中每个域各占用2个字节，具体如下：UDP源端口号、目标端口号、数据报长度、校验值。

 源端口号：这是在源主机上运行进程所使用的端口，有16 位长，可以表示的端口号从0 到65535，当源主机是客户端时，此端口号为短暂端口号，为源主机上UDP软件随机生成。当源主机是服务端时，此端口号通常是熟知端口。
 目的端口号：这是在目的主机上运行的进程使用的端口号，长度是16 位，若目的主机是服务器端，那么此端口号通常是熟知端口，如果目的主机是客户端，那么此端口号通常是随机出来的短暂端口。服务器端发送报文的目的端口，通常是将客户端发送报文的源端口复制过来。
 总长度：长度为16位，它定义了用户数据报的总长度，首部加上数据，16 位可以定义的总长度是从0到65535字节，但是最小长度是8 字节,有首部没有数据。
 检验和：这个字段用来检验整个用户数据报（首部加上数据）出现的差错。UDP的校验和的计算和IP与ICMP校验和的计算不同，UDP 的校验和包括伪首部、UDP。
1.1.3 UDP协议的首部格式
用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段有8 个字节，由4个字段组成，每个字段都是两个字节。

 伪首部：在UDP伪首部中，包含32位源IP地址，32位目的IP地址，8位填充0，8位协议，16位UDP长度。通过伪首部的校验，UDP可以确定该数据报是不是发给本机的，通过首部协议字段，UDP可以确认有没有误传。伪首部并非UDP数据报中实际的有效成分。伪首部是一个虚拟的数据结构，其中的信息是从数据报所在IP分组头的分组头中提取的，既不向下传送也不向上递交，而仅仅是为计算校验和。
1.1.4 UDP的封装
在交给IP层之前，UDP给用户要发送的数据加上一个首部。IP层又给从UDP接收到的数据报加上一个首部。最后，网络接口层把数据报封装到一个帧里，再进行机器之间的传送。如图所示。帧的结构根据底层的网络技术来确定。通常网络帧结构包括一个附加的首部。

1.1.5 UDP校验和的计算（可忽略）
UDP检验和覆盖UDP首部和UDP数据。
UDP检验和的基本计算方法与IP首部检验和计算方法相类似（16b字的二进制反码和），但是它们之间存在不同的地方。
首先， UDP数据报的长度可以为奇数字节，但是检验和算法是把若干个16 bit字相加。解决方法是必要时在最后增加填充字节0，这只是为了检验和的计算（也就是说，可能增加的填充字节不被传送）。
其次， UDP数据报包含一个12字节长的伪首部，它是为了计算检验和而设置的。伪首部包含IP首部一些字段。其目的是让UDP两次检查数据是否已经正确到达目的地。
如果检验和的计算结果为0，则存入的值为全1，这在二进制反码计算中是等效的。如果传送的检验和为0，说明发送端没有计算检验和。
1.1.6 用于进程间通信的过程
（1） 接收数据主机A的应用程序要申请一个UDP端口，设为P。
（2）发送方的应用程序准备好数据后，将其交给UDP协议，由其发送给主机A的端口P。
（3） UDP协议将应用程序数据作为UDP数据包的数据部分封装在一个UDP数据包中，并将数据包的目标端口字段设置为P。
（4） UDP协议将UDP数据包交给IP协议处理，由其发送给主机A。
（5） IP协议将UDP数据作为IP数据包的数据部分封装在一个IP数据包中，并将数据包的目的地址字段设置为A，将协议字段设置为17。
（6） IP数据交给网络层发送出去，经多个网络设备（路由器），到达主机A的IP协议层。
1.2 UDP通信特点
UDP协议直接工作于IP协议的上层，和KP协议提供的服务相比具有以下特点：
 是一种报文投递方式，没有流的概念；
 不存在连接；
 不提供可靠通信保证；
 UDP头部包含很少的字节，比TCP!头部消耗少，
 传输效率高。
在具体实现上，UDP协议存在以下和TCP协议不同的地方：
①不进行数据分片，保持用户数据完整投递，用户可以直接将从UDP接收到的数据解释为应用程序认定的格式和意义；
②没有对UDP承载的整介用户数据的到达进行确认，这由用户来完成，相对于TCP协议这是一个缺点；
③没有连接的概念，不提供流量控制，也不存在对连接进行建立和维护；
④进行数据校验，和TCP一样将保持它首部和数据的检验和，这是一个端到端的检验和，当校验和出现差错的时候，抛弃数据，没有任何动作。
1.3 UDP协议和局域以太网结合的效率分析（和TCP比较）
UDP的特点决定了其不能提供和TCP类似的功能。但它存在其他优势：
①由于不存在数据分片和连接管理，系统开销比较小，通信带宽有效利用率要高于基于连接的通信方式；
②用户无需从其中接收的通信数据进行组装和判断，内部通信基于消息机制，每次收发的数据报文具有独立意义，采用UDP，相对TCP可以降低用户最终数据的解释将带来额外系统开销；
③在局域以太网上采用UDP，可以充分利用硬件上支持广播和组播的特点；
④适合于上层业务是基于消息机制的突发传输特点，更适合通信的时间间隔比较大，连续的多个消息一般不是发送给同一个对象的通信特点；
⑤方便用户针对整个用户数据进行确认的实现，使得确认方式更为有效。
综合来看，在局域以太网上采用UDP进行内部通信比较合适。一个良好设计的可靠UDP通信比TCP更能衔接上层基于消息的内部通信方式和底层的局域以太网。
二. RTP协议
RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。
2.1 RTP协议以及工作机制
2.1.1 RTP协议工作原理
RTP和RTCP在网络层次中的位置，如下图：

RTP协议原理比较简单，负责对流媒体数据进行封包并实现媒体流的实时传输，即它按照RPT数据包格式来封装流媒体数据，并利用与它绑定的协议进行数据包的传输；RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务.
2.1.2 RTP数据包格式
RTP报文头格式：

以上域具体意义如下：
版本(V):2比特 此域定义了RTP的版本.此协议定义的版本是2.(值1被RTP草案版本使用,值0用在最初”vat”语音工具使用的协议中.)
填料(P):1比特 若填料比特被设置,此包包含一到多个附加在末端的填充比特,不是负载的一部分.填料的最后一个字节包含可以忽略多少个填充比特.填料可能用于某些具有固定长度的加密算法,或者在底层数据单元中传输多个RTP包.
扩展(X):1比特 若设置扩展比特,固定头(仅)后面跟随一个头扩展.
CSRC计数(CC):4比特CSRC计数包含了跟在固定头后面CSRC识别符的数目.
标志(M):1比特 标志的解释由具体协议规定.它用来允许在比特流中标记重要的事件,如帧范围.规定该标志在静音后的第一个语音包时置位.
负载类型(PT):7比特 此域定义了负载的格式,由具体应用决定其解释.协议可以规定负载类型码和负载格式之间一个默认的匹配.其他的负载类型码可以通过非RTP方法动态定义.RTP发射机在任意给定时间发出一个单独的RTP负载类型;此域不用来复用不同的媒体流.
序列号（sequence number）:16比特 每发送一个RTP数据包,序列号加一,接收机可以据此检测包损和重建包序列.序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难.
时间标志（timestamp）:32比特 时间标志反映了RTP数据包中第一个比特的抽样瞬间.抽样瞬间必须由随时间单调和线形增长的时钟得到,以进行同步和抖动计算.时钟的分辨率必须满足要求的同步准确度,足以进行包到达抖动测量.时钟频率与作为负载传输的数据格式独立,在协议中或定义此格式的负载类型说明中静态定义,也可以在通过非RTP方法定义的负载格式中动态说明.若RTP包周期性生成,可以使用由抽样时钟确定的额定抽样瞬间,而不是读系统时钟.例如,对于固定速率语音,时间标志钟可以每个抽样周期加1.若语音设备从输入设备读取覆盖160个抽样周期的数据块,对于每个这样的数据块,时间标志增加160,无论此块被发送还是被静音压缩.
时间标志的起始值是随机的,如同序列号.多个连续的RTP包可能由同样的时间标志,若他们在逻辑上同时产生.如属于同一个图象帧.若数据没有按照抽样的顺序发送,连续的RTP包可以包含不单调的时间标志,如MPEG交织图象帧.
同步源（SSRC）:32比特 SSRC域用以识别同步源.标识符被随机生成,以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符.尽管多个源选择同一个SSRC识别符的概率很低,所有RTP实现工具都必须准备检测和解决冲突.若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源.
有贡献源（CSRC）列表:0到15项,每项32比特 CSRC列表识别在此包中负载的有贡献源.识别符的数目在CC域中给定.若有贡献源多于15个,仅识别15个.CSRC识别符由混合器插入,用有贡献源的SSRC识别符.例如语音包,混合产生新包的所有源的SSRC标识符都被陈列,以期在接收机处正确指示交谈者.
注意：前12个字节出现在每个RTP包中,仅仅在被混合器插入时,才出现CSRC识别符列表.
2.1.3 RTP工作机制
RTP根据应用程序的要求将流媒体数据包封装成RTP数据包并进行发送；它靠上层的调用以及依赖网络层发送来实现；
工作时，RTP协议从上层接收流媒体信息码流（如H.263），装配成RTP数据包发送给下层，下层协议提供RTP和RTCP的分流。如在UDP中，RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度限制，它的最大包长只受下层协议的限制。
2.2 关键技术指标
2.2.1 时间戳
时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间(Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，就可以确定输出的时间间隔。
RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。
在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值，如多个分组属于同一画像。
2.2.2 时延
影响时延的因素有多个方面：编解码、网络、防抖动缓冲、报文队列等都影响时延，其中有些是固定时延，如编解码网络速率等；有些是变化的，如防抖动缓冲和队列调度等，固定的时延可以通过改变编解码方式和提高网络速率来改变，而变化的时延通常采用提高转发效率来提高；
2.2.3 抖动
在视频电话中，语音、视频数据都是使用UDP协议传送的，但这种协议传输的数据包在网络层不能保证其发送顺序，需要应用层进行排序。在网络的传输中都会有延时，且随着网络负载的变化，延时的长短也不相同，对于语音数据，如果接收方收到后立即播放，很容易造成语音的抖动。
为了更好的解决抖动的问题，最好能实现抖动缓存，一是保证语通道读取数据包的顺序正确，二是控制接收方按照采集的时间顺序播放语音，减少语音的抖动；另外提供QoS和资源预留使语音数据获得优先发送和获得固定的带宽也是解决抖动问题的主要手段。
2.2.4 丢包率
丢包率是通过计算接收包数量和发送包数量的比率得到的，丢包率获得的整个流程是：发送方每间隔一定时间读取每个发送通道的发包数量和数据长度，组成一个此通道的RTCP报文发送给接收方，同时将发送数据包计数清零；接收方收到RTCP包后，读取接收通道接收到的包数量，并计算出丢包率，通过一个RTCP接收汇报包发送给发送方，同时对接收数据包计数清零。
2.2.5 会话和流两级分用
一个RTP会话(Session)包括传给某个指定目的地对(Destination Pair)的所有通信量，发送方可能包括多个。而从同一个同步源发出的RTP分组序列称为流(Stream),一个RTP会话可能包含多个RTP流。一个RTP分组在服务器端发送出去的时候总是要指定属于哪个会话和流，在接收时也需要进行两级分用，即会话分用和流分用。只有当RTP使用同步源标识(SSRC)和分组类型(PTYPE)把同一个流中的分组组合起来，才能够使用序列号(Sequence Number)和时间戳(Timestamp)对分组进行排序和正确回放。
2.2.6 多种流同步控制
RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical Name），尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。
2.3 特点以及应用
2.3.1 特点
RTP的设计有以下特点：
（1）轻型的传输协议。RTP提供端对端的实时媒体传输功能。但并不提供确保实时传输和服务质量的保证机制，没有如TCP／IP那样完整的体系框架，主要与具体应用结合一起来实现。
（2）灵活性。体现在把协议机制与控制策略的具体算法分开。协议本身只提供完成实时传输的机制．对控制算法的策略不作具体规定，开发者自己根据应用的实际情况，设计合适的算法和控制策略来保证传输的实时性。
2.3.2 应用
（1）RTP协议应用方案之单播
在客户端与媒体服务器之间建立一个单独的数据通道，从一台服务器送出的每个数据包只能传送给一个客户端，这种传送方式称为单播。
优点：便于控制和管理；
缺点：每个用户必须分别对媒体服务器发送单独的查询，而媒体服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余造成服务器负担沉重，响应需要很长时间.
（2） RTP协议应用方案之广播
广播指的是用户被动地接收流。在广播过程中，数据包的单独一个拷贝将发送给网络上的所有用户，客户端接收流，但不能控制流; 广播方式中资料包的单独一个拷贝将发送给网络上的所有用户, 而不管用户是否需要，会非常浪费网络带宽。
优点：简单
缺点：浪费网络带宽
（3） RTP协议应用方案之组播
组播技术构建的网络，允许路由器一次将数据包复制到多个通道上。采用组播方式，媒体服务器只需要发送一个信息包，所有发出请求的客户端即可同时收到连续数据流而无延时。这就大大减少了网络上传输的信息包的总量, 组播吸收了单播和广播两种发送方式的长处，克服了上述两种发送方式的弱点，将资料包的单独一个拷贝发送给需要的那些客户。组播不会复制资料包的多个拷贝传输到网络上，也不会将资料包发送给不需要它的那些客户，保证了网络上多媒体应用占用网络的最小带宽。

优点：减少网络上传输的信息包的总量。网络利用效率大大提高，成本大为下降；
缺点：当不同的用户同时点播同一个节目时，由于点播总有先后顺序，后点播的用户并不是从开始播放，而是依照网络中同时点播此节目的其它用户的播放进度，这就造成当前用户极有可能从节目的中间开始看起,很难做到个性化。
2.4 RTP协议移植计划
代码Jrtplib-3.3.0基本上实现了RTP协议的一个封装，我们后续要做的是第一对该代码进行一次全面的验证，以确保该代码的质量；第二通过做测试实验来得到一个稳定可用的视频帧率和质量调整算法以满足网络实时传输的要求；计划是先在PC上完成代码和算法的验证，然后再移植到DVR上；
2.5 RTP协议安全方面考虑
RTP安全方面的考虑: 攻击者可能通过伪造源地址,目的地址,修改报头等方式来攻击RTP,如果RTP是通过组播方式发送,那么发送者无法控制接收者的行为,即无法对接收者进行管理以达到安全上的要求,目前也有一些策略如加密方法来解决安全方面的问题,但还没有完全解决该问题,这里不再详细描述;
三. SPICE协议(补充)
SPICE (简单协议独立计算环境，Simple Protocol for Independent Computing Environment)是具有自适应能力的远程提交协议，能够提供与物理桌面完全相同的最终用户体验。传统的远程桌面传输协议工作在虚拟机Guest OS中,而SPICE 协议本身运行在虚拟机服务器中,可以直接使用服务器的硬件资源。SPICE 协议能够自动判断和调整图像处理的位置,如果用户终端能够处理复杂的图像操作,就尽可能地传输图像处理命令而不是渲染后的图像内容,这样可以减少网络上传输的数据量。
3.1 桌面传输协议分析
3.1.1原理
桌面传输协议是一组用来在桌面服务器和用户终端之间进行通信的协议。主要完成服务器到用户终端的图形、图像、音频的传输以及用户终端到服务器输入信息的传输，包括鼠标、键盘、外设等输入信息，如下图所示。

桌面传输协议负责把虚拟桌面显示的内容从服务端通过网络传递到远程用户终端。数据的传输过程需要用到TCP／IP网络中的传输层协议，可
以使用TCP协议或UDP协议进行传输。
目前的桌面传输协议大多使用TCP协议，也有协议使用UDP协议来传输视频流数据，如PCoIP协议。使用TCP协议可以保证数据的完整性，不会有数据丢失，但是TCP协议会产生大量的ACK确认报文，而且如果每一个用户事件都封装在一个TCP／IP报文中，会导致大量的分组开销。例如一个键
盘事件只需要8 bytes即可．TCP头部需要32 bytes，IP头部需要20 bytes，分组开销高达87％。UDP协议适合用来传输对丢失不敏感的数据。因此，适当地结合TCP和UDP协议能够提高虚拟桌面的性能。
目前的桌面传输协议一般都会采用多种压缩算法，针对不同的数据类型采用不同的压缩算法，在降低数据传输量的同时最大限度地保证数据完整性。
各传输协议都提供了对虚拟多通道技术的支持，通过在一个物理链路上虚拟出多条逻辑通路，从而提供对不同设备的支持。虚拟通道技术具有良好的扩展性．如果添加新的外围设备，只需要添加一条新的虚拟通道就可以完成对新设备的支持。每一条虚拟通道可以定义不同的优先级，根据不同的优先级来保证QoE。
3.1.2 影响因素
（1）图像数据处理方式
（2）传输层协议
（3）压缩和缓存技术
3.1.3 桌面传输协议比较

传输带宽要求的高低直接影响了虚拟桌面访问的流畅性。PColP协议采用分层渐进的方式在用户端显示桌面内容，首先传输一个完整但模糊的图像，然后在此基础上逐步精化，最终显示清晰的桌面。ICA协议采用处理性能和压缩比都很高的压缩算法，降低了对网络带宽的需求。针对视频播
放，ICA通过压缩协议缩减数据规模，但是这样会造成画面质量的降低．而SPICE则能够自适应地感知用户端设备的处理能力，进而将图像渲染操作
放在用户端进行。
3.2 SPICE协议分析
3.2.1 介绍
采用独特的三层架构设计：

(1)QXL。
驱动：部署在服务器侧、提供虚拟桌面服务的虚拟机中，用于接收操作系统和应用程序的图形命令，并将其转换为KVM的QXI。图形设备命令。SPICE服务器支持QXL VDI接口。
(2)SPICE客户端：
部署在用户终端上的软件，负责显示虚拟桌面．同时接收终端外设的输入。
(3)QXL设备：
部署在KVM服务器虚拟化的Hypervisor中，用于处理各虚拟机发来的图形图像操作。QXL设备需要 guest QXL驱动为所有功能。但是，当没有驱动时支持VGA标准。VDI端口是一个QEMU PCI设备，用于和代理之间通信。
SPICE协议最大的特点是其架构中增加的位于Hypervisor中的QxI。设备，本质上是KVM虚拟化平台中通过软件实现的PCI显示设备，利用循环队列等数据结构供虚拟化平台上的多个虚拟机共享实现了设备的虚拟化。但是，这种架构使得SPICE协议紧密地依赖于服务器虚拟化软／硬件基础设施，SPICE必须与KVM虚拟化环境绑定。传统的远程桌面传输协议工作在虚拟机Guest OS中，而SPICE协议本身运行在虚拟机服务器中，可以直接使用服务器的硬件资源。
SPICE协议定义了一组协议消息，用于同用户终端进行通信，这些消息不依赖于任何专用的传输层协议，能够灵活选择加密算法。SPICE连接
会话包括多个虚拟通道，可以在运行时动态添加和删除通道。每个通道对应一个远程设备。
SPICE协议能够自动判断和调整图像处理的位置，如果用户终端能够处理复杂的图像操作，就尽可能地传输图像处理命令而不是渲染后的图像内容，这样可以减少网络上传输的数据量。
应用SPICE协议时，需要在KVM虚拟化环境的QEMU中安装libspice库，这样KVM才能成为虚拟桌面服务器。提供虚拟桌面服务的虚拟机(即图中的Quest OS)上的应用程序向操作系统的图形引擎(GDI／X Engine)发出图形处理操作，图形引擎把绘图命令发送给QXL驱动，QXL驱动将操作系统的绘图命令转换为QXI。命令后推送到QXL设备的图形命令循环队列中，libspice库从中获取绘图命令，添加到图形命令树上。图形命令树主要负责对QXL命令进行组织和优化，同时负责对视频流进行侦测。经过图形命令树优化的QXL命令推送到发送队列中，由libspice库维护，并发送到SPICE客户端更新显示内容。

3.2.2 SPICE协议特性
（1）多通道
SPICE协议支持多通道设置，利用不同的通道传输不同的内容。每个通道中的内容都可以通过相应的图形命令数据流或代理命令数据流进行传输。同时能够独立进行加密，支持不同级别的QoE。
（2）硬件加速
高性能渲染- 使用OpenGL，Spice client 能够渲染的更快。使用硬件进行拉伸要比耗费大量软件操作的拉伸高效的多。因此，Spice 能够达到更好的用户体验。
• 减少客户端CPU 使用率- 客户端可以用节约下来的CPU 时间，用来执行其他的工作，比如audio。
（3）图像压缩
在虚拟桌面解决方案中，图形的渲染和处理都将消耗大量的计算资源，因此图形处理是虚拟桌面解决方案实现的关键部分。SPICE架构同时提供
了软件处理方法和硬件处理方法。SPICE客户端采用基于Cairo图形库的软件处理方式，使用CPU计算资源，提供2D图形数据的渲染处理能力。同
时也提供了基于GPU的硬件处理方法，在Linux平台使用OpenGI。库，在Windows平台使用GDI接口。采用基于GPU的处理方式可以提供高性能的图形渲染处理，尤其是在很消耗资源的多媒体应用中；同时也可以降低用户终端的CPU利用率，使得用户终端有能力来处理更多的应用。
为了提供对低性能终端设备的支持，SPICE框架实现了自适应的图形处理模块。如果用户终端处理能力比较差，图形处理操作则尽可能转移到服务端执行；如果用户终端有足够的处理能力，图形命令直接发送到客户端，由客户端进行处理，降低服务器的负载。同时也降低带宽需求。
（4）视频压缩
Spice 对这些视频流采用有损压缩，SPICE服务器启发式的识别视频区域，并发送他们作为视频流编码采用M-JPEG。这样节省流量，改善其性能，特别是在WAN环境下。但是，在某些情况下，启发式识别可能引发低质量图像。视频流能够被选择在服务器初始化时，并动态的实时运行。
（5）鼠标模式
Spice支持两种鼠标模式：服务器和客户端。
服务器鼠标：当用户点击Spice客户端窗口内，客户端鼠标被获取并设置无形。在这个模式下，服务器控制在显示器上鼠标位置。但是，它可能在广域网上负载的服务器是有问题的，在这里鼠标可能具有某些潜在的或没有反映。
客户端鼠标：没有获取，并用来有效地指针设备。对于启用客户端鼠标，VDI主机应用必须记录一个绝对的指针设备（例如USB tablet in QEMU）这个模式适合于WAN或负载服务器，因为光标平滑移动和反应。但是光标可能有暂时是不同步的（位置和形状）。
（6）其他特性
多监视器：支持任意数量的监视器
双向音频：支持音频重放和录音。重放是使用CELT算法压缩的；
口型同步：在视频和语音之间。只可用于视频流启用时；
迁移：开关通道连通性，支持服务器迁移
像素影射