为了保证音视频的质量，WebRTC底层做了大量的工作，尤其是网络传输与服务质量，更是其核心技术，本文由北京音视跳动科技有限公司 首席架构师 李超在LiveVideoStack线上分享的演讲整理而成，详细解析了WebRTC底层技术与优化在网络质量、传输实时性与服务质量之间的矛盾以及平衡之道。

作者 | 李超

整理 | LiveVideoStack

非常高兴和大家一同探讨WebRTC传输是如何保证音视频服务质量的。

本次分享我将从四个方面向大家介绍一下WebRTC传输是如何保证音视频服务质量的。第一，实时通信的目标。我们首先需要确定实时通信的目标，才能够知道要将实时通信做成怎样的系统、保证怎样的实时性；第二，WebRTC如何保障数据传输的实时性；第三，进行实时传输时，想要满足实时性，网络与服务质量之间可能存在的矛盾；最后，就是WebRTC如何解决网络与服务质量之间的矛盾。

1. 实时通信的目标

1.1 实时通信的目标是什么？

首先提出两个问题：第一，开会时你是喜欢在办公室里，还是更喜欢在线上开？第二，如果有一场演唱会，你愿意去现场呢？还是愿意在线上听？

1.2 线上与现在不同的原因

相信大家更多都会选择线下，理由是线上线下感觉不一样。其不同点在于：首先是摄像头与人眼看到的效果不一样，例如摄像头采集的角度过小、无法拍到某些角度的画面；其次是采集设备的质量参差不齐，一场会议中大家所使用的设备有的高清、有的模糊；最后，也是最关键的一点就是现场的气氛无法被摄像头采集到，每个人都有自己的气场，当大家聚集在一起时，现场氛围感非常热烈，但隔着屏幕无法感受到。

1.3 实时通信的目标

根据以上几点，我们可以总结出实时通信最终的目标是：尽可能逼近或达到面对面交流的效果。从目前的情况来看，超越面对面交流的效果是几乎不可能的。

2. 几个重要指标

2.1 几个重要指标

那么如何才能达到面对面交流的效果呢，这里涉及到几个重要指标。

最为关键的是实时通信的延迟指标，只有将延迟指标搞清楚，才能知道做实时通信时，达到怎样的延迟才算符合要求的，即接近面对面交流的效果。然后是音视频服务质量指标，延迟指标达到后，再根据这项指标判断音视频服务质量的好坏。

2.2 实时通信延时指标

下面具体看一下延迟指标的分级标准。通过图中表格可以看到，如果端到端延迟在200ms以内，说明整个通话是优质的，通话效果就像大家在同一个房间里聊天一样；300ms以内，大多数人很满意，400ms以内，有小部分人可以感觉到延迟，但互动基本不受影响；500ms以上时，延迟会明显影响互动，大部分人都不满意。

所以最关键的一级是500ms，只有延迟低于500ms，才可以说是合格的实时互动系统。

2.3 音频服务质量指标

接下来是音频服务质量指标，它根据MOS值来打分。4.0-5.0为“优”，评值标准是听得非常清楚，延时小，交流顺畅；3.5-4.0为“良”，音质稍差，听得清，延时小，有点杂音；3.0-3.5为“中”，音质较可，能听清，有一定时延，可以交流；1.5-3.0为“差”，勉强能够听清，交流时需要重复多次才能够表述清楚；0-1.5为“劣”，完全听不清，延时大，交流不畅。

2.4 视频服务质量指标

视频服务质量的评价标准有几个，它们也都是通过MOS值打分来判断质量好坏的，图中参考是以码流大小为标准评估指标。以640*480为例，如果想达到MOS值为4.5的优质效果，可以看到产生的码流的大小大概在3Mbps左右。这样的码流对于实时传输来说太大了，如果是640*480的视频占用3Mbps的带宽，那是一件非常奢侈的事儿。一般情况下，我们会选择MOS值为3.5（绿色线）的码流，其码流范围在600kbps左右。

从以上可以看到，在保证传输的实时性时，由于带宽是一定的，可能会牺牲一定的服务质量。

3 主要矛盾

3.1 实时通信与服务质量的矛盾

通过了解上述三个指标，我们可以得到实时通信与服务质量的主要矛盾。

