企业官网建设流程全解析

先抛个问题：十几年前想在网页上看直播，打开的是一个插件页面，没有 HLS，没有 WebRTC，只有那个灰底白字的 Flash 播放器。那时候直播不卡，靠的是一套叫 NetStream 的 API，在 ActionScript 里负责把远端的音视频流拉回来，或者把手边的画面推上去。很多从那个年代走过来的流媒体开发者，提起 RTMP 和 NetStream，都会把它当成理解“流传输”的入门必修课。这篇文章我把 NetStream 的前因后果、工作原理、实战参数和踩坑记录都摊开讲一遍，适合刚入行的流媒体开发、产品经理，以及想搞懂“浏览器直播底层到底发生了什么”的人。我会按实际项目里的经验来写，不堆概念，只讲能落地的内容。

1. NetStream 到底是个啥

1.1 先回到 Flash Player 的时代

NetStream 不是一个网络协议，也不是一台服务器，它是 Adobe Flash Player 和 Flex/ActionScript 里提供的一套客户端流媒体 API。它解决的问题很具体：浏览器不是电影播放器，你要怎么把一个正在录制或者正在编码的视频流，实时地拉到用户屏幕上？

那时候浏览器也支持 video 标签，但 HTML5 的视频解码能力和直播能力非常有限。MP4 点播能播，但“推流-拉流-低延迟”这条路，几乎没有替代方案。微软的 Silverlight 有小众的方案，RealPlayer 也在，但网页直播的第一选择基本就是 Flash。于是 NetStream 成了事实标准。当时的直播网站、视频聊天室、摄像头监控后台，播放器核心十有八九是同一个套路：创建一个 NetConnection，连上一个 RTMP 地址，然后把 NetStream 挂上去，再调用 play 或 publish。

很多人一听 NetStream 就以为是 Flash 专属，觉得跟今天的流媒体没有关系。但实际上，现在很多直播系统的服务端还是保留着 RTMP 入口，只是播放端从 Flash 换成了 HTML5 或原生 App。你打开 OBS 推流到云直播服务时，大多数推流地址填写的那串 rtmp:// 协议，仍然需要接收端有一套类似 NetStream 的逻辑来承接。所以理解 NetStream，并不只是为了考古，而是为了看懂直播链路里那些至今还在用的底层思路。

1.2 NetConnection、NetStream、Camera/Microphone 的分工

第一次写 NetStream 的时候，很容易把三个概念搞混：NetConnection、NetStream、Camera/Microphone。用电话类比就清楚了：

NetConnection 是“线路”，负责建立和维护客户端与流媒体服务器之间的连接。它以 rtmp:// 开头，好比你拨号给服务器。没有线路，一切免谈。NetStream 是“线路上的数据流”，一个连接上可以挂多个流，播放端用 play，推流端用 publish；同一份画面可以被多人各自独立播放。Camera 和 Microphone 是“信号源”，采集摄像头和麦克风，再交给推流的 NetStream，attachCamera 和 attachMicrophone 就是把它们绑上去。

这三个角色搞清楚了，代码里就不会犯一些低级错误。比如有人 new 了 NetConnection 却一直不触发 Success，那可能是连接地址不对，也可能是服务端没开对应端口。而有人永远卡在“连上了却没画面”，那就要去看 NetStream 这个环节，是否真的拿到了流名，是否设置了 client 回调，是否缓冲一直没填满。排查的时候，先看连接，再看流，再查采集，基本上能定位大多数问题。

2. 核心原理：NetStream 是怎么把画面送出去的

2.1 为什么 RTMP 能做到低延迟

要理解 NetStream，必须捎带理解它背后最常见的传输协议 RTMP。RTMP 是 Adobe 为流媒体设计的实时消息协议，默认走 TCP 1935 端口。相比 HTTP 的一次请求一次响应，RTMP 在握手成功后建立一条长连接，客户端和服务器可以在这条连接上双向、持续地交换数据。这条长连接最大的价值不只是省掉几次握手，而是让服务器可以随时把新增的音视频数据推给播放器，不需要播放器反复发 HTTP 请求来轮询。

RTMP 的另一个关键设计是消息分块，也就是 chunk。音视频数据被切成小块，在一条 TCP 连接上交错传输，音频、视频、命令消息互相穿插，接收端再按 chunk stream id 重新拼装。这是一个非常贴合实时场景的设计：视频帧再大，也能被切成小块，不至于让音频消息一直排队等着发送。正是“长连接 + 小块交错传输 + AMF 命令即时交互”这三个特性组合在一起，才让 RTMP 能把直播延迟做到 0.5 到 3 秒。在 2008 年左右的网页直播里，这几乎是唯一真正可用的低延迟方案。

