Google也挺鸡贼啊

Google也挺鸡贼啊
不知道什么时候封了这个搜索方式

以前可以直接搜索IP的网站
使用 site:.88 就可以搜索出所 IP段88结尾的网站

不要问我为什么有这个需求,反正就是有用
这个方式封掉了….

我试着使用 site:*.88 加通配符 又有结果了
估计之前是拿IP结果玩的太厉害 封了这种模式

最近通过搜索访问本文章的关键词:

【分享】一个不算成功的数据网站的开发和运营和流量数据的案例 包括原理和想法介绍

分享个不算成功的数据网站制作案例 包括原理和介绍

很早以前 打算利用信息差 尝试下数据网站的存活率
所以设计了这个网站

这个例子算比较早 好几年了 网站现在还存活着
域名使用的是 www.91r.net 很简陋 主要是编程相关的内容
这个内容是来源于 stackoverflow.com

收录可以查看 2017-07-02 更新

百度 8月3日 收录过千万了
该网站共有 10,454,575 个网页被百度收录

百度: https://www.baidu.com/s?wd=site%3A91r.net

Google: https://www.google.com/search?q=site%3A91r.net

当初最早设计的时候
姑且叫第一个版本吧 直接使用小偷程序的原理 就是抓数据 返回
后来发现英文内容 搜索对英文重复内容的判断过于强大 基本无法带来什么流量
数据在多也没用

所以换个思路 就弄了第二个版本
第二个版本的设计 小偷还是小偷 但是利用翻译 把内容翻译为中文
这里的信息差 就是内容唯一性,以及使用百度翻译结果给google抓取
结果是成功的 很短的时间 流量上升到5000IP/天

继续阅读【分享】一个不算成功的数据网站的开发和运营和流量数据的案例 包括原理和想法介绍

最近通过搜索访问本文章的关键词:

Google Cloud 性能真好

最低套餐 1个share cpu
编译软件速度飞快
网络就不说了 真心飞快….

测试网络高峰期的时候 Drive里的视频 1080P 无压力
就是流量费用贵了点 单资源的话 价格算很便宜的
total used free shared buff/cache available
Mem: 588 138 85 4 364 311
Swap: 0 0 0

1个共享处理器 / 600M内存 = $5/月
10G硬盘 $0.4/月

剩下费用都是流量费用了

CentOS 7 开启 Google BBR TCP 加速

#1 检查内核

如果非4版本的话,继续

#2 更新内核源

#3 调整内核

#4 重启

#5 开启TCP控制 给bbr接管

#6 检查
检查内核

返回4.9版本
代表OK

检查BBR

返回 net.ipv4.tcp_available_congestion_control = bbr cubic reno
代表OK

google 真是到处限制啊

www.BOIP.net 的IP信息图片调用
好好的莫名其妙输出不了图片,debug了下 发现变量timezoneID没值了

因为取时区 所以使用了Google的api
结果发现 这个api是和map地图绑定的

一天限制2500/次…..

改为写死UTC 就OK了

真是各种坑

最近通过搜索访问本文章的关键词:

云存储 真的都干不下去了

云存储真干不下去了

定调
所以说倒底 利益问题, 当一个公司 投入百万千万的资源,运行一个亏本生意,投资人肯定不干
通过技术解决滥用和涉黄的内容传播 对于程序狗来说 并无什么难度
因为这些公司的云存储 重复文件都是存储唯一副本的
所以无非扫描文件 标记标识符 X 或 Y 如果X类型的 禁止分享
对于视频 通过机器学习 提取视频的N个帧文件 做图像识别 是不是X
如果是 标记X 并且将所有这个副本唯一识别符 都标记为禁止分享

先说国内 最近360云盘最近也阵亡了
发布公告
这个事其实我意料之中, 在各家网盘打存储空间的时候,我估计离关闭也不远了
在大公司的业务布局里,云盘不属于一个战略级的产品
唯一的价值是收集一些数据 比如用户行为数据等等

实际上在网盘的用户群体中 付费用户并不多
这个是因为国内用户对于数据的敏感性远没那么高
普通的用户 利用网盘存储的数据 都不是特别重要的数据
特别重要的数据 都会使用U盘,移动硬盘等东西存储
企业客户更不说了 有点数据安全概念的 都会使用本地存储
因为各家公司的黑历史 大部分网民对这些大公司 都不是特别信任
而且国内没国外那种成熟的法律法规 限制公司对客户存储的数据操作 像Google Drive有合规的数据中心和合规的安全协议
所以存储相对安全 这些东西更多的是靠公司和行业自律

云存储的出现 本意是解决当今数据爆炸和网络宽带速度增长产生的数据存储问题
尤其是文件的网络传输共享
但是在中国变味了 完全变存爱情动作片的小电影用途了
如果自己看 也无可厚非 毕竟不能剥夺爱好对吧
问题在于最离谱的一点 敷生了一个产业链 一个从下载 打包 卖账户的生态
好像美国的淘金 千里迢迢去淘金的人没赚钱 卖牛仔裤的发了
这样这类云盘的公司 还干嘛 肯定不干啦
我投入N个G的带宽 百万千万的硬件设备,结果尽给你们赚钱了,我还承担个涉黄的风险

所以封是早晚的事 尤其是在这种维权和版权意识越来越严格的大环境下
网络靠资源投机时代已过去了

看国外的一些类似网站的历史 也就知道未来会怎么样

