客户反馈近来主机流量报警，但网站本身页面不多，不至于如此。
于是通过服务器端查看iis日志，发现许多状态为206的日志记录。再细看前面：GET /aaa.mp3
然后找到网站根目录，才发现网站中存在一个mp3文件，虽然不热但是浏览的人也比较多。根据RFC协议，206状态反馈出的意义如下：
iis状态码206是什么意思：
服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。
该请求必须包含 Range 头信息来指示客户端希望得到的内容范围，并且可能包含 If-Range 来作为请求条件。
响应必须包含如下的头部域：
Content-Range 用以指示本次响应中返回的内容的范围；如果是 Content-Type 为 multipart/byteranges 的多段下载，则每一 multipart 段中都应包含 Content-Range 域用以指示本段的内容范围。假如响应中包含 Content-Length，那么它的数值必须匹配它返回的内容范围的真实字节数。
Date
ETag 和/或 Content-Location，假如同样的请求本应该返回200响应。
Expires, Cache-Control，和/或 Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。
假如本响应请求使用了 If-Range 强缓存验证，那么本次响应不应该包含其他实体头；假如本响应的请求使用了 If-Range 弱缓存验证，那么本次响应禁止包含其他实体头；这避免了缓存的实体内容和更新了的实体头信息之间的不一致。否则，本响应就应当包含所有本应该返回200响应中应当返回的所有实体头部域。
假如 ETag 或 Last-Modified 头部不能精确匹配的话，则客户端缓存应禁止将206响应返回的内容与之前任何缓存过的内容组合在一起。
任何不支持 Range 以及 Content-Range 头的缓存都禁止缓存206响应返回的内容。
另外部分日志中存在zune的状态，仔细查了下百度，zune如是：
以下是引用片段：
Zune是微软（Microsoft）公司提供的高级视频和音乐服务，是供Windows Phone和PC使用的一款免费应用软件，能管理和播放数字音乐和视频。 |
至此原因明了：主机中mp3文件被zune盗链，用户请求该音乐时，zune自动盗链抓取所致。
解决办法：删除mp3文件。
建议：视频、音频等用户私有容易被盗链的娱乐性文件建议不要放到正规网站中保存。
以前最bt的一个案例是，曾经一个客户放了一个流行mp3文件，一天被某音乐引擎盗链了500G流量（毫不夸张），所以千万不要一时侥幸而做出错事，如果主机限制流量，且又被盗链消耗掉流量，主机被停，网站管理员恰巧又没及时发现，那么后果可想而知！
