Shell's Home

你认识这人多少?

Apr 23, 2012 - 1 minute read - Comments

别误会,这篇是讲个人信息在网络上传播和留存相关话题的。但是不得不说,有点拷问人生的味道。 你究竟认识一个人多少呢?知道名字算认识么?知道性别,年龄,长相,工作单位,算认识么? 这么说吧,如果一个人留了足够多的信息在网络上,你就能找到他/她么? 本周末我就做了这个有趣的研究,事情从欢乐开始,结束于惆怅。 我自己认识我自己吧 当然,如果不认识自己,您需要做的事情是逆运真气修炼九阴真经,而不是在这里看博客。既然您能够正常阅读博客,我假定您对自己的了解超过对其他任何一个人,同时您也是所有人中最了解自己的。 在这个假定下,贝壳搜索了自己的真名。结果是——第一个?没办法,用真名给网易写过一篇东西,就像在身上绑了一根定位锚一样,看起来很长时间内褪不下去了。Google上大部分都是那篇文章的转载,而baidu上还命中了我的开心首页。好吧,鉴于名人效应,我忽略这篇文章所有有关的内容继续研究。 第二个实验是使用自己的网名,分别搜索baidu和google。结果两者都是全部命中,没有一篇是错误的。可见shell909090是一个罕见关键字,如果你只知道我的英文名shell就糟了,全是某个能源公司和自然生物,翻到10多页都看不到我呢。 第三个实验是联合限定,使用自己的真名加上描述关键词,我首先选用了“程序”。结果是google在第三页找到了两个命中,都是python相关的内容。而baidu翻了三页什么都没有。。。 第四个实验是联合限定,关键词用大学名。结果是baidu三页内什么都没有,google给出了我的一篇论文,还有一篇通知,是我在吉他社当副社长的时候的。如果你知道我弹过吉他,应该能发现那是有关我的信息。 结论: 仅仅搜索我本人而言,baidu只有一次比google强——他上面有开心的信息。后面两次google都给出了比baidu更加准确的关于我的信息。 如果没有网易的这篇文章,很多人不一定找的到我自己。你需要知道我的网名,或者知道我的职业,或者知道就读大学和兴趣。 个人身上的特征比想象的更少,尤其在网络上。我总不能联合我的身高体重吧,长相也没什么用处。一般只有职业,大学,公司这种特征才能有效筛选信息。 你对某人的了解在搜信息的时候多半用不到,在筛选哪条是的时候才用的上。 有没有什么别人肯定搜不到的 贝壳其实有一篇IEEE论文,是合作作者。师兄的论文,贝壳提供仿真计算代码,师兄客气,给挂了个名字。这篇论文里,署名是Zhi-Xiang Xu。我自己都是IEEE发通知才知道,别人搜的到才有鬼! 筛我妹看看 为什么搜我妹?我基本把人在网络上的信息的多少和类型分为五类。第一类是老太太型,例如我外婆。什么都没有,也不用网络,你搜的到才是怪事。第二类是潜水员型,使用网络,但是不会在网络上使用自己的真名。偶尔帐号丢了就丢了,再申请一个,记得多少朋友就加多少。第三类是网络活跃型,网络上信息很多,但是基本都是网名为基础的,真名信息找不到。第四型是真实人物型,真名信息很多,但是网络上的活动类比一/二型。最后是全面活跃型,主要是网络名人,真名网名都是一堆信息。 我妹妹是潜水员的典型代表。我跳过整个过程,简述一下结果:满地都是某个书记的言论,无论我用什么关键字搜,基本都找不到相关信息。唯一的命中就是大学里面的考试名单,一个xls文件被公开在了网上。 结论: 要完全屏蔽信息不是你说了算的,很多时候依赖于学校老师/管理员/公司HR有没有错误的把信息贴出去,尤其是word文档。这是大部分人最容易中枪的地方。 当你的名字或者关键字和某个热关键字重合的时候,你的信息就像被遮盖起来一样,很难从大量垃圾中筛出。 baidu基本找不到word文档,估计是没这个能力。 老婆 本人名字和著名音乐家重合,所以死活找不到。联合大学找不到,联合单位后找到了一篇关于考试的xls文档,确实是她的。 换网名,我擦,满屏的命中,基本没几个错的,很多我都不知道。。。所以,我慢慢去看了。 里面还有她的班号,顺着还检索出了她的奖学金。各种信息满坑满谷。网络活跃型典型。 小学同学 很罕见的名字,输入后直接筛出两篇内容,google和baidu都是同时给出。一篇是该同学写给哈尔滨日报的吐槽,2005年的事情。另一篇是该同学上班后发的文,被收录了。后者有她所属部门的名字,交叉检索后能够多看到一篇文档。影响力不大,估计是内部发行。还有一次去台湾出席会议的经历。资料不是太多,典型的真实人物型啊。 以前有过暧昧的女孩子1 恩,别告诉某喵,大家懂。 跳过过程,上结果:不行,只有她考试的名单。典型的潜水员。 某个朋友 出乎贝壳的意料,直接输入姓名后,直接命中开心首页。google还命中了一场官司。从公开的文档中给出的家庭地址来看,确实就是她本人打的官司。这个算是信息的被动泄露,本人还是网络活跃型的吧。 以前曾经喜欢过的女孩子 曾经听说过此人进了中国一家很有名的网络公司当经理,一搜,果然有。不但有文字材料,还有该公司公关帐号放出的活动照片。近几年基本没怎么大变化,和当初看起来差不多。资料上发的文章,职位变迁一点不少,甚至还有一些帐号。但是没有QQ/开心之类的信息。也就是说,属于真实人物型。 好吧,看起来不错就好。这么多年,同学之间也只能说看你看起来不错就好。也许再过一段时间,标准会进一步降低为活着就好。 以前有过暧昧的女孩子2 此人信息非常奇怪。首先是真名什么资料都找不到,那么就是二/三型的。我有她的hotmail,搜索之后找到了一个论坛,上面的资料非常全,而且还找到了一个QQ号。交叉检索QQ号,发现是她当时男朋友的。在德国华人社区有发言,和她说男朋友去德国留学相一致。再检索她的网名,有大量资料。但是奇怪的是,都在某个时间点以前。具体来说,大概是2008年5月前后。之后的信息就完全消失。而她男友的帐号直到今年(2012年)一月还在活跃。结合上述来说,我有种非常不好的预感。更炸头皮的是,我检索了自己和她联系的历史记录。在同一个时间点后,我发送的所有信息都没有回应。包括msn上线状态/聊天记录,手机拜年短信等。。。 结论: 此人改名搬家,去了德国。配合她男友的记录来看,这种情况不无可能。 此人曾说过,如果要躲某人,就会彻底和自己以前的生活告别,在陌生的城市里过陌生的生活,即使见到也不会相认。我相信她是做的到这点的人。 此人已死。 好吧,按照最低标准,活着就好。 总结论 现实中大部分人都是一/二型,在网络上什么信息都找不到。之所以没有在贝壳这里体现,是因为贝壳做不到纯随机取样的条件。数据源本身是贝壳自己认识的人,大部分都是受到良好教育,能够熟练使用网络的青年。有不少甚至从事相关行业。用这些人做样本,你可以认为不存在不上网的人。 真的信息上网的人中,大部分都是网络活跃型,即使用网名会命中非常多的信息。上述例子的分析中,贝壳本人/小学同学/之前曾经喜欢过的女孩子在网络上主动留存了本名相关的资料,大约三分之一。但是上面说了,这些例子本身就是网络上留存数据的人的例子。可以粗略的得到结论,大约三分之一上网的人在网络上有真实的个人信息。 根据上条,在网上要找人,用网名比较有效。如果要被人找到,网名不要换比较有效。如果不要被找到,什么真实信息都不留,然后每隔一段时间换个帐号。 但是一半以上都会被动泄露资料(尤其是xls文件),这说明网络对个人隐私的保护非常差。除去一个公示的例子是必须公开的,其余都是莫名其妙就出现在网上的。即使只通过这些资料还原,大约有三分之一人的基本信息也会被掌握。这本来是没必要的。

