官方文档-分片分配和集群路由

对应72官方文档路径：Modules » Shard allocation and cluster-level routing

官方地址如下：

https://wwwelasticco/guide/en/elasticsearch/reference/72/modules-clusterhtml

主节点的一个重要角色就是决定哪个分片分配到哪个节点，移动分片到不同节点目的是为了平衡集群。

以下设置可以控制分片分配过程：

集群级别分片分配: 一些控制分配和平衡的设置

基于磁盘的分片分配: 阐述es如何考虑可用磁盘空间以及相关设置

分片分配感知和强制感知: 控制分片如何在不同机架或者区域分配

集群级分片分配过滤: 允许某些节点或某些节点组从分配中排除，以便将其停用

除此以外，还有一些其他混杂的集群级别设置

这部分的设置都是动态设置,可以在活动的集群上使用用集群设置更新api动态更新。

分片分配是将分片分配到节点的过程，可能发生在初始化恢复，副本分配，重新平衡，节点的添加和移除的过程中。

以下动态设置可以用来控制分片分配和恢复:

启用或者禁用某些种类分片的分配：

all(默认)： 允许全部种类分片分配

primaries： 只允许主分片分配

new_primaries： 允许新建的索引的主分片分配

none： 不允许任何分片分配

在一个node上允许同时恢复多少个shard，默认2

一个node上允许同时进行多少个shard recovery outgoing，比如这个node上，有一个primary shard，现在要将replica shard分配给其他的node，那么就是outgoing shard recovery。默认值也是2

同时设置上面两个值

在如果replica shard recovery通过网络传输来分配，那么一个未被分配的primary shard会在node重启之后使用本地磁盘上的数据，这个过程因为是使用本地的数据，因此会比较快，默认值是4

默认值是 false ，如果设置为true，那么就不允许将一个primary shard和replica shard分配到同一个物理机上，也许这个物理机上启动了多个es实例。

以下动态设置可用于控制整个群集中的分片重新平衡：

all(默认): 允许对所有类型的shard进行rebalance过程

primaries: 仅仅允许对primary shard进行rebalance过程

replicas: 仅仅允许对replica shard进行rebalance

none: 不允许对任何shard进行rebalance

always ：任何时候都允许rebalance

indices_primaries_active： 仅在分配了集群中的所有主分片时,才能rebalance

indices_all_active(默认): 仅允许所有的主副分片都被分配之后,才能rebalance

允许控制多少个shard rebalance的操作同时运行，默认是2

//todo

默认85%不再分配分片，90%将移走分片，95%触发read_only

你可以使用自定义节点属性作为感知属性,以使es在分配分片时考虑你的物理硬件配置。如果es知道哪些节点在同一个物理服务器上，同一个机架或者同一个区域，他可以分发主/副分片到不同地方,以最大程度减少发生故障时丢失全部分片的风险。

当分片分配感知通过 clusterroutingallocationawarenessattributes 设置生效时，分片将仅分配给具有设置了特殊感知属性值的节点。如果设置了多个感知属性，es将分别考虑他们。

分配感知属性可以在yml文件中设置，或者通过cluster-update-settings api动态更新。

es倾向于在同一位置(相同感知属性值)的分片上进行search，get请求，使用本地shards将会比跨机架和区域边界更快。

注： 属性值的数量决定了每个位置分配了多少个分片副本。如果每个位置中的节点数量不平衡，并且有很多副本，则副本分片可能未分配。

你也可以在启动节点的时候设置自定义属性：

注：多个属性以逗号分割填写

你也可以通过 cluster-update-settings api 设置或者更新集群感知属性。

使用以上例子的配置，如果你启动两个 nodeattrrack_id 为 rack_one 的节点，并创建一个5个主分片一个副本的索引，则全部的主分片和副本将分配到这两个节点。

如果你再添加两个 nodeattrrack_id 为 rack_two 的节点,es将移动分片到新的节点。来保证没有分片和其副本在同一个rack里面(如果可以做到的话)。

当rack_two的节点都挂掉，默认es将分配丢失的分片副本到rack_one。为了避免某一特定分片的副本分配到相同的区域，你可以使用强制感知。

默认的，如果一个区域失败了，es将分配所有丢失的副本到尚存的区域。也许你拥有充足的跨区域资源来持有你的全部主分片和副本分片，但是一个区域也许不能持有全部的分片。

为了避免发生故障时某一个区域过载，你可以设置clusterroutingallocationawarenessforce，这样直到其他的区域可用才会分配副本。

例如，你有一个感知属性zone，配置了节点分别为zone1，zone2，你可以用强制感知来避免es在只有一个zone区域可用时分配副本。

为感知属性指定所有可能的值:

通过以上的例子，当你启动两个nodeattrzone为zone1的节点，并创建一个5分片1副本的索引，es将创建索引并分配5个主分片，但是副本不会分配，除非有一个nodeattrzone为zone2的节点可用。

你可以使用集群级别分片分配过滤控制es将任何索引的分片分配到哪里，这个集群级别的过滤可以和每个索引分配过滤和分配感知配合使用。

分片分配过滤可以基于自定义节点属性或者内置的属性_name,_ip或者_host。

clusterroutingallocation设置是动态的，允许将活动的索引从一组节点移动到另一组节点。分片只有在不打破其他路由规则的前提条件下才可以移动，例如不能将主副分片移动到同一个节点。

最常用的集群级别分片分配过滤就是当你想下线一个节点的时候，将分片从此节点一走后停止这个节点，可以使用如下api通过ip过滤此节点：

clusterroutingallocationinclude{attribute}

将分片分配给attribute属性至少匹配一个逗号分隔中的值的节点。

clusterroutingallocationrequire{attribute}

仅将分片分配给attribute属性具有所有逗号分隔后的值的节点。

clusterroutingallocationexclude{attribute}

禁止将分片分配给attribute属性具有任何一个逗号分隔后的值的节点。

_name ： 通过节点名字匹配

_ip ： 通过ip地址匹配(与hostname相关联的ip)

_host ： 通过hostname匹配

你可以使用通配符描述属性值，例如：

clusterblocksread_only

将整个群集设为只读（索引不接受写操作），不允许修改元数据（创建或删除索引）。

clusterblocksread_only_allow_delete

与clusterblocksread_only索引相同，但允许删除索引以释放资源

clustermax_shards_per_node

控制每个数据节点在集群中允许的分片数量

……

NDP邻居发现协议用到的ICMPv6报文：

