博客园_LiXiong's Debugging paper

Web服务的性能，和BCrypt性能问题的解决方法

2011-12-24T17:51:00Z

在昨天的研究中，发现BCrypt最大的隐患在于性能。BCrypt的安全性是通过牺牲性能来获取的。BCrypt比传统hash+salt要安全一万倍，但是代价是使用BCrypt做认证对比密码和密文时候，性能也比hash+salt要慢一万倍。

所以，我得出一个结论。如果使用传统hash+salt需要N台认证服务器的话，那用BCrypt就需要添加10000*N台服务器才能达到同样的性能。比如一个邮件系统使用了2台服务器来专门作认证，那使用BCrypt的话就需要再购买2万台。当然，小的应用，如果使用一台服务器1%的性能就可以做完认证的话，使用BCrypt只需要100台服务器。

这个听起来比较吓人，但是我通过另外一种计算方法，也能得出同样的结果。比如说163的邮件系统，峰值的时候每秒钟可能需要处理10000个登陆请求。比如每天早上9点到9点半之间，很多人都会登陆邮件系统。按照BCrypt提到的，每个请求需要花费0.3秒，那么处理10000个请求需要3000秒。这显然是不能接受的。如果要让客户都能在1秒钟登陆，那就需要添加服务器，把登陆请求均分到各个服务器上。对于单CPU的服务器，就一共需要3000台。

我把上面的想法和网友讨论后，得到了不同的意见。有人觉得0.3秒的处理时间其实不多阿，因为通常一个web请求，内存，磁盘数据库转一圈下来，离0.3秒也差不多了吧，所以BCrypt的0.3秒的开销是一个正常值，不会带来什么问题。有人提到普通web服务器每秒处理1000个请求是很常见的。如果按照我上面的计算方法，这就表示每个请求在1ms内完成了，这听起来有点不可能嘛。

根据上面的意见，我又仔细思考了一下。我想借这个话题，先讨论一下Web服务器的性能，再看看BCrypt带来的问题应该如何解决。

注意，下面所叙述的，是根据我现有知识和经验做的逻辑推理。我没有写半行web程序的code来验证，我也没有任何大规模web项目的经验。但是我非常喜欢先做这样“纸上谈兵”的推理，因为这样可以让我先仔细想清楚后再行动。

网页的加载时间，和单个request的处理时间是不一样的。单个网页中往往包含多个子元素，比如图片和AJAX调用。这些子元素的加载都会在额外的request里面完成。另外网页加载的时间除了web服务器的运算处理时间外，还有数据在网络上的传输时间，脚本运行时间，浏览器绘制时间，当然如果是第一次访问，还包括DNS查询和TCP握手时间等等。现在主流网站的页面加载时间都在2秒以内，每个页面大概包含10-50个子元素。客户端脚本和浏览器的处理占用了大概一半时间，所以跟服务器相关的时间大概就是1秒。由于部分子元素可能在浏览器中有cache，所以这1秒钟对应的大概就是5-25个请求。这样算下来每个请求大概在200-40毫秒之间。这里面大概web服务器的运算开销可能只有25%，那大概就是50ms到10ms之间。注意，50ms-10ms这个估算是指平均时间。

由于网络传输和客户端导致的开销不是今天的讨论范围，所以下面就只讨论web服务器运算一个request需要怎样的开销。处理一个web request，通常牵涉到下面一些工作。输出流添加，数据库读写，文件读写，复杂计算。输出流添加是最常见的，比如服务器会把Response.Write里面的内容加入到Response里面。输出流添加是非常快的。速度和string.format或者StringBuilder.Append应该在一个数量级。肯定比毫秒要快多个数量级。复杂计算是指需要CPU密集超过50ms的运算，比如正则表达式运算和BCrypt操作。数据库读写和文件读写所需要的时间往往也超过50ms，但是这两者不一定需要占用web服务器的CPU资源。

由此，在考量web服务器运算一个request所需的开销的时候，先看这个request是不是需要复杂运算。如果需要，那么这个复杂运算肯定是一个瓶颈。

那么数据库和文件操作是不是瓶颈呢。从处理request所需的时间上来说，这两者肯定也是瓶颈。因为再快也得先等到这两者返回。但是和复杂运算相比，复杂运算损害的不单单是request所需的时间，另外还损害了服务器的可伸缩性。

由于数据库和文件操作不占用web服务器的CPU，所以web服务器在等待数据库和文件操作结果的时候，可以把CPU资源用来处理新的request。比如来了100个请求，每个请求都需要2秒钟的数据库操作，不等于说服务器需要200秒才能处理完所有请求的。因为服务器可以让100个请求都进来，然后发送者100个请求的数据库操作，然后让这100个请求同时等待。2秒钟以后，这100个数据库操作的结果都返回回来后，服务器可以把这100个请求的结果都返回了。

但如果请求中牵涉到了复杂运算呢，服务器就没办法并发了。如果来了100个请求，每个请求都需要运算2秒钟，而服务器如果只有一个CPU的话，那就一定需要200秒。

