易隐者 - 蚂蚁网-多维人生，三实而立！

欢迎关注:1，欢迎关注本博客，你可点击右手边的【QQ邮件订阅】订阅本博客！2，本博客推出江湖救急计划，主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析，如有需要，请在江湖救急计划页面给我留言！

IDS异常导致业务访问故障的案例

作者：易隐者发布于：2013-3-29 16:46 Friday 分类：案例讨论

【说在之前】：

1，这个是以前我在某个商业银行解决的疑难故障，其中IDS设备出现异常，将原先捕获到的原始数据包通过交换机的镜像口回放至交换机，而交换机的镜像端口并未关闭MAC地址学习功能，引起业务服务器交换机MAC表混乱，导致业务服务器的访问出现异常；

2，这是一个非常少见的疑难故障，因此值得大家学习参考；

3，这段时间由于我个人的规划，工作会作出一些变动，杂事较多，有段时间未在博客中更新新的文章，还望各位兄弟见谅，就将这篇老文作为我三月份博客的更新吧。

【案例全文】：

前段时间晚上，接到某单位朋友电话，说是其一核心业务系统白天出现了故障，很长一段时间没有解决，现在很多厂家工程师都在，让我过去增援一下，明确定位一下故障的原因所在。于是赶紧打的到现场。下面我把故障的情况描述一下：

故障拓扑

经过简化的网络拓扑如下：

故障现象

核心业务访问异常，业务出现中断现象，使用测试pc直接接入业务服务器交换机，设置为服务器同网段IP，在使用ping测试服务器，不通。

故障分析

故障时，交换机MAC表出现异常，主要表现为交换机端口镜像的目的口上，出现了防火墙ETH2口的MAC地址和核心服务器的MAC地址，导致核心业务访问出现异常。

分析业务交换机MAC表异常的原因：

交换机MAC表学习的过程为源地址学习，H3C交换机在做端口镜像时，镜像目的端口默认是可以参与网络数据转发的，那么在交换机端口镜像的目的口上出现了防火墙E2口的MAC和业务服务器的MAC，只能说明该端口上收到了源MAC为防火墙E2口和业务服务器的报文，但是作为与IDS监听口相连的端口镜像目的口，通常情况下是不可能收到任何报文的，因为IDS监听口只是被动监听发过来的报文，而不会主动向网络内发送任何的报文。

这里我们大胆猜想一下：

IDS在极端情况下，工作机制出现异常，将以前捕获的报文，从监听口播放出去，导致交换机口学习到了业务服务器的MAC和防火墙E2口的MAC，这样交换机1根据源地址学习的工作机制，将防火墙E2口MAC和业务服务器MAC对应记录到端口镜像目的端口上。这样可以完美的解释整个故障的现象。如下图所示：

故障解决的方式：

关闭交换机端口镜像目的端口的MAC地址学习功能。这样即使该端口接收到大量的相关报文，其也不会影响交换机正常的MAC地址表项。

到底是不是IDS将以前捕获的报文发送至镜像目的端口？我们可以通过TAP串接抓取IDS监听口的报文。如果是，那么IDS为什么会这么做？这个问题是个疑问，我想只有厂家可以解释了。技术的东西是可以较真的，没什么太多的变数。

阅读全文>>

标签: 端口镜像疑难故障 MAC表 IDS

评论(0) 引用(0) 浏览(5577)

癸巳正月初六日野外见灵芝记

作者：易隐者发布于：2013-2-16 13:01 Saturday 分类：生活见闻

正月初六日访亲，于某山之中，见野生灵芝数枚。但看其层有三，或云其一年生一层，断为三年之芝。

上三尺又见数枚，大小不一，荣枯互现，其中三簇嫩褐黄色隐现于枯叶之中，当为新生之芝。

百度百科中摘录数条史料记载如下：

⒈《别录》：“赤芝生霍山。”“紫芝生高夏山谷。六芝皆无毒。六月、八月采。”

⒉《新修本草》：“五芝，《经》云：皆以五色生于五岳。诸方所献，白芝未必华山，黑芝又非常岳，且芝多黄白，稀有黑青者。然紫芝最多，非五芝类。但芝自难得，纵获一二，岂得终久服耶？”

