分类：据说是技术

解决Laravel获取获取配置不稳定的问题

2020 年 4 月 15 日

（还在更新排版中...）
原因
在Apache开启worker或者event配合PHP Thread-safe版本的多线程情况下，环境变量由各个PHP线程共享。
在前一个线程初始化/退出清理环境的时候，会影响到其他线程读取环境变量，导致phpdotenv无法获取到正确的值（被初始化），从而导致Laravel获取不到设定的config，导致config初始化。

OpenVZ 通过 User-Mode Linux 来安装 BBR

2017 年 5 月 11 日

起源

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

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

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

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

2016 年 9 月 26 日

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

起源

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

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

2014 年 1 月 1 日

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

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

群众：尼的Java反编译系列教程呢？那边还没坑玩，怎么有开了个坑！！

Ovear：啊哈哈哈哈，今天的天气真不错啊，来看文

群众：滚尼玛（西瓜皮，胖次，带血的胖次）

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

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

2013 年 8 月 17 日

（看到这个一感觉肯定没好事发生）
众所周知，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 快速入门手册

2012 年 7 月 15 日

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

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

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

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

SElinux的奇葩问题

2012 年 5 月 14 日

转自:新の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

解密中国假宽带

2012 年 1 月 19 日

众所皆知，存储大小单位分位-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操作会导致出现一个被损坏的没有用的表。对这样的表的任何读取或写入都会失败，直到您再次优化或修复它（不中断）。