对于刚开始接触AWS的用户而言，区域（Region）和可用区（Availability Zone，AZ）这两个概念有点不好理解。初次接触时往往不知道它们跟我们日常说的数据中心是什么关系。然而区域和可用区是AWS中非常基础和重要的概念，因此我这里详细解释一下它们的一些来龙去脉。

 

我们知道云服务底层的物质基础是数据中心，但是一方面由于AWS目前的规模已经比较庞大，另一方面AWS需要服务全球不同地区的用户，因此AWS在全球建立了许多数据中心。那如何来组织和设计这些数据中心，从而让用户能够更为可靠的使用AWS提供的云服务，同时满足他们在法规遵循方面的要求呢？AWS巧妙的采用了区域和可用区两层设计架构，而不是直接使用数据中心概念。实际上这是一种IT系统架构中常用的抽象和解耦的方式，只不过这是在更宏观更高的层次——把AWS云服务与底层物理数据中心进行了解耦设计。

 

先来看一下区域（Region）概念。AWS云服务在全球不同的地方都有数据中心，比如北美、南美、欧洲和亚洲等。与此对应，根据地理位置我们把某个地区的基础设施服务集合称为一个区域。通过AWS的区域，一方面可以使得AWS云服务在地理位置上更加靠近我们的用户，另一方面使得用户可以选择不同的区域存储他们的数据以满足法规遵循方面的要求。在12月18日发布会之前全球有9个区域，包括：美东（北佛吉尼亚）、美西（俄勒冈）、美西（北加利佛尼亚）、欧洲（爱尔兰）、亚太（新加坡）、亚太（东京）、亚太（悉尼）、南美（圣保罗）和在美西服务政府的GovCloud区域。AWS中国（北京）区域将是亚马逊AWS在亚太地区的第4个区域，同时也是全球范围内的第10个区域。

 

总的来说，AWS的不同区域之间是相对独立的，但是它们的独立程度与区域的类别有关。根据目前10个区域的各自特点我们可以把它们分成3个不同的类别。第一类是GovCloud区域，主要是服务美国的政府机构和部分美国客户。GovCloud满足ITAR和FedRAMP等规范，具有独立的用户管理体系。用户使用GovCloud区域的AWS服务需要专门的申请和审核流程，所以这个区域跟我们中国用户关系不大。第二类是中国区域，这也是一个与其他区域独立的专门服务中国客户的区域。中国区域采用了独立的用户账户体系，也就是说用户需要在中国（北京）区域的网站上申请账户来使用这里的服务。最后一类的是目前其他8个区域。这8个区域是面向所有用户的，且共享同一个账户体系，所以用户注册AWS账户后可以使用所有这8个区域的服务。对于那些需要同时使用AWS这8个区域和AWS中国区域的用户来说，他们同时需要两个账户——一个在中国的区域使用，另一个在其他8个区域使用。

 

我们可以看出GovCloud区域和AWS中国区域都有自己独立的账户体系，与其他区域的服务是隔离的。对于其他8个区域，用户在不同区域存储的数据也都是相互独立的，也就是说AWS不会自动对用户数据进行跨区域的传输，这个对用户的法规遵循要求很重要。而且这8个区域的大部分AWS服务也是独立的，不过与中国区域和GovCloud区域完全独立不同的是有一些服务它们是共享的，比如它们共用一个账户体系和IAM服务，使用同一个AWS管理控制台，统一的Route53服务等。由于区域和区域之间相对独立，因此用户通过AWS管理控制台，CLI命令行和API操作AWS服务时，需要事先指定操作的对象是在哪个区域。以EC2的区域为例说明，每个区域都有自己对应的编码如下表所示：



许多AWS用户同时使用了多个区域，因此为了方便用户进行跨区域使用和部署服务，AWS目前也开始提供一些跨区域的服务，比如跨区域的EC2 AMI拷贝、跨区域的EBS快照拷贝、跨区域的RDS读拷贝等。不要需要指出的是所有这些跨区域操作都需要用户自己发起，而且这些跨区域操作只能在前面所说的8个区域之间进行。

 