⒊《纲目》：“《神农经》云：山川云雨、四时五行、阴阳昼夜之精，以生五色神芝，为圣王休祥。《瑞应图》云：芝草常以六月生，春青夏紫，秋白冬黑。葛洪《孢朴子》云：芝有石芝、木芝、草芝、肉芝、菌芝，凡数百种也。石芝石象，生于海隅石山岛屿之涯。肉芝状如肉。附于大石，头尾具有，乃生物也。赤者如珊瑚，白者如截肪，黑者如泽漆，青者如翠羽，黄者如紫金，皆光明洞彻如坚冰也。大者十余斤，小者三四斤。凡求芝草，入名山，必以三月、九月，乃山开出神药之月……时珍尝疑：芝乃腐朽余气所生，正如人生瘤赘，而古今皆以为瑞草，又云服食可仙，诚为迂谬。近读成式之言，始知先得我所欲言，其揆一也。又方士以木积湿处，用药傅之，即生五色芝。嘉靖中王金尝生以献世宗。此昔人所未言者，不可不知。”

灵芝民间又称仙草，与之有关的仙家故事甚多，记得济公传中有云济公出生之时，满屋梁柱皆生灵芝。从网上的相关资料来看，灵芝多生于江西、长白山等，安徽霍山也产紫芝，老家之山虽说是大别山尾脉，与霍山同属大别山脉，但物理距离较远，并从父辈口中得知未曾听闻有人在老家山中采过灵芝，今能于野外亲见之，实乃幸事，是以为记。

阅读全文>>

标签: 灵芝

评论(0) 引用(0) 浏览(5022)

如何保证IT服务的质量？

作者：易隐者发布于：2013-2-5 21:29 Tuesday 分类：IT 服务

IT服务涵盖的范围非常广，其可以是一个具体产品的售后服务，如给用户提供一台设备后的安装与实施，也可以是一个专门的IT服务产品，如各种IT外包服务等。

IT服务不像那些具有具体、明确交付物的产品，我们可以根据产品的形态、功能、性能等特性来衡量其质量如何，比如我们提供给用户的硬件产品，我们可以通过硬件产品的相应配置和性能指标对其进行比较和衡量，从而得出该产品是否符合用户的要求或需求的结论，这很容易实现，双方也都容易理解。但是IT服务的最终成果往往是无形的并且难以衡量，那么针对这些IT服务，我们如何保证这些IT服务的质量是足以让用户满意的？个人总结如下图所示：

以用户/客户为中心

我们提供的IT服务是面向用户/客户的，因此，我们所谓的IT服务质量肯定是以用户/客户的体验和感受为依据，说白了就是用户说你的服务很好，就说明用户认可你的服务，那么服务的目标基本上就达到了，自然就可以认为我们提供的服务质量是令用户满意的。

用户可以根据其感受对IT服务的质量进行评价，但是用户的感受具有很大的主观性，因此我们首先要做的就是在主观上：围绕客户而做好以下几点：

1，维护良好的客户/用户关系

在中国现在的大环境下，一提到“用户关系”，很容易让人想到通过行贿受贿等潜规则换取的交易型用户关系，但我在这里提到的“用户关系”并不是指这种类型的用户关系，而是指通过对用户的尊重、站在用户的角度去考虑问题、积极主动的帮助用户解决问题、成为用户核心业务支撑上的强大后盾等多种方式建立起来的真正意义上的用户关系。这种用户关系建立在真实、平等、互信、互惠互利的基础上，这种更为稳固的用户关系能够大大提高用户主观上对IT服务质量的认可度。当然良性优质用户关系的建立并非一日之功，需要服务团队的每个成员为这种良性关系不断添加正面的积累，通过较长的时间方能逐步建立。

2，服务态度

用户关系是长期而持久的，而服务态度则具体至每一次的服务过程。建立、维护用户关系过程中非常重要的一点就是服务态度，对服务态度的要求并非IT服务行业的特例，所有的服务行业基本上都是一样的，具体主要有以下几点基本要求：

热情：对用户热情，有问必答，不可爱理不理，没精打采，心不在焉

诚恳：对用户诚恳，坦诚相待，特别是在服务过程中出现失误和损失时

积极主动：主动帮助用户提供解决问题的方案，多做一些本职工作分外之事，解决用户的问题，满足用户需求。