顺带说一句，TCP 本身是有拥塞控制和重传机制的，网络抖动剧烈时延迟依然会上升。NetStream 不是在传输层上做过什么神奇的事情，它更多是在传输之上建立了一套“怎么描述一条流、怎么控制一条流、怎么感知一条流”的客户端模型。这也是为什么后来 Flash 没了，这套模型的很多思想还是留了下来。

2.2 缓冲、状态机与播放策略

NetStream 播放画面时并不是数据一到就立即显示。它内部有一个播放缓冲，客户端会先把头几个片段收进来，再开始播放。所以千万别以为“连接成功”就等于“画面出现”，两者之间隔着一个缓冲期。

有两个参数必须分清楚：bufferTime 是你给播放器预设的缓冲目标，单位是秒；bufferLength 是当前实际缓冲的时长，单位也是秒。NetStream 会尽力让 bufferLength 逼近 bufferTime。当 bufferLength 掉到很低，长时间收不到新的可解码数据，就会触发 NetStream.Buffer.Empty。缓冲补足重新开始播放时，会触发 NetStream.Unpause.Notify 之类的事件。

bufferTime 怎么调，取决于业务场景。网络抖动大的环境，比如跨运营商直播、无线网络为主的场景，bufferTime 建议设到 2 到 3 秒。强实时场景，比如连麦、互动答题，bufferTime 可以压到 0.5 到 1 秒。但要注意，这个参数不能无限缩小，设得太小，网络一抖动就触发 Buffer.Empty，画面就会一直卡。这里面的本质是抖动容忍度和端到端延迟的权衡，没有绝对正确的值，只有适合你业务的区间。

2.3 音视频数据混流如何区分

一条 NetStream 上既有视频又有音频，还可能夹带 onMetaData、onPlayStatus 等数据消息。RTMP 内部通过消息类型 ID 区分：音频消息、视频消息和数据消息各有各的 message type，然后在同一条连接上交错传输。播放器收到后拆包，视频交给 Video 对象解码显示，音频交给 Sound 系统播放，数据消息则触发回调方法。

在 AS3 里，接收数据消息通常要给 NetStream 设置一个 client 对象，然后实现 onMetaData、onPlayStatus 等方法。这一点很多新手都会忽略。如果不设置 client，就会出现“什么都能播，就是拿不到视频时长、分辨率、关键帧位置这些信息”的怪问题。我当时做点播列表的时候，需要读取 onMetaData 里的 duration 来显示视频总时长，结果一直拿不到值，后来才发现是少了 ns.client = this 这一步。

3. 动手实战：用 NetStream 做一个播放器和推流端

3.1 播放端：从 connect 到 play

纸上谈兵不如直接写代码。下面是 AS3 里一个最基础的播放器流程：创建 NetConnection，监听状态事件，连接成功后创建 NetStream，设置缓冲和 client，最后播放一条流。

import flash.net.NetConnection; import flash.net.NetStream; import flash.events.NetStatusEvent; import flash.media.Video; var nc:NetConnection = new NetConnection(); nc.addEventListener(NetStatusEvent.NET_STATUS, onNetStatus); nc.connect("rtmp://192.168.1.10/live"); function onNetStatus(e:NetStatusEvent):void { if (e.info.code == "NetConnection.Connect.Success") { var ns:NetStream = new NetStream(nc); ns.client = this; ns.bufferTime = 1.5; video.attachNetStream(ns); ns.play("stream1"); } }

这里的 video 是一个放在显示列表里的 Video 对象，这一步不能漏。很多人看到 NetStream 连接成功，也调用了 play，但播放器没有画面，排查了半天才发现 Video 对象没有添加到舞台上，或者没有执行 attachNetStream。Video 和 NetStream 之间是绑定关系，你可以在一个 Video 上切换不同的 NetStream，也可以换用不同的 Video 展示同一条流。这个灵活性在后来写画中画、多路预览时非常有用。

接收 onMetaData 也很简单，定义同名方法即可：

function onMetaData(info:Object):void { trace("分辨率: " + info.width + "x" + info.height); }

注意命名，Flash 运行时是按方法名去回调的。如果写成 onMetadata、onMetaDataInfo 这种名字，它是不会正常触发的，也不会报错，你只会觉得莫名其妙。