语义的精密表达

Apr 19, 2012 - 1 minute read - Comments

辨析语言的微妙差异,使得语言精密的符合目的语义,此为程序员基本功的最高要求。对精密语义的追求,应当凌驾于排版美观,代码美感,代码简化之上,也凌驾于运行时效率之上。除非为特定目的小幅的修正,否则不应破坏此原则。 以此为指导,我们看几个if。 if a in python 以下代码的目标语义是,如果a不为None,就运行代码。 if a: do something 有什么问题? 有没有考虑a=0的情况?a=[]呢? if a is not None: do something 这样才是严密表达。 if a in C 以下代码的目标语义是,a是一个int数,对a!=0的情况下,执行代码。 if (a) do something 有什么问题? 没问题,因为C是静态语言,这限定了a的使用。除了代码并没有体现a!=0的条件,没有太大问题。但是鉴于语言表达语义,最好改为以下代码。 if (a != 0) 相对的,如果a是bool型,就可以直接用了。 if (a) 如果a是char*形,那么合适的语义表达应当是。 if (a != NULL) 他们生成的汇编代码都没有差异。 if a in C++ 概念上同C,不过a是一个复杂对象。 if (a) do something 有什么问题? 问题大了去了,和python一样,C++可以重载行为。谁知道type(a)::opreator bool(const type(a) &a)函数被定义为什么鬼逻辑。这就是为什么我憎恨默认行为重载的原因——因为他们对精密语义表达有破坏作用。