133 路由器请求RS

134 路由器通告RA

135 邻居请求NS

136 邻居通告ND

137 重定向

通过NDP邻居发现协议实现的功能：

1、路由器发现

2、地址自动配置

3、地址解析

4、DAD重复地址检测

5、邻居状态跟踪

6、重定向

补充path-mtu

地址自动配置

通过type 133的ICMPv6报文和type 134的ICMPv6报文实现，type 133的ICMPv6报文称为RS路由器请求，type 134的ICMPv6报文称为RA路由器通告；

PC1连接网线后，会发送RS路由器请求报文，获取地址自动配置所需的前缀信息，源IP地址为未指定地址，目的ip地址为FE02::2,源MAC地址为PC1接口mac地址，目的MAC地址为目的IP地址对应的组播mac地址；

网段上的路由器收到后，发送RA路由器通告应答，源IP地址为路由器接口的link-local地址，目的地址为FF02::1,源MAC地址为路由器接口mac地址，目的mac地址为目的地址对应的组播mac地址，报文内容携带地址前缀信息；

PC1收到后，根据地址前缀信息，软件方式自动生成IPv6地址，同时将路由器的link-local地址作为默认网关；

通过RA路由器通告报文中的M位、O位判断是无状态自动配置，还是有状态自动配置；

无状态自动配置无需DHCPv6服务器，仅能获取前缀生成地址；

有状态自动配置通过DHCPv6服务器，可以为主机分配地址和其他配置信息；

PC1也可以通过无状态自动配置获取前缀生成地址，仅通过有状态自动配置获取其他配置信息；

路由器发现

路由器会周期性（200s）的发送RA路由器通告，通知网段上的主机该网段上的前缀信息和网关；

如果一个网段上有多台路由器，RA路由器通告报文中携带路由器优先级选项，low、medium、high，主机优先级选择优先级高的路由器作为默认网关；如果优先级相同，都作为默认网关；

地址解析

通过type 135的ICMPv6报文和type 136的ICMPv6报文实现，type 135的ICMPv6报文称为NS邻居请求报文，type 136的ICMPv6报文称为NA邻居通告报文；

PC1要访问PC2，需要封装PC2的链路层地址，首先PC1发送NS邻居请求报文，请求PC2的链路层地址，通过type 135的ICMPv6报文实现，源IP为PC1的接口IP地址，目的IP为PC2的接口地址对应的请求组播地址，源MAC为PC1的接口MAC地址，目的MAC为请求组播地址对应的组播mac地址，报文内容部分为想要请求的IPv6地址，即PC2的接口地址，及PC1自身链路层地址；

PC2收到报文后，发送NA邻居通告报文进行响应，通过type 136的ICMPv6报文实现，源IP地址为PC2的接口IP地址，目的IP地址为PC1的接口IP地址，源MAC为PC2的接口MAC地址，目的MAC为PC1的接口MAC地址，报文内容携带请求的IPv6地址（PC2自身接口IP地址），以及对应的链路层地址（PC2接口mac地址）；

DAD重复地址检测

IPv6地址的生存期分为tentative、preferred、valid、invalid几个阶段；

接口开始使用一个IPv6地址时，先进入tentative阶段，发送NS邻居请求报文，探测网段上该地址是否已经被使用，通过type 136的ICMPv6报文实现，源IP为未指定地址，目的IP为想要使用地址的请求组播地址，源MAC为自身MAC地址，目的MAC为请求组播地址对应的组播MAC地址，报文内容携带想要使用的IPv6地址；

如果没有收到NA邻居通告回应，说明网段上该地址未被使用，进入preferred阶段，可以使用该地址进行通信；如果收到NA邻居通告回应，说明网段上该地址已被使用，不会使用该地址进行通信；

邻居状态跟踪

邻居状态跟踪通过type 135的ICMPv6报文和type 136的ICMPv6报文实现，type 134的ICMPv5报文称为NS邻居请求报文，type 136的ICMPv6报文称为NA邻居通告报文；

主机会维护一张IPv6地址到链路层地址的映射表，在主机发送NS邻居请求报文时，会在本地映射表中生存对应的缓存表项，由于还不知道想要请求的IPv6地址对应的链路层地址，将状态标记为incompele；

如果收到NA邻居通告报文，将在本地缓存表得到完整的映射条目，状态标记为Reachable；如果每隔1s，连续发三次NS邻居请求报文，都没收到回应，删除该表项；

状态Reachable的表项超时后（30s），不确定该映射条目是否有效，状态标记为stale；

如果有报文需要向stale状态的IP地址转发，需要先验证表项有效性，发送NS邻居请求报文，状态标记为delay，表示正在验证表项有效性；

如果5s内收到NA邻居通告报文，表示表项有效，状态标记为Reachable；

如果5s内没有收到NA邻居通告报文，说明表项无效，进入probe状态，每隔1s发送一次NS邻居请求报文，连发三次没有收到NA邻居通告响应，删除该表项；如果收到NA邻居通告，则认为邻居有效，进入Reachable状态；

重定向

通过type 137的ICMPv6报文实现

PC1访问R3的地址2001::3,查找路由表默认网关是R2的链路本地地址FE80::2,发送IPv6报文源IP为2000::1，目的IP为2001::3,源MAC为PC1的G0/0/0接口MAC，目的MAC为R2的G0/0/0接口MAC；

R2收到后，根据目的IP地址2001::3查找路由表，发现出接口和收到报文的接口一致，向PC1发送type 137的ICMPv6重定向报文，告知PC1去往2001::3的报文直接向FE80::3转发，重定向报文源IP为FE80::2，目的IP为2000::1，源MAC为R2的G0/0/0接口MAC，目的MAC为PC1的G0/0/0接口MAC；

PC1收到后，后续发往2001::3的报文直接转发给FE80::3;

pathMTU

通过type 2的ICMPv6报文（packet too big差错消息）来实现；

如果PC1有超过MTU1500的报文要发送，会按照MTU1500进行分片；

R2收到后，发现超过自身转发接口的MTU1400，返回type2的ICMPv6报文，告知PC1 packet too big，需要使用MTU 1400来分片，PC1重重新按照MTU1400来分片；

R3收到后，依然会因为报文超过转发接口MTU 1300，而回送type 2的ICMPv6报文，告知PC1 packet too big，需要按照MTU 1300进行分片，PC1重新按照MTU 1300进行分片，最终达到目的地PC2；