由此可见，请求的平均处理时间和服务器的吞吐量不是简单的比例关系。这牵涉到这个请求具体是如何处理的。如果服务器的吞吐量是1秒钟1000个请求，不能简单地用1000毫秒除以1000，得到每个请求只需要1毫秒来处理。这个运算法则只在没有任何并发可能性的情况下才有效。这也在此证明了，合理使用异步调用，对服务器性能会有多大的提高。

接下来反过来想，对于一个不涉及数据库，不涉及文件，不涉及复杂运算的请求，合理的处理时间应该是多少呢。这个处理时间其实等同于同等复杂程度的函数调用时间。换句话说，如果只是计算出一个几十k的页面，花费的时间肯定在1ms的数量级。你肯能觉得这里没有考虑web服务器的“仪式性”开销，比如说处理TCP报文，分析HTTP头等等。其实，主流的web服务器在这方面已经足够优化，比如从IIS6开始，对于HTTP协议的处理都直接在内核里面做了，所以就算把这些开销都算上，也能做到1ms的数量级。对于计算机来说，1ms其实很长的，1ms表示一秒内调用函数1000次而已。不信你可以估算一下下面的代码，循环了10000次，大概需要多少时间：

StringBuilder dummy = new StringBuilder();

for (int i = 0; i < 10000; i++)

{

dummy.AppendLine((string.Format("this is {0}", i)));

}

var len = dummy.Length;

另外，上诉的讨论还没有考虑一个非常重要的武器:Cache。如果使用cache, 整个页面可能根本不需要任何运算，都不需要跑一行处理代码，web服务器就把结果给返回了。如果大量使用cache，别说一千次，一秒钟处理上十万次都可以。大多数的网站已经广泛使用cache了，图片是cache的，blog文章的内容是cache的，甚至评论都是cache的。正因为如此，把包含复杂运算，数据库和文件处理的慢操作跟带cache的块操作一平均，结果落到前面估算的50ms-10ms是很自然的事情。

有了上面的分析后，再来看文章前面的两个问题。第一个问题是，BCrypt的300ms开销，和数据库，磁盘文件兜一圈下来的开销也差不多阿，为什么说BCrypt就更严重呢。原因是BCrypt的300ms都压在了CPU上面，而人家的是可以并发的。当然，动不动就要去兜数据库和磁盘文件的web应用，设计上也有问题的。第二个问题是，我的服务器可以一秒钟处理1000个请求，按照原来的计算方法，就是1ms处理1个了，这个不可能吧。这个问题就要区分情况来回答了。首先，1ms处理1个请求是可能的，比如使用了cache，绝对能。其次，如果考虑并发的话，的确不能简单做除法。但问题关键是，BCrypt是不支持并发的阿。

所以，BCrypt最大的隐患的确就是在性能上。我所做的下列判断是正确的：“如果使用传统hash+salt需要N台认证服务器的话，那用BCrypt就需要添加10000*N台服务器才能达到同样的性能”。

接下来的问题是，BCrypt性能问题有解决办法么。在前面的逻辑推理中，我想到了一个最常见的办法：用空间换时间。我可以在内存中建立cache，把密码原文和用BCrypt计算后的hash缓存起来。这样每次处理认证请求的时候，就不需要计算了。当然，这里其实带来了新的安全隐患。如果有人盗窃了服务器的内存转储(memory dump), 那么就能看到cache里面的东西，那可就是密码的原文明文阿。这有何去何从呢？

引起这片文章的讨论来源:

http://weibo.com/1709648133/xDtMxivam

http://weibo.com/1709648133/xDy7YjYX0

本文链接

md5/sha1+salt和Bcrypt

2011-12-23T20:04:00Z

今天在weibo.com上看到一则消息说, 用md5/sha1+salt的方法保存密码是不安全的. 文章中用连续9个Bcrypt加感叹号来强调, 保存密码一定要用Bcrypt.

这个消息非常应景, 因为csdn.net两天前把数据库弄丢了, 里面的密码是明文保存的. 我对密码和安全没有研究, 但是在我粗浅的记忆中, hash+salt是非常主流的方法. 如果说这样也不靠谱, 那我正好借这个机会复习一下.

我把密码安全分为两个等级, 黄色和红色. 当数据库丢失后, 能算出一个可以用来登陆的密码, 这个密码不一定是原文, 但是保证可以通过验证, 这个算达到黄色. 如果还能算出原文, 这个就达到了红色.

红色比黄色严重得多. 因为用户往往在多个网站上都使用了同样的密码. 如果攻击者拿到原文, 这等于说多个网站都受到影响了. 如果拿不到原文, 那攻击者最多也就破坏当前这个泄露数据库的网站, 不会影响到其它网站.

在我看来, 很多用户对安全的要求是, 如果我使用的网站A不幸阵亡了, 只要密码原文不泄漏, 就不会伤及我使用同样密码注册的其它网站. 至于在网站A上面的任何损失, 我都不在乎了.

