Day5：应用层——CDN、 TCP 套接字编程、 UDP 套接字编程、小结

加油！偷博人！

0、killer application（杀手级应用）

1.网络流量占比大
2.最能吸引用户
比如，Video Application：youtube，tiktok，iqiyi，Tencent movie…

---

 视频流量：占据着互联网大部分的带宽
 挑战：异构性
 不同用户拥有不同的能力（例如：有线接入和移动用户；带宽丰富和受限用户）
 解决方案: 分布式的，应用层面的基础设施

---

再来口水话谈谈视频：

•  视频：固定速度显示的图像序列。 e.g. 24 images/sec

•  网络视频特点：
   高码率：>10x于音频,高的网络带宽需求
   可以被压缩
   90%以上的网络流量是视频

•  数字化图像：像素的阵列
   每个像素被若干bits表示

•  编码：使用图像内和图像间的冗余来降低编码的比特数
   空间冗余(图像内)
   时间冗余(相邻的图像间)
  例子如下
  
  frame帧
  

---

0.1存储视频的流化服务 （边下边看）

多媒体流化服务：DASH

•  DASH: Dynamic, Adaptive Streaming over HTTP（在http之上的动态自适应的流化技术）

•  服务器:
   将视频文件分割成多个块
   每个块独立存储，编码于不同码率（8-10种）
   告示文件（manifest file）: 提供不同块的URL

•  客户端:
   先获取告示文件
   周期性地测量服务器到客户端的带宽
   查询告示文件,在一个时刻请求一个块，HTTP头部指定字节范围
   如果带宽足够，选择最大码率的视频块
   会话中的不同时刻，可以切换请求不同的编码块 (取决于当时的可用带宽)

•  “智能”客户端: 客户端自适应决定
   什么时候去请求块 (不至于缓存挨饿，或者溢出)
   请求什么编码速率的视频块 (当带宽够用时，请求高质量的视频块)
   哪里去请求块 (可以向离自己近的服务器发送URL，或者向高可用带宽的服务器请求)
  
  理解的太粗糙了，还不太懂

---

一、CDN （Content Distribution Networks）

 挑战: 服务器如何通过网络向上百万用户同时流化视频内容 (上百万视频内容)?

•  选择1: 单个的、大的超级服务中心“megaserver”
   服务器到客户端路径上跳数较多，瓶颈链路的带宽小导致停顿
   “二八规律”决定了网络同时充斥着同一个视频的多个拷贝，效率低（付费高、带宽浪费、效果差）
   单点故障点，性能瓶颈
   周边网络的拥塞