企业官网建设流程全解析

1. 从“哪个更优”到“哪个更适合”：实时视频流选型的真实逻辑

近几年只要聊到直播、连麦、低延迟传输，HLS和WebRTC就一定会被摆在一起比较。我经常在看到类似“HLS与WebRTC，哪种技术能带来最佳的实时视频流体验？”的问题时，第一反应不是直接给答案，而是反问一句：你说的“实时”，到底有多实时？这里的“体验”，指的是秒开速度、画面清晰度、弱网稳定性，还是直播画面的绝对同步？“最佳”这两个字背后，对应的是完全不同的技术取舍。

简单说，HLS是基于HTTP的流媒体分发协议，由某公司提出后逐渐普及，目前几乎所有播放器、几乎所有平台都在支持它。它通过把视频切成一个个小片段，借助M3U8索引文件调度播放，兼容性极好，但天然存在数秒至数十秒的延迟。而WebRTC是一套浏览器实时通信标准，核心是P2P或通过SFU服务中转的音视频传输，延迟能做到几百毫秒甚至更低，但搭建复杂度、软硬件成本、弱网优化难度都明显更高。两者目标场景不同：HLS是“尽量让更多人流畅地看完”，WebRTC是“让有限的人在极低延迟下实时互动”。

如果你是在做传统的“一对多”直播，比如在线教育大班课、发布会、体育赛事转播，HLS在成本、稳定性和兼容性上几乎没有对手；如果你做的是连麦、视频会议、低延迟直播带货，或者任何需要观众和主播实时互动的场景，那WebRTC几乎是唯一靠谱的选择。

这份博文我会拆开HLS和WebRTC的核心机制、延迟来源、部署经验、常见坑点，并给出一个实际可用的选型判断框架。适合正在做直播系统选型、优化播放体验，或者准备从HLS往更低延迟方案迁移的开发者参考。这中间有不少是我自己踩过坑之后的真实体会，踩坑次数多了，就特别想把这些经验写下来。下面直接进入正题。

2. 先弄清两套方案的底层逻辑差异

2.1 HLS：切片、索引与“自适应”的真正含义

HLS全称HTTP Live Streaming，虽然名字带个Live，但它的设计哲学从来不是“实时”，而是“可靠地分发”。它的工作方式可以通俗理解为：把一整场直播拆成无数个小视频文件，每几秒钟切一个，每个切片都有独立的时长，然后不断生成一个更新中的M3U8播放列表，播放器定期去重新拉取这个列表，接着播放最新出现的切片。

这种“边切边播”的模式有几大先天好处。首先是分发成本低，因为切片本质上就是静态文件，可以直接扔到CDN上，由CDN的边缘节点进行缓存和分发，源站压力极小，观看人数再多也只是CDN带宽的问题。其次是兼容性极佳，因为播放器只需要一个能播MPEG-TS或fMP4的解码器，理论上任何支持HTTP请求的设备都能播，从智能电视、老旧手机到网页播放器，几乎全覆盖。

再说自适应码率（ABR）。HLS的M3U8里可以同时放多条不同码率的流，播放器根据当前网络带宽、缓冲区大小、CPU负载等指标，动态决定拉取哪一条流。这个机制的成熟度非常高，主流的开源播放器（比如某知名Web播放器的底层策略）都做过多轮优化，在稳定性和切换平滑性上经过了大规模验证。但也正因为如此，HLS在“自适应”上投入的注意力远多于在“降低延迟”上的投入，因为后者对于传统点播和普通直播并没有那么迫切。

2.2 WebRTC：浏览器里的实时通信，本质是一场对网络的“妥协”

WebRTC全称Web Real-Time Communication，它的诞生目标很纯粹：在浏览器里实现实时音视频通信，不需要安装任何插件。它的核心思路也跟HLS完全相反，HLS是“把实时流量变成文件流”，WebRTC是“把媒体流当成实时数据传输，在尽可能低的延迟下保持同步”。