在这个背景下, 我的本能看法是, 用hash+salt难道不能实现上述的要求, 一定要使用Bcrypt吗?

如果仔细分析一下黄色和红色的定义, 会发现一个问题. 对于一个给定的可以用来登陆的密码, 如何判定这个密码就是原文呢? 这里的解决方法通常就是对比字典, 或者观察这个密码的字面特性.

既然牵涉到字典, 情况就更加有趣了. 破解密码的两种方法分别是穷举和字典. 我从wikipedia以及介绍上Bcrypt的资料上了解到, 如果只是穷举, hash+48位的salt算起来已经比较困难了. 文章中说，半分钟可以穷举完所有的6位密码。可以想象，如果加上一个48位的salt, 按照复杂度的增加比例，要穷举完所有可能的密码，至少还是要按月算计算的吧。

在这样的情况下，如果要想得到密码原文，首先需要花大量时间把很多可能的密码都算出来，然后才能挑选原文。就算用集群计算机，这个也需要几天时间吧。我想也不是所有用户都能享受到这个待遇的吧。如果这条路走不成，那就只有反过来，根据现成的字典来算。如果不幸使用了字典中能查到的就活该倒霉了。

当然，上面的假设是窃密者不知道salt的情况. 如果salt一起丢了的话, salt对单个用户的保护就完全丢失了。这个情况下salt的作用是让窃密者必须对每个用户都单独计算。但是即便是这样，如果密码稍微复杂一点，用8位数字字母组合，暴力走一遍也需要60的8次方除以700M，结果是66小时。实际时间应该比这个更长一点，因为这个时间没有考虑到长度小于8位的。

为了证明我的想法，我特意花了20大洋，到http://cmd5.com/ 这个网站上买了4次破解机会。我提交了一个123456作为原文，12位salt计算出来的密文。另外再提交了一个8位包含大小写数字和一个@字符的原文，12位同样salt计算出来的密文。提交的时候把salt一起提交的。明天我再看看他能计算出怎样的结果。

根据上面的分析，使用hash+salt的话，在不同情况下有不同的结果：

如果salt没有丢，除非你的确是机要人员，基本上安全。普通cracker不会花这么多精力来搞你。

如果salt丢了，情况根据密码复杂度来看。简单密码就秒破到原文了。对于8位普通程度的密码，比如315@hkBJ这样的密码，对方可以在几个小时内走到黄色等级，但需要2天时间才能开始分析原文。

再来看看使用 Bcrypt的话，情况会有如何变化。Bcrypt其实是通过增加计算密文的成本来换取安全。使用Bcrypt，默认设置下登陆时间会增加5个数量级，破解成本也会增加5个数量级。所以使用Bcrypt的话，根据我的理解，情况分为两种：

如果Bcrypt的salt丢了，使用简单密码或者字典中存在的密码，秒破的时间从小于一分钟变到几天时间。所以使用简单密码还是不安全的。但是如果salt没有丢，或者即便丢了但是使用了稍微复杂的密码，要达到黄色平均时间都上年了，要到红色就不可能了。

所以，总的结论是：

如果使用不安全的密码，什么都帮不上忙。

如果使用hash+salt, 事故发生的时候，如果salt丢了，算法也没有特殊的地方，只要遇上专业人员，如果密码在8位以内，要拿到可能的密码原文，基本上是一个星期的工作。我估计花1W RMB应该能找到人干。但是如果密码里面的特殊字符多一点，或者长度再长一点，基本就安全了，除非你是重要人物。

如果使用Bcrypt，那当然最好了。丢了什么都不怕。但是，使用Bcrypt的成本是，负责做认证的服务器，可能要扩容几十倍或者几百倍哦，它是靠把计算成本提高5个数量级来换取安全的。

作为设计人员，使用Bcrypt肯定安全很多。但是安全的代价是性能。小型的应用没有问题，但如果每秒峰值要做到上万次登陆呢？毕竟每次登录默认0.3秒的开销摆在那里，一万次是3000秒，如果要保证登陆在1秒内完成，须要3000个服务器啊。所以在大一点的应用上使用Bcrypt，登陆服务器的设计和Bcrypt参数的配置都要仔细考量。在这样的权衡下，我觉得使用hash+salt仍旧是不错的选择. 前提是要做到如下几点: 把salt单独存放，使用SHA512, 独立设计hash方法比如把salt插到password中间，多做几层hash，另外把代码和数据库分开存放。

下面这篇文章详细分析了Bcrypt的性能。得到的结论是除非你给五角大楼写程序，通常的SHA512足够好了。

http://www.binarylogic.com/2008/11/22/storing-nuclear-launch-codes-in-your-app-enter-bcrypt-for-authlogic/

“The level of security your app provides is really up to you. Unless you are writing apps for the pentagon, the default Sha512 is fine. Regardless, Authlogic shouldn’t get in your way or make decisions for you, so if you feel BCrypt is necessary then go for it.”

作为用户来讲，主要是做到两点。首先要使用比较复杂的密码，其次是不同安全级别的网站要使用不同的密码。比如国内网站和国外网站坚决不用一样的。银行密码不用一样的。如果注册使用邮箱作为源，那这个源的密码要特别设计。

