Web 类别下的最新文章

1e100.net,来自 Google

| 7 Comments

在 Alexa 上观测最近的一些数据的变化,发现了一个奇怪的域名: 1e100.net ,全球排名 45 。乍看上去,这个域名非常山寨,不过查询一下,发现这居然是 Google 的域名。Google 的名字是 Googol 这个单词拼错得来的,而 Googol 就是 10100 这个大数。1e100 = 1x10^100 = Googol (refer)。Twitter 上也有网友对此进行了提示。

1e100.net.png

这么看来,1e100 这样的域名风格倒是很 Google 化。从网上的反馈看,Google 有不少服务都在使用 1e100.net 这个域名,最多的应该是 Google Chrome 浏览器的 Safe Browsing 特性对地址的使用(对 Firefox 也有影响),而且会启用较多的并发连接,所以会有网站对此带来的压力无法承受而屏蔽 Google 的这个服务(refer),此外也让我想起以前 Google Chrome 早期的版本解析 DNS 多少有点慢,不知道是否有相关因果关系。Google 的其它产品包括 Google Toolbar、Google Analytics、YouTube 、FeedBurner 等服务也用这个域名。也有人发现 Google IPV6 地址也是通过这域名在进行测试。不过直接访问 1e100.net 是访问不到的,Google 通过子域名的形式进行使用。

按理说,这种不对外提供服务的地址,Alexa 没必要统计流量的,或许是他们的小失误倒是让我们了解到 Google 的一点有趣的信息。

--EOF--

更多参考:

更新:最新的消息说是 Google 不同数据中心间用来" identify servers, hinting that reverse DNS plays a role" ,关键词"Spanner"。

针对小型站点的技术普及信息,中大型网站的牛人不用看,耽误您的时间我负不起这责任。
用 Windows 做网站的也别看了,不适合。

说起单点故障(Single Point of Failure,SPOF),倒是可以想起电影 《2012》中,一把焊枪把齿轮卡住,从而导致整个舱门无法关闭,进而整个引擎无法发动。这是个有点生动的例子--如此庞大的一个系统,居然因为一把小小的焊枪而险些毁于一旦。投入巨大人力物力生产的救命方舟居然做不到高可用(High availability),这是致命的事情。

大脑对与人来说,就是一个单点,大脑损坏,人也完蛋;手是不是单点? 一只没了,另一只还能日常生活,从这个角度来说,不是单点。消除单点的最常见的做法:增加冗余。比如,人有两只手。其次,层次化。当然,分层的目的是便于隔离问题。电影 《2012》 中的这个问题,不知道谁是总架构师,看起来,隔离做得不太够 :)

一般来说,只要系统能够比较清楚的分出层次来,要消除单点故障还是有章可循的事情。比如,一个网站,从基础的硬件层,到操作系统层,到数据库层,到应用程序层,再到网络层,都有可能产生单点故障。如果要有效的消除单点故障,最重要的一点是设计的时候要尽量避免引入单点,而随着架构的变化,定期审查系统潜在单点也是有必要的。

有人或许会问,假设一个起步中的站点,只有一台服务器,什么东西都在一个盒子里,到底要怎么做呢? 这里的建议是先抛开主板、CPU 、内存这些,首先必须考虑硬盘(存储层)的问题,如果机器只有一块硬盘,即使你备份计划再完善(不要说你的备份也是备份在这块硬盘上的),还是建议你起码再弄一块。做镜像,让出错的概率降低,这是划算的投入,当然消除单点,成本几乎不可避免的要增加。如果硬盘多,或者有其他备份机制,可选的方法就更多,别刻舟求剑。