技术实现上，WebRTC的音视频传输默认走UDP协议，用SRTP做加密，配合RTCP反馈机制控制传输质量。为什么用UDP而不用TCP？简单说，TCP为了保证数据不丢失，遇到丢包会重传，但重传会导致数据到达时间不可控，一旦网络抖动，就会出现声音画面卡顿甚至越来越卡的情况。实时通信对“延迟的一致性”要求极高，宁可丢一帧画面，也不要让音频等画面而拖延整个时间线。UDP本身不保证可靠交付，但恰好可以在应用层做更灵活的控制：丢弃过期数据、优先传输关键帧、动态调整码率。

为了在公网上建立连接，WebRTC引入了一套相当复杂的NAT穿透机制，包括ICE、STUN和TURN。STUN服务器用来探测设备的公网地址，ICE用来协商出一条最优的传输路径，TURN服务器作为中继兜底——当P2P穿透失败时，所有数据经由TURN转发。这一套流程解决了浏览器在不同网络环境下的连通性问题，但也带来了不容忽视的协议栈复杂度。

2.3 两个方案的延迟差异，根源不在网络而在架构

很多人以为HLS延迟高是因为切片时间太长，只要把切片从6秒切成1秒，延迟不就降下来了吗？这个方向对，但不完全对。延迟高的根本原因是HLS的整个分发链路是“文件化”的：编码器生成切片、写入索引文件、CDN缓存、播放器拉取，每一个环节都存在固有的等待时间。CDN边缘节点的缓存策略、播放器轮询索引的周期、播放器缓冲区积累到一定阈值才播放的策略，共同决定了端到端延迟。

而WebRTC的延迟低，直接原因就是没有文件化过程。整个链路从采集、编码、传输到播放，是一个近乎实时的流水线，数据包到达接收端后解码立即渲染。配合JitterBuffer（抖动缓冲），播放器可以精确控制“延迟多少毫秒才开始播放”，既补偿网络抖动，又把总延迟控制在几百毫秒。这种架构上的差异，决定了你可以对HLS做再多参数调优，也很难把它压到一秒以内；同样，WebRTC的架构在设计之初就是为了几百毫秒之内的实时反馈而生的。

3. 核心技术点逐一拆解：从延迟、带宽到兼容性

3.1 延迟的具体构成：HLS为什么总是慢半拍

以常见HLS直播为例，假设切片时长是4秒，播放列表更新周期大约是4秒一次。编码器输出第一个切片后，需要等切片完整生成才能写入索引；CDN又需要几秒时间去缓存节点、刷新索引；播放器每隔一段时间去轮询一下索引，拿到新切片地址后还要下载并缓冲。即便你把切片切成2秒，端到端延迟通常在10到20秒之间，这还是在网络理想的情况下。

如果采用低延迟HLS（LL-HLS），原理上是把切片进一步细分为更小的“parts”，通过HTTP/2的Server Push或者增量传输，让播放器边下载边渲染，理论上可以把延迟压到2到5秒。但这个方案的落地效果高度依赖播放器和CDN的配合程度，生态支持远不如传统HLS成熟，实际部署时经常遇到部分播放器要回退到传统HLS模式，反而增加了维护成本。

WebRTC的延迟就比较直观了。端到端延迟主要取决于视频编码缓冲、网络传输和接收端的抖动缓冲。在网络正常的局域网环境下，WebRTC端到端延迟可以做到200毫秒以内；公网环境下，如果两端连接质量尚可，多数情况下能控制在500毫秒以内。当然如果网络状况恶劣，比如某段时间公网丢包率超过5%，延迟也会大幅飘升，但整体远优于HLS。

3.2 带宽与流量成本：同样清晰度下，谁更“吃”带宽

