https

http https
换句话说，HTTPS 跟 HTTP 一样，只不过增加了 SSL。

HTTP 包含如下动作：

浏览器打开一个 TCP 连接浏览器发送 HTTP 请求到服务器端服务器发送 HTTP 回应信息到浏览器TCP 连接关闭

SSL 包含如下动作：

验证服务器端允许客户端和服务器端选择加密算法和密码，确保双方都支持验证客户端(可选)使用公钥加密技术来生成共享加密数据创建一个加密的 SSL 连接基于该 SSL 连接传递 HTTP 请求

HTTPS和HTTP的区别：
https协议需要到ca申请证书，一般免费证书很少，需要交费。
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议
http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
http的连接很简单,是无状态的
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 要比http协议安全
HTTPS解决的问题：
1 . 信任主机的问题. 采用https 的server 必须从CA 申请一个用于证明服务器用途类型的证书. 改证书只有用于对应的server 的时候,客户度才信任次主机. 所以目前所有的银行系统网站,关键部分应用都是https 的. 客户通过信任该证书,从而信任了该主机. 其实这样做效率很低,但是银行更侧重安全. 这一点对我们没有任何意义,我们的server ,采用的证书不管自己issue 还是从公众的地方issue, 客户端都是自己人,所以我们也就肯定信任该server.
2 . 通讯过程中的数据的泄密和被窜改
1. 一般意义上的https, 就是 server 有一个证书.
a) 主要目的是保证server 就是他声称的server. 这个跟第一点一样.
b) 服务端和客户端之间的所有通讯,都是加密的.
i. 具体讲,是客户端产生一个对称的密钥,通过server 的证书来交换密钥. 一般意义上的握手过程.
ii. 加下来所有的信息往来就都是加密的. 第三方即使截获,也没有任何意义.因为他没有密钥. 当然窜改也就没有什么意义了.
2. 少许对客户端有要求的情况下,会要求客户端也必须有一个证书.
a) 这里客户端证书,其实就类似表示个人信息的时候,除了用户名/密码, 还有一个CA 认证过的身份. 应为个人证书一般来说上别人无法模拟的,所有这样能够更深的确认自己的身份.
b) 目前少数个人银行的专业版是这种做法,具体证书可能是拿U盘作为一个备份的载体.
HTTPS 一定是繁琐的.
a) 本来简单的http协议,一个get一个response. 由于https 要还密钥和确认加密算法的需要.单握手就需要6/7 个往返.
i. 任何应用中,过多的round trip 肯定影响性能.
b) 接下来才是具体的http协议,每一次响应或者请求, 都要求客户端和服务端对会话的内容做加密/解密.
i. 尽管对称加密/解密效率比较高,可是仍然要消耗过多的CPU,为此有专门的SSL 芯片. 如果CPU 信能比较低的话,肯定会降低性能,从而不能serve 更多的请求.
ii. 加密后数据量的影响. 所以，才会出现那么多的安全认证提示

从这个图我们可以看出：

由于浏览器和服务器之间对数据传输进行了对称加密，从而保证了数据的安全性，但是现在有一个问题，如何保证浏览器生成的随机数（对称加密的密钥）能安全的传递给服务器端？
如果这把密钥被第三方窃取，那么浏览器和服务器之间传递的数据就能被轻而易举的解密，进而造成危险.

我们可以这么做：
采用非对称加密的方式，让浏览器安全的把对称加密的密钥传送给服务器. 那什么是非对称加密呢？ 假如有两把钥匙一个叫公钥，一个叫私钥，用公钥加密的数据只有私钥才能解开，那么只要服务器存留一份私钥，把公钥发个浏览器，就可以安全传输数据.
问题似乎完美的解决了，但是不要忘记，服务器需要把它的公钥传递给浏览器，所以服务器如何保证它能正确的传递公钥呢（这问题像这样推倒下去，就没完没了，变成鸡和蛋的哲学问题了）？

好吧，我们来个终结者：CA证书.
CA证书是由权威机构颁发（意味着你可以信任他），证书的内容包含多种信息，其中就包括服务器的公钥，还包括证书有效期等等。
通过它建立我们的信任基点，就可以保证服务器公钥被正确的传递给浏览器，然后浏览器可以使用它安全的把对称加密的密钥传递给服务器，之后以此密钥加密需要传递的信息，保证了数据的安全性

可能到这里，你会有疑问，为什么我们不直接采用非对称加密加密数据，而先是使用非对称加密传送对称加密的密钥，之后传递数据使用对称加密？
这里的原因很简单，非对称加密的计算效率远远不如对称加密；
整个https流程实际上是： 使用非对称加密算法保证对称加密密钥的安全传递，然后使用对称加密来保证数据传输过程中的安全性

HTTPS简介

　　HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图。

1. 客户端发起HTTPS请求

   　　这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

   　　2. 服务端的配置

   　　采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

   　　3. 传送证书

   　　这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

   　　4. 客户端解析证书

   　　这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

   　　5. 传送加密信息

   　　这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

   　　6. 服务段解密信息

   　　服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

   　　7. 传输加密后的信息

   　　这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

   　　8. 客户端解密信息

   　　客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。
   http://www.jb51.net/network/68135.html
   http://dl2.iteye.com/upload/attachment/0077/5277/d31b3d02-eb0c-3788-b824-bb6840252272.jpg
   http://www.jianshu.com/p/a766bbf31417