Android 网络编程相关的包 : 9 包, 20 接口, 103 类, 6 枚举, 14异常; -- Java包 : java.net 包 (6接口, 34类, 2枚举, 12异常);-- Android包 : android.net 包 (1接口, 19类, 3枚举, 1异常), android.net.http 包 (6类), android.net.nsd 包 (3接口, 2类), android.net.rtp (4类), android.net.sip 包 (1接口, 9类, 1异常), android.net.wifi 包 (16类, 1枚举), android.net.wifi.p2p 包 (9接口, 7类), android.net.wifi.p2p.nsd 包 (6类);一. 权限相关类1. Authenticator类的全名称 : public abstract class Authenticator extends Object-- 作用 : 获取网络链接验证对象;-- 使用方法 : 当需要获取一个带 口令 保护的文件的时候, 需要使用 用户名 和 密码 才能获取该文件的输入流, 如果遇到这种情况, 提示用户输入用户名 密码获取文件;使用流程1> 获取用户名密码关键方法 : protected PasswordAuthentication getPasswordAuthentication()-- 重写方法 : 重写该方法, 在该方法中调用 该类中的其它方法, 获取关于请求验证的信息; -- 用户输入 : 然后写一个 用户名密码输入框, 弹出该输入框, 通过用户输入获取用户名密码;-- 返回结果 : 根据用户输入的 口令 密码 以及上面获取的请求验证信息, 返回 PasswordAuthentication 对象;2> 验证验证流程 :-- 注册验证类实例 : 调用 setDefault(Authenticator) 方法向系统注册实例;-- 验证 : 调用 requestPasswordAuthentication()方法;public static void setDefault(Authenticator a)-- 作用 : 设置 代理 或者 HTTP服务器 请求校验时 密码使用的 authenticator; public static PasswordAuthentication requestPasswordAuthentication(InetAddress addr, int port, String protocol, String prompt, String scheme)-- 作用 : 要求向系统注册的 authemticator 提供密码;-- 参数 : addr 请求授权站点的 InetAddress, port 请求链接端口, protocol 请求连接的协议, prompt 用户提示的字符串, scheme 验证方案;2. PasswordAuthentication类的全名称 : public final class PasswordAuthentication extends Object-- 作用 : 该类保存 Authenticator 使用的 用户名 和 密码;构造方法 : public PasswordAuthentication(String userName, char[] password)-- 用法 : 根据传入的用户名 和 密码创建 PasswordAuthentication 对象;获取用用户名密码的方法 : -- 获取用户名方法 : public String getUserName() ;-- 获取密码方法 : public char[] getPassword() ;3. NetPermission类的全名称 : public final class NetPermission extends BasicPermission-- 作用 : 用于各种网络权限, 包含一个名称, 没有动作列表;权限解析 : 每个权限都有一个权限名称, 所允许的操作, 以及对应的风险;-- setDefaultAuthenticator : 设置代理 或 HTTP 服务器请求验证, 获取验证信息的方式;-- requestPasswordAuthentication : 设置 在系统中注册的 authenticator 可以提供密码;-- specifyStreamHandler : 构造 URL 时指定流处理程序;-- setProxySelector : 设置 建立网络连接时使用代理的 代理选择器;-- getProxySelector : 获取 建立网络连接时使用代理的 代理选择器;-- setCookieHandler : 设置 HTTP会话处理高度安全敏感的cookie 的 cookie 处理程序;-- getCookieHandler : 获取 HTTP会话处理高度安全敏感的cookie 的 cookie 处理程序;-- setResponseCache : 设置 本地响应缓存的访问权限;-- getResponseCache : 获取 本地响应缓存的访问权限;.二. 地址相关类 1. InetAddress类的全名称 : public class InetAddress extends Object implements Serializable作用 : 代表 IP 地址;IP地址层级 : IP地址是一种低级的协议, UDP 和 TCP 都是在这个协议的基础上构建;IP地址类型 : -- 单播地址 : 用于当作单个接口标识符, 发送到单播地址的数据包 被发送到 由该地址标识的接口;-- 多播地址 : 用于当作一组接口的标识符, 发送到多播地址的数据包被交付给由地址标识的所有接口;-- 回送地址 : 分配给回送接口的地址, 发送到回送地址的任何内容, 都将当作本地主机的IP输入, 通常在测试客户机的时候使用这种类型的地址;多播地址的注意事项 : 不能将多播地址分配给任何节点, 它是 anylocal 地址 或者 通配符地址, 服务器主机有多个接口的情况下接收任何接口上的客户端链接;IP地址范围 : -- 链接本地地址 : 在单个链接上寻址, 以解决诸如自动地址配置, 邻居发现, 或者没有路由器的问题; -- 站点本地地址 : 不许要全局前缀时, 站点内部寻址; -- 全局地址 : Internet中唯一的地址; IP地址文本表现形式 : 有 IPv4 IPv6 两种格式;主机名解析 : -- 主机名到IP地址解析 : 使用 本地配置信息 和 网络命名服务 实现, 特定命名服务默认情况下 是本地机器配置的;-- 反向名称解析 : 返回IP地址对应的主机名;InetAddress 缓存 : 存储 主机名解析, 不管成功还是失败;-- 默认缓存 : 正确解析的主机名 解析结果会永久保存, 如果解析失败 该记录只保存10秒;-- 正主机名解析缓存 : 使用 networkaddress.cache.ttl 成功解析的缓存策略, 用于设置java安全属性设置为另外的 TTL 值进行正缓存;-- 负主机名解析缓存 : 使用 networkaddress.cache.negative.ttl 解析主机名失败的缓存策略;2. Inet4Address 类的全名称 : public final class Inet4Address extends InetAddress-- 作用 : 表示 IPv4 地址;IP地址文本表示形式 : -- 指定4部分 : d.d.d.d , 每个部分都是一个字节数据, 从左到右 分配给 IPv4 四个字节;-- 指定3部分 : d.d.d , 最后一部分是2个字节, 放在最右边的网络地址上;-- 指定2部分 : d.d , 最后一部份是3个字节, 放在最右边的三个字节上;-- 指定1部分 : d , 直接存储在网络地址中, 字节不用重新排列;多播地址范围 : IPv4 生存时间 (Time-to-live) 作为多播范围字段库增加一倍;-- TTL = 0 : 表示节点本地;-- TTL = 1 : 表示链接本地;-- TTL = 32 : 表示站点本地;-- TTL = 64 : 表示地区本地;-- TTL = 128 : 表示大陆本地;-- TTL = 255 : 表示全球;3. Inet6Address类的全名称 : public final class Inet6Address extends InetAddress-- 作用 : 代表 IPv6 地址;

本文内容来自学霸君资深架构师袁荣喜的技术分享。 1、前言 实时视频直播经过去年的千播大战后已经成为互联网应用的标配技术，但直播平台的成本却一直居高不下，各个平台除了挖主播、挖网红以外，其背后高额的带宽费用也是他们最大的一块成本。 现阶段直播技术在传输方面分为两块： CDN ：负责流媒体的分发传输； 连麦系统：负责解决同时多个主播间互动的实时通信传输问题。 我们始终认为基于 CDN+ 连麦系统的直播技术是一个高成本高消耗的技术，从各大直播平台纷纷亏损来看就验证了这一点。除了带宽成本，延迟问题也是现在直播技术的一个硬伤。我们很早就意识到现在这种传统的直播技术是无法大规模进行在线教育互动直播的，所以学霸君从 2016 年下半年就开始研发基于 UDP 和 P2P 技术的互动直播系统。 整个系统的设计目标是： 端到端延迟控制在秒级范围之内； 在不影响视频质量的情况下尽力节省分发带宽。 基于 P2P 技术的整个分发架构在一个 10W+ 直播平台上进行了 9 个月的测试和调优，初步达成了设计目标。 那整个系统是怎么设计的？使用了哪些技术来达成目标？接下来我来重点分享一下架构设计和技术细节。 （本文同步发布于：http://www.52im.net/thread-1289-1-1.html） 2、分享者介绍 袁荣喜：学霸君资深架构师，2015年加入学霸君，负责学霸君的网络实时传输和分布式系统的架构设计和实现，专注于基础技术领域，在网络传输、数据库内核、分布式系统和并发编程方面有一定了解。 3、基于P2P的实时视频直播分发网络架构 3.1 基本架构 传输分发网络中我们把连麦系统和分发系统合二为一，将分布式推流与边缘节点分发作为一套传输体系，通过服务之间的 P2P 通信和路由选择来实现连麦的最小时延。 架构如下图： 整个传输分发网络分为三部分： 推流部分； 服务之间 P2P； 客户节点 P2P。 这个传输网络有一个系统锚点：假定推流者 speaker 推到 Edge server 上是不会发生丢包和延迟的，Edge server 会通过服务间 P2P 快速将收到的流数据分发到其他的 Edge server，而且在这个过程也不会发生延迟和丢包。 为什么需要这样一个锚点？因为在客户节点的 P2P 网络需要保证流畅性和最小延迟，也就是要求所有的 Edge server 在最短时间周期内拥有完整的数据，至于为什么要这样，后面我们在流补偿环节重点介绍。 我将通过整个流数据传输过程来解析具体的技术细节，但在这之前首先要解决的就是媒体数据分片问题，所有的传输过程会基于分片 (segment) 来设计。 3.2 媒体数据分片 媒体数据分片是整个分发传输系统中最为基础的部分，我们在设计分片时主要考虑的是时延和消耗的问题，分片如果太大，传输的时延就会越高，例如 HLS；如果分片太细，网络中回馈报文就会很多，对 P2P 网络来说额外的消耗也是个问题。 最后我们借鉴了 RTP 和 FLV 中的经验，采用按帧来做数据分片，这样做有以下几个好处： 按帧分片延迟粒度小，可以在帧传输进行延时优化； 实现简单，与编解码器编码原则一致； 组合灵活，可以实现播放 buffer 无缝结合。 每一个分片称作为 segment，用一个自增长的 32 位 ID 来表示唯一性，传输过程都是以这个 ID 为标示来确定数据的完整性。 3.3 推流与连麦 确定好了媒体分片就可以进行推流了，我们把推流和分发的路径合二为一，上麦者是将流数据 segment 推送到离自己最近的 Edge server 上，而不是推送到专门的连麦系统上。我们推流传输使用的是 RUDP 传输算法，这个 RUDP 是采用了类似 BBR 基于延迟和丢包来设计的拥塞算法，并且对报文做了拥塞丢弃。 示意图如下： 关于 RUDP 的细节可以参考我的另一篇文章《怎么让不可靠的UDP可靠？》。至于为什么不采用 RTP 或者 RTMP/TCP 来推流，因为 RTP 虽然是基于 UDP 的，但需要通过 RTCP 和 NACK 来保证可靠性，需要设计拥塞算法，也需要对 RTP 进行改造扩展，而且还受 RTP 协议本身的限制，所以我们并没有直接采用 RTP。使用 RTMP/TCP 来设计是很简单的，但在弱网环境延迟很大，而且容易引起重连，所以在设计之初也否定了。 3.4 Server 间的 P2P 因为整个传输分发网络是分布式的，由多个 Edge server 组成，所以基于系统锚点，媒体数据分片到 Edge server 上必须尽快分发到其他 Edge server 上。最早我们是统一用 BGP server 来中转，这样耗费的 BGP 带宽很多，而且 BGP server 一旦异常，整个 Edge server 之间的通信就中断了。 其实大部分时间跨运营商的 Edge server 之间延迟也没有想象的那么大，这可以考虑使用 Edge server 之间点对点通信来解决问题，所以我们设计了一个基于 RUDP 无窗口多路径的传输模型来进行 Edge server 之间的通信，如下图： 上图的通信模型是一个多路径并联通信模型，我们在 RUDP 发送前添加了一个路径路由表，这个路由表记录了各个路径的分发概率，RUDP 每次向接收端发送包时会通过路由表中的概率来选取路径。那么确定路由表概率就是一个非常重要的事情。我们通过 RUDP 实时 ACK 反馈和路径实时 ping 探测来得到网络的状态 (丢包、延迟、抖动)，再将网络状态参数输入到逼近函数 f(x) 来确定各条路由的概率，这里有条原则：如果 Edge server 之间直连的延迟和丢包足够小的情况下，直连通信路由的概率将会接近 100%，如果某一条路由出现周期性断开或者延迟超过 200ms，它的概率会接近 0。 以下是整个路由概率评估的过程示意图： 4、基于P2P的实时视频直播网络构建过程 媒体流数据通过 Edge server 间的 P2P 多路径传输网络到达各个 Edge server 上，接下来每个 Edge server 需要将流数据分片下发到各个客户节点上，我们针对上麦节点做了传输特殊处理让时延更小，过程和普通的 RTC 通信模型相似，这里就不赘述了。观看节点上分发采用自组织 P2P 网络，既然是通过 P2P 下发的，那么就要在客户节点群构建一个 P2P 网络，这个网络是怎么构建的？具体分为三步：连接、评估、分层。 4.1 连接 客户节点程序是运行在客户机上的，大部分客户节点都会在路由器或者 NAT 后面，他们之间要相互建立连接，必须穿越彼此的 NAT 和防火墙。虽然现在穿越 NAT 的方法有很多，如 STUN、ICE 等，但穿越连通率始终是一个问题，如果穿越率太低，会让很多优质的节点资源得不到充分利用。 在设计穿越方案时我们将直连连通率放在第一位，通过修改 STUN 协议设计了一种基于端口多次猜测和尝试的穿越机制。首先通过类似 STUN 协议判断 NAT 类型、NAT 端口变化规律、NAT 是否有黑名单机制等信息，然后将这些信息存到辖区连接中的 Edge server 中，当有伙伴节点来与它穿越，会交换彼此的这些信息，不同的排列组合会有不同的穿越策略，每一次穿越的过程和结果都会记录到我们的后台数据库，我们会周期性地将这些数据进行分析并调整协商穿越策略。如下图： 穿越完成后，节点之间就会进行连接握手和身份证书认证（关于为什么要证书后面细讲），建立通信联系和邻居关系。那么邻居关系是怎么动态变化的呢？ 4.2 邻居关系与评估 【邻居问题】： 连接一旦完成，节点与节点之间就成为邻居，彼此会进行状态交换和心跳，那么问题来了，一个直播系统有成千上万的节点参与，如果都两两相连的话光心跳通信就可以将客户节点的上传带宽占满。我们设计了一个节点 LRU 淘汰链表，链表中保持 40 个联系的邻居节点，老的节点会退出，新的节点会加入，LRU 会根据邻居与自己的通信状态来进行 LRU 新增和淘汰，原则如下： 就近原则，内网优先，同城同一运营商网络次之； 周期性评测延迟和媒体分片命中率，末位淘汰； 当 LRU 列表中节点不足 40 个时会从备用节点列表中选取新的节点进行连接并加入到 LRU 中。 【节点评估】： 每个客户节点的计算能力、通信能力和网络分区等都不一样，这使得我们必须对每个节点做一个评价，对一个节点的评价分为两部分：邻居节点对自己的评价和自己对自己的评估。 邻居评价主要是： RTT； 丢包率； 请求命中率。 通过这三个参数会对每个邻居计算出一个亲和力分值 score，这个值会用于后面的分发选择。 主要评估自己这几点： CPU、内存； 网络类型：WIFI/4G/ 有线网络； 上传带宽。 节点会周期性计算这两类参数，通过一个网络 QOS 收敛函数 f(x) 来计算节点能力和对邻居 QOS 策略。 4.3 节点分层 节点评估最终的目的是让有能力的节点成为超级节点（super node）来分担 Edge server 的分发压力。 那么一个节点成为超级节点的条件是什么呢？有以下几个条件： 有足够的上传带宽，4G 和弱 WIFI 下不能成为超级节点； 有空闲的 CPU 和内存，计算能力不够的低端移动设备不能成为超级节点； 对邻居通信友好，不是通信孤岛； 得到 Edge server 的任命，和 Edge server 之间通信顺畅。 超级节点如果性能衰减了怎么办？答案是会退化成普通节点，因为节点评估是周期性实时进行的，如果发现节点性能衰减，Edge server 会让其退化。 既然任命了超级节点，那么超级节点是怎么工作的？每一个超级节点在被任命时都会分配到一个分组 ID，Edge server 会根据自己辖区的超级节点数量进行分组，每个分组由多个超级节点组成，分组内的超级节点负担自己分组的媒体分片分发。例如：有 5 个超级节点分组，这时单位周期内有 1 ~ 20 个 segment，那么第一个分组负责 1、6、11、16 编号的 segment 分发，以此类推第二组负责 2、7、12、17 ……这样做是为了防止单个超级节点失效，增强了 P2P 分发的稳定性。 示意图如下： 5、基于P2P的实时视频直播流媒体分发过程 通过上面的 P2P 网络构建过程我们知道整个 P2P 网络其实是一个分层有向图分发网络，那么具体是怎么进行流数据分发的呢？也分三步：先推 (push)、后拉 (pull)、再补偿。下面来仔细解释是怎么实现的。 5.1 push 在介绍超级节点时有提到会根据 segment ID 将数据推到对应的超级节点分组群上，超级节点收到这些 segment 后怎么进行处理呢？按照 P2P 设计的原理应该将数据转发到其他分组的超级节点或者普通节点上，但是如果都这样推有可能会造成网络发送冗余而消耗过多的带宽。 为了解决这个问题我们设计了一个预先订阅机制，原理就是每个 P2P 客户节点会根据自己缓冲区最大的 segment ID 来进行预订，提前预订 10 秒以后的媒体数据分片，预订请求要根据节点评估出来的亲和力值 score 做权衡，收到这些请求的超级节点会将预订的分片请求信息保存下来，等到 Edge server 推送这个分片到这个超级节点，它就会无条件转发这些被预订的报文给发起预订的节点，如下图所示： 从上图中可以看出以下几个原则： 从 Edge server 到所有节点路径最多两层，这样做是为了控制链路延迟； 不同分组 super node 之间会相互订阅对应分组的 segment； 普通 node 只会向 super node 发起订阅。 5.2 pull 数据 segment 通过预先订阅的方式进行 push 推送到各个客户节点，但网络是会丢包的，super node 也有可能会中途退出，这样就会造成最终的节点发生丢包，那丢包了我们怎么办？ 我们设计一个向邻居拉取缺失分片的机制，大致的流程如下： 节点周期性检查丢失分片的信息和收到分片的信息，构建一个 gossip 协议向邻居交换缓冲区信息； 节点收到邻居的 gossip 信息，将对方拥有的分片信息记录到本地； 本地根据记录邻居的分片信息查找自己丢失的分片，通过邻居亲和力值 score 进行权衡随机选取邻居，并向选取的邻居发起 pull 请求； 收到邻居拉取分片请求，将分片发往请求的节点。 整个步骤会周期性尝试多次拉取，示意图如下： 这里值得一说的是因为会周期性交换缓冲区的 gossip 信息，这意味着缓冲区的 gossip 信息越小越好，我们设计了一个类似 bloom filter 来描述 gossip 信息，不仅可以减小 gossip 报文的数据大小，而且比对速度也很快。 5.3 补偿 因为 P2P 的客户节点是不稳定的，有可能某个 segment 通过拉取多次还是没有收到，这个 segment 又临近播放位置，那么缺失这个 segment 的节点会直接向 Edge server 请求补偿让其尽快传送这个分片，这样做的目的是防止因为 P2P 通信造成丢包的卡顿。这也就是说每个 Edge server 需要拥有所有分片数据，这也就是系统的锚点。 流程如下图： 这个流程大部分情况下没有问题，但如果同一时刻大部分客户节点都缺失某几个 segment 分片，会有大量的补偿请求到 Edge server 上，这会造成网络风暴。我们在应对这个问题时设计了一个稀缺评估和拒绝服务的机制。这个机制是指当单位时间内太多个补偿请求到达 Edge server，那么这个 Edge server 会拒绝自己承受能力之外的请求，只重发承受范围之内的分片。而且这个过程还会对补偿请求做稀缺评估，如果某个分片大部分节点都没有，它会主动将这个分片通过 super node 群再推送一次。 5.4 缓冲 buffer 与时延控制 通过上面的三个阶段可以将所有数据 segment 分发到每个客户节点上，但客户节点需要一个缓冲 buffer 来配合这个三个阶段和本地的播放，buffer 如果缓冲时间过长，会引起不必要的延迟，如果过短会造成卡顿和三个阶段不完整。 为此我们设计了一个三阶段 buffer 动态缓冲区，如下图所示： 下边解释一下上图各个区间的意思： push 区间：因为分片是通过不同的 super node 推送过来的，那么必然会造成一定的抖动，所以在 buffer 最开始的头上会有一个 jitter 缓冲阶段，直到第一个邻居节点 gossip 信息中有这个分片 push 位置结束，这个阶段一般持续 100 ~ 300ms； pull 区间：分片时序进入 pull 区间后，会周期性检查丢失的分片，根据 gossip 掌握的邻居进行权衡拉取，会进行 3 次尝试，每一次尝试时间是本地节点与邻居之间的 RTT 值。3 次失败则进入补偿区间； 补偿区间：分片时序进入补偿区间后，也会周期检查丢失的分片，根据丢失的分片 ID 直接向 Edge server 请求拉取，尝试 4 次，每次尝试时间为一个本地节点与 Edge server 之间的 RTT。如果 4 失败则进行 waiting 状态，等待邻居 gossip 或者 Edge server 主动推送； 过期区间：被播放后的分片会放到这个过期区间中而不是立即删除，为什么呢？因为每一个节点的播放时间点不同，有可能本地播放的分片正是其他节点丢失的分片，有可能其他节点会通过 pull 来拉取，所以我们会把播放后的分片放在过期区间 3 秒后再删除。 5.5 秒开问题 上面分发的三个阶段和 buffer 控制解决了流持续分发和播放延迟控制问题，但现阶段所有的直播技术必须要有秒开，其实 P2P 分发在解决秒开问题上比单纯的 Server CDN 转发要更加简单。秒开就是用户进入直播间时瞬间能看到主播的视频图像，秒开的宗旨是新进入的客户节点要求服务端边缘节点从视频的上一个 GOP 关键帧开始发送数据，客户节点再根据视频编码器从这个 GOP 关键帧零等待加速播放。我们在 P2P 分发网络中新进入的节点会收到 Edge server 的上一个 GOP 关键帧分片 ID，客户节点根据这个 ID 从各个邻居中快速拉取整个 GOP 分片数据，而不是单纯地让 Edge server 来发，秒开的速度平均缩短了 100 毫秒。 6、基于P2P的实时视频直播内容授权 直播分发技术除了传输分发以外，还需要考虑内容防盗和授权，P2P 系统中更加需要考虑系统安全性。我们引入了 CA 证书和双端协商加密方案来保证链路的合法性。大致的做法是每个合法的节点单元（Edge server 和所有的客户节点）会向 CA 发起合法校验，如果检验通过，CA 会根据节点的 ID、节点 RSA 公钥、授权起始时间和授权终止时间等信息利用 CA 的 RSA 进行证书生成。每个拿到证书的节点单元需要和其他的节点进行通信，先交换证书，校验对方证书的合法性，然后利用证书中 RSA 公钥加密算法的 KEY 返回给证书方，证书方收到加密的 KEY 后会用 RSA 私钥解密得到对称加密的 KEY，这样双方就完成了合法性校验并利用这个交换的 KEY 进行报文加解密通信。 流程如下图： 7、线上数据对比 上面的技术分析只是帮助读者理解这个系统的运作机理，除此以外，当然需要公布一下线上数据来佐证下系统可行性，下图是一个 10W+ 在线直播平台使用了这套 P2P 系统后线上的对比数据。我们在同一个 Edge server 上的同一个直播间对象中，把一半的用户节点关闭 P2P，一半的用户开启 P2P，来观察一天中同一个 Edge server 上这两部分用户群的带宽消耗情况。 从上图可以看出，P2P 模式带宽消耗只有不开启 P2P 模式的 1/4，我们这个 P2P 系统节省了 75% 的带宽成本。这个数据的视频样本是单路 480P 800kps 码率的直播流，高峰期真实节点数 1000+，最终所有终端的平均延迟是 1.07 秒。 8、本文小结 到这里关于 P2P 分发网络的技术解析就结束了，P2P 技术从产生到现在已经经历了 19 年，而且 P2P CDN 也是下一代 CDN 的主体技术，P2P 技术和模型也一直变化改进。我们在直播分发领域使用 UDP 和 P2P 是想从成本和延迟上来解决我们教育场景互动的问题，出发点不一样，也就会得到不一样的结果，如果你遇到成本和延迟的困扰，可以尝试使用这种技术来解决问题。 附录：更多实时音视频技术文章 [1] 开源实时音视频技术WebRTC的文章： 《开源实时音视频技术WebRTC的现状》 《简述开源实时音视频技术WebRTC的优缺点》 《访谈WebRTC标准之父：WebRTC的过去、现在和未来》 《良心分享：WebRTC 零基础开发者教程（中文）[附件下载]》 《WebRTC实时音视频技术的整体架构介绍》 《新手入门：到底什么是WebRTC服务器，以及它是如何联接通话的？》 《WebRTC实时音视频技术基础：基本架构和协议栈》 《浅谈开发实时视频直播平台的技术要点》 《[观点] WebRTC应该选择H.264视频编码的四大理由》 《基于开源WebRTC开发实时音视频靠谱吗？第3方SDK有哪些？》 《开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用》 《简述实时音视频聊天中端到端加密（E2EE）的工作原理》 《实时通信RTC技术栈之：视频编解码》 《开源实时音视频技术WebRTC在Windows下的简明编译教程》 《网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？》 >> 更多同类文章 …… [2] 实时音视频开发的其它精华资料： 《专访微信视频技术负责人：微信实时视频聊天技术的演进》 《即时通讯音视频开发（一）：视频编解码之理论概述》 《即时通讯音视频开发（二）：视频编解码之数字视频介绍》 《即时通讯音视频开发（三）：视频编解码之编码基础》 《即时通讯音视频开发（四）：视频编解码之预测技术介绍》 《即时通讯音视频开发（五）：认识主流视频编码技术H.264》 《即时通讯音视频开发（六）：如何开始音频编解码技术的学习》 《即时通讯音视频开发（七）：音频基础及编码原理入门》 《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》 《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除�概述》 《即时通讯音视频开发（十）：实时语音通讯的回音消除�技术详解》 《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》 《即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨》 《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》 《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》 《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》 《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》 《即时通讯音视频开发（十七）：视频编码H.264、VP8的前世今生》 《实时语音聊天中的音频处理与编码压缩技术简述》 《网易视频云技术分享：音频处理与压缩技术快速入门》 《学习RFC3550：RTP/RTCP实时传输协议基础知识》 《基于RTMP数据传输协议的实时流媒体技术研究（论文全文）》 《声网架构师谈实时音视频云的实现难点(视频采访)》 《浅谈开发实时视频直播平台的技术要点》 《还在靠“喂喂喂”测试实时语音通话质量？本文教你科学的评测方法！》 《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》 《移动端实时视频直播技术实践：如何做到实时秒开、流畅不卡》 《如何用最简单的方法测试你的实时音视频方案》 《技术揭秘：支持百万级粉丝互动的Facebook实时视频直播》 《简述实时音视频聊天中端到端加密（E2EE）的工作原理》 《移动端实时音视频直播技术详解（一）：开篇》 《移动端实时音视频直播技术详解（二）：采集》 《移动端实时音视频直播技术详解（三）：处理》 《移动端实时音视频直播技术详解（四）：编码和封装》 《移动端实时音视频直播技术详解（五）：推流和传输》 《移动端实时音视频直播技术详解（六）：延迟优化》 《理论联系实际：实现一个简单地基于HTML5的实时视频直播》 《IM实时音视频聊天时的回声消除技术详解》 《浅谈实时音视频直播中直接影响用户体验的几项关键技术指标》 《如何优化传输机制来实现实时音视频的超低延迟？》 《首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》 《Android直播入门实践：动手搭建一套简单的直播系统》 《网易云信实时视频直播在TCP数据传输层的一些优化思路》 《实时音视频聊天技术分享：面向不可靠网络的抗丢包编解码器》 《P2P技术如何将实时视频直播带宽降低75%？》 >> 更多同类文章 …… （本文同步发布于：http://www.52im.net/thread-1289-1-1.html）