以上就是今天晚上研究了4个小时的收获。看来我7年前了解到的hash+salt，在新时代的计算能力面前的确比较脆弱了。我算重新入门了一次。多谢 @左耳朵耗子.

从Win8回顾微软平台的各种技术

2011-12-03T06:15:00Z

我安装好Win8 CTP后做的第一件事情就是用调试器研究Win8各个组件的协作关系. 从我半天的研究结果看来, Win8真是一个让我爱不释手的产品. Win8里面涉及到的很多技术正好也是我的兴趣所在. 这篇文章简单回顾一下这些技术的变迁, 优缺点, 和对Win8的影响.

注意, 下面提到的对Win8的分析, 是基于公开的Win8 CTP来做的. 相信Win8面世的时候, 这些技术和细节, 都会发生重大改变. 所以这篇文章不具备实践上的指导价值.

COM -Component Object Model 通用组件模型

COM是上个世纪中期设计出来的伟大产品. COM旨在解决软件复用的问题. 在COM以前, 大家都是用代码级别的复用, 常见的就是C/C++的库, 无论是原代码库还是lib库, 都是需要编译后才能重用的. COM使得技术人员可以在二进制上进行复用. 从Win95, OLE32和Office95系列开始, COM就是微软平台上的一个技术基石, 无论是DirectX API, 还是最常见的剪贴板, 以及后来.NET Framework的host接口, 都离不开COM. 但任何伟大的产品, 都有局限的一面. COM在局限性在下面一些地方

STA/MTA/NTA等等线程模型过于复杂

线程模型, 特别是STA, 设计的目的是方便使用者. 但COM的线程模型严重依赖于太多系统组件, 比如Win32 Message, RPC和Windows系统服务, 使得程序员需要熟悉和了解太多系统知识才可以正确地使用线程模型. 否则用STA导致死锁简直就是家常便饭.

开发工具没有提供足够支持

COM和Visual Studio 6.0的关系, 就如同现在CLR2/VS2005, CLR3.5/VS2008和CLR4/VS2010的关系一样铁. 使用COM开发, 当时的选择要么是VB6, 要么用ATL. 这两者都有天生的局限. VB6适合企业开发, 特别是当时流行的MIS系统, 数据库系统这样的CS应用, 但是VB6不够灵活. 而且VB6里面由于缺少多线程支持, 无法用MTA的模型. ATL功能强大, 足够灵活, 但是使用起来特别复杂. 每次实现一个接口, 都要做一大堆C++的仪式性工作, 比如实现多重继承, 定义新的模板, 使用大量的C宏. 神经再粗大的程序员, 都经不起这样用C++的.

无止境地扩充到DCOM, COM+, DTC, MSMQ以及后来的.NET Remoting/WCF, 使得最后的复杂度无法控制

为了更好地适应企业级别的开发, COM被进一步延伸和演化成了DCOM和COM+. 所谓"企业级别", 其实是指对安全性和可伸缩性的更高要求. 经典的COM是一个进程内模型, 无法让不同的代码运行在不同的帐号下的, 因为同一个进程只能启在唯一的帐号下. 虽然通过impersonate等方法可以适当地解决问题, 但是为了让安全模型更为全面, 正确的做法是让不同的接口实现, 能够跨越进程甚至跨越机器等安全边界运行, 要能够赋予不同的接口不同的安全级别, 能够和域帐号集成, 支持不同等级的加密等等.远程通用组件模型, 也就是DCOM就这样诞生了. 读者可以尝试运行以下dcomcnfg.exe这个工具, 展开一些节点, 看看属性页, 就能体会到DCOM的功能是多么让人眼花缭乱了. 对于可伸缩性, 微软更上一层楼, 在DCOM的基础上加入了对象池和新的同步模型做成了COM+. 风靡十年的ASP, 就是运行在COM+框架下的最好例子. 更让人叹为观止的是, 微软把DTC和MSMQ的设计也和COM+模型绑定起来. 陌生的读者可能不了解DTC是个多么nb的东西. 简单说DTC是可以让程序员一行代码都不用写, 就让SQL Server和Oracle的数据库操作运行在同一个事务边界里面. 可以想象, 在MSSQL Server刚进入市场的时候, 微软推出这样的功能, 对于抢占Oracle的市场份额有多么重要. DTC和COM+当时成为了很多大公司的标准配置, 以至于后来设计.NET Remoting和WCF的时候, 都还是要考虑对DTC的支持. 这些强大而且复杂的功能, 让本来就复杂的COM更加恐怖. 这样的复杂度虽然也体现了当时的市场需求, 但由于缺乏配套的开发工具, 新的开发语言和更优美的抽象, 使得这条路最后越走越窄.

.NET Framework/CLR

在我眼中, CLR的各方面简直是无可挑剔的. 但可能正是因为CLR太好了, 让微软从2003年开始, 对unmamanged world的投资就不大了.