如果是IPv4的话，PC1按照MTU1500进行分片；

R2收到报文重组后，按照MTU1400进行分片；

R3收到报文重组后，按照MTU1300进行分片；

Redis数据量日益增大，而且使用的公司越来越多，不仅用于做缓存，同时趋向于存储这块，这样必促使集群的发展，各个公司也在收集适合自己的集群方案，目前行业用的比较多的是下面几种集群架构，大部分都是采用分片技术，解决单实例内存增大带来的一系列问题。

本篇文章简单介绍五种方案：

官方cluster方案

twemproxy代理方案

哨兵模式

codis

客户端分片

官方cluser方案

从redis 30版本开始支持redis-cluster集群，redis-cluster采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他节点连接。redis-cluster是一种服务端分片技术。

redis-cluster架构图

redis-cluster特点：

每个节点都和n-1个节点通信，这被称为集群总线（cluster bus）。它们使用特殊的端口号，即对外服务端口号加10000。所以要维护好这个集群的每个节点信息，不然会导致整个集群不可用，其内部采用特殊的二进制协议优化传输速度和带宽。

redis-cluster把所有的物理节点映射到[0,16383]slot（槽）上，cluster负责维护node--slot--value。

集群预分好16384个桶，当需要在redis集群中插入数据时，根据CRC16(KEY) mod 16384的值，决定将一个key放到哪个桶中。

客户端与redis节点直连，不需要连接集群所有的节点，连接集群中任何一个可用节点即可。

redis-tribrb脚本（rub语言）为集群的管理工具，比如自动添加节点，规划槽位，迁移数据等一系列操作。

节点的fail是通过集群中超过半数的节点检测失效时才生效。

整个cluster被看做是一个整体，客户端可连接任意一个节点进行操作，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点。

为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。如果主节点失效，redis cluster会根据选举算法从slave节点中选择一个上升为master节点，整个集群继续对外提供服务。

twemproxy代理方案

twemproxy代理架构图：

Redis代理中间件twemproxy是一种利用中间件做分片的技术。twemproxy处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后（sharding），再转发给后端真正的redis服务器。也就是说，客户端不直接访问redis服务器，而是通过twemproxy代理中间件间接访问。降低了客户端直连后端服务器的连接数量，并且支持服务器集群水平扩展。

twemproxy中间件的内部处理是无状态的，它本身可以很轻松地集群，这样可以避免单点压力或故障。

twemproxy又称nutcracker，起源于推特系统中redis、memcached集群的轻量级代理。

Github源码地址（https://githubcom/twitter/twemproxy）

从上面架构图看到twemproxy是一个单点，很容易对其造成很大的压力，所以通常会结合keepalived来实现twemproy的高可用。这时，通常只有一台twemproxy在工作，另外一台处于备机，当一台挂掉以后，vip自动漂移，备机接替工作。关于keepalived的用法可自行网上查阅资料。

哨兵模式

Sentinel哨兵

Sentinel（哨兵）是Redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器以及这些主服务器下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

例如:

在Server1掉线后：

升级Server2为新的主服务器：

Sentinel的工作方式

每个Sentinel以每秒钟一次的频率向它所知的Master、Slave以及其他Sentinel实例发送一个PING命令。

如果一个实例距离最后一次有效回复PING命令的时间超过down-after-milliseconds选项所指定的值，则这个实例会被Sentinel标记为主观下线。

如果一个Master被标记为主观下线，则正在监视这个Master的所有Sentinel要以每秒一次的频率确认Master的确进入了主观下线状态。

当有足够数量的Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线。

在一般情况下，每个Sentinel会以每10秒一次的频率向它所知的所有Master、Slave发送INFO命令。

当Master被Sentinel标记为客观下线时，Sentinel向下线的Master的所有Slave发送INFO命令的频率会从10秒一次改为每秒一次。

若没有足够数量的Sentinel同意Master已经下线，Master的客观下线状态就会被移除。若Master重新向Sentinel的PING命令返回有效值，Master的主观下线状态就会被移除。

codis

codis是一个分布式的Redis解决方案，由豌豆荚开源，对于上层的应用来说，连接codis proxy和连接原生的redis server没什么明显的区别，上层应用可以像使用单机的redis一样使用，codis底层会处理请求的转发，不停机的数据迁移等工作，所有后边的事情，对于前面的客户端来说是透明的，可以简单的认为后边连接的是一个内存无限大的redis服务。

客户端分片

分区的逻辑在客户端实现，由客户端自己选择请求到哪个节点。方案可参考一致性哈希，这种方案通常适用于用户对客户端的行为有完全控制能力的场景。

总结：没有最好的方案，只有最合适的方案。

更多Redis相关技术文章，请访问Redis教程栏目进行学习！

IPFS是什么？

IPFS是一种点对点的分布式文件系统，致力于取代HTTP。

IPFS和HTTP之间的区别

安全性：HTTP属于中心化的，所有流量直接搭载在中心化的服务器上，承载的压力极大，容易造成系统崩溃，HTTP还容易遭受DDOS攻击；IPFS的存储方式是去中心化的分片的分布式存储，黑客无法攻击，文件不易丢失，安全有保障。

效率：HTTP依赖中心化服务网络，服务器容易被关闭，服务器上文件也容易被删除，服务器需要24小时开机；IPFS采用P2P网络拓扑，全网域的计算机都可以成为存储节点，就近分布式存储大大提高了网络效率。

成本：HTTP中心化服务器运行，需要较高的维护运行成本，中心化数据库一旦遭受DDOS攻击，或遭受不可抗力损害，所有数据将全部丢失；IPFS极大的降低服务器存储成本，也降低了服务器的带宽成本。

HTTP的客户网络访问绝大部分不是本地化的，有网络延迟，IPFS可以极大的加快网络访问速度，网络访问本地化，体验感会明显提升。

IPFS的使用场景：

作为一个挂载的全局文件系统，挂载在IPFS和IPNS下

作为一个挂载的个人同步文件夹，自动的进行版本管理，发布，以及备份任何的写入

作为一个加密的文件或者数据共享系统

作为所有软件的版本包管理者

作为虚拟机器的根文件系统

作为VM的启动文件系统(在管理程序下)

作为一个数据库：应用可以直接将数据写入MerkleDAG数据模型中，获取所有的版本，缓冲，以及IPFS提供的分配

作为一个linked（和加密的）通信平台

作为一个为大文件的完整性检查CDN（不使用SSL的情况下）

