msgbartop
PHP语言, PHP扩展, Zend引擎相关的研究,技术,新闻分享 – 左手代码 右手诗
msgbarbottom

02 Oct 15 让你的PHP7更快之Hugepage

PHP7刚刚发布了RC4, 包含一些bug修复和一个我们最新的性能提升成果(NEWS), 那就是”HugePageFy PHP TEXT segment”, 通过启用这个特性,PHP7会把自身的TEXT段(执行体)”挪“到Huagepage上,之前的测试,我们能稳定的在Wordpress上看到2%~3%的QPS提升。

关于Hugepage是啥,简单的说下就是默认的内存是以4KB分页的,而虚拟地址和内存地址是需要转换的, 而这个转换是要查表的,CPU为了加速这个查表过程都会内建TLB(Translation Lookaside Buffer), 显而易见如果虚拟页越小,表里的条目数也就越多,而TLB大小是有限的,条目数越多TLB的Cache Miss也就会越高, 所以如果我们能启用大内存页就能间接降低这个TLB Cache Miss,至于详细的介绍,Google一搜一大堆我就不赘述了,这里主要说明下如何启用这个新特性, 从而带来明显的性能提升。

21 Jan 14 Curl的毫秒超时的一个”Bug”

最近我们的服务在升级php使用的libcurl, 期望新版本的libcurl支持毫秒级的超时, 从而可以更加精细的控制后端的接口超时, 从而提高整体响应时间.

但是, 我们却发现, 在我们的CentOS服务器上, 当你设置了小于1000ms的超时以后, curl不会发起任何请求, 而直接返回超时错误(Timeout reached 28).

原来, 这里面有一个坑, CURL默认的, 在Linux系统上, 如果使用了系统标准的DNS解析, 则会使用SIGALARM来提供控制域名解析超时的功能, 但是SIGALARM不支持小于1s的超时, 于是在libcurl 7.28.1的代码中…

18 Mar 13 Yac (Yet Another Cache) – 无锁共享内存Cache

好久没有更新blog了, 这一年来的工作确实很忙….. anyway, 今天终于有新东西可以和大家分享.

这个idea来自一个很简单的想法, 以及目前所遇到的一个机会. 首先我们来谈谈这个机会.

在以前, 很多人都会选择使用APC, APC除了提供Opcode Cache以外, 还会提供一套User Data Cache(apc_store/apc_fetch), 所以对于很多有需求使用User Data Cache的同学, 使用APC, 就没什么问题.

然而, 最近Zend Optimizer Plus开源了, 测试表明, Zend O+在Opcode Cache方面, 因为做了Opcode Cache优化, 所以会比APC要高效, 再后来, PHP5.5已经把Zend O+作为了源代码的一部分. 会随着PHP一起发布.

这就有了个问题, 对于那些既要使用Zend O+的Opcode Cache, 又要使用APC的User Data Cache的同学, 怎么办呢?

开始的时候, 我只是给APC增加了一个开关apc.opcode_cache_enable, 这样一来, 用户就可以使用APC然而关闭opcode cache来达到这个目的, 但是APC的User Data Cache使用的存储机制是和Opcode Cache一样的, 这样的场景要求数据严格正确, 所以锁会比较多, 测试表明, APC的User Data Cache的效率和本地memcached几乎相当.

所以, 我想到了这个idea, 单独开发一个基于共享内存的, 高性能的User Data Cache

16 Oct 12 PDOStatement::bindParam的一个陷阱

废话不多说, 直接看代码:

<?php
$dbh = new PDO('mysql:host=localhost;dbname=test', "test");

$query = <<<QUERY
  INSERT INTO `user` (`username`, `password`) VALUES (:username, :password);
QUERY;
$statement = $dbh->prepare($query);

$bind_params = array(':username' => "laruence", ':password' => "weibo");
foreach( $bind_params as $key => $value ){
    $statement->bindParam($key, $value);
}
$statement->execute();

请问, 最终执行的SQL语句是什么, 上面的代码是否有什么问题?

15 Sep 12 Yar – 并行的RPC框架(Concurrent RPC framework)

Yar(yet another RPC framework, 教主问我为啥都是Ya打头, 呵呵, 因为这样名字好起)是我在3个多月前, 为了解决一个实际的问题, 而开发的一个PHP扩展的, RPC框架, 和现有的RPC框架(xml-rpc, soap)不同, 这是一个轻量级的框架, 支持多种打包协议(msgpack, json, php), 并且最重要的一个特点是, 它是可并行化的..