为了争取企业客户, 全力推广CLR是最正确的做法. 毕竟绝大多数的程序员, 一辈子都是和数据库, 和UI代码打交道. 你总不能让他们一辈子都用C去管理内容, 创建窗口句柄吧. CLR的性能也很有竞争力, 与之对应的编程语言和开发工具也非常给力, 每个新版本都带来长足进步. 但是, 这些再好, 也无法掩饰一个悖论: 要用用C#写出性能可以和C++一个数量级的程序, 不是不可能, 而是花费的代价往往比直接用C++写更大. 这里面有很多原因. 比如系统最底层的API还是unmanaged的, 通过CLR作interop的性能损失无法忽略. 比如用C#的话程序员的控制力很弱, 从工具和语言层面上很难对性能精雕细作, 一不注意就box/unbox了. 比如JIT编译器为了实现自己的安全模型和异常处理, 每次访问成员函数的都是都要生成代码确认this指针是否为空. 这个世界上还是有很多程序, 是需要对性能做严格控制的. 在CLR高速发展的几年中, 对应的系统平台, Win32 API, C++开发工具, 只有完善性的改善, 并没有重大突破. 这个问题对Windows平台本身影响不大, 但如果寄希望于在移动设备上, 大家都指着C#来开发, 就有点天方夜谭了. 这样的失衡, 使得微软在移动设备和消费者产品这两个严重需要unmanaged和系统投入的领域缓慢发展了很长时间.

WPF

在我看来, WPF是一个设计得很美的产品. WPF解决了传统Win32 UI程序的四大局限. 1) Win32的绘图是由各自Window元素独立控制, 基于GDI的. WPF引入了rendering thread来提高性能, 优化算法, 借用GPU加速. 2) Win32依赖于GDI Object, 在开发复杂窗口程序的时候, 很容易就遭遇资源泄露和资源不足. 比如早期的淘宝旺旺, 开到几十个窗口的时候, 程序就会出问题. 所以淘宝针对这个问题, 使用了统一控制台, 合并多个窗口到标签页的方法来解决. 而WPF只有最外面的窗口使用了Win32 Window和GDI, 内部的元素都是抽象成了WPF自己的元素, 不额外占用Win32 GDI资源的. 3) Win32窗体程序严重依赖Windows Message模型. 这要求程序员对系统知识有深入的了解. 而且Win32 API并不是非常利于使用, 比如要进行UI thread和Worker thread之间的通信, 往往需要和SendMessage这样的API打交道. 在WPF中, 引入了Dispatcher类和BeginInvoke方法, 把这些复杂问题抽象了. 加上CLR提供了更方便高效的开发环境, 使用WPF是很愉快的工作. 4) Win32缺乏数据, 设计和代码三者之间的模式抽象. 这三者在WPF中对应了数据绑定, XAML文件, 以及后台代码. 在WPF中可以更直观地使用各种模式比如MVC和MVVM. 这些都体现了WPF设计上的优美.

再优美的东西都还是有局限性的. WPF的问题在于过多的模式和对CLR过度的依赖. 了解WPF框架的人都知道, 就一个简单的dependent property, 就把设计模式这本书里面的模式用掉一大半了. 分析WPF框架代码的话, 简直就是看一本设计模式的百科全书. 我曾经统计过, 关于mouse click这样一个event回调, WPF里面有7种不同的实现方法, 分别各有好处, 旨在解决不同问题. 在这样高度灵活的背后, 牺牲的是程序性能. 无论是五花八门的模式, 还是最常用的数据绑定, 背后的主力都是CLR的reflection. 过度依赖于reflection导致WPF程序规模一大, 性能上就出问题. 就算再怎么优化, 也总找不到原生Win32程序那般流利的感脚. 使用reflection也体现了对CLR的依赖. 所以前面CLR的局限性, 也适用于WPF.

微软产品的互操作性

微软的产品线虽又长又多, 但是各个产品之间一定是能够互操作的. 比如C#可以和C++互相调用. 任何语言开发的程序都可以嵌入Browser Control来借用IE的功能. Office暴露了VBA接口, 通过VBScript都能够自动化Office程序. 各种管理工具无论是Explorer还是MMC, 都暴露了编程接口可以让程序员添加自己的功能. 我见过客户用ASP.NET在后台用VBScript生成Excel表格, 然后把表格嵌入在 IE浏览器中, 再使用JavaScript来帮助客户编辑, 最后提交回MSSQL数据库做完成报销功能的. 完善的互操作性充分保护了用户的投资, 使得客户对微软平台用一次就上瘾, 几乎没有不可能完成的任务. 仔细分析, 其实这些互操作有一个共性, 都是把暴露COM接口作为内部实现原理. 这个做法导致了三个局限性, 首先是牵涉到了前面提到的COM的复杂度. 其次是潜在的性能损耗. 最后是在具体开发的时候, 都需要一些仪式性的工作来引入或者定义COM接口, 使得开发过程不够自然流畅. 在CLR和COM互操作的调用栈里面, CLR的RCW, CCW, 安全处理, 列集拷贝等等, 耗费的时间带来的性能开销简直是可以到了肉眼可察觉的地步(听硬盘的声音和看任务管理器里面CPU的波动).

