模式对于OOP开发人员尤其有用,因为他有助于创建稳定的API,并且仍然保持一定的灵活度。一种模式可以帮助我们定义一个负责完成特定任务的对象,还可以允许我们彻底修改掉某个类而不用修改与这些类打交道的代码。前者被称为类的职责模式,后者被称为类的多态性模式。

单例模式被当作职责模式,单例模式用 来在应用程序中创建一个单一的功能访问点。它将创建对象的控制权委托到一个单一的访问点上。在任何时候,应用程序中都只会有这个类仅有的一个实例存在。这 可以防止我们去打开数据库的多个连接或者不必要得使用多余的系统资源。在更加复杂的系统中,使用单例模式在维持应用程序状态的同步方面也尤其有用。

所有的单例类至少拥有以下三种公共元素:

它们必须拥有一个构造函数,并且必须被标记为private。
它们拥有一个保存类的实例的静态成员变量。
它们拥有一个访问这个实例的公共的静态方法

和普通类不同的是,单例类不能在其他类中直接实例化。单例类只能被其自身实例化。要获得这样的一种结果, __construct()方法必须被标记为private。如果试图用private构造函数构造一个类,就会得到一个可访问性级别的错误。

要让单例类起作用,就必须让其为其他类提供一个实例,用它调用各种方法。单例类并不会创建实例副本,而是会向单例类内部存储的实例返回一个引用。结 果是单例类不会重复占用内存和系统资源,从而让应用程序的其它部分更好地使用这些资源。作为这一模式的一部分,必须创建一个空的私有__clone()方 法,以防止对象被复制或克隆。

返回实例引用的这个方法通常被命名为getTnstance()。这个方法必须是静态的,而且如果它还没有实例化,就必须进行实例化。getInstance() 方法通过使用 instanceof 操作符和self 关键字,可以检测到类是否已经被实例化。


   /* 例子:数据库连接职责的集中控制 */ class Database 
   {
       private $_db;
       static $_instance;
    
       private function __construct() 
       {
           $this->_db = pg_connect('dbname=example_db');
       } 
    
       private __clone() 
       {
       };
    
       public static function getInstance() 
       {
           if( !(self::$_instance instanceof self) ) 
           {
               self::$_instance = new self();
           }
           return self::$_instance;
       }
    
       public function query($sql) 
       {
           // 使用 $this->_db 执行一个查询
           return pg_query($this->_db, $sql);
       }
   }

这个例子一开始声明了两个变量:一个实例变量 $_db, 构造对象时这个变量的值会被填充;另一个变量是静态变量,这个变量会保存类仅有的一个实例。

接着是私有的 __construct() 和 __clone() 魔术方法。私有构造函数可以防止外部代码使用 new 操作符来创建对象。类似的。私有的 __clone() 方法消除了php语言中可以复制对象从而破坏单一职责的一个漏洞。

这之后的代码声明了 getInstance() 静态方法,这事单例模式的实际构造。这个方法最后返回实例的引用。

现在,你已经看到了如何声明单例类。但是应该如何使用他呢?例子如下:

$db = Database::getInstance();
$db->query('SELECT * FROM example_table ');

通过调用 getInstance() 方法,$db 现在存有内部存储实例的引用。通过这个实例,你可以调用单例类中定义的任何非静态方法。

如果这个类不需要使用 __construct() 方法,那么这个类就不大适合使用单例模式。在这种情况下,应该使用纯静态类。你只需要提供一个没有函数体的私有构造函数,并且去掉 getInstance() 和 $_instance 成员就可以做到这一点。这会防止类被实例化。它通过消除使用这段代码时获得实例的可能性确保了单一职责性。

例子如下:


    class SomeClass 
    {
        //防止类被当作实例使用
        private function __construct() 
        {
        }
        public static function SomeMethod() 
        {
            //执行一些操作
        }
    }

[HTTPS-3.jpg]

HTTP Strict Transport Security (通常简称为HSTS) 是一个安全功能,它告诉浏览器只能通过HTTPS访问当前资源, 禁止HTTP方式。

0×01. Freebuf百科:什么是Strict-Transport-Security

我摘自owasp上的一段定义:

HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.
The specification has been released and published end of 2012 as RFC 6797 (HTTP Strict Transport Security (HSTS)) by the IETF. (Reference see in the links at the bottom.)