值返回和指针返回简说

Apr 18, 2012 - 1 minute read - Comments

好吧,这是常识,我说快点。 C * c = get_c(); 这是指针返回。 C c = get_c(): 这是值返回。 指针返回的缺点是,你必须检测返回指针的有效性,也就是NULL。并且,你需要手工管理指针释放。而优点则是避免了值拷贝,还有可以返回空值,即通过返回NULL表示没有值的情况。 而引用返回最大的优势在于,变量的生存周期和作用域相同,你无需管理释放问题。然而缺陷就是庞大的拷贝开销。 在get_c返回的时候,会return一个对象。这个对象是子函数作用域对象(sub function scope),会随着子函数退出而失效。因此,在返回值的时候会引发拷贝。这种拷贝有两种可能。 拷贝构造 当返回值被用于某个对象的声明时,会触发拷贝构造函数。被返回的对象会作为拷贝构造参数传递(引用传递),而拷贝出的对象就是被生成对象。 赋值算子 即operator =。当对某个已经声明对象进行赋值时,会发生这种现象。 当然,近代编译器对于“在返回时进行构造用于返回后的构造”这种情况做了优化,通称RVO优化。例如上文,如果get_c中使用return C(a, b);进行返回,实际上只有C::C(a, b)的调用,而没有C::C(const C & c)的调用。

vps上应当装什么

Apr 17, 2012 - 1 minute read - Comments

假定你有一台debian vps,上面需要装一些东西来——你懂。你应该装一些什么呢? 基础部分 ssh 没啥好多说,没有ssh,你甚至无法管理机器。不过注意,安全的ssh方式应当只允许使用key登录,禁止一切密码登录。而且对于没必要登录的某些用户,需要在/etc/passwd中将shell改为/bin/false。至于端口改不改,这个不重要,看你心情。 vim debian默认装的是vim-tiny,很不好用。建议改为vim,改配置的时候让自己舒服点。 安全部分 iptables-persistent 这是debian内用于iptables规则持久化的工具,你可以编辑/etc/iptables/rules.v4来修改防火墙规则。注意,目前debian stable(squeeze)中的版本还没有4/6区分,你可以弄一个testing(wheezy)中的来装。 一般来说,你的规则中至少要包含以下内容: -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i tun+ -j ACCEPT -A INPUT -i ppp+ -j ACCEPT -A INPUT -p tcp -m multiport --dport 22,xxx,xxx,xxx -j ACCEPT -A INPUT -p udp -m multiport --dport xxx,xxx,xxx -j ACCEPT 而且强烈建议,先保存一个没问题的iptables,然后直接修改iptables,再保存。这样的好处是,当你脑残改错了导致你自己都无法管理的时候,只要重启就可以恢复vps工作,而不用更麻烦的动作。 denyhosts 这是ssh的连接防御进程,用python编写。如果有人试图尝试你的ssh密码,这个程序就会踢掉他的ip。 如果你已经用了我说的,通过key的连接方式,你可以一次就直接踢掉对方ip。 管理部分 ifstat ifstat是用于网络流量管理的工具,可以告诉你网络目标的流量是多少。 dnsutils dnsutils里面包含了不少用于管理dns的工具,包括我们常用的nslookup,还有相对少用的dig。 mtr-tiny mtr是一个traceroute工具,比后者好用很多。这个工具可以快速跟踪路由。