WIFI和无线上网,对于许多人来说已不是陌生词汇.然而迅驰平台的漏洞却让偷窥热了起来。网上破解无线网络的软件比比皆是，当然破解的方法是林林种种。开放的网络——例如办公室，家里，带PORTAL认证的网络——例如机场、运营商，这2中情况下直接用Omnipeek无线抓邮箱的用户名、密码和截获MSN聊天信息都非常大方便，只要你使用的是迅驰无线网卡，网上的破解方法随便搜索，蹭邻居的网上也是很容易的。有WEP、WPA加密的网络破解起来就会比较麻烦——例如上岛咖啡和星巴克，这种网络可以先用inAircrackPack进行WEP、WPA密钥的破解，然后用破解获得的WEP密钥加入到Omnipeek中抓邮箱的用户名、密码和截获MSN聊天信息。 谷歌Android手机欲与运营商分成 传苹果CEO乔布斯病情迅速恶化 微软明年1月15日或将裁员17% 中移动拟调低2009年整体资费10% 腾讯将推以QQ为主题的上网本 如何感受2008年额外增加的一秒 上面的方法在网上已经铺天盖地了，所以有人说艳照门是因为wi-fi漏洞我倒认为很靠谱。这倒给那些那些渴望提前知道金融危机自己是否被老板裁员的人一个机会，前提是你们公司在使用无线上网，那么破解起来就容易了。 星巴克、麦当劳、图书馆、飞机场、家庭、写字楼、街道……的无线网络已几乎覆盖很多地方.在咖啡厅等休闲娱乐场所里,经常能见到不少人边喝咖啡边上网工作;在家里,几台电脑同时上网也不再需要跟无数的网线纠缠不清,甚至不申请宽带也能偶尔蹭上网.无线上网的实现,确实为都市人的生活带来很多便利. 光顾商家免费上网 在星巴克、麦当劳、绿茵阁等餐饮连锁店,以及天河南、淘金的小咖啡馆都纷纷架设无线网络,顾客一般只要光顾消费就能免费享受WIFI无限上网. 完全免费“蹭”网 现在咖啡店密集的街道、或者自己家里,或许能搜到免费开放的WIFI热点,这样就能免费蹭一下别人的网络.但从安全角度考虑,还是尽可能选用运营商的WIFI网络,避免掉进黑客陷阱,或者在疏忽中丢失重要资料. 有人的地方就有江湖,有网络的地方就存在隐患.跟有线上网相比,由于WIFI是散发在空中的信号,更容易被黑客突破,若被盯上不仅电脑上的资料容易被盗、还可能被传播病毒. 著名的写手韩寒曾在电视节目上透露,他经常深夜才更新博客,因为那时他可以去蹭邻居的无线信号来上传文章.尽管经常传着传着就会断线,但他还是乐在其中。 上文提到的陆先生也告诉笔者,他在无线上网的过程中,经常会发现陌生账户连接到自己的无线网络.假如对方只是看看网页还无所谓,并不影响自己的使用;但有的邻居居然在上面玩起网游,严重影响他上网的流畅. 据业内人士介绍,陆先生的情况,是由于他使用的无线路由器上网没有设置密码,相当于在整栋楼里开通了无线局域网,他的邻居只要有无线上网设备就能蹭上他的网络. 据了解,无线上网却不注意加密的WIFI用户大有人在.某网络高手告诉笔者,无线网络虽然方便,安全性也相对减弱了.如果无线网络的主人不注意防范,被他人成功蹭网,资料信息被盗走、电脑被灌入病毒、木马都是比较容易的事情;甚至可能因帐号被盗而承受经济损失. 无线比有线危险 IFI技术的确存在一定的安全隐患,因为连上同一热点的用户处于同一局域网中,如果不采取必要的安全措施, 就可能受到攻击.尤其是公共场所的无线网络,由于成员都是动态匿名的,安全问题更为突出. 也就是说,在公共场所使用WIFI无线上网,与自己处于同一局域网的用户都是陌生人,比起在单位等有线的局域网,用户大都是同事这样相对熟悉的人,安全性自然不可比.因此,就更要保护好自己的隐私. 蹭上无线网络偷窥别人电脑资料有多容易?笔者请教网络高手吴先生,见证了“偷窥”的全过程。 见证:“偷窥”其实很简单 首先,下载并安装了软件“局域网超级工具”,并进行一些简单的设置.这样他轻易地从扫描到的热点中,搜索到有“共享文件”的用户;然后从中选取感兴趣的文件,直接打开就可以看到了. “偷窥真的这么简单?”,面对笔者的惊讶,吴先生很平静地说,“操作其实很简单,只要你有心偷窥,只要不是对电脑一窍不通,从网上下载这一类软件,稍微学习一下就可以了.看完我的演示,现在你也应该学会了.” 被偷窥是最常见的安全隐患.除此以外,更危险的是被窃取个人密码、甚至被传播病毒.他告诉笔者,破解密码的软件在网上有很多,有了这些工具就能轻易利用无线上网连接,对其他用户进行攻击.笔者看到吴先生利用破解软件,轻松连接到加密的无线局域网中,这时吴先生就已能获取 对方电脑的各种机密信息、电子邮件等,“我们还可以删除这个人的私密的文件、邮件,甚至传播电脑病毒,这些都很容易操作.而且利用他的账户进行话费充值,甚至进行犯罪活动都是可以实现的.”十分钟.“虽然这种偷窥在有线网络也能实现,但相比而言,无线网络中更容易.” 安全习惯很重要 在公共场合使用无线,应该怎样保证自己的安全呢?专家建议我们首先要有很好的安全风险意识,养成良好的计算机安全习惯.比如,和别人共享的内容要即时关闭,不要将自己的文档暴露在局域网中;还要及时更新系统补丁和防病毒、防木马软件. 此外,对于垂手可得的免费热点,专家提醒大家,即使发现不明的免费无线网络,不要贪小便宜,因为这也可能是温柔的陷阱,有可能是有人诱惑你上钩,从而窃取你的资料. 有些黑客会在公共场合设置一个伪装的无线存取设备,吸引使用者上钩,从而截取上钩者输入的各类密码,或将病毒输入上钩者的电脑. 怎样查出是否被蹭? 大多数路由控制面板带有流量统计的界面,可以直观地看到已连接网络的电脑终端的IP地址和流量情况.如果发现异常情况,可以通过路由控制面板直接关闭可疑的IP地址连接. 如何避免信息泄漏? 1、安装一定的防病毒、防木马和防火墙软件; 2、保持电脑操作系统以及杀毒软件等的更新,并定期利用这些软件扫描计算机,查杀病毒、木马、垃圾软件等; 3、定期更新微软等操作系统的安全补丁; 4、关闭共享的文件,如果必须共享应在共享结束后及时关闭共享; 5、以加密方式传输重要资料也是比较安全的方法,比如在网址开头是“Https”的网站所使用的资料都是经过加密处理的,比起一般的 “Http”网址的网站安全.一般来说,电子银行或网上交易网站都会使用这种技术. 6、为避免连上可疑的无线热点,导致个人资料被盗,要紧记只用可信任的无线热点,在咖啡店等消费场所上网前应先店员确认热点的网络名称,以免上错黑客伪造的名称相近的热点； 7、在使用公共开放无线网络时,应避免读取私人电子邮件、使用网上银行服务或进行网上交易等操作. 当然目前最好的就是有新的平台取代迅驰，新的上网方式取代WIFI，偷窥事件也就少了。 注：本文为博主根据多方信息综合整理。