第一，码流与带宽之间的矛盾。要想达到好的质量，码流一般会比较大（当然，不能超过最大码流)，而带宽是有限的，于是码流和带宽之间就会产生矛盾；第二，实时性和服务质量之间的矛盾。通常为了保证好的实时性我们会选择UDP，而UDP不保证网络传输的可靠性，丢包、乱序是经常发生的。一旦出现丢包、乱序，网络传输质量就无法得到保证，最终会影响到音视频的质量。

这里我们就可以总结出实时通信的主要矛盾，即：音视频的质量与带宽大小、实时性和网络质量之间存在矛盾，其它包括3A问题都属于次要矛盾。

4 解决矛盾方法

4.1 解决矛盾的方法

下面来看下解决矛盾的方法。对于WebRTC来说，主要从以下几个方面解决主要矛盾：如何保障数据传输的实时性、如何提高网络质量、如何更准确的评估带宽、如何平衡码流与带宽。

5 保障数据的实时性

对于WebRTC来说，为了保障数据的实时性，提供了两种方法：一种是传输路径的选择，它首先会选择最佳的传输路径，使得端到端传输时采取最好、最短的传输路径从而保障数据传输的实时性；另一种是传输协议的选择，可以选择TCP或者UDP。下面咱们先看一下WebRTC是如何选择最佳传输路径的。

5.1 选择一条最好的路径

图为WebRTC路径选择的架构图。图中包括三个端，A端、B端和C端，其中A和B在同一个局域网内，对于WebRTC来说，如果发现同一局域网内的两端需要通信时，会选择局域网内直连，从而保障网络路径最短最优；如果是A和C通信，它们不在同一局域网内，那么WebRTC会选择P2P直连，做NAT穿越，如果穿越成功，便可进行直连，这样路径相对服务器中转来说也比较短。只有在P2P不成功时，才会选择服务端中转。从图中可以看到，当一端通过TURN服务器将数据传输给另一端时，其传输路径明显长于P2P直连，所以对于WebRTC来说，它一定会选择最短、最优的路径，从而保障端到端的实时传输。

5.2 使用TCP还是UDP？

接下来看一下WebRTC对TCP/UDP协议的选择。在网络比较优质时，TCP/UDP都可以用于实时传输，但大多数情况下，我们首选UDP（后面会介绍UDP的优势）；弱网环境下不能使用TCP；而在进行网络穿越时，使用TCP又有较大的好处，在企业内可以使用TCP访问外网的80端口进行穿透。

5.3 为什么极端网络环境下不能用TCP？

为什么在弱网环境下不能用TCP？这是由于TCP的机制所造成的。TCP的机制是发送、确认、丢包、重传。正常情况下，数据从一端传输到另一端是没有任何问题的，但当出现丢包时就会有较大的麻烦。

图中显示了多次丢包时的延迟情况：从客户端向服务端发送数据包，服务端需要返回ACK消息进行确认; 客户端收到确认消息后, 才能继续发送后面的数据（有滑窗时也是类似的）。每次客户端发完数据后，都会启动一个定时器，定时器的最短超时时间是200ms。如果因某种原因，在200毫秒客户端没有收到返回的ACK包，客户端会重发上一个包。由于TCP有退避机制，以防止频繁发送丢失包，因此会将重发包的超时时间延长到400ms。如果重发包依然没有收到确认消息，则下一次重发的超时时间会延长到800ms。我们可以看到，连续几次丢包后，就会产生非常大的延迟，这就是TCP在弱网环境下不能使用的根本原因。

5.4 选择UDP带来的问题

由于TCP的机制问题，因此通常我们会选择UDP来保障音视频传输的实时性。UDP在实时性方面有优势，但缺点同样明显。由于UDP是不可靠传输，它只能尽力送达，所以出现丢包、乱序是常见的事儿，但对于网络质量来说，丢包是非常严重的事情，这就需要我们自己处理这个问题。下面咱们就来看看WebRTC是如何解决这个问题的吧！

6 如何提高网络质量

6.1 网络质量包含哪些指标

那么，WebRTC是如何处理UDP的网络质量的呢？

要想解决网络质量，首先要知道影响网络质量的几个因素：它包括了丢包率、延迟时间、抖动、乱序。如果网络丢包率低、延迟时间小、不抖动、不乱序，这就是非常优质的网络啦。但如果丢包率很高，那么网络质量一定会很差。

6.2 造成丢包的原因