AWS的每个区域一般由多个可用区（AZ）组成，而一个可用区一般是由多个数据中心组成。AWS引入可用区设计主要是为了提升用户应用程序的高可用性。因为可用区与可用区之间在设计上是相互独立的，也就是说它们会有独立的供电、独立的网络等，这样假如一个可用区出现问题时也不会影响另外的可用区。在一个区域内，可用区与可用区之间是通过高速网络连接，从而保证有很低的延时。AWS的区域与可用区的关系示意如下图所示：



每次当用户需要使用EC2相关资源的时候，他需要首先选择目标区域，如美东（北佛杰尼亚）us-east-1。然后在创建EC2实例的时候，用户可以选择实例所在的可用区，比如可以是us-east-1a或us-east-1b等。可用区的编码就是区域后面顺序添加不同的英文字母。为了尽可能让不同用户平均分布在不同的可用区，一个用户选择的us-east-1a与另一个用户选择的us-east-1a可能不是同一个可用区，AWS后台会根据实际资源情况进行映射，但同一个用户选择的某个可用区前后是固定的。如果用户在创建EC2实例的时候没有选择可用区，那么AWS会自动选择一个合适的可用区。AWS建议用户在设计应用架构的时候尽可能的把他们的应用分布在不同的可用区上面，从而提升他们应用的高可用性。应用和服务的多可用区的部署也是实现高服务水平协议的一个重要手段和要求。

 

 

 

 

 

 

 

 

 

本篇博客思路：

对于OSPF的LSA信息泛洪问题-----

-划分区域-----

-在MA中解决LSA泛洪问题-----

-路由器承担不同角色-----

-不同的LSA信息进行介绍-----

-限制LSA数量------
OSPF协议介绍博客目录
OSPF区域划分
OSPF路由器角色
OSPF 七类LSA
限制LSA数量
1.区域划分
2.特殊区域
(1)stub末节区域
(2)Totally Stub完全末节区域
(3)NSSA 非完全末节区域
(4)Totally NSSA完全的非完全末节区域
3. LSA汇总
4.LSA过滤
OSPF不规则区域的处理
(1) 双向重发布
（2）virtual link 虚链路
（3）Tunnel 隧道
ospf FA地址解释
OSPF工作过程

OSPF区域划分
划分区域的作用是什么？为了解决什么问题？



对于在MA网络中如何解决LSA泛洪的问题呢？



区域划分为：

1）骨干区域：主要功能为快速、高效地传输IP分组的OSPF区域。骨干区域将其他类型的OSPF区域连接起来，通常没有终端用户。骨干区域也叫OSPF区域0，它是网络核心，其他区域都与它直接相连。

注意：在一些CISCO文档中，将骨干区域称为中转区域。然而在OSPF RFC中，中转区域是一个与虚链路相关的术语。虚链路在后续的文章中介绍。

2）常规（非骨干）区域：主要功能为连接用户和资源的OSPF区域。常规区域通常是根据职能或地理位置划分的。默认情况下，常规区域不允许另一个区域使用其连接将数据流传输到其他区域。默认情况下，来自其他区域的所有数据流都必须经过骨干区域0.常规区域又分为几类，包括标准区域、末节区域、完全末节区域和次末节区域（NSSA）和绝对末节NSSA。文章后续的文章中介绍这些区域类型。

OSPF采用严格的两层区域结构。网络的底层物理连接必须与两层区域结构匹配，即所有非骨干区域都直接与区域0相连。
  特殊情况：如果OSPF只有一个区域，可以为任意的区域编号。

下篇 博客还会讲到对于OSPF的不规则区域的解决办法
OSPF路由器角色
OSPF路由器的类型决定了什么样的数据流能够进入和离开区域。

1）内部路由器：

所有接口都位于同一个区域中的路由器，同一个区域中所有内部路由器的LSDB都相同。

2）骨干路由器：

位于骨干区域0边缘的路由器，至少有一个接口与区域0相连。骨干路由器在维护OSPF路由信息时采用的步骤和算法与内部路由器相同。

3）区域边界路由器（ABR）：

