之前文章提到了阿里云经典网络问题，这里操作一把。
1，首先扫端口
nmap -v -sT 10.161.91.0/16 -p 6379 –open
发现一些IP和端口
2，随便找一个登录
redis-cli -c -h 10.161.29.xx -p 6379
这里用-c的原因是redis采用的是集群，允许集群模式
scan 0看下数据：
发现很轻易就获得了数据！!
月份：2017年2月
nmap的基本使用
其基本功能有三个，一是探测一组主机是否在线；其次是扫描 主机端口，嗅探所提供的网络服务；还可以推断主机所用的操作系统 。Nmap可用于扫描仅有两个节点的LAN，直至500个节点以上的网络。Nmap 还允许用户定制扫描技巧。通常，一个简单的使用ICMP协议的ping操作可以满足一般需求；也可以深入探测UDP或者TCP端口，直至主机所 使用的操作系统；还可以将所有探测结果记录到各种格式的日志中， 供进一步分析操作。
进行ping扫描，打印出对扫描做出响应的主机,不做进一步测试(如端口扫描或者操作系统探测)：
nmap -sP 192.168.1.0/24
仅列出指定网络上的每台主机，不发送任何报文到目标主机：
nmap -sL 192.168.1.0/24
探测目标主机开放的端口，可以指定一个以逗号分隔的端口列表(如-PS22，23，25，80)：
nmap -PS 192.168.1.234
使用UDP ping探测主机：
nmap -PU 192.168.1.0/24
使用频率最高的扫描选项：SYN扫描,又称为半开放扫描，它不打开一个完全的TCP连接，执行得很快：
nmap -sS 192.168.1.0/24
当SYN扫描不能用时，TCP Connect()扫描就是默认的TCP扫描：
nmap -sT 192.168.1.0/24
UDP扫描用-sU选项,UDP扫描发送空的(没有数据)UDP报头到每个目标端口:
nmap -sU 192.168.1.0/24
确定目标机支持哪些IP协议 (TCP，ICMP，IGMP等):
nmap -sO 192.168.1.19
探测目标主机的操作系统：
nmap -O 192.168.1.19
nmap -A 192.168.1.19
另外，nmap官方文档中的例子：
nmap -v scanme.
这个选项扫描主机scanme中 所有的保留TCP端口。选项-v启用细节模式。
nmap -sS -O scanme./24
进行秘密SYN扫描，对象为主机Saznme所在的“C类”网段 的255台主机。同时尝试确定每台工作主机的操作系统类型。因为进行SYN扫描 和操作系统检测，这个扫描需要有根权限。
nmap -sV -p 22，53，110，143，4564 198.116.0-255.1-127
进行主机列举和TCP扫描，对象为B类188.116网段中255个8位子网。这 个测试用于确定系统是否运行了sshd、DNS、imapd或4564端口。如果这些端口 打开，将使用版本检测来确定哪种应用在运行。
nmap -v -iR 100000 -P0 -p 80
随机选择100000台主机扫描是否运行Web服务器(80端口)。由起始阶段 发送探测报文来确定主机是否工作非常浪费时间，而且只需探测主机的一个端口，因 此使用-P0禁止对主机列表。
nmap -P0 -p80 -oX logs/pb-port80scan.xml -oG logs/pb-port80scan.gnmap 216.163.128.20/20
扫描4096个IP地址，查找Web服务器(不ping)，将结果以Grep和XML格式保存。
host -l | cut -d -f 4 | nmap -v -iL –
进行DNS区域传输，以发现中的主机，然后将IP地址提供给 Nmap。上述命令用于GNU/Linux — 其它系统进行区域传输时有不同的命令。
其他选项：
-p (只扫描指定的端口)
单个端口和用连字符表示的端口范 围(如 1-1023)都可以。当既扫描TCP端口又扫描UDP端口时，可以通过在端口号前加上T: 或者U:指定协议。 协议限定符一直有效直到指定另一个。 例如，参数 -p U:53，111，137，T:21-25，80，139，8080 将扫描UDP 端口53，111，和137，同时扫描列出的TCP端口。
-F (快速 (有限的端口) 扫描
其中关于阿里云扫内网的方法：
阿里云上的 VM 在 10.25.0.0/16 这个网段。
$ nmap -v -sT 10.25.6.0/24 –open
你还可以扫个更大的网段（专扫redis）：
$ nmap -v -sT 10.25.0.0/16 -p 6379 –open
[转]HTTPS为什么安全 &分析 HTTPS 连接建立全过程
本文将分两个专题去理解HTTPS。
专题一：HTTPS为什么安全
1、http为什么不安全？
http协议属于明文传输协议，交互过程以及数据传输都没有进行加密，通信双方也没有进行任何认证，通信过程非常容易遭遇劫持、监听、篡改，严重情况下，会造成恶意的流量劫持等问题，甚至造成个人隐私泄露（比如银行卡卡号和密码泄露）等严重的安全问题。
可以把http通信比喻成寄送信件一样，A给B寄信，信件在寄送过程中，会经过很多的邮递员之手，他们可以拆开信读取里面的内容（因为http是明文传输的）。A的信件里面的任何内容（包括各类账号和密码）都会被轻易窃取。除此之外，邮递员们还可以伪造或者修改信件的内容，导致B接收到的信件内容是假的。
比如常见的，在http通信过程中，“中间人”将广告链接嵌入到服务器发给用户的http报文里，导致用户界面出现很多不良链接； 或者是修改用户的请求头URL，导致用户的请求被劫持到另外一个网站，用户的请求永远到不了真正的服务器。这些都会导致用户得不到正确的服务，甚至是损失惨重。
2、https如何保证安全？
要解决http带来的问题，就要引入加密以及身份验证机制。
如果Server（以后简称服务器）给Client（以后简称 客户端）的消息是密文的，只有服务器和客户端才能读懂，就可以保证数据的保密性。同时，在交换数据之前，验证一下对方的合法身份，就可以保证通信双方的安全。那么，问题来了，服务器把数据加密后，客户端如何读懂这些数据呢？这时服务器必须要把加密的密钥（对称密钥，后面会详细说明）告诉客户端，客户端才能利用对称密钥解开密文的内容。但是，服务器如果将这个对称密钥以明文的方式给客户端，还是会被中间人截获，中间人也会知道对称密钥，依然无法保证通信的保密性。但是，如果服务器以密文的方式将对称密钥发给客户端，客户端又如何解开这个密文，得到其中的对称密钥呢？
说到这里，大家是不是有点儿糊涂了？一会儿密钥，一会儿对称密钥，都有点儿被搞晕的节奏。在这里，提前给大家普及一下，这里的密钥，指的是非对称加解密的密钥，是用于TLS握手阶段的； 对称密钥，指的是对称加解密的密钥，是用于后续传输数据加解密的。下面将详细说明。
这时，我们引入了非对称加解密的概念。在非对称加解密算法里，公钥加密的数据，有且只有唯一的私钥才能够解密，所以服务器只要把公钥发给客户端，客户端就可以用这个公钥来加密进行数据传输的对称密钥。客户端利用公钥将对称密钥发给服务器时，即使中间人截取了信息，也无法解密，因为私钥只部署在服务器，其他任何人都没有私钥，因此，只有服务器才能够解密。服务器拿到客户端的信息并用私钥解密之后，就可以拿到加解密数据用的对称密钥，通过这个对称密钥来进行后续通信的数据加解密。除此之外，非对称加密可以很好的管理对称密钥，保证每次数据加密的对称密钥都是不相同的，这样子的话，即使客户端病毒拉取到通信缓存信息，也无法窃取正常通信内容。
上述通信过程，可以画成以下交互图：
但是这样似乎还不够，如果通信过程中，在三次握手或者客户端发起HTTP请求过程中，客户端的请求被中间人劫持，那么中间人就可以伪装成“假冒客户端”和服务器通信；中间人又可以伪装成“假冒服务器”和客户端通信。接下来，我们详细阐述中间人获取对称密钥的过程：
中间人在收到服务器发送给客户端的公钥（这里是“正确的公钥”）后，并没有发给客户端，而是中间人将自己的公钥（这里中间人也会有一对公钥和私钥，这里称呼为“伪造公钥”）发给客户端。之后，客户端把对称密钥用这个“伪造公钥”加密后，发送过程中经过了中间人，中间人就可以用自己的私钥解密数据并拿到对称密钥，此时中间人再把对称密钥用“正确的公钥”加密发回给服务器。此时，客户端、中间人、服务器都拥有了一样的对称密钥，后续客户端和服务器的所有加密数据，中间人都可以通过对称密钥解密出来。
中间人获取对称密钥的过程如下：
为了解决此问题，我们引入了数字证书的概念。服务器首先生成公私钥，将公钥提供给相关机构（CA），CA将公钥放入数字证书并将数字证书颁布给服务器，此时服务器就不是简单的把公钥给客户端，而是给客户端一个数字证书，数字证书中加入了一些数字签名的机制，保证了数字证书一定是服务器给客户端的。中间人发送的伪造证书，不能够获得CA的认证，此时，客户端和服务器就知道通信被劫持了。加入了CA数字签名认证的SSL会话过程如下所示：
所以综合以上三点：非对称加密算法（公钥和私钥）交换对称密钥+数字证书验证身份（验证公钥是否是伪造的）+利用对称密钥加解密后续传输的数据=安全
3、https协议简介
为什么是简单地介绍https协议呢？因为https涉及的东西实在太多了，尤其是其中的加解密算法，十分复杂，作者本身对这些算法也研究不完，只是懂其中的一些皮毛而已。这部分仅仅是简单介绍一些关于https的最基本原理，为后面分析https的建立过程以及https优化等内容打下理论基础。
3.1 对称加密算法
对称加密是指：加密和解密使用相同密钥的算法。它要求发送方和接收方在安全通信之前，商定一个对称密钥。对称算法的安全性完全依赖于密钥，密钥泄漏就意味着任何人都可以对他们发送或接收的消息解密，所以密钥的保密性对通信至关重要。
3.1.1 对称加密又分为两种模式：流加密和分组加密
流加密是将消息作为字节流对待，并且使用数学函数分别作用在每一个字节位上。使用流加密时，每加密一次，相同的明文位会转换成不同的密文位。流加密使用了密钥流生成器，它生成的字节流与明文字节流进行异或，从而生成密文。
分组加密是将消息划分为若干个分组，这些分组随后会通过数学函数进行处理，每次一个分组。假设使用64位的分组密码，此时如果消息长度为640位，就会被划分成10个64位的分组（如果最后一个分组长度不到64，则用0补齐之后加到64位），每个分组都用一系列数学公式进行处理，最后得到10个加密文本分组。然后，将这条密文消息发送给对端。对端必须拥有相同的分组密码，以相反的顺序对10个密文分组使用前面的算法解密，最终得到明文消息。比较常用的分组加密算法有DES、3DES、AES。其中DES是比较老的加密算法，现在已经被证明不安全。而3DES是一个过渡的加密算法，相当于在DES基础上进行三重运算来提高安全性，但其本质上还是和DES算法一致。而AES是DES算法的替代算法，是现在最安全的对称加密算法之一。
3.1.2 对称加密算法的优缺点：
优点：计算量小、加密速度快、加密效率高。
缺点：
（1）交易双方都使用同样密钥，安全性得不到保证；
（2）每次使用对称加密算法时，都需要使用其他人不知道的惟一密钥，这会使得发收信息双方所拥有的钥匙数量呈几何级数增长，密钥管理成为负担。
3.2 非对称加密算法
在非对称密钥交换算法出现以前，对称加密的最主要缺陷就是不知道如何在通信双方之间传输对称密钥，而又不让中间人窃取。非对称密钥交换算法诞生之后，专门针对对称密钥传输做加解密，使得对称密钥的交互传输变得非常安全了。
非对称密钥交换算法本身非常复杂，密钥交换过程涉及到随机数生成，模指数运算，空白补齐，加密，签名等等一系列极其复杂的过程，作者本人也没有研究完全透彻。常见的密钥交换算法有RSA，ECDHE，DH，DHE等算法。涉及到比较复杂的数学问题。其中，最经典也是最常用的是RSA算法。
RSA：诞生于1977年，经过了长时间的破解测试，算法安全性很高，最重要的是，算法实现非常简单。缺点就是需要比较大的质数（目前常用的是2048位）来保证安全强度，极其消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法，RSA 是最经典，同时也是最常用的是非对称加解密算法。
3.2.1 非对称加密相比对称加密更加安全，但也存在两个致命的缺点：
（1）CPU计算资源消耗非常大。一次完全TLS握手，密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%。如果后续的应用层数据传输过程也使用非对称加解密，那么CPU性能开销太庞大，服务器是根本无法承受的。赛门特克给出的实验数据显示，加解密同等数量的文件，非对称算法消耗的CPU资源是对称算法的1000倍以上。
（2）非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256个字节。
所以非对称加解密（极端消耗CPU资源）目前只能用来作对称密钥交换或者CA签名，不适合用来做应用层内容传输的加解密。
3.3 身份认证
https协议中身份认证的部分是由CA数字证书完成的，证书由公钥、证书主体、数字签名等内容组成。在客户端发起SSL请求后，服务端会将数字证书发给客户端，客户端会对证书进行验证（验证这张证书是否是伪造的？也就是公钥是否是伪造的），如果证书不是伪造的，客户端就获取用于对称密钥交换的非对称密钥（获取公钥）。
3.3.1 数字证书有三个作用：
1、身份授权。确保浏览器访问的网站是经过CA验证的可信任的网站。
2、分发公钥。每个数字证书都包含了注册者生成的公钥（验证确保是合法的，非伪造的公钥）。在SSL握手时会通过certificate消息传输给客户端。
3、验证证书合法性。客户端接收到数字证书后，会对证书合法性进行验证。只有验证通过后的证书，才能够进行后续通信过程。
3.3.2 申请一个受信任的CA数字证书通常有如下流程：
（1）公司（实体）的服务器生成公钥和私钥，以及CA数字证书请求。
（2）RA（证书注册及审核机构）检查实体的合法性（在注册系统里面是否注册过的正规公司）。
（3）CA（证书签发机构）签发证书，发送给申请者实体。
（4）证书更新到repository（负责数字证书及CRL内容存储和分发），实体终端后续从repository更新证书，查询证书状态等。
3.4 数字证书验证
申请者拿到CA的证书并部署在网站服务器端，那浏览器发起握手并接收到证书后，如何确认这个证书就是CA签发的呢？怎样避免第三方伪造这个证书？答案就是数字签名（digital signature）。数字签名是证书的防伪标签，目前使用最广泛的SHA-RSA（SHA用于哈希算法，RSA用于非对称加密算法）。数字签名的制作和验证过程如下：
1、数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，然后使用CA自己的私钥对消息摘要进行加密。
2、数字签名的校验。使用CA的公钥解密签名，然后使用相同的签名函数对签名证书内容进行签名，并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。
需要注意的是：
（1）数字签名签发和校验使用的非对称密钥是CA自己的公钥和私钥，跟证书申请者（提交证书申请的公司实体）提交的公钥没有任何关系。
（2）数字签名的签发过程跟公钥加密的过程刚好相反，即是用私钥加密，公钥解密。（一对公钥和私钥，公钥加密的内容只有私钥能够解密；反过来，私钥加密的内容，也就有公钥才能够解密）
（3）现在大的CA都会有证书链，证书链的好处：首先是安全，保持CA的私钥离线使用。第二个好处是方便部署和撤销。这里为啥要撤销呢？因为，如果CA数字证书出现问题（被篡改或者污染），只需要撤销相应级别的证书，根证书依然是安全的。
（4）根CA证书都是自签名，即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的非对称密钥进行签名和验证的。
（5）怎样获取根CA和多级CA的密钥对？还有，既然是自签名和自认证，那么它们是否安全可信？这里的答案是：当然可信，因为这些厂商跟浏览器和操作系统都有合作，它们的根公钥都默认装到了浏览器或者操作系统环境里。
3.5 数据完整性验证
数据传输过程中的完整性使用MAC算法来保证。为了避免网络中传输的数据被非法篡改，或者数据比特被污染，SSL利用基于MD5或SHA的MAC算法来保证消息的完整性（由于MD5在实际应用中存在冲突的可能性比较大，所以尽量别采用MD5来验证内容一致性）。 MAC算法是在密钥参与下的数据摘要算法，能将密钥和任意长度的数据转换为固定长度的数据。发送者在密钥的作用下，利用MAC算法计算出消息的MAC值，并将其添加在需要发送的消息之后，并发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值，并与接收到的MAC值比较。如果二者相同，则报文没有改变；否则，报文在传输过程中被修改或者污染，接收者将丢弃该报文。 SHA也不能使用SHA0和SHA1，山东大学的王小云教授（很牛的一个女教授，大家有兴趣可以上网搜索一下她的事迹）在2005年就宣布破解了 SHA-1完整版算法，并获得了业内专家的认可。微软和google都已经宣布16年及17年之后不再支持sha1签名证书。
专题二：实际抓包分析
本文对百度搜索进行了两次抓包，第一次抓包之前清理了浏览器的所有缓存；第二次抓包是在第一次抓包后的半分钟内。
百度在2015年已经完成了百度搜索的全站https，这在国内https发展中具有重大的意义（目前BAT三大家中，只有百度宣称自己完成了全站HTTPS）。所以这篇文章就以www.baidu.com为例进行分析。
同时，作者采用的是chrome浏览器，chrome支持SNI （server Name Indication） 特性，对于HTTPS性能优化有很大的用处。
注：SNI是为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。一句话简述它的工作原理就是：在和服务器建立SSL连接之前，先发送要访问的域名（hostname），这样服务器根据这个域名返回一个合适的证书。目前，大多数操作系统和浏览器都已经很好地支持SNI扩展，OpenSSL 0.9.8已经内置这一功能，新版的nginx和apache也支持SNI扩展特性。
本文抓包访问的URL为：http://www.baidu.com/
（如果是https://www.baidu.com/，则以下结果不一样！）
抓包结果：
可以看到，百度采用以下策略：
（1）对于高版本浏览器，如果支持 https，且加解密算法在TLS1.0 以上的，都将所有 http请求重定向到 https请求
（2）对于https请求，则不变。
【详细解析过程】
1、TCP三次握手
可以看到，我的电脑访问的是http://www.baidu.com/，在初次建立三次握手的时候， 客户端是去连接 8080端口的（我所在小区网络总出口做了一层总代理，因此，客户端实际和代理机做的三次握手，代理机再帮客户端去连接百度服务器）
2、tunnel建立
由于小区网关设置了代理访问，因此，在进行https访问的时候，客户端需要和代理机做”HTTPS CONNECT tunnel” 连接（关于”HTTPS CONNECT tunnel”连接，可以理解为：虽然后续的https请求都是代理机和百度服务器进行公私钥连接和对称密钥交换，以及数据通信；但是，有了隧道连接之后，可以认为客户端也在直接和百度服务器进行通信。）
fiddler抓包结果：
3、client hello
3.1 随机数
在客户端问候中，有四个字节以Unix时间格式记录了客户端的协调世界时间（UTC）。协调世界时间是从1970年1月1日开始到当前时刻所经历的秒数。在这个例子中，0x2516b84b就是协调世界时间。在他后面有28字节的随机数（random_C），在后面的过程中我们会用到这个随机数。
3.2 SID（Session ID）
如果出于某种原因，对话中断，就需要重新握手。为了避免重新握手而造成的访问效率低下，这时候引入了session ID的概念， session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的“对称密钥”，而不必重新生成一把。
因为我们抓包的时候，是几个小时内第一次访问https://www.baodu.com ，因此，这里并没有Session ID.（稍会儿我们会看到隔了半分钟，第二次抓包就有这个Session ID）
session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器（这是很有可能的，对于同一个域名，当流量很大的时候，往往后台有几十台RS机在提供服务），就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。
3.3 密文族（Cipher Suites）
RFC2246中建议了很多中组合，一般写法是”密钥交换算法-对称加密算法-哈希算法，以“TLS_RSA_WITH_AES_256_CBC_SHA”为例：
（a）TLS为协议，RSA为密钥交换的算法；
（b）AES_256_CBC是对称加密算法（其中256是密钥长度，CBC是分组方式）；
（c）SHA是哈希的算法。
浏览器支持的加密算法一般会比较多，而服务端会根据自身的业务情况选择比较适合的加密组合发给客户端。（比如综合安全性以及速度、性能等因素）
3.4 Server_name扩展（一般浏览器也支持 SNI扩展）
当我们去访问一个站点时，一定是先通过DNS解析出站点对应的ip地址，通过ip地址来访问站点，由于很多时候一个ip地址是给很多的站点公用，因此如果没有server_name这个字段，server是无法给与客户端相应的数字证书的，Server_name扩展则允许服务器对浏览器的请求授予相对应的证书。
服务器回复
（包括Server Hello，Certificate，Certificate Status）
服务器在收到client hello后，会回复三个数据包，下面分别看一下：
4、Server Hello
4.1、我们得到了服务器的以Unix时间格式记录的UTC和28字节的随机数 （random_S）。
4.2、Seesion ID，服务端对于session ID一般会有三种选择 （稍会儿我们会看到隔了半分钟，第二次抓包就有这个Session ID）：
（1）恢复的session ID：我们之前在client hello里面已经提到，如果client hello里面的session ID在服务端有缓存，服务端会尝试恢复这个session；
（2）新的session ID：这里又分两种情况，第一种是client hello里面的session ID是空值，此时服务端会给客户端一个新的session ID，第二种是client hello里面的session ID此服务器并没有找到对应的缓存，此时也会回一个新的session ID给客户端；
（3）NULL：服务端不希望此session被恢复，因此session ID为空。
4.3、我们记得在client hello里面，客户端给出了多种加密族 Cipher，而在客户端所提供的加密族中，服务端挑选了“TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”
（a）TLS为协议，RSA为密钥交换的算法；
（b）AES_256_CBC是对称加密算法（其中256是密钥长度，CBC是分组方式）；
（c）SHA是哈希的算法。
这就意味着服务端会使用ECDHE-RSA算法进行密钥交换，通过AES_128_GCM对称加密算法来加密数据，利用SHA256哈希算法来确保数据完整性。
5、Certificate
在前面的https原理研究中，我们知道为了安全的将公钥发给客户端，服务端会把公钥放入数字证书中并发给客户端（数字证书可以自签发，但是一般为了保证安全会有一个专门的CA机构签发），所以这个报文就是数字证书，4097 bytes就是证书的长度。
我们打开这个证书，可以看到证书的具体信息，这个具体信息通过抓包报文的方式不是太直观，可以在浏览器上直接看。（点击chrome浏览器左上方的绿色锁型按钮）
6、Server Hello Done
我们抓的包是将 Server Hello Done 和 server key exchage 合并的包：
7、客户端验证证书真伪性
客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下：
（1）证书链的可信性trusted certificate path，方法如前文所述；
（2）证书是否吊销revocation，有两类方式离线CRL与在线OCSP，不同的客户端行为会不同；
（3）有效期expiry date，证书是否在有效时间范围；
（4）域名domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析；
8、秘钥交换
这个过程非常复杂，大概总结一下：
（1）首先，客户端利用CA数字证书实现身份认证，利用非对称加密协商对称密钥。
（2）客户端会向服务器传输一个“pubkey”随机数，服务器收到之后，利用特定算法生成另外一个“pubkey”随机数，客户端利用这两个“pubkey”随机数生成一个 pre-master 随机数。
（3）客户端利用自己在 client hello 里面传输的随机数 random_C，以及收到的 server hello 里面的随机数 random_S，外加 pre-master 随机数，利用对称密钥生成算法生成 对称密钥enc_key：enc_key=Fuc(random_C, random_S, Pre-Master)
9、生成session ticket
如果出于某种原因，对话中断，就需要重新握手。为了避免重新握手而造成的访问效率低下，这时候引入了session ID的概念， session ID（以及session ticke）的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的“对话密钥”，而不必重新生成一把。
因为我们抓包的时候，是几个小时内第一次访问 https://www.baodu.com 首页，因此，这里并没有 Session ID.（稍会儿我们会看到隔了半分钟，第二次抓包就有这个Session ID）
session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。
后续建立新的https会话，就可以利用 session ID 或者 session Tickets ， 对称秘钥可以再次使用，从而免去了 https 公私钥交换、CA认证等等过程，极大地缩短 https 会话连接时间。
10、利用对称秘钥传输数据
三、半分钟后，再次访问百度：
有这些大的不同：
由于服务器和浏览器缓存了 Session ID 和 Session Tickets，不需要再进行 公钥证书传递，CA认证，生成 对称密钥等过程，直接利用半分钟前的对称密钥加解密数据进行会话。
1、Client Hello
2、Server Hello
[转]百亿级微信红包的高并发资金交易系统设计方案
2017年1月28日，正月初一，微信公布了用户在除夕当天收发微信红包的数量——142亿个，而其收发峰值也已达到76万每秒。百亿级别的红包，如何保障并发性能与资金安全？这给微信带来了超级挑战。面对挑战，微信红包在分析了业界“秒杀”系统解决方案的基础上，采用了SET化、请求排队串行化、双维度分库表等设计，形成了独特的高并发、资金安全系统解决方案。实践证明，该方案表现稳定，且实现了除夕夜系统零故障运行。
本文将为读者介绍百亿级别红包背后的系统高并发设计方案，包括微信红包的两大业务特点、微信红包系统的技术难点、解决高并发问题通常使用的方案，以及微信红包系统的高并发解决方案。
一、微信红包的两大业务特点
微信红包（尤其是发在微信群里的红包，即群红包）业务形态上很类似网上的普通商品“秒杀”活动。
用户在微信群里发一个红包，等同于是普通商品“秒杀”活动的商品上架；微信群里的所有用户抢红包的动作，等同于“秒杀”活动中的查询库存；用户抢到红包后拆红包的动作，则对应“秒杀”活动中用户的“秒杀”动作。
不过除了上面的相同点之外，微信红包在业务形态上与普通商品“秒杀”活动相比，还具备自身的特点：
首先，微信红包业务比普通商品“秒杀”有更海量的并发要求。
微信红包用户在微信群里发一个红包，等同于在网上发布一次商品“秒杀”活动。假设同一时间有10万个群里的用户同时在发红包，那就相当于同一时间有10万个“秒杀”活动发布出去。10万个微信群里的用户同时抢红包，将产生海量的并发请求。
其次，微信红包业务要求更严格的安全级别。
微信红包业务本质上是资金交易。微信红包是微信支付的一个商户，提供资金流转服务。
用户发红包时，相当于在微信红包这个商户上使用微信支付购买一笔“钱”，并且收货地址是微信群。当用户支付成功后，红包“发货”到微信群里，群里的用户拆开红包后，微信红包提供了将“钱”转入折红包用户微信零钱的服务。
资金交易业务比普通商品“秒杀”活动有更高的安全级别要求。普通的商品“秒杀”商品由商户提供，库存是商户预设的，“秒杀”时可以允许存在“超卖”（即实际被抢的商品数量比计划的库存多）、“少卖”（即实际被抢的商户数量比计划的库存少）的情况。但是对于微信红包，用户发100元的红包绝对不可以被拆出101元；用户发100元只被领取99元时，剩下的1元在24小时过期后要精确地退还给发红包用户，不能多也不能少。
以上是微信红包业务模型上的两大特点。
二、 微信红包系统的技术难点
在介绍微信红包系统的技术难点之前，先介绍下简单的、典型的商品“秒杀”系统的架构设计，如下图所示。
该系统由接入层、逻辑服务层、存储层与缓存构成。Proxy处理请求接入，Server承载主要的业务逻辑，Cache用于缓存库存数量、DB则用于数据持久化。
一个“秒杀”活动，对应DB中的一条库存记录。当用户进行商品“秒杀”时，系统的主要逻辑在于DB中库存的操作上。一般来说，对DB的操作流程有以下三步：
a. 锁库存
b. 插入“秒杀”记录
c. 更新库存
其中，锁库存是为了避免并发请求时出现“超卖”情况。同时要求这三步操作需要在一个事务中完成（所谓的事务，是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行）。
“秒杀”系统的设计难点就在这个事务操作上。商品库存在DB中记为一行，大量用户同时“秒杀”同一商品时，第一个到达DB的请求锁住了这行库存记录。在第一个事务完成提交之前这个锁一直被第一个请求占用，后面的所有请求需要排队等待。同时参与“秒杀”的用户越多，并发进DB的请求越多，请求排队越严重。因此，并发请求抢锁，是典型的商品“秒杀”系统的设计难点。
微信红包业务相比普通商品“秒杀”活动，具有海量并发、高安全级别要求的特点。在微信红包系统的设计上，除了并发请求抢锁之外，还有以下两个突出难点：
首先，事务级操作量级大。上文介绍微信红包业务特点时提到，普遍情况下同时会有数以万计的微信群在发红包。这个业务特点映射到微信红包系统设计上，就是有数以万计的“并发请求抢锁”同时在进行。这使得DB的压力比普通单个商品“库存”被锁要大很多倍。
其次，事务性要求严格。微信红包系统本质上是一个资金交易系统，相比普通商品“秒杀”系统有更高的事务级别要求。
三、解决高并发问题通常使用的方案
普通商品“秒杀”活动系统，解决高并发问题的方案，大体有以下几种：
方案一，使用内存操作替代实时的DB事务操作。
如图2所示，将“实时扣库存”的行为上移到内存Cache中操作，内存Cache操作成功直接给Server返回成功，然后异步落DB持久化。
这个方案的优点是用内存操作替代磁盘操作，提高了并发性能。
但是缺点也很明显，在内存操作成功但DB持久化失败，或者内存Cache故障的情况下，DB持久化会丢数据，不适合微信红包这种资金交易系统。
方案二，使用乐观锁替代悲观锁。
所谓悲观锁，是关系数据库管理系统里的一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作对某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。对应于上文分析中的“并发请求抢锁”行为。
所谓乐观锁，它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。
商品“秒杀”系统中，乐观锁的具体应用方法，是在DB的“库存”记录中维护一个版本号。在更新“库存”的操作进行前，先去DB获取当前版本号。在更新库存的事务提交时，检查该版本号是否已被其他事务修改。如果版本没被修改，则提交事务，且版本号加1；如果版本号已经被其他事务修改，则回滚事务，并给上层报错。
这个方案解决了“并发请求抢锁”的问题，可以提高DB的并发处理能力。
但是如果应用于微信红包系统，则会存在下面三个问题：
- 如果拆红包采用乐观锁，那么在并发抢到相同版本号的拆红包请求中，只有一个能拆红包成功，其他的请求将事务回滚并返回失败，给用户报错，用户体验完全不可接受。
- 如果采用乐观锁，将会导致第一时间同时拆红包的用户有一部分直接返回失败，反而那些“手慢”的用户，有可能因为并发减小后拆红包成功，这会带来用户体验上的负面影响。
- 如果采用乐观锁的方式，会带来大数量的无效更新请求、事务回滚，给DB造成不必要的额外压力。
基于以上原因，微信红包系统不能采用乐观锁的方式解决并发抢锁问题。
四、微信红包系统的高并发解决方案
综合上面的分析，微信红包系统针对相应的技术难点，采用了下面几个方案，解决高并发问题。
1.系统垂直SET化，分而治之。
微信红包用户发一个红包时，微信红包系统生成一个ID作为这个红包的唯一标识。接下来这个红包的所有发红包、抢红包、拆红包、查询红包详情等操作，都根据这个ID关联。
红包系统根据这个红包ID，按一定的规则（如按ID尾号取模等），垂直上下切分。切分后，一个垂直链条上的逻辑Server服务器、DB统称为一个SET。
各个SET之间相互独立，互相解耦。并且同一个红包ID的所有请求，包括发红包、抢红包、拆红包、查详情详情等，垂直stick到同一个SET内处理，高度内聚。通过这样的方式，系统将所有红包请求这个巨大的洪流分散为多股小流，互不影响，分而治之，如下图所示。
这个方案解决了同时存在海量事务级操作的问题，将海量化为小量。
2.逻辑Server层将请求排队，解决DB并发问题。
红包系统是资金交易系统，DB操作的事务性无法避免，所以会存在“并发抢锁”问题。但是如果到达DB的事务操作（也即拆红包行为）不是并发的，而是串行的，就不会存在“并发抢锁”的问题了。
按这个思路，为了使拆红包的事务操作串行地进入DB，只需要将请求在Server层以FIFO（先进先出）的方式排队，就可以达到这个效果。从而问题就集中到Server的FIFO队列设计上。
微信红包系统设计了分布式的、轻巧的、灵活的FIFO队列方案。其具体实现如下：
首先，将同一个红包ID的所有请求stick到同一台Server。
上面SET化方案已经介绍，同个红包ID的所有请求，按红包ID stick到同个SET中。不过在同个SET中，会存在多台Server服务器同时连接同一台DB（基于容灾、性能考虑，需要多台Server互备、均衡压力）。
为了使同一个红包ID的所有请求，stick到同一台Server服务器上，在SET化的设计之外，微信红包系统添加了一层基于红包ID hash值的分流，如下图所示。
其次，设计单机请求排队方案。
将stick到同一台Server上的所有请求在被接收进程接收后，按红包ID进行排队。然后串行地进入worker进程（执行业务逻辑）进行处理，从而达到排队的效果，如下图所示。
最后，增加memcached控制并发。
为了防止Server中的请求队列过载导致队列被降级，从而所有请求拥进DB，系统增加了与Server服务器同机部署的memcached，用于控制拆同一个红包的请求并发数。
具体来说，利用memcached的CAS原子累增操作，控制同时进入DB执行拆红包事务的请求数，超过预先设定数值则直接拒绝服务。用于DB负载升高时的降级体验。
通过以上三个措施，系统有效地控制了DB的“并发抢锁”情况。
3.双维度库表设计，保障系统性能稳定
红包系统的分库表规则，初期是根据红包ID的hash值分为多库多表。随着红包数据量逐渐增大，单表数据量也逐渐增加。而DB的性能与单表数据量有一定相关性。当单表数据量达到一定程度时，DB性能会有大幅度下降，影响系统性能稳定性。采用冷热分离，将历史冷数据与当前热数据分开存储，可以解决这个问题。
处理微信红包数据的冷热分离时，系统在以红包ID维度分库表的基础上，增加了以循环天分表的维度，形成了双维度分库表的特色。
具体来说，就是分库表规则像db_xx.t_y_dd设计，其中，xx/y是红包ID的hash值后三位，dd的取值范围在01~31，代表一个月天数最多31天。
通过这种双维度分库表方式，解决了DB单表数据量膨胀导致性能下降的问题，保障了系统性能的稳定性。同时，在热冷分离的问题上，又使得数据搬迁变得简单而优雅。
综上所述，微信红包系统在解决高并发问题上的设计，主要采用了SET化分治、请求排队、双维度分库表等方案，使得单组DB的并发性能提升了8倍左右，取得了很好的效果。
五、总结
微信红包系统是一个高并发的资金交易系统，最大的技术挑战是保障并发性能与资金安全。这种全新的技术挑战，传统的“秒杀”系统设计方案已不能完全解决。在分析了业界“秒杀”系统解决方案的基础上，微信红包采用了SET化、请求排队串行化、双维度分库表等设计，形成了独特的高并发、资金安全系统解决方案，并在平时节假日、2015和2016春节实践中充分证明了可行性，取得了显著的效果。在刚刚过去的2017鸡年除夕夜，微信红包收发峰值达到76万每秒，收发微信红包142亿个，微信红包系统的表现稳定，实现了除夕夜系统零故障。
作者简介
方乐明，现任微信支付应用产品系统负责人，主要从事微信红包、微信转账、微信群收款等支付应用产品的系统设计、可用性提升、高性能解决方案设计等，曾负责2015、2016和2017年春节微信红包系统的性能优化与稳定性提升，取得良好的效果。
原文链接：http://www.infoq.com/cn/articles/2017hongbao-weixin
[转]扛住100亿次请求？我们来试一试
1. 前言
前几天，偶然看到了 《扛住100亿次请求——如何做一个“有把握”的春晚红包系统”》（url）一文，看完以后，感慨良多，收益很多。正所谓他山之石，可以攻玉，虽然此文发表于2015年,我看到时已经是2016年末，但是其中的思想仍然是可以为很多后端设计借鉴，。同时作为一个工程师，看完以后又会思考，学习了这样的文章以后，是否能给自己的工作带来一些实际的经验呢？所谓纸上得来终觉浅，绝知此事要躬行，能否自己实践一下100亿次红包请求呢？否则读完以后脑子里能剩下的东西 不过就是100亿 1400万QPS整流 这样的字眼，剩下的文章将展示作者是如何以此过程为目标，在本地环境的模拟了此过程。
实现的目标: 单机支持100万连接，模拟了摇红包和发红包过程，单机峰值QPS 6万，平稳支持了业务。
注：本文以及作者所有内容，仅代表个人理解和实践，过程和微信团队没有任何关系，真正的线上系统也不同，只是从一些技术点进行了实践，请读者进行区分。因作者水平有限，有任何问题都是作者的责任，有问题请联系 ppmsn2005#gmail.com. 全文内容 扛住100亿次请求？我们来试一试
2. 背景知识
QPS: Queries per second 每秒的请求数目
PPS：Packets per second 每秒数据包数目
摇红包：客户端发出一个摇红包的请求，如果系统有红包就会返回，用户获得红包
发红包：产生一个红包里面含有一定金额，红包指定数个用户，每个用户会收到红包信息，用户可以发送拆红包的请求，获取其中的部分金额。
3. 确定目标
在一切系统开始以前，我们应该搞清楚我们的系统在完成以后，应该有一个什么样的负载能力。
3.1 用户总数:
通过文章我们可以了解到接入服务器638台, 服务上限大概是14.3亿用户， 所以单机负载的用户上限大概是14.3亿/638台=228万用户/台。但是目前中国肯定不会有14亿用户同时在线，参考http://qiye.qianzhan.com/show/detail/160818-b8d1c700.html 的说法，2016年Q2 微信用户大概是8亿，月活在5.4 亿左右。所以在2015年春节期间，虽然使用的用户会很多，但是同时在线肯定不到5.4亿。
3.2. 服务器数量：
一共有638台服务器，按照正常运维设计，我相信所有服务器不会完全上线，会有一定的硬件冗余，来防止突发硬件故障。假设一共有600台接入服务器。
3.3 单机需要支持的负载数：
每台服务器支持的用户数：5.4亿/600 = 90万。也就是平均单机支持90万用户。如果真实情况比90万更多，则模拟的情况可能会有偏差，但是我认为QPS在这个实验中更重要。
3.4. 单机峰值QPS：
文章中明确表示为1400万QPS.这个数值是非常高的，但是因为有600台服务器存在，所以单机的QPS为 1400万/600= 约为2.3万QPS, 文章曾经提及系统可以支持4000万QPS，那么系统的QPS 至少要到4000万/600 = 约为 6.6万, 这个数值大约是目前的3倍，短期来看并不会被触及。但是我相信应该做过相应的压力测试。
3.5. 发放红包：
文中提到系统以5万个每秒的下发速度，那么单机每秒下发速度50000/600 ＝83个/秒,也就是单机系统应该保证每秒以83个的速度下发即可。
最后考虑到系统的真实性，还至少有用户登录的动作，拿红包这样的业务。真实的系统还会包括聊天这样的服务业务。
最后整体的看一下 100亿次摇红包这个需求，假设它是均匀地发生在春节联欢晚会的4个小时里，那么服务器的QPS 应该是10000000000/600/3600/4.0=1157. 也就是单机每秒1000多次，这个数值其实并不高。如果完全由峰值速度1400万消化 10000000000/(1400*10000) = 714秒，也就是说只需要峰值坚持11分钟，就可以完成所有的请求。可见互联网产品的一个特点就是峰值非常高，持续时间并不会很长。
总结：
从单台服务器看.它需要满足下面一些条件
1. 支持至少100万连接用户
2. 每秒至少能处理2.3万的QPS，这里我们把目标定得更高一些 分别设定到了3万和6万。
3. 摇红包：支持每秒83个的速度下发放红包，也就是说每秒有2.3万次摇红包的请求，其中83个请求能摇到红包，其余的2.29万次请求会知道自己没摇到。当然客户端在收到红包以后，也需要确保客户端和服务器两边的红包数目和红包内的金额要一致。因为没有支付模块，所以我们也把要求提高一倍，达到200个红包每秒的分发速度
4. 支持用户之间发红包业务，确保收发两边的红包数目和红包内金额要一致。同样也设定200个红包每秒的分发速度为我们的目标。
想完整模拟整个系统实在太难了，首先需要海量的服务器，其次需要上亿的模拟客户端。这对我来说是办不到，但是有一点可以确定，整个系统是可以水平扩展的，所以我们可以模拟100万客户端，在模拟一台服务器 那么就完成了1/600的模拟。
和现有系统区别：
和大部分高QPS测试的不同，本系统的侧重点有所不同。我对2者做了一些对比。
| 常见高QPS系统压力测试 | 本系统压力测试 | |
|---|---|---|
| 连接数 | 一般<1000 （几百以内） | 1000000 (1百万) |
| 单连接吞吐量 | 非常大 每个连接几十M字节吞吐 | 非常小 每个连接每次几十个字节 |
| 需要的IO次数 | 不多 | 非常多 |
4. 基础软件和硬件
4.1软件：
Golang 1.8r3 , shell, python (开发没有使用c++ 而是使用了golang, 是因为使用golang 的最初原型达到了系统要求。虽然golang 还存在一定的问题，但是和开发效率比，这点损失可以接受)
服务器操作系统:
Ubuntu 12.04
客户端操作系统:
debian 5.0
4.2硬件环境
服务端： dell R2950。 8核物理机，非独占有其他业务在工作，16G内存。这台硬件大概是7年前的产品，性能应该不是很高要求。
服务器硬件版本：
服务器CPU信息：
客户端： esxi 5.0 虚拟机,配置为4核 5G内存。一共17台，每台和服务器建立6万个连接。完成100万客户端模拟
5. 技术分析和实现
5.1) 单机实现100万用户连接
这一点来说相对简单，笔者在几年前就早完成了单机百万用户的开发以及操作。现代的服务器都可以支持百万用户。相关内容可以查看 github代码以及相关文档。
https://github.com/xiaojiaqi/C1000kPracticeGuide
系统配置以及优化文档：
https://github.com/xiaojiaqi/C1000kPracticeGuide/tree/master/docs/cn
5.2) 3万QPS
这个问题需要分2个部分来看客户端方面和服务器方面。
客户端QPS
因为有100万连接连在服务器上，QPS为3万。这就意味着每个连接每33秒，就需要向服务器发一个摇红包的请求。因为单IP可以建立的连接数为6万左右， 有17台服务器同时模拟客户端行为。我们要做的就保证在每一秒都有这么多的请求发往服务器即可。
其中技术要点就是客户端协同。但是各个客户端的启动时间，建立连接的时间都不一致，还存在网络断开重连这样的情况，各个客户端如何判断何时自己需要发送请求，各自该发送多少请求呢？
我是这样解决的：利用NTP服务，同步所有的服务器时间，客户端利用时间戳来判断自己的此时需要发送多少请求。
算法很容易实现：
假设有100万用户，则用户id 为0-999999.要求的QPS为5万， 客户端得知QPS为5万，总用户数为100万，它计算 100万/5万=20，所有的用户应该分为20组，如果 time() % 20 == 用户id % 20，那么这个id的用户就该在这一秒发出请求，如此实现了多客户端协同工作。每个客户端只需要知道 总用户数和QPS 就能自行准确发出请求了。
（扩展思考：如果QPS是3万 这样不能被整除的数目，该如何办？如何保证每台客户端发出的请求数目尽量的均衡呢？）
服务器QPS
服务器端的QPS相对简单，它只需要处理客户端的请求即可。但是为了客观了解处理情况，我们还需要做2件事情。
第一: 需要记录每秒处理的请求数目，这需要在代码里埋入计数器。
第二: 我们需要监控网络，因为网络的吞吐情况，可以客观的反映出QPS的真实数据。为此，我利用python脚本 结合ethtool 工具编写了一个简单的工具，通过它我们可以直观的监视到网络的数据包通过情况如何。它可以客观的显示出我们的网络有如此多的数据传输在发生。
工具截图： 
5.3) 摇红包业务
摇红包的业务非常简单，首先服务器按照一定的速度生产红包。红包没有被取走的话，就堆积在里面。服务器接收一个客户端的请求，如果服务器里现在有红包就会告诉客户端有，否则就提示没有红包。
因为单机每秒有3万的请求，所以大部分的请求会失败。只需要处理好锁的问题即可。
我为了减少竞争，将所有的用户分在了不同的桶里。这样可以减少对锁的竞争。如果以后还有更高的性能要求，还可以使用 高性能队列——Disruptor来进一步提高性能。
注意，在我的测试环境里是缺少支付这个核心服务的，所以实现的难度是大大的减轻了。另外提供一组数字：2016年淘宝的双11的交易峰值仅仅为12万/秒，微信红包分发速度是5万/秒，要做到这点是非常困难的。（http://mt.sohu.com/20161111/n472951708.shtml）
5.4) 发红包业务
发红包的业务很简单，系统随机产生一些红包，并且随机选择一些用户，系统向这些用户提示有红包。这些用户只需要发出拆红包的请求，系统就可以随机从红包中拆分出部分金额，分给用户，完成这个业务。同样这里也没有支付这个核心服务。
5.5）监控
最后 我们需要一套监控系统来了解系统的状况，我借用了我另一个项目(https://github.com/xiaojiaqi/fakewechat) 里的部分代码完成了这个监控模块，利用这个监控，服务器和客户端会把当前的计数器内容发往监控，监控需要把各个客户端的数据做一个整合和展示。同时还会把日志记录下来，给以后的分析提供原始数据。 线上系统更多使用opentsdb这样的时序数据库，这里资源有限,所以用了一个原始的方案
监控显示日志大概这样
6. 代码实现及分析
在代码方面，使用到的技巧实在不多，主要是设计思想和golang本身的一些问题需要考虑。
首先golang的goroutine 的数目控制，因为至少有100万以上的连接，所以按照普通的设计方案，至少需要200万或者300万的goroutine在工作。这会造成系统本身的负担很重。
其次就是100万个连接的管理，无论是连接还是业务都会造成一些心智的负担。
我的设计是这样的：
首先将100万连接分成多个不同的SET，每个SET是一个独立，平行的对象。每个SET 只管理几千个连接，如果单个SET 工作正常，我只需要添加SET就能提高系统处理能力。
其次谨慎的设计了每个SET里数据结构的大小，保证每个SET的压力不会太大，不会出现消息的堆积。
再次减少了gcroutine的数目，每个连接只使用一个goroutine,发送消息在一个SET里只有一个gcroutine负责，这样节省了100万个goroutine。这样整个系统只需要保留 100万零几百个gcroutine就能完成业务。大量的节省了cpu 和内存
系统的工作流程大概如下：
每个客户端连接成功后，系统会分配一个goroutine读取客户端的消息，当消息读取完成，将它转化为消息对象放至在SET的接收消息队列，然后返回获取下一个消息
在SET内部，有一个工作goroutine，它只做非常简单而高效的事情，它做的事情如下，检查SET的接受消息，它会收到3类消息
1， 客户端的摇红包请求消息
2， 客户端的其他消息 比如聊天 好友这一类
3， 服务器端对客户端消息的回应
对于 第1种消息 客户端的摇红包请求消息 是这样处理的，从客户端拿到摇红包请求消息，试图从SET的红包队列里 获取一个红包，如果拿到了就把红包信息 返回给客户端，否则构造一个没有摇到的消息，返回给对应的客户端。
对于第2种消息 客户端的其他消息 比如聊天 好友这一类，只需简单地从队列里拿走消息，转发给后端的聊天服务队列即可，其他服务会把消息转发出去。
对于第3种消息 服务器端对客户端消息的回应。SET 只需要根据消息里的用户id，找到SET里保留的用户连接对象，发回去就可以了。
对于红包产生服务，它的工作很简单，只需要按照顺序在轮流在每个SET的红包产生对列里放至红包对象就可以了。这样可以保证每个SET里都是公平的，其次它的工作强度很低，可以保证业务稳定。
见代码
https://github.com/xiaojiaqi/10billionhongbaos
7实践
实践的过程分为3个阶段
阶段1：
分别启动服务器端和监控端，然后逐一启动17台客户端，让它们建立起100万的链接。在服务器端，利用ss 命令 统计出每个客户端和服务器建立了多少连接。
命令如下：
Alias ss2=Ss –ant | grep 1025 | grep EST | awk –F: “{print \$8}” | sort | uniq –c’
结果如下： 
阶段2：
利用客户端的http接口，将所有的客户端QPS 调整到3万，让客户端发出3W QPS强度的请求。
运行如下命令：
观察网络监控和监控端反馈，发现QPS 达到预期数据
网络监控截图
在服务器端启动一个产生红包的服务，这个服务会以200个每秒的速度下发红包，总共4万个。此时观察客户端在监控上的日志，会发现基本上以200个每秒的速度获取到红包。
等到所有红包下发完成后，再启动一个发红包的服务，这个服务系统会生成2万个红包，每秒也是200个，每个红包随机指定3位用户，并向这3个用户发出消息，客户端会自动来拿红包，最后所有的红包都被拿走。
阶段3
利用客户端的http接口，将所有的客户端QPS 调整到6万，让客户端发出6W QPS强度的请求。
如法炮制，在服务器端，启动一个产生红包的服务，这个服务会以200个每秒的速度下发红包。总共4万个。此时观察客户端在监控上的日志，会发现基本上以200个每秒的速度获取到红包。
等到所有红包下发完成后，再启动一个发红包的服务，这个服务系统会生成2万个红包，每秒也是200个，每个红包随机指定3位用户，并向这3个用户发出消息，客户端会自动来拿红包，最后所有的红包都被拿走。
最后，实践完成。
8 分析数据
在实践过程中，服务器和客户端都将自己内部的计数器记录发往监控端，成为了日志。我们利用简单python 脚本和gnuplt 绘图工具，将实践的过程可视化，由此来验证运行过程。
第一张是 客户端的QPS发送数据
这张图的横坐标是时间，单位是秒，纵坐标是QPS，表示这时刻所有客户端发送的请求的QPS。
图的第一区间，几个小的峰值，是100万客户端建立连接的， 图的第二区间是3万QPS 区间，我们可以看到数据 比较稳定的保持在3万这个区间。最后是6万QPS区间。但是从整张图可以看到QPS不是完美地保持在我们希望的直线上。这主要是以下几个原因造成的
- 当非常多goroutine 同时运行的时候，依靠sleep 定时并不准确，发生了偏移。我觉得这是golang本身调度导致的。当然如果cpu比较强劲，这个现象会消失。
- 因为网络的影响，客户端在发起连接时，可能发生延迟，导致在前1秒没有完成连接。
- 服务器负载较大时，1000M网络已经出现了丢包现象，可以通过ifconfig 命令观察到这个现象，所以会有QPS的波动。
第二张是 服务器处理的QPS图
和客户端的向对应的，服务器也存在3个区间，和客户端的情况很接近。但是我们看到了在大概22：57分，系统的处理能力就有一个明显的下降，随后又提高的尖状。这说明代码还需要优化。
整体观察在3万QPS区间，服务器的QPS比较稳定，在6万QSP时候，服务器的处理就不稳定了。我相信这和我的代码有关，如果继续优化的话，还应该能有更好的效果。
将2张图合并起来 
基本是吻合的，这也证明系统是符合预期设计的。
这是红包生成数量的状态变化图
非常的稳定。
这是客户端每秒获取的摇红包状态
可以发现3万QPS区间，客户端每秒获取的红包数基本在200左右，在6万QPS的时候，以及出现剧烈的抖动，不能保证在200这个数值了。我觉得主要是6万QPS时候，网络的抖动加剧了，造成了红包数目也在抖动。
最后是golang 自带的pprof 信息，其中有gc 时间超过了10ms, 考虑到这是一个7年前的硬件，而且非独占模式，所以还是可以接受。
总结：
按照设计目标，我们模拟和设计了一个支持100万用户，并且每秒至少可以支持3万QPS，最多6万QPS的系统，简单模拟了微信的摇红包和发红包的过程。可以说达到了预期的目的。
如果600台主机每台主机可以支持6万QPS，只需要7分钟就可以完成 100亿次摇红包请求。
虽然这个原型简单地完成了预设的业务，但是它和真正的服务会有哪些差别呢？我罗列了一下
| 区别 | 真正服务 | 本次模拟 |
|---|---|---|
| 业务复杂 | 更复杂 | 非常简单 |
| 协议 | Protobuf 以及加密 | 简单的协议 |
| 支付 | 复杂 | 无 |
| 日志 | 复杂 | 无 |
| 性能 | 更高 | 无 |
| 用户分布 | 用户id分散在不同服务器，需要hash以后统一， 复杂。 | 用户id 连续，很多优化使代码简单 非常高效 |
| 安全控制 | 复杂 | 无 |
| 热更新及版本控制 | 复杂 | 无 |
| 监控 | 细致 | 简单 |
Refers：
- 单机百万的实践
- https://github.com/xiaojiaqi/C1000kPracticeGuide
- 如何在AWS上进行100万用户压力测试
- https://github.com/xiaojiaqi/fakewechat/wiki/Stress-Testing-in-the-Cloud
- 构建一个你自己的类微信系统
- https://github.com/xiaojiaqi/fakewechat/wiki/Design
- http://djt.qq.com/article/view/1356
- http://techblog.cloudperf.net/2016/05/2-million-packets-per-second-on-public.html
- http://datacratic.com/site/blog/1m-qps-nginx-and-ubuntu-1204-ec2
- @火丁笔记
- http://huoding.com/2013/10/30/296
- https://gobyexample.com/non-blocking-channel-operations
关于Python中的yield
在介绍yield前有必要先说明下Python中的迭代器(iterator)和生成器(constructor)。
一、迭代器(iterator)
在Python中，for循环可以用于Python中的任何类型，包括列表、元祖等等，实际上，for循环可用于任何“可迭代对象”，这其实就是迭代器
迭代器是一个实现了迭代器协议的对象，Python中的迭代器协议就是有next方法的对象会前进到下一结果，而在一系列结果的末尾是，则会引发StopIteration。任何这类的对象在Python中都可以用for循环或其他遍历工具迭代，迭代工具内部会在每次迭代时调用next方法，并且捕捉StopIteration异常来确定何时离开。
使用迭代器一个显而易见的好处就是：每次只从对象中读取一条数据，不会造成内存的过大开销。
比如要逐行读取一个文件的内容，利用readlines()方法，我们可以这么写：
1 2 |
for line in open("test.txt").readlines():
print line
|
这样虽然可以工作，但不是最好的方法。因为他实际上是把文件一次加载到内存中，然后逐行打印。当文件很大时，这个方法的内存开销就很大了。
利用file的迭代器，我们可以这样写：
1 2 |
for line in open("test.txt"): #use file iterators
print line
|
这是最简单也是运行速度最快的写法，他并没显式的读取文件，而是利用迭代器每次读取下一行。
二、生成器(constructor)
生成器函数在Python中与迭代器协议的概念联系在一起。简而言之，包含yield语句的函数会被特地编译成生成器。当函数被调用时，他们返回一个生成器对象，这个对象支持迭代器接口。函数也许会有个return语句，但它的作用是用来yield产生值的。
不像一般的函数会生成值后退出，生成器函数在生成值后会自动挂起并暂停他们的执行和状态，他的本地变量将保存状态信息，这些信息在函数恢复时将再度有效
1 2 3 4 5 6 7 8 |
>>> def g(n): ... for i in range(n): ... yield i **2 ... >>> for i in g(5): ... print i,":", ... 0 : 1 : 4 : 9 : 16 : |
要了解他的运行原理，我们来用next方法看看：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
>>> t = g(5) >>> t.next() 0 >>> t.next() 1 >>> t.next() 4 >>> t.next() 9 >>> t.next() 16 >>> t.next() Traceback (most recent call last): File "<stdin>", line 1, in <module> StopIteration |
在运行完5次next之后，生成器抛出了一个StopIteration异常，迭代终止。
再来看一个yield的例子，用生成器生成一个Fibonacci数列：
1 2 3 4 5 6 7 8 9 10 |
def fab(max):
a,b = 0,1
while a < max:
yield a
a, b = b, a+b
>>> for i in fab(20):
... print i,",",
...
0 , 1 , 1 , 2 , 3 , 5 , 8 , 13 ,
|
看到这里应该就能理解生成器那个很抽象的概念了吧~~