原文:http://www.oschina.net/translate/the-road-to-500k-qps-with-mysql-5-7
英文:http://dimitrik.free.fr/blog/archives/2013/10/mysql-performance-the-road-to-500k-qps-with-mysql-57.html


本文提供 MySql5.7实现每秒50W查询 一文的细节以及基准测试结果,解释了我早期在Mysql Connect 发表的谈话。

回顾 MySQL / InnoDB 的改善历史。你能很容易发现。在MySQL 5.6稳定版本中从来没有read-only 这么快的提速,它很容易搞懂,以及在read-only(RO)有着良好的扩张性。也很期待它在read+write(RW)上达到一个较高水平。(特别是在读取数据是数据库主要工作的时候)


然而。我们对于RO在 MySQL 5.6的表现也十分的高兴,在5.7这个版本中,主要工作集中在 read+write (RW)上, 因为在大数据的处理上还没能达到我们的期望。但是RW依赖RO下。能够再次提高速度。 InnoDB 团队通过不断的改进,强烈的推进优化着5.7这个版本的每秒的性能。 

GRPC是一个高性能、开源、通用的RPC框架,面向移动和HTTP/2设计,是由谷歌发布的首款基于Protocol Buffers的RPC框架。


目前提供C、Java和Go语言版本,这三个版本的源码全都托管在Github上,分别是:grpcgrpc-javagrpc-go。其中C版本支持CC++Node.jsPythonRubyObjective-CPHP 和 C#

GRPC基于HTTP/2标准设计,带来诸如双向流、流控、头部压缩、单TCP连接上的多复用请求等特性。这些特性使得其在移动设备上表现更好,更省电和节省空间占用。Protocol Buffers简称protobuf是Google公司开发的一种数据描述语言,类似于XML能够将结构化数据序列化,可用于数据存储、通信协议等方面。它不依赖于语言和平台并且可扩展性极强。现阶段官方支持C++、JAVA、Python等三种编程语言,但可以找到大量的几乎涵盖所有语言的第三方拓展包。

Docker的价值和应用场景分析

[不指定 2015/02/28 16:36 | by ipaddr ]

近年来,Docker在IT界可谓风光十足,各大技术论坛上赚足了眼球,公司内外也有相当多的介绍和尝试;看上去如此高大上的技术,貌似会给云时代、服务部署、运维等领域带来颠覆性的创新;

近期查阅了一些文档,较深入的了解Docker的技术细节,发现Docker确实在解决部分需求时恰到好处,但也绝对不是无所不能的万金油;