作者：东帆@阿里安全技术平台团队   0x00 引言 近日，中共中央办公厅、国务院办公厅印发了《推进互联网协议第六版（IPv6）规模部署行动计划》，加快推进IPv6规模部署，构建高速率、广普及、全覆盖、智能化的下一代互联网。 随着计划实施推行以及移动互联网、物联网的大力发展，我国整个网络环境将发生翻天覆地的变化，全产业链已蓄势待发，目前IPv6根服务器架设中国开始部署，IPv6城域网、政府网站IPv6双栈化改造、IPv6城市公共无线网络等均已开始试点和部署，互联网BAT部分内容已支持IPv6访问，流量增长迅速，新的网络环境以及新兴领域均将面临着新的安全挑战。 按照部署计划，到2018年末，IPv6活跃用户数达到2亿，在互联网用户中的占比不低于20%，到2020年末，IPv6活跃用户数超过5亿，在互联网用户中的占比超过50%，新增网络地址不再使用私有IPv4地址，到2025年末，我国IPv6网络规模、用户规模、流量规模位居世界第一位，网络、应用、终端全面支持IPv6，全面完成向下一代互联网的平滑演进升级，形成全球领先的下一代互联网技术产业体系。 针对IPv6安全，计划中重点要求升级安全系统，强化IPv6地址管理，增强IPv6安全防护，加强IPv6环境工业互联网、物联网、车联网、云计算、大数据、人工智能等领域的网络安全技术、管理及机制研究，构筑新兴领域安全保障能力。 本文从IPv6安全威胁结合互联网网络安全运营视角进行了重点分析，同时探讨了互联网IPv6网络安全保障体系面临安全风险及加固建议。   0x01 IPv6协议介绍 IPv6（Internet Protocol version 6，互联网通信协议第6版）是数据包交换互联网络的网络层协议，主要用于寻址和路由，是IETF（互联网工程任务小组Internet Engineering Task Force，简称IETF）设计用来替代IPv4协议的，在早期协议发展阶段，IPv6也叫做IPng。 IETF自1990年开始，开始规划IPv4的下一代协议，除要解决IP地址短缺问题外，还要进行更多扩展。1994年,IETF会议中正式提议IPv6发展计划，并于1998年8月成为IETF的草案标准，最终IPv6在1998年底被IETF通过公布互联网标准规范（RFC 2460）的方式定义正式发布。 目前随着移动互联网、物联网的大力发展，计算机网络已经与人们的生活密切相关，可能身边的每一样电子设备都需要连入网络，IP地址需求量剧增，同时IPv4地址越来越紧缺，IPv6的发展越来越迫切。 IPv6发展的主要原因如下： a)128位的地址空间：IPv6由128比特位构成，单从数量级上来说，IPv6所拥有的地址容量是IPv4的约8×1028倍，达到2128个巨大的地址空间，不但解决了网络地址资源数量的问题，同时也为物联网的发展提供了基础。 b)层次化的路由结构，而这是当前IPv4无法满足的：  分层汇总（Public、Site、Interface）  更为简单的ACL  更少的路由条目 c)实现真正的点到点通信，而不是NAT d)对安全传输的内在支持，提供更为安全的数据传输 e)对数据报文进行简化，提供更快的数据包处理 f)支持移动IPv6，提供稳定的移动网络服务 g)自动配置、即插即用 h)流标签提供更多的服务质量控制能力 如下图1为IPv4和IPv6报文头结构，从报文头结构对比看，IPv6借鉴了IPv4的应用经验,大大简化了基本报头结构,仅包含8个字段，IPv6中所有非核心功能都由扩展报头实现。 IPv4和IPv6报文头主要差异点如下： a)IPv6简化报头和数据长度计算：报头长度字段已经不在IPv6基本报头中使用,只使用一个字段来标示数据净荷的总长度； b)更好支持DiffServ QoS服务：IPv4报头的服务类型字段在IPv6中该字段被扩展为业务流类型、流标签2个独立的字段； c)取消中间分片：IPv4报头为数据分片提供了数据报文ID、分片标志、分片偏移值3个字段,目前有许多针对这3个字段的攻击手段, IPv6采用Path MTU发现机制,避免了中间路由器的分片处理,消除了一些安全隐患； d)取消校验和字段：许多IPv4后续报文头如ICMP、UDP和TCP中均含有同时覆盖基本报头和数据部分的检验和字段,因此IPv4报头中校验和字段是多余的,此字段在IPv6基础报头中已经取消； e)对选项功能的处理：IPv6采用扩展报头实现选项功能,解决了IPv4中带有选项内容的数据包不能被高效传输的问题,也使得IPsec以及未来可能出现的新的安全协议的采用更加方便。 从报文头结构对比可见，IPv4协议报文头结构冗余，影响转发效率，同时缺乏对端到端安全、QoS、移动互联网安全的有效支持，而IPv6协议重点针对上述几个方面进行了改进，采用了更加精简有效的报文头结构，IPv6协议选项字段都放在扩展头中，中间转发设备不需要处理所有扩展报文头，提高数据包处理速度，并且通过扩展选项实现IPsec安全加密传输和对移动互联网安全的支持。                           图1  IPv4和IPv6报文头结构 从协议族来看，IPv6协议族相对于IPv4协议族，基本部分也发生了较大的变化，如ARP协议被邻居发现协议（NDP）代替，ICMPv6合并了IPv4中的ICMP（控制报文协议)，IGMP（组成员协议)、ARP（地址解析协议)、RARP（反向地址解析协议)和RA（路由广播)等多个协议的功能。   0x02  IPv6协议设计的安全考虑 从协议的角度，IPv4协议诞生较早，前期设计几乎没有任何的安全考虑，因此特别是对报文地址的伪造与欺骗使得无法对网络进行很有效的监管和控制，而在IPv6协议设计之初，引入了AH（认证包头）、ESP（封装安全载荷）、SA（安全关联）、IKMP（密钥管理协议）等加密和认证机制，并强制实现了IPsec认证，IPsec协议族中的AH（AuthenticationHeader，报文认证头）和ESP（EncapsulationSecurity Payload，报文封装安全载荷）内嵌到协议栈中，作为IPv6的扩展头出现在IP报文中，提供完整性、保密性和源认证保护，从协议设计上较大地提升安全性。 从IPv6协议安全设计上考虑，相比IPv4主要有如下增强： a)可溯源和防攻击：IPv6地址资源丰富，不需要部署NAT，扫描困难 b)IPv6的默认IPsec安全加密机制：IPv6协议中集成了IPsec，通过认证报头（AH）和封装安全载荷报头（ESP）两个扩展头实现加密、验证功能，中间转发设备只需要对带有IPsec扩展包头的报文进行普通转发，大大减轻转发压力 c)邻居发现协议（NDP）和SEND：采用NDP(neighbor discovery protocol)协议取代现有IPv4中ARP及部分ICMP控制功能如路由器发现、重定向等 d)真实源地址检查体系：真实源IPv6地址验证体系结构（SAVA）分为接入网（Access Network）、区域内（Intra-AS）和区域间（Inter-AS）源地址验证三个层次，从主机IP地址、IP地址前缀和自治域三个粒度构成多重监控防御体系。 特别对于IPv4网络地址而言，数量非常有限，因此很多时候是一个地址被多台主机通过NAT等技术共用。使用IPv6之后，可以将每个地址指定给一个对象，每个地址唯一，IPv6的地址分配可采用逐级、层次化的结构，这将使得追踪定位、攻击溯源得到很大的改善，用户、报文和攻击关联对应，用户对自己的任何行为负责，并具有不可否认性。 IPv6协议也定义了多播地址类型，而取消了IPv4下的广播地址，可有效避免IPv4网络中利用广播地址发起的广播风暴攻击和DDoS攻击。同时，IPv6协议规定了不允许向使用多播地址的报文回复ICMPv6差错消息，能有效防止ICMPv6报文造成的放大攻击。 另外，IPsec协议族中的AH和ESP安全扩展包头为IPv6核心的安全机制和设计，提供了关键的加密和认证机制。 AH 是IPv6的一个安全扩展包头，在RFC4302中定义，协议号为51。IPv6的认证主要由AH来完成。认证包头通过在所有数据包头加入一个密钥，通过AH使数据包的接收者可以验证数据是否真的是从它的源地址发出的，并提供密码验证或完整性测试。这种认证是IP数据包通过一定加密算法得出的编码结果，相当于对IP数据包进行数字签名，只有密钥持有人才知道的“数字签名”来对用户进行认证，同时接收者可通过该签名验证数据包的完整性。AH的验证范围与ESP有所区别，包括了整个IPv6数据包。 AH位于IPv6头和一些上层协议头之间，如果存在扩展包头，则AH必须位于逐跳选项头、选路扩展头和分段扩展头之后。 ESP也是IPv6的一个安全扩展包头，在RFC4303中定义，协议号为50。其对IPv6数据包的有效载荷部分加密，不包括IPv6包头部分，能为IP层提供机密性、数据源验证、抗重放以及数据完整性检验等安全服务，其中数据机密性是ESP的主要功能，其他均为可选。ESP头位于IPv6头和上层协议之间，如果存在扩展包头，则ESP头必须位于逐跳选项头、选路扩展头、分段扩展头和认证头之后。由于ESP只对ESP头之后的数据加密，所以通常将目的地选项头置于ESP头之后。 ESP和AH各扩展包头可以单独使用，也可以一起使用。   0x03 IPv6网络安全威胁分析 IPv6相对于IPv4，除了和IPv4相同的安全威胁外，新增部分主要来自于协议族、协议报文格式、自身设计实现、IPv4向IPv6的演进过程中新增或者变化引入的安全威胁。   1. IPv6与IPv4共同的安全威胁 IPv6与IPv4同为网络层协议，有共同的安全威胁如下： a)未配置IPsec可实施网络嗅探，可能导致信息泄露 b)应用层攻击导致的漏洞大多数在网络层无法消除 c)设备仿冒接入网络 d)未实施双向认证情况下可实施中间人攻击Man-in-the-Middle Attacks (MITM) e)泛洪攻击   2. IPv6协议族新增安全威胁 IPv6相对于IPv4在协议族上发生了较大的变化，新增安全威胁如下： a)邻居发现协议（ND）攻击：针对ARP的攻击如ARP欺骗、ARP泛洪等在IPv6协议中仍然存在,同时IPv6新增的NS、NA也成为新的攻击目标，存在DoS攻击、中间人攻击等安全威胁。 b)新增ICMPv6协议作为IPv6重要的组成部分，存在DoS攻击、反射攻击等安全威胁； c)IPv6 支持无状态的地址自动分配，该功能可能造成非授权用户可以更容易的接入和使用网络，存在仿冒攻击安全威胁； d)IPv6 网络环境下由于网络扫描实施难度高，但仍可通过IPv6前缀信息搜集、隧道地址猜测、虚假路由通告及DNS查询等手段搜集到活动主机信息，通过DNS获取IPv6地址范围和主机信息可能会成为黑客优选攻击路径，针对DNS系统的攻击会更加猖獗； e)IPv6组播地址仍然支持，存在通过扫描、嗅探甚至仿冒关键DHCP Server、Router等安全威胁。 f)IPv6路由协议攻击：RIPng/PIM依赖IPsec，OSPFv3协议不提供认证功能，而是使用IPv6的安全机制来保证自身报文的合法性，未配置IPv6安全机制，OSPFv3路由器存在仿冒的安全威胁； g)移动IPv6仿冒伪造攻击：移动IPv6节点能够在不改变IP地址的情况下,在任何地方接入网络都能够直接与其他节点通信，在提供可移动性及方便通信的同时,由于移动节点的不固定性,也给不法分子提供了攻击的机会，存在伪造绑定更新消息等安全威胁； h)MLD仿冒及泛洪攻击。 3. IPv6协议报文格式新增安全威胁 IPv6 协议相关RFC标准在不断的发展更新，协议自身也存在漏洞，所有遵循IPv6协议的设备都会受到该漏洞的影响，新增安全威胁如下： a)协议自身存在漏洞，如IPv6协议Type0路由头拒绝服务漏洞，该漏洞已于2007年12月由RFC 5095修补，禁用了IPv6扩展头中的Type 0路由头； b)IPv6分片攻击 c)IPv6扩展头攻击 d)ND DAD攻击（Duplicate Address Detection） e)ND Router Advertisement仿冒、DoS、中间人攻击 4. IPv6自身实现新增安全威胁 IPv6 和IPv4协议一样，设备与应用在实现对IPv6协议的支持时，不同的系统开发商因软件开发能力的不同，在IPv6协议软件开发、各种算法实现也会引入各种可能的安全漏洞。 从下一代互联网国家工程中心全球IPv6测试中心11月份发布的《2017 IPv6支持度报告》来看： 目前的操作系统中，75%左右都默认安装IPv6协议栈，65%左右支持DHCPv6，50%左右支持ND RNDSS。其中手机操作系统支持IPv6协议已经从实验室走向了应用阶段，Android 4.2、IOS 4.1、Windows Phone 6.5、Symbian 7.0都已经支持IPv6，并且默认安装IPv6，自以上各手机系统版本后推出的新版本均支持IPv6。在DHCPv6功能上，IOS支持得比较好，从V4.0开始支持stateless DHCPv6，V4.3.1支持Stateful DHCPv6。Windows Phone支持DHCPv6 Lite，Android系统不支持DHCPv6。在邻居发现(ND)选项RDNSS功能上，IOS目前已经支持ND RDNSS，Android 5.0以上已经支持ND RDNSS。若一个操作系统不支持DHCPv6和ND RDNSS，则无法在纯IPv6网络环境中自动配置查询域名服务器。 各种应用软件也逐渐开始支持IPv6以应对广大用户的需求。但是目前并不普遍，只有一些基础应用软件已经支持IPv6。 基础应用软件中有一小部分已可以支持IPv6，其中浏览器软件，如IE系列、Chrome、Firefox和Opera等都支持IPv6；下载软件和邮件客户端软件，如FileZilla3、SmartFTP4以及Outlook等都支持IPv6。但是国内自主研发的基础应用软件，除浏览器外，其他诸如下载软件、即时通讯软件等都尚无法在IPv6环境下正常使用。 各类软件安全实现不当都可能引入IPv6协议安全漏洞，需要做好安全编码及质量保障活动。 如下为典型的IPv6协议栈实现方面的漏洞。 1、Python getaddrinfo() remote IPv6 buffer overflow 2、Apache remote IPv6 buffer overflow 3、Postfix IPv6 unauthorized mail relay vulnerability 4、Openbsd remote code execution in IPv6 stack ……   5. IPv4向IPv6演进过程中新增安全威胁 IPv4向IPv6的过渡是一个长期的过程，在IPv4与IPv6共存时期，为解决两者间互通所采取的各种措施将带来新的安全风险。例如，隧道方式下存在的拒绝服务攻击、中间人攻击，NAT-PT技术下存在的拒绝服务攻击等。 IPv4向IPv6的演进过程中涉及到双栈、隧道以及翻译技术，主要安全威胁如下： a)双栈技术：许多操作系统都支持双栈，IPv6默认是激活的，但并没有向IPv4一样加强部署IPv6的安全策略，支持自动配置，即使在没有部署IPv6的网络中，这种双栈主机也可能受到IPv6协议攻击。 b)隧道技术：几乎所有的隧道机制都没有内置认证、完整性和加密等安全功能，攻击者可以随意截取隧道报文，通过伪造外层和内层地址伪装成合法用户向隧道中注入攻击流量，存在仿冒以及篡改泛洪攻击安全威胁。 c)翻译技术：涉及载荷转换，无法实现端到端IPsec，存在受到NAT设备常见的地址池耗尽等DDoS攻击安全威胁。   0x04 互联网IPv6网络安全保障体系及策略探讨 随着基于IPv6的下一代网络中应用的增加、速度的加快和规模的变大，IPv6网络面临着新的安全风险。 对于互联网网络，安全是保证网络健康发展的重要因素，IPv6网络安全保障体系的配套建设作为IPv6网络建设的重要方面，在IPv6网络设计阶段对网络安全需要进行通盘考虑，提升网络架构的整体安全性。 网络安全保障体系可分为静态安全防护体系以及动态安全运营体系两个层面。 静态安全防护体系根据ITU-T X.805标准（端到端通信系统安全框架），网络可分为基础设施层、业务层和应用层，每个网络层次可以划分为管理、控制和数据三个平面。采用多种技术手段隔离管控，并在每个平面实施相应安全防护措施，从而使每个平面在安全方面都具备访问控制、鉴别、不可抵赖、数据保密性、通信安全、完整性、可用性和隐私性8个属性防护能力。 动态安全运营体系通过安全检测和响应等安全基础设施和相关安全管理组织、制度和流程的配套建设，可实现对网络安全风险的动态发现和管理。 与IPv4相比，可以共用相同的网络整体安全保障体系，但在IPv4基础网络的前提下需要确定升级演进到IPv6的策略，基于IPv6的特点和安全威胁分析，识别IPv6安全产品缺失的现状并补齐，确定改造节奏，包括LVS、DNS等各类型服务器、网络设备、DDoS设备、防火墙等，升级安全系统，结合业务实际利用好IPv6协议本身的安全增强技术手段，增强IPv6安全防护，同时加强IPv6环境各业务领域特别是新兴领域物联网、云计算、大数据、人工智能等的网络安全技术、管理及机制研究，促进新的安全业务和应用的开展，形成全球领先的下一代互联网技术产业体系。   0x05 IPv6网络安全加固建议 虽然IPv6相对于IPv4来说增强了自身的安全机制，但一个新协议的引入必然会引入新的安全问题，对已有的网络安全技术体系造成影响，因此熟悉已有业务及网络、IPv6现状及其安全性并针对性部署安全加固非常重要。 针对不同的IPv6网络安全风险，有不同的安全应对技术、措施和方法，需要采取合适自身的IPv6安全解决方案及措施，构筑IPv6网络安全及IPv6环境下新兴领域安全保障能力。 如下典型的IPv6网络安全加固建议供参考。 a)做好IPv6网络各层各面和各安全域的隔离及访问控制，将安全影响控制到最小； b)合理管控IPv6管理、控制和数据平面之间的资源互访，在各平面安全域根据各域的特点辅以相应的安全保护和控制措施，实施双栈的情况建议在IPv4/6双栈设备上采用严格的网络过滤和访问控制，防范IPv4和IPv6安全问题的相互影响； c)做好管理和控制平面IPv6网络接入的认证与鉴权，制定完善的边界防护策略，防止恶意设备及用户的接入，结合业务实际情况有效利用IPv6协议的IPsec特性、源地址过滤技术等加强平面内的安全保护； d)控制平面做好新增ICMPv6协议安全防护，建议根据实际情况选择合适的安全措施，例如配置ACL白名单，仅允许必须的ICMPv6等报文通过，接口关闭ICMPv6重定向、端口停止发送RA消息，关闭发送ICMP不可达信息，关闭源路由防止Type 0 Routing Header攻击等； e)控制平面通过IPsec、认证以及白名单策略等做好IPv6网络路由等协议安全防护； f)管理平面与IPv4网络类似，通过白名单策略、禁用不使用的IPv6服务等，确保攻击面最小； g)数据平面与IPv4网络类似，配置ACL白名单策略，关闭不必要的服务、禁止源路由，部署IPv6 uRPF等； h)DNS做好IPv6扫描及嗅探的安全检测及防护； i)建议严格限制IPv6同一片报文的分片数目，设置合理的分片缓冲超时时间； j)建议配置端口的最大ND表项学习数量，限制扩展头的数量和同一类型扩展头实例的数目； k)IPv6网络涉及各类服务器、终端、网络设备及应用软件等，设计及开发需要遵从成熟的安全工程方法及规范，确保IPv6协议栈安全质量，同时做好已知漏洞的安全检测及修复； l)IPv6协议攻击的实施目前已有很成熟的开源安全工具套件，例如THC-IPv6、Si6 Networks ipv6-toolkit等，IPv6网络及协议上线运行时，需要提前做好网络中各部分IPv6协议栈健壮性测试、安全渗透测试及安全质量评估，及时削减安全风险； m)基于IPv6的特点和安全威胁分析，确定IPv4升级演进到IPv6的策略，识别IPv6安全产品缺失的现状并补齐，确定改造节奏，升级安全系统。   0x06 参考文档: [1]IPv6的发展和安全性研究 [2]Atlasis, IPv6 Extension Headers: New Features, and New Attack Vectors, IPv6 Security Summit, Troopers 13, Heidelberg, 11-15 March 2013 [3]RFC 2460: Internet Protocol, Version 6 (IPv6) Specification [4]RFC 3756: IPv6 Neighbor Discovery (ND) Trust Models and Threats [5]RFC 4291: IP Version 6 Addressing Architecture [6]RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 Specification [7]RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [8]RFC 4942: IPv6 Transition/Coexistence Security Considerations [9]下一代互联网国家工程中心-全球IPv6测试中心-《2017 IPv6支持度报告》 本文由阿里聚安全发布，转载请注明出处，原文链接：http://jaq.alibaba.com/community/art/show?spm=a313e.7916646.24000001.2.7ac796c4APeSUP&articleid=1258

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/a724888/article/details/78197072 计算机网络 自顶向下方法 第二章 应用层  分类：计算机网络-笔记（2）  版权声明：本文为博主原创文章，未经博主允许不得转载。 目录(?)[+] 第二章 应用层 Tags： 计算机网络 2.1 应用层协议原理 应用层协议只能运行在端系统，这种限制促进了应用程序的开发，即不用考虑底层网络核心的实现。 2.1.1 网络应用程序体系结构 两种主流 应用程序体系结构： 客户-服务器体系结构（CS） 有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。 客户之间不直接通信。 该服务器具有固定的 IP 地址。 P2P 体系结构 应用程序在间断的主机对之间进行直接通信，这些主机对被称为对等方。 2.1.2 进程通信 客户和服务器进程 网络应用程序有成对的进程组成，在两个不同端系统上的 进程，通过跨越计算机网络交换 报文（message）。 通常将两个进程之一标识为 客户，另一个标识为 服务器。 在给定的一对进程之间的通信会话场景中，发起通信的进程被标识为 客户，在会话开始时等待联系的进程是 服务器。 进程与计算机网络之间的接口 进程必须通过一个称为 套接字（socket） 的软件接口向网络发送和接收报文。 在发送端的应用程序将报文推进该套接字，在套接字另一侧，运输层协议负责使该报文进入接收进程的套接字。 套接字也被称为应用程序和网络之间的应用程序编程接口。 开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没有控制权，除了：1. 选择运输层协议（如果可供选择的话）；2. 也许能设定几个运输层参数，如最大缓存和最大报文段长度。 进程寻址 一台主机的进程向另一台主机的进程发送分组，接收进程需要一个地址。为了标识该进程，需要定义两种信息： 主机的地址：用 IP地址 标识； 定义在目标主机中的接收进程的标识符：用目的地 端口号 标识。 2.1.3 可供应用程序使用的运输服务 根据运输层协议为应用层程序提供的服务，按下列要求进行分类：  可靠数据传输  是否容忍数据丢失 吞吐量  应用程序是否对吞吐量有特定的要求，若是，则称为带宽敏感的应用，否则称为弹性应用。 定时  对时延的要求 安全性 2.1.4 因特网提供的运输服务 TCP 服务 TCP 服务模型包括：  面向连接的服务：在应用层数据报文开始流动之前，TCP 让客户和服务器互相交换运输层控制信息，即握手阶段。之后，一条 全双工 的 TCP 连接 就在两个进程的套接字之间建立了。应用程序结束发送报文时，则拆除该连接。 可靠的数据传送服务：通信进程能够依靠 TCP，无差错、按适当顺序交付所有发送的数据。 TCP 协议还具有 拥塞控制机制：  当发送方和接收方之间的网络出现拥塞时，TCP 的拥塞控制机制会抑制发送进程。 TCP 拥塞控制机制也试图限制每个 TCP 连接，使他们达到公平共享网络带宽的目的。 这种服务不一定为通信进程带来直接好处，但是能为因特网带来整体好处。 UDP 服务 UDP 是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。 UDP 是无连接的，因此在两个进程通信之前无握手。 UDP 协议提供一种不可靠数据传送服务，也就是说，当进程将一个报文发送进 UDP 套接字时，UDP 并不 保证该报文到达接收进程。不仅如此，到达接收进程的报文也可能是乱序到达的。 UDP 没有包括拥塞控制机制，所以 UDP 的发送端可以用它选定的任何速率向其下层（网络层）注入数据。 因特网运输协议所不提供的服务 TCP 能提供可靠的数据传输服务，也能通过 SSL 来加强以提供安全服务。 今天的因特网通常能够为时间敏感应用提供满意的服务，但不能提供任何定时或带宽保证。 2.1.5 应用层协议 应用层协议定义了运行在不同端系统上的进程如何相互传递报文。  交换报文的类型，例如请求报文和响应报文。 各种报文类型的语法，如报文中各个字段及这些字段是如何描述的。 字段的语义，即这些字段中包含的信息的含义。 一个进程何时以及如何发送报文，对报文进行响应的规划。 2.2 Web 和 HTTP 2.2.1 HTTP 概况 Web 的应用层协议是 超文本传输协议（HTTP），它是 Web 的核心。 HTTP 由两个程序实现：一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中，通过交换 HTTP 报文进行会话。 HTTP 使用 TCP 作为它的支撑运输协议。  客户首先发起一个与服务器的 TCP 连接。一旦该连接建立，该浏览器和服务器进程就可以通过套接字接口访问 TCP。 HTTP 是一个 无状态协议。服务器向客户发送被请求的文件，而 不存储 任何该客户的状态信息。 Web 使用了 客户-服务器应用程序体系结构。 2.2.2 非持续连接和持续连接 非持续连接 应用程序在采用非持续连接的情况下，客户的每个请求都要建立一个单独的 TCP 连接。 简单估算一下从客户请求 HTML 文件到客户收到文件为止所花费的时间。  下图中，往返时间（RTT）：一个短分组从客户到服务器然后再返回客户所花费的时间。  因此，粗略的讲，总的响应时间就是两个 RTT 加上服务器传输 HTML 文件的时间。 持续连接 在采用持续连接的情况下，服务器再发送响应后保持该 TCP 连接打开。再相同的客户与服务器之间的后续请求和响应报文能够通过相同的连接进行传送。 一般来说，如果一条连接经过一定的时间间隔（一个可配置的时间间隔）仍未被使用，HTTP 服务器就关闭该连接。 HTTP 的默认模式是使用带流水线的持续连接。 2.2.3 HTTP 报文格式 HTTP 请求报文  GET /boyfriend/memory.html HTTP/1.1 Host: www.xinxin.org Connection: close User-agent: Chrome/57.0 Accept-language: ch 1 2 3 4 5 一个请求报文可以具有更多的行或者至少位一行。 第一行叫做 请求行，其后继的行叫做 首部行。 请求行有三个字段：  方法字段：包括 GET、POST、HEAD、PUT 和 DELETE。绝大部分报文使用 GET 方法。 URL 字段 HTTP 版本字段 首部行 Host: www.xinxin.org 指明了对象所在的主机。 首部行 Connection: close 要求服务器发送完请求的对象后就关闭该连接。 首部行 User-agent: Chrome/57.0 用来指明用户代理，即向服务器发送请求的浏览器的类型。 首部行 Accept-language: ch 指明了用户想要得到该对象的中文版本。 下图是请求报文的通用格式  首部行后面的 实体体(Entity body),在使用 GET 方法时为空，使用 POST 方法时才使用该实体体。 HTTP 响应报文   对前一个栗子的响应报文： HTTP/1.1 200 OK Connection: close Date: Tue, 09 Aug 2011 15:44:04 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT Content-Length: 6821 Content-Type: text/html (data data data data data ......) 1 2 3 4 5 6 7 8 9 响应报文分为三个部分：  一个初始 状态行  状态行有三个字段：版本协议字段、状态码和相应状态信息。 下表包括了一些常用的状态码和相关短语 状态码 状态信息 含义 200 OK 请求成功，信息在返回的响应报文中 301 Moved Permanetly 请求的对象已经被永久转移了，新的 URL 定义在相应报文的 Location：首部行中。客户软件将自动获取新的 URL。 400 Bad Request 一个通用差错代码，指示该请求不能被服务器理解 404 Not Found 请求的文档不在服务器上 505 HTTP Version Not Supported 服务器不支持请求报文使用的 HTTP 协议版本 6 个 首部行  就是字面意思，参考上一个栗子的解释。 实体体 下图是响应报文的通用格式  2.2.4 用户与服务器的交互：cookie HTTP 是无状态的，但是 Web 站点通常希望能够识别用户，为此，HTTP 使用了 cookie，它允许站点对用户进行跟踪。 cookie 有 4 个技术组件：  在 HTTP 响应报文中的一个 cookie 首部行； 在 HTTP 请求报文中的一个 cookie 首部行； 在用户端系统中保留有一个 cookie 文件，并由用户的浏览器进行管理； 位于 Web 站点的一个后端数据库。 cookie 的工作过程如下图 2.2.5 Web 缓存 Web 缓存器也叫 代理服务器，是能够代表 Web 服务器来满足 HTTP 请求的网络实体。 Web 服务器有自己的磁盘存储空间，并在存储空间中保存着最近存储过的对象的副本。 可以配置用户的浏览器，使得用户所有的 HTTP 请求首先指向 Web 缓存器。 客户与 Web 缓存器之间的速度通常比较快，所以可以提高访问的速度，降低时延。 客户通过 Web 缓存器请求对象  2.2.6 条件 GET 方法 用来解决 Web 缓存器中的副本可能是旧的的问题。 若同时满足一下两点的则称为 条件 GET 方法：  请求报文使用 GET 方法。 请求报文中包含一个 If-Modified-Since: 首部行。 举个栗子，当一个条件 GET 的首部中包含 If-Modified-Since:wed,7,Sep 2011 09:23:24,该条件 GET 告诉服务器，仅当自该日期后该对象被修改过，才发送该对象。若没有被修改过，服务器仍发送一个响应报文，但并不会在报文中包含所请求的对象，它告诉缓存器可以使用其本地的对象。 2.4 因特网中的电子邮件 电子邮件系统有 3 个主要组成部分：  用户代理 邮件服务器 简单邮件传输协议  2.4.1 SMTP SMTP 是因特网中电子邮件中主要的应用层协议。它使用 TCP 可靠数据传输。 SMTP 限制所有的邮件报文只能采用简单的 7 比特 ASCII 表示。 一个简单的邮件发送过程是：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱上。如下图。  如果 Bob 的邮件服务器没有开机，该报文会保留在 Alice 的邮件服务器上并尝试进行新的尝试。这意味着邮件并不会在中间的某个邮件服务器存留。 注意：SMTP 一般不使用中间服务器发送邮件，即使这两个邮件服务器位于地球的两端也一样。 SMTP 用的是 持续链接：如果发送邮件服务器有几个报文发往同一个接收邮件服务器，它可以通过同一个 TCP 连接发送所有的的报文。 2.4.2 与 HTTP 的对比 相同点：  都用于从一台主机向另一台主机传送文件。 都使用持续连接。 不同点：  HTTP 是一个 拉协议，TCP 连接是由想要接收文件的机器发起的。SMTP 是一个 推协议，TCP连接是由想要发送文件的机器发起的。 SMTP 要求报文必须按照 7 比特 ASCII 码进行编码。HTTP 则没有这种限制。 在处理包含多种不同类型的文档时。HTTP 把每个对象封装到它自己的 HTTP 响应报文中，SMTP 则把所有报文对象放在一个报文中。 2.4.4 邮件访问协议 POP3 IMAP 基于 Web 的电子邮件 2.5 DNS：因特网的目录服务 2.5.1 DNS 提供的服务 主机可以使用 主机名 和 IP 地址 进行标识。 DNS 提供从主机名到IP地址的目录服务。 DNS 即 域名系统是：  一个由分层的 DNS 服务器 实现的分布式数据库。 一个使得主机能够查询分布式数据库的应用层协议。 DNS 协议运行在 UDP 上，使用 53 端口。 DNS 通常是由其他应用层协议所使用的，包括 HTTP，SMTP 和 FTP，将用户的主机名解析为 IP 地址。 DNS 还提供了一些重要的服务：  主机别名 邮件服务器别名 负载分配 2.5.2 DNS 工作机理概述 分布式、层次数据库  有三种类型的 DNS 服务器： 根 DNS 服务器 因特网上的主机的标识有2种方式 1、 主机名，如www.baidu.com 2、 IP地址，如xxx.xxx.xxx.xxx 这两种标识其实指代的是同一样东西，就如你父亲叫你全名和叫你儿子是一样的一个道理。那为什么需要2种标识呢？ 因为我们人类喜欢主机名这种便于记忆的标识，而对路由器来说，它更喜欢定长的、有层次结构的IP地址。我们在浏览器的地址上输入网址时都是输入其主机号。 所以我们需要一种能进行主机名到IP地址转换的服务，也就是域名系统(Domain Name System，DNS)。DNS协议运行在UDP上，使用53号端口。 DNS也是应用层协议，它通常会被其他应用层协议所使用，包括HTTP、SMTP和FTP。 DNS除了将主机名转换为IP地址，还有以下服务 1、识别主机别名（用于HTTP、FTP） 2、识别邮件服务器别名（用于SMTP） 3、负载分配 DNS服务器采用分布式、层次数据库 DNS缓存 与Web缓存器一样，DNS服务器同样有缓存器。 P2P体系结构 相比于客户-服务器体系结构，P2P具有自扩展性，表现在对等方N越大，最小分发时间也趋于平缓。这种自扩展性的直接成因是：对等方除了是比特的消费者外还是它们的重新分发者。 安全性 DDoS（分布式拒绝服务）带宽泛洪攻击：向处理如.com域的域名服务器发送大量DNS请求，使得大部分合法请求无法获得响应 DNS毒害（污染）：给你返回假的或不能用的IP地址。比如中国的『墙』。所以如果你能拿到google的当前IP地址（百度搜的到），手动在hosts里配置，是可以做到直接访问谷歌服务器的。说到翻墙，一般大家都是用某种方法配置一台海外服务器当做中转（国家一般不墙这种个人服务器），来访问墙外服务器的，比如shadowsocks，shadowrocket之类的软件可以用来配置中转服务器。 DNS反射攻击：请求中冒充目标主机源地址，大量请求DNS服务器，DNS就大量向源地址主机发送回答，淹没目标主机 P2P应用 P2P文件分发 在P2P文件分发中，每个对等方能重新分发它所有的该文件的任何部分，可以协助服务器分发 P2P体系结构的扩展性 最小分发时间，对等方N越大，P2P的最小分发时间越小 对等方除了是比特的消费者外还是他们的重新分发者 BitTorrent（没错就是你们老用的种子） P2P文件共享协议，参与一个特定文件分发的所有对等方结合被称为一个洪流（torrent），在一个洪流的对等方彼此下载等长度的文件块，可以随时离开洪流，也可继续向其他对等方上载 Alice加入某洪流时，会在追踪器里进行注册，周期性通知追踪器它仍在洪流中。 洪流随机从参与对等方的结合中选择一个子集，将他们的IP地址发给Alice，Alice维护这张对等方列表，视图与所有对等方建立并行的TCP连接。 Alice周期询问每个邻近对等方（连上的）他们有的文件块列表，她随时知道邻居有哪些文件块 Alice使用最稀缺优先技术，首先请求那些邻居们副本数量最少的块，使该文件块迅速分发，以均衡每个块在洪流中的副本数量 BitTorrent使用一种算法，Alice优先从像她传时速度最快的邻居（4个，每10s修改一次）那里获取文件块。 每过30s，Alice也要随机选择另外一个对等方Bob，向他发送块。若Alice是Bob最快的前四快，Bob也是Alice的前4快，则Bob和Alice互相发送数据。 每过30s换一个新的对象，互相交换数据（一报还一报），为了使对等方能够找到彼此协调的速率上传 BitTorrent其他机制和变种 片、流水线、随机优先选择、残局模型、反怠慢等机制 变种：P2P直播流式应用，如PPLive和PPstream 分布式散列表（DHT） 分布式、P2P版本的key-value数据库，在大量对等方上存储key-value值（键值对） 分布式数据库用来定位拥有某key-value的对等方，然后向查询方返回该键值对 环形DHT、对等方扰动（了解即可） 微信公众号【黄小斜】大厂程序员，互联网行业新知，终身学习践行者。关注后回复「Java」、「Python」、「C++」、「大数据」、「机器学习」、「算法」、「AI」、「Android」、「前端」、「iOS」、「考研」、「BAT」、「校招」、「笔试」、「面试」、「面经」、「计算机基础」、「LeetCode」 等关键字可以获取对应的免费学习资料。                       ​