一个网站接受一个HTTP的请求,然后跳转到HTTPS,用户可能在开始跳转前,通过没有加密的方式和服务器对话,比如,用户输入http://foo.com或者直接foo.com。这样存在中间人攻击潜在威胁,跳转过程可能被恶意网站利用来直接接触用户信息,而不是原来的加密信息。网站通过HTTP Strict Transport Security通知浏览器,这个网站禁止使用HTTP方式加载,浏览器应该自动把所有尝试使用HTTP的请求自动替换为HTTPS请求。

0×02. 我们为什么需要开启Strict-Transport-Security

想想这样一种场景:

有的网站开启了https,但为了照顾用户的使用体验(因为用户总是很赖的,一般不会主动键入https,而是直接输入域名, 直接输入域名访问,默认就是http访问)同时也支持http访问,当用户http访问的时候,就会返回给用户一个302重定向,重定向到https的地址,然后后续的访问都使用https传输,这种通信模式看起来貌似没有问题,但细致分析,就会发现种通信模式也存在一个风险,那就是这个302重定向可能会被劫持篡改,如果被改成一个恶意的或者钓鱼的https站点,然后,你懂得,一旦落入钓鱼站点,数据还有安全可言吗?

对于篡改302的攻击,建议服务器开启HTTP Strict Transport Security功能,这个功能的含义是:

当用户已经安全的登录开启过htst功能的网站 (支持hsts功能的站点会在响应头中插入:Strict-Transport-Security) 之后,支持htst的浏览器(比如chrome. firefox)会自动将这个域名加入到HSTS列表,下次即使用户使用http访问这个网站,支持htst功能的浏览器就会自动发送https请求(前提是用户没有清空缓存,如果清空了缓存第一次访问还是明文,后续浏览器接收到服务器响应头中的Strict-Transport-Security,就会把域名加入到hsts缓存中,然后才会在发送请求前将http内部转换成https),而不是先发送http,然后重定向到https,这样就能避免中途的302重定向URL被篡改。进一步提高通信的安全性。

上面是我自己的理解,下面是owasp中文站点关于hsts的描述:

HSTS的作用是强制客户端(如浏览器)使用HTTPS与服务器创建连接。服务器开启HSTS的方法是,当客户端通过HTTPS发出请求时,在服务器返回的超文本传输协议响应头中包含Strict-Transport-Security字段。非加密传输时设置的HSTS字段无效。

比如,https://example.com/ 的响应头含有Strict-Transport-Security: max-age=31536000; includeSubDomains。这意味着两点:

在接下来的一年(即31536000秒)中,浏览器只要向example.com或其子域名发送HTTP请求时,必须采用HTTPS来发起连接。比如,用户点击超链接或在地址栏输入 http://www.example.com/ ,浏览器应当自动将 http 转写成 https,然后直接向 https://www.example.com/ 发送请求。

在接下来的一年中,如果 example.com 服务器发送的TLS证书无效,用户不能忽略浏览器警告继续访问网站。

HSTS可以用来抵御SSL剥离攻击。SSL剥离攻击是中间人攻击的一种,由Moxie Marlinspike于2009年发明。他在当年的黑帽大会上发表的题为“New Tricks For Defeating SSL In Practice”的演讲中将这种攻击方式公开。SSL剥离的实施方法是阻止浏览器与服务器创建HTTPS连接。它的前提是用户很少直接在地址栏输入https://,用户总是通过点击链接或3xx重定向,从HTTP页面进入HTTPS页面。所以攻击者可以在用户访问HTTP页面时替换所有https://开头的链接为http://,达到阻止HTTPS的目的。

HSTS可以很大程度上解决SSL剥离攻击,因为只要浏览器曾经与服务器创建过一次安全连接,之后浏览器会强制使用HTTPS,即使链接被换成了HTTP

另外,如果中间人使用自己的自签名证书来进行攻击,浏览器会给出警告,但是许多用户会忽略警告。HSTS解决了这一问题,一旦服务器发送了HSTS字段,用户将不再允许忽略警告。

0×03. Strict-Transport-Security的一些不足