作为一个加密的CDN

在网页上，作为一个webCDN

作为一个links永远存在新的永恒的Web

云计算最初的目标是对资源的管理，管理的主要是计算资源，网络资源，存储资源三个方面。想象你有一大堆的服务器，交换机，存储设备，放在你的机房里面，你最想做的事情就是把这些东西统一的管理起来，最好能达到当别人向你请求分配资源的时候（例如1核1G内存，10G硬盘，1M带宽的机器），能够达到想什么时候要就能什么时候要，想要多少就有多少的状态。

这就是所谓的弹性，俗话说就是灵活性。灵活性分两个方面，想什么时候要就什么时候要，这叫做时间灵活性，想要多少就要多少，这叫做空间灵活性。

物理机显然是做不到这一点的。虽然物理设备是越来越牛了：

服务器用的是物理机，例如戴尔，惠普，IBM，联想等物理服务器，随着硬件设备的进步，物理服务器越来越强大了，64核128G内存都算是普通配置。

网络用的是硬件交换机和路由器，例如思科的，华为的，从1GE到10GE，现在有40GE和100GE，带宽越来越牛。

存储方面有的用普通的磁盘，也有了更快的SSD盘。容量从M，到G，连笔记本电脑都能配置到T，更何况磁盘阵列。所以人们想到的第一个办法叫做虚拟化。所谓虚拟化，就是把实的变成虚的。

物理机变为虚拟机：cpu是虚拟的，内存是虚拟的。

物理交换机变为虚拟交换机：网卡是虚拟的，交换机是虚拟的，带宽也是虚拟的。

物理存储变成虚拟存储：多块硬盘虚拟成一个存储池，从中虚拟出多块小硬盘。

虚拟化很好的解决了上面的三个问题：

人工运维：虚拟机的创建和删除都可以远程操作，虚拟机被玩坏了，删了再建一个分钟级别的。虚拟网络的配置也可以远程操作，创建网卡，分配带宽都是调用接口就能搞定的。

浪费资源：虚拟化了以后，资源可以分配的很小很小，比如1个cpu，1G内存，1M带宽，1G硬盘，都可以被虚拟出来。

隔离性差：每个虚拟机有独立的cpu, 内存，硬盘，网卡，不同虚拟机的应用互不干扰。

在虚拟化阶段，领跑者是VMware，可以实现基本的计算，网络，存储的虚拟化。

当然这个世界有闭源，就有开源，有Windows就有Linux，有iOS就有Andord，有VMware，就有Xen和KVM。在开源虚拟化方面，Citrix的Xen做的不错，后来Redhat在KVM发力不少。

对于网络虚拟化，有Open vSwitch，可以通过命令创建网桥，网卡，设置VLAN，设置带宽。

对于存储虚拟化，对于本地盘，有LVM，可以将多个硬盘变成一大块盘，然后在里面切出一小块给用户。

但是虚拟化也有缺点，通过虚拟化软件创建虚拟机，需要人工指定放在哪台机器上，硬盘放在哪个存储设备上，网络的VLAN

ID，带宽具体的配置，都需要人工指定。所以单单使用虚拟化的运维工程师往往有一个Excel表格，有多少台机器，每台机器部署了哪些虚拟机。所以，一般虚拟化的集群数目都不是特别的大。

为了解决虚拟化阶段的问题，人们想到的一个方式为池化，也就是说虚拟化已经将资源分的很细了，但是对于如此细粒度的资源靠Excel去管理，成本太高，能不能打成一个大的池，当需要资源的时候，帮助用户自动的选择，而非用户指定。所以这个阶段的关键点：调度器Scheduler。

于是VMware有了自己的vCloud。

于是基于Xen和KVM的私有云平台CloudStack，后来Citrix将其收购后开源。

当这些私有云平台在用户的数据中心里面卖的其贵无比，赚的盆满钵满的时候。有其他的公司开始了另外的选择，这就是AWS和Google，开始了公有云领域的探索。

AWS最初就是基于Xen技术进行虚拟化的，并且最终形成了公有云平台。也许AWS最初只是不想让自己的电商领域的利润全部交给私有云厂商吧，于是自己的云平台首先支撑起了自己的业务，在这个过程中，AWS自己严肃的使用了自己的云计算平台，使得公有云平台不是对于资源的配置更加友好，而是对于应用的部署更加友好，最终大放异彩。

公有云的第一名AWS活的很爽，第二名Rackspace就不太爽了，没错，互联网行业嘛，基本上就是一家独大。第二名如何逆袭呢？开源是很好的办法，让整个行业大家一起为这个云平台出力，兄弟们，大家一起上。于是Rackspace与美国航空航天局（NASA）合作创始了开源云平台OpenStack。OpenStack现在发展的和AWS有点像了，所以从OpenStack的模块组成，可以看到云计算池化的方法。

OpenStack包含哪些组件呢？

计算池化模块Nova：OpenStack的计算虚拟化主要使用KVM，然而到底在那个物理机上开虚拟机呢，这要靠nova-scheduler。

网络池化模块Neutron：OpenStack的网络虚拟化主要使用Openvswitch，然而对于每一个Openvswitch的虚拟网络，虚拟网卡，VLAN，带宽的配置，不需要登录到集群上配置，Neutron可以通过SDN的方式进行配置。

存储池化模块Cinder:OpenStack的存储虚拟化，如果使用本地盘，则基于LVM，使用哪个LVM上分配的盘，也是用过scheduler来的。后来就有了将多台机器的硬盘打成一个池的方式Ceph，则调度的过程，则在Ceph层完成。

有了OpenStack，所有的私有云厂商都疯了，原来VMware在私有云市场实在赚的太多了，眼巴巴的看着，没有对应的平台可以和他抗衡。现在有了现成的框架，再加上自己的硬件设备，你可以想象到的所有的IT厂商的巨头，全部加入到社区里面来，将OpenStack开发为自己的产品，连同硬件设备一起，杀入私有云市场。

网易当然也没有错过这次风口，上线了自己的OpenStack集群，网易云基础服务（网易蜂巢）基于OpenStack自主研发了IaaS服务，在计算虚拟化方面，通过裁剪KVM镜像，优化虚拟机启动流程等改进，实现了虚拟机的秒级别启动。在网络虚拟化方面，通过SDN和Openvswitch技术，实现了虚拟机之间的高性能互访。在存储虚拟化方面，通过优化Ceph存储，实现高性能云盘。