图中是网络基本的拓扑，造成丢包的原因有很多，如链路质量差，当手机与基站连接时，由于信号不好会造成丢包，这就属于链路差，这种情况在移动端是经常发生的；第二是带宽满，比如一台机子上行发送码率比较大，而下行接收链路比较小，这时在上游的路由器会把数据缓存起来慢慢发送，但缓存是有限制的，一旦缓存被塞满，后面就会造成大量丢包；第三是主动丢包，比如路由是跨运营商的，在不同运营商之间传输数据时，可能由于运营商未知的原因造成丢包；第四是光线被挖断等偶然原因造成丢包。

6.3 减少丢包的方法

WebRTC主要通过两种方式解决丢包：NACK和FEC。

6.4 NACK

NACK的作用是丢包重传。从图中你可以看到，WebRTC的发送端不停地向接收端发送RTP包，接收端每隔一小段时间，就对这段时间内的丢包情况进行统计。如果发现丢包，它会给发送端回一个NACK消息，NACK消息中记录了这一段时间内哪些包丢失了。发送端收到NACK后，会在之前的发送历史记录中找到丢失的包并重新发送。

6.5 NACK适合使用的场景

当然，通过NACK重传，会产生一定的延时，该延时包括：等待发送NACK的时间（10或20ms），NACK经过网络的时延以及RTP的网络时延和重传RTP包的网络时延，即1.5RTT+10或20ms。通过这个公式我们可以知道，如果RTT时延比较大，比如200ms，那么1.5RTT就是300ms。通过前面讲述的实时传输延时指标我们可以知道，端到端实时传输的时延需要控制在500ms之内，如果仅数据的网络传输就占了300ms，那数据再经过采集、编码、解码、渲染等流程，这些处理时间加在一起很有可能就超过500ms。

所以可以得出结论，丢包重传仅适用于网络传输时延比较小的情况，如果RTT比较大时，就不适合使用丢包重传来保障网络质量了。

6.6 FEC

FEC的作用是通过冗余数据解决丢包。实际上，它就是一个异或操作。如图所示，假设传输的数据是Data1和Data2，这两个数据如果在传输的过程中没有FEC进行保护，其中一个数据丢失了，那只能通过NACK重新找回。那么，能否在传输过程中加一些冗余数据，以保证接收时，当某一个数据丢失后，不经过重传就可以将丢失的包找回来呢？这就是FEC。

在图中我们可以看到，Data1和Data2同时发送到对端，在发送时对它们做一下异或操作，即Data1的最后一位0与Data2的最后一位0异或为0，Data1的倒数第二位1与 Data2的倒数第二位1异或为0，依次类推，最后就产生了冗余数据R，同时将三个包从一端传输到另一端。传输过程中，如果Data1丢失，通过Data2和冗余包R就可以将Data1找回来。找回包的算法也是异或操作，即在接收端将Data2的每一位与冗余包中的相同位进行异或操作就算出了Data1。这就保证了不用重新请求，就将丢失包找回的作用。

而且异或具有传递性，A、B、C三个包可以同时异或得到D，如果其中任意一个包丢失，可以通过D和其它包找回丢失的包。

6.7 ULPFEC

对于WebRTC来说，它默认使用的是ULPFEC。其原理是，将要传输的数据包先进行分组，如将三个包分为一组，然后为这一组包产生一个冗余包，如果这一组中某个包丢失了，就可以通过冗余包和其它包的异或操作将其找回。从图中第一行可以看到1和2到了，3丢了，通过R1可以找回3，第三行同样可以找回9。其缺点是，如果连续的两个包都丢失了，这种算法就失效了，比如第二行4和5丢失后，通过6和R2无法找回它们。

6.8 FlexFEC

于是就有了改进的FlexFEC，它做了双向冗余处理，不仅横向做了冗余，而且纵向也做了冗余。

此时，当4和5同时丢失时，通过1、7和C1可以找到4，2、8和C2可以找到5，这样就可以找回连续的两个丢包。当然它也有弊端，其弊端是无法处理批量的连续丢包，例如连续丢失了10个包，FlexFEC对这种情况也无能为力。

以上就是WebRTC对于丢包的解决方法，通过“NACK+FEC”防止丢包。

6.9 如何解决抖动和乱序

