第二章 第4节

第二章第四节：

接下来我们看P2P应用：Peer-to-peer (P2P) 架构，没有（或极少）一直运行的服务器 ，任意端系统都可以直接通信 ，Peers请求其他peers节点的服务，为其他peers节点提供服务

特点：自扩展-新节点带来新的服务请求，以及新的能力,Peer节点间歇上网，每次IP地址都 有可能变化,管理复杂(后续会说NAT的原因)

一般用在两用户彼此建立的基础上，类似于钉钉会议这类的，kankan流媒体。

在P2P模式中，每个用户端不仅下载数据，同时也会利用自己的上行带宽向其他peer上传数据，也就是说，服务器不用再肚子承担所有上载负担，这是和CS模式的区别，所有参与者的带宽都被调动起来，形成了人人为我我为人人的协作模式。

来看一个例子：对于大小为F的文件，一台服务器分发到N个节点需要耗时多少（节点的上下载能力是受限的资源）

CS模式下，流量全部由服务器的带宽承担，所用的最短时间取决于两个因素。第一个就是服务器上载N份文件的完整时间NF/us，服务器最起码要有一份文件，第二个因素是最慢客户端下载完整文件的时间，F/dmin，最后一个客户端完成下载，才说明所有客户端全部下载完成。所以说传统CS模式下，服务器需要独立上传N份文件，他需要自己的带宽支付全部成本，那我们看看P2P是怎么解决的

首先P2P模式下，服务器只上传很少的份数比如几份，大部分上传工作由已经拿到数据的客户端完成，也就是每个客户端贡献自己的上行带宽，这些流量被服务器用来服务其他客户端，所以服务器全部带宽成本由所有参与者分摊，正因如此P2P具有高可扩展性，能大规模分发

所以影响他的最短时间只有三个因素，一个是服务器最少要上传一个文件副本，所以是F/us的时间，另一个是最慢的一个客户端的下载时间F/dmin，然后就是系统总上载能力分摊总下载量所需时间，NF/us+所有的ui，即所有peer的上载和服务器的上载带宽传递N个文件。

所以随着peer节点增多，每个peer也带来了服务能力，所以CS模式随着用户增多，他的时间会线性变化也就是耗时会更久，而P2P不会这样。

然后看P2P工作的具体流程：（比特洪流客户端Bittorrent）

首先认识几个概念：

文件：（人话就是要传递的书）

文件块：将大文件切分成的小块，便于并行下载和传递。（书里面的纸）

Torrent:参与同一个文件分发的所有peer节点组（就是建个群的意思）

Tracker：跟踪服务器，记录当前有哪些peer在torrent中，帮助新节点找到伙伴（群管理）

Peer节点：同时下载和上载的客户端（群成员）

然后我引入其中一个交互流程，再展示一些特殊的策略：

比如说Fly要加入torrent，第一步他一开始没有任何块，所以他要加群，所以得找群管理，需要联系这个Tracker，第二步这个管理向跟踪服务器注册获取活跃的peer，第三步fly和周围一些随机选择的peer建立TCP连接，成为邻居关系，第四步：询问对方拥有哪些块，周期温邻居你有什么块的请求，第五步：把邻居拥有的块列表，按照一个规则策略请求下载

接下来看一些策略：

Rarest First稀缺块优先：思想是优先请求一些出现次数最少的块，目的是为了避免某些块成为稀缺资源最后导致无法完成下载

发送块策略：一报还一报 ，用来激励合作惩罚自私，规则是每个peer只能同时向4给邻居上载，当前时刻选择4个对自己最有用的邻居也就是4个速度最快的邻居，然后其他邻居被阻塞，暂时不给他们上载。但是也不是完全如此，每10秒重新评估，然后替换掉表现差的

发送块的优化疏通策略：每30秒做一次优化疏通，随机选一个被阻塞的邻居，临时给他一个既会上载，哪怕他没给我提供高速率，作用是探索潜在的好伙伴，也许新节点有很高的上载能力，只是还没机会展示，并且防止死锁。下面这个例子就是Alice给了Bob以一个机会，所以Bob为了感谢Alice，Bob的高速率给了Alice成为了她的前4提供者。

然后就是一些差别：Churn扰动：peer节点随时可能上下限，所以torrent成员会动态变化，所以客户端需要定期向tracker报告状态，尝试连接新的peer。还有一些自私行为比如说下载完立马关闭客户端，以及吸血行为，阻塞规避策略，只下载不贡献，这样会被答谢机制不断排除堵塞。

