当我们在查看网页源文件的时候,在源文件顶部往往都能看到:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” ”http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
或者
<html xmlns=”http://www.w3.org/1999/xhtml” …>
如上面的代码,都含有指向W3C网站服务器的关于HTML DTDs 和 命名空间相关的网页资源。W3C管理员的纠结正源于此。
我们注意到上面的刷蓝标签,其实并不是HTML中的超链接,他们是仅仅用来作为确认的URIs,这是以机器能读懂的方式告诉计算机“这个文档是HTML”。并且,通常计算机软件程序并不需要去抓取这些URI资源,并且一定不需要反反复复地去抓取这些资源!然而,W3C服务器却接收到“令人震惊”的“出奇地大”的对这些资源的请求:每天收到超过130,000,000次的请求,占用宽带使用350Mbps,仅仅是抓取几年未变样的资源文件。
这时,W3C管理员声音很哽咽,感觉得出这事对他影响很大,鬼斧很认真地接着听她讲下去,了解到:
这么大的网站访问请求,有绝大多数来自处理各种标记(HTML, XML, XSLT, SVG)的系统,如在验证DTD或schema的处理期间发起的请求。
要处理这么大的请求给W3C带来了昂贵的成本和代价:服务器!带宽!还要花费大量人力来分析这些请求数据、限制或阻止一些大量重复的请求。“很郁闷,我们宁愿用这些钱去做其他事情!比如改进、完善W3C和WEB社区的软件和服务。而不是这样被耗这么多钱!”W3C管理员显然有点小怒了。
“前不久,我们加了一个系统来监控这些请求,并对一些泛滥的请求直接发送503错误,并根据具体的垃圾请求形式作为对应的响应信息返回。我们希望是这些个对W3C发起大量请求的软件的开发者或部署管理员能够注意到这个错误,并且对他们的软件做一些必要的修正。”W3C管理员继续哽咽地讲到。听到这里我拍拍她的肩膀说“i am sorry!”表示同情。
“但是这些系统大多数依旧每日无数次地请求相同的DTDs,即使我们夜以继日给它们返回503错误也毫无效果,为啥这些系统这么讨厌!他们根本就不关系这些请求!(对于一些请求源头,我们最后在TCP层对其IP进行了阻止。)”
“我们也鉴定出了一些导致对W3C大量请求的软件,并且联系了他们的负责人,告诉他们在对W3C进行DDos攻击。一些进行积极相应并及时修正了这些问题。不幸的是,有很多却拖延很长时间不给解决!还有大量的请求无法断定来源!”W3C管理员眼睛里夹杂着丝丝无奈。
“我多么希望这个问题可以一劳永逸地解决,做梦都想!这也是为了部署在W3C网站的所有软件着想。所以我给那些软件作者一些建议,希望他们不要再无休止地折磨W3C”:
1、关注您的HTTP响应码。
编程的一个好习惯是检查您的响应码,否则当一些错误发生的时候您压根就不知道。
2、善用 HTTP caching/expiry 信息。
W3C网站的资源是以友好缓存方式存储的。我们的DTDs 和 schemata都明确定义过期时间为90天以上,所以压根没必要一天不停息地请求。(有一个公司的许多IP地址从W3C请求DTD,一个IP地址每天请求竟然超过10万次。)
3、如果您的软件实现采用HTTP,可允许超速缓存。
4、负责关注您对外出的网络流量。
5、在实际需要的时候才抓取外部内容。
最后,W3C管理员抛出一个问题:“W3C可以忽略这个问题,响应所有的用户请求吗?”
假如有一天,我们目前处理10亿多DTD请求,变为100亿次的DTD请求该会怎么办?
总的来说,对于W3C过度的DTD网络流量(W3C‘s Excessive DTD Traffic )这个事,“W3C管理员很生气,郁闷、惆怅、纠结”,这比墨西哥湾漏油更让她寝食难安。
网林鬼斧最后给W3C管理员了三点建议,希望对其有所帮助:
1、首先得让大家知道这个事情、逐渐重视这个事,这一点阅网博客带头给大家进行国内首次的书面介绍。
2、在中国做一些更明了的使用手册或帮助手册,如果中文帮助做好,错误的时间、错误的请求是可以最大程度避免的。在做一份关于DTD使用经验更加简单明了方面,阅网博客愿意帮助W3C共同推进此事。(当然国外也是。)
3、希望W3C管理员注意身体,该吃吃该喝喝,有事别往心里隔,积极处理此事,但是别因此日渐憔悴,多出去转转、多陪陪家人:) 哈哈,有点扯远了。
最后,希望W3C管理员头疼的这个问题早日得到解决。
来源:阅网博客投稿,原文链接。