Win8

在讨论完这些技术背后的故事后, 再看看为啥我就对Win8爱不释手了.

Win8引入了Windows Runtime, 简称WinRT. WinRT是一个操作系统模块, 运行在用户态, 介于Win32的上层和应用程序的下层, 目的在于提供更高效友好的开发接口供Win8的程序员使用. WinRT在二进制模型上基本就是照搬了经典的COM. WinRT和CLR互不依赖, WinRT可以被CLR使用. WinRT通过C/C++实现, 效率高是一个方面, 更重要的时Win8引入了projection的概念, 就是可以把WinRT的API用最直接最高效的方法, 提供给上层的编程语言调用. 这个语言可以是C#, C或者JavaScript.

对于第一次接触Projection的朋友, 可以把Projection认为是一种新的Windows API模型. 传统的操作系统API, 要么是暴露DLL的方法, 要么是通过COM接口. 无论是哪一种, 在CLR中调用的时候都有不小的开销. 使用这些传统API的效率, 比调用一个C#自己的方法, 效率差了多个数量级, 根本的原因在于CLR的安全模型, 内存模型和传统的unmanaged模型不兼容, 所以跨越边界的调用需要额外的代码来处理. 而Projection提供的模型, 是在提供新功能的同时, 还针不同编程模型和语言, 提供了最利于它们调用的方法. 这样就主动避免了不同模型之间为了互相兼容导致的开销, 也使得程序员写代码的时候非常自然流畅, 调用的时候根本感觉不到和调用本地函数的区别. 当然, 能够实现这一点, 也是得益于CLR, C#语言和VS开发工具这十年的长足发展. 举个例子, C# 5.0中引入了await关键字, WinRT中引入了async operation. Projection技术把C#中的await语句转换为WinRT async operation的调用, 而且这个调用直接从managed code直接跳到unmanaged code, 中间没有任何冗余, 也不需要CLR Engine的介入. 进一步的信息, 可以参考Build大会关于WinRT的多个演讲. 后面的callstack也提供了直观的例子.

前面提到了COM的局限性在于一个轻量的二进制模型, 被硬生生的扩展成一个无所不能的框架. WinRT取其精华, 去其糟粕, 借用了COM的轻便, 舍弃了复杂性, 在扩展性上依托于上层的编程语言和工具. WinRT通过projection的技术解决了传统互操作性效率不高使用不方便的问题. 以前的路线是希望所有的产品和技术最后都统一到CLR上来. 现在修正为底层模型通过WinRT和C来实现, 然后把这一层高效的组件无缝提供给上层的开发技术比如CLR来使用. 这个转变重新重视unmanaged层面的二进制模型. 归纳为, unmanaged模型的优势在于执行效率高, 可以通吃所有场景, 缺点在于开发和使用成本也高. CLR的优势在于开发成本低, 缺点在于无法通吃各种需求. 现在微软自己用unmanaged来做WinRT, 然后把WinRT提供给上层语言, 这两者就可以取长补短了.

有了WinRT, 有了unmanaged的回归, 再加上微软开发工具和C#语言的长足发展, 前面介绍的各种技术在Win8里面就相得益彰了. Metro是如何修复WPF的缺陷就显而易见了: Win8的metro程序继续使用WPF中引入的rendering模型和XAML, 但是在control的基础设计和实现上, 从CLR转移到了C, 然后通过WinRT来暴露给使用者. 至于使用的灵活性, 比如要不要实现数据绑定, 就看上层使用者自己的选择了.

附录

下面是我研究过程中看到的一些Win8的callstack. 基于这些callstack和我以往的经验, 才写了上面的文章.

Stack1:

Windows_UI_Immersive!`Windows::Internal::CMessageDialog::ShowAsync'::`50'::<lambda_32D66FEFF293CE6B>::<lambda_32D66FEFF293CE6B>

Windows_UI_Immersive!Windows::Internal::CMessageDialog::ShowAsync+0x1a0

image08ee0000!DomainNeutralILStubClass.IL_STUB_CLRtoCOM()+0x8c

application1!Application1.MainPage+<button_Click>d__0.MoveNext()+0xcd

application1!Application1.MainPage.button_Click(System.Object, Windows.UI.Xaml.RoutedEventArgs)+0x80

stack2:

combase!CComActivator::DoCreateInstance+0x121

combase!CoCreateInstanceEx+0x51

combase!CoCreateInstance+0x65

Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::_TryToUnregisterForIHMNotifications+0x3b

Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::_HideWindow+0x31

Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::HideWindow+0x9

Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::DestroyWindow+0x24

Windows_UI_Immersive!Windows::Internal::CPopupWindow::Destroy+0x57

Windows_UI_Immersive!Windows::Internal::CClosePopupCommandHandler::Invoke+0xe 0x73

Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::_OnButtonPress+0xc0

Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::OnMessage+0x18b

