如何理解冲突域和广播域？（转）

转自：http://blog.sina.com.cn/s/blog_7e8dec240102wyio.html
网上看到的好文章，整理下来，方便复习，侵删

• 1、冲突域：

【定义】在同一个冲突域中的每一个节点都能收到所有被发送的帧。简单的说就是同一时间内只能有一台设备发送信息的范围。

【分层】基于OSI的第一层物理层

【设备】第二层设备能隔离冲突域，比如Switch。交换机能缩小冲突域的范围，交换接的每一个端口就是一个冲突域。

• 2、广播域：

【定义】网络中能接收任一设备发出的广播帧的所有设备的集合。简单的说如果站点发出一个广播信号，所有能接收收到这个信号的设备范围称为一个广播域。

【分层】基于OSI的第二层数据链路层

【设备】第三层设备才能隔离广播域，比如Router。路由器能隔离广播域，其每一个端口就是一个广播域。

​下面通过三个例子来说明：
例子一：一个Switch直连三台PC和一台hub，而hub下直连有2台PC。

​​图中已经给出了答案，可是，这个4个冲突域1个广播域是怎么算出来呢？

根据前面介绍的关于广播域的定义中我们知道 ，只有第三层设备才能隔离广播域。上图中并没有router等第三层设备，所以，这里的广播域没有被隔离。也就是说上图中的网络只有1个广播域。

冲突域的计算，前面有说Switch能缩小冲突域，一个Switch端口其实就是一个冲突域，上图中有3台pc和1台hub直连到Switch上，所以，这里的冲突域为4个。

第一个例子比较简单，下面我们在网络中有router第三层设备的例子

​一台router下直接连接三台hub，hub下都各自连有三台pc：

第三层设备router能隔离广播域，上图中router的三个端口分别直连了三个hub，因此得出有三个广播域。

但是，那3个冲突域是怎么来的呢？

其实，router他不但能隔离广播域，默认也是可以缩小冲突域的。所以上图中的router用3个端口将网络既分开成了3个广播域，又缩小成了3个冲突域。

第二个例子给了我们一个提醒，那就是路由器默认也是可以隔离冲突域的。

好了，下面我再看最后一个例子，这里都用上了常用的网络设备hub、Switch和router。

一台router下连两台交换机和一台hub，两台交换机下分辨连有三台 PC，而hub下连有4台PC：

​上图所示网络，算出3个广播域不难，因为router有3个端口直连了2台交换机和1台集线器嘛。可是，冲突域不是7个吗？怎么是9个呢？两台交换机共使用了6个端口，外加路由器下还直连了一个集线器，这也是一个冲突域。于是，我可以得出6+1=7，7个冲突域啊。究竟是哪里算少了？对了，就是路由器到两台交换机之间也还是存在冲突域的。这一点也特别需要注意。

最后记录一下例子中提到的需要注意的地方了：

1、第二层设备只能隔离冲突域，第三层设备才能隔离广播域；

2、路由器不但能隔离广播域，默认也是可以隔离冲突域的；

3、路由器下直连交换，则路由器到交换机之间也是存在冲突域的。

总结：

​1、第二层设备只能隔离冲突域，第三层设备才能隔离广播域

​2、路由器不但能隔离广播域，默认也是可以隔离冲突域的

​3、路由器下直连交换，则路由器到交换机之间也是存在冲突域的

​4、router不仅能能够分割广播域，也能缩小冲突域

​5、交换机的每一个端口是一个冲突域

​6、集线器下连的所有端口是一个冲突域（上一个设备是路由器）

​

原文：https://www.cnblogs.com/imstudy/p/9124987.html

3、帝国时代

我相信我们都玩过一款特别火的游戏：帝国时代。小时候想要玩帝国时代，需要到软件城购买盗版光盘安装，大概3块钱一张左右的样子，当时已经觉得很便宜了，谁想到现在有了网络之后是免费。

小A是一个帝国时代大神，他打通了游戏的所有关卡，可以一个人单挑8个疯狂的电脑玩家。渐渐地他觉得无聊了，想要找小伙伴一起PK。

但是两个电脑需要互联才行，如何实现两台设备的互联呢？

小A很聪明，他发明了一个类似于USB口一样的可以传输数据的端口，他将其命名为网口。小A通过一根网线将自己的电脑与小B的网口相连，实现了两台电脑间的互连（如下图）。

4、集线器（Hub）

两个小伙伴很开心，联机玩了起来，这时被路过的小C看见了，小C也要加入进来。

但是我们知道，每台电脑只有一个网口，无法实现三台电脑的相互连接，那要要怎么办呢？

这时候小B出了一个主意：咱们再找一台计算机，给他多设计几个网口，我们每个人都连到这台计算机的网口上，不也实现咱们哥几个之间的互连了吗。

说干就干，于是他们设计出了一款微型计算机，他本身具备多个网口，专门实现多台计算机的互联作用，这个微型计算机就是集线器（HUB）。

顾名思义，集线器起到了一个将网线集结起来的作用，实现最初级的网络互通。

集线器是通过网线直接传送数据的，我们说他工作在物理层（如下图所示）。