在某些技术含量不高的服务工作过程中，态度对服务质量的影响远远超出服务过程本身，举一个简单的例子，在用户不紧急、对用户影响不大的IT环境中，即使提供服务的工程师经验和水平有限，但是在其热情、诚恳端正的服务态度下，用户也不会太责难他，甚至有用户会安慰工程师，给他足够的时间，帮助他协调各种资源来尽快解决遇到的问题，最终虽然解决的时间比预期的长，但用户对服务质量的主观感受也不会很差，这就是良好的服务态度从中起到的作用。当然，在IT服务这个高技术含量的工作中，这个例子不会是一个普遍的现象，但足以说明态度是做好IT服务的第一步，这一步迈不好，所谓的服务质量就无从谈起。

3，沟通并与用户达成一致

主要针对验收标准、免责条款达成一致性意见。

服务的特性决定了其没有直观的、统一的质量验收标准，标准不一是造成验收异议的根源，而一旦用户对服务结果存在异议，对服务质量的影响将不言而喻，严重时，可能会直接导致IT服务不被用户认可，直至整个IT服务工作的失败。另一方面，信息系统的构成是非常复杂的，与用户核心业务系统的正常运转关联的因素非常之多，有时并不是一次性的IT服务就一定能够解决的，可能需要升级其他的IT服务项目或购买相应的设备才能解决，一旦出现这种情况，如果不提前说明清楚并得到用户的认可，事后难免出现分歧。因此，我们应该在提供IT服务之前与用户做全面的沟通和交流，一起就IT服务产品的验收标准和免责条款达成一致意见，并签署相应的IT服务合同。

考虑到用户只关心最终结果而无须关心具体实现细节以及IT服务的专业性，我们一般主要针对IT服务的实施效果作为IT服务的验收标准，比较常见的衡量指标有服务响应时间、网络恢复时间、业务恢复时间、服务完成时间、一次性问题解决率等等。

虽然用户的主观感受在衡量IT服务质量的过程中非常重要，但是由于IT服务高技术含量的特性以及信息系统对用户的重要性，IT服务质量的根本还在于我们能够提供的服务能否高效、经济的解决用户的问题，这就要求IT服务提供者在客观上从如下几点做好自己：

1，专业能力

IT服务高技术的含量特性要求提供IT服务的人员必须具有一定的专业水准，提供具体服务的工程师的专业技术能力水平决定了我们为用户提供的服务所能达到的效果。

一般而言，技术能力更强的工程师总能提供更好的IT服务过程、质量保证，更容易达到令用户满意的服务效果，同时技术能力更强的工程师会产生更高的服务成本，考虑到服务的经济性，我们需要将用户的服务类型和工程师能力水平进行合理的划分，以便我们为用户提供低成本、高质量的IT服务。除了服务团队的梯度划分，我们还必须建立一支专家团队作为强大的技术服务后盾，随时应对服务过程中遇到的各种疑难问题和突发事件，以保证绝大部分的服务质量不会受到小概率突发问题的影响。

IT服务提供者对IT服务团队成员内部的选拔、培训、淘汰、激励等种种制度是保证IT服务团队具备高超专业技术能力的基础。这涉及到整个服务团队的建设问题，是一个大课题，在此就不做过多的阐述了。

无强大的专业技术能力，服务质量无法保证。

2，标准流程

这里的标准流程主要指服务的标准流程和内部的工作流程两方面。

绝大部分的服务的流程都是可标准化的，服务流程标准化的好处是其可以大大减少服务质量的偏差，我们试想一下，如果甲工程师按照其个人的习惯为用户提供某个IT服务，乙工程师也按照自己的一套方式为用户提供IT服务，即使甲乙两人最终都可以完成各自的IT服务过程，但是整个服务质量却会因个人的经验、技术能力、工作习惯等差异的影响而出现较大的偏差，这些都是影响IT服务质量的不可控因素，服务流程标准化之后，提供具体IT服务的人员全部按照标准化的服务流程按部就班的为用户提供IT服务，可以大大减少这些不可控因素对服务质量的影响。经过不断完善的标准化的服务流程还可以大大提高服务的效率，让经验不足的工程师在提供服务的过程中少走弯路。

另一个标准流程主要指IT服务团队内部的工作流程标准化，包括IT服务请求的受理、服务过程的状态监控、状态通告、服务升级、服务评价、投诉等等。