这个话题在实际项目中往往被忽视，却是长期运营成本的大头。HLS走HTTP协议的天然优势是利用CDN做分发，流量打到的节点距离用户近，源站带宽压力小，CDN厂商之间的价格竞争也已经把带宽单价压得比较低。对于大规模一对多直播，HLS在成本结构上是WebRTC很难比拟的。

WebRTC在一对一场景下走P2P，相当于端到端直接传输，不占用服务器带宽，这是它最省钱的地方。但一旦进入一对多直播或多人会议，情况就完全变了：需要部署SFU边缘节点，所有上行和下行流量都经过SFU中转，服务器带宽成本直线上升。更关键的是，WebRTC为了实时性，通常不会做太多缓存优化，同一份流在不同观众到达时几乎同时转发，对SFU的瞬时带宽压力和并发处理能力都提出了极高要求。

举个例子，做一个千人在线的WebRTC直播，如果每人观看1Mbps码率，那么SFU需要同时处理大约1Gbps的下行转发流量，这还没有计入信令和TURN中继的开销。HLS走CDN时，同样场景下边缘节点各司其职，源站压力小得多。从成本角度说，规模越大，HLS的优势越明显；规模越小、互动需求越高，WebRTC的P2P优势才能发挥出来。

3.3 编码与质量表现：H.264之外还有多少选择

两套方案在编码选择上的自由度也不同。HLS生态以H.264编码为核心，因为MPEG-TS容器和硬件解码兼容性基本都是围绕H.264打底，往上再扩展H.265/HEVC、AV1等编码时，会遇到兼容性分层问题：H.265在苹果生态较好，但在部分安卓和Web端播放器上可能无法硬解；AV1虽然压缩率突出，但编码器性能和硬解覆盖还是短板。也就是说，HLS想用新编码，往往得做好降级到H.264的准备。

WebRTC在编码层面已经默认支持VP8、VP9，H.264是兼容性考量下的可选编码，AV1的支持也正在逐步落地。VP9和AV1在同等画质下比H.264节省码率，这对实时传输非常重要——同样的带宽下可以传更清晰的画面。不过编码器本身的计算开销也需要考虑，尤其是在低端设备上做VP9/AV1实时编码，CPU占用率会明显偏高，实践中经常需要根据设备性能动态选择编码器和参数。

3.4 弱网下的表现：谁的“求生欲”更强

弱网是个绕不开的话题。真实网络环境永远充满丢包、抖动和带宽波动，两套方案在这方面的策略完全不同。

HLS对弱网的核心策略是“缓冲”。播放器会根据当前网络吞吐量和缓冲区水位调整拉取的码率档位，如果网络变差，它会降低码率，同时尽量维持播放不中断。这种做法带来的体验是：延迟会增加，但画面不轻易卡死，观众看到的是“画质变差但一直在播”的状态。对于大班课、赛事直播这类用户不太在意延迟、更在意连续性的场景，HLS的弱网表现其实很讨巧。

WebRTC对弱网的核心策略是“调速和纠错”。如果检测到丢包，接收端会反馈给发送端，发送端加大编码冗余或者降低帧率、码率，让数据量适应网络带宽。值得注意的是，WebRTC的拥塞控制算法（比如GCC——Google Congestion Control）会在带宽评估基础上动态调节码率，这对“保持流畅”的效果极好，但如果带宽突然骤降，画面会出现明显模糊或帧率骤降。相比HLS的“缓冲等待”，WebRTC更偏向“牺牲质量换取实时性”，取舍方向完全不同。

4. 实操参数细节与应用场景对照：选型表与配置建议

4.1 多维度选型对照表，帮助你少走弯路

下面这张表是我在实际项目中反复使用的一张选型对照表，基本覆盖了决策者最关心的几个维度。你不需要把所有指标背会，只需要按自己的业务场景去看哪几列最影响体验。

4.2 如果你仍选了HLS，这些参数值得仔细调

