分类:据说是技术

OpenVZ 通过 User-Mode Linux 来安装 BBR

watch-dogs-2013821151855_106b80f.jpg

起源

今天 Ovear 突然想起来,好像很久没有更新博客了,然后打开博客一看。卧槽,上一篇博客已经是半年多一年更新的了,说好的月更也没有做到(:з」∠),还欠了几篇的。吓得 Ovear 懒癌立马退散,赶紧继续更一篇 CDN 系列压压惊。

没错 Ovear 还是管不住自己的手,又剁了台大硬盘 VPS ,可惜是 OpenVZ 的。Ovear 已经特意避开 OpenVZ 的 VPS 好久了,超兽还是其次,主要是自定义空间太小了,完全没办法自己装内核啥的。只能跟母鸡用一个内核,连 swap 和 mount 都不能自由做到。所以 Ovear

一般是不怎么喜欢买啦,但是这次的价格真心棒,忍不住就入了。入了之后,果然线路和性能都不咋地,但是硬盘大啊!鉴于我们大天朝的原因,出国速度想快一点,就只能上无脑 KCPTUN 锐速 BBR 之类的。但是 KCPTUN 的自适应性太差了,正好看见有菊苣在折腾 UML, 刚好就可以在 OpenVZ 上跑 BBR。所以也就学了学,写了这一篇文章。

解决 Nginx 在分发大文件时 Block 浏览器请求的情况