3，检验考核

为用户提供的每个具体的IT服务都应该在经过检验后纳入服务团队内部考核之中。针对服务质量的检验主要指用户检验和内部检验两种，用户检验可包含对服务提供者的服务态度、主动性、专业性等多方面给出评价，内部检验则从用户的反馈、服务的交付物等方面对其服务过程和质量作出检验。

将用户对服务过程的检验反馈和内部对服务质量的检验结果作为团队内部考核的内容之一，这样做的目的是督促具体的IT服务人员，鼓励其主动做好IT服务工作，提高IT服务的质量和用户的满意度。

4，交付物

绝大部分的IT服务是无形的，不像有形的IT产品那样，用户可以清清楚楚的看到他的机房里放着一台服务器、交换机、防火墙，因此IT服务作为一个无形的产品，我们需要将服务的成果实体化、具体化，最为常见的形式就是服务文档。我们在每一次提供IT专业服务之前就应该告知服务后会有哪些交付物交给用户，这些交付物大部分都是服务文档，这些文档主要包含所提供的专业服务的完成情况、给用户带来的可评估效果、给用户的改进优化建议、解决方案等等不一而足，一般根据具体的IT服务类型提供不同内容的文档，这个需要结合服务团队的服务目录做专门的文档架构、设计和规划。

服务文档交付物让用户直观的感受到IT服务的价值，同时也是体现服务专业性的一种方式，另外有些服务文档还可以作为服务团队内部的知识库。在专业的IT服务产品中，交付文档是不可或缺的，我们需要认真细致的对待每一个服务之后递交给用户的交付文档。

总结

IT服务的质量保证工作应该以用户感受为中心，态度为基本门槛，专业能力为基础，内部管控为根本，外部关系为升华。通过不断的完善与加强，在上述主客观、内外部的因素之间形成良性循环，不断提升IT服务的质量和用户的满意度。

阅读全文>>

标签: 解决方案交换机团队响应时间团队成员服务质量保证交付物 IT服务

评论(2) 引用(0) 浏览(5949)

某公司业务系统经ISA防火墙访问正常而经硬件防火墙访问慢故障分析解决案例

作者：易隐者发布于：2013-1-25 10:10 Friday 分类：案例讨论

1 故障环境

这个故障产生的环境较为简单，我们在不影响故障分析的前提下，简化分析网络环境，其故障发生的拓扑结构大致如下所示：

1.1 网络拓扑

故障发生的拓扑结构如下所示：

1，业务服务器的IP为16.66.252.249/24，网关为16.66.252.254；

2，测试客户端的IP为16.66.180.167/24，网关为16.66.180.1；

3，防火墙与服务器相连的接口地址为16.66.252.254，防火墙与测试客户端相连接口的地址为16.66.180.1；

4，防火墙工作在纯路由模式下；

1.2 业务访问流程

1，业务服务器的业务端口为TCP 211；

2，测试客户端将数据报文经过硬件防火墙转发至业务服务器端，业务系统根据测试客户端的相关请求，返回业务应用数据报文经硬件防火墙转发给测试客户端；

2 故障现象

经过与用户的交流和现场的测试，确定故障现象主要表现为以下几点：

1，客户端经过ISA访问业务服务器，测试连接速度非常快；

2，将ISA换成天融信硬件防火墙，硬件防火墙工作在纯路由模式下，测试发现客户端连接业务服务器的大概需要消耗20秒左右的延时；

3，用户反馈，测试过使用cisco的ASA和H3C的硬件防火墙，均有不同程度的较大的连接延时；

3 故障分析

3.1 分析过程

3.1.1 确认是否是硬件防火墙产生的延时

经过ISA防火墙，业务系统连接测试一切正常，速度很快，但是经过硬件防火墙（TOPSEC/CISCO/H3C）之后，就产生了较大的延时，那么看起来似乎是硬件防火墙产生的延时，我们先从这个角度入手，在测试客户端与业务服务器端同时抓包做对比分析，用于确认是否是硬件防火墙产生的转发延时。

1，我们分别在服务器、客户端上安装科来网络分析系统，并开启捕获界面；

2，在测试客户端上做应用连接测试，当测试客户端弹出连接成功窗口后，分别停止客户端与服务器端的捕包界面；