很多团队评估之后，尤其是在兼容性要求高、播放终端类型复杂的情况下，仍然会选择HLS。那怎么在现有架构内把体验做到最好？我的经验是三个方向。

第一，切片时长别死守4秒或6秒，尽量根据你的业务场景做权衡。切片越短，播放器启动越快，延迟越低，但切片的数量变大，索引文件更新频率变高，对CDN的小文件请求也更频繁。实践中我会先用2秒切片起步，观察源站压力和CDN回源情况，如果运维层面的压力可接受，就维持这个值。

第二，播放器的启动逻辑直接影响首屏体验。你可以通过预加载M3U8索引、提前创建解码Context、使用MediaSource实时追加片段等方式，把首屏耗时压到1秒左右。很多播放器还支持“起播不求稳”，即以较低码率先起播，随后在播放过程中升到更高码率，这对用户感知的秒开体验很有帮助。

第三，自动化码率切换策略要实测。自适应码率切换如果跳变太大，画面一会儿糊一会儿清晰，用户的感知比一直保持较低清晰度还差。建议把码率档位之间的距离控制好，切换策略上尽量“慢升快降”——带宽回升时不要立刻跳高码率，而要在低码率档位多停留一段时间，带宽下降时要果断快速降档，避免长时间卡顿。

4.3 如果选了WebRTC，部署架构上有哪些要点

选WebRTC后，工作量和系统架构复杂度会明显提升。一个基础可用的WebRTC直播架构至少包含这几块：信令服务器、SFU服务或P2P连接协商、前端播放SDK、服务端录制和录制文件的转存。

信令服务器建议用成熟的WebSocket方案，负责交换Offer/Answer（SDP）和ICE候选信息。SFU建议选用开源成熟的方案，比如某广泛部署的SFU引擎，它已经处理好了包括音视频推拉流、房间管理、带宽估计等一系列问题。自己从零写一套SFU的代价极大，绝大多数团队不值得重新造轮子。

需要注意一个经常被忽略的细节：TURN服务器虽然是兜底方案，但在公网部署时千万别省略。实际运营中，即使ICE穿透成功率看似在85%-90%左右，但剩下的10%-15%用户如果没有TURN中继，就会完全无法连接。而这部分用户往往是网络环境更复杂的普通家庭用户或办公楼用户，忽略他们等于直接放弃了一部分真实流量。

4.4 混合方案：HLS为主、WebRTC为辅不是伪需求

其实有不少业务场景并不需要整个系统完全切换技术栈。比如一场大型直播活动，主播端和观看端可以是两套体系：主播用WebRTC推流到服务端，保证推流的低延迟和高可控性；服务器转封装后切成HLS分发给海量观众，借助CDN解决观看端的规模化问题。也就是说，WebRTC负责“进”，HLS负责“出”，两者各司其职。

这种混合方案在B站和一些大型直播平台的实际架构中都能看到影子。它既避开了WebRTC服务于大规模观众时的高昂SFU成本，也弥补了HLS在推流端延迟过高的短板。具体到实施上，需要让媒体服务器同时具备WebRTC接入能力和HLS切片分发能力，典型方案是在同一套媒体网关里并行处理两套协议——这也意味着团队需要同时理解两个协议栈，技术门槛更高，但作为折中方案，性价比很突出。

5. 典型问题排查实录：从拉流失败到画面卡顿

5.1 为什么HLS直播延迟突然从10秒变成30秒

某次在做活动直播时，我遇到一个比较迷惑的现象：测试阶段HLS延迟稳定在10秒出头，但活动当天却一路飙到了30秒以上。排查后发现，问题出在编码器侧设置了GOP（关键帧间隔）和切片参数的不匹配。如果切片切割点没有对齐关键帧，播放器就无法从一个切片头部开始独立解码，只能在拉取切片后等待下一个关键帧才真正起播，延迟自然大幅度增加。