mirrors.geekbone.org软件仓库镜像站将于4月中旬下线

Apr 13, 2012 - 1 minute read - Comments

原文在此我用了5年多的cn99和geekbone两大镜像终于全部下线。 需要通告的一点关键问题即是, 由于tux下线早于新一个版本的debian发行, 因此目前mirrors.geekbone.org还是已经发行的debian安装盘的官方源之一. 请大家在安装debian6的时候不要再选择geekbone, 并请通告其他debian用户. 在09年加入shlug之初,就知道当年用了很久的geekbone服务器是shlug管理维护的。当时就很惊讶,以捐助方式运作一台镜像服务器,这个是相当不容易的。包括募集,管理,账目,在中国要做整套过程需要相当心力。而且geekbone还是在debian有注册的镜像站之一。可以看Debian 全球鏡像站。 大约在11年,中科大的ustc服务器上线后。在一次和lightning的闲聊中,lightning就谈到了tux服务器的问题。当时tux的服务器硬盘已经不足,最多在数月后就会满额。lightning删除了部分上面的无用数据,让服务器可以稍稍多工作一些时日。我当时就建议不要全面镜像所有的debian镜像,毕竟当时中国已经有anheng和ustc两个全面源,其中ustc还在申请大陆一级源(他们的资源投入确实不错,镜像速度相当快)。tux毕竟是老服务器,可以转做i386和amd64两个主要镜像。国内大部分人用的都是这两个arch,sohu的部分镜像也是针对这部分的。lightning表示看看再说。 今天,看到了shlug通告,tux服务器准备下线。想想也的却是,tux已经在超期服役,而国内已经有了ustc, anheng, sohu, bjtu四个镜像. 再进行一次募捐让tux恢复服役看来是没什么必要了. 在此, 感谢一下shlug服务器维护团队, 谢谢你们的努力让我五年来得以享用快速的源服务. 祝tux一路走好, 愿电脑诸神与它同在, enter. 另外, 提一点我们和欧美的工业水准差距. 我曾经撰文说过, 中国要追赶美国还有很长的路要走. 当时列举的证据就是dd和debian mirror lists. 当时我们也是4个源, 目前加入了bjtu, tux退出, 还是4个源. 相比美国那个深不见底, 鼠标滚轮滚好几下都没看到头的列表, 实在是太差距了. 这个差距不仅体现在源少, 更体现在用户少. 用户少就是源少的原因. 如果用户增长一个数量级, 目前这些源肯定会发生不足, 然后吵着让各个大学再开一两个镜像出来. 我倒是觉得这样不错, 至少sjtu有机会露个脸. 其实sjtu也是有自己的源的](http://ftp.sjtu.edu.cn/debian/)%E7%9A%84), 只是没有对普通网络用户开放, 访问速度缓慢而已.

segment的核心数据结构空间和时间效率估量

Apr 12, 2012 - 1 minute read - Comments

首先我们简述核心词典的目标。词典最主要的目标是,给定一句句子S,匹配出所有和句子开始拥有完整匹配的词语。所谓完整匹配,就是句子开始的一定长度的连续序列和词语相等。例如,中华,中华人民,中华人民共和国,都是句子:中华人民共和国今天成立了,的完整匹配。 要解决这个问题,直观方式是使用tied tree。但是中文的tied tree非常不好实现。英文的tied tree在一个节点上最多拥有不超过26个子节点,而中文的在根上面会拥有6000个以上的子节点,使用同样的结构在子节点上会浪费大量内存。 我们先跳过tied树本身的细节,来讨论如何使用python内置数据结构高效简洁的完成这一工作。作为一个读比写高频很多的结构,无疑hash table是一个非常适合的结构。我在hash table的性能分析中说过,hash table的查询性能是O(1)量级的。无疑,可以使用hash tree来高速完成查找。同时注意一点,词语的最小长度是2,因此不存在只有一级的结构。所以,hash tree的第一级结构可以从2开始,而不是1。 实现效果如何?我们正式给出的词典拥有127K的词汇量,平均第二级宽度为6.8,因此大致可以推算出,第一级的词典含有元素19K个左右。python源码解析中说过,当表项小于50000个时,扩张大小为当前活跃表项的4倍,最高填充率不超过2/3,即填充率最低25%,最高66%。平均来说,填充率应当在45%上下波动,我们以0.5计算,实际上一级词典的Entry个数应当是40K个上下。在源码Include/dictobject.h:50有给出Entry的结构,这应当是三个平台相关的数据结构,以贝壳的64位系统而言,长度应当是24字节。忽略掉辅助结构,一级词典的大小应当是960K,即约1M。而词典指向的数据,即2字长的str对象本身头部长度24字节,辅助数据长度12字节,数据长度4字节(utf-16编码的两个unicode),null term1字节,共计41字节。由于python对象是8字节对齐,因此实际占用48字节。19K个数据总计占用912K。 二级表项平均长度6.8,这个长度很难估量。因为5的话总表项刚好是8,而6就会增长到24,我们取中间数20做一个估量值(因为6.8毕竟大大偏离了5),一个词典的大小应当是480字节,加上头部大约是512字节(算的粗糙点吧),19K个词典就是8.5M左右。指向的对象长度更加难估量,我们粗糙点按照96字节一个对象(别忘记了,unicode对象不但成员多,而且超出了BOM,一个字占4字节),127K个对象大约是12M内存。而float内部使用C的double类型,一个对象占据32字节,127K个对象占据4M内存。 以上总计,初级词典本身占用1M,关键字占1M。二级索引占据10M,关键字占12M,频率数据占4M。总计28M内存,基本上一个12.7W词的词典,大小2.5M,占据30M内存,这就是dict核心词典的空间效率估量。 时间复杂度估量更加复杂,不过我们可以简化来说。初级索引需要多少时间?O(1)量级,毋庸置疑。问题是二级词典的复杂度,异常难算。凑合一下,按照比较6.8次计算(因为必须通过遍历才能知道全部的匹配)索引出一个句子所有的完整匹配的时间复杂度O应当为O(n),其中n是平均二级索引宽度。目前而言,实际测量结果,平均6.8。当词汇量大于一定值后,随着词典的加大,这个值基本是线性增加的,我们粗略的可以认为O(n)即是正比于词典大小。 而后我们顺便给出分词核心算法在处理一句话时的效率估量吧,证明太长,这里写不下。假定句子长度S,词典大小N,匹配数目M,分词算法的时间复杂度量级为O(N*M*S),有兴趣的可以帮我复核一下,这个证明颇为困难,不知道有没有证错。在实际运行的时候,匹配数目会跟着词典的增长而增长,而句子长度则相对固定。当然,明眼人一眼就可以看出,所谓匹配数据随着词典增长而增长,其中并不是正比的。而是O(1)<O<O(n)。因此我们可以看作时间复杂度为O(N)<O<O(N\^2),具体是什么,做不出来。 然后是纯粹的tied tree的性能估量。讲到tied tree,我们就必须要提到如何实现一个有效的tied tree。实际上纯粹用区域哈希映射太浪费内存了,而顺序查找太浪费时间。比较折衷的办法还是只有——dynamic hash table。 不过这次我们就可以控制一下哈希表的大小了。对于大小不超过6W的哈希,我建议采用crc32,虽然离散度并不高,但是作为一个近似填满的hash table的hash key足矣(这点需要实际考察一下)。如果是自己实现,表项直接存字符串,连指针都不需要,采用开链法。总计大小1M即可以保存所有的一级数据。 二级数据就无法这么偷懒了,因为二级结构中字符串长度不定。但是以数据展开大小只有2.4M来看,无论这一级别如何扩张,字符串本身大小不应当超过3M。开链法一个节点24字节,平均填充率0.5计算,14个表项一个词典(这个也可以自行控制了),336个字节一个词典,乘以19K个dict。大约6.23M。127K个频率数据1M,这是常规占用。 以上总计,初级词典本身占用1M,二级结构本身占用10M,不超过20M应当就可以构建起一个高效的核心数据结构。由于实现类似,时间复杂度也类似,就不详细推论了。 以上还有一点可改进之处,dict作为二级存储的绝对劣势在于,必须要对比全部词典才能确定完全匹配数量,于是时间复杂度正比于词典大小。严格的tied树只需要沿着顺序进行几次索引即可,复杂度取决于词语长度——基本来说和词典大小无关。按照这个推论,实现一个紧凑的,高效的二级小结构,可能比较有利于减小总体大小,增加工作速度。

赞一下京东

Apr 11, 2012 - 1 minute read - Comments

昨天觉得背不舒服,买了个按摩器,200。 10点下单,下午两点就送到了,效率不错。 但是用了20分钟,不动了。照说明冷却了一阵,还是不动,遂报换货。 下午四点打电话,10分钟后就来电确认了,五点来了个人,把东西拿走了。 我要求换货,目前页面写的是退货,不知道会不会把新品送来。 不过效率很不错呢。

如何用tabbar插件做emacs的tab定位切换

Apr 10, 2012 - 1 minute read - Comments

说明一下,定位切换的意思,是像chromium那样,用Atl-1-9直接切换tab。而不是用上一个下一个慢慢换。另外,是切换buffer,不是切换frame。 以下是实现部分: ;; 全部的buffer都分一组,否则这个修改是没任何意思的 (setq tabbar-buffer-groups-function (lambda () (list "All Buffers"))) ;; 去掉emacs自带的几个buffer (setq tabbar-buffer-list-function (lambda () (remove-if (lambda(buffer) (find (aref (buffer-name buffer) 0) " *")) (buffer-list)))) ;; 切换到第N个buffer,1为第一个,负数表示从后数,注意0会出错,这里就不处理了 (defun switch-tabbar (num) (let* ((tabs (tabbar-tabs (tabbar-get-tabset "All Buffers"))) (tab (nth (if (> num 0) (- num 1) (+ (length tabs) num)) tabs))) (if tab (switch-to-buffer (car tab))))) ;; 不说废话,绑热键 (global-set-key [(meta 1)] (lambda () (interactive) (switch-tabbar 1))) (global-set-key [(meta 2)] (lambda () (interactive) (switch-tabbar 2))) (global-set-key [(meta 3)] (lambda () (interactive) (switch-tabbar 3))) (global-set-key [(meta 4)] (lambda () (interactive) (switch-tabbar 4))) (global-set-key [(meta 5)] (lambda () (interactive) (switch-tabbar 5))) (global-set-key [(meta 6)] (lambda () (interactive) (switch-tabbar 6))) (global-set-key [(meta 7)] (lambda () (interactive) (switch-tabbar 7))) (global-set-key [(meta 8)] (lambda () (interactive) (switch-tabbar 8))) (global-set-key [(meta 9)] (lambda () (interactive) (switch-tabbar 9))) (global-set-key [(meta )] (lambda () (interactive) (switch-tabbar -1)))

empathy的无聊问题——记一次排错

Apr 9, 2012 - 1 minute read - Comments

废话不说,debian testing,装了empathy后没法用account,等于废物。 先看bug report,开reportbug,看empathy的bug,有一个“Accounts window does not open”,估计就是我要的。 在浏览器中打开,http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594945&archived=False&mbox=no,里面说了大致情况,和我这里非常类似。 第一个意见,killall -9 empathy-account,无效。 第二个意见,需要装CM。 跑去看看,一个都没装。跟着看说明,应该在recommand里面的。OK,我这里有这个配置。 shell-deb:\~\# cat /etc/apt/apt.conf.d/20norecommanded APT { Install-Recommends 0; }; 这是对付很多无聊包把recommand当作suggest用的,结果这次中标。其实这次的recommand应当放入dep里面的。 OK,完事。 PS.虽说如此,记得把telepathy重启一下,否则jabber协议看的到但是无效。

无线网络问题的诊断

Apr 1, 2012 - 1 minute read - Comments

今天看到ZQ在坛子里面说无线网络卡,想想这对很多人是个问题。现在越来越多设备采用无线网络,本来看似够用的无线网络应该也会逐渐变的不怎么够用。这篇文章的大部分内容在blog中都有说,但是没有集结成文。今天集结一下,为大家提供便利。 关于无线网络卡这个问题,有多种可能,我们逐个分析原因/诊断方法/解决方案。 有终端连不上,即使这个终端就在路由器附近 这个主要是因为无线网络负载的设备达到极限所致的。这个极限,我见过最差的路由器是8个,普通路由器(包括dir-825刷openwrt)大概是50上下,苹果的要超过100。一个/24子网的最大负荷是253个IP地址,如果不另行设定,大多数的默认配置都无法超过这个极限。 解决方案很简单,加路由器,或者换一个更好的路由器。加路由器具体参考这篇。换路由器的意见是,不要用fastnet,推荐tplink或者dlink的设备,buffalo的也不错。如果你已经用了这些路由器,但是终端超过50个(好像通常只有公司会碰到吧),可以考虑苹果的,或者多扔两个路由器,辐射小信号好。 有终端离开一点距离后就连不上,或者离开一定距离后速度变慢 这是典型的信号衰减。作为不严谨的测试,你可以在android上安装wifi测试仪,然后走到各个角落。如果你的信号质量不足80dbm,那么就属于比较差的情况。大概能连接,但是经常断线,或者速度很慢。如果不足90dbm,基本就不可用了。 解决方案也很简单,同上一个。总之优化到家里的每个点信号质量都可以就好了。 明明信号很好,速度就是上不去 有可能是因为周围的channel干扰,也可能是因为你的路由器CPU不足。你可以用wifi测试仪,看看你周围当时有多少人在用你路由器的channel。两个channel相隔5以上才不互相干扰。所以,如果你使用channel6,那么channel2-channel10都会对你的信道造成一定干扰,相隔越远干扰越小。而如果你隔壁有一堆和你同channel的AP,实际带宽是均分给你们所有channel的。如果对方用的比较多,也会对你造成干扰。 这是非常难解决的问题,你总不能跑到隔壁说,你们改个信道吧。一方面,如果有条件,你可以对墙壁,门缝做信号屏蔽。这样能减小一点隔壁的信号干扰。另一方面,建议你采用5G频段。这个频段的信道更多,更不容易串扰。但是目前支持5G频段的设备少,而且5G的穿透能力比2.4G更差。 CPU不足呢 CPU不足最典型的确诊就是关掉加密,你的无线网速就会突然暴增。或者你保持无线空载,用有线狂用网络,无线的ping值从10变化到上千。 碰到这种情况,扔掉垃圾路由器重新买一个。 明明有些设备一点问题都没有,有些设备就是连AP都找不到 看看你的channel是否设定到了11以上,例如12/13/14之类的。各个国家对channel的许可范围不一,欧洲日本美国的许可比中国宽一些,因此有12等信道,中国最高到11。因此你用水货手机连外贸版本的路由器的时候,channel12没问题,而用中国许可的设备的时候就连AP都找不到。 解决方法很简单,换个中国许可的channel。 无线速度跟不上外网速度 自从20M以上光纤出现以来,这个问题就逐渐变成主要问题。11g的标准速度号称54Mbps,但是实际上通常只有18Mbps。而外网速度从常见的1/2/4Mbps骤然升到了10/20/30Mbps,就出现了严重的外网速度反超内网速度。 这个一点办法都没有,只能把11g的设备都淘汰光。只要有11g的设备在,11n就无法发挥极限速度,导致你的无线只能在18Mbps上晃。而换用11n的设备后,速度一般可以达到30-40Mbps以上,基本够用。 路由器被打爆 由于速度加快,导致现在有更多的小包可能被传输。虽然传输速率要求不高,但是由于路由器对每个包都需要做同样处理,所以大量小包的资源消耗和同样数量的大包是同一个量级的。我们做一个简单的计算。如果一个包是1500字节,128KB/s的网络可以每秒传输90个包。而如果每个包是64字节,就可以传输2000个包。而当速度升级到2.5MB/s(20Mbps光纤),如果是1500字节,每秒1700个,而64字节的就是40000个。如果路由器的处理能力是每秒10000个包,升级到光纤一跑小包就挂了。很多人在ADSL的时代没问题,升级到光纤反而频繁出问题就是这个原因。 现象比较多,如果是交换机挂掉,往往是一个机器链路OK但是就是有TX没有RX。怎么整也没用,但是过一会,这台机器突然就OK了,换下一台出同样问题。而如果是整个路由器挂掉,可能是路由器突然重启,或者ppp0断线重新拨号。还有的机器是死在那里没任何反应,必须拔掉电源线重新插才有效。