3.2 推流端：publish 完成一次直播发布

播放端只是网络直播的一半，另一半是推流。把摄像头和麦克风采集到的数据推给服务器，用 NetStream 写起来也很直接：

var cam:Camera = Camera.getCamera(); var mic:Microphone = Microphone.getMicrophone(); if (cam == null) { trace("没有检测到摄像头"); return; } var ns:NetStream = new NetStream(nc); ns.attachCamera(cam); ns.attachMicrophone(mic); ns.publish("stream1", "live");

publish 的第二个参数有三种常见值：live 表示直播不落盘；record 表示边推边录，服务器会把流录制到文件中；append 表示在已有录制文件上追加。对直播业务，绝大多数都使用 live。录像回放业务才会用 record 或 append。有一次我们在测试环境里推流后一直看服务器没有录像，排查半天才发现写的是 live，改成 record 后文件就正常生成了。这个参数看起来简单，但放错位置会让业务行为完全不一样。

另外，attachCamera 之前最好先调用 Camera.getCamera() 返回对象并做非空判断。在真实浏览器环境里，如果用户没有插摄像头，或者摄像头被其他程序占用，Camera.getCamera() 会返回 null，不处理的话后面 attachCamera 就会直接抛错或静默失败。

3.3 关键事件状态码速查表

NetStream 把几乎所有关键状态变化都通过 NetStatusEvent 回调告诉你，事件里有一个 info.code 字符串。真实的项目里，我遇到过不下十种状态码，下面这几个是最常用的。

建议不要把状态码字符串到处散落在业务代码里，最好定义成常量类统一管理。否则别人维护代码的时候，看到一段魔法字符串还以为写错了。

4. 真实项目里的坑与排查思路

4.1 有画面没声音，或者有声音没画面

这类问题在直播开发里太常遇见了。有画面没声音，最常见的第一个猜测是“播放端静音了”，但多数时候不是。发布端麦克风没有 attach，或者音频编码格式播放端不支持，才是真正原因。那个年代 Flash 最低支持的音频编码一般是 AAC 和 Speex，如果服务器转码后输出其他格式，或者发布端使用了低码率 NellyMoser 编码，播放端可能直接丢弃音频。

排查步骤可以固定下来：先看发布端是否有麦克风权限，Microphone.getMicrophone() 是否返回 null；再用 NetStream 的 info 属性检查有没有音频字节流；最后看服务端日志里音频轨的编码格式。有声音没画面也是一样，先看 Camera 是否被占用，再看视频编码是否是服务端和播放端都支持的格式，比如 H.264 基线或主配置。

4.2 Buffer.Empty 反复触发

直播播放最烦的事情就是播放几秒卡一次。现象上表现为 NetStream.Buffer.Empty 反复出现，画面断断续续。原因通常是三类：第一，客户端网络带宽不足，数据接收速度跟不上播放速度；第二，服务端发送策略有问题，关键帧间隔太大，播放器要等下一个关键帧才能恢复画面；第三，bufferTime 设置太小，网络稍微抖动就直接触发缓冲事件。

针对这个场景，我建议先做一个可量化的调整：把 bufferTime 暂时调到 3 秒，观察 Buffer.Empty 触发频率。如果明显减少，说明是网络抖动或缓冲设置问题。如果依然频繁触发，就要看服务端，关键帧间隔最好控制在 1 到 2 秒。有些开源流媒体服务器默认配置的关键帧间隔很大，播放器在丢帧后要等很久才能找回画面，体感就是一直在缓冲。

4.3 延迟越来越大

直播系统跑一段时间后，延迟从 1 秒慢慢爬到 5 秒甚至更多，这是 NetStream 项目里很典型的问题。原因不难理解：NetStream 在直播场景里不会因为本地缓冲超量而主动丢帧。如果推流端码率和播放端处理速度有一点点差距，bufferLength 会缓慢上涨，延迟也就在不知不觉中变大。

当时我常用的应急手段是开一个定时器，监测 bufferLength 和 bufferTime 的关系，当 bufferLength 比 bufferTime 多出一定阈值时，执行一遍 pause 再马上 resume，利用缓冲重建把多余的数据丢弃，把画面跳回接近实时。

var timer:Timer = new Timer(5000); timer.addEventListener(TimerEvent.TIMER, function():void { if (ns.bufferLength > ns.bufferTime + 2) { ns.pause(); ns.resume(); } }); timer.start();