第一套801.11ac芯片即将来到，但802.11n可能还会存在很多年，无论是企业还是家庭使用。然而，n标准承诺的300Mbps(兆比特每秒)很少实现，并且它被证明给50/100Mbps宽带连接、1080p视频流、大规模备份等带来巨大瓶颈问题。在企业方面，一些琐碎的工作(例如远程桌面或实时协作)都受到糟糕的Wi-Fi连接的影响。 　　在我们的测试中，我们经常会看到这样的结果：通过802.11n连接，只相隔几米(中间只有一面墙)的设备速度会下降到只有2-15Mbps，这里就是你会遇到的问题： 　　1. 0.5-2 Mbps： 对于这个速度，足够你应付所有基本的聊天和邮件服务，不过加载一些内容丰富的网站时会比较慢。 　　2. 4-5 Mbps：足够处理所有网站和基本视频流 　　3. 20+ Mbps：这是HD流需要的最低速度。一个典型码率的720p iTunes电视节目是2-6Mbps，你的路由器需要补偿给其他连接的客户端和预缓冲。 　　4. 50+ Mbps：可以支持1080p电影和空中备份。 　　如果你很憎恨如此慢的Wi-Fi速度，但又不想回到以太网，我们为你提供了一些技巧来提高速度。 　　1.检查你的路由器的生态设置 　　有些路由器在默认情况下被设置为“省电”模式，其目标：节约几毫瓦电。但是，这种值得称道的方法会相应地减少带宽。虽然我信任的Linksys WRT610N路由器并没有设置为这种不必要的省电模式，不过我其调为省电模式来看这样做对带宽的影响。 　　如果比起节省几毫瓦电，你更重视带宽，那么请检查路由器的设置，找到被称为“发射功率”或者各种Eco模式的选项，并将它们关闭。此外，检查你的路由器是否开启了某些“自动”传输设置，你应该将其关闭。 　　2.克服物理规律 　　有时候，物理定律也会影响无线带宽和信号强度。首先，你的路由器和无线适配器之间的距离对网速的影响比你想象中的更大。这里有一个经验法则：只要路由器和客户端之间的距离增加一倍，吞吐量将会下降到原始值的三分之一。无线中继器(可能花费在20-100美元之间)将明显提高你的信号强度。 　　除了距离，其他无线信号杀手包括影响吞吐量的对象和元素，也就是水和金属。水会阻止2.42GHz的信号，所以你最好将你家里或者办公室所有包含任何形式液体的对象(这包括散热器和花盆，这不是开玩笑!)拿走。同时，还要确保路由器和客户端之间没有金属，例如金属家具以及金属板、高科技装备等。 　　请记住，光滑且有光泽的表面会反射信号，从而影响信号强度。 　　3. 升级你的路由器的天线 　　数据包丢失和较弱的吞吐量通常是糟糕的天线设计造成的。好消息是：你可以使用更强大的天线来取代路由器中的内置天线。这个有一点麻烦，但是它会让你明显感觉到缓慢连接和快速连接到路由器之间的区别。 　　根据你的设置，你可以选择全向天线或者定向天线(如果需要良好吞吐量的大部分设备都在一个房间里)。 　　4.找出放置路由器的最佳地点 　　使用无线热映像工具来衡量距离、频率变化和建筑结构对信号强度的影响，有两个值得推荐的工具就是NetSpot(针对Mac)和Heatmapper(针对Windows)，这两个工具都可以帮助你跟踪办公室或者家庭的无线覆盖情况。在我们的测试中，我们将向你展示NetSpot的工作原理：在安装好这个软件后，在“Site Survey”中输入新名称，然后点击“Blank Map(空白地图)”。你也可以选择家中或者办公室的平面图，来获取更精确的地图。如果你想更富创意的话，我建议你选择“Draw Map(绘制地图)”功能，并开始绘制自己的平面图。下一步，确定两个地点之间的精确距离，点击“让我们开始吧”，然后走到一个点，点击你目前在平面图上的位置： 　　显然，你扫描的点越多，你的无线热图更精确。完成这些步骤后，你将得到一个地图显示信号强度，同时显示无线网络的吞吐量情况。 　　5.不同的CPU频率及其对无线信号的影响 　　你的电脑主板也是以“千兆赫”频谱运行，这个“噪音”会被内置无线发射器检测到。不幸的是，这个噪音越高，你的无线路由器就越有可能自动降低带宽(通过降低链路速率和避免频率干扰)。由于现在的CPU频率是动态的，无线适配器需要不断适应链路速率，这不仅会导致Mbps的变化，而且可能会造成连接断开。尤其是在笔记本电脑上，无线适配器通常内置在内存和CPU总线旁边，这是问题的主要根源。 　　当然，这一切都取决于你的无线适配器的设计，但是如果上述症状正是你面对的问题，你可能需要通过配置一个外部适配器来解决问题。有一些适配器(例如Linksys适配器)会有一个通过较长的USB电缆连接的支架，通过这种方式来拉开无线适配器和CPU噪音之间的距离将很有帮助。当然，当你在外办公时，这个方法不太方便，不过，在家里使用时，这是个可行的办法。典型的无线适配器(例如Linksys AE2500，802.11n双频)或者MSI US310EX都非常好用。 　　6.固件或驱动程序问题 　　一个简单但常常被人遗忘的建议就是：确保你的路由器固件是最新版本，特别是当你购买了一个新的路由器时。通过前几个固件更新，预计带宽、功能集和信号弹性都会得到提升。(我的Linksys只有在更新后才能提供到客厅的完全带宽)。 　　另外，请确保无线适配器(无论是外配还是内置)始终保持最新版本。在升级到下一个适配器驱动程序的版本后，待机问题、性能低等问题都将得到解决。虽然近年来通过Windows Update交付的驱动程序变得更好了，但是却很少提供给你最新最好的驱动程序。你可以这样做： 　　查看更新的第一个地方是制造商的支持页面。但是如果他们的驱动程序领域没有得到很好的维护的话，你可以去芯片组制造商的网站。我们经常会看到无线适配器的芯片组被收购，然后采用新品牌名称。例如，我们的Linksys WUSB 600N适配器就采用了台湾制造商Ralink生产的RT2870芯片组。所以说，直接去芯片组制造商的网站找更新程序是一个聪明的办法。 　　查看他们的支持/下载页面，输入你的电子邮件地址，然后获取驱动程序。 　　想要知道你使用的是什么芯片组，可以检查无线适配器的规格表。 　　7.选择合适的通道 　　你的路由器设置好后，它会自动检测最不拥挤的通道，然后将其设置为默认通道。但是，随着新邻居或者办公室的出现，这个情况可能会迅速发生改变：突然间，某个通道会被很多路由器占据，而其他通道则没人使用。InSSIDer可以帮助你解决这个问题：这个工具会分析整个无线频谱，然后为你提供家庭网络的详细情况已经通道使用情况。 　　我很惊讶地发现我在与其他四个路由器共享通道1。这并不是最理想的情况。因为通道9并没有被使用，所以，我改为使用这个通道，这帮助我明显地改善了延迟和吞吐量。 　　8.使用你的路由器的5GHz网络 　　2.4GHz频率很拥挤，不仅因为邻居使用相同的频率，而且还有婴儿监护器、无绳电话、微波炉等。现代802.11n路由器提供“双频”，这意味着它们发送两个网络信号：一个在2.4GHz，一个在5GHz，这个一点都不拥挤，且提供更多通道。那么，为什么我们不跳到5GHz，享受一个不太拥挤且速度更快的无线频率呢?不幸的是，很多设备制造商认为应该在无线芯片方面节省成本，而只选择了2.4GHz接收器，这包括所有便携式游戏机，还有很多Android手机，所有苹果iOS设备和Windows Phone。我的建议是：同时激活这两个网络，连接移动设备到2.4GHz网络。为你的笔记本电脑和台式机启用5GHz网络。 　　9.限制你的路由器的频段 　　有时候，你没有办法选择5GHz频段或者选择一个“不拥挤”的通道，在这种情况下，你可以限制你的路由器在20MHz的间隔来发送信号，虽然这可能会降低整体吞吐量，但会给你一个更强的信号。 　　10.测试连接情况 　　有很多无线监测工具可以衡量上述我们给出的解决方法。然而，其中最精确的工具要数iPerf，这个工具在你想要测量的笔记本或PC上有一个客户端，然后在PC上有一个服务器工具直接连接到路由器。在两端都部署了分析器后，你就知道你的无线速度的情况了。 　　我的建议是：在你家里或者办公室，对路由器和客户端测试不同位置无线速度，热映像图将会为你指出最佳地点。