这个检查项建议放到每次直播前的测试清单里：确认切片时长与GOP时长保持整数倍关系，且切片最好从关键帧开始切。举个例子，如果你用2秒切片，GOP应该设置在2秒或4秒，避免出现2.5秒这样的非整倍数。另一个常见原因是CDN节点未及时刷新索引文件导致的部分节点命中旧版本索引内容，排查方法是直接对比不同地区节点的M3U8内容是否一致。

5.2 WebRTC画面频繁卡顿，但延迟并没有变高

某次连麦演示时，观看端画面每隔几秒就明显卡顿，网络连接显示质量良好，延迟也正常。逐个环节排查后，发现是发送端的CPU占用过高，导致编码器来不及实时处理每一帧画面，部分帧被主动丢弃。而WebRTC的丢帧和带宽估计是独立机制，丢帧只是导致画面跳顿，并不会触发拥塞控制。

遇到这类问题时，先看发送端CPU是否有突发负载。尤其是在多开窗口、编码分辨率较大时，X86架构的软件编码开销很容易吃掉性能。建议在推流端对编码分辨率、帧率做动态降级，或者直接换硬件编码能力更充分的设备。另一个容易忽略的原因是浏览器限制后台标签页的定时器执行频率，如果推流页面切到了后台，编码帧率可能被严重压制，必要时需要给推流页面加一些保证可见性的特殊处理。

5.3 HLS播放黑屏但音频正常

音频正常、画面黑的案例在HLS里不算罕见，通常属于解码器兼容性或分辨率变化导致的问题。最常见的是视频编码包含B帧，解码顺序与显示顺序复杂化，某些播放器在关键帧不足时无法及时输出图像，就会黑屏一段时间。另一个场景是切码率后分辨率发生变化，部分播放器没有重建解码Context，导致画面无法输出。

排查方法比较直接：用抓包工具检查M3U8和切片类型，确认视频轨是否存在，再单独拉一个切片用FFmpeg解码验证。如果切片本身没问题，那就基本锁定为播放器端解码逻辑的兼容性问题，可以通过升级播放器或调整播放器初始化参数来解决。

5.4 WebRTC连不上或反复重连，应该如何定位

WebRTC连接失败的原因比HLS复杂得多，因为涉及信令、NAT穿透、ICE候选收集、STUN/TURN服务多个环节。我的排查顺序是按漏斗从上往下来做的：第一，先看信令服务器是否正常交换了Offer/Answer，这一步最容易排查，日志里直接看消息；第二，看ICE候选是否收集成功，如果只有一个host类型的候选，多半是STUN服务没有配置或请求失败；第三，看双方是否有可达的公网候选，如果没有，就检查TURN服务是否配置正确，中继连接是否成功。

如果TURN服务没有正确配置，WebRTC在严格NAT环境下十有八九会失败，这几乎是所有公网WebRTC项目的常见病。另外一个隐蔽坑是WebRTC的ICE候选有有效期限制，如果信令服务器的交换过程耗时过长，等候选列表到达对端时已经过期，连接也会失败，必要时需要缩短信令流转链路的时间。

5.5 追帧和拥塞：两套方案各自的核心矛盾

聊到这儿，忍不住想再展开一个有点抽象的话题：HLS的复制给“追帧”带来了困难，WebRTC的实时性则让“拥塞”成为它需要时刻盯防的问题。HLS播放时，如果观众暂停了一会儿，播放器需要跳帧或者加速播放来赶上实时进度，否则延迟会持续累积，这种“追帧”策略在传统HLS播放器里并不总是做得好，容易造成跳变感。

WebRTC则时刻在跟拥塞控制博弈。接收端的反馈、发送端的码率调整、编码器的帧率控制，牵一发动全身。实测中我发现，WebRTC在弱网下的表现并不完全取决于算法本身，还取决于编码器是否支持实时参数调节，以及发送端是否预留了足够的CPU余量来响应动态调整。如果编码器对码率变化的响应速度过慢，拥塞控制算法再先进，表现也会打折扣。