但是网易并没有杀进私有云市场，而是使用OpenStack支撑起了自己的应用，仅仅是资源层面弹性是不够的，还需要开发出对应用部署友好的组件。

随着公有云和基于OpenStack的私有云越来越成熟，构造一个成千上万个物理节点的云平台以及不是问题，而且很多云厂商都会采取多个数据中心部署多套云平台，总的规模数量就更加大了，在这个规模下，对于客户感知来说，基本上可以实现想什么时候要什么时候要，想要多少要多少。

云计算解决了基础资源层的弹性伸缩，却没有解决应用随基础资源层弹性伸缩而带来的批量、快速部署问题。比如在双十一期间，10个节点要变成100个节点，如果使用物理设备，再买90台机器肯定来不及，仅仅有IaaS实现资源的弹性是不够的，再创建90台虚拟机，也是空的，还是需要运维人员一台一台地部署。于是有了PaaS层，PaaS主要用于管理应用层。我总结为两部分：一部分是你自己的应用应当自动部署，比如Puppet、Chef、Ansible、

Cloud

Foundry，CloudFormation等，可以通过脚本帮你部署；另一部分是你觉得复杂的通用应用不用部署，比如数据库、缓存等可以在云平台上一点即得。

要么就是自动部署，要么就是不用部署，总的来说就是应用层你也少操心，就是PaaS的作用。当然最好还是都不用去部署，一键可得，所以公有云平台将通用的服务都做成了PaaS平台。另一些你自己开发的应用，除了你自己其他人不会知道，所以你可以用工具变成自动部署。

当然这种部署方式也有一个问题，就是无论Puppet、

Chef、Ansible把安装脚本抽象的再好，说到底也是基于脚本的，然而应用所在的环境千差万别。文件路径的差别，文件权限的差别，依赖包的差别，应用环境的差别，Tomcat、

PHP、

Apache等软件版本的差别，JDK、Python等版本的差别，是否安装了一些系统软件，是否占用了哪些端口，都可能造成脚本执行的不成功。所以看起来是一旦脚本写好，就能够快速复制了，但是环境稍有改变，就需要把脚本进行新一轮的修改、测试、联调。例如在数据中心写好的脚本移到AWS上就不一定直接能用，在AWS上联调好了，迁移到Google

Cloud上也可能会再出问题。

容器是Container，Container另一个意思是集装箱，其实容器的思想就是要变成软件交付的集装箱。集装箱的特点，一是打包，二是标准。

在没有集装箱的时代，假设将货物从A运到B，中间要经过三个码头、换三次船。每次都要将货物卸下船来，摆的七零八落，然后搬上船重新整齐摆好。因此在没有集装箱的时候，每次换船，船员们都要在岸上待几天才能走。

有了集装箱以后，所有的货物都打包在一起了，并且集装箱的尺寸全部一致，所以每次换船的时候，一个箱子整体搬过去就行了，小时级别就能完成，船员再也不能上岸长时间耽搁了。

这是集装箱“打包”、“标准”两大特点在生活中的应用。

部署任何一个应用，也包含很多零零散散的东西，权限，用户，路径，配置，应用环境等！这就像很多零碎地货物，如果不打包，就需要在开发、测试、生产的每个环境上重新查看以保证环境的一致，有时甚至要将这些环境重新搭建一遍，就像每次将货物卸载、重装一样麻烦。中间稍有差池，都可能导致程序的运行失败。

那么容器如何对应用打包呢？还是要学习集装箱，首先要有个封闭的环境，将货物封装起来，让货物之间互不干扰，互相隔离，这样装货卸货才方便。

封闭的环境主要使用了两种技术，一种是看起来是隔离的技术，称为namespace，也即每个namespace中的应用看到的是不同的IP地址、用户空间、程号等。另一种是用起来是隔离的技术，称为cgroup，也即明明整台机器有很多的CPU、内存，而一个应用只能用其中的一部分。

有了这两项技术，集装箱的铁盒子我们是焊好了，接下来就是如何将这个集装箱标准化，从而在哪艘船上都能运输。这里的标准一个是镜像，一个是容器的运行环境。

所谓的镜像，就是将你焊好集装箱的那个时刻，将集装箱的状态保存下来，就像孙悟空说定，集装箱里面就定在了那一刻，然后将这一刻的状态保存成一系列文件。这些文件的格式是标准的，谁看到这些文件，都能还原当时定住的那个时刻。将镜像还原成运行时的过程（就是读取镜像文件，还原那个时刻的过程）就是容器的运行的过程。

有了容器，云计算才真正实现了应用层和资源层的完全弹性。

在云计算的发展过程中，云计算逐渐发现自己除了资源层面的管理，还能够进行应用层面的管理，而大数据应用作为越来越重要的应用之一，云计算也可以放入PaaS层管理起来，而大数据也发现自己越来越需要大量的计算资源，而且想什么时候要就什么时候要，想要多少就要多少，于是两者相遇，相识，相知，走在了一起。

说到大数据，首先我们来看一下数据的分类，我们生活中的数据总体分为两种： 结构化数据和非结构化数据。

结构化数据：指具有固定格式或有限长度的数据，如数据库，元数据等。

非结构化数据：指不定长或无固定格式的数据，如邮件， word 文档等

当然有的地方还会提到第三种，半结构化数据，如 XML， HTML 等，当根据需要可按结构化数据来处理，也可抽取出纯文本按非结构化数据来处理。

随着互联网的发展，非结构化数据越来越多，当我们遇到这么多数据的时候，怎么办呢？分为以下的步骤：

数据的收集：即将散落在互联网世界的数据放到咱们的系统中来。数据收集分两个模式，推和拉，所谓的推，即推送，是在互联网世界里面放很多自己的小弟程序，这些小弟程序收集了数据后，主动发送给咱们的系统。所谓的拉，即爬取，通过运行程序，将互联网世界的数据下载到咱们的系统中。

数据的传输：收到的数据需要通过一个载体进行传输，多采用队列的方式，因为大量的数据同时过来，肯定处理不过来，通过队列，让信息排好队，一部分一部分的处理即可。

数据的存储：好不容易收集到的数据，对于公司来讲是一笔财富，当然不能丢掉，需要找一个很大很大的空间将数据存储下来。

数据的分析：收到的大量的数据，里面肯定有很多的垃圾数据，或者很多对我们没有用的数据，我们希望对这些数据首先进行清洗。另外我们希望挖掘出数据之间的相互关系，或者对数据做一定的统计，从而得到一定的知识，比如盛传的啤酒和尿布的关系。

