概述
计算机网络最初是为传送数据设计的。因特网 IP 层提供的 “尽最大努力交付” 服务以及每一个分组独立交付的策略，对传送数据信息十分合适。因特网使用的 TCP 协议可以很好地解决P层不能提供可靠交付这一问题。
音频/视频常称为多媒体信息
多媒体信息（包括声音和图像信息）与不包括声音和图像的数据信息有很大的区别，其中最主要的两个特点如下。
1.多媒体信息的信息量往往很大；
2.在传输多媒体数据时，对时延和时延抖动均有较高的要求；
在传送 时延敏感(delay sensitive) 的实时数据时，不仅传输时延不能太大，而且时延抖动也必须受到限制。输在运输层应采用用户数据报协议 UDP 而不使用TCP协议。这就是说，对于传送实时数据，宁可丢失少量分组（当然不能丢失太多)，也不要太晚到达的分组。
在连续的音频或视频数据流中，很少量分组的丢失对播放效果的影响并不大（因为这是由人来进行主观评价的)，因而是可以容忍的。 丢失容忍(loss tolerant) 也是实时数据的另一个重要特点。
目前因特网提供的音频/视频服务大体上可分为三种类型：
1.流式(streaming)存储音频/视频
这种类型是先把已压缩的录制好的音频/视频文件(如音乐、电影等）存储在服务器上。用户通过因特网下载这样的文件。流式存储音频/视频文件下载的特点是 边下载边播放 ，即在文件下载后不久（例如，几秒钟到几十秒钟后）就开始连续播放。
2.流式实况音频/视频
这种类型和无线电台或电视台的实况广播相似，不同之处是音频/视频节目的广播是通过因特网来传送的。 流式实况音频/视频是一对多（而不是一对一）的通信 。它的特点是：音频/视频节目不是事先录制好和存储在服务器中，而是在发送方 边录制边发送 （不是录制完毕后再发送)。在接收时也是要求能够连续播放。接收方收到节目的时间和节目中的事件的发生时间可以认为是同时的（相差仅仅是电磁波的传播时间和很短的信号处理时间)。流式实况音频/视频按理说应当采用多播技术才能提高网络资源的利用率，但目前实际上还是使用多个独立的单播。流式实况音频/视频现在还不普及。
3.交互式音频/视频
这种类型是用户使用因特网和其他人进行实时交互式通信。现在的因特网电话或因特网电视会议就属于这种类型。
流式存储音频/视频
流式存储音频和视频是一种通过网络按照时间顺序传输音频和视频数据的技术。这种方式允许用户在数据传输的同时播放内容，而无需等待整个文件下载完成。
传统浏览器从服务器下载音频/视频文件的三个步骤：
1.用户从客户机(client machine)的浏览器上用 HTTP协议向服务器请求下载某个音频/视频文件，GET表示请求下载的HTTP报文。请注意，HTTP使用TCP连接。
2.服务器如有此文件就发送给浏览器，RESPONSE 表示服务器的 HTTP 响应报文。在响应报文中就装有用户所要的音频/视频文件。整个下载过程可能会花费很长的时间。
3.当浏览器完全收下这个文件后，就可以传送给自己机器上的媒体播放器进行解压缩，然后播放。
具有元文件的万维网服务器
在万维网服务器中，除了真正的音频/视频文件外，还增加了一个元文件(metafile) 。
所谓元文件就是一种非常小的文件，它描述或指明其他文件的一些重要信息。这里的元文件保存了有关这个音频/视频文件的信息。
1.浏览器用户点击所要看的音频/视频文件的超链，使用 HTTP 的 GET 报文接入到万维网服务器。实际上，这个超链并没有直接指向所请求的音频/视频文件，而是指向一个元文件。这个元文件有实际的音频/视频文件的统一资源定位符 URL。
2.万维网服务器把该元文件装入 HTTP 响应报文的主体，发回给浏览器。在响应报文中还有指明该音频/视频文件类型的首部。
3.客户机浏览器收到万维网服务器的响应，分析其内容类型首部行，调用相关的媒体播放器（客户机中可能装有多个媒体播放器），把提取出的元文件传送给媒体播放器。
4.媒体播放器使用元文件中的 URL 直接和万维网服务器建立 TCP 连接，并向万维网服务器发送 HTTP 请求报文，要求下载浏览器想要的音频/视频文件。
5.万维网服务器发送 HTTP 响应报文，把该音频/视频文件发送给媒体播放器。媒体播放器在存储了若干秒的音频/视频文件后（这是为了消除抖动），就以音频/视频流的形式边下载边解压缩边播放。
媒体服务器
媒体播放器使用的是 HTTP 的服务，但 HTTP 是在 TCP 连接上运行的。TCP要重传出错的或丢失的报文段，因而不适合于流式音频/视频文件的传送。当网络出现拥塞时，流式音频/视频文件的播放就会暂停（因为在缓存中存放的数据已经用完了)。
因此，应当不使用 TCP 而使用UDP。由于万维网服务器都是使用HTTP协议，因此我们需要另外的一种服务器，即 媒体服务器(media server) 。
媒体服务器也称为 流式服务器(streaming server) 。媒体服务器和万维网服务器可以运行在一个端系统内，也可以运行在两个不同的端系统中。
媒体服务器与普通的万维网服务器的最大区别就是，媒体服务器支持流式音频和视频的传送。媒体播放器与媒体服务器的关系是客户与服务器的关系。现在媒体播放器不是向万维网服务器而是向媒体服务器请求音频/视频文件。媒体服务器和媒体播放器之间采用另外的协议进行交互。
采用媒体服务器后，下载音频/视频文件的前三个步骤仍然和上一节所述的一样，区别就是后面两个步骤,即:
4.媒体播放器使用元文件中的 URL 接入到媒体服务器，请求下载浏览器所请求的音频/视频文件。下载可以借助于使用 UDP 的任何协议，例如使用实时运输协议 RTP。
5.媒体服务器给出响应、把该音频/视频文件发送给媒体播放器。媒体播放器在迟延了若干秒后，以流的形式边下载边解压缩边播放。
媒体服务器也可以在 TCP 连接上向媒体播放器传送音频/视频文件。由于 TCP 有重传丢失报文段的功能，因此音频/视频文件还原后的质量应当会更好些（只要重传时不造成缓存的清空）。但如果网络发生分组丢失而重传时应用程序的缓存已被抽空，那么媒体服务器在播放音频/视频文件时就会出现暂停。
实时流式协议 RTSP
RTSP（Real-Time Streaming Protocol）是一种用于实时流媒体传输的网络协议。它是一个应用层协议，通常用于控制多媒体服务器之间的实时流传输。RTSP 的主要目标是提供一种标准的方法，使客户端能够控制和接收来自多媒体服务器的实时流媒体数据。
主要特点：
1.控制和传输分离：RTSP 协议将控制和数据传输分离。控制消息负责控制媒体播放，而实际的媒体数据通过独立的传输协议（通常是 RTP）进行传输。
2.请求-响应模型：RTSP 使用请求-响应模型，类似于 HTTP。客户端通过发送 RTSP 请求来请求服务器执行某些操作，服务器则响应以提供相应的信息。
3.会话（Session）管理：RTSP 支持建立和管理会话，以便客户端可以在多个请求之间保持状态，并保留有关媒体传输的上下文信息。
4.媒体描述和控制：RTSP 允许客户端获取有关服务器上媒体资源的描述信息，并通过控制命令（如播放、暂停、停止）来操纵媒体流。
5.多媒体流支持：RTSP 被设计用于支持各种多媒体流，包括音频、视频、以及其他可能的数据流。
6.媒体定位和同步：RTSP 允许客户端定位媒体流的特定位置，以及在多个媒体流之间保持同步。
7.广泛用于 IP 监控和流媒体应用：RTSP 在 IP 监控和流媒体领域得到广泛应用，用于实时视频传输和控制。
工作原理：
1.客户端发起连接：客户端通过建立到 RTSP 服务器的连接来初始化会话。
2.获取媒体描述：客户端通过 RTSP 请求获取有关媒体资源的描述信息，通常使用 SDP（Session Description Protocol）格式。
3.控制命令：客户端通过 RTSP 发送控制命令，如播放、暂停、停止，以及媒体流的定位和同步。
4.数据传输：媒体数据通过独立的传输协议（通常是 RTP）进行实时传输。
5.会话管理：RTSP 支持会话管理，允许客户端在多个 RTSP 请求之间保持状态和上下文信息。
RTSP 协议为实时流媒体提供了一种标准化的控制机制，使得客户端可以与服务器交互，并实时获取和操控多媒体内容。在流媒体应用中，RTSP 通常与 RTP（Real-time Transport Protocol）一起使用，以实现媒体数据的实时传输。
交互式音频/视频
交互式音频/视频指的是一种通过网络实现实时双向通信的音频和视频传输。
IP 电话
狭义的 IP 电话 就是指在IP网络上打电话。所谓“IP网络”就是“使用IP协议的分组交换网”的简称。这里的网络可以是因特网，也可以是包含有传统的电路交换网的互联网，不过在互联网中至少要有一个IP网络。
广义的 IP 电话 则不仅仅是电话通信，而且还可以是在 IP 网络上进行交互式多媒体实时通信（包括话音、视像等)，甚至还包括 即时传信IM(Instant Messaging) 。即时传信是在上网时就能从屏幕上得知有哪些朋友也正在上网。
IP 电话网关 ：是公用电话网与 IP 网络的接口设备。
(1)在电话呼叫阶段和呼叫释放阶段进行电话信令的转换；
(2)在通话期间进行话音编码的转换。
有了这种 IP 电话网关，就可实现 PC 机用户到固定电话用户打 IP 电话（仅需经过 IP 电话网关一次)，以及固定电话用户之间打 IP 电话（需要经过 IP 电话网关两次)。
IP电话的 通话质量主要由两个因素 决定：一个是 通话双方端到端的时延和时延抖动 ，另一个是 话音分组的丢失率 。但这两个因素都是不确定的，而是取决于 当时网络上的通信量 。若网络上的通信量非常大以致发生了网络拥塞，那么端到端时延和时延抖动以及分组丢失率都会很高，这就导致IP电话的通话质量下降。因此，一个用户使用 IP 电话的通话质量 取决于当时其他的许多用户的行为 。
在 IP 电话的通信中，至少需要两种应用协议：
一种是信令协议，它使我们能够在因特网上找到被叫用户。
另一种是话音分组的传送协议，它使我们用来进行电话通信的话音数据能够以时延敏感属性在因特网中传送。
提供实时交互式音频/视频服务所需的应用层协议
实时运输协议 RTP
RTP 为实时应用提供端到端的运输，但不提供任何服务质量的保证 。
需要发送的多媒体数据块（音频/视频）经过压缩编码处理后，先送给 RTP 封装成为 RTP 分组（也可称为RTP报文)，RTP分组再装入运输层的 UDP 用户数据报，然后再向下递交给 IP 层。
实际上，RTP 是一个 协议框架 ，因为它只包含了实时应用的一些共同的功能。RTP 自己并不对多媒体数据块做任何处理，而只是向应用层提供一些附加的信息，让应用层知道应当如何进行处理。
从应用开发者的角度看， RTP应当是应用层的一部分 。在应用程序的发送端，开发者必须编写用 RTP 封装分组的程序代码，然后把 RTP 分组交给 UDP 套接字接口。在接收端，RTP 分组通过 UDP 套接字接口进入应用层后，还要利用开发者编写的程序代码从 RTP 分组中把应用数据块提取出来。
然而 RTP 的名称又隐含地表示它是一个 运输层协议 。这样划分也是可以的，因为 RTP 封装了多媒体应用的数据块，并且由于 RTP 向多媒体应用程序提供了服务（如时间截和序号)，因此也可以把 RTP 看成是在 UDP 之上的一个运输层子层的协议。
值得注意：1.RTP 分组只包含 RTP 数据，而控制是由另一个配套使用的 RTCP 协议提供的；2.RTP 在端口号1025 到 65535 之间选择一个未使用的 偶数 UDP 端口号，而在同一次会话中的 RTCP 则使用下一个 奇数 UDP端口号。但端口号 5004 和 5005 则分别用作RTP和RTCP的默认端口号。
数据包格式：RTP使用一种灵活的数据包格式，包含头部和负载两个部分。头部包含序列号、时间戳、同步源标识符等信息，用于确保数据包的顺序和同步。负载部分则包含实际的音视频数据。
传输协议：RTP本身并不负责数据的传输，而是依赖底层的传输协议，通常与用户数据报协议（UDP）结合使用。UDP提供了一种无连接、低延迟的传输方式，非常适合实时性要求较高的音视频应用。
时间戳和同步源：RTP头部中的时间戳用于同步不同媒体流中的数据，确保它们能够按照正确的时间顺序播放。同步源标识符用于唯一标识不同的媒体流，以便接收端能够正确解析和还原数据。
动态负载类型： RTP允许在负载部分使用动态负载类型 ，这使得它非常灵活，可以适应不同的音视频编码格式。动态负载类型通过RTP配置协商确定，确保发送端和接收端能够正确解析数据。
实时运输控制协议 RTCP
实时运输控制协议（RTCP，Real-Time Transport Control Protocol）是与实时运输协议（RTP）配对使用的协议，用于 提供实时音视频传输中的控制和监测功能 。
RTCP的主要任务是提供有关媒体传输质量、网络状况和参与者信息的反馈，从而帮助维护和改善实时音视频通信的质量。
RTCP 分组（也可称为 RTCP报文）也使用 UDP 来传送，但 RTCP 并不对音频/视频分组进行封装。由于 RTCP 分组很短，因此可把多个 RTCP 分组封装在一个 UDP 用户数据报中。RTCP 分组周期性地在网上传送，它带有发送端和接收端对服务质量的统计信息报告（如已发送的分组数和字节数、分组丢失率、分组到达时间间隔的抖动等)。
RTCP使用的五种分组类型，都使用同样的格式：
| 类型 | 缩写 | 意义 |
|---|---|---|
| 200 | SR | 发送端报告 |
| 201 | RR | 接收端报告 |
| 202 | SDES | 源点描述 |
| 203 | BYE | 结束 |
| 204 | APP | 特定应用 |
结束分组BYE 表示关闭一个数据流。
特定应用分组APP 使应用程序能够定义新的分组类型。
接收端报告分组RR 用来使接收端周期性地向所有的点用多播方式进行报告。
接收端每收到一个 RTP 流（一次会话包含有许多的 RTP 流）就产生一个接收端报告分组 RR。
RR分组的内容有：所收到的 RTP 流的 SSRC；该 RTP 流的分组丢失率（若分组丢失率太高，发送端就应当适当降低发送分组的速率)；在该RTP流中的最后一个RTP分组的序号；分组到达时间间隔的抖动等。
发送 RR 分组有两个目的：
1.可以使所有的接收端和发送端了解当前网络的状态；
2.可以使所有发送 RTCP 分组的站点自适应地调整自己发送 RTCP 分组的速率，使得起控制作用的 RTCP分组不要过多地影响传送应用数据的RTP分组在网络中的传输。
通常是使 RTCP 分组的通信量不超过网络中的数据分组的通信量的 5%，而接收端报告分组的通信量又应小于所有 RTCP 分组的通信量的75%。
发送端报告分组SR 用来使发送端周期性地向所有接收端用多播方式进行报告。
发送端每发送一个 RTP 流，就要发送一个发送端报告分组 SR。
SR 分组的主要内容有：该 RTP 流的 SSRC；该 RTP 流中最新产生的 RTP 分组的时间戳和绝对时钟时间（或墙上时钟时间wall clock time)；该RTP流包含的分组数；该RTP流包含的字节数。
绝对时钟时间是必要的。因为 RTP 要求每一种媒体使用一个流。例如，要传送视频图像和相应的声音就需要传送两个流。有了绝对时钟时间就可进行图像和声音的同步。
源点描述分组SDES 给出会话中参加者的描述，它包含参加者的规范名CNAME(Canonical NAME)。规范名是参加者的电子邮件地址的字符串。
H.323
H.323是一个ITU-T（国际电信联盟电信部门）定义的标准，用于在计算机网络中实现语音、视频和数据的多媒体通信。H.323协议套件被广泛用于实时通信应用，如IP电话、视频会议和互联网传真。
H.323的主要组成部分：
1.终端（Terminal）：
终端是H.323体系结构中的用户设备，可以是IP电话、视频摄像头、软电话或其他支持H.323标准的终端设备。终端负责与其他终端进行通信。
2.网关（Gateway）：
网关是连接H.323网络和传统电话网络（PSTN）之间的设备。它实现了IP网络和传统电话网络之间的协议转换和信令转换，允许H.323终端与传统电话用户进行通信。
3.网守（Gatekeeper）：
网守是H.323网络中的一个可选组件，用于提供呼叫控制、地址解析和带宽管理等服务。网守帮助终端找到对方终端的地址，管理呼叫建立和释放，并协调多媒体会话。
4.多点控制单元（Multipoint Control Unit，MCU）：
MCU是用于支持多点会议的设备。它负责协调和管理多个终端之间的多点通信，包括音视频混合、广播和选择等功能。
5.H.323终端和网守之间的通信协议：
H.323终端和网守之间的通信协议包括RAS（Registration, Admission, and Status）协议，用于地址解析、注册和状态通知；Q.931协议，用于呼叫控制和建立；H.225.0协议，用于传输呼叫信令和媒体数据。
H.323的特点：
1.灵活性： H.323支持多种网络环境，包括局域网（LAN）、广域网（WAN）和因特网，因此非常灵活。
2.多媒体支持： H.323支持音频、视频和数据的传输，适用于实时通信的多媒体应用。
3.互操作性： H.323标准确保了不同厂商生产的H.323设备可以相互通信，提高了系统的互操作性。
4.开放标准： H.323是一个开放的国际标准，使得开发者能够基于这个标准构建自己的实时通信应用。
会话发起协议SIP
会话发起协议（Session Initiation Protocol，SIP）是一种用于在计算机网络上建立、修改和终止多媒体会话的通信协议。SIP常被用于实时通信应用，如互联网电话（VoIP）、视频会议和即时消息。
SIP 使用文本方式的客户服务器协议。SIP系统只有两种构件，即 用户代理(user agent) 和 网络服务器(network server) 。
用户代理包括两个程序，即 用户代理客户UAC (User AgentClient) 和 用户代理服务器UAS (User Agent Server)，前者用来发起呼叫，后者用来接受呼叫。
网络服务器分为 代理服务器(proxy server) 和 重定向服务器(redirect server)。代理服务器接受来自主叫用户的呼叫请求（实际上是来自用户代理客户的呼叫请求)，并将其转发给被叫用户或下一跳代理服务器，然后下一跳代理服务器再把呼叫请求转发给被叫用户（实际上是转发给用户代理服务器)；重定向服务器不接受呼叫，它通过响应告诉客户下一跳代理服务器的地址，由客户按此地址向下一跳代理服务器重新发送呼叫请求。
改进“尽最大努力交付”的服务
。。。。 这个不学了，，，用的时候再看
谢希仁第五版《计算机网络》学习笔记
