很早之前，笔者使用浏览器观看各平台直播时，无意中发现一个奇怪的现象：有时候，某些网站的直播页面在占用下行带宽的同时，还会持续占用大量上传带宽，且上传速率和下载速率相近。我们知道，观看直播时需要不断从服务器获取视频流和弹幕，持续占用下载带宽是正常现象，且下载带宽的占用量往往和画质、帧率等成正比；而作为观看直播的普通用户，网页对上传带宽的占用应该是微乎其微。长时间占用如此多的上行带宽显然有悖于常理。
但这个现象的出现似乎并非必然，而且上传带宽的占用情况也并不总是一成不变，因而没有太过在意。咨询网站客服，得到的解释是：“亲，这是观看直播时的正常现象呢 ~~~///(^v^)~~~”，遂放任不管之...
随着时间推移，这个现象越来越明显，往往前脚刚打开直播房间页面，没过十几秒，上传带宽马上就占用起来，而在上传带宽巨额占用现象发生的十几秒之前，直播观看完全正常，并没有出现画面中断。也就是说，这个上传占用并不是观看直播所必需的。没有这个夸张的上传行为，我们应该依然可以正常观看直播。由此怀疑，这可能是某种P2P行为。
什么是P2P？我们在使用迅雷等软件下载文件的时候，经常会遇到这个词汇。Peer To(2) Peer，顾名思义，是点对点、个人对个人的意思。P2P下载技术，就正是一种用户到用户的下载方式。P2P下载文件之所以往往比普通下载速度快，除开软件本身的性能和VIP等因素影响之外，最重要的是：把普通用户的电脑（终端）当作了其他用户的服务器。
“当作其他用户的服务器”是什么意思？举个例子：
A用户使用支持P2P功能的下载器，从某个加载速度十分缓慢的网站上费了九牛二虎之力下载了一份文件，但下载完成后，该用户并没有关闭下载器，而是将其放在了后台运行。
不久，B用户打开了同款下载器，准备从相同的网站下载相同的文件。正常思路下，下载器应该会从网站的服务器上下载这个文件。但如果A用户和B用户同时开启了P2P文件传输功能，那么这个下载器就可能会把A用户的电脑当作服务器，从A用户电脑上下载这个文件。
于是，B用户很可能会发现：相比于不开启P2P功能的情况下，文件的下载速度飞速提升，往常需要几分钟的下载，现在只需要不到一分钟甚至十几秒就可以完成下载。B用户对此下载器的表现感到十分满意，给出了五星好评。欣喜之余，B用户把这款软件推荐给了自己的N位小伙伴。
在B用户的大力推荐下，其他小伙伴纷纷开始使用这款下载器，在打开了P2P下载功能后，开始陆续下载文件。
紧接着A用户发现，自己的电脑风扇往往无缘无故地狂转，CPU和网络（上传）带宽占用率被频频大量占用，显著影响到了A用户的日常使用体验。经过一番排查，A用户把源头定在了下载器软件本身上，愤怒之余给出了一星差评，并发誓再也不用此款软件。
上述例子就能很大程度上概括出P2P网络传输的特点：用户既可以是受益者，也可以是无偿奉献者。作为下载数据的受益者，用户的下载速度、网络延迟等可以得到很大改善；而作为提供数据、充当服务器的奉献者，用户的计算机CPU、内存、网络等资源也往往会被大量占用。这对于计算机性能本身较差、网络带宽较小的用户来说，无疑会造成显著的负面影响。
而B站直播页面使用的P2P与此思路基本一致：直播网站出于节省自己服务器资源和网络带宽、降低运营成本等考虑，使用这类技术来把直播观众的手机电脑等当成一个个小型服务器，让其他观众连到这些小型服务器上去（而不是直接连到直播网站的服务器上），从而利用观众的硬件和网络资源分担了自己的运营负担。
可以看到，上传带宽的占用非常明显，对于上传普遍限速30Mbps的家庭宽带来说，影响非常显著话已至此，想必各位已经对此类P2P技术有了初步的认知。那么问题自然摆在眼前：既然B站明面否认使用了此类技术，也就代表着用户无法通过常规设置关闭P2P功能。既然如此，如何才能彻底关闭P2P功能呢？
首先笔者想到的是按照网络传输的协议类型进行识别+拦截。打开Wireshark软件进行网络抓包，一段时间后果然发现了异常的流量。网上查询相关信息发现，这些使用名为STUN协议的数据，正是P2P功能占用上传带宽传输的数据。
千里P2P一“站”牵那么使用某种方式，按照协议类型进行拦截是否可取？理论上可行，但这往往需要借助其他第三方软件进行拦截。如果使用的设备不止一台，则需要在每台设备上都安装相应的拦截软件，费时费力，并不讨好。而且这样操作的灵活性较差，如果无脑拦截所有STUN流量，可能还会误伤其他软件的功能。至于能实现这种拦截操作的软件...如果有推荐，欢迎在评论区留言。
转换思路。笔者想到，自己平日以PC端网页版使用较多，应该可以通过分析网页的内容，拦截相应的脚本或破坏相应的代码。但B站的JS脚本绝大多数都经过压缩，并没有办法直接对源代码进行操作。深入研究P2P功能的实现代码发现，B站的P2P功能需要用到某些特定的函数，因而可以通过在Tampermonkey中挂载用户自定义脚本，在网页加载完毕后自动删除相应的函数，从而破坏P2P功能。下图摘自其他网站的论坛，代码内容不再赘述。
听说油猴上也可以搜索得到那么这种方法是否可行？答案自然是肯定的，但缺点也比较显著。用户仍然需要在每台设备上安装Tampermonkey插件，手动添加相应的脚本，工作量较大。而且这种方法只适用于网页端，对于App端和不能安装油猴插件的浏览器则无能为力。
分析到这里，难道就没有更好的思路的吗？答案当然也是否定的。我们调转方向，转而研究STUN协议本身的实现方式。通过网上资料的查询得知，该协议的实现往往需要一台“中介”服务器：两台客户端要想成功建立P2P连接，常常需要各自向服务器建立连接、提供自己的网络和设备信息，然后再由服务器进行“拉线搭桥”，让双方彼此连接配对。如果能阻止客户端联系“中介”服务器，不就可以从根源上阻止P2P功能了嘛！再次打开Wireshark进行抓包，对相关数据进行仔细分析后，成功找到了相应的数据包：
用于联系中介服务器的DNS查询请求按理说成功找到了目标，自然应该是皆大欢喜。但喜悦之余不免发现，中介服务器的域名不止一个，而且往往含有不同的字母拼写和数字编号，将其一一加入hosts黑名单或者Adblock屏蔽列表显然会成为一项艰巨的工作，而且随时间推移，这些域名可能还会继续增加，从而产生更多的“漏网之鱼”。
短短几分钟，就抓到如图所示这么多的域名。打个小码，算是留点面子吧机智的观众此时也许会立即抢答：上图中的域名都有相同的部分（.chat.bilibili.com），直接用正则匹配过滤掉不就可以了吗？对，但并不完全对。不管怎么说，先试一试。以网页端为例，打开Adblock-选项-高级，在“我的过滤列表”中添加相应的过滤规则。
如图如果此时兴冲冲地刷新直播房间的网页，你会欣喜地看到：任务管理器里的网络占用已经回到正常水平。
上传和CPU占用都降下来了！✌于是你认为，问题已经得到了圆满的解决。但持续观看直播一段时间后，你会同样成功地发现：弹幕不见了！打开F12开发人员工具，看到大量红色报错。仔细观察筛选，发现用于获取弹幕信息的WSS连接出现了问题，而WSS的连接域名与P2P中介服务器的域名恰好相同。
WSS连接报错再仔细观察，发现弹幕的请求URL地址稍有不同，域名后多了一个:2245/sub目录。借此想到，如果可以在Adblock中添加一条更为详细的白名单规则，就可以放行弹幕流量。查询官方文档后，添加了如下一条规则，成为下图所示。
两条匹配规则再次打开直播页面测试，发现控制台不再有弹幕报错，弹幕恢复正常，同时P2P流量消失，至此任务达成。按照此思路，若能将相应的屏蔽规则直接写进路由器的拦截列表中，从而达到一次配置、全网通用的简并目的，岂不美哉！
作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～