数据的检索和挖掘：分析完毕的数据我们希望能够随时把我们想要的部分找出来，搜索引擎是一个很好的方式。另外对于搜索的结果，可以根据数据的分析阶段打的标签进行分类和聚类，从而将数据之间的关系展现给用户。

当数据量很少的时候，以上的几个步骤其实都不需要云计算，一台机器就能够解决。然而量大了以后，一台机器就没有办法了。

所以大数据想了一个方式，就是聚合多台机器的力量，众人拾柴火焰高，看能不能通过多台机器齐心协力，把事情很快的搞定。

对于数据的收集，对于IoT来讲，外面部署这成千上万的检测设备，将大量的温度，适度，监控，电力等等数据统统收集上来，对于互联网网页的搜索引擎来讲，需要将整个互联网所有的网页都下载下来，这显然一台机器做不到，需要多台机器组成网络爬虫系统，每台机器下载一部分，同时工作，才能在有限的时间内，将海量的网页下载完毕。开源的网络爬虫大家可以关注一下Nutch。

对于数据的传输，一个内存里面的队列肯定会被大量的数据挤爆掉，于是就产生了Kafka这样基于硬盘的分布式队列，也即kafka的队列可以多台机器同时传输，随你数据量多大，只要我的队列足够多，管道足够粗，就能够撑得住。

当数据量非常大的时候，一个索引文件已经不能满足大数据量的搜索，所以要分成多台机器一起搜索，如图所示，将索引分成了多个shard也即分片，分不到不同的机器上，进行并行的搜索。

所以说大数据平台，什么叫做大数据，说白了就是一台机器干不完，大家一起干。随着数据量越来越大，很多不大的公司都需要处理相当多的数据，这些小公司没有这么多机器可怎么办呢？

于是大数据人员想起来想要多少要多少，想什么时候要什么时候要的云平台。空间的灵活性让大数据使用者随时能够创建一大批机器来计算，而时间的灵活性可以保证整个云平台的资源，不同的租户你用完了我用，我用完了他用，大家都不浪费资源。

于是很多人会利用公有云或者私有云平台部署大数据集群，但是完成集群的部署还是有难度的，云计算的人员想，既然大家都需要，那我就把他集成在我的云计算平台里面，当大家需要一个大数据平台的时候，无论是Nutch,

Kafka，hadoop，ElasticSearch等，我能够马上给你部署出来一套。我们管这个叫做PaaS平台。

大数据平台于是作为PaaS融入了云计算的大家庭。

作为国内最早诞生的互联网公司之一，网易在过去十余年的产品研发、孵化和运维过程中，各个部门对数据有着不同且繁杂的需求。而如何把这些繁杂的需求用统一的手段来解决，网易在大数据分析方面同样进行了十余年的探索，并自去年开始通过“网易云”将这些能力开放出来

“网易猛犸”与“网易有数”两大数据分析平台就是在这个阶段逐渐成型的。

网易猛犸大数据平台可以实现从各种不同数据源提取数据，同步到内核存储系统，同时对外提供便捷的操作体验。现在每天约有130亿条数据进入网易猛犸平台，经过数据建模和清洗，进行数据分析预测。

网易的另一大数据分析平台，网易有数则可以极大简化数据探索，提高数据可视化方面的效率，提供灵活报表制作等，以帮助分析师专注于自己的工作内容。

有了大数据平台，对于数据的处理和搜索已经没有问题了，搜索引擎着实火了一阵，当很多人觉得搜索引擎能够一下子帮助用户搜出自己想要的东西的时候，还是非常的开心的。

但是过了一阵人们就不满足于信息仅仅被搜索出来了。信息的搜索还是一个人需要适应机器的思维的过程，要想搜到想要的信息，有时候需要懂得一些搜索或者分词的技巧。机器还是没有那么懂人。什么时候机器能够像人一样懂人呢，我告诉机器我想要什么，机器就会像人一样的体会，并且做出人一样的反馈，多好啊。

这个思想已经不是一天两天了，在云计算还不十分兴起的时候，人们就有了这样的想法。那怎么做的这件事情呢？

人们首先想到的是，人类的思维方式有固有的规律在里面，如果我们能够将这种规律表达出来，告诉机器，机器不就能理解人了吗？

人们首先想到的是告诉计算机人类的推理能力，在这个阶段，人们慢慢的能够让机器来证明数学公式了，多么令人欣喜的过程啊。然而，数学公式表达相对严谨的，推理的过程也是相对严谨，所以比较容易总结出严格个规律来。然而一旦涉及到没有办法那么严谨的方面，比如财经领域，比如语言理解领域，就难以总结出严格的规律来了。

看来仅仅告知机器如何推理还不够，还需要告诉机器很多很多的知识，很多知识是有领域的，所以一般人做不来，专家可以，如果我们请财经领域的专家或者语言领域的专家来总结规律，并且将规律相对严格的表达出来，然后告知机器不就可以了么？所以诞生了一大批专家系统。然而专家系统遭遇的瓶颈是，由人来把知识总结出来再教给计算机是相当困难的，即便这个人是专家。

于是人们想到，看来机器是和人完全不一样的物种，干脆让机器自己学习好了。机器怎么学习呢？既然机器的统计能力这么强，基于统计学习，一定能从大量的数字中发现一定的规律。

其实在娱乐圈有很好的一个例子，可见一斑

有一位网友统计了知名歌手在大陆发行的 9 张专辑中 117 首歌曲的歌词，同一词语在一首歌出现只算一次，形容词、名词和动词的前十名如下表所示（词语后面的数字是出现的次数）：

如果我们随便写一串数字，然后按照数位依次在形容词、名词和动词中取出一个词，连在一起会怎么样呢？

例如取圆周率 31415926，对应的词语是：坚强，路，飞，自由，雨，埋，迷惘。稍微连接和润色一下：

坚强的孩子，

依然前行在路上，

张开翅膀飞向自由，

让雨水埋葬他的迷惘。

是不是有点感觉了？当然真正基于统计的学习算法比这个简单的统计复杂的多。

然而统计学习比较容易理解简单的相关性，例如一个词和另一个词总是一起出现，两个词应该有关系，而无法表达复杂的相关性，并且统计方法的公式往往非常复杂，为了简化计算，常常做出各种独立性的假设，来降低公式的计算难度，然而现实生活中，具有独立性的事件是相对较少的。