DUI70!DirectUI::NativeHWNDHost::WndProc+0x73

USER32!InternalCallWinProc+0x23

USER32!UserCallWinProcCheckWow+0x100

USER32!DispatchMessageWorker+0x3d4

USER32!DispatchMessageW+0x10

Windows_UI_Immersive!SHProcessMessagesUntilEventsEx+0xe2

Windows_UI_Immersive!Windows::Internal::PopupWindowOperation::Show+0x103

Stack3:

Windows_UI_Xaml!HWWalk::RenderChildren+0x7a

Windows_UI_Xaml!HWWalk::RenderContentAndChildren+0x2d1

Windows_UI_Xaml!HWWalk::Render+0x61e

Windows_UI_Xaml!HWWalk::RenderChildren+0x7a

Windows_UI_Xaml!HWWalk::RenderRoot+0x1c4

Windows_UI_Xaml!CCoreServices::NWDrawTree+0x698

Windows_UI_Xaml!CCoreServices::NWDraw+0x1d6

Windows_UI_Xaml!CRenderTarget::Draw+0x13

Windows_UI_Xaml!CWindowRenderTarget::Draw+0x40

Windows_UI_Xaml!CXcpBrowserHost::OnTick+0x88

Windows_UI_Xaml!CXcpDispatcher::Tick+0x184

Windows_UI_Xaml!CXcpDispatcher::OnReentrancyProtectedWindowMessage+0x133

Windows_UI_Xaml!CXcpDispatcher::ProcessMessage+0xa4

Windows_UI_Xaml!CXcpDispatcher::WindowProc+0x69

USER32!InternalCallWinProc+0x23

USER32!UserCallWinProcCheckWow+0x100

USER32!DispatchMessageWorker+0x3d4

USER32!DispatchMessageW+0x10

windows_ui!Windows::UI::Core::CDispatcher::ProcessMessage+0xc7

windows_ui!Windows::UI::Core::CDispatcher::ProcessEvents+0x6c

Windows_UI_Xaml!CJupiterWindow::RunCoreWindowMessageLoop+0x3b

Windows_UI_Xaml!CJupiterControl::RunMessageLoop+0x1d

Windows_UI_Xaml!CJupiterControlLight::RunMessageLoop+0x8

Windows_UI_Xaml!DirectUI::DXamlCore::RunMessageLoop+0x15

Windows_UI_Xaml!DirectUI::ViewProvider::Run+0x11

twinapi!Windows::ApplicationModel::Core::CoreApplicationView::ViewProviderThreadProc+0x27

This is the end

本文链接

为什么EXE不能超过4GB

2010-07-13T02:32:00Z

为什么EXE不能超过4GB

前几天看到大家在讨论EXE装载的问题，很新奇。有的说PE装载受到进程空间的限制，有的说PE一定是整体装入，有的用ZIP自解压包来举例子。

我当时大概想了一下，觉得PE不一定是要整体装入的。PE文件包含一个PE header，里面定义了各个段，比如代码，资源等等的偏移地址，装载的时候应该不会超出这个PE header的定义。也就是说，如果PE header里面定义了最远的段是10M，但是PE文件有100M的话，应该最多只有10M装载。

于是我写了一个程序来测试下。首先写一个简单的C++的helloworld。然后随便在硬盘上找了个700M左右的A片，然后执行下面的命令把这两个文件拼合起来成为一个新的EXE:

copy /B helloworld.exe /B + 常盘みちる.avi /B largepe.exe /B

然后运行这个largepe.exe, 一切正常。在debugger中加载这个largepe.exe后发现，这个module占据的内存空间和helloworld一样，并没有包avi那部分。

所以我在想，既然是这样的话，我可以把很大的数据放到exe文件后面，然后在exe的实现里面来分段读取这些数据，实现自我播放自我解压之类的。为了再次证明这一点，我用dxshow写了一个简单的播放程序，然后用同样的办法拼接了一个4G多的高清版本。运行，发现：

不能运行。说这个是invalid win32 application。

好吧，由此看来，自解压文件不超过4G的确还是有原因的。但是原因到底是什么呢，难道真的和4GB内存空间相关么？于是我换了个64位的机器，运行，发现：

不能运行。说这个是invalid win32 application。

哦，原来64位的机器也不能运行超过4GB的EXE啊，那看来和什么进程内存空间没太大关系了吧。但是原因到底是什么呢，我拿debugger跟到失败前的最后一个API，发现是ZwCreateSection，这个API调用失败并且返回STATUS_INVALID_FILE_FOR_SECTION。额，这里已经超出我的知识范围了，于是就去讨论组问专家，专家Pavel说:

"
SECTION_IMAGE_INFORMATION structure contains a ULONG ImageFileSize field. If we allow files larger than 4 GB, programs that use this structure may break, and that can potentially affect 3rd party apps because all this information is on the web, even though the structure and the APIs using it are not officially documented.

(Note that this is separate from the image size in the PE headers, which is also a ULONG and is currently limited to slightly less than 2 GB.)