这个方法不算优雅，也有可能在跳帧瞬间出现轻微画面跳跃，但至少能把延迟控制在一个可接受的范围内。更彻底的做法是在服务端把缓存队列压小，只保留少量缓冲，让播放器拿到的数据始终接近实时。真正要解决延迟问题，必须客户端和服务端一起调，单靠一边很费劲。

4.4 NetStream.info 不是摆设

很多人不知道 NetStream 自带一个 info 属性，用它可以直接看到接收字节数、当前帧率、丢帧情况等关键数据。排查问题的时候，这些参数比猜要靠谱得多。

setInterval(function():void { trace("接收字节:" + ns.info.bytesReceived + " 当前FPS:" + ns.info.currentFPS + " 丢帧:" + ns.info.droppedFrames); }, 5000);

bytesReceived 每隔几秒稳定增长，说明数据链路是通的。currentFPS 长时间低于设定的推流帧率，说明推流端或服务端没有按预期输出。droppedFrames 突然飙升，说明解码端处理不过来，或者网络丢包导致到达的数据不完整。这几个值组合起来看，能判断问题是出在推流端、传输链路还是播放端。我在线上环境里定位过一个问题：播放器画面卡，服务端却说数据正常，最后从播放器的 currentFPS 和 droppedFrames 数值对比中看出是解码性能不足，跟网络无关。

5. NetStream 和现代流媒体技术的关系

5.1 从 RTMP 到 HTTP-FLV、HLS、WebRTC

Flash 退场之后，NetStream 这个 API 慢慢没人写了，但它背后的思路并没有消失。HTTP-FLV 是最直接的后继者：它把 RTMP 里的 FLV tag 封装进 HTTP 响应体里持续下发，播放端用 MediaSource Extensions 边接收边播放。协议从 RTMP 换成了 HTTP，但流的内部结构还是 FLV，缓冲和状态机的思路也和 NetStream 一脉相承。

HLS 则走了另一条路，把连续的视频流切成一个个 TS 或 fmp4 分片，再用 m3u8 索引文件描述分片顺序。它的延迟偏高，但对标准 CDN 非常友好，因为是纯静态文件分发。WebRTC 又把延迟压到了毫秒级，底层用 UDP 和 SRTP 做实时传输，配合 ICE 协商建立连接。虽然技术栈完全不同，但你会看到类似的连接状态管理、缓冲层级和丢帧策略。

5.2 NetStream 留下的流媒体基本功

学 NetStream 最值钱的不是 AS3 语法，而是三个概念：连接与流分离、状态机驱动、缓冲调优。现在你在 WebRTC 里也会看到连接状态变化，在 MSE 里也会看到 SourceBuffer 的 update 状态和 buffer 水位监控。换个壳，内核依然是“什么时候开始播放，什么时候缓冲，什么时候丢帧或跳帧”。

我后来带人做播放器开发，第一堂内部课不是讲播放器框架，而是拿一个用 NetStream 写的老播放器做案例分析。把里面的 connection、stream、buffer、event code 讲透，新人再去看现代播放器的源码，理解速度会快很多。这套基础知识跨协议、跨语言，价值不会随着 Flash 退场而消失。

5.3 现在还要不要学 NetStream

纯做新项目的 Web 播放器，当然不需要再去写 AS3。但如果要维护老直播系统、阅读开源流媒体服务器里的 RTMP 模块、理解 OBS 推流日志和流名规则，NetStream 和 RTMP 的知识仍然有用。它更像一门流媒体老古董课，但胜在逻辑简单直接，反而适合作为入门教材。

如果你刚接触流媒体，我建议不要把时间浪费在纠结“要不要学已经过时的技术”上。把 NetStream 状态机理解清楚，再对比着学 WebRTC 或 MSE，你会发现“流的工作方式”在本质上没怎么变。有了这个底子，后面接触任何新协议都能很快上手。

最后说点私人经验。我后来负责把一套 Flash 直播系统迁移到 HTML5/MSE 时，没有急着替换播放器，而是先让团队把老系统里 NetStream 的状态机、缓冲策略、流名规则整理出来，然后在现代播放器里一一对号入座。这种迁移方式最后比直接重写稳得多，因为业务层面的问题早就被老系统暴露过一遍了。如果你现在才开始接触流媒体，不要觉得 NetStream 过时就跳过它，把它当成理解“流”这门手艺的入门课，是很划算的选择。