Rapidshare 德国 2006年至2015年 客户存储了超过10PB的文件 我以前最喜欢用的
Megaupload 香港 2005年至2015年 不被美国司法部以拥有大量的侵犯著作权文件为由,强制关闭网站
这个只是比较著名的 Rapidshare最高峰储备带宽超600Gbps 知道什么概念吗?
这些原则上和国内的云存储是一样的 上传文件 分享文件 只是这类一般会被叫上传站 国内叫网盘 云存储 云盘 云硬盘
没什么本质区别

下一个 百度网盘
虽然百度做了很多工作去防止滥用和非法传播 比如让你看“30秒的宣传片” 这个打击是几何倍增的
但是遏制不了 因为人多 当然 按百度的尿性 一般会归类为”这届网民不行”

使用Google Drive解决跨国跨区域数据传输慢的问题

Google Drive 服务器分布

最近同步了大量数据 研究了一下

Google的服务器集群标识符和CF是一样的 都是使用机场代码进行标识的
例如达拉斯 使用是dfw

Drive的服务器 也是geographic分布
服务器非常多,网络上行基本毫无压力,只要你服务器速度够快
Drvie的url是这个 API调用都是走Googleapis的域名
这个域名也是GEO解析的
https://www.googleapis.com/upload/drive/v2/files
如果你多区域Ping 可以得到非常多的IP地址
http://ping.chinaz.com/?host=https%3A%2F%2Fwww.googleapis.com%2Fupload%2Fdrive%2Fv2%2Ffiles&linetype=%E7%94%B5%E4%BF%A1%2C%E5%A4%9A%E7%BA%BF%2C%E8%81%94%E9%80%9A%2C%E7%A7%BB%E5%8A%A8%2C%E6%B5%B7%E5%A4%96

比如
日本 解析到 216.58.197.234 PTR是nrt13s49-in-f10.1e100.net
这个NRT是日本千叶的成田机场,代表Google日本千叶县的数据中心
香港 解析到 216.58.199.106 PTR是 hkg07s22-in-f10.1e100.net
这个HKG是香港国际机场的代码,代表Google亚太香港数据中心

其他的以此类推

美国 好像主力是走DAL线路 就是达拉斯 标识是dfw
因为达拉斯差不多在美国算核心的互联网交换枢纽 信息高速公路
而不是在谷歌的大本营加州
我美国主要区域的服务器 上传数据 捕获的都是上传到达拉斯线路

速度非常的快

达拉斯1Gbps带宽的服务器上传到Drive服务器 速度基本维持在900Mb左右
堪萨斯1Gbps带宽的服务器上传到Drive服务器 速度基本维持在100Mb左右
堪萨斯带宽质量是比较差的 价格低

而欧洲 好像法国 fra是主力
我法国服务器上传数据 是fra
我德国服务器上传数据 也是fra
速度也在900Mb/s左右的速度

如果不是Google Drive有频率限制 rate limit
基本带宽都可以跑满你服务器的物理极限

以我的高智商 又提高了工作效率

比如这种使用场景
美国到欧洲 服务器对服务器Rsync同步 速度上不去 网络状况不佳 100M的速度
但是使用Google Drive作为中转的话
我的美国服务器 -> Google Drive服务器 < =10Gbps线路=> Google欧洲服务器 -> 我的德国服务器
这样就解决了 传输速度问题 1G带宽的肯定不低于500Mb/秒的速度
而且最大的好处是 同时解决了备份的问题啊有木有?

Linux服务器
使用Rclone可以sync模式或者upload模式
有自动判断rate limit的问题

这个方案 其实非常的赞哦

最近通过搜索访问本文章的关键词:

果然还是Google靠谱

果然还是Google靠谱
达拉斯到德国传输实在太慢了 简直不能忍
想想还是研究了一个折中的方案,
初期的想法是使用Squid部署一个代理节点,做数据中转
结果根本不是那么回事, 貌似我所有达拉斯不同机房到德国都慢
这个就排除机房网络问题了 应该是路由问题

然后使用Google的Drive来做中转
上传速度600Mb/秒 那叫一个快….
可惜的是

403: User Rate Limit Exceeded

The per-user limit from the Developer Console has been reached.

有配额限制…………
每100秒 低于1000次请求还是什么的
同步是快 问题在于这个403错误

再次脑洞大开 使用cronjob定时任务 每5分钟运行一次, 在运行之前 kill掉gdirve的进程

这样不知道几天可以同步完8T内容
然后在从Google Drive同步到德国服务器 估计又是几天….
哎 难…….

低成本使用Google Drive 10T存储

低成本使用Google Drive

如果备份内容不超1T  Google Drive直接买就可以了 $9.9/月
如果超了 就是$99.9/月 10T了
问题是 这个跨度有些大 是不?  很少有人使用10T的

那么问题来了 有没更低成本的方式?


因为有需求使用Google的企业套件 包括企业Email等
这里包括的Google Drive 默认说无限 其实是10T的
最低的要求是5 user版本 = 每月$50 = 5个无限Google Drive存储?

而且内容可以传输,功能和99.9的10T无区别

$99.9 = 10T 单账户
$50.0 = 5x 10T 多账户 (其实说的是无限)

对于我这种备份大户来说 还是很不错的
就是不能多服务器同时备份
会出现userratelimit的限制
但是 多账户可以不同账户操作啊…..

好像上行有限制 洛杉矶的100M独立端口 备份速度才5MB/s

PS:更新下
企业Google Drive是无限的
如果API查看配额 是显示 10T
但是你上传1T文件 显示可用还是10T, 但是总计容量 变为11T了
可用容量好像没变…… 一直是10T

不建议大家撸Google羊毛 比如买EDU账户 很容易被封的
花点钱买安心  而且就算$99.9的 也算良心价了
10T 你哪个云端存储备份的都没这个价…….

最近通过搜索访问本文章的关键词: