你遇到的这个场景特别典型——单节点扛下全栈服务（前后端、数据库、视频文件全在一台机器），1k并发就出现严重卡顿，但CPU和内存还剩50%以上的空闲，优先怀疑带宽瓶颈是完全合理的判断。下面我结合你的问题拆解两部分内容：带宽瓶颈的排查方法，以及视频下载/流媒体播放时服务器的核心流程，帮你定位问题。

一、先确认是不是带宽瓶颈 #

既然CPU内存都有富余，第一步可以精准验证带宽是否被打满：

• 用iftop或nload这类工具实时监控公网带宽占用：当网站卡顿的时候，看服务器的出口带宽是不是已经跑到了服务商给的上限（比如很多云服务器默认带宽只有10M/50M，1k并发视频流很容易打满）；
• 注意区分带宽上限和实际有效带宽：如果是跨运营商访问（比如用户用电信，服务器是联通），就算带宽没跑满，高延迟和丢包率也会导致视频加载慢，这种情况可以用mtr工具测试到用户端的网络链路质量；
• 算一算理论带宽需求：比如1080p视频的码率大概5-8Mbps，1k并发的话就是5000-8000Mbps（5-8Gbps），普通服务器的公网带宽根本达不到这个量级，这时候卡顿几乎是必然的。

二、视频下载/播放时服务器的核心流程 #

1. 当用户直接下载视频文件时 #

• 用户前端发送HTTP GET请求到服务器，请求对应视频文件的资源路径；
• 如果是Nginx/Apache这类静态文件服务器直接处理，会先校验文件存在性、访问权限，然后打开文件，通过TCP连接分段发送文件内容；
• 这里的关键卡点：如果带宽不足，服务器的发送队列会堆积，所有请求（包括网页静态资源、接口请求）都会被挤在队列里排队，导致简单网页加载耗时超过40秒；
• 如果你是用应用层服务（比如Node.js/Java）处理下载，还要看是否用了阻塞IO，但你CPU空闲的话，这部分瓶颈可能性极低。

2. 当用户在线播放视频（流媒体场景） #

如果用的是HLS/DASH这类主流流媒体协议，流程会更复杂：

• 用户前端先请求索引文件（比如HLS的.m3u8），服务器返回包含不同码率视频分片的索引列表；
• 前端根据当前网络状况选择合适的码率，然后逐个请求10-30秒的视频分片文件；
• 这时候并发请求数会远高于直接下载——1k用户可能同时发起几千个分片请求，就算单个分片带宽不大，累计起来也很容易打满带宽；
• 如果是原生HTTP流式播放（非HLS/DASH），前端会通过Range请求头实现断点续传，边下载边播放，本质和下载流程类似，但会提前预加载后续片段。

三、额外的排查方向（避免漏判） #

除了带宽，还有两个容易被忽略的点：

• 磁盘IO瓶颈：如果视频存在机械硬盘上，1k并发读取会把磁盘IOPS（每秒读写次数）打满，导致文件读取慢，拖慢整个服务。可以用iostat -x 1实时查看磁盘的%util（使用率）和await（平均等待时间），如果await超过100ms，大概率是磁盘IO的问题；
• Web服务器配置问题：比如Nginx的worker_processes是否和CPU核心数匹配、keepalive_timeout设置是否合理、有没有开启合适的连接池，这些配置不合理也会导致并发性能下降；
• 数据库辅助排查：虽然CPU内存空闲，但如果网页加载需要查数据库，可以用show processlist（MySQL）或pg_stat_activity（PostgreSQL）看看有没有慢查询或连接池耗尽的情况，不过这部分瓶颈可能性相对低。

备注：内容来源于stack exchange，提问作者stack