(不要问 Ovear 为什么最近突然诈尸了,我也不知道(:з」∠)

起源

接上一篇,Ovear 买了一大堆奇奇怪怪的 VPS 之后,弄了一个 CDN 又弄了一个图床,又闲得无聊想试试做个视频 CDN,于是在原本的 CDN 上面上传了几个视频文件,然后用浏览器打开,结果发现卡!住!了!,整个请求页面都 Block 住了。然而 Wget 却是没有这个问题(:з」∠)

我是这么设计高性能海量数(ku)据(zi)查询系统的(一)

哎呀,一不小心就2014年了呢~回来看看博客,都长草了_(:з」∠)_。一转眼又要考试了,于是匆匆忙忙码了篇文出来(尼不就是想炫耀下你的裤子么)

另外在乌云也发了篇~希望各位菊苣也去看看~

群众:尼的Java反编译系列教程呢?那边还没坑玩,怎么有开了个坑!!

Ovear:啊哈哈哈哈,今天的天气真不错啊,来看文

群众:滚尼玛(西瓜皮,胖次,带血的胖次)

Ovear:呃,别扔了。咦等等,欧尼sama带血的胖次,啧啧,欧尼sama的血,舔 咳咳咳。。。

6467271020120811120612017

反编译使用Classloader加密的Java class(适合所有带虚拟机的语言)(一)

(看到这个 一 感觉肯定没好事发生)
众所周知,Java是一个实时编译型的语言,其编译后的产物,class文件也是Bytecode,字节码。
很容易被反编译工具反编译,而传统的Java源代码保护方法基本都是采用混淆的方式,
但这样会带来很多麻烦,而且也不能真正保护class文件。
于是,市面上出现了很多采用jni技术定制classloader调用经过加密的class来动态解密,运行class文件的加密器。
所以加密后的文件,根本就不是合法的class文件,自然目前大部分Java反编译器都无法反编译啦,所以也在一定程度上保证Java程序不被轻易逆向。

于是呢,就有了这篇文章

首先来分析下

从上面说的可以看出,经加密过的类字节码 其实已经不是[Java字节码]文件了,那么这样奇葩的二进制文件是怎么被java虚拟机成功加载的呢?
其实就是————>通过Java虚拟机所提供的参数,来设定解密程序(启动的时候需要指定): -agentlib:classloader.dll

简单的来讲,这个agentlib相当于给Java虚拟机做了一个‘Plugin’(插件),Java虚拟机在把Class字节码读入内存的时候,就会先尝试把Class字节码先交给这个Plugin处理再交给系统本身的Classloader(类装载器)加载、执行。
所以嘛,确定了一点:Java虚拟机把读到”奇怪的字节码”交给之前提到的加密器提供的classloader.dll,然后这个dll文件再将这段“奇怪的字节码”解密,然后把解密后的Bytecode再交给Java虚拟机来进行下一步,Java虚拟机就可以正常使用系统的Classloader加载这个类了。当然这个加密器的任务也就结束了。

可以看到,无论加密方式多么屌炸天,都在最后一个环节,[解密]上薄弱了,因为你不管怎么样,都要交给系统的Classloader来加载,也就是说,系统必须认得,既然系统认得了,那么自然在内存中的信息就是你想要的啦。

所以照这个思路下去,任何只要带虚拟机的语言,什么c#啦,什么python啦,什么什么的,都可以按照这个思想来反编译。

那么通用的,也是最简单的解密方法也出来了,酱酱酱酱—–
那就是:请听下回分解。(去尼玛,还下回分解,明明是想偷懒好不好,鬼知道你下回又是什么时候写了,看看你上一篇认真写的文章是什么时候发布的,喂,别走啊~)

Apache mina 1.1 快速入门手册

由于Ovear最近需要一个Socket Server,看中了Mina,所以弄来了一份官方快速入门手册翻译版

Mina 编写自己的编码解码FilterChain(codec)

mina 自己带的FilterChain codec是非常好用,但是在实际网络应用中还是有他的局限性,如编写基于CMPP、SGIP的短信系统。

下面我编写的一个自己FilterChain例子,方便以后查看和其他的人查阅(哎,网上的mina资料少的可怜)

SElinux的奇葩问题

转自:新のBlog(http://xinwo.sinaapp.com/program-can-not-listen-port/)

今天折腾apache正向代理,需要把代理端口单独分离出来。首先选择82,只是调试而已。嗯嗯…启动后就报奇葩错误了:

(13)Permission denied: make_sock: could not bind to address [::]:82
(13)Permission denied: make_sock: could not bind to address 0.0.0.0:82
no listening sockets available, shutting down

这啥奇葩情况?没遇到过啊。因为昨天才在另一台弄来着,半信半疑执行下netstat -anp|grep 82,结果…

unix 6 [ ] DGRAM 5827 1871/syslogd /dev/log

好吧我终于想起了1024以下端口不能随便用,我换…换8282总行了吧?结果…

(13)Permission denied: make_sock: could not bind to address [::]:8282
(13)Permission denied: make_sock: could not bind to address 0.0.0.0:8282
no listening sockets available, shutting down
(13)Permission denied: make_sock: could not bind to address [::]:32323
(13)Permission denied: make_sock: could not bind to address 0.0.0.0:32323
no listening sockets available, shutting down

我勒个去,坑爹也不带这么坑的啊!iptables确定关了,再netstat -anp|grep 32323、netstat -anp|grep 8282确定没程序占用这2个端口。只好无助地求助万能的google,结果就是这台机器启用了selinux,需要把端口加进规则里,否则不放行。据说selinux是加固系统用的,系统本来就很安全了加上这个总感觉像win7加了UAC一样蛋疼。没辙,懒得关了,关了还得重启,查查怎么用吧。

首先用semanage port -l | grep http列出全部http相关的端口规则:

http_cache_port_t tcp 3128, 8080, 8118, 11211, 10001-10010
http_cache_port_t udp 3130, 11211
http_port_t tcp 80, 443, 488, 8008, 8009, 8443
pegasus_http_port_t tcp 5988
pegasus_https_port_t tcp 5989

好吧原来还有8008、8009、8443这几个没见过的端口,不管了先加上自己的,执行semanage port -a -t http_port_t -p tcp 32323,然后apache满血原地复活!~
感谢这位博主提供命令:http://www.zzxj.net/blog/fxs_2008/archive/2010/07/05/187.html
最后带上semanage的用法,有空学学:http://hi.baidu.com/leowang715/blog/item/021bf91330489545f819b8b2.html

[转]2011年中国各大网站均沦陷!隐私化为乌有!新的信任危机!?

12月21日:CSDN 640W用户帐户,密码,邮箱遭到黑客泄露

12月22日:中国各大知名网站全面沦陷….涉及范围甚广,泄露信息涉及用户相关业务甚多….

一场席卷全中国的密码安全问题爆发了….

12月23日:经过确认 CSDN 泄露 多玩 泄露 梦幻西游帐户通过木马泄露 人人网部分泄露

12月23日:网友爆料 天涯沦陷…7K7K包中包含天涯帐户密码!!!互联网安全何在???

12月24日:178沦陷 UUU9沦陷 事态蔓延

12月24日 15:30:天涯全面沦陷 泄露多达900W帐户信息…

12月24日 17:00:网易土木在线也沦陷,数据量惊人…

12月25日:百度疑因帐号开放平台泄露帐户信息…

12月25日:北京麒麟网信息科技有限公司疑泄露百度与PPLive帐户与密码.并且自身帐户信息全部泄露…

12月25日:UUU9.COM被黑客两次拖库..

12月25日:网络流传腾讯数据库泄露!!!

12月25日:事态升级天涯疑泄露4000W用户资料

12月25日:178第二次被拖库泄露数据110W条

12月25日:木蚂蚁被爆加密密文用户数据,约13W数据

12月25日 23:32:知名婚恋网站5261302条帐户信息证实…

12月26日:myspace泄露,迅雷又成功离线3个泄露包!

12月26日 9:47:ispeak泄露帐户信息 已验证!请官方通知会员修改密码!

12月26日 11:36:网络流传包17173.7z中17173.0为178帐户信息,178惨被拖库3次。。。泄露数据200W条

12月26日 11:43:网络流传包17173.7z中17173.3为UUU9.COM帐户信息,泄露数据不详

12月26日 23:17:塞班智能手机网校验准确率高达70%!!或塞班智能手机网沦陷

明天还有谁?还有多少网站没被轮!?

 

 

解密中国假宽带

众所皆知,存储大小单位分 位-bps 字节-byte。so 根据这个我们可以得出 1byte = 8bps;

然后让我们再来揭秘下“砖家”所谓的100M宽带硬盘不够速的问题;

让我们来参考下Wiki -> http://zh.wikipedia.org/zh/SATA

SATA  版本  带宽速度

SATA 3.0  6Gb/s  600MB/s

SATA 2.0  3Gb/s  300MB/s

SATA 1.0   1.5Gb/s  150MB/s

so 由此看来 100Mbps = 12.8Mbyte
让我们看看最低宽频的STAT1 速度为150MB/s 哦 是Mbyte哦。也就是咱迅雷什么下的实际速度;
如此看来,什么硬盘效能不足纯属子虚乌有;
这是Ovear的电脑硬碟;

300m 跟 12.8m比,谁大谁小大家应该知道了吧;
讨论完硬体问题;
我们再来看看实际速率问题;
传送门:http://www.cnbeta.com/articles/167020.htm

首先我们明确下现在国内使用的是ADSL网路方式 也就是传统说所的通过电话线上网;

我们再来看看Wiki;

Adsl:http://zh.wikipedia.org/wiki/ADSL

光纤:http://zh.wikipedia.org/wiki/%E5%85%89%E7%BA%96%E9%80%9A%E8%A8%8A

首先,美国采用的是光纤通讯 这一点就比Adsl好了很多 具体区别请看wiki;

另外Adsl也分很多版本 例如adsl2 adsl2+;

但是据Ovear了解,大部分地区还是采用的Adsl1的格式,这样下载速率最大为8mbps 也就是1Mbyte 也就是迅雷所显示的1m;

而且上行宽带也是很值得考虑的一个问题;

我朝adsl大部分限死为512kbps 也就是64kbyte 但是经常也不达标 有50k就算不错的了;

而我们再来看看cnbeta的米国宽带;

 

米国的宽带大部在3mb左右 而且是实际上传速率;

也就是384Kbyte 左右 相对于我朝的50K不到已经好了很多了;

 

再来看看电信所谓的4M宽带官方测试工具和Ovear用Flashfxp测试结果的差异;

 

以下为Ovear的测试图

纳尼!!!!网卡占用率3.66% 也就是3.66Mbps ,猎奇的电信测试工具,不知道这个4.18mbps哪来的;

 

笔者又对电信的软件进行抓包,获取了电信的测试地址 笔者便自己进行了一番测试;

 

 

ftp地址为sz.10000.gd.cn 协议为ftp ,我们来进行测试;

 

Ovear这里采用了最常见的FlashFxp进行测试;

 

结果如下

 

 

可以很明显的看见,离标准512KB还差了很远;

 

下面我们再来看看非电信官方服务器结果,这里我才用了115服务器 + 迅雷;

 

 

可以看出差距还是很明显的 平均在3.4左右 p2p工具都不是很稳定的说

 

另外Ovear在这补充句 什么线路质量全是扯淡;

你电信限制2M 只有1.8M;

4m只有3.6M;

 

为什么你限制的越高 线路质量越好?明显就是扯淡。要线路质量不好 我4m应该也只有1.8M的速度,为什么可以跑到3.6呢。

既然不是线路问题为什么3.6了就上不去呢?所谓的”专家”需要好好地想一想这个理由了;

[转]MYSQL的KILL语法

最近Ovear在烦恼Mysql query Null过多的问题

因为开启了auto reconnected,所以还不会自动KILL掉

于是Ovear就准备手动KILL掉,后来便看到此文章,转过来用一用

KILL [CONNECTION | QUERY] thread_id 

每个与mysqld的连接都在一个独立的线程里运行,您可以使用SHOW PROCESSLIST语句查看哪些线程正在运行,并使用KILL thread_id语句终止一个线程。

KILL允许自选的CONNECTION或QUERY修改符:

KILL CONNECTION与不含修改符的KILL一样:它会终止与给定的thread_id有关的连接。

KILL QUERY会终止连接当前正在执行的语句,但是会保持连接的原状。

如果您拥有PROCESS权限,则您可以查看所有线程。如果您拥有SUPER权限,您可以终止所有线程和语句。否则,您只能查看和终止您自己的线程和语句。

您也可以使用mysqladmin processlist和mysqladmin kill命令来检查和终止线程。

注释:您不能同时使用KILL和Embedded MySQL Server库,因为内植的服务器只运行主机应用程序的线程。它不能创建任何自身的连接线程。

当您进行一个KILL时,对线程设置一个特有的终止标记。在多数情况下,线程终止可能要花一些时间,这是因为终止标记只会在在特定的间隔被检查:

· 在SELECT, ORDER BY和GROUP BY循环中,在读取一组行后检查标记。如果设置了终止标记,则该语句被放弃。

· 在ALTER TABLE过程中,在每组行从原来的表中被读取前,检查终止标记。如果设置了终止标记,则语句被放弃,临时表被删除。

· 在UPDATE或DELETE运行期间,在每个组读取之后以及每个已更行或已删除的行之后,检查终止标记。如果终止标记被设置,则该语句被放弃。注意,如果您正在使用事务,则变更不会被 回滚。

· GET_LOCK()会放弃和返回NULL。

· INSERT DELAYED线程会快速地刷新(插入)它在存储器中的所有的行,然后终止。

· 如果线程在表锁定管理程序中(状态:锁定),则表锁定被快速地放弃。

· 如果在写入调用中,线程正在等待空闲的磁盘空间,则写入被放弃,并伴随”disk full”错误消息。

· 警告:对MyISAM表终止一个REPAIR TABLE或OPTIMIZE TABLE操作会导致出现一个被损坏的没有用的表。对这样的表的任何读取或写入都会失败,直到您再次优化或修复它(不中断)。

KILL语法