Shell's Home

CNNIC的证书

Feb 3, 2010 - 1 minute read - Comments

最近,技术圈里面在争论CNNIC的证书被加入到信任根证书里面的问题。本文章试图和专业人士探讨这一变化的过程,以及向非专业人士说明会造成的影响。所有段落前会标明针对的群体。 事情的起源,是有人发现CNNIC的证书被加入了Mozilla和系统的信任根证书链里。这引发了大家对早年CNNIC所做的流氓软件的回忆,因此大量技术人士强烈反对。所做的反应包括发起BUG讨论提请Mozilla删除CNNIC的证书,发起投票,写信给Entrust阐述问题等。下面会简述一下信任根证书链,还有CNNIC的背景和历史。 本段适合非专业人士阅读。我们在访问一个网页的时候,通常有两种常见的通讯方式。http和https。区别在于,https会使用网站证书加密通讯过程。证书加密包含了几重的意义,首先,证书保证了你们的通讯没有第三者能截获。其次,证书验证了你访问的网站,是否是他号称的那个网站。也许很多人无法理解,这两种攻击怎么可能发生。要理解一点,中国电信也不是铁板一块,你完全无法指望他们的员工也绝对安全。否则的话,为什么所有银行都使用https来加密访问过程呢? 本段适合专业人士阅读。那么,不使用证书会发生如何的攻击呢?一旦有某个人更改DNS(这东西让百度都吃了亏),以某个服务器替换了你的银行(或者gmail)。那么,你访问你的目标域名的时候,就会被定位到他的中间机器上,他再使用代理技术,通过ssl访问目标服务器。整个过程如同走代理一样,唯一的问题就是你的密码泄露了。那么证书是如何防御这个攻击的呢?如果你访问目标机器,目标机器会让你验证一份证书,标明他的域名(用于防止域名劫持的),签署者。一旦域名不符合,或者你不信任证书,就会报警。那么攻击者如何复制这个证书呢?首先他无法通过访问的方式获得证书原文,因为证书给你的其实只有公钥部分。其次他无法将这个过程也代理下来,因为如果这么做,下面的内容就全是不可解的了,那他就纯粹花钱把自己弄成代理服务器了。最后,他也无法生成,因为按照规定,只有域名的拥有者可以向特定的单位申请证书。于是,他无法复制证书,攻击就会失败。 本段适合非专业人士阅读。然而,你需要信任什么证书呢?如果你要一家一家的信任证书,会发生什么?你见到是否信任就会习惯的去点,这对安全于事无补。因此,这里引申出一个证书链的问题。通常系统内内置了一些证书,这些证书叫做信任根证书。这些证书的权限是,可以让你信任其他证书。而被他们授权的证书,则分为可以继续授权和不可以继续授权两种。一旦被他们签署授权的证书,最起码你访问的时候不会有警告了。现在,CNNIC加入了这个根证书链。那CNNIC是个什么公司呢?他自称是中国科学院下属的中国互联网络信息中心,服务于科学和研究的机构,但很多人指出CNNIC的直接主管是工信部。当年,CNNIC推出中文域名服务,这项服务需要在几乎所有人的电脑内安装插件。他为了提高安装率,使用了不可删除的保护技术。这导致很多人的电脑安装后,无法卸载程序。至于安装呢?也不全是自愿安装(我不排除自愿者,绿霸还有自愿的呢)。他们曾经利用系统漏洞,向大量电脑上强行安装插件。而且CNNIC还借助官方身份,大量推行中文域名——其实他们根本就不是政府机构,而是非营利机构。并且,在前两年拼命忽悠CN域名,最近又突然停止域名解析(虽然是国家规定的),道歉赔偿啥都没有。大家自己想,真的可以信任这种公司么? 本段适合所有人阅读。现在CNNIC已经进入了信任根证书链,如果配合国家级的DNS劫持技术,理论上可以构造一个假的mail.google.com,或者www.hotmail.com。走代理,自己给自己签署一个证书。从而获得你的完整会话。这里(http://autoproxy.org/zh-CN/node/66)有比较大的说明和讨论。 我对这个事情的观点是。作为Mozilla或者任何根证书的发行机构,在没有直接证据的情况下,不大可能拒绝一个国家级机构的要求。然而,无论任何原因,信任一个机构,就代表你要为他的行为负责。如果CNNIC做出任何危害用户安全的行为,Moziila,微软,Debian.org会被我作为同罪者考虑和抵制。同时,系统发行的根证书系统,是否要去信任,是我们每个人的问题。如果你觉得CNNIC根本不值得信任,那么你可以删除他的所有证书,以及签署了他的所有证书。目前而言,我删除了CNNIC和Entrust的所有证书。

手机又丢了

Feb 1, 2010 - 1 minute read - Comments

昨天出去玩,拉小黄出来溜冰,结果被还了一个电脑。我还要买一个键盘给别人,手上一堆东西,再打车去见人。时间紧,手上大包小包一大堆,下车的时候两手满满的。下车了再一拍兜——杯具啊~~~~手机丢了。 估计是放兜里面没放的太进去,于是联系去找。大众的调度��嗦嗦的,问你上车时间下车时间车号前后排什么的,问了一堆。我当时心就一凉。司机每天要开车的,总算还比乘客靠谱点。下一个乘客上来,那可就彻底讲不清了。要验证我的身份,大可以等东西找到再说。估计这堆罗嗦问题就是要等到说下个乘客可以上车,然后再推说可能是乘客问题,让你无话可说的。所以大家车上丢了东西,就别指望调度了。 消息回来,果然找不到,手机满电的,也关机了。于是只有紧急停机,外加修改了所有在上面涉及过的密码,包括我的QQ,MSN/Hotmail,Gtalk/Gmail,还有张老师的blog。这里普及一个常识,手机使用的时候,一定要将手机设定为和SIM卡绑定。然后在手机丢了以后,立刻停机。这样做的主要目的是防止手机诈骗,例如打给你朋友,说你车祸了在急救,这里是医院,赶紧汇钱到XX账户啥的。我的朋友一般还比较懂行,肯定会挂了拨我号码以验证是否是我本人——问题是,那还是打到他手机上啊。人家和你够铁够仗义才付钱,万一被骗了,你好意思不赔他损失么?所以,丢了一定要停机。而SIM卡绑定,对于专业人士来说不难解,而对于业余人士则不好解。如果是外行捡到,卖给玩手机的就要被宰一刀,所以最好的思路是打上面几个人的电话问问要不要把手机买回去什么的。如果手机没绑定,大多都是拿到就用了,这个选项根本不可能。至于记录IMEI号什么的——你还没那个面子让移动封掉这个手机。另外上面如果用过QQMSN什么的,也赶紧改密码。不要心存侥幸,一天也许没事,两三天万一他解锁出来了,你哭都来不及。 至于数据么,大部分都有备份,但是所有人的联系方式肯定都泄密了。大家如果看到其他人,用别人的手机,宣称我如何如何的——别信他。半年内的联系人可能需要重新添加,回头我会一一联系。 至于其他么,半年内和我发过短信的,你们的短信都曝光了。和我照过相的,你们的照片都曝光了(这可不限半年,实际上我刚买的时候照的都还在)。其他数据应该没什么风险了,以上。 以下不算钱: 啊~~~~我的手机啊,又要买新的了,怨念。

一个远程下载verycd的小技巧

Jan 29, 2010 - 1 minute read - Comments

贝壳家里开了emule,天天下载,问题是又不能每次都是晚上添加资源。 怎么办呢?不知道大家知道不知道,emule是可以网络管理的,端口是4711。不过不是https,密码容易泄露。而且贝壳已经有一个nginx服务器了,也懒的再做端口映射,换端口。于是,在nginx中做如下设定。(当然,贝壳是放在https段中的) location ^~ /emule/ { rewrite ^/emule/(.*)$ /$1 break; proxy_pass <http://hostip:4711>; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } 然后,用https://dynname/emule/就可以访问你家里的emule了,记得密码设强点。 接下来,verycd里面曾经有复制所有连接的选项,现在没了。面对几个链接,也就手工复制一下,面对上百个连接,贝壳就无语了。贝壳试验过几个插件,都无法正确识别ed2k的链接获取。那怎么办呢?这时就要请出我们伟大的Linux。 需要准备的工具是lynx,请预先装好,然后如下操作。(范例是个动画^_^) wget -c <http://www.verycd.com/topics/2779234/> lynx -dump -listonly index.html | grep "ed2k://" | sed "s/.*ed2k/ed2k/g" | grep -v BIG5 > out.txt wc -l out.txt lynx的-dump选项是将某个网页全部渲染成文本进行展示,这是html2text的好方法,效果还不错哦,不过中文支持好像不是很好。而-listonly则是展示出页面上的所有链接,这就拿到了我们需要的原始数据。 然后,我们取其中的ed2k行,忽略其他链接,再通过sed转换,去除头部的编号和空格,这样就可以得到所有的ed2k链接。 我在下面是用-v BIG5的参数,忽略了其中繁体中文的资源,然后输出到一个文件中。数数行数,52行,大致和文件个数相当(其中好像有两个v2)。那就是可用资源了,复制到emule的控制页面中——出错? 这是因为emule的控制页面使用GET方式传递参数,因此有长度限制。你需要将链接10个一批往里面复制——有个几次就OK了。当然,如果还是多,贝壳回头会写一篇文章,介绍如何使用curl自动干这事情——这还不算太难。 这就是为啥贝壳喜欢Linux的原因了。相比Windows下的两个解决方案,找插件太费劲,自己写程序更费劲。Linux使用现有工具的组合可以轻松完成这一任务。

关于减少使用gmail的建议

Jan 19, 2010 - 1 minute read - Comments

这次,google又不走了。 事情处于很奇怪的状态,google本是不可能留下的。既然它留下了,我们说,事有反常必为妖。这次妖在哪里呢? 我建议大家减少使用gmail,最好别用。原因如下: 如果google的却是受到了某些关于知识产权的攻击,但是却愿意在中国留下,并且在发生这次的事件后,还能留下。这说明google(非中国的谷歌公司)已经和北京达成了某种秘密的和解协议。无论这个协议的细节是什么,我们有理由猜测,google的产品不能完全的信任了,包括gmail,google reader,bloger等。 另一方面,如果google并没有受到这些攻击,那就是出于各种原因的新闻炒作。既然google背弃不作恶的宣言在前,那杯葛在后也是自然而然咯? 所以说,如果google打算继续在中国留下,那么包括gmail在内的各种google产品,都必须视为非安全产品看待。建议尽量减少使用,并准备替代方案。

关于海地地震

Jan 18, 2010 - 1 minute read - Comments

深切同情这种虚伪的话就不说了,我们又没被震过,装B只会遭雷劈。 我得说,海地人民,海地政府还是比较公平的。学校倒了,总统府也倒了,这两天净看到倒塌的总统府了。在神奇的土地上,只听说学校倒塌压死人,还没听说政府机关房子倒塌压死人的情况——那到真是造福全社会了。

关于google退出中国的FAQ

Jan 14, 2010 - 1 minute read - Comments

F:google真的准备退出中国了么? Q:历史告诉我们,两个人谈价的时候,如果出现有人生气要走,那可能是讲价的手段。如果出现扇耳光,那么多数是谈崩了。除非被扇的人授意这么做,否则双方都没有回头路可走。目前google等于明确的在指责中国进行网络监控,并试图进行网络攻击。耳光都扇出去了,下面就不是谈价的问题了。 F:中国政府会怎样处理google的谈判呢? Q:这也是个挺头痛的问题,要是让google就这么走了,无异于变相承认了中国的网络舆论监控和网络安全问题。但是要答应无控制的搜索,那是绝对不可能 的。可能会派出发炎人,声明,中国要求google进行网络控制的理由是为了防止网络色情和网络暴力,这是我国内政,其他国家无权干涉。目前没有证据表明 入侵google的黑客得到中国政府的授意,任何试图联系两者的人都是邪恶和别有企图的。中国是一个开放的市场,任何人进入和离开是个人自己的选择,中国 依旧欢迎其他公司来中国建厂投资。 F:google退出中国真的是因为不作恶么?还是为求一个体面的退出? Q:别太把自己当回事了。google在中国的利润有多少?不超过总利润的10%。投资有多少?鬼知道。市场份额多少?33%。我们不看其他,就算中国市场全争取过来,最高也只能将利润增加到25%((10*3)/(100+10*2))。也就是说,中国最多是一块肉丝,而美国是块肥肉。如果肉丝真的有臭掉的风险,宁可丢块肉丝,也别丢肥肉。 而且,一旦明确指责网络舆论控制和网络安全问题,那么,同样进入中国的其他大型厂商就会陷入被动,包括微软,雅虎等。撤吧,他们的市场份额更大,问题也更复杂。不撤吧,他们在美国的形象会受到影响,有利于google在其他地区的业务。 F:google走了,百度得益了? Q:短期来看,没错,长期来看,市场会重新平衡。由于百度在谈判上的强势地位,因此会导致代理商和广告主非常难做,同时互联网广告的成本会增加。进而加剧劣币驱逐良币,最后让整个互联网的所有广告都变成近乎于废纸,互联网广告业务名存实亡。 而且,一旦google离开,百度就会直面政府。从政府需要”团结和依靠”的多数,变成需要”警惕”的”怀有异心”的人。可以预见,政府对百度的监控和利用会达到一个新的高峰(因为用不着让你活着对付google了),并且可能会提出注资成为某部下属机构的要求。 F:google走了,我们将会怎样? Q:google的离开,标志着中国的互联网整体倒退了6年。在IT界,3年是一个时代,6年的倒退,让我们退回了两个时代去,变成了上个世纪网络刚刚兴起的时候,那种上网艰难的状况。这不是用备份邮箱,备份新闻标签等方法可以解决的。 更严重的是,这会严重打击整个业界,工程师,对于中国的网络发展的评价。在这个问题解决前,我们可能落后其他国家10年以上。当然,之所以我这么担忧,其实还是因为这直接影响到了我的饭碗。

手工删除oracle数据库实例的全部文件

Jan 11, 2010 - 1 minute read - Comments

今天公司搬家,没啥好写的,简单记录一下前两天删除重建oracle数据库的过程吧。 首先,我重建的是oracle数据库,而不是oracle数据库程序。这几天不知道怎么回事,整个数据库的redo log出问题了,我又懒得去找。加上这个数据库做演示的时候乱糟糟的配置做了一堆,也记不请了,干脆重建。 重建的第一步,需要找到所有程序实例的位置,这个可以看/etc/oraInv什么的一个文件,这里会指向一个目录。这个目录是标准的,里面有各种格式的oracle程序实例的位置。然后,一个程序实例可以运行多个数据库实例,因此,要找出这些数据库实例的配置文件。这个就需要对oracle的数据库基本结构有所了解,这里不赘述oracle数据库的各种基本概念。 oracle的数据库配置文件在一个很怪的位置,/etc/oratab里面。其中有SID到spfile路径的对应关系,通常而言,这个路径位于$ORACLE_HOME/dbs/init$ORACLE_SID。我们首先不要删除这个对应关系和文件,因为启动中其他文件需要通过这个找到。我们首先通过spfile建立pfile,来读取其中的参数。 $ export SID=orcl $ sqlplus / as sysdba > create pfile from spfile > exit OK,这样我们就建立了pfile,现在可以删除$ORACLE_HOME/dbs目录下所有的SID相关的文件,并且删除oratab中的对应关系。完成这步后,数据库就无法启动,也不存在了。但是我们还需要回首数据库相关的文件,主要是收回空间,同时也免除后患。 首先,数据库有三个control files,还有一个到多个data files,以及多个redo log。在默认设置中,这些文件一般放在一起,你可以通过查看pfile确认这些文件的路径。找到之后,直接删除,没啥好多说的。在完成数据基础文件的删除后,我们还需要删除flash_recovery文件,这个也可以通过pfile确认,位置一般在data文件上两级(就是通常$ORACLE_BASE的位置)下面,flash什么的一个目录,很好找。 最后,我们删除admin目录,具体是在$ORACLE_BASE下面的admin下面,以SID命名的,可以通过pfile确认。至此,oracle数据库的删除完成。不过呢——呵呵——让大家失望的是,其实DBCA也可以完成一样的工作… 不过,dbca的工作必须通过vnc,绝对不要通过ssh + xming,因为那个会让最后一步执行前的确认无法被确认,导致不能执行。实在是很让人郁闷的一个bug,切记切记。

replay

Dec 23, 2009 - 1 minute read - Comments

发现最近的生活,越来越重复了。怎么说呢?每天早上起来,照例刷牙洗脸,吃饭出门。走在南泉路上,会看到一辆119。拐到兰村路上,会看到一个黑衣MM,对面走过来。人很漂亮,一般是在打手机,否则就是拿手机听歌。前走一点,有个保安在和卖煎饼的聊天,一个抽烟一个翻煎饼,每天的差异差不多就是有客户和没客户而已。再往前,在东方路前会碰到一个辫子MM走出来,辫子很长,从后面看很漂亮。不过记住,如果你不想对世界失去信心,一定要走在她后面。走在前面千万不要回头,无论是有人喊你还是后面有车要70码你。我头次很好奇的回了个头,结果一天都无法正常工作。走到东方路,有八成概率是一堆人在等红灯。恭喜,这代表你会在20秒内碰到绿灯――平均值通常是5秒。 上地铁后就更规律了,如果一堆人在等车,那车上肯定也是一堆人,你如果被挤上去就算是走运了。相反,如果只有小猫两三只,那么车上多半也没有人,慢慢走上去就好。到了世纪大道换车,就可以开电脑放音乐,头一首歌照例是《钢之炼金术士2009》的片头。到了张江,有车停左边和车停右边两个选项。不过没有关系,凡是在进站前停车的,就是左边,否则是右边。因为车要靠右开,停靠右边站台的车在开出时,换到左边(相对他是右边),而我们的车在进站时要靠左,也需要换边。不停车怕又碰到昨天一号线的事故,因此惯例是要停车的。 地铁下来后,有两个红绿灯,第一个灯是20秒横走40秒直行,因此多数会直行过去。第二个灯是50秒横走20秒直行,因此多数会横向过街。联合以上数据计算概率,两次直行的概率是19%,先直行后过街的概率是47.6%,先横后直行的概率是33.3%。没有觉得什么不对?看来又多一个走傻掉的。计算以上概率的方法是分支法,联合概率乘法?我没事先过个街,第二个路口走回来?那不真傻了? 最后,到办公室。一般这时候是王菲在唱《只有我自己》。如果刚唱到”走过千山万水”,那说明地铁走的还是挺快的。如果已经到了”失去你,就失去,面对孤独的勇气”,那――要么是地铁走的慢了,要么是你走的慢了。

论BTchina的倒掉

Dec 8, 2009 - 1 minute read - Comments

BTchina倒了,死的很惨。被广电总局直接勒令关闭,连整改的机会都没有。无疑,大家都知道,VeryCD会紧随其后。无论是非如何,请允许我先向这两家陪伴我多年的网站道声感谢,一路走好。 就打击这个问题来说,我无疑是赞成的。广电总局打击集中向两个关键词,盗版和非法。无论哪个,都是应该打击的对象。但是这次打击本身却值得怀疑,主要集中在三点,是否允许整改,选择性执法,还有实际效果。 首先,拿整改问题来说。BTchina和VeryCD做的是下载业务,其中有盗版下载再正常不过。一般打击都是先责令整改,然后再关服务器——虽然我们知道责令也不见什么效果,BTchina肯定改不过来的。不过样子还得做啊。不过从某种意义上说,样子做不做也就是政府内部的事情。无论做不做都是合理合法的,所以这点问题还不大。 其次,我质疑比较大的一点,就是选择性执法。有个朋友说的比较精辟,每只猫都有他的目的。我总是不惮以最大的恶意来揣测咱们的政府——他们这回想干啥?如果要打击盗版,那问题严重了去了。中国桌面上,十有八九都是盗版Windows。哪怕你买了个笔记本,上面带了个正版Vista,一般也非要装个番茄花园不可。中国人看的电影,听的歌,乃至于用的手机,都是盗版产品。所以从这个角度说,我到真的很愿意国家打击盗版。盗版没了我们的软件才更好卖,盗版没了才有人被逼用Linux,盗版没了我们这行才能赚钱。不过咱得看事实,不能听风就是雨,更不能YY。广电总局要真有决心打击盗版,首先应该奔着卖盗版盘和卖盗版书的去——虽然他们也被互联网下载整的生不如死。问题是,他们没有。 那,会不会是打击非法音像呢?这话说的更搞笑了。BTchina和VeryCD上有没有色情我不敢说,不过要有也绝对少于新华网。这不是指责新华网有多色情,而是阐述两者身为不同主体的无奈事实。BTchina和VeryCD要是碰到色情门那是沾上就死抡上就亡。作为半国企的新华网,就算偶尔行为出格,只要不出大差错无非就是检讨一下而已。这种情况下,前两家的审查力度,和后一家怎么可能同日而语?实话说,我当初还非常努力的试图在VeryCD上找什么色情资料。只能说他们的版主比较尽责,连疑似的都没有。要打击非法音像,还得找小网站——就是那种准备烧一把就走的。除非碰上严打,否则等查处来的时候,人都没了。 那我就得怀疑了,广电总局想干啥呢?说打击盗版,不像,说打击非法音像,也不像。这事情我怎么看怎么觉得像上海政府查处黑车,黑车不黑车不重要,重要的是规范正当市场——说白了就是交钱。百度百科也涉嫌抄袭Wikipedia啊,怎么没看广电局找他们麻烦呢?人家3000万春晚赞助可不是白交的。 那这事靠不靠谱呢?我只能说,越来越不靠谱了。从本心来说,我希望打击盗版,但是从现实而言,无论是美国政府,欧洲诸国政府,还是中国政府,对打击盗版都没啥办法。前两者有海盗党——当然,他们也被人盗版了他们的logo,真是讽刺。后者则有1亿多网民,每天发明各种奇怪的办法。现在的网民水准是越来越高了,或者说软件是越来越傻瓜了。原来下载必须在中心节点上投入大量资金,而且政府一来就玩完了。后来则是中心节点上只要搭个论坛,剩下的自然有P2P软件搞定。现在,根本就没中心节点。DHT的普及,使得去中心化的优势体现的淋漓尽致。Emule里面可以用kad搜索,直接搜索你需要的资源——正常情况下不比VeryCD差。而torrent里面则有个种子市场,可以直接搜索你要的种子。 好家伙,连服务器都不要了,这次广电局再要下手,只有从网络传输上下手了——中国为了解决轮子问题,为GFW投资了不少钱。不知道广电局是否能收到足够的钱,把这个系统扩大个几倍,把P2P的混淆协议也全概括进去。作为一个老程序员,我劝诫所有的下载者一点。下次再弄的时候,用emule的kad搜索来找你需要的资源,你会发现其实verycd也不是必须的——虽然对他们来说,这是个比广电局查处更不利的消息。

用python实现webserver(二)――Thread

Dec 7, 2009 - 3 minute read - Comments

我们上面说过,Prefork模式有着先天的缺陷。针对http这种大量短请求的应用(当然,http1.1以来,有不少客户端使用了长连接),Prefork的最高并发很让人不满。并且,无论是否高并发,Prefork的性能都非常不好。现在我们介绍一下Thread模式。 和Prefork非常类似,每Thread模式通过新建的线程来控制对象的传输。和Prefork模式不同的是,一个用户能够建立多少个线程并没有限制。在系统上似乎有限制,65535个,但是同样,文件句柄最高也就能打开65535个,因此通常而言一个服务器最高也就能顶50000并发,无法再高了(nginx就能够支撑5W并发,再高要使用一些特殊手法来均衡负载)。而且线程的建立和销毁的开销非常小——没有独立的空间,不用复制句柄,只要复制一份栈和上下文对象就可以。但是,由于所有线程运行在同一个进程空间中,因此每线程模式有几个非常麻烦的瓶颈。 首先是对象锁定和同步,在每进程模式中,由于进程空间独立,因此一个对象被两个进程使用的时候,他们使用了两个完全不同的对象。而线程模式下,他们访问的是同一个对象。如果两个线程需要进行排他性访问,就必须使用锁,或者其他线程同步工具来进行线程同步。其次,由于使用同一个进程空间,因此一旦有一个连接处理的时候发生错误,整个程序就会崩溃。对于这一问题,可以通过watchdog方式来进行部分规避。原理是通过一个父进程启动子进程,子进程使用每线程处理请求。如果子进程崩溃,父进程的wait就会返回结果。此时父进程重启子进程。使用了watchdog后,服务不会中断,但是程序崩溃时正在处理的连接会全部丢失。最后,是python特有的问题——GIL。由于GIL的存在,因此无论多少线程,实际上只有一个线程可以处理请求,这无形中降低了效率。下面我们看一下Thread模式的测试结果: 测试指令: ab -n 1000 -c 100 http://localhost:8000/py-web-server 返回结果: Document Path: /py-web-server Document Length: 1682 bytes Concurrency Level: 100 Time taken for tests: 3.834 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 1723000 bytes HTML transferred: 1682000 bytes Requests per second: 260.85 [#/sec] (mean) Time per request: 383.362 [ms] (mean) Time per request: 3.834 [ms] (mean, across all concurrent requests) Transfer rate: 438.91 [Kbytes/sec]