(http://www.iamadmin.com/, tomzhou 原创, 转载请注明.)

一、什么是Docker

官方定义:
Develop, Ship and Run Any Application, Anywhere

Docker is a platform for developers and sysadmins to develop, ship, and run applications. Docker lets you quickly assemble applications from components and eliminates the friction that can come when shipping code. Docker lets you get your code tested and deployed into production as fast as possible.


解读:

  • 官方把Docker定义为应用打包、部署的平台;而不是虚拟化技术;
  • Docker本身并没有革命性的创新,其核心是Container,Container是很多年前就提出来的理念,并且在Linux, Unix, FreeBSD上都有技术实现,Linux成熟的方案是lxc;
  • Docker是一个基于lxc(linux container),以及cgroup的上层工具;通过对lxc,cgroup及相关系统命令的封装,使得用户可以非常方便的使用Linux Container;
  • Docker Hub提供了应用包的版本管理和分发能力;

二、Docker的价值及同类技术对比

Container的核心价值在于隔离性和封装性,在这两方面也有较多类似解决方案,简单分析和对比一下:

1. 隔离性

Docker的隔离性是通过Container来实现的,并且是基于Lxc;与此相对应的另外一个解决方案是虚拟化;两者对比如下:

优点:

  • 非常轻量
    • 与创建或启动一个虚拟机相比,Container可以认为没啥开销,约等于Linux下创建一个进程;
    • 有个夸张的说法:单机可以轻易的启动多达上千个Container,但基本不太可能启动上千个虚拟机;
    • 但这比较的前提是需要在单机上隔离1000个应用;如果只需隔离两个应用,每个应用运行500个进程的话,对比应该是两个Container与两个VM;

缺点:

  • 隔离层次高
    • docker在Linux kernel之上进行隔离,确切的讲是进程间的隔离,这就决定了:
    • 1. Docker只支持64位Linux,必然不支持windows, unix, bsd...,而虚拟化可支持所有主流操作系统;
    • 2. Docker隔离在kernel之上,并且本身依赖于kernel的特性,所以只能模拟出高版本的Linux发行版;必然找不到ubuntu 9.04这样的image;
    • 3. Container使用的Kernel与主机的Kernel是一致的,无法定制Container的内核;
  • 硬件资源度量和配额能力
    • 通过cgroup,Docker具备一定的能力控制Container的资源使用,但在网络、磁盘、CPU的使用上,度量和隔离能力还没有VM成熟;
    • 此外,从用户角度来看,VM可以做到非常透明,可以直接理解为一台主机;但Container在网络连接、数据存储方面都需要经过特殊处理;


所以,与虚拟化相比,从隔离性上看,Docker的优势在于性能损耗低,劣势在于隔离层次比较高;
如果你的需求在是单机上进行尽可能多的隔离,那Docker是首选;
如果你的需求是尽可能彻底的隔离,对硬件资源精准控制且可度量,同时对隔离份数要求不多的话,那虚拟化是首选;

2. 封装性

从Docker的Logo以及官方的定义来看,它的主要能力并不在隔离性,而在于封装性,也就是应用的打包、部署、运行;


在封装方面的优势,主要体现在:

  • 封装大小
    • 与VM相比,Docker的image确实很小,官方的Centos image大概只有220M(被精减成最基本的Centos了,连ifconfig命令都没有,安装完常用工具,你会发现也不小了);
  • 可对应用高度定制和封装
    • 可通过Dockerfile定义应用包,Image内的部署可高度定制和封装,对外接口收敛且清晰;使用者无需关注细节;
  • Image仓库及版本管理
    • 非常成熟的公共和私有仓库搭建和使用,以及版本管理,并可通地仓库很容易的进行共享、分发、部署;
  • 应用和运行分离
    • 我们所看到的Image是静止的,只读的;将image运行起来后是Container了,在运行时的修改,只影响当前Container,不影响Image;

从上面可以看出,与VM Image的部署能力相比,Docker设计理念先进,优势明显,而且几乎没有啥缺点;

但从封装部署角度来看,Docker的竞品应该不是VM,而是RPM+YUM,DEB+APT这样的组合;
你会发现,与这两组合相比,能力出奇的相似了;但还是有些区别:

  • 封装能力:
    • Docker的Image,可以轻易实现在Centos上面跑Ubuntu,而且非常轻量,这个是Rpm,Deb不具备的;
    • 这个在一些测试、学习、或小规模的Paas场景下,是非常有价值的;
    • 但任何较大规模的应用,我想不太可能出现这样的部署;
  • 封装粒度及依赖管理:
    • Docker自kernel之上,全打包在一块了,里面包含了Linux用户环境、系统类库、应用程序;可以理解为,一个Docker Image的外部依赖只有Linux Kernel了;从另外一方面看,极大提升了移植能力;
    • Rpm、Deb的打包粒度比Docker更细,只打包单个应用自身,外部依赖通过只记录并不存储在包内,通过apt,yum这样的辅助工具也非常容易解决外部依赖;这样做的好处在于更轻量,理论上包大小肯定小于Docker;在大规模业务部署下,上千台设备发布20M的RPM,与发布200M的Docker image,效率上的差距应该还是比较大的;
    • 实际应用当中,在解决外部依赖问题上,C/C++程序还可以简单的通过静态链接来实现;Java/PHP/GoLang这类程序基本不存在系统类库的依赖,跨平台的能力也胜过Docker本身;
  • 跨平台:
    • 在各大Linux发行版下,你都可以按相同的方式使用Docker来管理打包及部署;但Rpm,Deb都有自己的粉丝和发行版本,在发行版间不通用;
    • 但Docker自身的学习和部署成本,要高于Rpm,Deb;

所以,从封装性看,Docker远胜于VM,与Rpm+Yum&Deb+Apt能力相当,从用户角度来看是多了一个选择;

抛开隔离性,假设你需要在单机上运行一个MySQL,你是希望安装Docker、再用Docker来部署MySQL?还是直接yum install mysql?

综合来看,Docker的核心价值就在于隔离性和封装性,并在两者间有个很好的平衡和兼顾,可预见的是在小规模的Paas领域是最好的解决方案;


三、Docker在公司内应用的思考

前面讲到Docker的核心价值在于隔离性和封装性,讨论Docker在公司内业务的应用也应该从这两个方面来看;

哪些场景可以用到隔离性:

  1. 研发测试流程,单机多版本并行部署和运行;
  2. 公司内部的类Paas服务,比如TDW计算、蓝鲸;
  3. 海量服务的正式环境,基本单个服务就能跑满单机,可以说完全没有隔离性需求;

哪些场景用到封装性:

公司所有业务都需要打包部署,但各大业务都已经有非常成熟的包发布系统;整合研发、编译、测试、发布以及架构、配置、路由等各方面的能力;推倒现有包发布系统,基于Docker重构的话,开发和用户学习成本相当高,但技术上并没有明显价值;

如果是全新开发的技术框架和运维体系的话,Docker会是一个较好的选择;但个人更倾向于Centos+Yum+RPM的组合;


四、其它

GoLang大放异彩

GoLang相比于传统语言,在设计上有如C->Java的跨越,而且在性能及部署上更为优秀;
之前在了解的过程中,惊叹此语言的各种内置功能和高级特性,料想在主流开发语言中必然占有一席之地,如今从docker及周边的组件来看,golang应用已是遍地开发;

基础运营环境更新工作任重道远

安装Docker需要Linux Kernel版本至少3.8+, 目前公司最新版的Tlinux 1.2的内核版本为2.6.32,加上公司对内核的管控,短时间内不太可能在正式环境大规模应用Docker;

IT技术日新月异,新技术和组件层出不穷,类似Docker之类的使用势必要求基础运营环境与业界保持同步更新;

但实际情况是公司主流的操作系统Suse10发布已经快十年了,正在更新的Tlinux1.2发布也有三年多了,覆盖率应该未达到50%;仍能在一些老业务上看到slockware的机器;

为了能保持与业界同步,技术团队仍需花费巨大精力投入到无任何业务产出的工作当中;

Centmin Mod

[不指定 2014/12/10 16:42 | by ipaddr ]

http://centminmod.com/

What is Centmin Mod ?

Centmin Mod - LEMP (Linux, Nginx, MariaDB MySQL & PHP-FPM) web stack for CentOS 6.x Linux (also Oracle Linux 6.x and CentOS 7 soon) byGeorge Liu (eva2000) with a shell menu based installer (shown on the right). The shell based menu allows you to do basic Nginx & PHP related management including upgrading or downgrading Nginx & PHP or setting upNginx vhosts. Centmin Mod auto installs Nginx server along with the following software:

Linux上MySQL优化三板斧

[不指定 2014/12/08 11:31 | by ipaddr ]

原文: http://www.woqutech.com/?p=1200

现在MySQL运行的大部分环境都是在Linux上的,如何在Linux操作系统上根据MySQL进行优化,我们这里给出一些通用简单的策略。这些方法都有助于改进MySQL的性能。
闲话少说,进入正题。

一、CPU

首先从CPU说起。
你仔细检查的话,有些服务器上会有的一个有趣的现象:你cat /proc/cpuinfo时,会发现CPU的频率竟然跟它标称的频率不一样:

    #cat /proc/cpuinfo      processor : 5     model name : Intel(R) Xeon(R) CPU E5-2620 0 @2.00GHz     ...     cpu MHz : 1200.000

这个是Intel E5-2620的CPU,他是2.00G * 24的CPU,但是,我们发现第5颗CPU的频率为1.2G。
这是什么原因列?
这些其实都源于CPU最新的技术:节能模式。操作系统和CPU硬件配合,系统不繁忙的时候,为了节约电能和降低温度,它会将CPU降频。这对环保人士和抵制地球变暖来说是一个福音,但是对MySQL来说,可能是一个灾难。
为了保证MySQL能够充分利用CPU的资源,建议设置CPU为最大性能模式。这个设置可以在BIOS和操作系统中设置,当然,在BIOS中设置该选项更好,更彻底。由于各种BIOS类型的区别,设置为CPU为最大性能模式千差万别,我们这里就不具体展示怎么设置了。

 

二、内存

然后我们看看内存方面,我们有哪些可以优化的。

i)我们先看看numa
非一致存储访问结构 (NUMA : Non-Uniform Memory Access) 也是最新的内存管理技术。它和对称多处理器结构 (SMP : Symmetric Multi-Processor) 是对应的。简单的队别如下:

Smp numa

如图所示,详细的NUMA信息我们这里不介绍了。但是我们可以直观的看到:SMP访问内存的都是代价都是一样的;但是在NUMA架构下,本地内存的访问和非本地内存的访问代价是不一样的。对应的根据这个特性,操作系统上,我们可以设置进程的内存分配方式。目前支持的方式包括:

 

--interleave=nodes
--membind=nodes
--cpunodebind=nodes
--physcpubind=cpus
--localalloc
--preferred=node

简而言之,就是说,你可以指定内存在本地分配,在某几个CPU节点分配或者轮询分配。除非是设置为--interleave=nodes轮询分配方式,即内存可以在任意NUMA节点上分配这种方式以外。其他的方式就算其他NUMA节点上还有内存剩余,Linux也不会把剩余的内存分配给这个进程,而是采用SWAP的方式来获得内存。有经验的系统管理员或者DBA都知道SWAP导致的数据库性能下降有多么坑爹。
所以最简单的方法,还是关闭掉这个特性。
关闭特性的方法,分别有:可以从BIOS,操作系统,启动进程时临时关闭这个特性。
a)由于各种BIOS类型的区别,如何关闭NUMA千差万别,我们这里就不具体展示怎么设置了。
b)在操作系统中关闭,可以直接在/etc/grub.conf的kernel行最后添加numa=off,如下所示:

kernel /vmlinuz-2.6.32-220.el6.x86_64 ro root=/dev/mapper/VolGroup-root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=VolGroup/root rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto rd_LVM_LV=VolGroup/swap rhgb crashkernel=auto quiet KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM  numa=off  

另外可以设置 vm.zone_reclaim_mode=0尽量回收内存。
c)启动MySQL的时候,关闭NUMA特性:
  numactl --interleave=all  mysqld &

 

当然,最好的方式是在BIOS中关闭。

 

ii)我们再看看vm.swappiness。

vm.swappiness是操作系统控制物理内存交换出去的策略。它允许的值是一个百分比的值,最小为0,最大运行100,该值默认为60。vm.swappiness设置为0表示尽量少swap,100表示尽量将inactive的内存页交换出去。
具体的说:当内存基本用满的时候,系统会根据这个参数来判断是把内存中很少用到的inactive 内存交换出去,还是释放数据的cache。cache中缓存着从磁盘读出来的数据,根据程序的局部性原理,这些数据有可能在接下来又要被读取;inactive 内存顾名思义,就是那些被应用程序映射着,但是“长时间”不用的内存。
我们可以利用vmstat看到inactive的内存的数量:

#vmstat -an 1 
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free inact active si so bi bo in cs us sy id wa st
1 0 0 27522384 326928 1704644 0 0 0 153 11 10 0 0 100 0 0
0 0 0 27523300 326936 1704164 0 0 0 74 784 590 0 0 100 0 0
0 0 0 27523656 326936 1704692 0 0 8 8 439 1686 0 0 100 0 0
0 0 0 27524300 326916 1703412 0 0 4 52 198 262 0 0 100 0 0

 

