视频点播平台用大宽带云服务器？我踩过的坑比你想象的更蠢
先别急着买带宽。说个上周的事。
我在钉钉上被一个做育儿视频网站的客户连续@了八次，消息从晚上9点一直弹到11点半。他说他的平台“一到晚上就卡成幻灯片”，小孩看动画片每30秒缓冲一次，老婆已经骂了三回“你找的什么破技术”。我远程登上去一看，带宽监控曲线平滑得跟心电图似的——120M的带宽用了不到40M。那为什么卡？
后来排查了俩小时，发现是视频文件没做分片，用户拖动进度条的时候，服务器得从头开始传输整个MP4文件。一个500MB的视频，用户想跳到最后30秒看，服务器老老实实从第0字节开始传。这等于你叫了个外卖，骑手非要从饭店步行走到你家，中间还不让抄近道。
写到这儿突然想起来，那个客户叫啥来着？真不记得了，只记得他钉钉头像是一只打哈欠的猫。
坑一：以为带宽够大就能解决一切，其实“协议开销”会吃掉你10%-20%
很多人买云服务器的时候，看着100M、200M的带宽数字就觉得稳了。但实际传输视频的时候，TCP协议本身就有损耗——握手、重传、窗口滑动，这些都在吃带宽。更别说现在大部分视频平台都用HTTPS，TLS握手那几轮往返，在弱网环境下能消耗掉将近15%的有效带宽。
我2019年帮一个做短剧的客户规划带宽，拍着胸脯说100M够撑500人同时看720p（按2Mbps码率算的）。结果上线第一天，350人就崩了。后来抓包才发现，他用的播放器默认开了平滑自适应，每隔几秒就发一次请求探测带宽，相当于每个用户实际占用的控制流量比预期多了30%。
这个坑怎么填？
别按“码率×并发数”简单算带宽，乘个1.2到1.3的系数（协议损耗）
开TCP BBR（大部分云厂商的控制台都能一键开），能明显改善丢包场景下的吞吐量
HLS/DASH分片大小别设太小，4秒一个片的话，请求频率太高；10秒一个片比较合理
当时那个短剧客户没完全听我的，他说“先不改，等出问题再说”。后来真出问题了，凌晨两点打电话让我起来改配置。我改了，但协议损耗的问题只能缓解不能根除——这是TCP的先天结构决定的，除非你换QUIC。
这是视频点播平台最隐蔽的坑。
你买了200M带宽，高高兴兴把几百个视频都放在云服务器的系统盘或者普通数据盘里。前10个人看没问题，第50个人开始拖动进度条，你会看到磁盘的读IOPS直接飙到几百甚至上千。普通云盘的IOPS上限也就两三千，一旦打满，磁盘延迟从几毫秒跳到上百毫秒，读取速度从50MB/s掉到5MB/s。这时候带宽还剩一大半，但视频已经卡成狗了。
我犯过一个特别蠢的错误：有一次帮客户排障，死活想不通为什么带宽只用了30%却卡顿，最后发现是磁盘格式用了NTFS挂载在Linux上（对，当时脑子抽了，为了省事直接从Windows迁移过来的），那个驱动在高并发读的时候性能烂得离谱。换成ext4之后，同样硬件环境下，IOPS翻了3倍。
最低成本：把视频文件放到对象存储（OSS），云服务器只负责生成签名URL重定向。对象存储的读IOPS几乎没有上限，而且你不需要提前买带宽。代价是对象存储的流出流量费，1GB大概0.2-0.5元（不同厂商不一样），流量大的话心疼。
中等成本：云服务器挂载高性能云盘（比如ESSD或SSD类型的），单盘IOPS至少5000起步。别用普通云盘，那个是给网站放静态页面用的。
较高成本：上CDN。CDN边缘节点缓存了视频分片，用户直接从离他最近的节点读，连你云服务器的磁盘都碰不到。但CDN刷流量的时候账单很刺激——我有个客户一个月跑了80TB，收到账单差点把手机扔了。
说到CDN，岔开一句。很多人以为开了CDN就不用管服务器带宽了，错。CDN回源的时候，你服务器的上行带宽如果不够，边缘节点拿不到数据，一样卡。回源带宽建议至少留20M-30M，别开到5M去省钱，省不下来的。
坑三：并发连接数超限，带宽没满但服务器拒绝新用户
这玩意儿很少有人主动提。云服务器除了带宽限制，还有连接数限制。不同厂商的内部限制不一样，有的单IP最多2000个并发连接，有的整个实例最多几万个。视频点播的用户每拖动一次进度条，就可能建立一个新的TCP连接（尤其是没用HTTP/2的情况下）。
去年有个做教育培训视频的客户，后台显示带宽用了不到一半，但用户一直报“连接超时”。我查了系统连接状态，ss -s一看，TCP连接数达到了5万多个。他那台云服务器的内核参数net.ipv4.ip_local_port_range默认只有3万多个端口，端口耗尽了，新连接直接被内核丢掉了。
当时的解决过程挺曲折：
我先让他改内核参数，把端口范围扩大到55000。重启后好了半天，晚上高峰又崩了。
又查，发现是他的播放器代码写得太烂，每10秒轮询一次状态接口，每个用户挂着3个长连接不释放。
建议他让前端改成HTTP/2（多路复用，一个连接搞定所有请求），他们开发说“下个版本再改”。
临时的妥协方案：在服务器上加了连接数限制，单IP最多50个连接，超出就返回503。这个方案不完美，有些用户用迅雷等多线程工具下载视频片段时会触发限制，但至少服务器没彻底崩。
最后那个客户也没完全改HTTP/2，他说“先这样，等下次活动再说”。我不知道他现在怎么样了，大概还在扛着吧。
很多人买大宽带云服务器，只算了“用户下载视频”这一条路的流量。但视频点播平台内部还有一堆看不见的流量在跑：
管理员上传新视频到服务器
服务器把视频推到转码集群（如果是自建转码）
转码后的文件传回存储
备份到另一个可用区
这些东西都走内网。内网带宽虽然不是收费的，但云服务器的内网带宽上限通常和实例规格绑定，低配机器可能只有1Gbps内网。你要是同时跑转码+分发+用户访问，内网先堵死，公网再大也没用。
我自己栽过跟头。2020年给一个做纪录片分享站的团队做方案，图便宜买了台2核4G的云服务器，配了200M公网带宽。结果转码一个10GB的4K视频时，服务器CPU跑满不说，内网带宽也被文件传输占了一半，用户看普通1080p视频开始缓冲。我当时没意识到是内网问题，傻乎乎地又加了100M公网带宽，完全没用。后来升了实例规格（4核8G，内网带宽从1.5G升到3G），问题消失。多花了一倍的钱，还耽误了三天。
建议：
转码这种事情尽量丢给云厂商的媒体处理服务（按分钟计费，不用自己扛）
如果非要自己转码，用单独的机器，别和提供下载的服务器混在一起
买云服务器的时候顺手查一下规格文档里的“网络收发包能力”和“内网带宽上限”，别只看公网带宽。
顺手整理个速查表（省得你翻来翻去）
最后说句实在话。我做了十年运维，见过最冤的一个视频站老板，花8000块买了500M大宽带服务器，结果最后查出来卡顿的原因是他用的是2.4GHz的Wi-Fi路由器，同频干扰严重。带宽再大也救不了烂网络。
所以别光盯着云服务器。先确认下你的用户到底是在什么环境下看视频——这个数据比你买多大带宽重要得多。我当时要是早点问那个育儿视频网站的客户一句“你家是Wi-Fi还是流量”，可能就不用熬到11点半了。
作者：SellBGP 技术Shawn
发布日期：2026-06-08
我在钉钉上被一个做育儿视频网站的客户连续@了八次，消息从晚上9点一直弹到11点半。他说他的平台“一到晚上就卡成幻灯片”，小孩看动画片每30秒缓冲一次，老婆已经骂了三回“你找的什么破技术”。我远程登上去一看，带宽监控曲线平滑得跟心电图似的——120M的带宽用了不到40M。那为什么卡？
后来排查了俩小时，发现是视频文件没做分片，用户拖动进度条的时候，服务器得从头开始传输整个MP4文件。一个500MB的视频，用户想跳到最后30秒看，服务器老老实实从第0字节开始传。这等于你叫了个外卖，骑手非要从饭店步行走到你家，中间还不让抄近道。
写到这儿突然想起来，那个客户叫啥来着？真不记得了，只记得他钉钉头像是一只打哈欠的猫。
坑一：以为带宽够大就能解决一切，其实“协议开销”会吃掉你10%-20%
很多人买云服务器的时候，看着100M、200M的带宽数字就觉得稳了。但实际传输视频的时候，TCP协议本身就有损耗——握手、重传、窗口滑动，这些都在吃带宽。更别说现在大部分视频平台都用HTTPS，TLS握手那几轮往返，在弱网环境下能消耗掉将近15%的有效带宽。
我2019年帮一个做短剧的客户规划带宽，拍着胸脯说100M够撑500人同时看720p（按2Mbps码率算的）。结果上线第一天，350人就崩了。后来抓包才发现，他用的播放器默认开了平滑自适应，每隔几秒就发一次请求探测带宽，相当于每个用户实际占用的控制流量比预期多了30%。
这个坑怎么填？
别按“码率×并发数”简单算带宽，乘个1.2到1.3的系数（协议损耗）
开TCP BBR（大部分云厂商的控制台都能一键开），能明显改善丢包场景下的吞吐量
HLS/DASH分片大小别设太小，4秒一个片的话，请求频率太高；10秒一个片比较合理
当时那个短剧客户没完全听我的，他说“先不改，等出问题再说”。后来真出问题了，凌晨两点打电话让我起来改配置。我改了，但协议损耗的问题只能缓解不能根除——这是TCP的先天结构决定的，除非你换QUIC。
坑二：磁盘IOPS比带宽先死，特别是多人同时拖进度条
这是视频点播平台最隐蔽的坑。
你买了200M带宽，高高兴兴把几百个视频都放在云服务器的系统盘或者普通数据盘里。前10个人看没问题，第50个人开始拖动进度条，你会看到磁盘的读IOPS直接飙到几百甚至上千。普通云盘的IOPS上限也就两三千，一旦打满，磁盘延迟从几毫秒跳到上百毫秒，读取速度从50MB/s掉到5MB/s。这时候带宽还剩一大半，但视频已经卡成狗了。
我犯过一个特别蠢的错误：有一次帮客户排障，死活想不通为什么带宽只用了30%却卡顿，最后发现是磁盘格式用了NTFS挂载在Linux上（对，当时脑子抽了，为了省事直接从Windows迁移过来的），那个驱动在高并发读的时候性能烂得离谱。换成ext4之后，同样硬件环境下，IOPS翻了3倍。
比较务实的几个方案（按代价从低到高）：
最低成本：把视频文件放到对象存储（OSS），云服务器只负责生成签名URL重定向。对象存储的读IOPS几乎没有上限，而且你不需要提前买带宽。代价是对象存储的流出流量费，1GB大概0.2-0.5元（不同厂商不一样），流量大的话心疼。
中等成本：云服务器挂载高性能云盘（比如ESSD或SSD类型的），单盘IOPS至少5000起步。别用普通云盘，那个是给网站放静态页面用的。
较高成本：上CDN。CDN边缘节点缓存了视频分片，用户直接从离他最近的节点读，连你云服务器的磁盘都碰不到。但CDN刷流量的时候账单很刺激——我有个客户一个月跑了80TB，收到账单差点把手机扔了。
说到CDN，岔开一句。很多人以为开了CDN就不用管服务器带宽了，错。CDN回源的时候，你服务器的上行带宽如果不够，边缘节点拿不到数据，一样卡。回源带宽建议至少留20M-30M，别开到5M去省钱，省不下来的。
坑三：并发连接数超限，带宽没满但服务器拒绝新用户
这玩意儿很少有人主动提。云服务器除了带宽限制，还有连接数限制。不同厂商的内部限制不一样，有的单IP最多2000个并发连接，有的整个实例最多几万个。视频点播的用户每拖动一次进度条，就可能建立一个新的TCP连接（尤其是没用HTTP/2的情况下）。
去年有个做教育培训视频的客户，后台显示带宽用了不到一半，但用户一直报“连接超时”。我查了系统连接状态，ss -s一看，TCP连接数达到了5万多个。他那台云服务器的内核参数net.ipv4.ip_local_port_range默认只有3万多个端口，端口耗尽了，新连接直接被内核丢掉了。
当时的解决过程挺曲折：
我先让他改内核参数，把端口范围扩大到55000。重启后好了半天，晚上高峰又崩了。
又查，发现是他的播放器代码写得太烂，每10秒轮询一次状态接口，每个用户挂着3个长连接不释放。
建议他让前端改成HTTP/2（多路复用，一个连接搞定所有请求），他们开发说“下个版本再改”。
临时的妥协方案：在服务器上加了连接数限制，单IP最多50个连接，超出就返回503。这个方案不完美，有些用户用迅雷等多线程工具下载视频片段时会触发限制，但至少服务器没彻底崩。
最后那个客户也没完全改HTTP/2，他说“先这样，等下次活动再说”。我不知道他现在怎么样了，大概还在扛着吧。
坑四：转码和分发抢带宽，忘了“内部流量”也占道
很多人买大宽带云服务器，只算了“用户下载视频”这一条路的流量。但视频点播平台内部还有一堆看不见的流量在跑：
管理员上传新视频到服务器
服务器把视频推到转码集群（如果是自建转码）
转码后的文件传回存储
备份到另一个可用区
这些东西都走内网。内网带宽虽然不是收费的，但云服务器的内网带宽上限通常和实例规格绑定，低配机器可能只有1Gbps内网。你要是同时跑转码+分发+用户访问，内网先堵死，公网再大也没用。
我自己栽过跟头。2020年给一个做纪录片分享站的团队做方案，图便宜买了台2核4G的云服务器，配了200M公网带宽。结果转码一个10GB的4K视频时，服务器CPU跑满不说，内网带宽也被文件传输占了一半，用户看普通1080p视频开始缓冲。我当时没意识到是内网问题，傻乎乎地又加了100M公网带宽，完全没用。后来升了实例规格（4核8G，内网带宽从1.5G升到3G），问题消失。多花了一倍的钱，还耽误了三天。
建议：
转码这种事情尽量丢给云厂商的媒体处理服务（按分钟计费，不用自己扛）
如果非要自己转码，用单独的机器，别和提供下载的服务器混在一起
买云服务器的时候顺手查一下规格文档里的“网络收发包能力”和“内网带宽上限”，别只看公网带宽。
顺手整理个速查表（省得你翻来翻去）
最后说句实在话。我做了十年运维，见过最冤的一个视频站老板，花8000块买了500M大宽带服务器，结果最后查出来卡顿的原因是他用的是2.4GHz的Wi-Fi路由器，同频干扰严重。带宽再大也救不了烂网络。
所以别光盯着云服务器。先确认下你的用户到底是在什么环境下看视频——这个数据比你买多大带宽重要得多。我当时要是早点问那个育儿视频网站的客户一句“你家是Wi-Fi还是流量”，可能就不用熬到11点半了。
作者：SellBGP 技术Shawn
发布日期：2026-06-08
上一篇：
没有了