5、交换机

有了集线器后，越来越多的小伙伴加入到游戏中，小D、小E等人都慕名而来。

然而集线器有一个问题，由于和每台设备相连，他不能分辨出具体信息是发送给谁的，只能广泛地广播出去。

例如小A本来想问小C：你吃了吗？结果小B，小D和小E等所有连接在集线器上的用户都收到了这一信息。 

由于处于同一网络，小A说话时其他人不能发言，否则信息间会产生碰撞，引发错误，对这种情况，我们称为各设备处于同一冲突域内。

这样的设备用户体验极差，于是小伙伴们一起讨论改进措施。

这时聪明的小D发话了：我们给这台设备加入一个指令，让他可以根据网口名称自动寻址传输数据。

比如我把小A的网口命名为macA，将小C的命名为macC，这时如果小A想要将数据传给小C，则设备会根据网口名称macA和macC自动将资料从A的电脑传送到C的电脑中，而不让小B、小D和小E收到。

（补充说明： 这里的macA, macB指的就是MAC地址，相当于一个人的身份证，独一无二。）

也就是说，这台设备解决了冲突的问题，实现了任意两台电脑间的互联，大大地提升了网络间的传输速度，我们把它叫做交换机。

由于交换机是根据网口地址传送信息，比网线直接传送多了一个步骤，我们也说交换机工作在数据链路层（如下图）。

交换机通过查找自身系统MAC地址表中的MAC地址与端口对应关系，将数据传送到目的端口。

这回小伙伴们高兴了，他们愉快地玩耍起来。

6、路由器

渐渐地，他们在当地有了名气，吸引了越来越多的小伙伴加入到他们的队伍中。有一天，一个外村的小伙突然找上门来，希望能和他们一起互联，实现跨村间的网络对战。

小A说可以呀，于是他们找了一根超长的网线将两个村落的交换机连在了一起。结果发现一件奇怪的事：两个村落间竟然不能相互通信。

怎么回事？原来那边的电脑和他们用的不是一套操作系统，这导致信息间的传送形式的不匹配。在这期间，还有其他村落的人也来找过小A，可是小A发现，每个村子之间用的操作系统都不一样。

这可咋办呐？难道以后只能各自村子玩各自的了吗？为了解决这一问题，各村的小伙伴们坐在一起组织了一场会议，最终得出了一套解决方案：采用同样的信息传送形式（像不像秦始皇统一度量衡？）。

那如何实现呢？小伙伴们规定，不同的村子间先在各自的操作系统上加上一套相同的协议。不同村落通信时，信息经协议加工成统一形式，再经由一个特殊的设备传送出去。这个设备就叫做路由器。

在这套协议中，每个机器都被赋予了一个IP地址，相当于一个门牌号一样。路由器通过IP地址寻址，我们说它工作在计算机的网络层。

这样，经由如此的一系列改装，小A终于带领村民们实现了整个乡镇的通信。随着越来越多的城里人也加入小A的协议，小A带领村民逐步实现了全市、全国乃至全世界的通信。这一套协议便是TCP/IP协议簇，互联网也便这样形成了（关于TCP/IP改变世界的故事，详见《技术往事：改变世界的TCP/IP协议（珍贵多图、手机慎点）》）。

然而，即便如今全网络已遍布了全世界，在小A和村里的小伙伴对战帝国时代的时候，也仍然用着交换机。只有和外面更大的世界交流的时候才用到路由器。

其实上图只是为了帮助您更好地理解路由器，一个真实的网络拓扑中，路由器、交换机、集线器是一起分工合作的，正如下图所示：

（如上图所示：Router即路由器、Switch即交换机、Hub即集线器）

广播域

广播是一种信息的传播方式，指网络中的某一设备同时向网络中所有的其它设备发送数据，这个数据所能广播到的范围即为广播域(Broadcast Domain)。
在传输中当不知道目的MAC地址时，需要在网段内广播当前子网下所有的节点，相应的广播报文以及目的MAC查找失败报文会向所有端口转发，因此会消耗大量的网络带宽。而二层交换机只能隔离冲突域，不能隔离广播域。（这里可使用Vlan技术  在一个局域网内      划分不同个    vlan（虚拟局域网）  来    隔离  广播域）
冲突域是基于第一层（物理层）
广播域是基于第二层（链路层）
 

原文链接：https://blog.csdn.net/weixin_39731083/article/details/81637581

交换机与路由器差别：

https://blog.csdn.net/liebao_han/article/details/52859814

（1）外形上：

       从外形上我们区分两者，交换机通常端口比较多看起来比较笨重，而路由器的端口就少得多体积也小

（2）工作层次不同：

       最初的交换机工作在OSI开放式系统互联模型的数据链路层，也就是第二层，而路由器则工作在OSI模型的网络层，就是第三层。也就是由于这一点所以交换机的原理比较简单，一般都是采用硬件电路实现数据帧的转发，而路由器工作在网络层，肩负着网络互联的重任，要实现更加复杂的协议，具有更加智能的转发决策功能，一般都会在在路由器中跑操作系统，实现复杂的路由算法，更偏向于软件实现其功能。