连接多个区域的路由器，为其连接的每个区域维护一个LSDB，并路由器前往/来自其他区域的数据流。ABR将区域0连接到非骨干区域，因此是区域的出口，这意味着前往其他区域的路由信息必须经过当前区域的ABR。ABR将这些路由选择信息通告给骨干，骨干路由器再将其转发给其他的ABR。只能在ABR对其连接的区域的地址进行汇总（对其连接的区域的LSDB种的路由选择信息进行汇总）。ABR分离LSA泛洪区，还可能提供默认路由。一个区域肯能有一台或多台ABR。

理想的设计是只让每个ABR连接两个区域：
骨干区域和另一个区域。正如前面指出的，建议ABR最多不要连接3个以上的区域。

4）自治系统边界路由器（ASBR）：

至少有一个接口与其他域（如另一个OSPF自治区域系统或使用其他网络协议的域）相连。OSPF自治系统由所有OSPF区域及其中的路由器组成。ASBR可将外部路由重分发到OSPF域中，反之亦然。

注意：同一台路由器可属于多种类型。
例如，如果路由器同时连接区域0、区域1和一个非OSPF网络，
则它既是ABR又是ASBR。

对于它连接的每个区域，路由器都有一个独立的LSDB。因此，ABR有两个LSDB，一个针对的是区域0，另一个针对的是它连接的非骨干区域。属于同一区域的两台路由器中针对该区域的LSDB相同。
OSPF 七类LSA
LSA新旧比较


LSA总结列表：




限制LSA数量
1.区域划分

2.特殊区域
(1)stub末节区域

配置注意事项：


(2)Totally Stub完全末节区域

(3)NSSA 非完全末节区域


七类LSA介绍：




(4)Totally NSSA完全的非完全末节区域

3. LSA汇总

4.LSA过滤

OSPF不规则区域的处理

不规则区域的主要表现形式（数字代表区域编号）：

1023 非骨干区域为与area0相连接

123    没有骨干区域area0

010    存在多个骨干区域area0*


(1) 双向重发布

（2）virtual link 虚链路

（3）Tunnel 隧道

ospf FA地址解释



OSPF工作过程
启动配置完成后，本地默认组播发出hello包到所有邻居；若收到其他邻居的hello回复，邻居关系建立，生成邻居表;

邻居关系建立后，进行条件匹配，匹配失败将维持邻居关系，仅hello继续周期保活；若条件匹配成功，使用DBD来获取数据库目录，之后使用LSR/LSU/LSack来获取本地未知的LSA信息，生成完整的数据库表；

之后本地基于LSDB，启用SPF算法，生成导向图，再基于最短路径优先选择，将最佳路径加载于路由表中；

收敛完成，hello包周期保活，每30min周期进行数据库同步（比对，纠正）

本文为原创文章转载必须注明本文出处以及附上 本文地址超链接  以及 博主博客地址：http://blog.csdn.NET/qq_20259459  和 作者邮箱（
 jinweizhi93@gmai.com ）。

（如果喜欢本文，欢迎大家关注我的博客或者动手点个赞，有需要可以邮件联系我）




最近一段时间，我们几个人一直在讨论一个简单的和平时不太注意的问题，也争执了一段时间，所以我觉得有必要在博客中也为大家解释说明一下这个问题，也许大家也遇到或者不知道这个问题准确的解释。这个问题就是fully connected 和 local connected的区别。


相信学过神经网络的各位都会知道有一个知识点就是MLP和CNN的区别：
1. MLP是fully connected layer. 而CNN是local connected layer.
2. MLP没有weights share. 而CNN有。
其实这两点是一点，因为fully connected layer就是没有weights share的。


所以我们可以说fully connected layer的特点就是没有weights share.但是在学习MLP的时候我们又知道MLP的nodes的连接方式是点对点的，也就是1x1的size。正是因为这点，才导致大家的分歧。因为在传统的CNN中我们也会用到fully connected layer,同时也有个比较有误导性的就是CNN的FC layer往往都是1x1的filter
 size。


正因为这样所以许多人认为1x1的filter size就是fully connected.我在网络上找了许多相关解释，不少人在解释1x1的filter size的时候认为其就是fully connected.然而这是错误的。