6. 成本与规模化：选型背后的ROI计算

6.1 HLS的规模化红利：只要能让CDN分担，就值得选

当你评估大规模一对多直播时，HLS的成本优势是压倒性的。CDN本身做了大量多级缓存和就近调度，源站只需要保证切片生成和更新速度，剩余的带宽和并发压力全部由CDN扛住。以一场万人观看的直播为例，假设平均码率2Mbps，理论上源站出口带宽压力几乎为零，费用结构主要是CDN流量费用，单价已经被压缩到很低水平。

运营细节上，还需要注意CDN预热和一些缓存参数。比如提前把直播的M3U8和首个切片推送到边缘节点，可以显著降低开播时观众集中进入造成的回源压力。另外，对M3U8的缓存时间设置也很关键——设置太短会导致边缘节点频繁回源，太长又可能导致部分观众看到过期索引，这中间要靠实际压测来确定合适的值。

6.2 WebRTC的规模化成本：SFU是一笔硬账

一对一的WebRTC通话可以不经过任何服务端，但在直播、会议、连麦场景下，SFU必不可少。每一个上行流进入SFU，需要被复制多份转发给多个订阅者，SFU的出口带宽与“码率×观看人数”基本线性相关。更麻烦的是，WebRTC的直播流量无法像HLS那样依赖CDN静态缓存，所有流量都要实时经过计算节点，成本模型完全不同。

拿实际项目来估算，一个千人在线的WebRTC直播，每人平均下行1Mbps，SFU公网出口带宽就要1Gbps以上，按商业带宽单价计算，单场活动带宽费用就可能达到数万元量级。这也解释了为什么很多平台只在连麦互动等局部场景启用WebRTC，而大规模观看仍然回退到HLS。总而言之，WebRTC的实时性优势是拿成本换来的，业务规模越大，这个成本越需要认真算。

6.3 自建SFU还是采购第三方实时音视频服务

很多团队一开始会倾向于自建SFU，但实际上自建SFU的隐性成本非常高：需要投入运维精力去保障稳定性，需要针对不同地区的网络做节点部署，还得自己搞定弱网优化和版本升级。如果你只是需要WebRTC能力，而团队没有专门的音视频工程师，我更建议先评估成熟的商业或开源云方案，它不需要你投入搭建和运维精力，按量付费即可。

但如果你有较强的音视频底层团队，并且业务对隐私性、定制化程度有较高要求，自建方案才值得考虑。核心权衡点是团队的长期技术积累和预算上限，而不是一时的技术热情。开源SFU方案提供了很好的基础，但你依然要自己搞定部署、监控、安全、编码优化等一整套工程体系。

7. 从“实时”视角看两者的未来演进与折中方案

7.1 HLS的演进：低延迟HLS能走多远

传统HLS的延迟问题确实在通过LL-HLS方案逐步缓解，切片细分和数据流的即时传输让端到端延迟有望稳定在3秒上下。但就目前的生态成熟度来说，LL-HLS的普及程度还远远不够。它依赖播放器和CDN同时支持HTTP/2推送等特性，只要有任何一个环节不支持，就只能回退到传统HLS模式，体验反而不稳定。

我的判断是，如果业务本身是强互动型，就不应该把宝压在LL-HLS的成熟度上，它的落地进度很难预测；如果业务是轻度互动，比如弹幕互动、礼物互动，LL-HLS是值得持续关注的方向。顺带说一句，部分厂商的播放器方案已经逐步兼容LL-HLS的部分特性，但实际效果因网络和终端差异极大，上线前务必在小范围灰度验证。

7.2 WebRTC的演进：从实时通话走进“直播”领域