（3）数据的转发对象不同：
        交换机是根据MAC地址转发数据帧，而路由器则是根据IP地址来转发IP数据报/分组。数据帧是在IP数据包/分组的基础上封装了帧头（源MAC和目的MAC等）和帧尾（CRC校验码）。而对于MAC地址和IP地址大家也许就搞不明白了，为何需要两个地址，实际上IP地址决定最终数据包要到达某一台主机，而MAC地址则是决定下一跳将要交互给哪一台设备（一般是路由器或主机）。而且，IP地址是软件实现的，可以描述主机所在的网络，MAC地址是硬件实现的，每一个网卡在出厂的时候都会将全世界唯一的MAC地址固化在网卡的ROM中，所以MAC地址是不能被修改的，但是IP地址是可以被网络管理人员配置修改的。

（4）”分工“不同

        交换机主要是用于组建局域网，而路由器则是负责让主机连接外网。多台主机可以通过网线连接到交换机，这时就组建好了局域网，就可以将数据发送给局域网中的其他主机，如我们使用的飞秋、极域电子教室等局域网软件就是通过交换机把数据转发给其他主机的，当然像极域电子教室这样的广播软件是利用广播技术让所有的主机都收到数据的。然而，通过交换机组建的局域网是不能访问外网的（即是Internet）,这时需要路由器来为我们”打开外面精彩世界的大门“，局域网的所有主机使用的都是私网的IP，所以必须通过路由器转化为公网的IP之后才能访问外网。

（5）冲突域和广播域

        交换机分割冲突域，但是不分割广播域，而路由器分割广播域。由交换机连接的网段仍属于同一个广播域，广播数据包会在交换机连接的所有网段上传播，在这种情况下会导致广播风暴和安全漏洞问题。而连接在路由器上的网段会被分配不通的广播域，路由器不会转发广播数据。需要说明的是单播的数据包在局域网中会被交换机唯一地送往目标主机，其他主机不会接收到数据，这是区别于原始的集线器的，数据的到达时间由交换机的转发速率决定，交换机会转发广播数据给局域网中的所有主机。

         最后需要说明的是：路由器一般有防火墙的功能，能够对一些网络数据包选择性过滤。现在的一些路由器都具备交换机的功能（如上图右），一些交换机具备路由器的功能，被称为3层交换机，广泛使用。相比较而言，路由器的功能较交换机要强大，但是速度也较慢，价格昂贵，三层交换机既有交换机的线性转发报文的能力，又有路由器的良好的路由功能因此得到广泛的使用。

   首先，Android依赖包冲突其实并不是简单的不同模块依赖了相同库的不同版本，因为系统会自动选择高版本，同时给这两个模块使用。冲突只存在两种情况

•     引用了本地jar文件
  由于引用的jar是会直接编译到项目里的，如果项目的两个module同时引入了相同的本地jar文件, 就会存在相同的类有多个实现，及duplicated defined class。这种情况比较好分析和定位，去掉其中一个即可。
•    不同模块引用了相同的远程库(比如maven库)的不同版本，且这两个版本不兼容
  这类冲突主要是Android Support类, 目前Android已经退出AndroidX包了。
  这种情况就比较难分析，本文将就我曾经遇到过的一个案例来分析此类包冲突的解决方案流程。

问题分析

 当时编译一个项目时遇到这个错误

  Learn how to resolve the issue at https://developer.android.com/studio/build/dependencies#duplicate_classes.

  Program type already present: android.support.design.widget.CoordinatorLayout$Behavior

 CoordinatorLayout$Behavior类存在多次定义。这个主要是因为这个类在support的低版本26.xx上，是在design库里的。而到了support的27.xx，这个类却到了support-core-ui库。

com.android.support:design:26.1.0

com.android.support:support-core-ui:27.1.0

     所以如果你有些模块引用了design:26.xx, 其他模块引用了support-core-ui:27.xx, 然后就会出现CoordinatorLayout在两个库都存在的问题

    如果design也是27版本，该库不会有CoordinatorLayout这个类，也就不会报错了。

    解决方法，就是让这两个库保持一样的版本。通过修改app/build.gradle, 让这两个库都使用较高的新版本，然后就可以保持一致了(全局使用高版本库替换)

问题原因

    上面分析出了原因，但是为甚会出现这种情况呢？我们具体来分析下：

通过./gradlew dependencies即可查看包的依赖分析，该命令非常有效，大家可以试试

ModuleA通过引用support 27版本引入了support-core-ui:27.1.1库

ModuleB直接依赖design 26版本，尽管因为ModuleA引入了support 27导致ModuleB依赖的support-core-ui升级到了27，

但是design库并没有升级，从而导致同时存在design:26和support-core-ui:27, 进而引入了两个相同类CoordinatorLayout

/**************************************************
* 本文来自CSDN博主"一点码客"，喜欢请顶部点击关注
* 转载请标明出处:http://blog.csdn.net/itchosen
***************************************************/

如需实时查看更多更新文章，请关注公众号"一点码客"，一起探索技术