用户首次访问某网站是不受HSTS保护的。这是因为首次访问时,浏览器还未收到HSTS,所以仍有可能通过明文HTTP来访问。解决这个不足目前有两种方案,一是浏览器预置HSTS域名列表,Google Chrome、Firefox、Internet Explorer和Spartan实现了这一方案。二是将HSTS信息加入到域名系统记录中。但这需要保证DNS的安全性,也就是需要部署域名系统安全扩展。截至2014年这一方案没有大规模部署。

由于HSTS会在一定时间后失效(有效期由max-age指定),所以浏览器是否强制HSTS策略取决于当前系统时间。部分操作系统经常通过网络时间协议更新系统时间,如Ubuntu每次连接网络时,OS X Lion每隔9分钟会自动连接时间服务器。攻击者可以通过伪造NTP信息,设置错误时间来绕过HSTS。解决方法是认证NTP信息,或者禁止NTP大幅度增减时间。比如Windows 8每7天更新一次时间,并且要求每次NTP设置的时间与当前时间不得超过15小时

0×04. 我的一些测试

1). 测试1

目标域名:portal.fraudmetrix.cn (这个站点不支持hsts功能) 同盾科技的风险控制管理系统(打个软广,同盾科技,基于大数据,专注反欺诈)。

第一次访问:在浏览器地址栏键入:portal.fraudmetrix.cn

可以看到:

这个域名并不在chrome浏览器的hsts的缓存中,也不在hsts中的preload list中(像facebook、twitter等网站已经内置在preload list中,所以每次请求这些站点的时候浏览器都会自动将http 转换成htttps),所以不会在发送请求前将http转换成https请求。

我们来把这个站点手动加入到chrome浏览器的hsts缓存中:

在未清空chrome浏览器历史记录的前提下,我们再次访问这个站点:

可以看到,一个307 响应码,这是chrome浏览器的内部转换,将http转换成https后再发送请求。

备注:为什么我们要求在未清空chrome浏览器的缓存前访问呢?

因为如果清空了chrome浏览器的缓存之后,我们手动加入到hsts缓存中的域名就会被清除,也就不会看到预期的效果了。

2). 测试2

我们先清空chrome浏览器的缓存,然后在浏览器的地址栏中键入 www.alipay.com

可以看到www.alipay.com(支付宝)这个站点并没有在chrome 浏览器的内置的preload list中,所以第一次访问的时候,chrome浏览器并不会将http转换成https。

而是由前端的F5的负载均衡(BigIP)器将http请求重定向到https请求。

我们继续看看这次请求的其他响应:

可以看到支付宝站点服务器是支持hsts功能的,在其响应头中插入了:Strict-Transport-Security,并且设置这个头部的有效期,只要不手动清空缓存,那么在这个有效期内,chrome浏览器都会将所有发送这个站点的http请求在内部转换成https再发送出去。

浏览器在收到带有Strict-Transport-Security响应头的报文后,就会将这个站点加入到hsts缓存中,下次以http访问的时候就会被自动转换成https。

我们这时查看以下hsts的缓存中是不是有了 www.alipay.com

正如你所见:www.alipay.com已经被加入到了chrome浏览器的缓存中。

这时候在未清空浏览器缓存的前提下再次访问 www.alipay.com

看到了吧,熟悉的307响应码,浏览器做了内部转换,将http转换成https。

3). 其他

脸书www.facebook.com是已经加入到chrome浏览器hsts preload list中的。

注意到没,信息很详细哦!

看看我大百度呢?

清空chrome浏览器缓存,在地址栏键入www.baidu.com:

很遗憾,我大百度也不在chrome hsts preload list中。

在看看这次请求中的其他响应报文呢:

也没有看到 Strict-Transport-Security的影子。

*作者:wenjian_tk0,转于 http://www.freebuf.com/articles/web/66827.html

这两年Redis火得可以,Redis也常常被当作Memcached的挑战者被提到桌面上来。关于Redis与Memcached的比较更是比比皆是。然而,Redis真的在功能、性能以及内存使用效率上都超越了Memcached吗?

下面内容来自Redis作者在stackoverflow上的一个回答,对应的问题是《Is memcached a dinosaur in comparison to Redis?》(相比Redis,Memcached真的过时了吗?)

You should not care too much about performances. Redis is faster per core with small values, but memcached is able to use multiple cores with a single executable and TCP port without help from the client. Also memcached is faster with big values in the order of 100k. Redis recently improved a lot about big values (unstable branch) but still memcached is faster in this use case. The point here is: nor one or the other will likely going to be your bottleneck for the query-per-second they can deliver.

