昨天做测试不小心弄错了，在那个时间段访问的朋友会收到抓取频繁的通知，不用担心。
为什么要测试呢，看上图。
昨天总共用去33G，是近几天最少的。我用的是最便宜的主机，每月1000G，简单乘一下就知道，一定是超了。
暂时的忍耐度是2%，超过的会收到抓取频繁的信息提示修改设置。受影响的非常少。
说过太多次了，我去抓别人网站最多也就是半小时一次，你分分钟都来更新，只是更新了个寂寞。（此话基本针对有自己服务器的，这前几位已经占去10%以上的流量，可供参考的feedly只用了60m左右）
不想升级，没钱。
RSS全文订阅
昨天做测试不小心弄错了，在那个时间段访问的朋友会收到抓取频繁的通知，不用担心。
为什么要测试呢，看上图。
昨天总共用去33G，是近几天最少的。我用的是最便宜的主机，每月1000G，简单乘一下就知道，一定是超了。
暂时的忍耐度是2%，超过的会收到抓取频繁的信息提示修改设置。受影响的非常少。
说过太多次了，我去抓别人网站最多也就是半小时一次，你分分钟都来更新，只是更新了个寂寞。（此话基本针对有自己服务器的，这前几位已经占去10%以上的流量，可供参考的feedly只用了60m左右）
不想升级，没钱。
如果自己看，每日一次都不一定看得完。
这种属于高频次的，更接近商业用途，应该请他们自己承担商业带宽的成本。
请问是否可以加上RSS 的 TTL 字段呢。可以按照抓间隔给ttl。对于正确实现的RSS reder 可以减少ttl内的请求次数节省带宽
我觉得不会起太大作用，这算个君子协定吧。因为那些流量比较大的服务器程序一般都会有获取时间间隔选项（通常默认时间还都挺短），我觉得他们根本不会去参考ttl的，我管你的推荐设置呢。
感谢，试试也无妨。
我觉得正常健康的抓取不应该比feedly、inoreader超出太多，这也是以后封禁的一个参考。
找到一个比较详细的
https://www.rssboard.org/rss-profile#element-channel-ttl
一般大型的程序会专门有一个bot去抓取。特别是feedly, inoreader这种。bot大多会使用Range Header 抓前面的lastBuildTime和ttl。然后通知feed更新。
不是分析lastbuiledtime或ttl，应该是判断Last-Modified和If-Modified-Since。
看日志就能看出feedly inoreader tts outlook等都很规矩，GET请求会带条件，没更新的话服务器返回304，数据量为0。但绝大部分程序都是直接GET请求，并不判断If-Modified-Since，服务器返回200。
上面我找的链接说当时连google reader 都不支持ttl。