rtp是什么意思?

RTP的含义：实时传输协议（Real-time Transport Protocol或简写RTP）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。

RTP，即快速热处理，是一种升温速度非常快保温时间很短的热处理方式。

简介

RTP快速热处理（rapid thermal processing)，是一种升温速度非常快的，保温时间很短的热处理方式。升温速率能达到10~100摄氏度每秒。一般采用红外卤素灯或者电阻棒加热，加热时电流很大，功率很大。

实验室一般采用专门的RTP炉进行实验。是半导体制造中的一道工艺，可以用于离子注入后的杂质快速激活、快速热氧化等。此方法能大量节省热处理时间和降低生产成本，是热处理上的一次革新。

快速热处理（Rapid thermal processing, RTP）是将晶片快速加热到设定温度,进行短时间快速热处理的方法,热处理时间通常小于1~2分钟。过去几年间,RTP已逐渐成为先进半导体制造必不可少的一项工艺,用于氧化、退火、金属硅化物的形成和快速热化学沉积。

RTP系统采用辐射热源对晶片进行一片一片的加热,温度测量和控制通过高温计完成。而之前传统热处理工艺采用的是批处理式高温炉,一大批晶片在同一炉管中同时受热。批处理高温炉的使用仍然很广泛,它更加适合于处理时间相对较长（超过10分钟）的热处理过程。

RTP技术的使用范围很广。它可以快速升至工艺要求的温度（200~1300℃）,并快速冷却,通常升（降）温速度为20~250℃/秒此外,RTP还可以出色地控制工艺气体。因此,RTP可以在一个程式（recipe）中完成复杂的多阶段热处理工艺。RTP快速升温、短时间快速处理的能力很重要,因为先进半导体制造要求尽可能缩短热处理时间、限制杂质扩散程度。用RTP取代慢速热处理工艺还可以大大缩短生长周期,因此对于良率提升阶段来说RTP技术特别有价值。

RTP系统有多种加热结构、热源和温度控制方法。其中,利用多排卤化钨灯对晶片进行加热是最常用的方法,因为它提供的热源易控制、方便、有效、加热速度快。RTP系统中,热源直接面对晶片表面,而不是象批处理高温炉一样对晶片边缘进行加热。因此,RTP系统处理大直径晶片时不会影响工艺处理的均匀性和升（降）温速度。通常,RTP系统还有晶片旋转功能,使热处理均匀性更佳。

目前最先进的RTP系统可以将晶片表面的温度分布精确控制在3s<2℃的范围内。然而,晶片表面的器件分布图形（pattern）会给温度带来一些影响和限制。因为RTP系统加热晶片时采用的是辐射性热源,温度会受到光学性质的影响。随着器件尺寸的不断微缩和对工艺处理均匀性的要求变得更加苛刻,如何优化加热结构、减小“图形效应”已成为一个重要的研究领域。解决“图形效应”的办法有很多,包括减少晶片表面入射能量的双面加热方法,以及采用与晶片温度接近的热源对有图形的一面进行照射的方法。

RTP的另一关键因素是温度的测量和控制。图1为采用高温计控制的RTP系统示意图,高温计测量的是晶片背面温度。早期的RTP系统有重复性差的问题,因为晶片背面涂层不同时,光谱发射率会有所变化,从而导致温度读数错误。现在的RTP系统含有复杂的发射率校正系统,热处理重复性很好。

RTP的一个重要应用是活化离子注入杂质,形成超薄结合。这一工艺要求热处理系统具有快速升温和冷却功能,因为离子注入后,必须将晶片加热到约1050°C进行高温退火,除去离子注入引起的损伤,并活化注入的杂质,同时必须缩短高温处理时间,尽可能减少杂质离子的扩散。为此,人们又开发了尖峰退火（spike-anneal）方法,使晶片可以快速升温然后立即冷却。

RTP的另一重要应用是形成金属硅化物。在这项工艺中,金属薄膜通过与源极、漏极和栅极区域的硅反应,形成金属硅化物。在先进的逻辑工艺中,常用金属为Co,目前正在为65nm工艺开发Ni。金属硅化物生成工艺通常在500℃以下进行,晶片必须放置在有高纯度气体保护的环境中加热,因为金属薄膜对氧化反应很敏感。对于该工艺来说,RTP系统是非常理想的。因为RTP的反应器体积较小,很容易通入高纯度气体进行净化,形成非常洁净的反应环境。

RTP在氧化反应中的作用也逐渐变得重要起来。由于RTP可以使用多种气体在高温下进行快速热处理,因此可以精确控制工艺条件,生成性能优异的氧化膜。RTP生成的氧化膜通常用于栅极介电材料、氧化膜和浅沟道隔离（STI）垫层。在气体中通蒸汽为RTP开创了新的应用领域。例如,使用富含H2的蒸汽对含W的栅极叠层结构进行选择性的氧化,这一应用已引起先进DRAM技术的特别关注。

实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该

协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP

和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的

是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可

以发出请求，即RTSP可以是双向的。