欢迎转载，转载请注明来源：github地址 谢谢点赞 相关书籍下载 测试开发 Web UI测试自动化 splinter - web UI测试工具，基于selnium封装。 链接 selenium - web UI自动化测试。 链接 --推荐 文档参考 mechanize- Python中有状态的程序化Web浏览。链接 selene - 使用Python + Ajax支持+ PageObjects + Widgets进行简明UI测试 链接 hitch - 基于服务的应用程序的高级集成测试框架。链接 Needle - Css 自动化测试框架。链接 seleniumbase - 端到端自动化测试框架。链接 pytest_splinter - pytest spinter和selenium集成。 链接 Browsermob Proxy - Browsermob Proxy的python包装器。 链接 Selenium-Requests - 扩展Selenium WebDriver类以包含请求库中的请求函数，同时完成所有需要的cookie和请求头处理。链接 移动测试自动化 appium - 移动端UI自动化测试。 链接 --推荐 uiautomator- 安卓UI自动化测试。 链接 ATX - 智能手机自动化工具。支持iOS，Android，WebApp和游戏。 网易出品 链接 --推荐 uiautomator2- Android Uiautomator2 Python Wrapper。 链接 --推荐 facebook-wda Facebook WebDriverAgent Python Client Library (not official) 可用于IOS应用测试。 链接 --推荐 Windows UI测试自动化 Winium.Desktop - 开源测试自动化工具，用于基于WinForms和WPF平台自动测试Windows应用程序，基于Selenium远程WebDriver实现。 链接 pyautogui- 跨平台的UI自动化工具，控制鼠标和键盘。 链接 autopy - 简单的跨平台GUI自动化工具包，适用于Python。 链接 pywinauto - Windows UI自动化。 链接 SikuliX - 基于OpenCV的GUI测试框架，使用图像识别来定位与之间的项目，来自python 2.7的脚本，跨平台。链接 UI测试 pyautoacad - AutoCAD自动化。 链接 sikuli - 位图自动化。 链接 monkeyrunner- 安卓自动化。 链接 ldtp - Linux UI自动化。 链接 dogtail- Linux UI自动化。 链接 pyautoit- autoit python api。 链接 雪峰磁针石说明: autopy、WATSUP、winGuiAuto因为较长时间未更新未收录 性能测试 软件测试专家工具包2性能测试 https://china-testing.github.io/testing_tools_perf.html funkload - 性能及功能测试工具。 链接 --推荐 Locust.io – 了解服务器端性能的好工具。 语言python3。源码 python3+ python2.7+ github上star和fork最多的性能测试工具。 --强烈推荐 Bees with Machine Guns – 进行负载测试的蜜蜂(微型EC2实例)。 语言python3+ python2.6+ --强烈推荐 Multi-Mechanize – 用于性能和负载测试的开源框架，它运行并发Python脚本以生成针对远程站点或服务的负载(复合事务)。它通常用于Web性能和扩展性测试，但您也可以使用Multi-Mechanize来测试任何远程API。 --基于python多进程和多线程实现，学习自行开发性能测试的佳品。 Python 2.6 or 2.7 较长时间没有更新，一般只建议改造使用。 ngrinder - 市面上最强大的性能测试工具之一，主要用jython书写脚本，性能在loadrunner和jmeter之上，扩展性好。 链接 --强烈推荐 boom - 类似ab(ApacheBench)的性能测试工具。 链接 测试框架 pyresttest 接口测试框架 -- 推荐 HttpRunner HTTP接口测试框架 -- 推荐 augmented-traffic-control facebook开发的最强悍弱网网络模拟工具 --强烈推荐 Hypothesis - 高级单元测试测试框架，支持行为驱动，基于property 。 链接 -- 推荐 unittest - (Python 标准库) 单元测试框架 链接 -- 推荐 mamba - 行为驱动测试框架。 链接 nose- 更好的单元测试框架。 链接 -- 推荐 nose2- nose基于unittest2的版本。 链接 pytest- 很好的强大的单元测试框架，实际上广泛使用在自动化单元、接口、功能等测试。 链接 -- 强烈推荐 参考 testify - 单元测试框架，提供增强的测试fixture设置，将测试套件拆分成易于并行化的存储bucket，PEP8命名约定，带有大量日志/报告选项及颜色测试运行器。链接 trial - Twisted的单元测试框架，基于unittest。链接 Robot Framework- 通用的python测试框架，易于上手，生成的报告比较好看，适合小型公司使用，支持关键字和数据等驱动，系业界内很出名的框架。不过因为写用例不能很灵活的应用python，需要大量的python封装，大公司通常使用pytest，django，flask之类的库自行开发。 链接 green- 彩色(命令行能显示多种颜色)的单元测试框架。 链接 tox- 基于virtualenv的测试框架，主要用于解决多版本python问题。 链接 sixpack- A/B 测试框架。 链接 lettuce- 行为驱动 测试框架。 链接 pyccuracy- 行为驱动 web验收测试框架。 链接 pytest-bdd- 基于pytest的行为驱动 测试框架。 链接 ddt- 数据驱动测试。 链接 behave- 行为驱动测试。 链接 lettuce- 行为驱动测试。 链接 mamba - Python的测试定义工具，基于行为驱动。链接 pyvows - Python的异步行为驱动开发，Vows.js的python移植。链接 pyhamcrest - Python的Hamcrest匹配器。 链接 sure - 强大而灵活的断言python测试库。链接 factory_boy - 基于thinkbot的factory_girl的fixture替代。链接 Mock doublex：强大的测试桩框架。链接 mock：(Python3 标准库) mock和patch。链接 freezegun：伪造时间。[链接]https://github.com/spulec/freezegun) httmock：Python 2.7+ 和 3.4+ mock requests库。链接 httpretty：Python 的 HTTP 请求 客户端mock 工具，暂时不支持python3。链接 responses：针对requests 库的mock库。链接 VCR.py：录制HTTP请求加快测试执行速度并可进行mock。链接 -- 推荐 factoryboy：Python测试fixtures(setup和teardown)替代库。链接 mixer：另外一个测试fixtures(setup和teardown)替代库，支持 Django, Flask, SQLAlchemy, Peewee 等。链接 modelmommy：为 Django测试创建随机fixtures 链接 faker：生成多种伪数据。链接 fake2db：伪造数据库生成器。链接 mimesis：生成mock数据。[链接]https://github.com/lk-geimfari/mimesis) 雪峰磁针石说明: radar 因为github星级太少而未收录 最近版本参见原文：https://github.com/china-testing/python-api-tesing 其他测试工具 coverage：代码覆盖率。链接 FuckIt.py：代码出错也可以执行。链接 RoboBrowser：一个简单的，Python 风格的库，用来浏览网站，而不需要一个独立安装的浏览器。链接 MechanicalSoup：用于自动和网络站点交互的 Python 库。链接 augmented-traffic-control：网络模拟工具。链接 -- 强烈推荐 持续交付 buildbot - google等公司使用的持续集成框架，上手比Jenkins难，功能和性能远比Jenkins强大。 链接 python库介绍-buildbot教程 BitBake – 嵌入式Linux上类似make工具。链接 buildout – 用于从多个部分创建，组装和部署应用程序的构建系统。链接 PlatformIO – 在不同的开发平台的控制台构建工具。链接 PyBuilder – 纯Python编写的持续构建工具。链接 SCons – 软件构建工具。链接 测试工具对接 jira –自动化JIRA。链接 awesome-python 管理面板(Admin Panels) Ajenti - Linux & BSD web管理面板。管理进程和文件等。 链接 django-suit - 现代主题的Django管理界面(仅限非商业用途)。链接 django-xadmin - 方便的Django admin替代。 完全支持插件扩展，基于 Twitter Bootstrap，并有站内书签、支持 xls, csv, xml和json数据导入等不少增强。 链接 flask-admin - Flask的简单和可扩展的 web 管理界面框架。 链接 flower - Celery的实时监控和网络。 链接 Grappelli - Django管理界面的爵士皮肤。[链接]https://github.com/sehmaschine/django-grappelli) Wooey - 为Python脚本创建自动Web UI的Django应用程序。 链接 算法和设计模式(Algorithms and Design Patterns) Python的算法和设计模式的实现。 algorithms - Python的算法模块。 链接 PyPattyrn - 简单有效实现通用设计模式。 链接 python-patterns - Python中设计模式的集合。 链接 sortedcontainers - SortedList，SortedDict和SortedSet类型的快速，纯Python实现。 链接 反病毒(Anti-spam) django-simple-captcha - 简单且高度可定制的Django应用，可以将验证码图像添加到任何Django表单。 链接 雪峰磁针石说明: django-simple-spam-blocker因为github星级太少而未收录 最近版本参见原文：https://github.com/china-testing/python-api-tesing 资产管理(Asset Management) 用于管理，压缩和缩小网站资产的工具。 django-compressor - 将链接和内联的JavaScript或CSS压缩到单个缓存文件中。 链接 django-pipeline - Django的资产包装库。 链接 django-storages - Django自定义存储后端集。 链接 fanstatic - 用 Python 的包的方式封装，优化静态文件并解依赖。 链接 fileconveyor - 检测和同步文件到CDN，S3和FTP的后台程序。 链接 flask-assets - 集成web 资源到Flask应用。 链接 jinja-assets-compressor - Jinja扩展程序，用于编译和压缩资源。 链接 -- github星级不到100. webassets - 为静态资源打包，优化和管理基于缓存的唯一URL。 链接 音频(Audio) 操作音频的库。 audiolazy - 数字信号处理(DSP)软件包。 链接 audioread - 跨库(GStreamer +Core Audio+ MAD + FFmpeg)音频解码。链接 beets - 音乐库管理和MusicBrainzb标签。链接 -- 推荐 dejavu - 音频指纹识别。链接 -- 推荐 id3reader - 用于读取MP3元数据的Python模块。链接 m3u8 - 解析m3u8文件的模块。链接 mingus - 先进的音乐理论和MIDI文件和播放支持符号包。链接 mutagen - 用于处理音频元数据的Python模块。链接 pyAudioAnalysis - Python音频分析库：特征提取，分类，分割和应用。链接 -- 推荐 pydub - 通过简单易用的高级界面处理音频。链接 -- 推荐 pyechonest - Echo Nest API的Python客户端。链接 talkbox - 用于语音/信号处理的Python库。链接 TimeSide - 开放的Web音频处理框架。链接 tinytag - 用于读取MP3，OGG，FLAC和Wave文件的音乐元数据的库。链接 雪峰磁针石说明: django-elastic-transcoder， eyeD3 因为github星级太少而未收录 scikits.talkbox 因长时间未更新未收录 最近版本参见原文：https://github.com/china-testing/python-api-tesing 认证(Authentication) Authomatic：简单但是强大的框架，身份验证/授权客户端。链接 django-allauth：Django 的验证应用。链接 django-oauth-toolkit： Django OAuth2。链接 django-oauth2-provider：Django OAuth2。链接 Flask-OAuthlib： Flask OAuthlib 。链接 OAuthLib： 通用完整的实现OAuth请求-签名逻辑。链接 python-oauth2：创建 OAuth 客户端和服务端完全测试的抽象接口。链接 python-social-auth：设置简单的社交认证。链接 rauth：OAuth 1.0/a, 2.0, 和 Ofly。链接 sanction：一个超级简单的OAuth2 客户端实现。链接 PyJWT：JSON Web 令牌草案 01。链接 python-jwt：生成和验证 JSON Web 令牌。链接 雪峰磁针石说明: jose，python-jws因为github星级太少而未收录 scikits.talkbox 因长时间未更新未收录 内置类增强(Built-in Classes Enhancement) attrs - 替换类定义中的__init__，__eq__，__repr__等样板文件。 bidict - 高效的双向字典。 Box - 点符号访问的Python字典 区块链(Blockchain) blockchain - 简单的区块链。 bidict - 高效的双向字典。 Box - 点符号访问的Python字典 CMS(Content Management Systems) 内容管理系统 django-cms：开源的，基于Django的企业级 CMS。链接 djedi-cms：轻量级但却非常强大的 Django CMS ，考虑到了插件，内联编辑以及性能。[链接]http://djedi-cms.org/) FeinCMS：基于 Django 构建的最先进的内容管理系统之一。链接 Kotti：高层的的web应用框架，基于 Pyramid 构建。链接 Mezzanine：强大的，一致的，灵活的内容管理平台。链接 -- 推荐 Opps：杂志，报纸网站以及大流量门户网站设计的 CMS 平台，基于 Django。[链接]https://github.com/opps/opps) Plone：构建于开源应用服务器 Zope 之上的 CMS。链接 Quokka：灵活，可扩展的小型 CMS，基于 Flask 和 MongoDB。链接 Wagtail：Django 内容管理系统。链接 -- 推荐 Widgy： CMS 框架，基于 Django。链接 缓存(Caching) 缓存数据的库。 Beaker：缓存和会话库，可以用在 web 应用和独立 Python脚本和应用上。链接 DiskCache：Python磁盘缓存(Django兼容)。。链接 django-cache-machine：Django 模型的自动缓存和失效。链接 django-cacheops：具有自动颗粒化事件驱动失效功能的 ORM。链接 dogpile.cache：dogpile.cache 是 Beaker 的替代，由同一作者开发。链接 HermesCache：Python 缓存库，具有基于标签的失效和 dogpile effect 保护功能。链接 johnny-cache：django应用缓存框架。[链接]https://github.com/jmoiron/johnny-cache) pylibmc：libmemcached 接口的 Python 封装。链接 雪峰磁针石说明: django-viewlet因为github星级太少而未收录 自动聊天工具(ChatOps Tools) Errbot：最简单和最流行的聊天机器人用来实现自动聊天工具。链接 代码分析和lint(Code Analysis) coala：语言独立和易于扩展的代码分析应用程序。链接 code2flow：把你的 Python 和 JavaScript 代码转换为流程图。暂时无法继续维护。链接 pycallgraph：这个库可以把你的Python 应用的流程(调用图)进行可视化。链接 Flake8：模块化源码检查工具: pep8, pyflakes 以及 co。链接 Pylint：一个完全可定制的源码分析器。链接 pylama：python代码审计。链接 YAPF: Google的Python代码格式化工具。链接 --推荐 pylama：Python 和 JavaScript 的代码审查工具。链接 autopep8：自动格式化 Python 代码，以使其符合 PEP8 规范。链接 --推荐 mypy ：静态类型检查。链接 --推荐 pep8 ：python风格检查。链接 --推荐 prospector - 分析Python代码并输出有关错误，潜在问题，违反常规和复杂性的信息的工具。链接 命令行工具(Command-line Tools) 命令行程序开发( Command-line Application Development) asciimatics：跨平台，全屏终端包(即鼠标/键盘输入和彩色，定位文本输出)，完整的复杂动画和特殊效果的高级API。链接 cement：Python 的命令行程序框架。链接 click：一个通过组合的方式来创建精美命令行界面的包。链接 --推荐 cliff：一个用于创建命令行程序的框架，可以创建具有多层命令的命令行程序。链接 clint：Python 命令行程序工具。链接 colorama：跨平台彩色终端文本。链接 docopt：Python 风格的命令行参数解析器。链接 --推荐 Gooey：一条命令，将命令行程序变成一个 GUI 程序。链接 Python-Fire：将命令行程序变成一个 GUI 程序。链接 --推荐 python-prompt-toolkit：构建强大的交互式命令行程序的库。链接 --推荐 Pythonpy：在命令行中直接执行任何Python指令。链接 生产力工具(Productivity Tools) aws-cli：Amazon Web Services 的通用命令行界面。链接 bashplotlib：在终端中进行基本绘图。链接 caniusepython3：判断是哪个项目妨碍你你移植到 Python 3。链接 cookiecutter：从 cookiecutters(项目模板)创建项目的一个命令行工具。链接 doitlive：一个用来在终端中进行现场演示的工具。链接 howdoi：通过命令行获取即时的编程问题解答。链接 --推荐 httpie：命令行HTTP 客户端，cURL 的替代品，易用性更好。链接 PathPicker：从bash输出中选出文件。链接 percol：向UNIX shell 传统管道概念中加入交互式选择功能。链接 SAWS：一个加强版的 AWS 命令行。链接 thefuck：修正你之前的命令行指令。链接 mycli：一个 MySQL 命令行客户端，具有自动补全和语法高亮功能。链接 --推荐 pgcli：Postgres 命令行工具，具有自动补全和语法高亮功能。链接 --推荐 try：很简单的命令行工具，用来试用python库。链接 兼容性(Compatibility) 帮助从 Python 2 向 Python 3迁移的库。 Python-Future：这就是 Python 2 和 Python 3 之间丢失的那个兼容性层。链接 Python-Modernize：使 Python 代码更加现代化以便最终迁移到 Python 3。[链接]https://github.com/mitsuhiko/python-modernize) Six：Python 2 和 3 的兼容性工具。链接 计算机视觉(Computer Vision) 计算机视觉库。 OpenCV：开源计算机视觉库。链接 2018最佳人工智能图像处理工具OpenCV书籍下载 pyocr：Tesseract 和 Cuneiform 的包装库。链接 pytesseract：Google Tesseract OCR 的另一包装库。链接 文档 SimpleCV：一个用来创建计算机视觉应用的开源框架。链接 并发和并行及异步与网络(Concurrency and Parallelism) 用以进行并发和并行操作的库。 multiprocessing：(Python 标准库) 基于进程的“线程”接口。链接 --推荐 threading：(Python 标准库)更高层的线程接口。 链接　--推荐 eventlet：支持 WSGI 的异步框架。链接 gevent：一个基于协程的 Python 网络库，使用greenlet。链接　--推荐 Tomorrow：用于产生异步代码的神奇的装饰器语法实现。 链接　 uvloop：在libuv之上超快速实现asyncio事件循环。链接　--推荐 asyncio - (Python 标准库) 异步 I/O, 事件循环, 协程以及任务 链接　--推荐 aiohttp 异步http client/server框架(asyncio) 链接 --推荐 curio 协程并发库. 链接 pulsar - 事件驱动的并发框架. 链接 pyzmq - ZeroMQ 消息库的 Python 封装. 链接 Twisted - 事件驱动的网络引擎. 和asyncio有很多类似的地方，逐渐被代替,需要数据库等相关生态圈的支持 链接 diesel - 基于Greenlet 的事件 I/O 框架。. 链接 Tornado - web 框架和异步网络库. 链接 Trio – 异步I/O 链接 可能会飙升 NAPALM - 处理网络设备的跨供应API. 链接 txZMQ - 基于 Twisted 的 ZeroMQ 消息库的 Python 封装。链接 配置(Configuration) 用来保存和解析配置的库。 config：logging 模块作者写的分级配置模块。链接 -- 较长时间未更新 ConfigObj：INI 文件解析器，带验证功能。链接 ConfigParser：(Python 标准库) INI 文件解析器。链接 profig：通过值转换配置多种格式。链接 python-decouple：将设置和代码完全隔离。链接 加密(Cryptography) cryptography：这个软件包意在提供密码学基本内容和方法提供给 Python 开发者。链接 hashids：在 Python 中实现 hashids 。链接 Paramiko：SSHv2 协议的 Python (2.6+, 3.3+) ，提供客户端和服务端的功能。链接 -- 推荐 Passlib：安全密码存储／哈希库，链接 PyCrypto：Python 密码学工具箱。链接 PyNacl：网络和密码学(NaCl) 库的 Python 绑定。链接 数据分析(Data Analysis) blaze：NumPy 和 Pandas 的大数据接口。链接 Open Mining：使用 Python 挖掘商业情报 (BI) (Pandas web 接口)。链接 orange：通过可视化编程或 Python 脚本进行数据挖掘，数据可视化，分析和机器学习。链接 Pandas：提供高性能，易用的数据结构和数据分析工具。链接 --强烈推荐 书籍：利用Python进行数据分析 2017 第二版 代码 链接 --推荐 利用Python进行数据分析·第2版 --推荐 数据验证(Data Validation) 数据验证库。多用于表单验证。 Cerberus： 轻量级可扩展的数据验证库.链接 colander：验证并反序列化XML、JSON、HTML表单获取的数据。链接 colander：json模式的实现。链接 kmatch：一种用于匹配/验证/筛选 Python 字典的语言。[链接]() schema：一个用于对 Python 数据结构进行验证的库。[链接]() Schematics：人性化的python数据结构。链接 valideer：轻量级可扩展的数据验证和适配库。链接 voluptuous：Python 数据验证库。主要是为了验证传入 Python的 JSON，YAML 等数据。链接 数据可视化(Data Visualization) 进行数据可视化的库。 参见: awesome-javascript。 matplotlib：Python 2D 绘图库。链接 --推荐 bokeh：用Python进行交互式web绘图。链接 --推荐 英文快速入门 中文快速入门 ggplot：ggplot的 Python移植。链接 -荐 plotly：交互式基于浏览器的绘图。链接 pyecharts：基于百度 Echarts 的数据可视化库。链接 -荐 pygal：Python SVG 图表创建工具。链接 pygraphviz：Graphviz 的 Python 接口。链接 PyQtGraph：交互式实时 2D/3D/ 图像绘制及科学/工程学组件。链接 SnakeViz：基于浏览器的 Python cProfile 模块输出结果查看工具。链接 vincent：把 Python 转换为 Vega 语法的转换工具。链接 VisPy：基于 OpenGL 的高性能科学可视化工具。链接 Altair - 用于Python的声明式统计可视化库。链接 bqplot - Jupyter Notebook的互动绘图库。链接 Seaborn - 使用Matplotlib进行统计数据可视化。链接 -荐 plotly.py 交互式基于浏览器的绘图 -荐 A Dramatic Tour through Python’s Data Visualization Landscape (including ggplot and Altair) Python data visualization: Comparing 7 tools 10 Useful Python Data Visualization Libraries for Any Discipline Overview of Python Visualization Tools Effectively Using Matplotlib pyecharts + notebook Bokeh vs Dash 01+ Resources to Learn Data Science chinese 数据库(Database) Python实现的数据库。 pickleDB：简单，轻量级键值储存数据库。链接 PipelineDB：流式 SQL 数据库。链接 TinyDB：轻型的，面向文档型数据库。链接 ZODB： Python 原生对象数据库。键值和对象图数据库。链接 数据库驱动(Database Drivers) 连接和操作数据库的库。 mysql-python：Python 的 MySQL 数据库连接器。链接 不支持python3，不推荐 PyMySQL：纯 Python MySQL 驱动，兼容 mysql-python。链接 --推荐 mysql-connector-python：mysql官方python API。链接 --推荐 psycopg ：Python 中最流行的 PostgreSQL 适配器。链接 --推荐 queries：psycopg2 库的封装，用来和 PostgreSQL 进行交互。链接 txpostgres：基于 Twisted 的异步 PostgreSQL 驱动。链接 apsw：另一个 Python SQLite 封装。链接 dataset：在数据库中存储 Python 字典 pymssql：简单的 Microsoft SQL Server 数据库接口。[链接](https://github.com/pudo/dataset) cassandra-python-driver：Cassandra 的 Python 驱动。链接 HappyBase：Apache HBase。链接 Plyvel：快速且功能丰富的 LevelDB 的 Python 接口。链接 pycassa：Cassandra 的 Python Thrift 驱动。链接 PyMongo：MongoDB 的官方 Python 客户端。链接 -- 推荐 redis-py：Redis 的 Python 客户端。链接 -- 推荐 telephus：基于 Twisted 的 Cassandra 客户端。链接 txRedis：基于 Twisted 的 Redis 客户端。链接 日期和时间(Date and Time) 操作日期和时间的类库。 arrow：更好的 Python 日期时间操作类库。链接 -- 推荐 Chronyk：Python 3 的类库，用于解析手写格式的时间和日期。链接 dateutil：Python datetime 模块的扩展。链接 delorean：解决 Python 中有关日期处理的棘手问题的库。链接 moment：用来处理时间和日期的 Python 库。灵感来自于 Moment.js。链接 pendulum：更处理datetime。链接 PyTime：简单易用的 Python 模块，用于通过字符串来操作日期/时间。链接 pytz：现代以及历史版本的世界时区定义。将时区数据库引入 Python。链接 --推荐 when.py：提供用户友好的函数来帮助用户进行常用的日期和时间操作。链接 when.py：人性化的datetime。链接 调试工具(Debugging Tools) 代码调试的库。 ipdb：IPython的 pdb。链接 pudb：pdb的替代。链接 -- 推荐 pudb：全屏，基于控制台的 Python 调试器。链接 pyringe：可以在 Python 进程中附加和注入代码的调试器。[链接]() wdb：一个奇异的 web 调试器，通过 WebSockets 工作。[链接]() winpdb：一个具有图形用户界面的 Python 调试器，可以进行远程调试，基于 rpdb2。[链接]() django-debug-toolbar：为 Django 显示各种调试信息。[链接]() django-devserver：一个 Django 运行服务器的替代品。[链接]() flask-debugtoolbar：django-debug-toolbar 的 flask 版。[链接]() 性能分析器 lineprofiler：逐行性能分析。[链接]() Memory Profiler：监控 Python 代码的内存使用。官网、内存 profiling：一个交互式 Python 性能分析工具。[链接]() 其他 pyelftools：解析和分析 ELF 文件以及 DWARF 调试信息。[链接]() python-statsd：statsd 服务器的 Python 客户端。[链接]() 深度学习(Deep Learning) 机器学习库。 参见:awesome-deep-learning.* 2018最佳机器学习工具书及下载(持续更新) Caffe - 快速开放的深度学习框架 --推荐 Keras - 高级神经网络库，能够在TensorFlow或Theano之上运行。 --推荐 MXNet - 高效率和灵活的深度学习框架。 Neupy - 运行和测试不同的人工神经网络算法. Pytorch - Python中的张量和动态神经网络，具有强大的GPU加速功能。 --推荐 Serpent.AI - 游戏代理框架。 使用任何视频游戏作为深度学习沙盒。 --推荐 TensorFlow - 由Google创建的最受欢迎的深度学习框架。 --强烈推荐 Theano - 用于快速数值计算的库. --推荐 DevOps工具(DevOps Tools) DevOps的软件和库。* Ansible - 极其简单的IT自动化平台。 --推荐 Cloud-Init - 处理云实例的早期初始化的多分发包。 cuisine - 为 Fabric 提供一系列高级函数。 Docker Compose - 使用Docker的快速隔离开发环境。 --推荐 Fabric - 简单的Pythonic远程执行和部署工具。 --推荐 Fabtools - 编写真棒Fabric文件的工具。 honcho - 一个[Foreman]的Python克隆(https://github.com/ddollar/foreman)，用于管理基于Procfile的应用程序。 nova - OpenStack计算。 --推荐 swift - OpenStack存储。 --推荐 pexpect - 在像GNU expect这样的伪终端中控制交互式程序。 --强烈推荐 psutil - 跨平台的进行和系统实用程序模块。 --推荐 SaltStack - 基础设施自动化和管理系统。 --推荐 supervisor - 用于UNIX的Supervisor进程控制系统。 gitapi：Git 的纯 Python API。官网 hgapi：Mercurial 的纯 Python API。官网 honcho：Foreman 的 Python 克隆版，用来管理基于 Procfile 的应用。官网 分发(Distribution) 打包为可执行文件以便分发。 PyInstaller：将 Python 程序转换成独立的执行文件(跨平台)。链接 --推荐 dh-virtualenv：构建并将 virtualenv 虚拟环境作为Debian 包来发布。链接 Nuitka：将脚本、模块、包编译成可执行文件或扩展模块。链接 py2app：将 Python 脚本变为独立软件包(Mac OS X)。链接 --推荐 py2exe：将 Python 脚本变为独立软件包(Windows)。链接 --已经比较久没有更新了。 pynsist：用来创建 Windows 安装程序的工具，可以在安装程序中打包 Python本身。链接 文档(Documentation) 用以生成项目文档的库。 Sphinx：Python 文档生成器。链接 awesome-sphinxdoc：链接 MkDocs：对 Markdown 友好的文档生成器。链接 -- 推荐 pdoc：替换Epydoc 的库，可以自动生成 Python 库的 API 文档。链接 Pycco：文学编程风格的文档生成器。链接 readthedocs：一个基于 Sphinx/MkDocs 的在线文档托管系统，对开源项目免费开放使用。链接 -- 推荐 下载器(Downloader) 用来进行下载的库. s3cmd：一个用来管理Amazon S3 和 CloudFront 的命令行工具。链接 s4cmd：超级 S3 命令行工具，性能更加强劲。链接 you-get：YouTube/Youku/Niconico 视频下载器，使用 Python3 编写。链接 --推荐 youtube-dl：一个小巧的命令行程序，用来下载 YouTube 视频。链接 电子商务(E-commerce) 用于电子商务以及支付的框架和库。 django-oscar：基于Django 的开源的电子商务框架。链接 -- 推荐 django-shop： 基于 Django 的店铺系统。链接 Cartridge：一个基于 Mezzanine 构建的购物车应用。链接 shoop：基于 Django 的开源电子商务平台。链接 alipay：非官方的 Python 支付宝 API。链接 merchant：可以接收来自多种支付平台支付的 Django 应用。链接 money：Python钱类，带有可选的CLDR支持的区域识别格式和可扩展的货币兑换解决方案。链接 forex-python：外汇汇率，比特币价格指数和货币兑换。链接 saleor - Python和Django的电子商务店面。链接 雪峰磁针石说明: python-currencies因为星级较少没有收录 编辑器插件(Editor Plugins and IDEs) 编辑器和 IDE 的插件 Elpy：Emacs Python 开发环境。链接 SublimeJEDI：Sublime Text 插件，用来实现自动补全库 Jedi。链接 Anaconda：把你的 Sublime Text 3 变成功能齐全的 Python IDE。链接 YouCompleteMe：引入基于 Jedi 的 Python 自动补全引擎。链接 Jedi-vim：绑定 Vim 和 Jedi 自动补全库对 Python 进行自动补全。链接 Python-mode：Vim 变成 Python IDE 的多合一插件。链接 PTVS：Visual Studio 的 Python 工具链接 wingIDE：商业化的 Python IDE,功能强大，占用资源少，python开发。也有免费的社区版提供。[链接]https://wingware.com/) -- 推荐 PyCharm：商业化的 Python IDE ，由 JetBrains 开发。也有免费的社区版提供。链接 LiClipse：基于 Eclipse 的免费多语言 IDE 。使用 PyDev 来支持 Python 。链接 Spyder：开源 Python IDE。链接 komodo-ide 链接 电子邮件(Email) 用来发送和解析电子邮件的库。 mailer：用简单的方式发送邮件。链接 -- 推荐 envelopes：人性化的电子邮件库。链接 flanker：email 地址和 Mime 解析库。链接 imbox：人性化的Python IMAP 库链接 inbox.py：人性化的Python SMTP 服务器。链接 inbox：具有时尚API的IMAP/SMTP同步系统。链接 -- 推荐 lamson：Python 风格的 SMTP 应用服务器。链接 marrow.mailer：高性能可扩展邮件分发框架。链接 modoboa：一个邮件托管和管理平台，具有现代的、简约的 Web UI。链接 pyzmail：创建，发送和解析电子邮件。链接 Talon：Mailgun 库，用来抽取信息和签名。链接 yagmail- 另外一个 Gmail/SMTP客户端。链接 sync-engine - IMAP/SMTP同步。 链接 -- 推荐 环境管理(Environment Management) Python版本和环境管理 Pipenv：Pipfile，Pip和Virtualenv的结合。链接 --强烈推荐 p：简单的python版本管理工具。链接 pyenv：简单的python版本管理。链接 --强烈推荐 venv：创建python虚拟环境，python3标准库。链接 --强烈推荐 virtualenv：创建独立的Python 环境。链接 --强烈推荐 virtualenvwrapper：virtualenv 的扩展。链接 --强烈推荐 文件(Files) 文件管理和 MIME(多用途的网际邮件扩充协议)类型检测。 imghdr：(Python 标准库)检测图片类型。链接 mimetypes：(Python 标准库)将文件名映射为 MIME 类型。链接 path.py：对 os.path 进行封装的模块。链接 pathlib：(Python3.4+ 标准库)跨平台的、面向对象的路径操作库。链接 --强烈推荐 python-magic：文件类型检测的第三方库 libmagic 的 Python 接口。链接 Unipath：用面向对象的方式操作文件和目录。链接 watchdog：管理文件系统事件的 API 和 shell 工具。链接 --推荐 外部函数接口(Foreign Function Interface) cffi：调用 C 代码。链接 --强烈推荐 ctypes：(Python 标准库) 调用 C 代码。链接 --强烈推荐 PyCUDA：Nvidia CUDA API 的封装。链接 SWIG：简单的包装器和接口生成器。链接 表单(Forms) Deform：Python HTML 表单生成库，受到了 formish 表单生成库的启发。链接 django-bootstrap3：集成了 Bootstrap 3 的 Django。链接 --推荐 django-crispy-forms：非常优雅且 DRY(Don't repeat yourself) 的方式来创建美观的表单。链接 --推荐 django-remote-forms：平台独立的 Django 表单序列化工具。链接 WTForms：灵活的表单验证和渲染库。链接 函数式编程(Functional Programming) CyToolz：Toolz 的 Cython 实现 : 高性能函数工具。链接 fn.py：在 Python 中进行函数式编程 : 实现了一些函数式编程缺失的功能。链接 -- 推荐 funcy：炫而实用的函数式工具。链接 Toolz：一组用于迭代器，函数和字典的函数式编程工具。链接 动态消息 用来创建用户活动的库。 django-activity-stream：从你的站点行为中生成通用活动信息流。链接 Stream-Framework：使用 Cassandra 和 Redis 创建动态消息和通知系统。链接 图形用户界面(GUI) curses：内置的ncurses 封装，用来创建终端图形用户界面。标准库。链接 Eel - 用于制作简单电子类离线HTML / JS GUI应用程序的小程序库。链接 enaml：使用类似 QML 的 Declaratic 语法来创建美观的用户界面。链接 kivy：创建NUI应用程序的库，可以运行在 Windows, Linux, Mac OS X, Android 以及 iOS 平台上。链接 -推荐 pyglet：Python 的跨平台窗口及多媒体库。链接 PyQt：跨平台用户界面框架 Qt 的 Python 绑定 ，支持 Qt v4 和 Qt v5。链接 PySide：跨平台用户界面框架 Qt 的 Python 绑定 ，支持 Qt v4。链接 Tkinter：Python GUI 标准库。链接 Toga：Python 原生的, 操作系统原生的 GUI 工具包。链接 urwid：创建终端 GUI 应用的库，支持组件，事件和丰富的色彩等。链接 wxPython：wxPython 是 wxWidgets C++ 类库和 Python 语言混合的产物。链接 PyGObject：GLib/GObject/GIO/GTK+ (GTK+3) 的 Python 绑定。链接 Flexx：纯 Python编写的用来创建 GUI 程序的工具集，它使用 web 技术进行界面的展示。链接 游戏开发(Game Development) Cocos2d - cocos2d是用于构建2D游戏，演示和其他图形/交互式应用程序的框架。它基于pyglet。 Panda3D - 由迪士尼开发并由卡内基梅隆娱乐技术中心维护的3D游戏引擎。用C ++编写，完全用Python包装。 -推荐 Pygame - Pygame是一套用于编写游戏的Python模块。 -推荐 PyOgre - Ogre 3D渲染引擎的Python绑定，可用于游戏，模拟，任何3D。 PyOpenGL - 用于OpenGL的Python ctypes绑定及其相关的API。 PySDL2 - SDL2库的基于ctypes的包装器。 RenPy - Visual Novel引擎。 地理位置(Geolocation) 地理编码地址和纬度和经度的图书馆。 django-countries - Django应用程序，提供与表单一起使用的国家选项，标志图标静态文件和模型的国家/地区字段。 GeoDjango - 世界级的地理网络框架。 -推荐 GeoIP - MaxMind GeoIP遗留数据库的Python API。 geojson - GeoJSON的Python绑定和实用程序。 geopy - Python地理编码工具箱。 pygeoip - 纯Python GeoIP API。 HTML操作(HTML Manipulation) 用于处理HTML和XML的库。 BeautifulSoup - Python风格的方式来对HTML或XML进行迭代，搜索和修改。 -推荐 bleach - 基于白名单的HTML清理和文本链接库。 cssutils - Python的CSS库。 html5lib - 用于解析和序列化HTML文档和片段的符合标准的库。 lxml - 用于处理HTML和XML的非常快速，易于使用和多功能的库。 -推荐 MarkupSafe - 为Python实现XML / HTML / XHTML标记安全字符串。 pyquery - 用于解析HTML的jQuery类库。 untangle - 将XML文档转换为Python对象以便于访问。 WeasyPrint - 可导出为PDF的HTML和CSS可视化呈现引擎。 xmldataset - 简单的XML解析。 xhtml2pdf：HTML/CSS 转 PDF 工具。官网 xmltodict - 像处理 JSON 一样处理 XML。 HTTP 使用 HTTP 的库。 aiohttp：基于 asyncio 的异步 HTTP 网络库。官网 requests：人性化的 HTTP 请求库。官网 --强烈推荐 grequests：requests 库 + gevent ，用于异步 HTTP 请求.官网 httplib2：全面的 HTTP 客户端库。官网 treq：类似 requests 的 Python API 构建于 Twisted HTTP 客户端之上。官网 urllib3：一个具有线程安全连接池，支持文件 post，清晰友好的 HTTP 库。官网 硬件(Hardware) 用于硬件编程的库。 ino - 用于Arduino的命令行工具包。 keyboard - 钩和模拟Windows和Linux上的全球键盘事件。 鼠标 - 在Windows和Linux上挂钩并模拟全局鼠标事件。 Pingo - Pingo提供统一的API来编程像Raspberry Pi，pcDuino，Intel Galileo等设备。 PyUserInput - 用于跨平台控制鼠标和键盘的模块。 scapy - 出色的数据包操作库。 thrift-tools thrift抓包工具。 mitmproxy：HTTP和抓包库。官网 wifi - 用于在Linux上使用WiFi的Python库和命令行工具。 Pyro：Python 机器人编程库。官网 PyUserInput：跨平台的，控制鼠标和键盘的模块。官网 图像处理(Image Processing) 用于处理图像的库。 pillow：Pillow 是一个更加易用版的 PIL。官网 -推荐 hmap：图像直方图映射。官网 imgSeek：使用视觉相似性搜索一组图片集合的项目。官网 较长时间没有更新 nude.py：裸体检测。官网 pyBarcode：不借助 PIL 库在 Python 程序中生成条形码。官网 pygram：类似 Instagram 的图像滤镜。官网 python-qrcode：纯 Python 实现的二维码生成器。官网 --推荐 Quads：基于四叉树的计算机艺术。官网 scikit-image：一个用于(科学)图像处理的 Python 库。官网 --推荐 thumbor：小型图像服务，具有剪裁，尺寸重设和翻转功能。官网 --推荐 wand：MagickWand的 Python 绑定。MagickWand 是 ImageMagick 的 C API 。官网 face_recognition：简单易用的 python 人脸识别库。官网 --强烈推荐 pagan - 基于输入字符串和散列的复古identicon(阿凡达)生成。 实现(Implementations) Python的实现。* CLPython - 用Common Lisp编写的Python编程语言。 CPython - 用C编写的Python编程语言的默认，最广泛使用的实现。 --强烈推荐 Cython - 优化Python的静态编译器。使用类型mixin将Python编译为C或C ++模块，从而获得巨大的性能提升 --强烈推荐 Grumpy - 更多的编译器比解释器更强大的CPython2.7替换(alpha)。 --推荐 IronPython - 实现用C＃编写的面向.NET Framework和Mono的Python编程语言。 --推荐 Jython - 为Java虚拟机(JVM)实现用Java编写的Python编程语言。 --推荐 MicroPython - MicroPython - 精简高效的Python编程语言实现，用于微控制器和受限制的系统 --推荐 Numba - 针对科学Python的LLVM的Python JIT编译器。 --推荐 PeachPy - 嵌入在Python中的x86-64汇编程序。可以用作Python的内联汇编程序，也可以用作Windows，Linux，OS X，Native Client和Go的独立汇编程序。 --推荐 Pyjion - 基于CoreCLR的Python JIT。 PyPy - 实现用RPython编写并编译为C的Python编程语言.PyPy关注速度，效率以及与原始CPython解释器的兼容性。解释器使用黑魔法使Python非常快速，而无需添加额外的类型信息。 --强烈推荐 PySec - python的强化版本，使安全专业人员和开发人员可以更轻松地编写应用程序，从而更有弹性地处理攻击和操作。 Pyston - 使用LLVM和现代JIT技术构建的Python实现，其目标是实现良好的性能。 --推荐 Stackless Python - Python编程语言的增强版本，它允许程序员在没有性能和复杂性的情况下获得基于线程编程的好处与传统线程相关的问题。 --推荐 交互式Python解释器(Interactive Interpreter) bpython - 界面丰富的 Python 解析器。 IPython - 功能丰富的工具，非常有效的使用交互式Python。 --强烈推荐 Jupyter Notebook - 功能丰富的工具，非常有效的使用交互式Python。 --推荐 ptpython - 在[python-prompt-toolkit]之上构建的高级Python REPL(https://github.com/jonathanslenders/python-prompt-toolkit) 。 --推荐 国际化 与i18n合作的图书馆 Babel - Python国际化库。 PyICU - Unicode C ++库的国际组件封装(ICU)。 作业调度(Job Scheduler) 用于调度作业的库。 APScheduler - 轻量但功能强大的进程内任务调度程序，可让您安排功能。 django-schedule - Django的日历应用程序。 doit - 任务运行者和构建工具。 gunnery - 具有基于Web界面的分布式系统的多用途任务执行工具。 Joblib - 一组用Python提供轻量级流水线的工具。 plan - 用Python编写crontab文件就像一个魅力一样。 schedule - 人性化的 Python 任务调度库。 --推荐 Spiff - 以纯Python实现的强大的工作流引擎。 TaskFlow - 可以让你方便执行任务的 Python 库，一致并且可靠。 AirFlow：Airflow 是Airbnb公司开源的，是一个工作流分配管理系统，通过有向非循环图的方式管理任务流程，设置任务依赖关系和时间调度。官方 日志(Logging) 用于生成和处理日志的库。 Eliot - 复杂和分布式系统日志。 logbook - 记录Python的替代品。 logging - (Python标准库)Python的日志工具。 --推荐 raven - Sentry的Python客户端，用于Web应用程序的日志/错误跟踪，崩溃报告和聚合平台。 机器学习 机器学习库。请参阅：awesome-machine-learning。 Metrics - 机器学习评估指标。 NuPIC - 用于智能计算的Numenta平台。 --推荐 scikit-learn - 流行的机器学习Python库。 --推荐 Spark ML - Apache Spark的可扩展机器学习库。--推荐 vowpal_porpoise - 用于[Vowpal Wabbit]的轻量级Python包装器(https://github.com/JohnLangford/vowpal_wabbit/)。 xgboost - 可扩展，可移植且分布式的渐变增强库。 --推荐 MapReduce MapReduce的框架和库。* PySpark - Apache Spark Python API。 dpark：Spark 的 Python 克隆版，类似 MapReduce 的框架。官网 dumbo：这个 Python 模块可以让人轻松的编写和运行 Hadoop 程序。官网 luigi - 可帮助您构建批处理作业复杂管道的模块。 mrjob - 在Hadoop或Amazon Web Services上运行MapReduce作业。 streamparse - 针对实时数据流运行Python代码。与Apache Storm集成。 dask - 灵活的分析计算并行计算库。 微软Windows Microsoft Windows上的Python编程。* Python(x，y) - 基于Qt和Spyder的面向科学应用的Python发行版。 --推荐 pythonlibs - Python扩展包的非官方Windows二进制文件。 --推荐 PythonNet - .NET公共语言运行时(CLR)的Python集成。 PyWin32 - Python的Windows扩展。 --推荐 WinPython - Windows 7/8的便携式开发环境。 --推荐 杂项 不适合上述类别的有用库或工具。 blinker：快速的 Python 进程内信号/事件分发系统。官网 itsdangerous：一系列辅助工具用来将可信的数据传入不可信的环境。官网 pluginbase：一个简单但是非常灵活的 Python 插件系统。官网 Pychievements：一个用来创建和追踪成就的 Python 框架。官网 Tryton：通用商务框架。官网 自然语言处理(Natural Language Processing) NLTK：构建Python程序以处理人类语言数据的领先平台。连接 - 推荐 jieba：中文分词工具。官网 - 推荐 langid.py：独立的语言识别系统。官网 Pattern：Python 网络信息挖掘模块。官网 - 推荐 SnowNLP：用来处理中文文本的库。官网 - 推荐 TextBlob：为进行普通自然语言处理任务提供一致的 API。官网 - 推荐 TextGrocery：一简单高效的短文本分类工具，基于 LibLinear 和 Jieba。官网   thulac:清华大学自然语言处理与社会人文计算实验室研制推出的一套中文词法分析工具包官网 gensim -人 性化的话题建模库。 spaCy - 用于Python和Cython的工业强度自然语言处理的库。 -推荐 网络虚拟化(Network Virtualization) 用于虚拟网络和SDN(软件定义网络)的工具和库。 Mininet：流行的网络模拟器以及用 Python 编写的 API。官网 -推荐 POX：一个针对基于 Python 的软件定义网络应用(例如 OpenFlow SDN 控制器)的开源开发平台。官网 Pyretic：火热的 SDN 编程语言中的一员，为网络交换机和模拟器提供强大的抽象能力。官网   SDX Platform：基于 SDN 的 IXP 实现，影响了 Mininet, POX 和 Pyretic。官网   NRU：一个基于组件的软件定义网络框架。官网 网络(Networking) 用于网络编程的库。 asyncio：(Python 标准库) 异步 I/O, 事件循环, 协程以及任务。官网 -推荐 Twisted：一个事件驱动的网络引擎。官网 -推荐 pulsar：事件驱动的并发框架。官网 diesel：基于 Greenlet 的事件 I/O 框架。官网 pyzmq：ZeroMQ 消息库的 Python 封装。官网 Toapi：轻巧，简单，快速的 Flask 库，致力于为所有网站提供 API 服务。官网 -推荐 txZMQ：基于 Twisted 的 ZeroMQ 消息库的 Python 封装。官网 NAPALM - 用于操纵网络设备的跨供应商API。 动态消息 用来创建用户活动的库。 django-activity-stream：从你的站点行为中生成通用活动信息流。官网 Stream-Framework：使用 Cassandra 和 Redis 创建动态消息和通知系统。官网 -推荐 ORM 实现对象关系映射或数据映射技术的库。 关系型数据库 Django Models：Django 的一部分。链接 SQLAlchemy：Python SQL 工具以及对象关系映射工具。链接 awesome-sqlalchemy系列 链接 Peewee：一个小巧，富有表达力的 ORM, 支持postgresql, mysql and sqlite。[链接]https://github.com/coleifer/peewee) PonyORM：提供面向生成器的 SQL 接口的 ORM。链接 python-sql：编写 Python 风格的 SQL 查询。链接 NoSQL 数据库 django-mongodb-engine：Django MongoDB 后端。链接 PynamoDB：Amazon DynamoDB 的一个 Python 风格接口。链接 flywheel：Amazon DynamoDB 的对象映射工具。链接 MongoEngine：Python 对象文档映射工具，用于 MongoDB。链接 hot-redis：为 Redis 提供 Python 丰富的数据类型。链接 redisco：一个 Python 库，提供可以持续存在在 Redis 中的简单模型和容器。链接 其他 butterdb：Google Drive 电子表格的 Python ORM。链接 dataset ：基于JSON的数据库。链接 包管理(Package Management) 管理包和依赖 pip：管理包和依赖。链接 pypi --强烈推荐 conda：跨平台，Python 二进制包管理工具。链接 --强烈推荐 Curdling：管理 Python 包的命令行工具。链接 pip-tools：保证 Python 包依赖关系更新的工具。链接 wheel：Python 分发的新标准，意在取代 eggs。链接 --强烈推荐 包仓库 本地 PyPI 仓库服务和代理。 warehouse：下一代 PyPI。链接 Warehouse：链接 bandersnatch：PyPA 提供的 PyPI 镜像工具。链接 devpi：PyPI 服务和打包/测试/分发工具。链接 localshop：本地 PyPI 服务(自定义包并且自动对 PyPI 镜像)。链接 权限(Permissions) 允许或拒绝用户访问数据或功能的库。 Carteblanche - 将代码与用户和设计师的想法对齐的模块。也神奇地处理导航和权限。 django-guardian - 为Django 1.2+权限管理 django-rules - 小巧但功能强大的应用程序，它为Django提供对象级权限，而不需要数据库。 进程(Processes) 用于启动和与OS进程进行通信的库。 delegator.py - Subprocesses用于Humans™2.0。 --推荐 sarge - Subprocesses的另一个封装。 sh - 一个全面的Python子程序替代品。 --推荐 队列(Queue) 用于处理事件和任务队列的库。 celery - 基于分布式消息传递的异步任务队列/作业队列。 --推荐 huey - 小多线程任务队列。 mrq - Queue先生 - 使用Redis＆gevent的Python中的分布式工作者任务队列。 rq - 简单的Python作业队列。 --推荐 simpleq - 一个简单的，无限可扩展的基于Amazon SQS的队列。 推荐系统(Recommender Systems) 用于构建推荐系统的库。 annoy - 针对内存使用进行了优化的C ++ / Python近似最近邻居。 --推荐 fastFM - 因式分解机器库。 implicit - 隐式数据集协作过滤的快速Python实现。 libffm - Field-aware因式分解机(FFM)库。 LightFM - 一些流行推荐算法的Python实现。 surprise - 用于构建和分析推荐系统的scikit。 TensorRec - TensorFlow中的推荐引擎框架 RESTful API 用于开发RESTful API的库。 Django    * django-rest-framework - 功能强大且灵活的工具包，用于构建Web API。 --强烈推荐     * django-tastypie - 为Django应用程序创建美味的API。 --推荐 Flask    * eve - 由Flask，MongoDB提供支持的REST API框架和。 --推荐     * flask-api-utils - 负责Flask的API表示和身份验证。    * flask-api - 适用于Flask的Browsable Web API。    * flask-restful - 快速构建适用于Flask的REST API。 --推荐    * flask-restless - 为使用SQLAlchemy定义的数据库模型生成RESTful API。*Pyramid     * cornice - Pyramid的RESTful框架。*其他    * falcon - 一个用于构建云API和Web应用后端的高性能框架。    * hug - 一个Python3框架，用于通过HTTP干净地公开API以及带有自动文档和验证的命令行。 --推荐    * restless - 基于从Tastypie学到的经验教训的框架不可知的REST框架。    * ripozo - 快速创建REST / HATEOAS / Hypermedia API。    * sandman - 现有数据库驱动系统的自动化REST API。    * apistar - 为Python 3设计的智能Web API框架。--推荐 RPC服务器(RPC Servers) RPC兼容服务器。* SimpleJSONRPCServer - 该库是JSON-RPC规范的实现。 SimpleXMLRPCServer - (Python标准库)简单的XML-RPC服务器实现，单线程。 zeroRPC - zerorpc是基于ZeroMQ和MessagePack。 --推荐 科学(Science) astropy - 用于天文学的社区Python库。 bcbio-nextgen - 为全自动高通量测序分析提供最佳实践管道。 bccb - 收集与生物分析相关的有用代码。 Biopython - Biopython是一套免费的生物计算工具。 cclib - 用于解析和解释计算化学软件包结果的库。 Color - 一种颜色科学软件包，用于实现各种颜色理论转换和算法。 NetworkX - 适用于复杂网络的高效软件。 NIPY - 一套神经影像工具包。 --推荐 NumPy - 用Python进行科学计算的基础软件包。 --强烈推荐 Open Babel - 一种化学工具箱，专门用于讲述多种化学数据的语言。 ObsPy - 地震学的Python工具箱。 PyDy - Python Dynamics的缩写，用于协助动态运动建模中的工作流程。 PyMC - 马尔可夫链蒙特卡洛采样工具包。 RDKit - Cheminformatics和机器学习软件。 SciPy - 一个基于Python的数学，科学和工程开放源码软件生态系统。 --强烈推荐 statsmodels - Python中的统计建模和计量经济学。 --推荐 SymPy - 符号数学的Python库。 Zipline - Pythonic算法交易库。 --推荐 SimPy - 基于流程的离散事件仿真框架。 --推荐 搜索 用于索引和执行数据搜索查询的库和软件。 django-haystack - Django模块化搜索。 elasticsearch-dsl-py - Elasticsearch的官方高级Python客户端。 elasticsearch-py - [Elasticsearch]的官方低级Python客户端(https： //www.elastic.co/products/elasticsearch)。 esengine - 用于Python的ElasticSearch ODM(对象文档映射器)。 pysolr - Apache Solr的轻量级Python包装(包括SolrCloud认知)。 solrpy - [solr]的一个Python客户端(http://lucene.apache.org/solr/)。 Whoosh - 快速，纯粹的Python搜索引擎库。 --推荐 序列化(Serialization) 用于序列化复杂数据类型的库 marshmallow - marshmallow是一个ORM / ODM /框架无关的库，用于将复杂数据类型(如对象)转换为本机Python数据类型和从本地Python数据类型转换。 无服务器框架(Serverless Frameworks 用于开发无服务器Python代码的框架。 apex - 轻松构建，部署和管理AWS Lambda功能。 --推荐 python-lambda - 用于在AWS Lambda中开发和部署Python代码的工具包。 Zappa - AWS Lambda和API网关上部署WSGI应用程序的工具。--推荐 特殊文本格式处理(Specific Formats Processing) 一些用来解析和操作特殊文本格式的库。 通用 tablib：处理 XLS, CSV, JSON, YAML表格数据的模块。链接 Office Marmir：把输入的Python 数据结构转换为电子表单。链接 openpyxl：用来读写 Excel 2010 xlsx/xlsm/xltx/xltm 文件的库。链接 --强烈推荐 python-docx：读取，查询以及修改 Microsoft Word 2007/2008 docx 文件。链接 unoconv：在 LibreOffice/OpenOffice 支持的任意文件格式之间进行转换。链接 XlsxWriter：一个用于创建 Excel .xlsx 文件的 Python 模块。链接 -- 推荐 xlwings： Excel 中方便调用 Python 的库(反之亦然)，基于 BSD 协议。链接 xlwt/xlrd：读写 MS Excel 97/2000/XP/2003 XLS Excel 文件的数据和格式信息。链接 relatorio：输出odt和pdf的模板。链接 pyexcel：用于读取，操作和写入CSV，ODS，XLS，XLSX和XLSM文件数据的单一API。链接 -- 实际pandas为第一数据处理库，支持所有excel格式, 不过会依赖上面的一些库。 合并多个excel表，插件mergebooks.dll和vba可以搞定。多表统计求和VBA可以搞定，参考资料, 当然pandas会比它们更强大。 PyXLL用于在excel中用python替代VBA. Pywin32 也可通过COM口连接excel。 PDF PDFMiner：从PDF文档中抽取信息的工具。链接 PyPDF2：可以分割，合并和转换 PDF 页面的库。链接 ReportLab：快速创建富文本 PDF 文档。链接 Markdown Mistune：快速并且功能齐全的纯 Python 实现的 Markdown 解析器。链接 Python-Markdown：John Gruber’s Markdown 的 Python 版实现。链接 Python-Markdown2：纯 Python 实现的 Markdown 解析器，比 Python-Markdown 更快，更准确，可扩展。链接 YAML PyYAML：Python 版本的 YAML 解析器。链接 CSV csv: 标准库，csv文件读写。链接 csvkit：用于转换和操作 CSV 的工具。链接 -- 推荐 Archive unp：方便解包归档文件的命令行工具。链接 静态网站生成器(Static Site Generator) [Cactus(https://github.com/eudicots/Cactus) - 为设计师设计的静态网站生成器。 Hyde - 基于Jinja2的静态网站生成器。 Lektor - 易于使用的静态CMS和博客引擎。 Nikola - 静态网站和博客生成器。 Pelican - 将Markdown或ReST用于内容，Jinja 2用于主题。 支持DVCS，Disqus。AGPL。 --强烈推荐 Tinkerer - 博客引擎和静态网站生成器，由Sphinx提供支持。 标签(Tagging) django-taggit - 简单Django的标签。 模板引擎(Template Engine) Genshi - 用于生成网络感知输出的Python模板工具包。 Jinja2 - 现代和设计友好的模板语言。 -- 推荐 Mako - Python平台的超快速和轻量级模板。 文本处理(Text Processing) 用于解析和操作文本的库。 通用 chardet：字符编码检测器，兼容 Python2 和 Python3。链接 difflib：(Python 标准库)帮助我们进行差异化比较。链接 ftfy：让Unicode文本更完整更连贯。链接 fuzzywuzzy：模糊字符串匹配。链接 --推荐 Levenshtein：快速计算编辑距离以及字符串的相似度。链接 pyfiglet：pyfiglet -figlet 的 Python实现。链接 shortuuid：生成器库，用以生成简洁的，明白的，URL 安全的 UUID。链接 unidecode：Unicode 文本的 ASCII 转换形式 。链接 uniout：打印可读的字符，而不是转义的字符串。链接 xpinyin：把汉字转换为拼音的库。链接 pypinyin ：把汉字转换为拼音的库。链接 simplejson：Python的JSON编码、解码器。链接 smassedit：Python的sed。链接 Slugify awesome-slugify：一个 Python slug 化库，可以保持 Unicode。链接 python-slugify：Python slug 化库，可以把 unicode 转化为 ASCII。链接 unicode-slugify：slug 工具，可以生成 unicode slugs ,需要依赖 Django 。链接 解析器 phonenumbers：解析，格式化，储存，验证国际电话号码。链接 PLY：lex 和 yacc 解析工具的 Python 实现。链接 Pygments：通用语法高亮工具。链接 --强烈推荐 pyparsing：生成通用解析器的框架。链接 python-nameparser：把人名分解为几个独立的部分。链接 python-user-agents：浏览器 user agent 解析器。链接 sqlparse：无验证的 SQL 解析器。官网链接 第三方 API(Third-party APIs) 用来访问第三方 API的库。 参见： List of Python API Wrappers and Libraries。 链接 apache-libcloud：为各种云设计的 Python 库。链接 boto3：Amazon Web Services 的 Python 接口。链接 django-wordpress：WordPress models and views for Django.链接 facebook-sdk：Facebook 平台的 Python SDK.链接 facepy：Facepy 让和 Facebook's Graph API 的交互变得更容易。链接 gmail：Gmail 的 Python 接口。链接 google-api-python-client：Python 用的 Google APIs 客户端库。链接 gspread：Google 电子表格的 Python API.链接 twython：Twitter API 的封装。链接 URL处理(URL Manipulation) 解析URLs的库 furl：处理 URL 更简单小型 Python 库。链接 purl：简单的，不可变的URL类，具有简洁的 API 来进行询问和处理。链接 pyshorteners：纯 Python URL 缩短库。链接 shorturl：生成短小 URL 和类似 bit.ly 短链的Python 实现。链接 webargs：解析 HTTP 请求参数的库，内置对流行 web 框架的支持，包括 Flask, Django, Bottle, Tornado和 Pyramid。链接 Video 用来操作视频和GIF的库。 moviepy：一个用来进行基于脚本的视频编辑模块，适用于多种格式，包括动图 GIFs。链接 WSGI 服务器(WSGI Servers) 兼容 WSGI 的 web 服务器 gunicorn：Pre-forked, 部分是由 C 语言编写的。链接 --推荐 uwsgi：uwsgi 项目的目的是开发一组全栈工具，用来建立托管服务， 由 C 语言编写。链接 bjoern：异步，非常快速，由 C 语言编写。链接 fapws3：异步 (仅对于网络端)，由 C 语言编写。链接 meinheld：异步，部分是由 C 语言编写的。链接 netius：异步，非常快速。链接 paste：多线程，稳定，久经考验。链接　--推荐 waitress：多线程, 是它驱动着 Pyramid 框架。链接 Werkzeug：一个 WSGI 工具库，驱动着 Flask ，而且可以很方便大嵌入到你的项目中去。链接　--推荐 网页内容提取(Web Content Extracting) 用于进行网页内容提取的库。 Haul：可以扩展的图像爬取工具。链接 html2text：将 HTML 转换为 Markdown 格式文本链接 lassie：人性化的网页内容检索库。链接 micawber：一个小型网页内容提取库，用来从 URLs 提取富内容。链接 newspaper：使用 Python 进行新闻提取，文章提取以及内容策展。链接 --推荐 opengraph：用来解析开放图形协议的 Python模块。链接 python-goose：HTML内容/文章提取器。链接 python-readability：arc90的易读性工具的移植。链接 sumy：一个为文本文件和 HTML 页面进行自动摘要的模块。链接 textract：从任何格式的文档中提取文本，Word，PowerPoint，PDFs 等等。链接 网络爬虫(Web Crawling) 2018最佳人工智能数据采集(爬虫)工具书下载 Scrapy：快速高级的屏幕爬取及网页采集框架。链接 --强烈推荐 cola：高层分布式爬虫框架。链接 Demiurge：基于PyQuery 的爬虫微型框架。链接 feedparser：通用 feed 解析器。链接 Grab：站点爬取框架。链接 MechanicalSoup：用于自动和网络站点交互的 Python 库。链接 portia：Scrapy 可视化爬取。链接 --推荐 pyspider：一个强大的爬虫系统。链接 --强烈推荐 RoboBrowser：一个简单的，Python 风格的库，用来浏览网站，而不需要一个独立安装的浏览器。链接 MechanicalSoup：用于自动和网络站点交互的 Python 库。链接 Web 框架(Web Frameworks) 全栈 Web 框架。 Django：Python 界最流行的 web 框架。链接 wesome-django系列 链接 --强烈推荐 Flask：Python 微型框架。链接 awesome-flask系列 链接 --强烈推荐 python web框架第一名 pyramid：一个小巧，快速，接地气的开源Python web 框架。链接 awesome-pyramid系列 [链接](https://github.com/uralbash/awesome-pyramid) Bottle：一个快速小巧，轻量级的 WSGI 微型 web 框架。链接 --推荐 CherryPy：一个极简的 Python web 框架，支持HTTP/1.1 协议且具有WSGI 线程池。链接 sanic：python3 快速的web服务器，类似flask。链接 --推荐 web.py：既简单，又强大的web 框架。链接 TurboGears：易于扩展的全栈微框架。链接 web2py：全栈 web 框架和平台，用于安全数据库访问的web用。链接 Tornado - web 框架和异步网络库. 链接 WebSocket AutobahnPython：WebSocket & WAMP 基于 Twisted 和 asyncio。链接 Crossbar：开源统一应用路由(Websocket & WAMP for Python on Autobahn).链接 django-channels：Django异步。链接 django-socketio：Django WebSocket。链接 WebSocket-for-Python：为Python2/3 以及 PyPy 编写的 WebSocket 客户端和服务器库。链接 监控 python应用性能监控工具简介 https://china-testing.github.io/python_monitor.html sentry Sentry is cross-platform application monitoring, with a focus on error reporting. https://sentry.io 推荐 Graphite 存储时间序列数据，并通过Django Web应用程序在图形中显示它们。 参考资料 https://github.com/vinta/awesome-python https://github.com/atinfo/awesome-test-automation https://westurner.github.io/wiki/awesome-python-testing 紧张整理更新中，讨论 钉钉免费群21745728 qq群144081101 567351477 相关书籍下载 https://github.com/china-testing/python-api-tesing/blob/master/books.md