--by Pavel
"

原来是这样啊~~~

PS, 附上文SECTION_IMAGE_INFORMATION的结构定义:

http://www.nirsoft.net/kernel_struct/vista/SECTION_IMAGE_INFORMATION.html

typedef struct _SECTION_IMAGE_INFORMATION
{
     PVOID TransferAddress;
     ULONG ZeroBits;
     ULONG MaximumStackSize;
     ULONG CommittedStackSize;
     ULONG SubSystemType;
     union
     {
          struct
          {
               WORD SubSystemMinorVersion;
               WORD SubSystemMajorVersion;
          };
          ULONG SubSystemVersion;
     };
     ULONG GpValue;
     WORD ImageCharacteristics;
     WORD DllCharacteristics;
     WORD Machine;
     UCHAR ImageContainsCode;
     UCHAR ImageFlags;
     ULONG ComPlusNativeReady: 1;
     ULONG ComPlusILOnly: 1;
     ULONG ImageDynamicallyRelocated: 1;
     ULONG Reserved: 5;
     ULONG LoaderFlags;
     ULONG ImageFileSize;
     ULONG CheckSum;
} SECTION_IMAGE_INFORMATION, *PSECTION_IMAGE_INFORMATION;

本文链接

其实.NET的确慢, 微软推的这一套的确不适合很多地方

2010-07-07T16:25:00Z

微软的bing/msn等web平台系统都不是用c#的, 自己好像用c/c++重新搞了一套

C#的速度也的确不能和C++什么的比

好像对C#和CLR的性能提升在很久以前还讨论过, 后来放了一个beta版本的compiler SDK出来, 就不是重点方向了

现在的重点方向是Azure

不过我觉得这没什么值得义愤填膺的, 类似的话题以前VB5/C++5.0的时候就有了, 或许还能找到当时的VB5/VC5/BC/Delphi大论战呢, 我这次就不跳出来哗众取宠了

本文链接

微软平台UI自动化(UIA)经验集

2010-05-20T12:30:00Z

根据我UIA自动化测试的经验, 总结了下面代码集. 在这个代码集中, 包含了:1. 一个WPF的窗体程序2. 一个WinForm的窗体, 这个窗体作为Model Dialog被WPF主程序打开3. 针对这个WPF和WinForm的测试代码例子4. 针对Win7 Calc.exe的测试代码例子5. 一个简单的TestEngine这个代码集的作用是:1. 演示UIA中基本的概念, 比如Automati...

今天在InfoQ看到一个google关于test的演讲, 非常精彩

2010-04-10T13:54:00Z

今天在InfoQ看到一个google关于test的演讲, 非常精彩http://www.infoq.com/cn/presentations/duannian-agile-test演讲人段念, 似乎也叫做关河, 网上的介绍在:http://www.qconbeijing.com/Speaker.aspx?Id=33个人网站在http://www.cnblogs.com/guanhe/没想到国内社区...

来来来, 我也来发发我大二时候的作品

2010-03-16T16:14:00Z

今天看到了:12年前的作品──《美绿中国象棋》制作过程及算法简介http://www.cnblogs.com/miloyip/archive/2010/03/16/1687647.html不仅想到了我大二时候的作品, 让大家比较下墙内墙外的差距, 希望大家不要见笑, 再怎么样, 我这个好歹还是开源的.第一个也是棋类游戏, 五子棋. 当时qq上都还没有五子棋, 个别网站上的支...

Windows用户态程序高效排错全文PDF

2010-02-11T06:29:00Z

今天一个朋友提醒我，说 Windows用户态程序高效排错的全文应该可以免费放出来了。我掐指一算，早过了和出版社约定的时间。下面是Windows用户态程序高效排错全文 PDF 的链接/Files/lixiong/userdbg_msinternal.pdf注意:1. 这个就是原书一样的内容。我太不负责了，里面的一些错误也没有修改。勘误请参考:http://blog.csdn.net/epar...

回顾下COM+提供的服务,就明白啥是中间层了, 我把绝招贡献给你们吧

2009-05-24T17:29:00Z

我实在看不下去了很久很久以前,我跟大家一样,觉得三层很神秘的直到有一天,我崇拜的老大,dr0,给我说了三层的秘密后, 我觉得任督二脉立刻打通三层其实说的就是中间层.前后都不用看中间层其实看com+就可以了关键在于实现可伸缩性和服务性

博客园_LiXiong's Debugging paper

Web服务的性能，和BCrypt性能问题的解决方法

md5/sha1+salt和Bcrypt

从Win8回顾微软平台的各种技术

为什么EXE不能超过4GB

其实.NET的确慢, 微软推的这一套的确不适合很多地方

微软平台UI自动化(UIA)经验集

今天在InfoQ看到一个google关于test的演讲, 非常精彩

来来来, 我也来发发我大二时候的作品

Windows用户态程序高效排错 全文PDF

回顾下COM+提供的服务,就明白啥是中间层了, 我把绝招贡献给你们吧

Windows用户态程序高效排错全文PDF