當我們在查看網頁源文件的時候,在源文件頂部往往都能看到:
<!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管理員頭疼的這個問題早日得到解決。
來源:閱網博客投稿,原文鏈接。