下面来说说抖动和乱序。抖动的意思是，一会儿来了很多包，一会儿又一个没有，包是一波一波的来，包到达的时间很不平均；而乱序指的是先发的包后到了，后发的包先到了。

WebRTC处理抖动和乱序使用的是JitterBuffer和NetEQ。JitterBuffer用于处理视频包，NetEQ用于处理音频包。它们的原理大致相同（NetEQ更为复杂一些），都是通过一个队列（缓存区）对接收到的数据做下缓冲，然后再从队列的另一端将数据包一个个均匀的取出， 这样取出的数据就是平滑的了。

对于乱序的处理也比较好解决，如图中所示，每个RTP包进来的时候有一个序号（Sequence Number），在数据进入队列时，它会根据序号插到对应的位置上，比如图中104、107包已经到达，并且在对应的位置上，而103、105和106没来，位置就空着，等它们来了再插入对应的位置，这样就可以防止乱序，所以通过JitterBuffer和NetEQ就可以同时解决乱序和抖动了。

总结一下，NACK和FEC解决丢包问题，NACK会增加时延，FEC会占用带宽。JitterBuffer解决视频的乱序与抖动，NetEQ解决音频的乱序与抖动。

6.10 网络延时产生的原因

说到延时，实际上就与带宽评估有密切的关系了。延时的产生有两个原因：第一是链路问题，正常的网络上，数据包的传输都是时快时慢的；第二是发生了网络拥塞，当发生拥塞后，数据包会进行缓冲，就会造成延时，而当缓冲溢出时，就出现了丢包。

所以对于延时来说，我们需要解决的是因拥塞而造成的延时，链路问题无法解决。下面咱们就来看看WebRTC是如何防止拥塞的。

7 准确的带宽评估方法

7.1 如何解决抖动和乱序

WebRTC防止拥塞的根基是有准确的带宽评估方法。它提供了两种带宽评估方法，一种是基于丢包的带宽评估，另一种是基于延时的带宽评估。而基于延时的评估方法又分为接收端（Goog-REMB）和发送端（Goog-TCC）的带宽评估方法，目前默认采用的是Goog-TCC方法，因为其相对来说更为精准。

7.2 基于丢包的带宽评估

基于丢包的带宽评估方法比较简单，根据丢包率进行计算。实际上，正常带宽也有一定的丢包，如果丢包率<2%，属于网络质量不错的正常丢包，说明带宽还没有达到上限，应该增加评估的带宽值。举个例子，比如你家里的带宽是8M，WebRTC最开始是不知道你家里的真实带宽的，它必须一点点测量，所以一开始它先给你的带宽设置一个假设值，即500K，当发现丢包率很低时，它再增加带宽的评估值，如从500K升到1兆，如果丢包率还是很低，就会加到1.5兆、2兆……，带宽评估值增加的速度是每次增加8%；如果丢包率>10%，说明发生拥塞了，此时应该立即降低带宽，公式如图（loss>0.1时）所示。如果丢包率<10%，说明现在的带宽评估的比较准确，此时应该保持这个带宽，不增加也不减少；

7.3 基于延时的带宽评估

基于延时的带宽评估方法比基于丢包的评估更好一些，因为它可以提前预估是否发生了拥塞。基于丢包的评估丢包率一旦超过10%就说明可能已经发生拥塞了，而网络一旦拥塞，再想恢复回原来的状态，需要花费一段时间，而这段时间就会影响音视频的服务质量。

而基于延时的带宽评估就不会产生这种情况。它的基本原理是，如果接收到的数据包的网络传输时延在持续增长，就说明网络变差了，当达到一定程度时，就要将评估的带宽值降下来，以防止发生网络拥塞。它的计算公式是根据状态机来的（状态机比较复杂，我这里就不讲了），当状态非常好时，需要增加带宽，同丢包增加带宽一样，每次增加8%；如果延时一直累加，则需要降低带宽，带宽降为原来85%，其它情况就保持当前带宽，无增无减。

8 媒体数据与带宽的平衡

8.1 媒体数据与带宽的平衡

当带宽评估准确之后再进行控制就非常容易了。接下来，我们看一下WebRTC如何平衡媒体数据与带宽。

带宽评估方法和网络质量的提升在前面我已经介绍了。在有限的带宽下，如何才能提供更好的音视频服务质量，是人们一直孜孜不倦追求的目标。因此在同等条件下，可以将数据压缩的更小，一直是解决服务质量的一种关键方法。目前最常用的视频编码器还是H.264，不过新的编码器已经有了很大突破VP9/H265、AV1/H266提供了更高的压缩率，这使得我们在网络条件有限的情况下，可以传输更多的数据从而保障更好的服务质量。