WebRTC演进的大方向之一，是把实时通话的延迟优势扩展到更大的分发规模。除了SFU本身能力的增强，服务商还在尝试在WebRTC上叠加选择性转发、智能合流等能力，让一对一实时互动扩展到千人以上的直播场景。另一个方向是对AV1编码的支持加深，让同样带宽下可以承载更高清晰度，这对移动端尤其有意义。

但也要泼一盆冷水：WebRTC在兼容性上依然有痛点，基于浏览器的方案在PC上是主流，但在智能电视、盒子、部分老设备上很难落地，这决定了它短期内不可能完全取代HLS。更现实的演进路径，是WebRTC负责超低延迟的“实时区”，HLS负责规模化分发的“分发区”，两者共存，各司其职。

7.3 混合架构还是二选一，业务需求才是最终答案

做选型时不要一上来就问“哪个技术更好”，而应该问“我的业务到底需要多低的延迟，能接受多高的成本”。如果业务是线性直播、用户只在乎画面清晰和稳定，那HLS足以胜任，没必要引入WebRTC增加运维负担；如果业务是强互动型，用户之间需要随时连麦、实时评论并得到即时反馈，那WebRTC是刚性需求。

现实里很多项目的正确做法是混合架构：推流端用WebRTC解决端侧低延迟互动，服务端转码后再通过HLS或者低延迟HLS向大众分发。这种架构既满足了互动场景的低延迟要求，又不至于让大规模观看的成本失控。等到业务逐渐跑起来，到底哪个环节需要加深投入，就有了数据支撑，再根据数据去动态调整分配。

8. 项目最终复盘与实操建议

8.1 不同目标下的技术选型快速决策指南

最后整理一个可以快速拿来做决策的指南。如果你的核心目标是最大兼容性和低成本分发，无条件选HLS；如果核心目标是端到端低延迟互动，选WebRTC；如果你既要大规模分发又要低延迟互动，混合方案是当前最稳妥的选择；如果你已经在这个领域有较深积累，且团队可以承受复杂度，可以考虑用WebRTC做全链路低延迟直播，但务必要做好成本预估和压力测试。

针对延迟这个核心指标的判断，我也给一个比较务实的标准：如果业务能容忍3秒以上的延迟，根本没有必要上WebRTC，HLS加合理配置就足够；如果业务要求延迟在1秒以内，那WebRTC几乎是唯一选项。这里面的本质区别不是“1秒和3秒哪个更流畅”，而是“你的业务规则是否依赖低于1秒的反馈循环”。

8.2 我在实际项目中踩过的坑，希望你能避开

一是低延迟HLS的坑。曾经有一段时间，我为了降低延迟把切片时长调到1秒，结果源站压力陡增，同时部分播放器的兼容性出现问题，体验不升反降。后来老老实实调回到2秒切片才稳定。二是WebRTC的TURN服务器遗漏。最早做自建方案时以为穿透成功率足够，没有部署TURN，后来连续好几个人反映连接失败，才意识到这类用户就是那10%-15%的网络受限场景。三是编码器的GOP和切片时长不匹配问题，这个在前面已经提过，但真的值得反复强调，直播前一定放进预检清单。

8.3 给刚开始接触实时音视频的读者最后几点建议

如果你刚接触实时音视频，我建议你先从HLS入手熟悉整套直播链路，它更简单、更通用，也更容易让你理解编码、CDN、播放器之间的协作关系。在此基础上，再深入WebRTC的协议细节，搞清楚信令、ICE、SFU这些概念是如何在真实系统中落地。直接上手WebRTC而不了解HLS的人，很容易对整个流媒体生态的复杂度产生误判。

我个人在实际操作中的体会是：选技术方案不应该是“选最强的”，而应该是“选最符合业务规律、团队承受得了”的。实时视频流的体验是一个系统工程，延迟、兼容性、成本、弱网韧性四者之间始终在互相拉扯。想清楚业务本质上要什么，比研究任何一份技术对比表都更重要。