于是人类开始从机器的世界，反思人类的世界是怎么工作的。

人类的脑子里面不是存储着大量的规则，也不是记录着大量的统计数据，而是通过神经元的触发实现的，每个神经元有从其他神经元的输入，当接收到输入的时候，会产生一个输出来刺激其他的神经元，于是大量的神经元相互反应，最终形成各种输出的结果。例如当人们看到美女瞳孔放大，绝不是大脑根据身材比例进行规则判断，也不是将人生中看过的所有的美女都统计一遍，而是神经元从视网膜触发到大脑再回到瞳孔。在这个过程中，其实很难总结出每个神经元对最终的结果起到了哪些作用，反正就是起作用了。

于是人们开始用一个数学单元模拟神经元

这个神经元有输入，有输出，输入和输出之间通过一个公式来表示，输入根据重要程度不同(权重)，影响着输出。

于是将n个神经元通过像一张神经网络一样连接在一起，n这个数字可以很大很大，所有的神经元可以分成很多列，每一列很多个排列起来，每个神经元的对于输入的权重可以都不相同，从而每个神经元的公式也不相同。当人们从这张网络中输入一个东西的时候，希望输出一个对人类来讲正确的结果。例如上面的例子，输入一个写着2的，输出的列表里面第二个数字最大，其实从机器来讲，它既不知道输入的这个写的是2，也不知道输出的这一系列数字的意义，没关系，人知道意义就可以了。正如对于神经元来说，他们既不知道视网膜看到的是美女，也不知道瞳孔放大是为了看的清楚，反正看到美女，瞳孔放大了，就可以了。

对于任何一张神经网络，谁也不敢保证输入是2，输出一定是第二个数字最大，要保证这个结果，需要训练和学习。毕竟看到美女而瞳孔放大也是人类很多年进化的结果。学习的过程就是，输入大量的，如果结果不是想要的结果，则进行调整。如何调整呢，就是每个神经元的每个权重都向目标进行微调，由于神经元和权重实在是太多了，所以整张网络产生的结果很难表现出非此即彼的结果，而是向着结果微微的进步，最终能够达到目标结果。当然这些调整的策略还是非常有技巧的，需要算法的高手来仔细的调整。正如人类见到美女，瞳孔一开始没有放大到能看清楚，于是美女跟别人跑了，下次学习的结果是瞳孔放大一点点，而不是放大鼻孔。

听起来也没有那么有道理，但是的确能做到，就是这么任性。

神经网络的普遍性定理是这样说的，假设某个人给你某种复杂奇特的函数，f(x)：

不管这个函数是什么样的，总会确保有个神经网络能够对任何可能的输入x，其值f(x)（或者某个能够准确的近似）是神经网络的输出。

如果在函数代表着规律，也意味着这个规律无论多么奇妙，多么不能理解，都是能通过大量的神经元，通过大量权重的调整，表示出来的。

这让我想到了经济学，于是比较容易理解了。

我们把每个神经元当成社会中从事经济活动的个体。于是神经网络相当于整个经济社会，每个神经元对于社会的输入，都有权重的调整，做出相应的输出，比如工资涨了，菜价也涨了，股票跌了，我应该怎么办，怎么花自己的钱。这里面没有规律么？肯定有，但是具体什么规律呢？却很难说清楚。

基于专家系统的经济属于计划经济，整个经济规律的表示不希望通过每个经济个体的独立决策表现出来，而是希望通过专家的高屋建瓴和远见卓识总结出来。专家永远不可能知道哪个城市的哪个街道缺少一个卖甜豆腐脑的。于是专家说应该产多少钢铁，产多少馒头，往往距离人民生活的真正需求有较大的差距，就算整个计划书写个几百页，也无法表达隐藏在人民生活中的小规律。

基于统计的宏观调控就靠谱的多了，每年统计局都会统计整个社会的就业率，通胀率，GDP等等指标，这些指标往往代表着很多的内在规律，虽然不能够精确表达，但是相对靠谱。然而基于统计的规律总结表达相对比较粗糙，比如经济学家看到这些统计数据可以总结出长期来看房价是涨还是跌，股票长期来看是涨还是跌，如果经济总体上扬，房价和股票应该都是涨的。但是基于统计数据，无法总结出股票，物价的微小波动规律。

基于神经网络的微观经济学才是对整个经济规律最最准确的表达，每个人对于从社会中的输入，进行各自的调整，并且调整同样会作为输入反馈到社会中。想象一下股市行情细微的波动曲线，正是每个独立的个体各自不断交易的结果，没有统一的规律可循。而每个人根据整个社会的输入进行独立决策，当某些因素经过多次训练，也会形成宏观上的统计性的规律，这也就是宏观经济学所能看到的。例如每次货币大量发行，最后房价都会上涨，多次训练后，人们也就都学会了。

然而神经网络包含这么多的节点，每个节点包含非常多的参数，整个参数量实在是太大了，需要的计算量实在太大，但是没有关系啊，我们有大数据平台，可以汇聚多台机器的力量一起来计算，才能在有限的时间内得到想要的结果。

于是工智能程序作为SaaS平台进入了云计算。

网易将人工智能这个强大的技术，应用于反垃圾工作中，从网易1997年推出邮箱产品开始，我们的反垃圾技术就在不停的进化升级，并且成功应用到各个亿量级用户的产品线中，包括影音娱乐，游戏，社交，电商等产品线。比如网易新闻、博客相册、云音乐、云阅读、有道、BOBO、考拉、游戏等产品。总的来说，反垃圾技术在网易已经积累了19年的实践经验，一直在背后默默的为网易产品保驾护航。现在作为云平台的SaaS服务开放出来。

回顾网易反垃圾技术发展历程，大致上我们可以把他分为三个关键阶段，也基本对应着人工智能发展的三个时期：

第一阶段主要是依赖关键词，黑白名单和各种过滤器技术，来做一些内容的侦测和拦截，这也是最基础的阶段，受限于当时计算能力瓶颈以及算法理论的发展，第一阶段的技术也能勉强满足使用。

第二个阶段时，基于计算机行业里有一些更新的算法，比如说贝叶斯过滤(基于概率论的算法)，一些肤色的识别，纹理的识别等等，这些比较优秀成熟的论文出来，我们可以基于这些算法做更好的特征匹配和技术改造，达到更优的反垃圾效果。