6.3 RTSP协议

实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使

实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据

。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径

，并为选择基于RTP上发送机制提供方法。

6.3.1 简介

6.3.1.1 目的

实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制

流交*是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控

制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对

服务器的可*传输连接以发出RTSP 请求。此外，可使用无连接传输协议，如UDP。RTSP流控制

的流可能用到RTP，但RTSP *** 作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和 ***

作上与HTTP/1.1类似，因此HTTP的扩展机制大都可加入RTSP。协议支持的 *** 作如下：

从媒体服务器上检索媒体：

用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体

的的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。

媒体服务器邀请进入会议：

媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模

式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。

将媒体加到现成讲座中：

如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP

请求可由代理、通道与缓存处理。

6.3.1.2 协议特点

RTSP 特性如下：

可扩展性：

新方法和参数很容易加入RTSP。

易解析：

RTSP可由标准 HTTP或MIME解吸器解析。

安全：

RTSP使用网页安全机制。

独立于传输：

RTSP可使用不可*数据报协议（UDP）、可*数据报协议（RDP），如要实现应用级可*，可

使用可*流协议。

多服务器支持：

每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在

传输层执行。

记录设备控制：

协议可控制记录和回放设备。

流控与会议开始分离：

仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下， SIP或H.323

可用来邀请服务器入会。

适合专业应用：

通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑

演示描述中立：

协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包含一个RTSP

URI。

代理与防火墙友好：

协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个"缺

口"。

HTTP友好：

此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet 内容选择平台

（PICS）。由于在大多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP 添加方法

。 适当的服务器控制：

如用户启动一个流，他必须也可以停止一个流。

传输协调；

实际处理连续媒体流前，用户 可协调传输方法。

性能协调：

如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的

用户界面。

6.3.1.3扩展RTSP

由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。RTSP 可以

如下三种方式扩展，这里以改变大小排序：

以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。

加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次

尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支

持的方法。

定义新版本协议，允许改变所有部分。（除了协议版本号位置）

6.3.1.4 *** 作模式

每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义

。使用HTTP或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。

为了说明，假设演示描述描述了多个演示，其中每个演示维持了一个公共时间轴。为简化说

明，且不失一般性，假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参

数外，网络目标地址和端口也需要决定。下面区分几种 *** 作模式：

单播：

以用户选择的端口号将媒体发送到RTSP请求源。

组播，服务器选择地址：

媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。

组播，用户选择地址：

如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。

6.3.1.5 RTSP状态

RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数

据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个

媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的

连接状态。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着

重要的作用：

SETUP：

让服务器给流分配资源，启动RTSP连接。

PLAY与RECORD：

启动SETUP 分配流的数据传输。

PAUSE：

临时停止流，而不释放服务器资源。

TEARDOWN：

释放流的资源，RTSP连接停止。

标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连

接产生连接标识。

6.3.1.6 与其他协议关系

RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目

前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，

演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP 服务器与用户

不全依*HTTP。

但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发

出请求，服务器作出响应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的

；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用HTTP功能至少在两个方面有好

处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。

当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。RTSP假设存在演示描述格

式可表示包含几个媒体流的演示的静态与临时属性。

6.3.2 协议参数

6.3.3 RTSP 信息

RTSP是基于文本的协议，采用ISO 10646 字符集，使用UTF-8编码方案。行以CRLF中断，但

接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易

。由于参数的数量和命令的频率出现较低，处理效率没引起注意。如仔细研究，文本协议很容

易以脚本语言（如：Tcl、Visual Basic与Perl）实现研究原型。

10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有

重要意义位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通过任何低层传输协议

携带。

请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器

端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度有如下因素决定：

不管实体头段是否出现在信息中，不包括信息体的的响应信息总以头段后第一和空行结束。

如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。

服务器关闭连接。

注意：RTSP目前并不支持HTTP/1.1"块"传输编码，需要有内容长度头。假如返回适度演示描

述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即

使必须有内容长度，且长度没显式给出，规则可确保行为合理。

从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP

定义了附加状态代码，而没有定义任何HTTP代码。

6.3.4 实体

如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体由实体头文件和试

题体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可

分别指用户和服务器。

实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附

加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽

略，而让代理转发。

6.3.5 连接

RTSP请求可以几种不同方式传送：

1、持久传输连接，用于多个请求/响应传输。

2、每个请求/响应传输一个连接。

3、无连接模式。

传输连接类型由RTSP URI来定义。对 "rtsp" 方案，需要持续连接；而"rtspu"方案，调用

RTSP 请求发送，而不用建立连接。

不象HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否

则媒体服务器没有可*途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途

径。

6.3.6 方法定义

方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。

某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和

服务器 *** 作复杂，并强加附加开销，除非有必要，应避免这样做。插入二进制数据仅在RTSP通

过TCP传输时才可使用。流数据（如RTP包）用一个ASCII美圆符号封装，后跟一个一字节通道标

识，其后是封装二进制数据的长度，两字节整数。

---