|
源。识别符的数目在CC 域中给定。 2.3 NAT 协议 互联网即将用完IPv4 地址，这是没有争议的。但是，争议的问题是互联网服务提供商 165 是直接迁移到IPv6 以解决这个问题，还是将采用运营商级网络地址转换(NAT)等替代方法在 其新用户中共享剩余的IPv4 地址。 到目前为止最成功的是网络地址转换(NAT)方法。尤其是NAT44，该技术将一个IPv4 地址转换成了另一个IPv4 地址。私有 IPv4 地址要在所给网络中使用;这里是假设在一个网 络中，大多数IP 设备都只需要和相同网络中的其他IP 设备进行连接。 170 NAT44(通常位于路由或防火墙之中)放在与公共互联网相接的网络边缘。NAT 拥有若 干独特的IPv4 地址。随着数据包从内部或私有界面发送到外部或公共界面，NAT 用其公共 IPv4 地址中的一个代替了数据包的私有IPv4 地址。NAT 技术通过映射内部地址到外部地址 的路径来记住数据包源自哪个内部设备。 网络地址转换(NAT,Network Address Translation)属接入广域网(WAN)技术,是一种将私有(保留) 地址转化为合法IP 175 地址的转换技术,它被广泛应用于各种类型Internet 接入方式和各种类型的网络中。 原因很简单，NAT 不仅完美地解决了lP 地址不足的问题，而且还能够有效地避免来自网络外部的攻 击，隐藏并保护网络内部的计算机。 NAT 可以分为Basic NAT 和PAT： - Basic NAT 只转化IP，不映射端口。 180 - PAT 除了转化IP，还做端口映射，可以用于多个内部地址映射到少量（甚至一个）外 部地址。 NAT 还可以分为静态NAT 和动态NAT： - 静态NAT，将内部网络中的每个主机都永久映射成 外部网络中的某个合法的地址， 多用于服务器。 185 - 动态NAT，则是在外部网络中定义了一个或多个合法地址，采用动态分配的方法映 射到内部网络。 3 流媒体服务器设计与实现 3.1 主要数据结构及算法 3.1.1 RTP 数据包头部定义 190 typedef struct { /**//* byte 0 */ uint8_t csrc_len:4; /**//* expect 0 */ uint8_t extension:1; /**//* expect 1, see RTP_OP below */ 195 uint8_t padding:1; /**//* expect 0 */ uint8_t version:2; /**//* expect 2 */ /**//* byte 1 */ uint8_t payload:7; /**//* RTP_PAYLOAD_RTSP */ uint8_t marker:1; /**//* expect 1 */ 200 /**//* bytes 2, 3 */ uint16_t seq_no; /**//* bytes 4-7 */ uint32_t timestamp; /**//* bytes 8-11 */ 205 uint32_t ssrc; /**//* stream number is used here. */ } RTP_FIXED_HEADER; 3.1.2 MPEG-4 打包rtp 算法 Mpeg‐4 打包rtp 的算法[3]的伪代码如下： While(MPEG‐4 数据流结束前) 210 {If(发现下一个VOP 起始码) {If(当前分段长度≤去除头部字段长度的路径MTU 值) {把此段数据打入RTP 包} else {把尽可能多的宏块打入RTP 包} 215 } else {对剩余数据打包} ｝ 3.1.3 AMR 打包rtp 算法 220 AMR 打包rtp 算法[4]，以流程图表示如下： 图3 视频流结构图 Fig.3 streaming video char 225 3.2 系统设计 本系统采用了boost C++库的asio 异步通信库和线程库进行设计和实现，保证了系统的 并发性，高效性以及跨平台性。系统设计如图4 所示。 图4 系统设计图 Fig.230 4 system design chart Server:系统主程序，负责初始化环境变量，线程池，异步通信机制。 RtspServicer:主要负责与客户端进行协商，并为rtpservicer 进行相关初始化和控制。 Request 和reply 分别代表客户端请求和服务器回复的类抽象。 235 RequestParser:解析request。 RequestHandler：对不同request 进行不同的处理。 RtpServicer:负责往客户端发送rtp 数据。 FileParser:负责解析媒体文件，提取帧数据 RtpPacketer：对媒体帧进行处理，打包成rtp 包。 240 本系统主要使用了rtsp 协议和rtp 协议，其主要工作机制[5]如图所示： 图5 系统工作流程 Fig.5 system work flow chart 流媒体文 件或者流 Demux Rtsp 协商 音频流 视频流 rtp 数据包 发送客户端 245 3.3 协议交互过程 RTP 协议并没有规定其传输层的实现，传输层主要有tcp 和udp 协议。但是基于tcp 有 以下特点. ·TCP 重传机制 ·TCP 拥塞控制机制 250 ·TCP 报文头比UDP 保文头要大 ·TCP 的启动速度慢 TCP 协议不适合传输实时的多媒体数据,新的为实时传输多媒体数据的RTP 协议也就应 运而生。流媒体技术采用RTSP-on-TCP/RTP-on-UDP 的方式进行交互和数据传输[6]。 面对ip 地址的减少，很多运营商或者局域网都使用了内网ip，这里就涉及到了在对内 255 网ip 客户端进行udp 传输时，需要对内网ip 进行穿透—也就是udp 打洞，NAT 穿越技术。 这样做的前提是该路由器支持NAT 协议。协议交互过程如图6 所示。 图6 系统交互图 Fig.6 system interaction chart 260 4 结论 3G 移动通信网作为日趋完善的无线网络，为流媒体的应用提供了一个崭新的平台，也 为流媒体技术更好的为使用者服务开辟了新的传输媒体。随着手机增值业务的不断发展，视 音频流媒体业务将会成为3G 增值业务的一个热点，通过手机实现视频点播、收看视频节目 265 成为最能吸引用户眼球的业务之一。 本文针对移动互联网和手持终端的特点，对流媒体协议和原理进行了详细的分析，并提 出了一套跨平台的服务端实现方案，并且给出了程序的具体实现。本系统已经过实际测试， 服务器测试平台为ubuntu,opensuse 及windows，客户端测试系统包括android,symbian, windows mobile. 270 由于本人能力和时间有限，可能本系统仍存在不足之处，比如对于系统流量的监控措施， 希望以后继续改进。 5 致谢 在本文的撰写及系统的开发过程中，感谢我的导师张笑燕以及杜晓峰老师给我提供的帮 助与指点。 学术论文网Tag：代写论文 代写代发论文 论文发表 职称论文发表 |