3，我们通过科来网络分析系统的“TCP会话”视图分析客户端上的测试连接建立的TCP会话过程，如下图所示：

客户端的这个数据交互过程充分说明了，在测试连接的过程中，产生了17秒左右的延时。

4，通过科来网络分析系统的“TCP会话”视图分析服务器端的应用连接建立的TCP会话交互情况，如下图所示：

上图清晰的反应了服务器端的应用层响应是在延迟了16.34秒后才发出了；

5，对比分析客户端与服务器端的数据交互过程，我们可以得出以下两点结论：

 经过硬件防火墙，应用连接的建立花费了17秒左右的时间；

 这个延时不是硬件防火墙产生的，而是业务系统应用产生的。

3.1.2 分析经过ISA防火墙时的业务交互情况

既然这个延时是业务应用本身产生的，跟硬件防火墙完全无关，那么为什么经过ISA访问的时候，连接测试一切正常呢？

我们还是在业务服务器上捕获客户端与服务器测试应用连接建立交互的数据报文，分析一下经过ISA访问业务系统时的数据交互情况，如下图所示：

其连接正常响应时的数据交互情况大致如下所述：

1，客户端与服务器通过TCP三次握手建立连接；

2，连接建立成功后，客户端立即向服务器端发送了应用层连接请求报文，该报文长度为150字节；

3，服务器在收到这个应用请求之后，在0.006645秒内，响应了客户端的应用层连接请求，这个报文长度为74字节，应用层字段长度为16字节；

4，客户端响应了服务器端的应用层响应报文，向服务器端发送应用层字段长度为16字节的报文确认；

5，应用测试连接成功，客户端主动通过TCP四次握手过程，正常释放TCP连接；

上述过程清晰的展示了客户端在经过ISA访问服务器时，应用连接建立的时间是非常短的，速度非常快。

3.1.3 分析经过硬件防火墙时的业务交互情况

在确认了经过ISA防火墙的业务系统网络交互行为之后，我们再来分析一下经过硬件防火墙时，业务系统的网络交互行为是怎么样的。

1，我们首先在服务器端开启科来网络分析系统捕获服务器交互的所有数据报文；

2，在测试客户端上做业务应用连接测试，当测试客户端弹出连接成功窗口后，停止服务器端的捕包界面；

3，我们通过科来网络分析系统的“数据包”视图，查看这个过程中业务服务器的数据交互情况，具体如下图所示：

交互过程说明：

 服务器端在接收到客户端的应用层请求报文后，没有立即向客户端发送带有应用层数据的连接响应报文，而是先向DNS反向解析客户端地址对应的域名；

 由于防火墙无法访问互联网，因此，硬件防火墙返回ICMP目的网络不可达差错报文；

 服务器端在尝试4次DNS反向解析失败后，发送NBNS名字解析报文；

 NBNS解析成功后，服务器端才向客户端发送应用层连接请求响应数据报文；

4，通过上图的数据交互情况分析，我们可以得出以下两点结论：

 服务器端在收到客户端的应用连接建立请求报文后，没有立即发送应用响应报文，而是首先做反向名字解析，解析不成功，再做NBNS解析；

 17秒的延时，就是服务器4次DNS反向解析失败产生的。

3.2 分析结论

通过上面一系列的分析，我们可以确定，导致该故障产生的核心原因是业务系统程序的处理机制异常导致的。

4 故障解决

我们知道了经过硬件防火墙访问业务系统变慢的原因是因为业务服务器在接收到客户端的应用请求时，需要针对客户端的IP地址做一个反向名字解析，那么我们可以通过在业务服务器的hosts列表中添加客户端的IP对应的主机名，以此来避开服务器的反向DNS名字解析过程，从而解决了业务系统慢的问题。此方法已经现场测试验证有效。

阅读全文>>

标签: 疑难故障防火墙 DNS ISA

评论(7) 引用(0) 浏览(10926)

TCP Fast Open（TFO）

作者：易隐者发布于：2013-1-10 15:22 Thursday 分类：网络分析

【说在之前】：

