计算机网络第7章总结

拿记事本写的，有些乱，做个笔记就不讲究了

总的来说，对于多媒体这一块，使用RTP的加上RTSP，或者私有的SIP协议，前后两者都在一定程度上效仿http的模式，避免udp流 的各种缺陷。
（如果有不对的欢迎大家讨论指出来）

偷了一张图：

HTTP与RTSP传输的差别。概括的讲，RTSP被许多公司防火墙拒绝，而HTTP可以作为一个普通的文件通过；RTSP适合于大数据量、高可用性的流，如直播事件、长事件或大型文件；HTTP更适合于较小的数据传输和交互；当终端用户正在观看时，RTSP允许用户在服务器有效的回放媒体，HTTP更象下载一段媒体并在客户机上播放。从终端用户观点来看，RTSP看起来像是文件从中心位置播放，有点象广播，而HTTP感觉更象时从视频库中取视频，并在家里的机器上播放。从服务质量的观点上看，对于流，RTSP有更好的体验，RTSP提供类似于VCR的媒体控制，如暂停、快进、倒退和绝对定位。使用HTTP传输，只能在整个流下载完成后，播放器软件再模拟该过程。虽然，RTSP能够使用TCP或UDP，但是RTSP控制经常与RTP联合使用，以最好的服务质量传送实际的媒体数据。

1.对流式视频最重要的性能测量是平均吞吐量；

2.流式视频，指的是我们实现录制好的视频，在服务器，我们从客户端对他 进行访问；
为了提供连续的播放，按照发送的时序到达，接受，并丢包控制在一定范围；重点是缓存和预取来实现用户的连续的获取；

3.定时考虑和数据丢失的容忍度是使用udp，需要一些方式保证的；

4.与web，浏览器等不同，要求传输的数据是完全而完整的，多媒体网络应用更关心时延敏感和容忍丢包；

5.流式存储音频和视频----会话式ip语音和视频----流式实况视频音频

类比：播放器—qq视频通话–看电视

6.流式视频系统分为：udp流，http流，适应性HTTP流；

7.因为用户是可以容忍在视频播放之前的初始时延，在这个时间客户会在接收到数据后缓存，这个缓存可以实现：
比如隐藏客户端对于服务器到客户端的网络时延的变化，客户端只需要关心从缓存读取视频数据就行，对于时延变化，只要缓存足够，这个时延客户是无法察觉的
即使服务器的视频后续视频到达，只要缓存还有空间就可以接受，不必担心数据被覆盖；

8.实时传输协议RTP

9.使用udp流进行视频数据传输有三大缺点：
1.由于服务器与客户端之间的网络带宽是无法预测的，可能会有丢包的事件发生，或者时延较大，虽然尽可能地让udp发送的数据包等于或者接近客户端的消耗速率，但是网络传输的实况不确定性会导致用户体验不好；
2.udp流必须要求服务器除了发送客户端需要的数据，还必须要并行维护一个单独的控制连接，这个连接是RSTP协议的；
通过该链接，客户可以发送有关于会话对的状态变化指令，处理客户端到服务器的交互请求和跟踪客户状态；需要增加部署一些RSTP控制服务器，成本和复杂；
3.许多的防火墙配置为阻塞udp流量，防止这些防火墙后面的用户接受udp流；

10.http流，我们把视频当做一个普通的文件处理，使用tcp连接，用http发送http get请求，将数据依然是保存到客户端的缓存中，缓存超过一定阈值就开始在客户端播放视频；tcp可靠但是有拥塞超时的机制，但是实际上通过客户端
缓存和预取就能够解决；可以很好的解决udp流防火墙的问题和不用部署rstp服务器；

11.预取机制：意思是通过使用高于消耗速率的大小的数据包进行传输，也就说通俗意义上的只要我发的够大，你的消耗就赶不上我方发送的；
这样即使后面网络状态变化，也不会对客户端造成影响；因此要使用tcp连接；因为tcp的拥塞避免尽量会使用所有网络可用带宽；

12.缓存：从服务器的发送缓存，到客户端的接收缓存，到客户端应用的应用缓存，再到被应用读取的缓存解析显示到屏幕上；

13.预取的缺点是发送速率要高于消耗速率，这样子对于不同的用户的带宽最终呈现的效果是不一样的；
即客户端接收到的相同编码的视频，要跟网络状况结合讨论，于是
HTTP的动态性适应流-----DASH；就是传输的版本可以是不同的，这个有客户选择；
大概就是播放器的高清、清晰、流畅不同版本选择传输速率也不同；
服务器对同一个视频的不同版本都有一个不同的url，和一个告示文件
客户首先请求该告示文件知道版本信息进行选择；