原文地址：http://www.smashed.by/perf-checklist  作者 | Vitaly Friedman  译者 | OpenWeb开发者 三三 众所周知，性能十分重要。然而，我们真的知道性能瓶颈具体在哪儿吗？是执行复杂的 JavaScript，下载缓慢的 Web 字体，巨大的图片，还是卡顿的渲染？研究摇树（Tree Shaking），作用域提升（Scope Hoisting），或是各种各样的与 IntersectionObserver、Clients Hints、CSS containment、HTTP/2 和 Service Worker 一同工作的华丽的加载模式真的有价值吗？最重要的是，我们从哪里开始优化性能，以及我们如何建立长期的性能文化呢？ 以前，性能往往只是事后的想法。通常直到项目最后的时候才会被考虑，然后被归结为压缩、合并、静态资源优化或者对服务器配置文件的一些细微调整。现在回想起来，事情似乎已经发生了很大的变化。 性能不仅仅是一个技术问题：它很重要，而且当把它引入到工作流时，设计决策必须根据其性能影响来决定。我们必须不断的测量、监视和改进性能，而且 Web 日益复杂的情况带来了新的挑战，使得性能指标难以被跟踪，因为性能指标将因设备、浏览器、协议、网络类型和延迟（CDN、运营商、缓存、代理、防火墙、负载平衡器和服务器都在其中发挥作用）而有很大差异。 因此，如果我们创作一个在提高性能时必须牢记的所有事项的概述——从流程的一开始到网站的最终发布——这样的列表将是什么样子？下面就是 2018 前端性能检查表（但愿不偏不倚和足够客观）——说明您可能需要考虑的问题，以确保您的站点响应时间快、用户交互流畅，并且不会用尽用户的带宽。 下面是您可能需要考虑的前端性能问题的概述，以确保您的响应时间快速而流畅。 译注：原文详细地阐述了文中所涉及的所有优化策略的原理和来龙去脉。此处仅翻译了原文中附带的 PDF 检查表文件，意在提供一个快速、简洁的性能优化清单。 一、准备：规划和指标 01 建立性能文化 只要团队之间没有协作，高性能就无法长期维持。研究用户反馈中常见的抱怨，看看提高性能是否可以帮助缓解其中一些问题。用真实数据来建立适合自己的案例和模型。在设计过程中就开始规划加载顺序和权衡。 02 选择正确的性能指标 并非每个指标都同等重要。研究最重要的度量标准：一般而言，它与您开始渲染最重要像素的速度以及提供输入响应的速度有关。根据客户的感受确定页面加载的优先级。可交互时间、页面大标题元素的渲染时间、首次有效绘制时间（FMP）、速度指数（Speed Index）一般都很重要。 03 比你的竞争对手快至少 20% 收集代表您受众的设备上的数据。在数据来源上，真实设备比模拟数据更好。选择一台 Moto G4、中端三星设备或者 Nexus 5X 等性能良好的中端设备。或者，也可以通过在电脑上，通过设置网络限速（例如：150ms RTT，1.5Mbps 下载，0.7Mbps 上传）和 CPU 限速（5 倍慢速）以模拟移动体验。最后在常规 3G、4G 和 Wi-Fi 之间切换。收集数据、设置电子表格、将指标提高 20% 并设置目标（即，“性能预算”）。 04 把这张检查表分享给你的同事 确保团队中的每个成员都熟悉该清单。每一个决策都涉及性能问题，前端开发人员的积极参与将使您的项目受益匪浅。将你的性能预算映射到设计决策上。 二、制定现实的目标 05 100 毫秒的响应时间 + 每秒60帧 每帧动画应在少于 16 毫秒（理想情况下为 10 毫秒）内完成，从而达到每秒 60 帧（1 秒 ÷ 60 = 16.6毫秒）。保持乐观，明智地利用空闲时间。对于像动画这样的高压点，只要能，就不要做任何其它事情。预计输入延迟时间（Estimated Input Latency）应低于 50 毫秒。 06 速度指数（SpeedIndex）小于 1250，可交互时间（Time-To-Interactive）在 3G 上小于 5 秒 目标是在 1 秒内（在高速网络下）完成首次绘制（FMP），速度指数（SpeedIndex）低于 1250 毫秒。考虑速度基线是一台有着 3G 网络的，价格为 200 美元左右的 Android 手机（译注：国产千元机水平），那么可以以 400 毫秒 RTT 和 400kb/s 的传输速度进行网络模拟，以达成可交互时间（Time-To-Interactive）小于 5 秒，第二次打开的速度低于 2 秒。尽你所能地降低这些指标。 07 核心块 = 15kb，关键文件 < 170 kb HTML 的前 14~15kb 是最关键的核心块（chunk），也是整个文件中唯一可以在第一个 RTT 内被下载的部分。要实现上述目标，请设定关键文件的最大尺寸“预算”。170kb gzip 后的文件（原始文件尺寸 0.8~1mb），在普通手机上可能需要 1 秒才能解析和编译完成。 三、定义环境 08 选择并设置你的构建工具 不要太注意所谓的“酷”。只要您能够快速获得结果，而且在维护构建过程上没有问题就很好了。 09 渐进增强 首先设计和构建核心功能，然后再在此基础上为功能强大的浏览器的高级功能增强效果，从而创建弹性的体验。如果您的网站在性能差、网络差的机器上还能运行得比较快，那在性能好、网络棒的机器上只会运行得更快。 10 设定硬性的性能基准 用 JavaScript 实现交互效果的成本相当高昂。170kb 的尺寸预算已经包含了核心的 HTML / CSS / JavaScript、路由、状态管理、工具函数、框架还有产品逻辑，因此，请彻底检查我们选择的框架的网络传输成本、解析 / 编译时间和其运行时的时间成本。 11 圣战止于智者：Angular, React 还是 Ember 并不是每个项目都需要框架。但是如果你的项目需要框架，那么最好选择使用一个支持服务器端渲染（SSR）的框架。在使用框架之前，请确保在移动设备上以服务器端渲染和客户端渲染两种模式来评估框架的启动时间。了解您将依赖的框架的具体细节。了解 PRPL 模式和 App Shell 模型。 12 你会使用 AMP 或者 Instant Articles 吗 译注：AMP 为 Google 的开源项目，意在以组件化的形式以提升移动设备对网站的访问速度；Instant Articles 是 Facebook 的协议，意在通过渲染页面的精简版本以提升页面在 Facebook App 内的打开速度。在国内，MIP 是和 AMP 类似的解决方案。 没有它们，你也可以获得良好的性能。但是 AMP 提供了一个可靠的性能框架，有免费的 CDN ，而 Instant Articles 将提高你在 Facebook 上的知名度和性能。你也可以构建一个渐进式 AMP（译注：Progressive Web AMP，PWA 和 AMP 的结合体）。 13 选择合适的 CDN 您可以将部分内容“外包”给静态站点生成器，然后将其推送到 CDN，并从CDN 提供静态版本，从而避免数据库请求（即 JAMStack）。当然，这取决于您拥有的动态数据量。仔细检查 CDN 是否为您执行了内容压缩和转换、智能 HTTP/2 和边缘端包含（ESI, edge-side includes）。 四、优化构建 14 合理安排优先级 把你所有的静态资源（JavaScript，图片，字体，第三方脚本，尺寸大的模块）列成一个表，然后把它们按优先级分成三组：基本核心功能（老浏览器也能浏览的核心内容）、增强体验效果（为现代浏览器设计的强大功能和丰富体验）、附加功能（不一定需要并且可以惰性加载的资源，比如字体、轮播脚本、视频播放器、分享按钮等）。 15 使用“符合标准”技术 译注：“符合标准”技术（cutting-the-mustard technique）是 BBC News 开发者博客提出的，一种基于浏览器特性来检测其支持程度，并以此选择要加载哪些功能的技术。 对老旧的浏览器，仅输出核心功能代码；对现代浏览器输出增强的功能代码。严格按标准加载静态资源：直接加载核心代码，在 DOMContentLoaded 事件中加载增强代码，并在 load 事件中加载剩下的代码。注意：廉价的 Android 手机虽然很符合标准，但这些手机的内存和 CPU 性能有限。因此，您可能需要使用读取设备内存大小的 JavaScript API 来检测设备性能，只有不支持的时候才按“符合标准”技术来。 16 减少 JavaScript 体积 由于解析 JavaScript 很耗时，所以请尽可能的减少 JavaScript 的体积。在构建 SPA 时，您可能需要用一定时间初始化应用程序之后，才能开始渲染页面。寻找可以加快初始渲染事件的模块和技术（在低端移动设备上，这可以轻松将速度提高 2-5 倍）。彻底检查每一个 JavaScript 依赖，以找出谁在消耗初始化的宝贵时间。 17 使用微优化和渐进式启动 使用服务器端渲染来获得快速的首次有效绘制时间（FMP），但也在页面里输出一些最小功能的 JavaScript 来保持交互时间（TTI）接近首次有效绘制时间（FMP）。然后，如果有需要或者有多余的时间，才开始启动应用程序的非必要部分。在加载时显示一个骨架屏幕，而不是“加载中”动画。 18 使用摇树和代码分割 使用摇树（Tree Shaking）技术和代码分割（Code Splitting）技术以减少代码体积。 摇树（Tree Shaking）技术是一种通过丢弃未使用的代码以在构建过程清理代码的方法。代码分割（Code Splitting）技术将您的代码拆分为按需加载的“chunks（块）”。作用域提升（Scope Hoisting）技术使得链式的依赖能被无缝地转换成行内函数。通过 WebPack 将上述技术用于您的代码。使用 AOT 编译器（译注：例如 Closure Compiler）将一些客户端计算移到服务端。 19 异步加载 JavaScript 作为开发者，我们必须显式地使用 defer 和 async 属性来告诉浏览器不要等待脚本下载、开始渲染页面。如果你不需要关注 IE 9 及以下版本的浏览器，那么使用 defer 更好；否则，使用 async 更好。使用静态的分享按钮、静态链接交互式地图而不是使用第三方库。 20 HTTP 缓存头是否设置好了 重新检查你是否正确的设置了 Expires, Cache-Control, Max-Age 等 HTTP 缓存控制响应头。通常而言，一个资源要么只被缓存很短的时间（比如经常修改的资源），要么永久缓存（比如不会被更改的那种资源）。使用专为带哈希指纹的静态文件设计的响应头 Cache-Control: imuutable 以避免浏览器重新请求文件。 五、静态资源优化 21 是否使用了 Brotli 或 Zopfli 压缩 Brotli 是一种新的无损压缩格式。现在，所有的现代浏览器都支持它。它比 Gzip 和 Deflate 压缩率更高，压缩非常慢，但是解压速度很快。使用最高压缩比的 Brotli+Gzip 预压缩静态文件，并使用 1~4 级的 Brotli 实时压缩动态内容。也顺便检查一下 CDN 是否支持 Brotli。或者，你也可以试试在不常变化的资源上使用 Zopfli —— 它将数据用 Deflate、Gzip 和 Zlib 格式压缩，并且被设计为一次压缩、多次下载。 22 图片是否被正确优化 尽可能使用通过 srcset、sizes 和 <picture> 元素实现的响应式图片。使用 WebP 格式的图片；这可通过 <picutre> 标签配合 JPEG fallback，或者通过 Accept 请求头来实现。对于核心图片，使用渐进式的 JPEG 并用高斯滤镜模糊掉不重要的部分。 23 Web Font 是否被正确优化 您使用的 Web Font 很可能包含未真正被使用的执行和额外的特性。制作字体的子集（译注：仅包含部分文字的字体，如 fontmin 等方案）。优先使用 WOFF2 并使用 WOFF 作为后备。立即使用后备字体显示文字、异步加载字体（例如，使用 loadCSS），然后再切换字体。同时也考虑本地操作系统中已经安装了的字体。不要忘记在 CSS 中写 font-display: optional；如果你无法从您的服务器加载字体，请记得使用 Font Load Events。 六、分发优化 24 快速推送核心 CSS 将所有首屏渲染所需要的 CSS 放在一起，然后方法在 <head> 标签中。考虑有选择的内联的方法。或者，使用 HTTP/2 服务端推送；但这样你可能需要构建一个可感知缓存的 HTTP/2 服务端推送机制。 25 使用 babel-preset-env 以仅转译 ES2015+ 特性 由于 ES2015 已被广泛支持了，您可以考虑使用 babel-preset-env 以仅转译现代浏览器不支持的 ES2015+ 特性。然后你可以编译两份，一份是 ES6 ，另一份是 ES5。使用 <script type="module"> 使得有 ESM 支持的浏览器加载新文件，剩下的老的浏览器可以使用 <script nomodule> 来加载老的文件。 26 提升渲染性能 使用 CSS 包含（CSS Containment）隔离渲染十分耗时的组件。请保证在滑动页面或者元素动画的时候，页面不会卡顿，而且你的页面能持续以 60fps 的速度渲染。如果那不可能，那么至少也要把 fps 控制在 15~60 之间。使用 CSS 的 will-change 属性通知浏览器哪个元素将会变化。 27 使用 Intersection Observer 懒加载大型脚本 Intersection Observer API 提供了异步监听目标元素与祖先元素或顶层文档视口交点中的更改的能力。浏览器支持？Chrome, Firefox, Edge 和三星浏览器都支持了。WebKit 还在开发。浏览器不支持？懒加载一个 polyfill。 28 是否优化了渲染体验 不要低估感知性能的作用。在加载静态文件时，尽量始终领先用户一步，这样在后台发生很多事情时，会感觉体验上很快。例如，要让用户持续关注你的页面，请使用骨架屏幕而不是一些加载中的动画。 29 预热连接以加快分发速度 使用骨架屏幕，然后懒加载所有的大型组件，比如字体、JavaScript、轮播图、视频和 iframe 等。使用资源提示（Resource Hints），如 dns-prefetch、preconnect、prefetch 和 preload来节省时间。 七、HTTP/2 30 为 HTTP/2 做准备 HTTP/2 支持很好，而且提供了不小的性能提升。缺点是，您必须迁移到 HTTPS；根据您不支持 HTTP/2 的用户群大小，你可能需要为 HTTP/1.1 和 HTTP/2 的用户返回不同版本的代码，这就要求您调整您的编译工具。 31 正确地部署 HTTP/2 您需要在打包模块和并行加载许多小模块之间找到一个良好的平衡。将整个界面分解为许多小模块；然后分组、压缩和打包。整个网站分为大约 6 到 10 个包应该是一个不错的折衷方案（对于传统浏览器来说也不错）。通过实验和数据监测来为您的网站找到正确的平衡。 32 你为 Save-Data 头节约数据流量了吗 Save-Data 请求提示头可以让我们为关心流量费用和性能的用户提供个性化的响应。例如，你可以把所有高清的图片都改成低清的，不用 Web Font 和华丽的动效，关掉视频自动播放和服务器推送，甚至修改你的应用界面。 34 确保服务器上的安全性是无懈可击的 再次检查安全标头是否设置正确，消除已知漏洞，并检查 SSL 证书。确保所有外部插件和跟踪脚本都是通过 HTTPS 加载的、没有 XSS，并且 HSTS 响应头和内容安全策略（CSP）响应头都已正确设置。 35 你的服务器和 CDN 都支持 HTTP/2 吗 不同的服务器和 CDN 可能对 HTTP/2 有不同的支持。使用 Is TLS Fast Yet? 来检查你的设置，或者直接看看你的服务器性能如何，支持的特性情况怎么样。 36 是否启用了 OCSP Stapling 在服务器上启用 OCSP Stapling 有助于提升 TLS 握手速度。OCSP 协议可以让浏览器无需下载并检索证书信息，从而减少握手时间。 37 你使用 IPv6 了吗 研究标明，IPv6 的邻居发现（NDP）和路由优化可以使网站快 10% ~ 15%。升级到支持 IPv6 的 DNS 以为未来做好准备。只需确保双栈网络能正常工作——这使得 IPv6 和 IPv4 能同时运行。毕竟，IPv6 不是向后兼容的。 38 HPACK 压缩启用了吗 如果你使用了 HTTP/2，再次检查你的服务器是否实现了 HPACK 压缩。HPACK 压缩可以压缩 HTTP 响应头，以减少不必要的开支。由于 HTTP/2 服务器现在都很新，他们可能不能完全支持包括 HPACK 压缩在内的所有标准。H2spec 是一个非常好的用于检测标准支持程度的工具。 39 你使用了 Service Worker 来缓存或者提供离线内容吗 网络再怎么优化，也不会比本地缓存更快。如果你的网站使用了 HTTPS，那么你可以把静态资源放在 Service Worker 的缓存中，而不用请求网络。 八、测试和监控 40 监控混合内容警告 如果您最近从 HTTP 迁移到了 HTTPS，请确保使用类似 Report-URI.io 之类的服务监控了严格的或被动的混合内容报警。你也可以用 Mixed Content Scan 来扫描你的 HTTPS 站点上是否有非 HTTPS 的混合内容。 41 使用 DevTools 的开发工作流是优化过的吗 选择一个调试工具，并试着点击每一个按钮。请确保您理解如何分析渲染性能、控制台输出、调试 JavaScript 和编辑 CSS 样式。 42 是否在代理浏览器和老式浏览器上测试过了 在 Chrome 和 Firefox 上测试是不够的。请看看你的网站在代理浏览器和老式浏览器（包括 UC 浏览器和 Opera Mini 等。译者注：此处的代理浏览器即指国内浏览器中常见的云加速功能）上是什么样子。统计你受众国家的网络平均速度，避免出现重大意外。使用网络节流并模拟高 DPI 设备。虽然 BrowserStack 很好，但也得在真机上测试。 43 是否设置了持续的监控 良好的性能指标是被动和主动监控工具的组合。拥有 WebPagetest 的私有实例和使用 Lighthouse 确实有利于快速测试，但也需要使用诸如 Calibre、speedscurve 等 RUM 工具建立持续的监控体系。设置您自己的用户计时打点以监控特定的业务速度指标。 九、速战速决 此列表相当全面，完成所有优化可能需要相当长的时间。如果你只有一个小时的时间，但又想获得显著的提升，你应该怎么做？我们挑出了 10 个最容易实现的方法。显然，在开始之前和完成之后，请统计结果，包括 3G 和有线连接上的开始渲染时间和速度指数（SpeedIndex）。 1. 统计真实的用户体验，设置可接受的目标。一个好的目标大致是：FMP < 1s，速度指数 < 1250，TTI 在 3G 网络上 < 5s 、二次访问 < 2s。优化开始渲染时间和 TTI。 2. 为你的主模板准备核心 CSS，并放在 <head> 标签里（你的预算是 14KB）。对于 CSS/JS，请保证核心文件尺寸最大为 170kb （gzip 后的尺寸；压缩前 0.8~1Mb） 3. 延迟或懒加载尽可能多的脚本，不管是你自己的还是第三方的——特别是分享按钮、视频播放器和其它的复杂模块。 4. 增加资源提示，包括 dns-lookup, preconnect, prefetch 和 preload。 5. 为 Web Font 创建子集，并异步加载（或者干脆别用）。 6. 优化图片。考虑在关键的页面（比如落地页）上用 WebP 格式。 7. 检查 HTTP 缓存头和安全头是否正确设置了。 8. 在服务器上启用 Brotli 或者 Zopfli 压缩。如果不支持，别忘了开 gzip。 9. 如果有 HTTP/2，启用 HPACK 压缩并上报混合内容警告。如果使用了 LTS，那么请打开 OCSP 装订。 10. 如果可能，将静态资源（包括字体、样式、脚本和图片等）尽可能多地在 service worker 里缓存起来。 Huge thanks to Yoav Weiss, Addy Osmani, Artem Denysov, Denys Mishunov, Ilya Pukhalski, Jeremy Wagner, Colin Bendell, Mark Zeman, Patrick Meenan, Leonardo Losoviz, Guy Podjarny, Andy Davies, Rachel Andrew, Anselm Hannemann, Patrick Hamann, Andy Davies, Tim Kadlec, Rey Bango, Matthias Ott, Mariana Peralta, Philipp Tellis, Ryan Townsend, Mohamed Hussain S H, Jacob Groß, Tim Swalling, Bob Visser, Kev Adamson and Rodney Rehm for reviewing this article, as well as our fantastic community, which has shared techniques and lessons learned from its work in performance optimization for everybody to use. You are truly smashing! 出处：https://mp.weixin.qq.com/s/MDRfdRnhJJ53611cG_Zb6g 版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。 原文发布时间为：2018年04月13日 本文作者：架构文摘 本文来源：CSDN 如需转载请联系原作者

