PCDN家庭宽带限速与局停原理、排查及自建节点实践

PCDN 这个词最近两年在家庭宽带圈子里出现频率极高一边是有人靠它把闲置上行变现另一边是有人刚跑起来就遇到限速、甚至直接被局停。围绕限速、局停为哪般的争论社区里每天都能刷到新帖。我前后折腾过几套节点也帮朋友排查过好几次为什么我的速度突然从 20Mbps 掉到 2Mbps把踩过的坑和拆过的原理整理出来。这篇内容会讲清楚 PCDN 的底层逻辑、运营商侧看到的是什么流量特征、限速和局停分别发生在哪个环节、自建节点时的硬件与参数怎么选以及实测下来的监控与排查方法。适合两类人看一类是想搞明白原理再决定要不要上车的技术爱好者另一类是已经在跑、但被限速搞得一头雾水的朋友。全文不会给任何规避检测的偏门办法只讲清楚规则和边界剩下的判断交给你自己。1. PCDN 到底是个什么东西1.1 从中心化 CDN 到分散式边缘一条省钱的逻辑链要说 PCDN得先把 CDN 讲明白。传统 CDN 的做法是在各地建机房、机房把源站的内容提前推到离用户近的边缘节点用户请求时从最近的节点取数据延迟低、源站压力小。这套模式效果很好但它有一块固定成本机房、带宽、电费、运维全是服务方自己掏钱。带宽单价在数据中心算便宜可架不住量大尤其是视频、下载、大文件分发这类业务带宽账单往往是最大的一笔支出。PCDN 的思路很直白既然终端设备有闲置的带宽、存储和算力为什么不把这些零散的资源组织起来当成一张野生边缘网络用用户 A 的设备缓存了某个热门文件用户 B 在附近想看同一个文件那就让 B 直接从 A 那里拉平台只需要在中间做调度和鉴权。这套逻辑在 BitTorrent 时代就被验证过只是那时候没有商业化的调度体系也没有稳定的结算机制。从工程角度看PCDN 的核心难点不在能不能传而在调度得准不准。一个合格的调度系统需要实时知道每个节点的在线状态、上行余量、缓存命中情况、到目标用户的网络距离然后在一堆候选节点里挑出最优的几个。挑错了用户端体验反而比直连源站更差。所以 PCDN 平台的技术壁垒很大一部分在调度算法和节点质量评估上而不在传输协议本身。这也是为什么同样是跑节点不同平台给的收益差别能有好几倍——调度策略直接决定了你的上行被利用的效率。理解了这一点就能明白后面所有的争议从哪来PCDN 要的是大量分散的上行而家庭宽带的上行资源从一开始就不是按这个场景设计的。1.2 家庭宽带怎么就成了边缘节点家庭宽带的技术底座是 PON无源光网络主流是 GPON 和后来的 10G PON。一个 OLT 的 PON 口通过分光器带几十户常见分光比是 1:64部分场景会到 1:128。GPON 单 PON 口的下行速率是 2.5Gbps上行是 1.25Gbps。注意这个上行是整个 PON 口共享的不是每户独享。再叠加一层资费设计绝大多数家庭宽带套餐是下行大、上行小千兆套餐常见配置是 1000Mbps 下行配 30Mbps 或 50Mbps 上行部分地区的上行会给到 100Mbps 甚至更高但比例依然是严重不对称的。这种不对称不是技术做不上去而是资费模型决定的——普通家庭用户的上行需求主要就是发发照片、开开视频会议、偶尔上传个文件峰值高但持续时间短平均占用极低。运营商的网络容量规划就是按平均占用低这个假设来做的。算一笔账就很清楚了。假设一户的上行是 50Mbps如果只是正常使用一天的上行流量可能就几个 GB。但如果这台设备在跑 PCDN上行被长时间占满理论峰值是 50 ÷ 8 × 86400 ≈ 540GB/天一个月就是 16TB 量级。这个数字和普通家庭的月均流量差了接近两个数量级。注意上面是理论满速值实际受调度命中率、对端需求、平台限流影响通常远低于这个数。但即便只跑到三成一个月也是几个 TB 的上行量级差异依然巨大。把视角拉到 PON 口这一层问题就更明显了。假设一个 PON 口带 64 户其中 10 户在跑 PCDN每户上行按 50Mbps 持续跑合计就是 500Mbps占掉 1.25Gbps 上行总容量的 40%。晚高峰本来就是上行压力大的时段这 40% 一占同 PON 口下其他用户的视频通话、网游、直播推流全都会受影响。这就是矛盾的核心PCDN 消耗的不是你自己的上行而是共享介质上的公共容量。1.3 一条上行链路的价值账从商业逻辑上讲PCDN 平台愿意付钱给节点是因为它省下了数据中心带宽的钱。数据中心带宽按 Mbps 月付价格和家庭宽带的单位带宽成本完全不在一个量级。家庭宽带是包月制用多用少一个价于是把包月没用满的上行卖出去这件事看起来就像套利。但套利能成立的前提是交易双方都认可这个资源可以这么用。问题恰恰出在这里。家庭宽带的服务协议通常写的是家庭日常使用把它变成持续满负荷的商业上行出口属于用途偏离。这不是技术问题是合同边界问题。很多争论吵到最后吵不出结果就是因为一方在谈技术可行性另一方在谈使用边界两边根本不在同一个频道上。我个人的判断是这件事的本质不是能不能跑而是跑了之后愿不愿意承担对应后果。技术上完全可行容量上大概率会挤到别人协议上多半不被允许这三个结论同时成立。想清楚这一点后面遇到限速、遇到停机心态会平和很多。2. 限速的真正原因流量模型与上行资源2.1 为什么上行带宽天生就是稀缺资源很多人有个误解觉得我办的是千兆宽带凭什么限我速。这里的千兆指的是下行峰值不是上行也不是随时可用的保证带宽。宽带套餐里的速率数字是接入速率的理论上限不是专享带宽。接入网是统计复用的所有人都按峰值跑网络立刻崩。上行比下行更紧张有三个结构性原因。第一PON 的上行采用时分复用多个 ONU 轮流发送需要严格的调度和测距可用总容量本来就比下行少一半。第二上行方向的设备成本和频谱规划更受限扩容周期长。第三家庭宽带的上行需求长期偏低运营商没有动力提前扩容。这三条叠加导致上行成了整个接入网里最脆弱的一环。所以当一批用户同时开始持续满跑上行时运营商的网管系统会最先在这条链路上看到异常某个 PON 口的上行利用率曲线从日常的 20% 一路爬到 80% 以上并且晚高峰之后也不回落全天候高位横盘。这种曲线和某个用户开了直播完全不一样直播是时段性的PCDN 是 7×24 小时的。曲线形态本身就是最强的信号。2.2 运营商侧看到的几类流量特征从网管和流量分析的角度PCDN 流量有一些比较明显的统计特征。这里说的是公开技术讨论中常见的分析维度不是某家具体系统的实现细节。观察维度普通家庭用户的典型表现PCDN 节点的典型表现上下行比例下行远大于上行比例常在 10:1 以上上行接近甚至超过下行比例倒挂或接近 1:1上行占用时长峰值高、持续时间短日均占用低长时间稳定在高位昼夜差异小并发连接数几十到几百随应用波动常维持数百到数千连接对象分散目的地址分布集中在少数几个大厂 CDN 段高度分散跨多个网段和地区端口与协议特征以 443 为主协议单一端口随机化明显长连接占比高流量时序有明显的人类作息特征平滑、均匀缺少突发性这张表不是为了教人怎么伪装成普通用户而是想说明一件事从统计上看PCDN 流量和家庭日常流量的差异是结构性的不是靠改几个参数就能抹平的。只要上行是持续满跑、连接是海量分散的统计特征就摆在那里。网管系统不需要精确识别出这是哪个平台的 PCDN只需要判断这个账号的流量模型异常就足够触发后续动作了。除了流量特征还有一类信号来自业务侧同一小区、同一 PON 口下多个账号出现高度相似的流量模型或者出现集中的投诉。这类群体性特征往往比单账号特征更容易被注意到。2.3 限速不是一刀切而是分层的很多人以为限速就是被拉进黑名单速度砍到 1Mbps。实际观察下来限速是有层次的而且不同层次的表现完全不同。第一层是端口级拥塞导致的被动降速。这种情况其实不算处罚就是 PON 口上行打满了大家分不到带宽你的实测速率自然掉下来。特征是波动大、晚高峰最差、凌晨能恢复。很多人误以为自己被限速了其实只是撞上了拥塞。第二层是** QoS 策略限速**。运营商在 BRAS 或 OLT 侧对特定账号下发限速模板把上行峰值压到一个较低的值。特征是很稳定——不管你什么时候测上行都卡在同一个数字上比如稳定在 5Mbps 或者 10Mbps纹丝不动。这种稳定恰恰是策略限速的标志因为物理拥塞不会这么整齐。第三层是上行与下行的联动限制。有些策略会把上行压得很低同时下行也做一定限制或者对新建连接数做约束。表现出来的现象是测速下行还行但打开网页、看视频都变卡因为连接建立被拖慢了。判断自己属于哪一层方法很简单连续几天在不同时段测上行看数据是波动还是稳定。波动 拥塞或调度问题稳定在某个整数附近 策略限速。这个判断很重要因为它决定了你该去排查自己侧的问题还是接受现状。3. 局停是怎么发生的从风控到停机3.1 局停这个词到底指什么局停是行业口语完整说法是局方停机指运营商机房侧对账号做的停机处理不是欠费停机也不是用户自己报停。表现出来就是光猫的 PON 灯正常、LOS 灯不红说明物理链路是通的但拨号拨不上或者拨上了没有流量账号状态在系统里被挂起。这个动作通常不是人工一个个点的而是风控系统根据规则批量触发的。触发之后用户侧看到的现象往往是突然断网重启光猫没用打客服电话才被告知账号存在异常使用。恢复流程一般需要本人带证件去营业厅或者通过线上渠道提交说明签署相关承诺后才能复机。整个过程对普通用户来说体验很差所以才会引发那么多情绪。需要说明的是停机是运营商对账号的一种管理手段触发条件各家不同也没有公开的完整规则。市面上流传的触发阈值大多是用户侧的经验归纳可信度参差不齐不能当成标准答案。3.2 触发链路上可能的几个环节从技术链路上推演一个账号从正常走到停机中间大概会经过这么几个环节。流量采集与建模。网管系统持续采集账号级的流量数据包括上下行速率、流量总量、连接数、活跃时段分布。这些数据进入模型后和该账号的历史基线、同套餐用户的群体基线做对比。偏离越大风险分越高。规则引擎判定。模型给出风险分之后规则引擎按策略决定动作。轻度偏离可能只是标记观察中度偏离可能下发限速模板重度偏离或者反复触发才会走到停机。人工复核与工单流转。停机这种影响较大的动作很多情况下会有一个复核环节尤其是首次触发。但复核的颗粒度因地区而异有些地方是批量处理用户感知就是莫名其妙被停。用户申诉与恢复。复机流程通常要求用户说明用途、承诺不再用于非家庭场景。这个环节的体验差异最大也是社区吐槽最集中的地方。提示上面这条链路是根据公开讨论和常见运维逻辑做的合理推演不代表任何具体运营商的实现。不同地区的策略差异可能非常大别把某个人的经验当成通用规律。我想强调的是这条链路上真正起决定作用的是偏离基线这个判断而不是某个精确的流量数字。同样是每月跑 5TB 上行一个历史基线本来就是高流量的账号和一个平时只用几百 GB 的账号风险分完全不同。这就解释了一个常见困惑为什么别人跑同样的量没事我一跑就被停。3.3 限速和局停处理逻辑完全不是一回事很多人把限速和局停混为一谈其实两者的性质、可逆性、应对方式都不一样。对比项限速局停影响范围速率被压制网络仍可用账号挂起无法正常上网触发门槛相对低流量模型异常即可相对高通常需要多次或严重偏离可逆性停止异常流量后多数可自行恢复需要走复机流程不能自行恢复用户感知速度变慢容易误判为网络故障直接断网现象明确恢复周期几小时到几天数天取决于流程排查重点先排除自身设备、线路、拥塞因素直接联系运营商确认账号状态从这个对比能看出来限速更像一个软约束停机是硬处置。实际使用中多数人是先经历限速如果继续跑才可能升级到停机。所以如果你已经被限速了还在硬跑那其实是在往下一个阶段走。顺带说一句判断自己被限速还是线路故障有个很实用的办法看同一时间下行的表现。如果下行正常、只有上行异常且上行数值非常稳定那基本可以确定是策略限速如果上下行一起抖动甚至丢包严重先查光猫、尾纤、分光器别急着下结论。4. 实操自建一套可控的 PCDN 节点4.1 硬件与功耗的成本核算先说硬件。PCDN 节点对算力要求不高但对存储 IO和网络稳定性要求不低。常见的配置是低功耗小主机或旧笔记本配一块 SSD 做缓存盘。CPU 用四核低功耗型号足够内存 8GB 起步缓存盘容量按平台要求来一般 200GB 到 1TB 之间。功耗这笔账必须算清楚很多人只看到收益没算电费。一台小主机待机加负载平均 20W一年耗电 20 ÷ 1000 × 24 × 365 ≈ 175 度按 0.6 元/度算差不多 105 元。如果用的是旧台式机功耗 60W 起步一年电费就 315 元很可能把收益吃掉大半。SSD 的寿命也得提前想。虽然 PCDN 整体是读多写少但缓存回源、文件替换都会产生写入。假设每天写入 30GB一年就是 10.9TB。消费级 SSD 的 TBW 一般在 200 到 600 之间正常用两三年问题不大但那些几十块钱的杂牌盘写入放大一高就容易掉速甚至掉盘。我踩过一次坑用了一块二手拆机盘跑了四个月开始出现写入延迟飙升缓存命中率断崖下跌排查了半天才定位到盘上。网络侧的准备光猫改桥接、路由器拨号、给节点机分配固定内网 IP、关掉节点的 Wi-Fi 省电。如果平台需要公网访问能力还得考虑 NAT 类型。这里只说明一个事实全锥形 NAT 对 P2P 打洞最友好对称型 NAT 下很多连接建不起来效果会差很多。至于怎么确认自己的 NAT 类型用现成的 STUN 工具测一下就知道不需要折腾别的。4.2 系统与运行环境的选择系统我建议用轻量的 Linux 发行版别用带桌面的版本省内存也省心。装好之后做几件事关闭不必要的服务、设置好时区与时间同步、配置日志轮转这点很重要日志写满磁盘是新手最常见的翻车原因、把缓存目录挂到独立分区。下面这个脚本用来做基础监控采集网卡的上下行速率和 TCP 连接数输出到 CSV方便后面画曲线看趋势。放在/opt/mon/netmon.py#!/usr/bin/env python3 import time, csv, os, subprocess IFACE eth0 # 换成你的实际网卡名 INTERVAL 60 # 采样间隔秒 OUT /var/log/netmon.csv def read_bytes(iface): with open(/proc/net/dev) as f: for line in f: if iface : in line: parts line.split(:)[1].split() rx int(parts[0]) # 接收字节 tx int(parts[8]) # 发送字节 return rx, tx return 0, 0 def count_conn(): try: out subprocess.check_output( [ss, -tn, state, established], textTrue) return max(len(out.strip().splitlines()) - 1, 0) except Exception: return -1 if not os.path.exists(OUT): with open(OUT, w, newline) as f: csv.writer(f).writerow([ts, rx_mbps, tx_mbps, conn]) prev_rx, prev_tx read_bytes(IFACE) prev_t time.time() while True: time.sleep(INTERVAL) cur_rx, cur_tx read_bytes(IFACE) cur_t time.time() dt cur_t - prev_t rx_mbps (cur_rx - prev_rx) * 8 / dt / 1e6 tx_mbps (cur_tx - prev_tx) * 8 / dt / 1e6 conn count_conn() with open(OUT, a, newline) as f: csv.writer(f).writerow([ time.strftime(%Y-%m-%d %H:%M:%S), round(rx_mbps, 2), round(tx_mbps, 2), conn ]) prev_rx, prev_tx, prev_t cur_rx, cur_tx, cur_t用 systemd 把它挂成服务开机自启日志按周切割。这套东西跑起来之后你对自家上行的一举一动就有了完整记录。后面不管是排查限速还是跟客服沟通拿数据说话比空口描述有力得多。注意脚本里IFACE一定要改成实际网卡名用ip -br link查一下。改错了不会报错只会一直记 0容易白白监控好几天。4.3 上行实测把感觉慢变成数据慢监控脚本看的是趋势具体到我现在的上行到底是多少还是得靠主动测速。我一般用三个层次交叉验证。第一层speedtest-cli或同类工具简单粗暴但对上行测得不细容易受测速服务器质量影响# 安装后列出附近服务器挑一个同城的 speedtest-cli --list | head -20 # 指定服务器 ID 测试多跑几次取中位数 speedtest-cli --server 12345 --simple第二层iperf3打流这个最可靠能排除测速服务器的干扰。找一台有公网地址的服务器做对端跑反向模式测上行# 服务端对端机器 iperf3 -s -p 5201 # 客户端测上行-R 表示反向服务端发包给客户端改成客户端发 # 想要测本机上行用 -R 让服务端发、本机收测的是下行 # 测上行要用默认方向本机发服务端收 iperf3 -c 对端IP -p 5201 -t 30 -P 4 # 只看结果 iperf3 -c 对端IP -p 5201 -t 30 -P 4 -f m-P 4是开 4 条并行流单流容易被 TCP 窗口和中间设备卡住多流更接近真实带宽。跑 30 秒看最后的 sender 那一行。第三层看运营商侧的数据。有些宽带 APP 会显示账号的实时速率虽然不一定精确但可以和前两层对照。如果三层数据一致地卡在同一个值上那结论就很明确了。我实测下来的经验是测速一定要分时段。早上 8 点、晚上 9 点、凌晨 2 点各测三次如果三个时段的数值差异很大比如晚高峰只有凌晨的三分之一那是拥塞如果三个时段数值几乎一样那是限速。这个判断方法百试不爽比问客服还准。4.4 在内网先做一次限速模拟实验如果你想搞清楚限速到底是什么手感可以在自己的内网做一次实验用tc把上行压到固定值然后体验一下各种应用的表现。这个实验只在局域网内做不影响外部网络。# 在节点机的上行网卡上限制出方向为 5Mbps sudo tc qdisc add dev eth0 root tbf rate 5mbit burst 32kbit latency 400ms # 查看当前规则 tc -s qdisc show dev eth0 # 压测看看实际效果 iperf3 -c 内网对端IP -t 20 -f m # 实验结束删除规则 sudo tc qdisc del dev eth0 root这个实验的价值在于建立直觉5Mbps 的上行意味着什么意味着一个 1GB 的文件上传要花将近 27 分钟意味着同时开两个视频会议就卡意味着网页首屏加载会明显变慢。有了这个体感你再看自己节点被限速后的表现就能判断是策略限速还是别的问题而不是一味地怀疑设备故障。提示tc规则要记得删。忘了删的话以后所有排查都会被这个规则干扰我就干过这种事——限速实验做完忘了清理第二天以为是运营商出手了白白折腾两小时。5. 常见问题与排查实录5.1 一张速查表覆盖大部分现象现象最可能的原因排查动作上行稳定卡在固定值下行正常策略限速停止异常流量观察数天联系运营商确认上行波动大晚高峰最差PON 口拥塞换时段多次测速对比凌晨数据上下行同时抖动、丢包高线路问题尾纤、分光器、光衰查光猫光功率必要时报修速率正常但缓存命中率低调度问题或 NAT 类型受限检查 NAT 类型看平台侧节点评分突然断网重启光猫无效账号状态异常联系运营商查账号状态节点频繁掉线重连设备过热或网卡/驱动问题查温度日志换网线换口SSD 写入延迟飙升盘寿命或写入放大查 SMART 信息看 TBW 剩余电费超出预期功耗估算错误用功耗计实测整机功率5.2 几个印象深刻的排查现场第一个是假限速。有位朋友的节点上行从 30Mbps 掉到 6Mbps稳定得可疑他一口咬定被限速了。我让他先跑了一周的监控脚本结果发现速率曲线是阶梯状的——白天还好晚上 7 点后准时掉下来11 点后又恢复。这不是限速是他家路由器开了智能 QoS把大流量设备自动降级了。关掉 QoS 之后恢复正常。这个案例说明先排除自己家的设备再怀疑外面顺序错了会浪费大量时间。第二个是缓存盘拖垮网络。某次节点跑着跑着整机卡死网络连接全断重启才好。查了半天发现是 SSD 出现坏块IO 阻塞导致系统负载飙高网卡中断处理不过来。换盘之后一切正常。SSD 这种部件平时不显眼出问题的时候表现却很迷惑容易误判成网络故障。建议定期看一眼 SMART 里的Reallocated_Sector_Ct和Percent_Lifetime_Remain。第三个是PON 口邻居效应。有位用户自己跑的量不大但速度一直上不去。后来聊到同一栋楼里有好几户都在跑基本可以确定是同 PON 口上行争抢。这种情况个人无解只能降低预期或者干脆不跑。这也是我前面强调上行是共享介质的现实注脚。第四个是复机之后的遗留问题。有些账号复机后速率模板没恢复成原来的配置导致下行正常、上行长期偏低。这种事不说清楚用户很难自己发现。建议复机后立刻做一次完整测速并留档作为后续沟通的依据。5.3 关于边界的几点个人看法写到这里必须说清楚PCDN 这件事在很多地区、很多套餐下是把家庭宽带用于了超出协议约定的场景。限速和局停不是技术故障是服务方在行使管理权。你可以不认同这个规则但规则是明摆着的跑之前应该知道自己承担什么。我的建议是三条。第一如果你要做边缘分发的正经业务用商业带宽、商务宽带或者专门的服务器托管别拿家庭宽带去顶。家庭宽带的定价模型里本来就没有给商业上行留空间。第二如果你只是想体验一下技术、跑个小规模玩玩那就把上行占用控制在一个不影响他人的水平别长时间满跑也别在晚高峰抢带宽。第三一旦被限速或停机别急着对抗先看数据、再沟通很多问题是能说清楚的。还有一个容易被忽略的点设备安全和数据安全。跑第三方的分发程序意味着你的设备会对外提供数据服务。选择平台时要看它分发的是什么类型的内容缓存目录里会落下什么文件有没有合规的内容审核机制。有些平台缓存的是公开的视频分片有些则不然。这个差别很大值得在入坑前花十分钟确认。最后分享一个我认为最有价值的小习惯给你的节点建一份运行日志。不用多复杂就记三件事——每天的上行总量、每天的平均连接数、每次异常的时间和现象。坚持一个月你会对自己这条线路的脾气了如指掌。哪天上行突然掉下来你翻一眼日志就能判断是限速、拥塞还是设备问题不用再靠猜。这份日志在跟运营商沟通时也很有用数据摆出来对方处理起来也会更认真一些。