我在之前的博客文章《非标准TCP三次握手建立连接过程一例》一文中提到了非标准的TCP三次握手行为，今天在微博上看到有人转发有关TCP Fast Open（TFO）的文章，大致看了一下，了解到所谓的TCP Fast Open（TFO）就是利用三次握手的SYN报文来传输应用数据，也就是说，允许SYN报文中包含应用数据。这样做的好处是在客户端与服务器的交互过程中减少一个RTT来提高交互的效率，如此来看，TCP Fast Open（TFO）就是一个最为典型的非标准TCP行为，但是这种非标准的TCP行为由于其特性优势使其将成为国际标准，其具体的交互过程和原理大家可参考下面的文章和相关链接。

【原文链接】：

http://blog.sina.com.cn/s/blog_583f42f101011veh.html

【原文全文】：

Google近日正式公布了TFO的paper，地址：http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/zh-CN/us/pubs/archive/37517.pdf

Google研究发现TCP三次握手是页面延迟时间的重要组成部分，所以他们提出了TFO：在TCP握手期间交换数据，这样可以减少一次RTT。根据测试数据，TFO可以减少15%的HTTP传输延迟，全页面的下载时间平均节省10%，最高可达40%。

目前互联网上页面平均大小为300KB，单个object平均大小及中值大小分别为7.3KB及2.4KB。所以在这种情况下，多一次RTT无疑会造成很大延迟。

在HTTP/1.1中，我们有了keep-alive。但实际应用并不理想，根据Google对一个大型CDN网络的统计，平均每次建连只处理了2.4个请求。

为了证实TCP三次握手是目前页面访问的重要性能瓶颈之一，Google工程师分析了Google的web服务器日志及Chrome浏览器统计数据。

2011年6月，对Google web服务器进行连续7天数十亿次针对80端口的请求分析，包括搜索、Gmail、图片等多个服务。其中第一次建连被称为cold requests，复用连接的请求称为warm requests。

图中描述了在cold requests及all requests中TCP握手时间在整个延迟时间中的占比。在cold requests中，TCP握手时间占延迟时间的8%-28%；即使统计所有的请求，TCP握手时间也占到了延迟时间的5%-7%。

对Chrome浏览器的统计持续了28天，当然仅限于愿意发送统计数据的用户。经过分析，即使打开了keep-alive，仍有33%的请求建立了新连接。主要原因可能为：为了加快下载速度，新版的浏览器对单个域名都会并行打开6-10个连接；而网页设计时也会把元素分配到多个域名上；NAT也可能关闭keep-alive；而手机端为了节省电源，也会尽快关闭空闲连接。

图中对比了三条线，一条为all requests；一条为cold request；而cold req no hsk代表去除了TCP握手时间的cold requests延迟数据。Y轴把所有采样数据按数值分布到各个百分比区间。

对比证明：cold requests基本比all requests慢50%，而TCP握手时间在cold requests延迟时间中往往占比了25%。

下面这幅图清楚的说明了TFO的设计：

1、用户向服务器发送SYN包并请求TFO cookie；

2、服务器根据用户的IP加密生成cookie，随SYN-ACK发给用户；

3、用户缓存住TFO cookie。

再次访问时：

1、用户向服务器发送SYN包并携带TCP cookie，同时请求实体数据；

2、服务器校验cookie。如果合法，向用户发送SYN+ACK，在用户回复ACK之前，便可以向用户传输数据；如果cookie校验失败，则丢弃此TFO请求，视为一次普通SYN，完成正常的三次握手。

因为用户使用DHCP，IP地址会改变；同时也为了防止攻击，服务器端会定期变换cookie。

建立了TFO连接而又没有完成TCP建连的请求在服务器端被称为pending TFO connection，当pending的连接超过上限值，服务器会关闭TFO，后续的请求会按正常的三次握手处理。

而一个带有TFO的SYN请求如果在一段时间内没有收到回应，用户会重新发送一个标准的SYN请求，不带任何其他数据。

在集群环境中，所有服务器会使用相同的key。

目前TFO被植入了Linux 2.6.34内核。

为了验证TFO的作用，Google分别测试了全页面的下载时间及开启TFO对服务器性能的影响。平均来看，页面一般会包含44个元素，分布在7个域名中。同时浏览器会支持并行下载。抽样的测试对象为：亚马逊、纽约时报、华尔街日报和维基百科。可以看到RTT时间越大，TFO的效果越明显。当RTT为200ms时，改善达到了11%-41%。这对移动互联网尤其意义重大。