通过/proc/meminfo 你可以看到更详细的信息:

#cat /proc/meminfo | grep -i inact 
Inactive: 326972 kB
Inactive(anon): 248 kB
Inactive(file): 326724 kB

 

这里我们对不活跃inactive内存进一步深入讨论。Linux中,内存可能处于三种状态:free,active和inactive。众所周知,Linux Kernel在内部维护了很多LRU列表用来管理内存,比如LRU_INACTIVE_ANON, LRU_ACTIVE_ANON, LRU_INACTIVE_FILE , LRU_ACTIVE_FILE, LRU_UNEVICTABLE。其中LRU_INACTIVE_ANON, LRU_ACTIVE_ANON用来管理匿名页,LRU_INACTIVE_FILE , LRU_ACTIVE_FILE用来管理page caches页缓存。系统内核会根据内存页的访问情况,不定时的将活跃active内存被移到inactive列表中,这些inactive的内存可以被交换到swap中去。
一般来说,MySQL,特别是InnoDB管理内存缓存,它占用的内存比较多,不经常访问的内存也会不少,这些内存如果被Linux错误的交换出去了,将浪费很多CPU和IO资源。 InnoDB自己管理缓存,cache的文件数据来说占用了内存,对InnoDB几乎没有任何好处。
所以,我们在MySQL的服务器上最好设置vm.swappiness=0。

我们可以通过在sysctl.conf中添加一行:

echo "vm.swappiness = 0" >>/etc/sysctl.conf

 

并使用sysctl -p来使得该参数生效。

 

三、文件系统

最后,我们看一下文件系统的优化
i)我们建议在文件系统的mount参数上加上noatime,nobarrier两个选项。

用noatime mount的话,文件系统在程序访问对应的文件或者文件夹时,不会更新对应的access time。一般来说,Linux会给文件记录了三个时间,change time, modify time和access time。
我们可以通过stat来查看文件的三个时间:

