商业源码 密码学HASH与对称加密
Hash，一般翻译做“散列”，也有直接音译为“哈希”的，就是把任意长度的输入通过散列算法变换成固定长度的输出，该输出就是散列值。这种转换是一种压缩映射，也就是，散列值的空间通常远小于输入的空间，不同的输入可能会散列成相同的输出，所以不可能从散列值来确定唯一的输入值。简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。
MD5信息摘要算法 （英语：MD5 Message-Digest Algorithm），一种被广泛使用的 密码散列函数 ，可以产生出一个128位（16 字节 ）的散列值（hash value），用于确保信息传输完整一致。2004年，证实MD5算法无法防止碰撞（collision）（如网站： CMD5 ），因此不适用于安全性认证，如 SSL 公开密钥认证或是 数字签名 等用途。
MD5 是哈希算法的一种。
密码加密常见的有以下几种方式：
HMAC是密钥相关的哈希运算消息认证码（Hash-based Message Authentication Code）的缩写，并在 IPSec 和其他网络协议（如 SSL ）中得以广泛应用，现在已经成为事实上的Internet安全标准。它可以与任何迭代散列函数捆绑使用。
如上图中，共有两个流程：
授权设备登录流程：
1、输入账号过后，就把账号作为参数向服务器发送请求
2、服务器根据账号生成对应的key，并传递给客户端
3、客户端拿到key，进行HMAC运算，并将运算结果的哈希值传给服务器
其他设备登录流程：
1、输入账号过后，在本地缓存中找服务器传过来的key，有就登录，没有就把账号作为参数向服务器发送请求
2、服务器要先看这个账号是否开启了设备锁，没有开启就不允许登录，开启了，就向授权设备发送请求，是否授权，如果授权，就将这个账号的key传给其他客户端
3、客户端拿到key，进行HMAC运算，并将运算结果的哈希值传给服务器
但是在这之中有一个潜在的安全隐患问题： 当别人拿到账号和传递的哈希值过后，也就能拿到登录权限，从而不安全。
为了防止上面的问题，注册流程不变，服务器还是保存的有加了key的HMAC哈希值。
1、只是登录的时候，客户端将哈希值与时间戳拼接过后，进行MD5加密，再传给服务器。
2、服务器将注册保存的账号对应的HMAC哈希值，分别与当前时间，和前一分钟拼接再MD5加密，再和客户端传过来的进行匹配，匹配成功则登录成功，否则不成功。
3、注意这里的时间戳是服务器给的时间戳。
常见的加密算法：
应用模式：
AES加密解密都是用到的CCCrypt函数，并且需要导入 CommonCrypto 框架。
哈希(Hash)算法,即散列函数。它是一种单向密码体制,即它是一个从明文到密文的不可逆的映射,只有加密过程,没有解密过程。同时,哈希函数可以将任意长度的输入经过变化以后得到固定长度的输出。哈希函数的这种单向特征和输出数据长度固定的特征使得它可以生成消息或者数据。
计算方法：
用来产生一些数据片段（例如消息或会话项）的哈希值的算法。使用好的哈希算法，在输入数据中所做的更改就可以更改结果哈希值中的所有位；因此，哈希对于检测数据对象（例如消息）中的修改很有用。此外，好的哈希算法使得构造两个相互独立且具有相同哈希的输入不能通过计算方法实现。典型的哈希算法包括 MD2、MD4、MD5 和 SHA-1。哈希算法也称为“哈希函数”。
另请参阅： 基于哈希的消息验证模式 (HMAC), MD2, MD4, MD5,消息摘要, 安全哈希算法 (SHA-1)
MD5一种符合工业标准的单向 128 位哈希方案，由 RSA Data Security, Inc 开发。 各种“点对点协议(PPP)”供应商都将它用于加密的身份验证。哈希方案是一种以结果唯一并且不能返回到其原始格式的方式来转换数据（如密码）的方法。质询握手身份验证协议(CHAP) 使用质询响应并在响应时使用单向 MD5哈希法。按照此方式，您无须通过网络发送密码就可以向服务器证明您知道密码。
质询握手身份验证协议(CHAP)“点对点协议(PPP)”连接的一种质询响应验证协议，在 RFC 1994 中有所描述。 该协议使用业界标准 MD5哈希算法来哈希质询串（由身份验证服务器所发布）和响应中的用户密码的组合。
点对点协议
用点对点链接来传送多协议数据报的行业标准协议套件。RFC 1661 中有关于 PPP 的文档。
另请参阅： 压缩控制协议 (CCP)，远程访问，征求意见文档 (RFC)，传输控制协议/Internet 协议 (TCP/IP)，自主隧道。
使用。
设定一个圆环上 0-2^3̂2-1 的点，每个点对应一个缓存区，每个键值对存储的位置也经哈希计算后对应到环上节点。但现实中不可能有如此多的节点，所以倘若键值对经哈希计算后对应的位置没有节点，那么顺时针找一个节点存储它。
1、考虑增加服务器节点的情况，该节点顺时针方向的数据仍然被存储到顺时针方向的节点上，但它逆时针方向的数据被存储到它自己。这时候只有部分数据会失效，被映射到新的缓存区。
2、考虑节点减少的情况。该缺失节点顺时针方向上的数据仍然被存储到其顺时针方向上的节点，设为 beta，其逆时针方向上的数据会被存储到 beta 上。同样，只有有部分数据失效，被重新映射到新的服务器节点。
扩展资料：
一致性哈希算法
这种方法可以应对节点失效的情况，当某个分布式集群节点宕机，服务请求可以通过hash算法重新分配到其他可用的服务器上。避免了无法处理请求的状况出现 。
但这种方法的缺陷也很明显，如果服务器中保存有服务请求对应的数据，那么如果重新计算请求的hash值，会造成大量的请求被重定位到不同的服务器而造成请求所要使用的数据失效，这种情况在分布式系统中是非常糟糕的。
一个设计良好的分布式系统应该具有良好的单调性，即服务器的添加与移除不会造成大量的哈希重定位，而一致性哈希恰好可以解决这个问题。
随着网络流量的增加，服务器开始面临繁重负载，这时就需要搭配一套HTTP负载均衡系统了，那么Linux下该如何配置HTTP负载均衡系统呢？随小编一起来学习一下吧。
如今对基于互联网的应用和服务的要求越来越大，这给广大的IT管理员施加了越来越大的压力。面对突如其来的流量猛增、自生的流量增加或者是内部挑战（比如硬件故障和紧急维护），不管怎样，你的互联网应用都必须保持随时可用。连现代化的开发运营和持续交付做法也会危及互联网服务的可靠性和一贯表现。
无法预测或缺乏一贯的表现是你所无法承受的。那么，我们如何能消除这些缺点呢？在大多数情况下，一套合适的负载均衡解决方案有望满足这个要求。今天我将为各位介绍如何使用HAProxy搭建一套HTTP负载均衡系统。
HTTP负载均衡简介
HTTP负载均衡是一种网络解决方案，负责在托管相同应用内容的几台服务器之间分配进入的HTTP或HTTPS流量。由于在多台可用服务器之间均衡了应用请求，负载均衡系统就能防止任何应用服务器变成单一故障点，因而提高了整体的应用可用性和响应能力。它还让你可以随着不断变化的工作负载，轻松地缩小/扩大部署的应用系统的规模，只需添加或删除额外的应用服务器。
哪里使用负载均衡、何时使用？
由于负载均衡系统改进了服务器的利用率，最大限度地提高了可用性，只要你的服务器开始面临繁重负载，或者正为一个较庞大的项目规划架构，就应该使用它。事先规划好负载均衡系统的用途是个好习惯。那样，未来你需要扩展环境规模时，它会证明其用途。
HAProxy是什么东东？
HAProxy是一种流行的开源负载均衡和代理系统，面向GNU/Linux平台上的TCP/HTTP服务器。HAProxy采用了单一线程的事件驱动型架构而设计，它能够轻松地处理10G网卡线路速度，现广泛应用于许多生产环境中。其功能特性包括：自动检查健康状况、可定制的负载均衡算法、支持HTTPS/SSL以及会话速率限制等。
我们在本教程中要达到什么样的目的？
在本教程中，我们将逐步介绍为HTTP网站服务器配置基于HAProxy的负载均衡系统这个过程。
前提条件
你至少需要一台（最好是两台）网站服务器来证实所搭建负载均衡系统的功能。我们假设，后端HTTP网站服务器已经搭建并运行起来。
将HAProxy安装到Linux上
就大多数发行版而言，我们可以使用你所用发行版的软件包管理器来安装HAProxy。
将HAProxy安装到Debian上
在Debian中，我们需要为Wheezy添加向后移植功能。为此，请在/etc/apt/sourceslistd中创建一个名为“backportslist”的新文件，其内容如下：
deb http://cdndebiannet/debian wheezybackports main
更新你的软件库数据，并安装HAProxy。
# apt get update # apt get install haproxy
将HAProxy安装到Ubuntu上
# apt get install haproxy
将HAProxy安装到CentOS和RHEL上
# yum install haproxy
配置HAProxy
在本教程中，我们假设有两台HTTP网站服务器已搭建并运行起来，其IP地址分别为1921681002和1921681003。我们还假设，负载均衡系统将在IP地址为1921681004的那台服务器处进行配置。
为了让HAProxy发挥功用，你需要更改/etc/haproxy/haproxycfg中的几个项目。这些变更在本章节中予以描述。万一某个配置对不同的GNU/Linux发行版而言有所不同，会在相应段落中加以注明。
1 配置日志功能
你首先要做的工作之一就是，为你的HAProxy建立合适的日志功能，这对将来进行调试大有用处。日志配置内容位于/etc/haproxy/haproxycfg的global部分。下面这些是针对特定发行版的指令，用于为HAProxy配置日志。
CentOS或RHEL：
要想在CentOS/RHEL上启用日志功能，把：
log 127001 local2
换成：
log 127001 local0
下一步，在/var/log中为HAProxy创建单独的日志文件。为此，我们需要改动当前的rsyslog配置。为了让配置简单而清楚，我们将在/etc/rsyslogd/中创建一个名为haproxyconf的新文件，其内容如下。
$ModLoad imudp $UDPServerRun 514 $template Haproxy，“%msg%/n” local0=info /var/log/haproxylog;Haproxy local0notice /var/log/haproxystatuslog;Haproxy local0 ~
该配置将把基于$template的所有HAProxy消息隔离到/var/log中的日志文件。现在，重启rsyslog，让变更内容生效。
# service rsyslog restart
Debian或Ubuntu：
要想在Debian或Ubuntu上为HAProxy启用日志功能，把：
log /dev/log local0 log /dev/log local1 notice
换成：
log 127001 local0
下一步，为HAProxy配置单独的日志文件，编辑/etc/rsyslogd/中一个名为haproxyconf的文件（或者Debian中的49-haproxyconf），其内容如下。
$ModLoad imudp $UDPServerRun 514 $template Haproxy，“%msg%/n” local0=info /var/log/haproxylog;Haproxy local0notice /var/log/haproxystatuslog;Haproxy local0 ~
该配置将把基于$template的所有HAProxy消息隔离到/var/log中的日志文件。现在，重启rsyslog，让变更内容生效。
# service rsyslog restart
2 设置默认值
下一步是为HAProxy设置默认变量。找到/etc/haproxy/haproxycfg中的defaults部分，把它换成下列配置。
log global mode http option httplog option dontlognull retries 3 option redispatch maxconn 20000 contimeout 5000 clitimeout 50000 srvtimeout 50000
上述配置推荐HTTP负载均衡器使用，但可能不是最适合你环境的解决方案。如果那样，请参阅HAProxy参考手册页，进行适当的改动和调整。
3 网站服务器集群的配置
网站服务器集群（Webfarm）的配置定义了可用的HTTP服务器集群。我们所建负载均衡系统的大部分设置都将放在这里。现在，我们将创建一些基本的配置，我们的节点将在这里加以定义。把从frontend部分到文件末尾的所有配置换成下列代码：
listen webfarm ：80 mode http stats enable stats uri /haproxy？stats stats realm Haproxy/ Statistics stats auth haproxy:stats balance roundrobin cookie LBN insert indirect nocache option httpclose option forwardfor server web01 1921681002:80 cookie node1 check server web02 1921681003:80 cookie node2 check
“listen webfarm ：80”这一行定义了我们的负载均衡系统将侦听哪些接口。出于本教程的需要，我将该值设为“”，这让负载均衡系统侦听我们的所有接口。在实际场景下，这可能不合意，应该换成可从互联网来访问的某个接口。
stats enable stats uri /haproxy？stats stats realm Haproxy/ Statistics stats auth haproxy:stats
上述设置声明，可以在http://《load-balancer-IP》/haproxy？stats处访问负载均衡系统的统计数字。这种访问由简单的HTTP验证以及登录名“haproxy”和密码“stats”来确保安全。这些设置应该换成你自己的登录信息。如果你不想让这些统计数字被人看到，那么可以完全禁用它们。
下面是HAProxy统计数字的一个例子。
“balance roundrobin”这一行定义了我们将使用哪种类型的负载均衡。在本教程中，我们将使用简单的轮叫调度算法，这对HTTP负载均衡来说完全绰绰有余。HAProxy还提供了其他类型的负载均衡：
•leastconn：连接数最少的服务器优先接收连接。
•source：对源IP地址进行哈希处理，用运行中服务器的总权重除以哈希值，即可决定哪台服务器将接收请求。
•uri：URI的左边部分（问号前面）经哈希处理，用运行中服务器的总权重除以哈希值。所得结果决定哪台服务器将接收请求。
•url_param：变量中指定的URL参数将在每个HTTP GET请求的查询串中进行查询。你基本上可以将使用蓄意制作的URL（crafted URL）的请求锁定于特定的负载均衡节点。
•hdr（name）：HTTP头《name》 将在每个HTTP请求中进行查询，被定向到特定节点。
“cookie LBN insert indirect nocache”这一行让我们的负载均衡系统存储持久性cookie，这让我们得以准确查明集群中的哪个节点用于某一个会话。这些节点cookie将与指定的名称一并存储起来。在我们这个例子中，我使用了“LBN”，但你可以指定自己喜欢的任意名称。节点将为该cookie把字符串作为一个值而存储起来。
server web01 1921681002:80 cookie node1 check server web02 1921681003:80 cookie node2 check
上述部分对网站服务器节点集群进行了定义。每台服务器都用内部名称（比如web01和web02）、IP地址和独特的cookie串来表示。cookie串可以定义为你需要的任何名称。我使用了简单的node1、node2 。。。 node（n）。
启动HAProxy
你完成了配置工作后，可以启动HAProxy，验证一切按预期运行。
在Centos/RHEL上启动HAProxy
使用下列指令，让HAProxy能够在系统启动后启动，并打开它：
# chkconfig haproxy on # service haproxy start
当然，别忘了启用防火墙中的端口80，如下所示。
CentOS/RHEL 7上的防火墙：
# firewallcmd permanent zone=public addport=80/tcp # firewallcmd reload
CentOS/RHEL 6上的防火墙：
把下面这一行添加到/etc/sysconfig/iptables中的这部分“：OUTPUT ACCEPT”：
A INPUT m state state NEW m tcp p tcp dport 80 j ACCEPT
然后重启iptables：
# service iptables restart
在Debian上启动HAProxy
使用下列指令启动HAProxy：
# service haproxy start
别忘了启用防火墙中的端口80，为此把下面这一行添加到/etc/iptablesuprules：
A INPUT p tcp dport 80 j ACCEPT
在Ubuntu上启动HAProxy
让HAProxy能够在系统启动后启动，只要在/etc/default/haproxy中将“ENABLED”选项设为“1”：
ENABLED=1
启动HAProxy：
# service haproxy start
然后启用防火墙中的端口80：
# ufw allow 80
测试HAProxy
为了检查HAproxy是否在正常工作，我们可以执行下列步骤：
首先，用下列内容准备好testphp文件：
《？php header（‘Content-Type： text/plain’）; echo “Server IP： ”。
该PHP文件将告诉我们哪台服务器（即负载均衡系统）转发请求，哪台后端网站服务器实际处理请求。
把该PHP文件放到这两台后端网站服务器的根目录下。现在，使用curl命令，从负载均衡系统（1921681004）提取这个PHP文件。
# chkconfig haproxy on # service haproxy start nbsp;curl http://1921681004/testphp
我们多次运行这个命令时，应该会看到下面两个输出交替出现（由于轮叫调度算法）。
Server IP： 1921681002
X-Forwarded-for： 1921681004
Server IP： 1921681003
X-Forwarded-for： 1921681004
如果我们停止这两台后端网站服务器中的其中一台，curl命令应该仍会执行，将请求定向到另一台可用的网站服务器。
结束语
至此，你应该有了一套完全实用的负载均衡系统，能够在轮叫循环模式下为你的网站节点提供请求。与往常一样，你可以随意更改配置，让它更适合自己的基础设施。希望本教程帮助你让自己的网站项目具有更强的抗压力和更高的可用性。
正如大家已经注意到的那样，本教程所含的设置适用于仅仅一套负载均衡系统。这意味着，我们把一个单一故障点换成了另一个单一故障点。在实际场景下，你应该部署至少两套或三套负载均衡系统，以防范可能出现的任何故障，但这不在本教程的讨论范围之内。
上面就是Linux系统下配置HTTP负载均衡系统的方法介绍了，这里主要使用的是HAProxy，且只介绍了配置一套负载均衡系统的方法，赶紧试试看吧。
ziplist 编码的哈希对象使用压缩列表作为底层实现， 每当有新的键值对要加入到哈希对象时， 程序会先将保存了键的压缩列表节点推入到压缩列表表尾， 然后再将保存了值的压缩列表节点推入到压缩列表表尾， 因此：
保存了同一键值对的两个节点总是紧挨在一起， 保存键的节点在前， 保存值的节点在后；
先添加到哈希对象中的键值对会被放在压缩列表的表头方向， 而后来添加到哈希对象中的键值对会被放在压缩列表的表尾方向。
举个例子， 如果我们执行以下 HSET 命令， 那么服务器将创建一个列表对象作为 profile 键的值：
另一方面， hashtable 编码的哈希对象使用字典作为底层实现， 哈希对象中的每个键值对都使用一个字典键值对来保存：
Redis 的字典使用哈希表作为底层实现， 一个哈希表里面可以有多个哈希表节点， 而每个哈希表节点就保存了字典中的一个键值对。
Redis 字典所使用的哈希表由 dicth/dictht 结构定义：
table 属性是一个数组， 数组中的每个元素都是一个指向 dicth/dictEntry 结构的指针， 每个 dictEntry 结构保存着一个键值对。
size 属性记录了哈希表的大小， 也即是 table 数组的大小， 而 used 属性则记录了哈希表目前已有节点（键值对）的数量。
sizemask 属性的值总是等于 size - 1 ， 这个属性和哈希值一起决定一个键应该被放到 table 数组的哪个索引上面。
图 4-1 展示了一个大小为 4 的空哈希表 （没有包含任何键值对）。
哈希表节点使用 dictEntry 结构表示， 每个 dictEntry 结构都保存着一个键值对：
key 属性保存着键值对中的键， 而 v 属性则保存着键值对中的值， 其中键值对的值可以是一个指针， 或者是一个 uint64_t 整数， 又或者是一个 int64_t 整数。
next 属性是指向另一个哈希表节点的指针， 这个指针可以将多个哈希值相同的键值对连接在一次， 以此来解决键冲突（collision）的问题。
举个例子， 图 4-2 就展示了如何通过 next 指针， 将两个索引值相同的键 k1 和 k0 连接在一起。
Redis 中的字典由 dicth/dict 结构表示：
type 属性和 privdata 属性是针对不同类型的键值对， 为创建多态字典而设置的：
ht 属性是一个包含两个项的数组， 数组中的每个项都是一个 dictht 哈希表， 一般情况下， 字典只使用 ht[0] 哈希表， ht[1] 哈希表只会在对 ht[0] 哈希表进行 rehash 时使用。
除了 ht[1] 之外， 另一个和 rehash 有关的属性就是 rehashidx ： 它记录了 rehash 目前的进度， 如果目前没有在进行 rehash ， 那么它的值为 -1 。
图 4-3 展示了一个普通状态下（没有进行 rehash）的字典：
在Redis中，由于它对实时性要求更高，因此使用了渐进式rehash
当有新键值对添加到Redis字典时，有可能会触发rehash。Redis中处理哈希碰撞的方法与Java一样，都是采用链表法，整个哈希表的性能则依赖于它的大小size和它已经保存节点数量used的比率。
比率在1:1时，哈希表的性能最好，如果节点数量比哈希表大小大很多的话，则整个哈希表就退化成多个链表，其性能优势全无。
上图的哈希表，平均每次失败查找需要访问5个节点。为了保持高效性能，在不修改键值对情况下，
需要进行rehash，目标是将ratio比率维持在1:1左右。
Ratio ＝ Used / Size
rehash触发条件：
rehash执行过程：
Redis哈希为了避免整个rehash过程中服务被阻塞，采用了渐进式的rehash，即rehash程序激活后，并不是
马上执行直到完成，而是分多次，渐进式（incremental）的完成。同时，为了保证并发安全，在执行rehash
中间执行添加时，新的节点会直接添加到ht[1]而不是ht[0], 这样保证了数据的完整性与安全性。
另一方面，哈希的Rehash在还提供了创新的（相对于Java HashMap）收缩（shrink）字典，当可用节点远远
大于已用节点的时候，rehash会自动进行收缩，具体过程与上面类似以保证比率始终高效使用。
当哈希对象可以同时满足以下两个条件时， 哈希对象使用 ziplist 编码：
要理解HTTPS首先要理解对称加密和非对称加密
对称加密相对来说耗时短，但是安全性差。非对称加密相对来说耗时长，但是安全性好。
所以HTTPS采用 非对称加密 来传输 对称加密 所需要的密钥。通信双方拿到 对称加密 所需要的密钥就对传输内容进行对称加密。兼顾安全性和性能。
这个过程中存在一个问题，就是可能会被中间人窃取对称加密密钥。
其实根本原因在于客户端并不知道服务器传输过来的公钥是不是属于对应的服务器。
为了解决中间人攻击的问题，于是引入了第三方也就是CA机构。由CA机构向服务器发放数字证书（包含服务器公钥和服务器IP等信息）和CA机构私钥。数字证书经过哈希算法之后得要一个哈希值，这个哈希值在经过 CA机构私钥 加密后得到的就是数字签名。
最后服务器向客户端传输的是明文数字证书和数字签名，客户端用 CA机构公钥 （从安装的根证书中获取）解开CA机构私钥加密的数字签名就得到哈希值A，再将数字证书用其中指定的哈希算法处理得到另一个哈希值B，比对两个哈希值就知道服务器公钥有没有被篡改了。如果没有被篡改那么安全的对称加密链接也就建立了。
0条评论