目前大多数p2p技术都是基于udp传输，经过stun 协议拿到自身的反射地址和其他peer进行连接。
打洞技术相信读者会在其他文章中学习到，本文不介绍具体的穿透技术，本文主要分享p2p在cdn
方向的用途。
p2p 在视频点播方向关键技术和难点？
- 如何和同一视频的其它用户（peer) 共享数据
- 如何选择peer进行共享数据
- peer 如何保证低延时和流畅
- 如何提高p2p比例
- 如何切片
以上几个问题相信如果涉及到p2p技术肯定会遇到的问题，结合自己当年在某某云做p2p项目的经验和大家讨论一下。
首先，如何和同一视频的用户共享数据？传统的p2p 基于DHT的确很好，但是收集peer的时间太长
会导致p2p比例的下降，我们采取了集中式tracker方案，也就是假设tracker服务，聚合在同一房间的peer，每个peer会定期上报自己可分享的数据的bitmap，以及运行商以及子节点数等信息。服务端会根据每个peer的当前状况选择最优的10个节点返回给其他用户。这样的话大大的提高了穿透率和缩短了建立连接时长。
第二个问题，如何选择peer进行共享数据？ 由于tracker 服务已经帮我们过滤了一边最适合的peer，我们拿到peer 列表之后直接进行握手，如果握手成功我们会不断发送心跳表来探测和每个peer的rtt值，结合对端peer的可分享数据以及子节点的数量 发送认购消息，如果收到接收到认购同意消息则开始接收数据，并启动定时器，超时则替换peer，此处细节问题比较多，比如说peer的带宽评估和延时，peer的淘汰策略,网络优化，丢包重传等
第三个问题，如何保证低延时和流畅？这个问题设计到智能调度，如何保证一个视频peer能分享的内容全覆盖和具有足够多的peer很考验系统设计，我们当时设计了2级缓存，一部分内容放在用户的内存中，另一部分内容通过内存映射存在磁盘上，这样尽可能的多分享数据又不占用用户过多的内存。关闭低延时部分，我们的优化方案是预加载和放弃p2p，在视频启动10s后再启动p2p，作为p2p的准备时间。我们同时会选择性p2p，比如多缓存一些文件尾数据，而不仅仅是顺序p2p。
第四个问题，如何提高p2p比例？也就是说如何避免用户访问cdn，尽可能的使用p2p？这里有几种提高p2p比例的方法，一种是提高穿透率，让尽可能的用户都能够p2p，但是网络状况太复杂我们直接放弃了对称型NAT,第二种方案是预加载技术和落盘，不做详细介绍。
最后，关于如何切片，我们当时支持p2p的文件类型主要是mp4和m3u8 ,对于mp4 文件我们会首先会向cdn 发起range请求，cdn基本都支持，然后解析出来文件头，然后根据samples 进行切片，遗漏一个关键部件就是我们会在sdk内部搭建一个http代理服务器，用户的cdn请求最终会变成我们的代理地址，代理服务器的设计也非常考验人，基本上要做的很完善才能应对各种变态播放器。对于m3u8 文件的处理我们会重新生成一个代理的文件，我们会把原始的m3u8 文件合并成一个比较大的逻辑文件在按秒数进行切片，如果是多码率的m3u8可能会涉及的问题更多，我们当时也没有考虑。
项目最终成果：
该项目最终对接了华数TV和南瓜电影，当时大概整体p2p比率为35%，也算本人的p2p项目生涯到此结束。
原文链接：https://blog.csdn.net/weixin_43929943/article/details/119183833?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165934461816781818779766%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165934461816781818779766&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-9-119183833-null-null.nonecase&utm_term=%E6%90%AD%E5%BB%BAcdn
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/7733