18 Feb 12 Taint-0.3.0(A XSS codes sniffer) released

最近几天忙里偷闲, 一直在完善taint, 今天我觉得终于算做到了80%的满意了, 根据80:20原则, 我觉得可以做为一个里程碑的版本了 :) .

什么是Taint? An extension used for detecting XSS codes(tainted string), And also can be used to spot sql injection vulnerabilities, shell inject, etc.

经过我实际测试, Taint-0.3.0能检测出实际的一些开源产品的(别问是什么)隐藏的XSS code, SQL注入, Shell注入等漏洞, 并且这些漏洞如果要用静态分析工具去排查, 将会非常困难, 比如对于如下的例子:

<?php
   $name = $_GET["name"];
   $value = strval($_GET["tainted"]);

   echo $$name;

对于请求:

http://****.com/?name=value&tainted=xxx

静态分析工具, 往往无能为力, 而Taint却可以准确无误的爆出这类型问题.

14 Feb 12 PHP Taint – 一个用来检测XSS/SQL/Shell注入漏洞的扩展

之前, 小顿和我提过一个想法, 就是从PHP语言层面去分析,找出一些可能的注入漏洞代码. 当时我一来没时间, 而来也确实不知道从何处下手..

直到上周的时候, 我看到了这个RFC: RFC:Taint.

但是这个RFC的问题在于, 它需要为PHP打Patch, 修改了PHP本身的数据结构, 这对于以后维护, 升级PHP来说, 很不方便, 也会有一些隐患.

虽然这样, 但这个RFC却给了我一个启发, 于是我就完成了这样的一个扩展:Taint Extension

08 Feb 12 PHP-5.3.9远程执行任意代码漏洞(CVE-2012-0830)

还记得我之前说的PHP Hash Collisions Ddos漏洞吧? 最初的时候, 开发组给出的修复方案, 采用的是如果超过max_input_vars, 就报错(E_ERROR), 继而导致PHP出错结束. 而后来, 为了更加轻量级的解决这个问题, 我们又改善了一下, 变成了如果超过max_input_vars, 就发出警告(E_WARNING), 并且不再往目的数组添加, 但是流程继续. 然后我们发布了5.3.9.

这个新的修复方法初衷是好的, 但是却带来一个严重的问题(5.3.10中已经修复), 这个问题最初是由Stefan Esser发现的. 请看之前(5.3.9)最终的修复方案(php_register_variable_ex):

30 Dec 11 PHP5.2.*防止Hash冲突拒绝服务攻击的Patch

由我前面的俩篇文章介绍(通过构造Hash冲突实现各种语言的拒绝服务攻击, PHP数组的Hash冲突实例 ), 这个攻击方法危害很高, 攻击成本也很小. 一个台式机可以轻松搞垮数十台, 上百台服务器.

而和Pierre沟通后, 官方开发组不会为此发布PHP 5.2.18, 但是目前还是由不少公司还在使用5.2, 所以我特将dmitry为5.4写的patch, 分别apply到5.2上.

大家如果有用5.2的, 如果被此类攻击威胁, 可以打上下面的patch, PHP5.3的, 可以考虑升级到5.3.9, 已经包含了此patch(因为5.3.9目前是RC状态, 所以如果不愿意升级, 也可以参照这个patch自己为5.3写一个):

https://github.com/laruence/laruence.github.com/tree/master/php-5.2-max-input-vars

另外, 其他语言java, ruby等, 请各位也预先想好对策, 限制post_size是治标不治本的方法, 不过可以用来做临时解决方案.

thanks

19 Dec 11 之前提到的PHP5.4一个注意点的update

在之前, 我曾经介绍过, 在PHP5.4中, PHP5.4中一个需要注意的变化(Chained string offsets) , 后续因为大多数人都表示这个变化很敏感, 容易成为坑.. 于是, 我们现在对此做了一些改进.

具体的改变是, 对于一个变量$a, 如果$a是一个字符串, 那么, 对于非数字型索引, 比如$a["foo"], 在isset的时候将返回false, empty返回true, 但是为了兼容已有的代码, 当你获取这个值的时候, 还是会返回$a[0], 不过会额外抛出一个警告信息. 比如:

<?php
$a = "laruence";
var_dump($a["foo"]) ; //PHP Warning:  Illegal string offset 'foo'
//output string(1) "l"

var_dump(isset($a["foo"]));
//false

var_dump(empty($a["foo"]));
//true

Pages: 1 2 3 4 5 6 7 8