另一方面，在带宽相同且码流无法压缩的情况下，还可以采用动态码率。通常，在使用动态码率时，我们可以直接从产品上看出来，你会发现视频一会儿清晰，一会儿模糊。即在带宽小时，编码器压缩码流，此时视频变得模糊；带宽大时，编码器放大了码流，所以视频变得清晰。以上就是通过减少数据量的方法来保障实时通信质量的。

8.2 Simulcast与SVC

除此之外，还可以通过Simulcast或SVC解决质量问题。Simulcast和SVC解决问题的思路是类似的，它们会在发送端增大码流的发送，将数据先传给服务端，然后由服务端根据接收端带宽的不同，选择合适的码流下发。对于网络较差的用户，传输清晰度低的码流，对于网络较好的用户，传输高清晰度的码流。所以这两种技术对于发送方的带宽和质量有非常高的要求。

SVC与Simulcast最大的区别：SVC上传的是一路码流，但这一路码流是由多层构成的。服务端会按照不同接收端的带宽大小，选择传输不同的层。如上图所示，手机端带宽小，就传输小的一层数据，PC端带宽大，就将所有层全部传输过去；而Simulcast上传的是多路流，一般分为小、中、大三路。对手机端传输小的一路，对PC端传输最大的一路。Simulcast的好处在于，每一路流都是独立的，所以可以对每一路流使用硬件编解码器，而 SVC的分层方式目前没有硬件支持，所以无法通过硬件加速。

8.3 流控

当带宽评估准确后，如果发送的的码流还是大于带宽大小，此时就需要通过流控来进行控制了。流控的作用是当输出码流大于带宽时，降低发送码率，以防止发生拥塞。当然它会导致时延的增加。实际上，对于流控来说，它需要控制两个点：第一个点是Pacer，降低发送码率。当然仅降低发送码率还不够，因为如果编码器仍然输出大量码流给Pacer，那么Pacer 的缓冲区迟早会被撑爆。所以在控制Pacer让它减少发送码率的同时，一定要降低音视频的编码器的输出码率，从而保持平衡，进而使数据平缓下行。

正如我前面所说的，流控虽然防止了网络拥塞的发生，但会增加一些延时，增加的延时最终会反应到实时通信的总指标里，总的延时必须控制在500ms以内。比如以前端到端时延是200ms，由于带宽不足，时延增加到300ms、400ms都是可以的，但一定不要超过500ms。

此外，对于编码器的输出码流来说，如果流控通过直接降低码流仍然不能与带宽适配时，还可以通过降低分辨率的方式来降低码流。总之，在带宽不足时，要想尽办法减少数据量。实在不行，也可以关掉视频只保留音频来保障网络的畅通。

9 总结

总结一下，对于服务质量保障，首先提高网络质量，NACK和FEC解决丢包问题，JitterBuffer解决视频的乱序与抖动，NetEQ解决音频的乱序与抖动；带宽评估通过Goog-REMB和Goog-TCC，还有丢包的带宽评估；为了保障实时性，需要选择更优质的线路，比如客户端与服务端通信的时候选择更好的路线节点，保证云端网络带宽等等；从业务上，减少数据量可以用AV1、SVC、Simulcast、动态码率，减少业务；在防拥塞上，通过Pacer进行流控，只要能控制在500ms之内，适当增加时延也是可以接收的。

以上就是本次分享的全部内容，谢谢！

Q&A (部分)

1. 路径的选择是WebRTC内部自动选择的吗？

是自动选择的。WebRTC会自动判断通信的双方是否在同一个局域网内，如果是就直接在局域网内建立连接；如果不是，会通过STUN协议获取各自的外网地址，然后进行NAT穿越；如果还不成功的话，才会选择TURN服务进行数据中转。

2. WebRTC网络传输质量衡量指标有什么？