我们知道CNN可以说是MLP的一种特例，但是CNN强大的拟合能力和自身的抑制能力目前为止还没有数学理论去证明，但是其优秀的结果总是颠覆更传统的一些神经网络。正因如此所以深度学习现在是大热到不行，不过为了证明CNN所具有超强的学习能力，有人已经做了相关的研究并发表在nature杂志上面，研究中作者打乱原来的label然后进行训练，却发现CNN还是可以提取正确的信息，这种研究虽然还是没有在数学上给予解释，但是已经可以证明CNN的强大的学习能力是存在的。


而在相对传统的CNN中，我们一直还在使用fully connected layer（比如AlexNet和VGGNet等），尽管在新的GoogleNet中FClayer已经被去除了。但是我们还是可以看到MLP这种原始神经网络的影响，以及其具有的一定的能力性。


所以我们往往会忽略一些FC的问题，因为它一直都存在于我们的使用中，一直那么的自然。久而久之我们会产生简单的把1x1就是等于fully connected的这种认知错误。






这里我将给大家一个简单的判断fully connected的方法：
1. 对于neuron的连接(点对点的连接)都是fully connected.（这里其实就是MLP）
2. 对于有filter的network，不是看filter的size，而是看output的feature map的size。如果output feature map的size是1x1xN的话这个layer就是fully connected layer。


这里解释一下第二个判断方法：
1. 1x1的filter size不一定是fully connected。比如input size是10x10x100，filter size是1x1x100，重复50次，则该layer的总weights是：1x1x100x50。


2. 1x1的filter size如果要是fully connected，则input size必须是1x1。关于这一点我们在前面使用matconvnet的时候有介绍过，fc的input size如果不是1x1就会出错。


3. input size是10x10的时候却是fully connected的情况：这里我们的output size肯定是1x1，且我们的filter size肯定是10x10。


因此我们也可以将第二点总结为：
filter size等于input size则是fully connected。






说到这里可能有人不太相信，因为大家可能根深蒂固的认为1x1的情况就是fully connected。其实有个很好的例子可以佐证我的说法：GoogleNet






这里是几种经典CNN的比较图，我们知道最导致网络冗杂和承重就是FC layer。所以GoogleNet虽然比AlexNet更加深度，但是却具有更加小的memory(weights)。 因为我们都知道GoogleNet是去掉了FC layer，所以才能在性能上大幅提升。但是我们可以看GoogleNet的构造，我们发现GoogleNet还是有1x1的filter
 size，而且有多个layer是存在1x1 filter的，因此这里可以证明我们不能通过1x1的filter size就认定是fully connected。只要input size不是1x1，那么1x1的filter也是具有weights share的。


但是在NiN的paper中，作者将Relu替换为MLP,这里就是fully connected，因为是点对点的连接。所以我们一定不要被其混淆，以至于认为1x1就是fully connected。


其实这个问题本身并不是很难理解，但是就是会有一些潜意识的理所当然会导致我们认知错误。
最重要还是需要去理解这些定义的含义，而不是自己通过想象去理解。






最后我再一次总结一下这篇文章的内容：
1. fully connected没有weights share。
2. 对于neuron的连接(点对点的连接)都是fully connected.（MLP）
3. Convolution中当filter size等于input size时，就是fully connected，此时的output size为1x1xN。

4. 当1x1不等于input size的时候,1x1一样具备weights share的能力。


但大家还是需要自己再去理解一下这个问题，仔细理解一下其中的道理。












本文为原创文章转载必须注明本文出处以及附上 本文地址超链接  以及 博主博客地址：http://blog.csdn.NET/qq_20259459  和 作者邮箱（
 jinweizhi93@gmai.com ）。

（如果喜欢本文，欢迎大家关注我的博客或者动手点个赞，有需要可以邮件联系我）

候选区域方法（region proposal method）：
首先，我们首先将每个像素作为一组。然后，计算每一组的纹理，并将两个最接近的组结合起来。但是为了避免单个区域吞噬其他区域，我们首先对较小的组进行分组。我们继续合并区域，直到所有区域都结合在一起。
下图展示了区域增长过程：


下图中蓝色矩形代表合并过程中所有可能的 ROI：