最后，随着人工智能算法的进步和计算机运算能力的突飞猛进，反垃圾技术进化到第三个阶段：大数据和人工智能的阶段。我们会用海量大数据做用户的行为分析，对用户做画像，评估用户是一个垃圾用户还是一个正常用户，增加用户体验更好的人机识别手段，以及对语义文本进行理解。还有基于人工智能的图像识别技术，更准确识别是否是色情，广告以及一些违禁品等等。

服务的无状态化就是冗余部署的多个服务模块(进程)，使其完全对等。也就是部署多个相同服务，请求到任一服务的处理结果是一样的。这些模块不存储业务的上下文信息，比如session、登录、业务上下文相关的信息。只会根据每次请求携带的数据进行相应的业务处理。

实质这些业务相关的信息是会存放在统一的一个地方，比如缓存、es等等。

1快速扩容

2弹性扩容

登录的基本信息，登录后的基本信息:用户凭证，AES、JWT进行加密等。

由于业务量大，需要部署多台服务器构成应用集群，这时候请求一般经过DNS，进入网关层，通过负载均衡算法，分配到不同的服务上，业务的上下文数据在不同的服务器上，是无法同步的。因此我们做无状态化设计，考虑的就是用户的session数据如何存放。

用户session数据存放:

分析

直接存放在网关层的话，就是类似一个单点登录的，这时候网关层是有状态的。单点，不高可用，有状态，不太好。

优化:

做集群，同步数据，全量。

特点：

1保证高可用。

2有状态化

这时候还是有状态，如果其中一台机器挂了，还未同步到另外两台，信息还是会丢失。同时，还要解决复杂的全量同步数据问题。

满足:

用户Session数据外部存储

特点:

类似使用redis做分片以及集群。

标志字段中的最低位记为MF （More Fragment）。MF＝1即表示后面“还有分片 ”的数据报。MF＝0表示这已是若干数据报片中的最后一个。

标志字段中间的一位记为DF （Don't Fragment），意思是“不能分片 ”。只有当DF＝0时才允许分片。

TCP最初只规定了一种选项，即最大报文段长度 MSS（Maximum Segment Size）［RFC 879］。请注意MSS这个名词的含义。MSS是每一个TCP报文段中的数据字段的最大长度 。数据字段加上TCP首部才等于整个的TCP报文段。所以MSS并不是整个TCP报文段的最大长度，而是“TCP报文段长度减去TCP首部长度”。

假定主机A运行的是TCP客户程序，而B运行TCP服务器程序。最初两端的TCP进程都处于CLOSED（关闭）状态。图中在主机下面的方框分别是TCP进程所处的状态。请注意，在本例中，A主动打开连接 ，而B被动打开连接 。

一开始，B的TCP服务器进程先创建传输控制块 TCB (15) ，准备接受客户进程的连接请求。然后服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。如有，即作出响应。

A的TCP客户进程也是首先创建传输控制模块 TCB。然后，在打算建立TCP连接时，向B发出连接请求报文段，这时首部中的同步位SYN＝1， ACK=0 同时选择一个初始序号seq＝x。TCP规定，SYN报文段（即SYN＝1的报文段）不能携带数据，但要消耗掉一个序号 。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。

B收到连接请求报文段后，如同意建立连接，则向A发送确认。在确认报文段中应把SYN位和ACK位都置1，确认号是ack＝x＋1，同时也为自己选择一个初始序号seq＝y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号 。这时TCP服务器进程进入SYN-RCVD（同步收到）状态。

TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号ack＝y＋1，而自己的序号seq＝x＋1。TCP的标准规定，ACK报文段可以携带数据。但如果不携带数据则不消耗序号 ，在这种情况下，下一个数据报文段的序号仍是seq＝x＋1。这时，TCP连接已经建立，A进入ESTABLISHED（已建立连接）状态。

当B收到A的确认后，也进入ESTABLISHED状态。

B收到连接释放报文段后即发出确认，确认号是ack＝u＋1，而这个报文段自己的序号是v，等于B前面已传送过的数据的最后一个字节的序号加1。然后B就进入CLOSE-WAIT（关闭等待）状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时的TCP连接处于半关闭 （half-close）状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一段时间。

A收到来自B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。

若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN＝1。现假定B的序号为w（在半关闭状态B可能又发送了一些数据）。B还必须重复上次已发送过的确认号ack＝u＋1。这时B就进入LAST-ACK（最后确认）状态，等待A的确认。

A在收到B的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK置1，确认号ack＝w＋1，而自己的序号是seq＝u＋1（根据TCP标准，前面发送过的FIN报文段要消耗一个序号）。然后进入到TIME-WAIT（时间等待）状态。请注意，现在TCP连接还没有释放掉。必须经过时间等待计时器 （TIME-WAIT timer）设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命 （Maximum Segment Lifetime），RFC 793建议设为2分钟。但这完全是从工程上来考虑的，对于现在的网络，MSL＝2分钟可能太长了一些。因此TCP允许不同的实现可根据具体情况使用更小的MSL值。因此，从A进入到TIME-WAIT状态后，要经过4分钟才能进入到CLOSED状态，才能开始建立下一个新的连接。当A撤销相应的传输控制块TCB后，就结束了这次的TCP连接。

第一，为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN＋ACK报文段的确认。B会超时重传这个FIN＋ACK报文段，而A就能在2MSL时间内收到这个重传的FIN＋ACK报文段。接着A重传一次确认，重新启动2MSL计时器。最后，A和B都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN＋ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常步骤进入CLOSED状态。

第二，防止上一节提到的“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

B只要收到了A发出的确认，就进入CLOSED状态。同样，B在撤销相应的传输控制块TCB后，就结束了这次的TCP连接。我们注意到，B结束TCP连接的时间要比A早一些。

1

软件的兼容问题：

据网络调查发现，win7的IE浏览器跟迅雷软件存在不兼容的问题，卸掉迅雷就会变好。

因为我的IE是系统自带的，所以出现这种情况少。

1

重置浏览器：

右击浏览器——属性——再选择那个高级——点击下面的那个重置，即可。

1

重新设置主页：

我之前将百度设置为主页的，然后进入百度任何一个网页就会出现“无响应”的情况，后来将hao123设置成主页，再回到百度浏览其他的，再也没有出现无响应的情况。

具体方法：通过您的主页，进入如hao123类似的网站导航，将它设置成主页，再回去打开你出现无响应页面的，看是否好了。

希望我的方法能对您有用，谢谢了！