14.cdn：内容分发网络；部署原则：1.深入，尽量接近互联网边缘，也就是尽量在各个底层一些的isp接入
深入cdn服务器，这样用户体验和时延，对于给isp的成本也降低；2.部署在关键点的位置，接近第一层的isp和pop的位置，只需要少量的集群化数据中心的部署，就可以建立一个自己内部的cdn网络，并使用专用的高速网络；

15.存储原则：没有的资源就请求其他cdn服务器，然后本地缓存，满了就删除最久未使用；

16.cdn能够通过dns服务器重定向到对应的cdn代理服务器，但是这个重定向的策略是什么？
1.地理位置最近，但是ldns可能配置的位置映射不是地理位置最近，出问题；
2.依据最近的连接过程中的流量状况选择；
3**.IP任播**：对于所有的cdn服务器初始化相同的IP地址，然后http请求让BGP域间路由协议去路由转发选择
对用户来说最好的路径；但是要考虑如果一个集群负载或者过载，这时候应该考虑不要定向到这个服务器

17.会话式ip语音和视频：对于这个默认使用的是udp传输协议，但是丢包，不可靠，时延，抖动这些都会造成用户体验极差，不符合功能设计；
解决方式：
1.时间戳；类似加序号的方式，发送方为每个块添加一个时间戳，但是接收方为每个块的播放设定一个时间，
在此之前到达就接受，否则丢弃；问题是会不会把这个时间戳的数据当成是提前到达的呢？
答案是不会，因为是发送方加戳，是按顺序的；在指定时间没有到达就是放弃；
2.接收方延迟播放：类似缓存机制，足够的缓存数据到达才开始播放；
3.自适应计算播放时间
4.自适应选择传输的版本
解决丢包方案：FEC（前向纠错）机制—
1.类似校验和，我们发送一个通过所有数据的计算异或得到的一个结果作为冗余信息发送给接收端，即使丢了一个包，也可以通过这个值计算出来；问题是这个块也可能会丢失或者丢了不止一个包；

2.我们可以在高质量压缩块后面添加低质量的压缩块，因为低质量的压缩块会包含更多的信息但是质量比较低

通过这个方案，同样的大小低质量块对于音频视频的信息多但是压缩的多，高质量信息少但是质量高，因此可以在高质量后面添加几个高质量块联合压缩到一起的块进行传输，保证连续的客户的连续体验；

总体来说：FEC（前向纠错）机制—机制就是发送一个冗余信息，要么可以让接收端重建的丢失包，要么就是发送包头加一些之前的包的压缩信息，这样即使前一个包丢失也可以有一个低质量的缓冲

但是如果连续多个包丢失？
丢包方案要添加：交织----
1.将数据进行分片之后交叉发送，这样就可以丢失大包也只是丢失了一些原本的分片信息
总体通过序号进行重组的时候就影响不大，但是交叉发送和接受重组需要时延；

于是产生第三种方案：差错掩盖----犯了错就找个差不多的代替
但是如果丢失过多，也不实用，怎么掩盖都不自然；
最简单，用之后接受的分组复制代替丢失的；

18.RTP：实时会话式协议，将相机和麦克风的数据量化PCM编码之后，应用会对他们添加RTP头部，包含编码类型，传输的数据类型，序号，时间戳等和其他有用的头部信息封装到UDP；依然不保证时延，可靠交付，按序到达；

19.dns服务器将域名翻译成一个ip地址，sip注册器将一个用户翻译成一个动态更新的ip地址sip注册器会对于sip用户使用应用时，添加一个跟踪器返回用户当前ip，即使用户更换ip和设备，也会被跟踪器对这个用户在sip服务器中更新这个用户的数据 ；（话说这个sip要是被攻击大家的ip都暴露出来，他跟踪啊，是不是就是我们平常类似打开高德要获取你的位置这样呢，估计可能问都不问自动获取保存）

20.链路调度：这个就了解一下，应该不会问的细，就看fifo和优先级，漏桶机制以后用到再说吧；

21.流量隔离的效率不高，但是标记分组如何衡量一个公平的优先级？不然低优先级的一直时延或者丢包吗？
在一直有高优先级的数据在路由中，用户体验极差；
优先级：流量配置文件

22.diffser还有点意思

23.通过分组标记，监管，流量隔离，链路调度这都是为了实现多媒体传输在下层尽可能减少丢包和时延的办法；

24.资源预留，阻塞和准入，感觉和操作系统那点死锁有点像；这个是资源预留协议
（RSVP），又知道一个新的协议可以装13了…道理说出来简单，如何预留和保证实现？
反正理论听起来不错；

这一章主要cdn，RTP，http流和DASH 有些意思，可以看看