stat libnids-1.16.tar.gz 
File: `libnids-1.16.tar.gz'
Size: 72309 Blocks: 152 IO Block: 4096 regular file
Device: 302h/770d Inode: 4113144 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access : 2008-05-27 15:13:03.000000000 +0800
Modify: 2004-03-10 12:25:09.000000000 +0800
Change: 2008-05-27 14:18:18.000000000 +0800

 

其中access time指文件最后一次被读取的时间,modify time指的是文件的文本内容最后发生变化的时间,change time指的是文件的inode最后发生变化(比如位置、用户属性、组属性等)的时间。一般来说,文件都是读多写少,而且我们也很少关心某一个文件最近什么时间被访问了。
所以,我们建议采用noatime选项,这样文件系统不记录access time,避免浪费资源。
现在的很多文件系统会在数据提交时强制底层设备刷新cache,避免数据丢失,称之为write barriers。但是,其实我们数据库服务器底层存储设备要么采用RAID卡,RAID卡本身的电池可以掉电保护;要么采用Flash卡,它也有自我保护机制,保证数据不会丢失。所以我们可以安全的使用nobarrier挂载文件系统。设置方法如下:
对于ext3, ext4和 reiserfs文件系统可以在mount时指定barrier=0;对于xfs可以指定nobarrier选项。

 

ii)文件系统上还有一个提高IO的优化万能钥匙,那就是deadline。

在Flash技术之前,我们都是使用机械磁盘存储数据的,机械磁盘的寻道时间是影响它速度的最重要因素,直接导致它的每秒可做的IO(IOPS)非常有限,为了尽量排序和合并多个请求,以达到一次寻道能够满足多次IO请求的目的,Linux文件系统设计了多种IO调度策略,已适用各种场景和存储设备。
Linux的IO调度策略包括:Deadline scheduler,Anticipatory scheduler,Completely Fair Queuing(CFQ),NOOP。每种调度策略的详细调度方式我们这里不详细描述,这里我们主要介绍CFQ和Deadline,CFQ是Linux内核2.6.18之后的默认调度策略,它声称对每一个 IO 请求都是公平的,这种调度策略对大部分应用都是适用的。但是如果数据库有两个请求,一个请求3次IO,一个请求10000次IO,由于绝对公平,3次IO的这个请求都需要跟其他10000个IO请求竞争,可能要等待上千个IO完成才能返回,导致它的响应时间非常慢。并且如果在处理的过程中,又有很多IO请求陆续发送过来,部分IO请求甚至可能一直无法得到调度被“饿死”。而deadline兼顾到一个请求不会在队列中等待太久导致饿死,对数据库这种应用来说更加适用。
实时设置,我们可以通过

echo deadline >/sys/block/sda/queue/scheduler

 

来将sda的调度策略设置为deadline。

我们也可以直接在/etc/grub.conf的kernel行最后添加elevator=deadline来永久生效。

 

 

总结

CPU方面
    关闭电源保护模式

内存:
    vm.swappiness = 0
    关闭numa

文件系统:
    用noatime,nobarrier挂载系统
    IO调度策略修改为deadline。

 

参考文档:
http://www.gentoo-wiki.info/FAQ_Linux_Memory_Management
http://bbs.gfan.com/android-4165836-1-1.html
https://wiki.archlinux.org/index.php/CPU_Frequency_Scaling_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87)
http://www.mysqlperformanceblog.com/2013/12/07/linux-performance-tuning-tips-mysql/ 

SSL Server Test

[不指定 2014/12/03 14:24 | by ipaddr ]

https://www.ssllabs.com/ssltest/index.html

This free online service performs a deep analysis of the configuration of any SSL web server on the public Internet.

推荐一个在线免费服务端SSL测试工具,可给HTTPS服务评级,并给出优化建议。

此外,还可用于客户端的SSL兼容性测试:

https://www.ssllabs.com/ssltest/viewMyClient.html


ProcessOn是一款专业作图人员的社交网络,这里汇聚很多业界专家、学者,同时他们分享的作品又形成一个庞大的知识图库,你在学习专业知识的同时还可以结交一些志同道合的新朋友。

ProcessOn核心设计器采用HTML5 canvas、JavaScript等技术完成,它跟Visio这类传统的软件最大的区别就是无需下载和安装,更不用激活,即开即用。操作起来极为方便和简单,你可以在浏览器中简单拖拖拽拽,即可完成作图,相当人性化,ProcessOn还支自动时保存和实时协作,通过HTML5独特的技术做到毫无延迟,允许多个用户同时对同一文件进行协作编辑和多人聊天。

随着时间推进和技术的发展,如今在线应用型产品越来越受关注和重视,这在一定程度上折射出互联网的发展趋势:WEB化和移动化,传统的软件必将在未来几年被WEB应用所替代,相信不久的将来也一定会出现更多在线版的传统软件。再延伸地去说,浏览器已经开始被赋予越来越重的责任和使命,想象一下现在所有的软件将来都会被“装进”浏览器中,这个趋势谁也改变不了。ProcessOn的崛起也必将在不久的将来取代现在传统专业作图工具的市场份额和地位!一个浏览器,一个窗口,全部搞定。

使用了一会,感觉很不错,期待会有数据相关展示控件,在我看来ProcessOn是一个动词,开始吧,On一下!

ProcessOn:www.ProcessOn.com

twemproxy (nutcracker) 介绍

[不指定 2014/07/21 11:28 | by ipaddr ]
twemproxy (pronounced "two-em-proxy"), aka nutcracker is a fast and lightweight proxy for memcached andredis protocol. It was primarily built to reduce the connection count on the backend caching servers.

https://github.com/twitter/twemproxy

Ipaddr注: twemproxy的目的不是为了提升性能、容灾,而是为了减少Redis/Memcached的连接数。

Features

  • Fast.
  • Lightweight.
  • Maintains persistent server connections.
  • Keeps connection count on the backend caching servers low.
  • Enables pipelining of requests and responses.
  • Supports proxying to multiple servers.
  • Supports multiple server pools simultaneously.
  • Shard data automatically across multiple servers.
  • Implements the complete memcached ascii and redis protocol.
  • Easy configuration of server pools through a YAML file.
  • Supports multiple hashing modes including consistent hashing and distribution.
  • Can be configured to disable nodes on failures.
  • Observability through stats exposed on stats monitoring port.
  • Works with Linux, *BSD, OS X and Solaris (SmartOS)
Server Name Indication是用来改善SSL(Secure Socket Layer)和TLS(Transport Layer Security)的一项特性。它允许客户端在服务器端向其发送证书之前请求服务器的域名。这对于在虚拟主机模式使用TLS是必要的。
TLS背景
加密一个面向流的通讯会话最常用的方法之一就是使用TLS协议。比如,当用户在浏览器的地址栏里面输入https时就是在使用这个协议。
为了确认用户想要连接的站点就是浏览器实际连接到的站点,TLS使用包含站点域名的数字签名证书。客户端软件(比如浏览器)通常信任这个证书,如果这个证书是由其内置信任的认证机构签发的。
在TLS启动阶段,客户端软件比较用户输入的URI的域名部分与在服务器证书里面找到的域名部分,如果比较失败,浏览器会提示用户,这个站点的证书存在问题。
缺点
SSL v2的设计顺应经典的公钥基础设施PKI(public key infrastructure)设计,后者认为一个服务器只提供一个服务从而也就只使用一个证书。这意味着服务器可以在TLS启动的早期阶段发送或提交证书,因为它知道它在为哪个域服务。
HTTP服务器开启虚拟主机支持后,每个服务器通过相同的地址可以为很多域提供服务。服务器检查每一个请求来决定它在为哪个域服务。这个信息通常从HTTP请求头获得。不幸的是,当设置了TLS加密,服务器在读取HTTP请求里面的域名之前已经向客户端提交了证书,也就是已经为默认域提供了服务。
因此,这种为虚拟主机提供安全的简单途径经常导致使用了错误的数字证书,从而导致浏览器对用户发出警告。
钓鱼连接
实际上,这意味着每一个HTTP服务器只能为一个域提供安全浏览。而事实上每一个web服务器都为很多域提供服务,结果就是其他的域无法使用安全通信,从而处于危险境地。此外,安全浏览的缺乏使浏览器无法认证服务器,亦即它无法校验站点是否真的是属于宣称它的那个人或实体。钓鱼的一个重要因素是他们企图通过虚假站点来获取用户的信息。使用SSL或者TLS安全连接,浏览器可以基于它的证书来认证站点。钓鱼站点不会作为一个欺骗性的站点得到认证,浏览器会警告这个安全风险。然而,没有安全HTTP就没有标准的方法去认证服务器,使这种钓鱼的企图很容易就能实现。
修正
一个叫做SNI的TLS扩展通过发送虚拟域的名字做为TSL协商的一部分修正了这个问题。这会使服务器更早的切换到正确的虚拟域,并且发送给浏览器包含正确名字的数字证书。
行动
在2005年,人们意识到从SSL v2到TLS没有很容易的升级路径,并且站点不得不升级他们的软件来。为了尽快的推进,Mozilla宣告完全抛弃对SSL v2的支持。Firefox社区确信其余的站点会升级他们的服务器到SSL v3或TLS v1。
从2005年开始,CAcert在虚拟服务器上用不同的方法使用TLS来进行试验,大部分试验是不满意并且不实际的。比如,可以使用subjectAltName在一个数字证书中包含多个域,但是这是一个证书,意味着所有的域必须被一个人拥有并控制,并且每次域列表发生变化,证书必须重新发放。
2004年,EdelKey project为OpenSSL里面的TLS/SNI开发了一个补丁。2006年这个补丁进入OpenSSL的开发分支,2007年,它被向后移植到了OpenSSL 0.9.8,也就是当前的发行版本。
支持状况
支持SNI的浏览器
* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (the TLS 1.1 protocol must be enabled)
* Internet Explorer 7 (Vista, not XP) or later
* Google Chrome (Vista, not XP)
* Safari 3.2.1 Mac OS X 10.5.6
支持SNI的服务器
* Apache 2.2.12 or later using mod_ssl (or alternatively with experimental mod_gnutls)
* Cherokee if compiled with TLS support
* Versions of lighttpd 1.4.x and 1.5.x with patch
* Nginx with an accompanying OpenSSL built with SNI support
* acWEB with OpenSSL 0.9.8j and later (on Windows)
支持SNI的库
* Mozilla NSS 3.11.1 client side only
* OpenSSL
0.9.8f (released 11 Oct 2007) – not compiled in by default, can be compiled in with config option ‘–enable-tlsext’.
0.9.8j (released 07 Jan 2009) – now compiled in by default
Unreleased 0.9.9 is likely to include SNI compiled in by default.
* GNU TLS
不支持SNI的操作系统,浏览器和库
客户端
* Windows XP and Internet Explorer
* Konqueror/KDE in any version
服务器端
* Microsoft Internet Information Server IIS (As of 2009).
* Qt
* Mozilla NSS server side
* Python
------------------------------------------
ipaddr注:
------------------------------------------
语言支持能力:
JavaSE 7+ & HttpClient 4.3.2+
PHP 5.3.2 + openssl 0.9.8f+
工具支持能力:
curl 7.18.1+ & openssl 0.9.8j+  
wget 1.14+ & openssl 0.9.8j+  
(单向认证的情况下,低版本curl可以通过-k参数来规避,低版本wget可以通过--no-check-certificate来规避,但双向认证只能升级新版本)
其它支持情况,请参考: http://en.wikipedia.org/wiki/Server_Name_Indication

Redis知识汇总[转]

[不指定 2014/07/15 19:41 | by ipaddr ]

https://github.com/springside/springside4/wiki/Redis


1. Overview
1.1 资料
    - <The Little Redis Book> ,最好的入门小册子,可以先于一切文档之前看,免费。
    - 作者Antirez的博客Antirez维护的Redis推特
    - Redis 命令中文版, huangz同学的翻译,同时还有Redis官网几篇重要文档的翻译。
    - Redis设计与实现 ,又是huangz同学的巨作,深入了解内部实现机制。
    - Redis 2.6源码中文注释版 ,继续是huangz同学的大功德。
    - NoSQL Fan里的Redis分类
    - 《Redis in Action》 (Manning, 2013) 挺实战的一本书。
1.2 优缺点

非常非常的快,有测评说比Memcached还快(当大家都是单CPU的时候),而且是无短板的快,读写都一般的快,所有API都差不多快,也没有MySQL Cluster、MongoDB那样更新同一条记录如Counter时慢下去的毛病。

丰富的数据结构,超越了一般的Key-Value数据库而被认为是一个数据结构服务器。组合各种结构,限制Redis用途的是你自己的想象力,作者自己捉刀写的用途入门

因为是个人作品,Redis2.6版只有2.3万行代码,Keep it simple的死硬做法,使得普通公司而不需淘宝那个级别的文艺公司也可以吃透它。 Redis宣言就是作者的自白,我最喜欢其中的“代码像首诗”,”设计是一场与复杂性的战斗“,“Coding是一件艰苦的事情,唯一的办法是享受它。如果它已不能带来快乐就停止它。为了防止这一天的出现,我们要尽量避免把Redis往乏味的路上带。”

让人又爱又恨的单线程架构,使得代码不用处理平时最让人头痛的并发而大幅简化,也不用老是担心作者的并发有没有写对,但也带来单CPU的瓶颈,而且单线程被慢操作所阻塞时,其他请求的延时变得不确定。

那Redis不是什么?

    - Redis 不是Big Data,数据都在内存中,无法以T为单位。
    - 在Redis 3.0的Redis-Cluster发布并被稳定使用之前,Redis没有真正的平滑水平扩展能力。
    - Redis 不支持Ad-Hoc Query,提供的只是数据结构的API,没有SQL一样的查询能力。
分页: 2/57 第一页 上页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]