没有必要过多的关心性能,因为二者的性能都已经足够高了。由于Redis只使用单核,而Memcached可以使用多核,所以在比较上,平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中,Memcached性能要高于Redis,虽然Redis最近也在存储大数据的性能上进行优化,但是比起Memcached,还是稍有逊色。说了这么多,结论是,无论你使用哪一个,每秒处理请求的次数都不会成为瓶颈。(比如瓶颈可能会在网卡)

You should care about memory usage. For simple key-value pairs memcached is more memory efficient. If you use Redis hashes, Redis is more memory efficient. Depends on the use case.

如果要说内存使用效率,使用简单的key-value存储的话,Memcached的内存利用率更高,而如果Redis采用hash结构来做key-value存储,由于其组合式的压缩,其内存利用率会高于Memcached。当然,这和你的应用场景和数据特性有关。

You should care about persistence and replication, two features only available in Redis. Even if your goal is to build a cache it helps that after an upgrade or a reboot your data are still there.

如果你对数据持久化和数据同步有所要求,那么推荐你选择Redis,因为这两个特性Memcached都不具备。即使你只是希望在升级或者重启系统后缓存数据不会丢失,选择Redis也是明智的。

You should care about the kind of operations you need. In Redis there are a lot of complex operations, even just considering the caching use case, you often can do a lot more in a single operation, without requiring data to be processed client side (a lot of I/O is sometimes needed). This operations are often as fast as plain GET and SET. So if you don’t need just GEt/SET but more complex things Redis can help a lot (think at timeline caching).

当然,最后还得说到你的具体应用需求。Redis相比Memcached来说,拥有更多的数据结构和并支持更丰富的数据操作,通常在Memcached里,你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中,这些复杂的操作通常和一般的GET/SET一样高效。所以,如果你需要缓存能够支持更复杂的结构和操作,那么Redis会是不错的选择。

参考: http://ssdb.io/docs/install.html

第一步: 下载并编译安装

wget --no-check-certificate https://github.com/ideawu/ssdb/archive/master.zip
unzip master
cd ssdb-master
make
# optional, install ssdb in /usr/local/ssdb  // 默认
sudo make install

复制脚本

cd tools/
cp ssdb.sh /etc/init.d/ssdb
chmod u+x /etc/init.d/ssdb
chkconfig ssdb on            # for centos 
update-rc.d -f ssdb defaults # for ubuntu

配置

mkdir -p /data/ssdb/test/
cp ssdb.conf /data/ssdb/test/ssdb.conf
mkdir /data/ssdb_data/qinzi/var
vi /data/ssdb/test/ssdb.conf 
service ssdb start

测试

/usr/local/ssdb/ssdb-cli 
set 1 1
get 1

我在使用 Elasticsearch 进行search 查询的过程中,出现了 Result window is too large 问题。

这里简单做一个报错复现:

In [1]: import requests
In [2]: requests.get('http://127.0.0.1:9200/cmdb-now/_search?page=1&size=10000000').json()
Out[2]:
{u'error': {u'failed_shards': [{u'index': u'cmdb-now',
    u'node': u'ldeZMZRAR6uZpAiIr5QxBQ',
    u'reason': {u'reason': u'Result window is too large, from + size must be less than or equal to: [10000] but was [10000000]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level parameter.',
     u'type': u'query_phase_execution_exception'},
    u'shard': 0}],
  u'grouped': True,
  u'phase': u'query',
  u'reason': u'all shards failed',
  u'root_cause': [{u'reason': u'Result window is too large, from + size must be less than or equal to: [10000] but was [10000000]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level parameter.',
    u'type': u'query_phase_execution_exception'}],
  u'type': u'search_phase_execution_exception'},
 u'status': 500}

从上面的报错信息,可以看到ES提示我结果窗口太大了,目前最大值为10000,而我却要求给我10000000。并且在后面也提到了要求我修改index.max_result_window参数来增大结果窗口大小。

我google了修改方法,命令如下:

curl -XPUT http://127.0.0.1:9200/cmdb-now/_settings -d '{ "index" : { "max_result_window" : 100000000}}'

cmdb-now 是我ES索引的名字。

有关官方针对 index 的相关配置介绍,可以点击这里进行查看。