闲聊音视频桥AVB--以太网的桥和路2

上篇为以太网的桥接和路由做了些铺垫，说到桥接以太网用到的MAC地址，下面继续浅谈闲聊。

MAC地址还可以根据传输方式分为单播，多播和广播。一般的MAC地址就像上篇给的那个例子CC:32:80:E9:44:DB，就是单播的，发给某一个设备。以太网还可以多播Multicast，单发多收。多播是通过赋予一部分特殊的MAC地址特殊性。多播的目的地址有个特点，就是最高8位MAC地址Octet的最低位如果设为1，就证明这个地址被用作多播地址。 

我常接触的多播地址就是91:E0:F0:00:FE:00 – 91:E0:F0:00:FE:FF，这些都是为AVB stream 静态配置准备的。多播里还有一个更特殊的形式就是当MAC地址是全F时，就是广播了，所有人都收到，FF:FF:FF:FF:FF:FF。

IP地址就不啰嗦了，会看我吧啦到这里的应该都知道，配合着子网掩码，实现了网络的Hierarchy结构。 

当一个IP数据包被套娃在以太网数据帧里的时候，你放眼看过去就可以看到MAC和IP这两对地址： 

这就可以引出桥接Bridging和路由Routing，Bridging用的是完整的MAC地址，桥接的永远是帧Frame；而Routing则要用到IP地址，路由出去的对象是IP数据包。当初我刚接触这两个概念的时候，感觉英语英语看不懂，中文中文看不懂，什么桥啊路啊的。现在想想确实比较抽象，特别是出现了交换机Switch搅局。有的交换机有路由功能，既可以当Bridge，又可以做路由器，看的云里雾里。其实后来稍微理解点背后的概念了，就好了。

记住一点，通常情况下，桥比路短，路比桥复杂。上了桥，哪怕是立交桥，到目的方向，通常只有一条线路。上了路，到目的地，往往有不同的走法。这也是Bridging和Routing的内核区别。

Bridging的转发只关注第二层数据链路层，只使用Ethernet的头或者头尾，不会把里面的IP套娃打开。交换机知道每个端口接的设备的MAC地址，当收到数据帧的时候直接根据目的MAC地址按照地址表格发送到相应的端口，所以速度较快。 

而路由则是通过解析IP数据包得到目标地址，再配合子网掩码确定发送端口，这就必须打开里面的套娃，读取IP地址，多一个动作速度就慢一点。 

前面说了AVB的B是桥接，发送的是音视频数据，对延迟，同步，抖动非常敏感。应用场景是像车身内部Infotainment系统的这种局域网，范围较小。我想这也是它基于第二层Bridging的主要理由。一个重要的点是，AVB总是基于多播MAC地址和VLAN ID进行桥接，目的地址都是91打头的。 

了解了这点继续先看普通情况下，没有应用AVB的以太网和交换机是如何转发以太网帧的，举个例子三台设备连接到交换机，两台设备发送，一台设备接受。 

在交换机的出口（Egress）会有一个输出缓存，这就避免了输出的冲突。通常这个缓存的大小不能太小。

但是如果某个发送设备，出现了数据突发Burst，即便是一个大缓存，也可能出现狼狈工作的情况，就会出现相应的高延迟，高抖动。

更进一步，如果繁重的传输任务继续加重，一直持续，就会出现缓存溢出，丢包，高延迟，高抖动都会更加严重。一定数量的以太网帧丢失，里面装的不管是音视频流，还是IP数据包，都会丢失。 

而AVB则通过预留带宽和FQTSS（Forwarding and Queuing of Time Sensitive Streams时间敏感性流的转发和队列协议）完美的解决了这个问题。Talker按步按节奏的发送信息，不会超过预留的带宽，这样在输出端口就不需要太大的缓存，也能实现低延迟和低抖动。带宽预留是按照媒体流来事先预定的，不会占据超过理论带宽的一个限定值，比如75%。

预留带宽，就是像给道路交通限流一样给媒体流限流，让发送设备不要肆意妄为的持续Burst。很可能你听说过SRP流预留协议，这个协议就是为预留带宽而准备的。它可以在网络启动的时候动态的根据不同流媒体的需要动态的分配带宽，满足各个流媒体的带宽需要，非常的灵活，而车载场景下，其实流媒体播放应用场景往往比较固定，所以，很多情况下SRP都没有在车载系统得到应用。而是在设计开始的时候，系统设计人员确定下流媒体数据传输和接受情况确定固定带宽预留好就可以了。铁板钉钉的事情虽然不灵活了，但是反而更加可靠。

一定要注意的是流预定时，一定要注意带宽能力，比如图中这种情况，两个交换机串联，如果设计成这种方式，串联两个交换机的线路带宽使用就达到了90Mbps，而图中的系统是基于100兆以太网建立的，90显然超过了70%的预留界限，就容易出现问题。在系统设计之初就应该规避掉这类问题。 

 像下图所示，降低了相应的流媒体的带宽就解决了这个问题，但是具体情况具体分析了，现在千兆以太网已经开始应用，不过相应的需求更好带宽的高清晰度视频也更多的出现在车载娱乐信息系统当中。设计的时候需要结合成本和需求，寻找一个平衡。

预留带宽或者物理的升级以太网是通过开源节流来解决问题，那是不是有了带宽预留，就可以高枕无忧了。从前面的图可以看到，当几个媒体流共享一个输出端口的时候，还是有可能出现问题。如果不加以干预，万一交换机脑残了开始挑肥拣瘦，只偏爱这几个流中的一个，统统放行，而其他流则每多掣肘，统统卡着，那也会出现问题。如何解决，前面也提到了，就是使用时间敏感性流的转发和队列协议FQTSS协议。

FQTSS说白了，也就是让所有的流和数据包能够雨露均沾的共享或者分配Egress输出端口的使用权。各种数据就像从四面八方来到目的地火车站的旅客，现实情况出站肯定是讲究人人平等，谁先到了谁出站。可是在AVB系统中，数据各不相同，有先后缓急之分。流媒体数据对时间非常敏感，就像公路上的消防车，对时间要求不高的普通数据必须给紧急的流让路。但是也不能让个没完，把普通人的权利完全剥夺了。FQTSS的策略就是优先考虑流媒体一部分时间，各个流多多少少放行一部分以后，再留给普通的Best Effort的数据一点时间发送。这样就解决了拥堵问题，既优先考虑了流媒体，又没有完全斩断普通数据的Social ladder。FQTSS的具体实现很有意思，也比较抽象，值得单独写一篇，继续挖坑以后填吧。

桥接Bridging和路由Routing，可以看作是AVB或者说是以太网进门的门槛，懂了以后觉得道理很简单，可能会觉得没有必要介绍这么多，可是最开始接触的时候总觉得自己每个字都懂，却似乎又不太明白。兜兜转转明白以后，才发现大神们命名技术的时候，其实就已经很形象的把栗子举起来放在了你的手上，蓦然回首，那人却在灯火阑珊处。Bridging和Routing就像桥和路。网络，节点，就像一个千岛之国，有桥有路，集中了各种智慧的网络协议就像Navi，不断的在更新迭代，提供更好的服务。我们要做的就是定好自己的目标地址，总有属于我们的桥和路由在前方

作者：心泉
文章来源：上汽零束SOA开发者论坛 
原文链接：https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7793