衡量任何一个实时传输系统时，首要看它的时延是否达到500ms以内。其实500ms对于实时通信而言，也是比较苛刻的标准了，因为网络的变化是非常大的， 所以要实现这个指标其实难度也是蛮大的。其次是丢包率，这是非常关键的指标，刚才说到2%的丢包率代表网络比较好；小于10%，对于WebRTC来说，代表目前的带宽是准确的；超过10%则代表发生了拥塞。有些厂商说它的产品可以抗xx%的丢包，这样的前提是不认为丢包是一个指标，但在真网络中，当路由的缓冲被撑爆后，必然会出现大量丢包，如果不把丢包当作指标的话，就缺少了一种判断网络拥塞发生的条件，这显然是不合理的。

3. 视频JitterBuffer怎么具体控制平滑的？

其实JitterBuffer平滑处理的难度并不像我们想像的那样复杂，之所以大家认为它复杂，可能是因为一些额外的因素，如还要处理音视频同步等问题。对于平滑处理，我们完全可以自己通过一个Buffer来实现。Buffer可以是动态大小或固定大小。为了简化，我们假设它是固定大小，比如定义一个可以存放 100 个元素的数组，在数组的一头每隔 10 毫秒取一个包，这就是一个最简单的平滑处理。当然更好的方式是可以根据网络的变化让这个平滑数组的大小也动态变化，这样就更高级一些。当然，如果Buffer是动态变化的，那在计算平滑数组的动态大小时，会稍难一些。

4. WebRTC要和SIP客户端通讯有什么好的方案？

一般与SIP通信最好借助流媒体服务器比如Janus，它既支持SIP协议也能支持WebRTC客户端。这样SIP终端就可以将数据传输流媒体服务器，然后再转发给WebRTC终端了，同理WebRTC终端也可以通过流媒体服务器与SIP终端通信了。

5. FEC和NACK默认是不是都要开启？

是的。对于WebRTC来说，FEC和NACK都是开启的，也可以控制它们的开关。

6. 能说下为什么TCC比REMB准确吗？

TCC和REMB主要有两个区别。第一是计算的端不同，REMB是在接收端计算的，接收端计算后再将结果返回给发送端进行控制，而在回传结果时，可能网络又发生了新的变化，这就造成了REMB的及时性不够；TCC是将所有数据都交给发送端做计算和控制，因此及时性和准确度会更高。第二是滤波器不同，REMB是卡尔曼滤波器（Kalman），TCC是最小二乘法滤波器（Trend line）。最小二乘法滤波器在网络延时评估这方面比卡尔曼滤波器效果更好一些。

7. 在内网环境下p2p想让延时尽可能小，可以做哪些工作？实验室环境最小延时可以达到100ms以下吗？

如果在同一个局域网内，实际只有几十毫秒的延迟。有同学可能会疑惑，有的产品在同一局域网内延迟非常小，为什么用WebRTC反而延迟增大了？这就是因为WebRTC为保障网络质量，在内部通过多种机制，各种缓冲，来做到的。所以它必然会产生一定的延迟，也就是拿延迟换质量。而在局域网内，网络基本没有延时，不丢包、不抖动、不乱序。这时什么策略都不采用，网络的传输才是最快的，因此在内网通信时，WebRTC的实时性一定不如什么策略都不加的产品好。

8. ULPFEC和FLEXFEC区别是？

ULPFEC只能进行单向冗余处理，而FLEXFEC可以进行双向冗余处理，即可以横向分组还可以纵向分组做冗余，所以它的抗丢包性要比ULPFEC好，同时占的带宽也比ULPFEC多。

9. 可靠性这块，UDP上的WebRTC做ack是自己封装了seq吗？然后，一样需要ack重传的话，跟TCP SACK有什么区别呢？

WebRTC使用的是RTP协议传输数据。RTP协议中有seq字段。此外，WebRTC用的NACK与TCP的ACK机制不同。TCP每一块数据都需要通过ACK进行确认，如果没收到ACK就重发，直到成功收到ACK或断连；而NACK允许丢包，当重传多次不行时，就不传了。且而即使重传了数据包，在接收端发现它已经过期时，也会将其丢掉。

10. WebRTC后面会用QUIC协议吗？

这个问题争论较大。WebRTC也在一直在尝试使用QUIC协议，从我的角度来看，QUIC协议最主要的是解决Http3，Http3解决的是TCP的问题，就要保证数据的可靠性，那么实时性就会受到影响，什么时候QUIC如果可以解决好实时性问题就可以用，反之则不能。

从我的角度看，一种协议最好只解决一件事儿，很难通过一套协议解决所有问题。