作者 | 吴翰清 不得不说的话 在过去的18个月里，我拒绝了所有的采访，投入了全部的精力专心在做一件事情。所以我想先借着这篇文章澄清一下18个月以来网上的所有关于我的新闻、抖音视频等，都是好事者编撰的我的段子，用来吸取流量的假新闻。这些假新闻让我很苦恼，因为这些新闻将我描绘成为了我最不想成为的人，里面的我是一个符号，而不是真实的我。我为此专门给今日头条写过信，要求审核并过滤这类不实传播，但只清净了一个月。我想再进一步只有向监管部门反馈，以及继续保留法律追责的权利。 这些未经我许可的新闻和视频，将我描绘成了一个无所不能的人，连带着马老师也受到了牵连。我想有没有我，马老师都睡得很安稳。阿里的安全是上千名工程师共同努力的结果，我一个人的力量在其中的贡献极其微薄。我也从没有黑过阿里的网站，只是以前因为工作性质在授权的情况下对阿里的业务系统做过很多的安全测试。我们不应该捧吹以破坏为目的的黑客，那是犯罪，是我最不想成为的人。我过去的工作是对抗黑客攻击，打击网络犯罪，因此以破坏系统的黑客来描述曾经的我，是对我最大的羞辱。真正的黑客精神是挑战权威，追求开放、自由，而并非入侵计算机系统。我想是时候终止这些不正确的传播了。 至于我过去取得的一点不足为人道的成就，我想99%的读者都没搞明白我为什么会在2017年被评为 MIT TR35，大家只是在看个热闹，鼓鼓掌。但我不需要这样的掌声，我不需要大家为我个人鼓掌，我希望大家是为我的作品鼓掌。这也是为什么在2014年以后我几乎不再写文章的原因。我希望大家记住的是我的作品，我对社会的贡献，而非我个人的成长轨迹。从这个角度来看，我对自己还非常不满意，人们关注我的经历多过我的作品，所以我还得加倍努力。 就我个人来说，从2017年下半年开始，我离开了网络安全领域，进入到了今天大家所说的人工智能领域。我带领团队在浙江，在上海，在重庆建设了很多关键的基础设施系统。尤其是2018年在上海做的事情，倾注了我的所有心血，我从来没有如此认真地做过一件事情，结果也很好。只是这些事情并不曾对外宣传，故不为外人所知。这18个月来关于我个人的假新闻满天飞，让我哭笑不得，因为这些段子手连我最引以为豪的事情都没搞清楚。 所以我今天决定写一篇文章，作为一名工程师，我想把我对未来的判断写下来，也许可以帮助一些人少走一点弯路。只代表个人的看法，不代表公司的观点。 科技的进步是为了解放生产力 我将生产力的进步分为五个阶段：体力劳动，机械化，电气化，信息化，智能化。其中每一次科技的进步，都会带来生产力的解放，对社会的改变是巨大的。 在140年前发生的第二次科技革命，让电力深入到各行各业。自从中央发电站和交流电变压器等关键技术构建的电力基础设施成型后，获取电力的成本逐渐降低，各种各样的电气应用开始涌现，人们获取到了新的、稳定的能源。 我们现在知道电力最早是应用在电话、电报、电灯上的，也正是电气照明这一需求，拉动了电力基础设施的发展。因为在当时电力的用途比较单调，并没有今天这么琳琅满目的电器。在100年前爱迪生通用电气与威斯汀豪斯之间的主要竞争就是聚焦在电气照明领域。我们很难说在这个过程中，到底是电灯泡更重要，还是发电站更重要。我曾经比喻说当前云计算面临的窘境，就是「中央发电站」已经造出来了，我们有单集群上万台服务器规模的算力基础设施，但是「电灯泡」在哪里却没有找到。我们用「中央发电站」在点「煤气灯」，今天托管在云计算上的业务，大多数依然是「信息化系统」。而理想中的会消耗大量算力的应用，应当是「智能化系统」。我们一直在苦苦追寻云计算的「电灯泡应用」，却求之不得。 这里需要讲清楚「信息化系统」和「智能化系统」的区别。我认为「信息化系统」的本质是编辑数据库，一个业务系统如果存在大量人工交互，依赖于人提交表单来完成业务，那么就是一个信息化系统。而我理想中的「智能化系统」，应该是以自动完成任务为目的，以任务作为输入，以完成的结果作为输出，中间的过程应该是机器高度自动化完成的。以其完成任务的复杂度，来评价其智能程度的高低。 从这个角度看，「智能手机」并不智能，依然是个「信息化系统」。市面上形形色色的智能系统也都只是冠上了智能的名号在鱼目混珠。我并不是说「信息化系统」没有价值，信息化系统很有价值，但不是下个时代的东西。自从计算机技术发展以来，产生的各色各样的信息化系统极大地改变了世界，完成了从「电气化」到「信息化」转型升级的重要一步。这就是我们看到各色各样的计算机系统开始应用在各个领域，帮助人们更加高效的管理工作和提供服务。 互联网在这一过程中扮演了放大作用。我认为互联网本身并不是生产力，互联网只是连接了成千上万个信息化系统，从而具备了规模效应。互联网是规模经济，能让一个系统的价值实现上千倍、上万倍的放大，但是生产力是信息化系统本身提供的。能够接收互联网连接服务的终端，是浏览器，是 iOS 和 Android，这些端的演进本身是重要的。百度通过互联网连接了人和信息，腾讯通过互联网连接人和人，阿里通过互联网连接了人和信息化服务。但是这些都不是下一个时代的东西。 下一个时代会发生的事情，首先是出现智能化系统对信息化系统的升级换代，然后会出现通过互联网连接所有智能化系统的公司。智能化对信息化的升级换代，是一次巨大的生产力进步，处于社会变革中的商业公司的结局是适者生存。从历史来看，在信息化时代的PC操作系统升级换代到移动操作系统，其过程就是天翻地覆的。苹果的iPhone 发布之后，所有的开发者都不再给微软的 Windows 写软件，而转去给 iOS 写软件，对微软带来了强烈的冲击，如果不是微软后来又抓住了云计算的机遇，就很可能会从此一蹶不振。从商业发展的角度看类似事件一定会发生，在信息化时代的庞然大物很可能随着一次生产力的变革就变得无足轻重。那么现在所有的问题在于，未来世界需要的智能系统到底是什么？ 让机器获得智能，一直是计算机科学家孜孜以求的事情。在过去简单的专家系统，依靠经验和规则，也能处理简单的任务。但有一个弊病是对于专家经验未覆盖的异常情况，机器就不知道怎么处理了。所以后来出现了数据驱动诞生的智能。 我们看到当机器具备一定的智能后，就能处理相对简单的任务，从而部分地解放人的生产力，此时增加机器规模就等同于增加人力的规模。而机器智能和人的智能又各有所长，机器运算量大且不知疲倦，因此对于很多工作都有可能做到精细化管理。这往往能带来成本的节约。 比如在过去公交车的排班是按照经验，在一个线路里设置好公交车的数量，但是如果市民的出行情况发生波动时，公交车的供需关系之间一定会存在差异，有的线路会繁忙，有的线路则会空闲，从而出现资源的浪费。要解决这一问题需要先统计清楚每辆公交车每一趟的精确载客人数，再依靠机器智能精细化的调度公交车到不同的线路，就能在同等资源下实现效率最优。因此使用机器智能的好处是显而易见的。 五年前做不出大规模的机器智能系统 我们看到在生产力发展的过程中，从信息化到智能化的这一转型升级正在到来，已经到了爆发的前夜。这得益于四项技术的成熟：云计算、大数据、IoT、网络连接技术。 我们知道机器智能当前的发展是得益于对脑科学的研究，以及算力的进步，让神经网络进化到了深度学习，从而在视觉、语音等领域有了重大突破。算力的重要性毋庸置疑，但是光有算力依然难以在实际的应用中取得成功，还需要其他几项技术的成熟。在当前的技术环境来说，云计算为智能提供了足够的算力，是算力基础设施；大数据技术提供了数据处理的方法论和工具，是数据基础设施（当前还没有垄断性的数据基础设施，碎片化严重）；IoT 技术将智能设备的成本降到了足够低，为部署丰富的神经元感知设备提供了基础；网络连接技术，从4G到5G，为数据的高速传输提供了重要基础。 如果有科技树这种说法的话，那么机器智能的大规模应用，就需要先点亮前四个技术，这是基础。在五年以前，这几项技术的成本是制约我们将智能技术大规模应用的主要瓶颈。到今天已经逐渐成熟了。 在一项新技术刚出现的时候，我们往往会遇到两个问题。 第一个问题是人才的稀缺性问题。我们知道一个懂深度学习或其他机器智能技术的博士生刚毕业的年薪可能比得上一个工作了十年的程序员。业界各处都需要机器智能，供不应求。 第二个问题是技术的成本问题。新技术刚出来的成本一定是昂贵的，就像云计算刚出来的时候也是先解决能力问题，再解决效率问题。我前些时看一个报告，AWS 的 EC2 推出到现在连续降价了57次。我们熟知的摩尔定律，计算的性能每18个月翻一倍，也就意味着同等算力的硬件每18个月会降一半的成本。机器智能作为新技术也有同样的规律，在一开始我们不要指望它的成本会足够便宜到能进入千家万户，新技术的普及需要时间。只是我们往往迫不及待。 这两个问题决定了机器智能在一开始的时候，应该首先被应用在对社会效率撬动最大的那个点上。从商业上我们要找到这样的场景，来让这项技术脱离实验室，走向社会，通过商业来源源不断的滋养这项技术的迅速成长。 世界需要什么样的机器智能系统 这两个问题随着时间的推移很快就能解决。但今天产业界真正碰到的问题我认为是搞偏了方向。这体现在两个方面。 第一个问题是未来不应该存在一个「人工智能」的产业，我们今天的分类就分错了。就像自电力基础设施诞生以来，各行各业都需要用电，因此电力成为了一个关键生产要素。我认为未来智能也是一个关键生产要素，每个行业都需要，因此不需要单独划分一个人工智能产业。单独搞了一个人工智能产业，反倒不知道这些公司在干什么了，这些公司自己也产生了困惑。最终应该像今天的零售业一样，每个做零售的都有个电商部门，会通过互联网来做营销和销售。未来每个企业也应该有一个部门，就是负责他们的智能系统的建设与训练。要像训练宠物一样训练智能系统，使他具备智能。这不是某一家人工智能公司要做的事情，而是每家公司都要自己做的事情。 第二个问题和机器智能技术的发展有关。因为最近这次机器智能的热点是从深度学习开始，在视觉、语音等领域有了巨大突破，因此产业化后的企业往往都是在做视觉、语音、自然语言处理等工作。但是我们千万别忘了完整的人脑智能是从「感知」到「行动」，并通过不断的反馈完成高频率的协同，最终诞生了智能。 只做「感知」是一个巨大的误区，从技术上讲没有问题，但是从商业上讲创造的社会价值就很有限了，因为其解放的生产力相对是有限的。 从生产力发展的角度来讲，评判一个智能系统的社会价值，应该以它解放生产力的多少来衡量。只做「感知」就是只能看，但是做了这么多大型项目后，我发现所有的价值创造都是在于「处置」环节。因此只做感知，很难讲清楚投入产出是否值得，但是一旦开始进入到「行动」环节，就会开始解放生产力，价值是可被量化的。这里的行动，是机器智能实现了对人力或其他设备的调度。 实际上从技术发展的角度看，我们早就拥有了让机器智能做决策的能力。搜索引擎和个性化推荐，就是典型的通过机器智能做决策。通过每天处理海量的数据，最终实现精细化的匹配。 所以我认为一个完整的「智能系统」，是包含了「感知」与「行动」，其中支撑行动的是决策和调度的技术。而衡量这个智能系统是否有价值的标准，是看其解放的生产力的多少。 遗憾的是，到今天为止我认为业界并不存在一个理想的「智能系统」。业界当前的状态我称之为「有智能，没系统」。很多人工智能的创业公司拥有局部的智能能力，比如视觉、语音、NLP、知识图谱、搜索、推荐等中的一项或多项技术，但是很少有公司有完整的技术栈。而像 BAT 等公司具备完整的技术栈，但是却并没有将所有的技术整合成为「感知」+「行动」的一个完整系统，而是各项技术以碎片化的形式存在。尤其是将所有技术应用到某一个具体场景中解决某一个具体问题的，更是寥寥无几，而这正是催生出这一智能系统的关键所在。所以这是一个工程化的问题，工程化的挑战在于整合所有智能技术，实现完整的「感知」+「行动」能力，并有效的控制成本，实现对开发者友好的接口。 在智能技术的角度来看，「自动驾驶」和「智能音箱」是两个完整的从「感知」到「行动」闭环的场景。我认为这两个场景可以用来打磨机器智能技术，但是当前在商业上比较难成功。「自动驾驶」解放了所有的驾驶员，对解放生产力的价值非常明显，但是因为受制于今天城市的道路基础设施，因此对老城市的意义不大。今天城市的道路不是为自动驾驶设计的，也很难容纳下自动驾驶的汽车。因此自动驾驶更适合航空、航海、物流等领域，商业范围一下小了很多。「智能音箱」综合了多项机器智能技术，其核心技术「对话机器人」被称为人工智能领域的圣杯，想要做好难度相当之大。但是「智能音箱」当前的阶段对家庭中各种任务的生产力解放极其有限，价值很难讲清楚，最后沦为玩物的可能性比较大。尽管如此，随着时间的推移，随着基础设施的更新换代，这两项技术也会逐渐焕发出他们的生命力。 如果用航空业来比喻的话，今天的智能技术，就好比造飞机，市面上已经有了很多零件和引擎，但是所有的厂商都拿着零件当飞机卖，客户以为他买了一架飞机，其实只是买了个零件（因为生产力并没有得到多大的解放）。而今天真正的难点在于飞机设计图纸都还没有。 所以我打算先画一张，造架飞机玩玩。 构建智能时代 飞机想要真正飞上天，还需要几个东西。 首先是飞行员。飞行员不一定要懂得怎么造飞机，造飞机是个门槛很高的活。但是飞行员要懂得怎么开飞机，最后还要让人人都能坐飞机。我认为飞行员就是未来各个企业里智能部门的员工，他们负责训练买来的智能系统，让智能系统真正具备智能。由于各个企业拥有的数据的不同，以及「飞行员」技能的高低和责任心，最后的各个企业的智能系统的聪明程度也会出现差异。世界是丰富多彩的。 其次是航道。我认为航道依然是基础设施提供商的，包括运营商、云计算厂商等。 最后是机场。机场需要负责所有航班的调度和协同，为所有的飞机提供服务。这是最有意思的地方。我认为「机场」是最后真正的商业模式，就像苹果的 AppStore一样。 我认为在智能时代的「机场」，最重要的工作是给机器智能系统提供服务，而并非给人提供服务。 想象一下未来互联网里，70%-80%的人口是机器智能，他们处理了未来世界的绝大多数工作，而每一个机器智能又是有一个主人的。其主人可以是个人，也可以是组织，但都是有主权的。每一个机器智能存在的目标都是为了完成某个或多个任务。那么为所有的机器智能提供服务，就会是一个巨大的商业模式。 机器智能系统的自动协同是通往未来的关键路径 同时我也认为当前的机器智能产业，过于重视人与机器的交互，而忽视了机器与机器的交互。而后者才是更重要的事情。因为人与机器的交互依然是回到了信息化系统的老路上去，而机器与机器的自动协同，则是在进一步将智能系统的价值实现规模放大。 因此未来有必要给所有的机器智能定义一套语言，他们之间的交流可以像人一样拥有自己的语言，实现简单的逻辑。而所有机器智能之间的交互与协同，是不需要人工干预的，就像你家的孩子与邻居家的孩子自己会去玩耍一样，你不需要干预到他们的交流之中，他们自己会各取所需地完成各自的任务。 以「一网通办」的业务举例。在当前一网通办的主流实现办法是将政府各委办局的数据实现全量汇聚后，进行数据治理，并梳理流程，重塑业务。这种大数据应用的思路依然是停留在信息化建设的老路上，其弊端是想推动新技术落地的前提是流程先改革，同时各个不同地区的高度定制化导致很难在全国实现规模化的产品。但其实也可以有另外一种智能化的建设思路，让每个委办局自己建一个机器智能系统，其任务就是代替公务员处理各自的窗口业务。当市民来提交一个申请时，经过认证后，该委办局的机器智能系统就根据所需材料，自行向其他委办局的机器智能系统发出协同请求，经过几轮机器智能之间的交流和协同之后，市民很快就得到了他想要的结果。这种多个机器智能系统之间自动协同的机制，对流程的冲击明显会小很多。 机器智能之间的交互与协同需要通过网络连接到一起，但安全性是可控的，因为是业务之间的协同，而并非数据本身发生了交换。因为每一个机器智能都有自己的主人，所有的训练过程也都发生在其主体内部，因此数据并不需要被拿出来交换共享。主人可以设定机器智能什么能说，什么不能说，所有的安全控制都发生在智能系统内部，而一旦连接到互联网要与其他机器智能协同或使用「机场」提供的服务，就会转为「默认不信任」模式。 至于机器智能系统到底部署在公共云还是专有云，这并不是一个重要的问题，主人爱部署在哪里就部署在哪里。所以时至今日，云计算依然有被管道化的危险，就像运营商被互联网内容提供商管道化一样，未来云计算厂商也可能会被智能厂商管道化。因为云计算和大数据都不是智能。 A组 也因此，为了以上这些构想，我受命在阿里云成立「A组」。「A组」成立的使命就是为了构建出这一机器智能系统，让智能时代更快的到来。 我认为这是一件需要整个社会共同努力三十到五十年的事情，就像在过去的三十到五十年我们在信息化建设上付出的所有努力一样。 以上，就是我想对世界说的话。 我说，你听。 阿里云-GTS-A组 吴翰清

