P2P文件分发： BitTorrent
p2p的管理模式
- 非结构化p2p（分布式散列表）： 每个peer之间构成的关系（上传下载），互通有无，就构成了一个有序的覆盖网（类似于环、树的关系）
- 结构化P2P： peer节点之间构成的覆盖关系是任意的、无序的。
- 文件被分为一个个块256KB
- 网络中的这些peers发送接收文件块，相互服务
Peer加入torrent
- 一开始没有块，但是将会通 过其他节点处累积文件块
- 向跟踪服务器注册，获得 peer节点列表，和部分peer 节点构成邻居关系 (“连接 ”)
- 当peer下载时，该peer可以同时向其他节点提供上载服务
- Peer可能会变换用于交换块的peer节点
- 扰动churn : peer节点可能会上线或者下线
- 一旦一个peer拥有整个文件，它会（自私的）离开或者保 留（利他主义）在torrent中
BitTorrent: 请求，发送文件块
请求块：
- 在任何给定时间，不同 peer节点拥有一个文件块 的子集
- 周期性的，Alice节点向 邻居询问他们拥有哪些块 的信息
- Alice向peer节点请求它 希望的块，稀缺的块
发送块：一报还一报titfor-tat
- Alice向4个peer发送块，这些 块向它自己提供最大带宽的服 务
- 其他peer被Alice阻塞 (将不会 从Alice处获得服务)
每10秒重新评估一次：前4位
- 每个30秒：随机选择其他peer 节点，向这个节点发送块
- “优化疏通” 这个节点
新选择的节点可以加入这个top 4
BitTorrent: tit-for-tat
(1) Alice “优化疏通” Bob
(2) Alice 变成了Bob的前4位提供者; Bob答谢Alice
(3) Bob 变成了Alice的前4提供者
P2P文件共享
应用例子：
P2P文件共享需要解决的有两个问题：
- 如何定位所需资源（目录服务的问题）
- 如何处理对等方的加入与离开（节点的管理问题）
已知的解决方案：
- 集中
- 分散
- 半分散
P2P：集中式目录
最初的“Napster”设计
- \1) 当对等方连接时，它告知 中心服务器：
- IP地址
- 内容
- \2) Alice查询 “双截棍.MP3”(资源)
- \3) Alice从Bob处请求文件 （下载or其他）
- Bob响应并处理请求
P2P：集中式目录中存在的问题
- 单点故障（目录服务器挂了怎么办）
- 性能瓶颈 （clent-server问题，很多的clent对应一个serveer）
- 侵犯版权
文件传输是分散的， 而定位内容则是高度 集中的
完全分布式（一个实例 查询洪泛：Gnutella ）
解决的两个问题：
- 如何定位所需资源（目录服务的问题）
- 如何处理对等方的加入与离开（节点的管理问题）
- 全分布式
- 没有中心服务器
- 开放文件共享协议
- 许多Gnutella客户端 实现了Gnutella协议
- 类似HTTP有许多的 浏览器
覆盖网络：图
- 如果X和Y之间有一个 TCP连接，则二者之间 存在一条边
- 所有活动的对等方和边 就是覆盖网络
- 边并不是物理链路
- 给定一个对等方，通常 所连接的节点少于10个
Gnutella: 协议
- 在已有的TCP连接上 发送查询报文
- 对等方转发查询报文
- 以反方向返回查询命 中报文
- 文件传输：HTTP
可扩展性： 限制范围的 洪泛查询
Gnutella：对等方加入
1.对等方X必须首先发现某些已经在覆盖网络中的其他对
等方：使用可用对等方列表
自己维持一张对等方列表（经常开机的对等方的IP）
联系维持列表的Gnutella站点
2.X接着试图与该列表上的对等方建立TCP连接，直到与
某个对等方Y建立连接
3.X向Y发送一个Ping报文，Y转发该Ping报文
4.所有收到Ping报文的对等方以Pong报文响应
IP地址、共享文件的数量及总字节数
5.X收到许多Pong报文，然后它能建立其他TCP连接
Gnutella： 对等方离开
个人理解： 可以通过加TTL
半分散（ 利用不匀称性：KaZaA ）
1.每个对等方要么是一个 组长，要么隶属于一个 组长
2.对等方与其组长之间有 TCP连接
组长对之间有TCP连接
3.组长跟踪其所有的孩子 的内容
4.组长与其他组长联系
5.转发查询到其他组长
获得其他组长的数据拷贝
KaZaA：查询
1.每个文件有一个散列标识码和一个描述符
2.客户端向其组长发送关键字查询
3.组长用匹配进行响应：
4.对每个匹配：元数据、散列标识码和IP地址
5.如果组长将查询转发给其他组长，其他组长也以匹配进行响应
6.客户端选择要下载的文件
7.向拥有文件的对等方发送一个带散列标识码的 HTTP请求
Kazaa小技巧
1.请求排队
- 限制并行上载的数量
- 确保每个被传输的文件从上载节点接收一定量的带宽
1.激励优先权
- 鼓励用户上载文件
- 加强系统的扩展性
1.并行下载
- 从多个对等方下载同一个文件的不同部分
CDN
背景：
随着网络得普及， 视频类业务占据着流量市场得大部分带宽， 人数也是占有量最大得。
如何让用户之间能够同步得播放视频等成为了互联网得最大挑战之一。
单个超级服务器无法提供服务。
解决方案： 分布式应用层可解决， 应用层面的基础设施。
多媒体视频
视频：固定速度显示的图像序列。
网络视频特点：
- 高码率：>10x于音频,高的网络带 宽需求
- 可以被压缩
- 90%以上的网络流量是视频
** 数字化图像：像素的阵列 （ **每个像素被若干bits表示 ）
编码：使用图像内和图像间的 冗余来降低编码的比特数
- 空间冗余(图像内)
- 时间冗余(相邻的图像间)
- **CBR: (constant bit rate): 以固定速率编码 **
- VBR: (variable bit rate): 视频编码速率随 时间的变化而变化
- 例子:
MPEG 1 (CD-ROM) 1.5 Mbps
MPEG2 (DVD) 3-6 Mbps
MPEG4 (often used in Internet, < 1 Mbps)
存储视频得流化服务（Streaming）
多媒体流化服务 ： DASH
DASH: Dynamic, Adaptive Streaming over HTTP
用户在播放视频时边下载边播放， 减少因为网络原因得卡顿。
相当于我们看虎牙直播 ，如果当前得网络不支持4k， 那么就会切换成1080p
**服务器: **
- 将视频文件分割成多个块
- 每个块独立存储，编码于不同码率（8-10种[1080p、4k等等 ] ）
- 告示文件（manifest file）: 提供不同块的URL
**客户端: **
- 先获取告示文件
- 周期性地测量服务器到客户端的带宽
- 查询告示文件,在一个时刻请求一个块，HTTP头部指定字 节范围
如果带宽足够，选择最大码率的视频块
会话中的不同时刻，可以切换请求不同的编码块 (取 决于当时的可用带宽)
“智能”客户端: 客户端自适应决定（动态自适应）
- 什么时候去请求块 (不至于缓存挨饿，或者溢出)
- 请求什么编码速率的视频块 (当带宽够用时，请求高质 量的视频块)
- 哪里去请求块 (可以向离自己近的服务器发送URL，或 者向高可用带宽的服务器请求)
Content Distribution Networks （CDN）
CDN： 内容分发网络
大家都是从一个或者说微缩非常少的服务器上去流化服务的化会带来什么问题？ （也就是高并发情况）
**挑战: **服务器如何通过网络向上百万用户同时 流化视频内容 (上百万视频内容)?
以下的几种方法…
使用单个， 超大的超级服务中心 “megaserver”出现的问题
通过服务器自身的提升来提高效率
- 服务器到客户端路径上跳数较多，瓶颈链路的带宽 小导致停顿
- “二八规律”决定了网络同时充斥着同一个视频的 多个拷贝，效率低（付费高、带宽浪费、效果差）
- 单点故障点，性能瓶颈
- 周边网络的拥塞
** 相当简单，但是这个方法不可扩展 **
通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验
CDN： 内容分发网络
CDN的运营商将节点部署按照一定的部署策略 将节点部署到世界各地， 然后如果某个商户（假设抖音）， 上传视频给用户去看， 视频就会上传的很多节点上， 然后不同地方的用户设备通过就近原则找到自己附件的节点 ，然后将视频拉去到本地。然后给用户看。
enter deep: 将CDN服务器深入到许多接入网
- 更接近用户，数量多，离用户近，管理困难
- Akamai, 1700个位置
**bring home: 部署在少数(10个左右)关键位置，如将服务器簇安装于POP附近（离若干1stISP POP较近） **
- 采用租用线路将服务器簇连接起来
- Limelight
**用户如何知道访问的内容是从哪里访问的呢？ **
- 告示文件（manifest file）: 提供不同块的URL
- 通过域名解析的重定向
**CDN: 在CDN节点中存储内容的多个拷贝 **
• e.g. Netflix stores copies of MadMen
** 用户从CDN中请求内容 **
- 重定向到最近的拷贝，请求内容
- 如果网络路径拥塞，可能选择不同的拷贝
CDN网络的特点就是： 采用主机-主机之间的服务来加速内容访问。
OTT 挑战: 在拥塞的互联网上复制内容
- 从哪个CDN节点中获取内容？
- 用户在网络拥塞时的行为？
- 在哪些CDN节点中存储什么内容？
场景：
** Bob(客户端)请求视频http://netcinema.com/6Y7B23V **
**视频存储在CDN，位于http://KingCDN.com/NetC6y&B23V **
最早的网络视频点播服务（网飞）Netflix
将自己制作的内容发给很多的CDN运营商， 通过这些运营商来传播自己的内容。
TCP套接字（Socket）编程
UDP套接字编程