第二个要考虑网卡与网线的单点问题。先说网线,如果要问一个系统里面最容易物理损坏的是哪个组件,答案恐怕非网线莫属,对于网线这样多数时候因为距离需要定制的东西,总是购买成品还是有成本的,从我观察到的情况来看,各个 IDC 的网线使用手工制作的比例不小,这个质量几乎很难控制,一根线,两个水晶头,哪一个出问题都不能正常传输。怎么办? 想办法提升网线整体质量还是弄两根网线放在那里? 解决办法早都有了,网卡绑定 (NIC bonding)一个很简单很通用的办法(refer),但是问题是并非很多人在用。多数 PC 服务器应该都是配置了多块网卡,如果是自己攒服务器,记得网卡多一块成本没多大,但是用处会有很多。如果耐着性子看到这里,先别急着去 Google,还有问题呢,两根网线如何接到上行交换机,什么样的交换机支持绑定,如何确定绑定是真正生效的? 答案是,尝试一下。

然后是什么? 是跑多个数据库,还是跑两个 Web 服务器,一个不行用另一个顶? 对于单台服务器,其它能消除单点的地方恐怕收效也不会特别大,现在少做无用功,或许要重点考虑如何备份,如何优化,以及出现问题的时候如何做到快速恢复。有一个或许会引起争议的建议是,除了 SSH 登录之外,要不要留一个 Telnet 登录的服务呢? 毕竟 SSH 服务器端守护进程不是百分百靠谱的事儿,如果 IDC 距离较远,需要斟酌一下。好吧,网站有了一点发展,用户量也增加了,感觉需要增加服务器了。再增加一台服务器,抗风险能力一下子加强了许多,毕竟一台机器质量再好,也有出错的时候。现在,Web 服务器、DB 服务器可以考虑引入 HA 的方案,如果单台服务能力够,主备模式也不错。随着网站的发展,服务器数量继续增加...

随着服务器数量的增加,到了必须要自己购买网络设备的时候了。同样的设备,一买恐怕就要买双份,原因无它--一台总要出错,哪怕是电源被拔错--而这样的情况实际上并不少见。如果预算不够,那就再等等,但是要记住,定期审查,有可能的话,进行弥补总不会错。

到现在,所有的服务器都还在一个 IDC 呢,IDC 本身也是个单点啊,服务器被黑怎么办? 机房光线被施工工人挖断怎么办? 机房停电怎么办? 找第二个机房吧。现在选 IDC 首先要考虑什么? 中国特色的互联网问题总要考虑吧,"南北互通"怎么样...或许在选择第一个机房的时候已经遇到了类似的问题,或许现在正在受到这个问题的困扰。选好 IDC 之后,首先计划一下数据如何备份过来,然后,网站的配置信息如何同步或备份过来(这是保证第一个 IDC 出了致命问题之后的最基本的恢复要求)。多个 IDC 之后不得不提上议程的要算 DNS 这个事儿了。你的 DNS 解析商靠谱么? 如果域名提供商遭受攻击,对自己的网站影响能承受么?

更多的服务器,提供更多的应用,更多的用户,更多的收入... 接下来该怎么办呢? 现在,您所面对的已经不是一个小型 Web 站点了,可以不用看这篇文章了。

到现在,我还没说人的问题,如果这些信息只有一个人知道,万一这个人出了点事情怎么办? 作为老板,还要考虑人的单点问题。

--EOF--


网站优化技术总是在进化。今天重新阅读了一下以前的前端优化笔记,发现对于 YSlow 优化 34 条准则关于减少 DNS 查找 (Reduce DNS Lookups)的部分或许应该修正一下了。

DNS 作为互联网的基础协议,其解析的速度似乎容易被网站优化人员忽视。现在浏览器厂商已经有在针对 DNS 进行优化,典型的一次 DNS 解析耗费 20-120 毫秒,减少 DNS 解析数是个优化的方式,而能够缩减 DNS 解析的时间也是有经济效益的事情。这就是浏览器厂商重视 DNS Prefetching 的主要原因。DNS Prefetching 对于性能的收益可以简单的用"DNS 同步请求到异步"来解释,也就是具有此属性的域名不需要用户点击链接就在后台解析,而域名解析和内容载入是串行的网络操作,所以这个方式能减少用户的等待时间,提升用户体验。