阿里妹导读：吴翰清，被大家亲切地称为“小黑”“道哥”。他是阿里巴巴研究员，更是一位“白帽黑客”。15岁，考入西安交大少年班，毕业后应聘阿里。23岁，成为阿里最年轻的高级技术专家。32岁，被评选为2017年度全球35位35岁以下的青年科技创新人才（TR35）。网上有许多关于他的猜测，然而，他始终保持低调，专注于自己热爱的事业。2014年之后，他几乎不再写文章；但在今天，他有话想说，关于自己，关于科技，关于未来，说给你听，说给世界听。 不得不说的话 在过去的18个月里，我拒绝了所有的采访，投入了全部的精力专心在做一件事情。所以我想先借着这篇文章澄清一下18个月以来网上的所有关于我的新闻、抖音视频等，都是好事者编撰的我的段子，用来吸取流量的假新闻。这些假新闻让我很苦恼，因为这些新闻将我描绘成为了我最不想成为的人，里面的我是一个符号，而不是真实的我。我为此专门给今日头条写过信，要求审核并过滤这类不实传播，但只清净了一个月。我想再进一步只有向监管部门反馈，以及继续保留法律追责的权利。 这些未经我许可的新闻和视频，将我描绘成了一个无所不能的人，连带着马老师也受到了牵连。我想有没有我，马老师都睡得很安稳。阿里的安全是上千名工程师共同努力的结果，我一个人的力量在其中的贡献极其微薄。我也从没有黑过阿里的网站，只是以前因为工作性质在授权的情况下对阿里的业务系统做过很多的安全测试。我们不应该捧吹以破坏为目的的黑客，那是犯罪，是我最不想成为的人。我过去的工作是对抗黑客攻击，打击网络犯罪，因此以破坏系统的黑客来描述曾经的我，是对我最大的羞辱。真正的黑客精神是挑战权威，追求开放、自由，而并非入侵计算机系统。我想是时候终止这些不正确的传播了。 至于我过去取得的一点不足为人道的成就，我想99%的读者都没搞明白我为什么会在2017年被评为 MIT TR35，大家只是在看个热闹，鼓鼓掌。但我不需要这样的掌声，我不需要大家为我个人鼓掌，我希望大家是为我的作品鼓掌。这也是为什么在2014年以后我几乎不再写文章的原因。我希望大家记住的是我的作品，我对社会的贡献，而非我个人的成长轨迹。从这个角度来看，我对自己还非常不满意，人们关注我的经历多过我的作品，所以我还得加倍努力。 就我个人来说，从2017年下半年开始，我离开了网络安全领域，进入到了今天大家所说的人工智能领域。我带领团队在浙江，在上海，在重庆建设了很多关键的基础设施系统。尤其是2018年在上海做的事情，倾注了我的所有心血，我从来没有如此认真地做过一件事情，结果也很好。只是这些事情并不曾对外宣传，故不为外人所知。这18个月来关于我个人的假新闻满天飞，让我哭笑不得，因为这些段子手连我最引以为豪的事情都没搞清楚。 所以我今天决定写一篇文章，作为一名工程师，我想把我对未来的判断写下来，也许可以帮助一些人少走一点弯路。只代表个人的看法，不代表公司的观点。 科技的进步是为了解放生产力 我将生产力的进步分为五个阶段：体力劳动，机械化，电气化，信息化，智能化。其中每一次科技的进步，都会带来生产力的解放，对社会的改变是巨大的。 在140年前发生的第二次科技革命，让电力深入到各行各业。自从中央发电站和交流电变压器等关键技术构建的电力基础设施成型后，获取电力的成本逐渐降低，各种各样的电气应用开始涌现，人们获取到了新的、稳定的能源。 我们现在知道电力最早是应用在电话、电报、电灯上的，也正是电气照明这一需求，拉动了电力基础设施的发展。因为在当时电力的用途比较单调，并没有今天这么琳琅满目的电器。在100年前爱迪生通用电气与威斯汀豪斯之间的主要竞争就是聚焦在电气照明领域。我们很难说在这个过程中，到底是电灯泡更重要，还是发电站更重要。我曾经比喻说当前云计算面临的窘境，就是「中央发电站」已经造出来了，我们有单集群上万台服务器规模的算力基础设施，但是「电灯泡」在哪里却没有找到。我们用「中央发电站」在点「煤气灯」，今天托管在云计算上的业务，大多数依然是「信息化系统」。而理想中的会消耗大量算力的应用，应当是「智能化系统」。我们一直在苦苦追寻云计算的「电灯泡应用」，却求之不得。 这里需要讲清楚「信息化系统」和「智能化系统」的区别。我认为「信息化系统」的本质是编辑数据库，一个业务系统如果存在大量人工交互，依赖于人提交表单来完成业务，那么就是一个信息化系统。而我理想中的「智能化系统」，应该是以自动完成任务为目的，以任务作为输入，以完成的结果作为输出，中间的过程应该是机器高度自动化完成的。以其完成任务的复杂度，来评价其智能程度的高低。 从这个角度看，「智能手机」并不智能，依然是个「信息化系统」。市面上形形色色的智能系统也都只是冠上了智能的名号在鱼目混珠。我并不是说「信息化系统」没有价值，信息化系统很有价值，但不是下个时代的东西。自从计算机技术发展以来，产生的各色各样的信息化系统极大地改变了世界，完成了从「电气化」到「信息化」转型升级的重要一步。这就是我们看到各色各样的计算机系统开始应用在各个领域，帮助人们更加高效的管理工作和提供服务。 互联网在这一过程中扮演了放大作用。我认为互联网本身并不是生产力，互联网只是连接了成千上万个信息化系统，从而具备了规模效应。互联网是规模经济，能让一个系统的价值实现上千倍、上万倍的放大，但是生产力是信息化系统本身提供的。能够接收互联网连接服务的终端，是浏览器，是 iOS 和 Android，这些端的演进本身是重要的。百度通过互联网连接了人和信息，腾讯通过互联网连接人和人，阿里通过互联网连接了人和信息化服务。但是这些都不是下一个时代的东西。 下一个时代会发生的事情，首先是出现智能化系统对信息化系统的升级换代，然后会出现通过互联网连接所有智能化系统的公司。智能化对信息化的升级换代，是一次巨大的生产力进步，处于社会变革中的商业公司的结局是适者生存。从历史来看，在信息化时代的PC操作系统升级换代到移动操作系统，其过程就是天翻地覆的。苹果的iPhone 发布之后，所有的开发者都不再给微软的 Windows 写软件，而转去给 iOS 写软件，对微软带来了强烈的冲击，如果不是微软后来又抓住了云计算的机遇，就很可能会从此一蹶不振。从商业发展的角度看类似事件一定会发生，在信息化时代的庞然大物很可能随着一次生产力的变革就变得无足轻重。那么现在所有的问题在于，未来世界需要的智能系统到底是什么？ 让机器获得智能，一直是计算机科学家孜孜以求的事情。在过去简单的专家系统，依靠经验和规则，也能处理简单的任务。但有一个弊病是对于专家经验未覆盖的异常情况，机器就不知道怎么处理了。所以后来出现了数据驱动诞生的智能。 我们看到当机器具备一定的智能后，就能处理相对简单的任务，从而部分地解放人的生产力，此时增加机器规模就等同于增加人力的规模。而机器智能和人的智能又各有所长，机器运算量大且不知疲倦，因此对于很多工作都有可能做到精细化管理。这往往能带来成本的节约。 比如在过去公交车的排班是按照经验，在一个线路里设置好公交车的数量，但是如果市民的出行情况发生波动时，公交车的供需关系之间一定会存在差异，有的线路会繁忙，有的线路则会空闲，从而出现资源的浪费。要解决这一问题需要先统计清楚每辆公交车每一趟的精确载客人数，再依靠机器智能精细化的调度公交车到不同的线路，就能在同等资源下实现效率最优。因此使用机器智能的好处是显而易见的。 五年前做不出大规模的机器智能系统 我们看到在生产力发展的过程中，从信息化到智能化的这一转型升级正在到来，已经到了爆发的前夜。这得益于四项技术的成熟：云计算、大数据、IoT、网络连接技术。 我们知道机器智能当前的发展是得益于对脑科学的研究，以及算力的进步，让神经网络进化到了深度学习，从而在视觉、语音等领域有了重大突破。算力的重要性毋庸置疑，但是光有算力依然难以在实际的应用中取得成功，还需要其他几项技术的成熟。在当前的技术环境来说，云计算为智能提供了足够的算力，是算力基础设施；大数据技术提供了数据处理的方法论和工具，是数据基础设施（当前还没有垄断性的数据基础设施，碎片化严重）；IoT 技术将智能设备的成本降到了足够低，为部署丰富的神经元感知设备提供了基础；网络连接技术，从4G到5G，为数据的高速传输提供了重要基础。 如果有科技树这种说法的话，那么机器智能的大规模应用，就需要先点亮前四个技术，这是基础。在五年以前，这几项技术的成本是制约我们将智能技术大规模应用的主要瓶颈。到今天已经逐渐成熟了。 在一项新技术刚出现的时候，我们往往会遇到两个问题。 第一个问题是人才的稀缺性问题。我们知道一个懂深度学习或其他机器智能技术的博士生刚毕业的年薪可能比得上一个工作了十年的程序员。业界各处都需要机器智能，供不应求。 第二个问题是技术的成本问题。新技术刚出来的成本一定是昂贵的，就像云计算刚出来的时候也是先解决能力问题，再解决效率问题。我前些时看一个报告，AWS 的 EC2 推出到现在连续降价了57次。我们熟知的摩尔定律，计算的性能每18个月翻一倍，也就意味着同等算力的硬件每18个月会降一半的成本。机器智能作为新技术也有同样的规律，在一开始我们不要指望它的成本会足够便宜到能进入千家万户，新技术的普及需要时间。只是我们往往迫不及待。 这两个问题决定了机器智能在一开始的时候，应该首先被应用在对社会效率撬动最大的那个点上。从商业上我们要找到这样的场景，来让这项技术脱离实验室，走向社会，通过商业来源源不断的滋养这项技术的迅速成长。 世界需要什么样的机器智能系统 这两个问题随着时间的推移很快就能解决。但今天产业界真正碰到的问题我认为是搞偏了方向。这体现在两个方面。 第一个问题是未来不应该存在一个「人工智能」的产业，我们今天的分类就分错了。就像自电力基础设施诞生以来，各行各业都需要用电，因此电力成为了一个关键生产要素。我认为未来智能也是一个关键生产要素，每个行业都需要，因此不需要单独划分一个人工智能产业。单独搞了一个人工智能产业，反倒不知道这些公司在干什么了，这些公司自己也产生了困惑。最终应该像今天的零售业一样，每个做零售的都有个电商部门，会通过互联网来做营销和销售。未来每个企业也应该有一个部门，就是负责他们的智能系统的建设与训练。要像训练宠物一样训练智能系统，使他具备智能。这不是某一家人工智能公司要做的事情，而是每家公司都要自己做的事情。 第二个问题和机器智能技术的发展有关。因为最近这次机器智能的热点是从深度学习开始，在视觉、语音等领域有了巨大突破，因此产业化后的企业往往都是在做视觉、语音、自然语言处理等工作。但是我们千万别忘了完整的人脑智能是从「感知」到「行动」，并通过不断的反馈完成高频率的协同，最终诞生了智能。 只做「感知」是一个巨大的误区，从技术上讲没有问题，但是从商业上讲创造的社会价值就很有限了，因为其解放的生产力相对是有限的。 从生产力发展的角度来讲，评判一个智能系统的社会价值，应该以它解放生产力的多少来衡量。只做「感知」就是只能看，但是做了这么多大型项目后，我发现所有的价值创造都是在于「处置」环节。因此只做感知，很难讲清楚投入产出是否值得，但是一旦开始进入到「行动」环节，就会开始解放生产力，价值是可被量化的。这里的行动，是机器智能实现了对人力或其他设备的调度。 实际上从技术发展的角度看，我们早就拥有了让机器智能做决策的能力。搜索引擎和个性化推荐，就是典型的通过机器智能做决策。通过每天处理海量的数据，最终实现精细化的匹配。 所以我认为一个完整的「智能系统」，是包含了「感知」与「行动」，其中支撑行动的是决策和调度的技术。而衡量这个智能系统是否有价值的标准，是看其解放的生产力的多少。 遗憾的是，到今天为止我认为业界并不存在一个理想的「智能系统」。业界当前的状态我称之为「有智能，没系统」。很多人工智能的创业公司拥有局部的智能能力，比如视觉、语音、NLP、知识图谱、搜索、推荐等中的一项或多项技术，但是很少有公司有完整的技术栈。而像 BAT 等公司具备完整的技术栈，但是却并没有将所有的技术整合成为「感知」+「行动」的一个完整系统，而是各项技术以碎片化的形式存在。尤其是将所有技术应用到某一个具体场景中解决某一个具体问题的，更是寥寥无几，而这正是催生出这一智能系统的关键所在。所以这是一个工程化的问题，工程化的挑战在于整合所有智能技术，实现完整的「感知」+「行动」能力，并有效的控制成本，实现对开发者友好的接口。 在智能技术的角度来看，「自动驾驶」和「智能音箱」是两个完整的从「感知」到「行动」闭环的场景。我认为这两个场景可以用来打磨机器智能技术，但是当前在商业上比较难成功。「自动驾驶」解放了所有的驾驶员，对解放生产力的价值非常明显，但是因为受制于今天城市的道路基础设施，因此对老城市的意义不大。今天城市的道路不是为自动驾驶设计的，也很难容纳下自动驾驶的汽车。因此自动驾驶更适合航空、航海、物流等领域，商业范围一下小了很多。「智能音箱」综合了多项机器智能技术，其核心技术「对话机器人」被称为人工智能领域的圣杯，想要做好难度相当之大。但是「智能音箱」当前的阶段对家庭中各种任务的生产力解放极其有限，价值很难讲清楚，最后沦为玩物的可能性比较大。尽管如此，随着时间的推移，随着基础设施的更新换代，这两项技术也会逐渐焕发出他们的生命力。 如果用航空业来比喻的话，今天的智能技术，就好比造飞机，市面上已经有了很多零件和引擎，但是所有的厂商都拿着零件当飞机卖，客户以为他买了一架飞机，其实只是买了个零件（因为生产力并没有得到多大的解放）。而今天真正的难点在于飞机设计图纸都还没有。 所以我打算先画一张，造架飞机玩玩。 构建智能时代 飞机想要真正飞上天，还需要几个东西。 首先是飞行员。飞行员不一定要懂得怎么造飞机，造飞机是个门槛很高的活。但是飞行员要懂得怎么开飞机，最后还要让人人都能坐飞机。我认为飞行员就是未来各个企业里智能部门的员工，他们负责训练买来的智能系统，让智能系统真正具备智能。由于各个企业拥有的数据的不同，以及「飞行员」技能的高低和责任心，最后的各个企业的智能系统的聪明程度也会出现差异。世界是丰富多彩的。 其次是航道。我认为航道依然是基础设施提供商的，包括运营商、云计算厂商等。 最后是机场。机场需要负责所有航班的调度和协同，为所有的飞机提供服务。这是最有意思的地方。我认为「机场」是最后真正的商业模式，就像苹果的 AppStore一样。 我认为在智能时代的「机场」，最重要的工作是给机器智能系统提供服务，而并非给人提供服务。 想象一下未来互联网里，70%-80%的人口是机器智能，他们处理了未来世界的绝大多数工作，而每一个机器智能又是有一个主人的。其主人可以是个人，也可以是组织，但都是有主权的。每一个机器智能存在的目标都是为了完成某个或多个任务。那么为所有的机器智能提供服务，就会是一个巨大的商业模式。 机器智能系统的自动协同是通往未来的关键路径 同时我也认为当前的机器智能产业，过于重视人与机器的交互，而忽视了机器与机器的交互。而后者才是更重要的事情。因为人与机器的交互依然是回到了信息化系统的老路上去，而机器与机器的自动协同，则是在进一步将智能系统的价值实现规模放大。 因此未来有必要给所有的机器智能定义一套语言，他们之间的交流可以像人一样拥有自己的语言，实现简单的逻辑。而所有机器智能之间的交互与协同，是不需要人工干预的，就像你家的孩子与邻居家的孩子自己会去玩耍一样，你不需要干预到他们的交流之中，他们自己会各取所需地完成各自的任务。 以「一网通办」的业务举例。在当前一网通办的主流实现办法是将政府各委办局的数据实现全量汇聚后，进行数据治理，并梳理流程，重塑业务。这种大数据应用的思路依然是停留在信息化建设的老路上，其弊端是想推动新技术落地的前提是流程先改革，同时各个不同地区的高度定制化导致很难在全国实现规模化的产品。但其实也可以有另外一种智能化的建设思路，让每个委办局自己建一个机器智能系统，其任务就是代替公务员处理各自的窗口业务。当市民来提交一个申请时，经过认证后，该委办局的机器智能系统就根据所需材料，自行向其他委办局的机器智能系统发出协同请求，经过几轮机器智能之间的交流和协同之后，市民很快就得到了他想要的结果。这种多个机器智能系统之间自动协同的机制，对流程的冲击明显会小很多。 机器智能之间的交互与协同需要通过网络连接到一起，但安全性是可控的，因为是业务之间的协同，而并非数据本身发生了交换。因为每一个机器智能都有自己的主人，所有的训练过程也都发生在其主体内部，因此数据并不需要被拿出来交换共享。主人可以设定机器智能什么能说，什么不能说，所有的安全控制都发生在智能系统内部，而一旦连接到互联网要与其他机器智能协同或使用「机场」提供的服务，就会转为「默认不信任」模式。 至于机器智能系统到底部署在公共云还是专有云，这并不是一个重要的问题，主人爱部署在哪里就部署在哪里。所以时至今日，云计算依然有被管道化的危险，就像运营商被互联网内容提供商管道化一样，未来云计算厂商也可能会被智能厂商管道化。因为云计算和大数据都不是智能。 A组 也因此，为了以上这些构想，我受命在阿里云成立「A组」。「A组」成立的使命就是为了构建出这一机器智能系统，让智能时代更快的到来。 我认为这是一件需要整个社会共同努力三十到五十年的事情，就像在过去的三十到五十年我们在信息化建设上付出的所有努力一样。 以上，就是我想对世界说的话。 我说，你听。原文发布时间为：2019-07-15本文作者：吴翰清