Bittorrent通过文件分块，tracker协调，稀缺块有限请求，tit-for-tat机制，将P2P理论公式落地成可扩展抗扰动激励合作的实用协议。这也是我们为什么流媒体如此发达面对面快传如此迅速的一些原因。

接下来看一下视频流化服务和CDN，核心问题是如何让全球上亿用户流畅看视频，油管，b站，网飞等许多平台这些平台都有很多用户，那具体是怎么实现的。所以说学计网确实会丰富自己的见识，我们还可以知道诸如12306是如何抢票分配的，这样一个宏大的抢票分配网站，局限的不仅仅是dj，dv这样简单的算法，更是一个集百亿级别访问前端刷新，后端数据流动，超复杂算法实现抢票购票的伟大例子，赞美中国科研工作者。

不扯题外话了，我们继续来看吧：

首先看一看挑战，规模性：带宽不够，地理位置对不同地区的用户不友好，有的远有的近，单点故障，服务器一挂谁也看不了了。解决方案是用CDN内容分发网络，再世界各地放很多缓存服务器，用户就近访问，类似于之前提到web缓存的时候就说是拿到的DNS就不是母公司的域名，而是CDN各地的缓存服务器域名。

异构性：用户设备和网络不同，带宽不一样，解决方案:ABR自适应流，同一个视频存多个码率版本，客户端根据网速自动切换。

首先来看CDN如何部署：

第一种部署策略：深入接入就是在很多城市甚至小区放服务器，优点是延迟低，但缺点是服务器数量大难以维护管理，第二种策略：在少数关键位置部署大型集群服务器，优点是便于维护，但是部分用户离得远。

现在的CDN往往是混合模式，核心层大集群，边缘层用小服务器。

之后看视频编码的基础：我们想要解决视频顺畅的问题，首先要知道视频是如何编码的

视频是一帧一帧的图像需要压缩，相邻帧之间（时间冗余）第i+1帧和第i帧大部分相同，则只记录变化的部分，会省很多空间，一帧内部如果很多内容相同则重复（游程编码）

CBR和VBR是两个不同的编码速率

下面有这些问题，server-to-client随着网络拥塞程度而变化，其带宽随时间变化（内 部、接入网络、网络核心、视频服务器） 数据包丢失、拥塞导致的延迟会播放暂停或视频质量下降

如果想要解决流化的核心问题，就需要解决网络抖动和缓存，没有缓存，播放器就会干等，所以我们接下来引入解决方案，DASH动态自适应流和播放缓存来解决这些问题

播放缓存：解决方法：客户端先等几秒，让缓冲区存几秒的视频，然后再开始播放，当网络快的时候缓冲区增加，网络慢的时候缓冲区减少，只要缓冲区不空，播放就不会卡顿。数据一边往我这里异步到达，一边我这里播。

DASH：传统的流媒体需要状态连接，且穿透防火墙困难，DASH把这些分成三个部分，HTTP请求+分片+自适应

服务器端和客户端

服务端的manifest文件里面有每个时间片的所有可用码率的URL

客户端根据带宽动态选择不同的码率来进行下载，然后还会从选择不同的CDN服务器请求，请求离得近的或者负载低的没什么人访问的

好处：播放不卡顿，充分利用带宽，完全基于HTTP易于穿透防火墙（第八章有，先让我缓缓累死我力）和缓存

分片机制就是把每视频切成很多片，每一片根据不同画质编码成多个码率版本，自适应就是根据自身带宽调整这样。

所以综合下来流媒体视频如何实现的：首先需要encoding编码，编码压缩方便传。其次需要DASH自适应，动态调整下载，最后需要playout buffering提前播放缓存解决网卡等丢包问题。

第二章后面还有古法编程在C语言实现socket套接字以及手动部署端口，手动绑定地址，发送数据，接受数据关socket，没啥用，现在AI都能写，而且现在都用IDE或者IDEA之类的已经有类似spring，django这些框架自动给配置，python的request包，已经没啥用了，我们下一章说TCP和UDP协议明白就好，毕竟我们又不是在写操作系统，不过我确实在用rust写操作系统，但也不是我写啊，只是我知道里面的syscall会回内核级再trap到用户级诸如这类的底层原理，代码这方面还是交给ai就好，Deepseekv4都出来了，国产千问大模型也随便做这些，所以，我们看开就好，我跳了，你随意~，今晚连肝下一节笔记。

2026.4.25