Google Chrome 内置就有 DNS Prefetching 技术(注意之前有几个小版本因为这一特性反而带来了性能问题) ,而 Firefox 3.5 也引入了这一 新特性。至于 IE 8,暂时还看不到有什么举措(或许是我没注意到?)。

对于一个网站来说,如果希望能充分利用用户浏览器端的这个功能,可以在页面添加 link 属性的锚点来做到。类似:

<link rel="dns-prefetch" href="http://www.google-analytics.com/">

另外还有这个 x-dns-prefetch-control 也有必要适当用一下。对于某些站点引用了 Google 的某些服务脚本,可能这尤其有用。

另外一种加速 DNS 的途径是考虑使用 pdnsd 之类的缓存 DNS 代理服务器来加速某些 DNS 请求。

在 Chrome 中,可以通过在地址栏输入 about:histograms/DNS 来观测一些有趣的 DNS 性能数据。

--EOF--

几天前看到的这个关于密码遮盖(Password Masking) 问题的讨论,顺着链接有找到了一些讨论来看,继而发现相关文章已经有人翻译了(refer),但中文技术社区好像很少见到讨论(也可能是我孤陋寡闻)。

这是个令人印象深刻的话题,因为挑战的是习惯性的设计方式。放眼看去,所有需要输入密码才可登录的网站都是遮盖密码的。密码遮盖带来的坏处是显而易见--用户的输入成了盲区,不知道自己输入的是否对,点击登录变成了变相的试错操作,产生比较多的再次登录操作,对给用户造成非常糟糕的使用感受。然而似乎很少有人如何去考虑改进这个现状。关注别人视而不见的问题才会带来革新与创新,要不怎么说人家 Jakob Nielsen 是用户体验方面的大牛呢,要从别人口中出来这个论断可能会被人笑话,而大牛就敢于挑战常规,弄个问题就给大家带来思考了--扯远了。

似乎多数人赞同添加一个额外的检查框(CheckBox),安全性要求不高的应用,默认不遮挡,用户输入完毕之后,再选择旁边的检查框对密码进行遮挡;对于安全性要求比较高的应用,默认密码遮挡,但可以选择显示一下密码明文一下,方便用户检查是否有拼写错误。

如果你用过苹果的产品,比如 iPhone 新 OS 3.0 的版本,你会发现密码的处理又进了一步,密码输入时是显示明文的,方便用户确认没有输错,在几秒钟后或者输入下一个字符的时候再对这个字符遮盖。(很多移动厂商好像现在都这么设计了)

iPhone_Password_Masking.png

(截图有点喧宾夺主,对付着看吧)

这个想法真的很让人欣赏,对于手持设备能够比较有效的防止了窥探(peeking over your shoulder),也减少了用户输入错误的频率。只是不知道是不是已经被手机厂商申请了专利。对于大屏幕显示器来说,窥探的可能性有多大?缺乏数据支持,很难说明。或许,这里的安全专家的分析对质疑者也会有点帮助。

其实我觉得密码遮盖问题在用户初次注册的时候带来的问题尤其严重。在这个环节如果添加一个 CheckBox 要用户知道自己连续两次输入的密码是什么应该是有必要的(有人举手同意麽?) ,否则的话,用户要的密码可能不是自己输入的,短时间内连续两次输入,出现键入错误的几率并非不存在。

好吧,现在开始审视一下自己的网站登录框设计以及注册页面吧...新的问题或许是,你有勇气做点修改麽?


如果觉得上面说的都是废话,那么不妨考虑这两个问题:

  • 为什么我们之前就没考虑到这一点?
  • 如何才能先于别人一步想到这一点?

--EOF--

延伸阅读:Better Password Inputs, iPhone Style

关于归档

本页包含 Web 类别下的所有文章.

上一类别为 Tech.Memo.

回到 首页 查看最近所有文章或者查看所有 归档文章.