http与https的区别我真的知道吗

以前每次看到相似“http与https的区别？”的问题时，都会本身思考一下答案，好像只是浅显地知道https比http安全，但究竟为何更安全，却又彷佛说不出个因此然，或者说不少细节地方本身都是不清楚的。为了搞清楚，也为了系统地了解一下http相关的知识，前段时间阅读了一波《图解HTTP》，不得不说这本书真的算是通俗易懂，了解到了不少以前不清楚的知识点（协议、报文、状态码、首部字段、身份认证、资源缓存以及web攻击等）。若是想了解更多http相关的知识的同窗固然也能够选择阅读《HTTP权威指南》。

HTTP

HTTP，全称超文本传输协议，是一种详细规定客户端与web服务器之间互相通讯的规则，经过因特网传送万维网文档的数据传送协议。它的特色是：

• 无状态，每一个请求结束后都会被关闭，每次的请求都是独立的，它的执行状况和结果与前面的请求和以后的请求是无直接关系的，它不会受前面的请求应答状况直接影响，也不会直接影响后面的请求应答状况；服务器中没有保存客户端的状态，客户端必须每次带上本身的状态去请求服务器，就像是“人生只如初见”，好比说用户须要请求某个数据，须要登陆权限，用户登陆以后进行请求，结果由于http的无状态，等用户下一次还想请求一份数据，还须要再次登陆，这样不就很烦了吗，因此就须要session和cookie来进行状态管理了。

• 明文传输（未通过加密的报文），为何通讯时不加密是一个缺点，这是由于，按TCP/IP 协议族的工做机制，通讯内容在全部的通讯线路上都有可能遭到窥视。不管世界哪一个角落的服务器在和客户端通讯时，在此通讯线路上的某些网络设备、光缆、计算机等都不多是我的的私有物，因此不排除某个环节中会遭到恶意窥视行为。即便已通过加密处理的通讯，也会被窥视到通讯内容，这点和未加密的通讯是相同的。只是说若是通讯通过加密，就有可能让人没法破解报文信息的含义，但加密处理后的报文信息自己仍是会 被看到的。

• 不验证通讯方的身份，所以有可能遭遇假装。HTTP 协议中的请求和响应不会对通讯方进行确认。也就是说存在“服务器是否就是发送请求中 URI 真正指定的主机，返回的响应是否真的返回到实际提出请求的客户端”等相似问题。在 HTTP 协议通讯时，因为不存在确认通讯方的处理步骤，任何人均可以发起请求。另外，服务器只要接收到请求，无论对方是谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没 有被 Web 服务器设定限制访问的前提下；不管是谁发送过来的请求都会返回响应，所以不确认通讯方，会存在如下各类隐患：一、没法肯定请求发送至目标的 Web 服务器是不是按真实意图返回响应的那台服务器。有多是已假装的 Web 服务器；二、没法肯定响应返回到的客户端是不是按真实意图接收响应的那个客户端。有多是已假装的客户端；三、没法肯定正在通讯的对方是否具有访问权限。由于某些Web 服务器上保存着重要的信息，只想发给特定用户通讯的权限；四、没法断定请求是来自何方、出自谁手；五、即便是无心义的请求也会照单全收。没法阻止海量请求下的 DoS 攻击（Denial of Service，拒绝服务攻击）。

• 没法证实报文的完整性。所以，在请求或响应送出以后直到对方接收以前的这段时间内，即便请求或响应的内容遭到篡改，也没有办法获悉；换句话说，没有任何办法确认，发出的请求 / 响应和接收到的请 求 / 响应是先后相同的。

HTTPS

HTTPS，全称Hyper Text Transfer Protocol Secure，相比http，多了一个secure，也就是TLS（SSL），一个安全套接层。https和http都属于应用层（application layer），基于TCP（以及UDP）协议，可是又彻底不同。TCP用的port是80， https用的是443。

HTTPS 并不是是应用层的一种新协议。只是 HTTP 通讯接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。一般，HTTP 直接和 TCP 通讯。当使用 SSL时，则演变成先和 SSL通讯，再由 SSL和 TCP 通讯了。简言之，所谓 HTTPS，其实就是身披SSL协议这层外壳的 HTTP。

HTTPS解决的问题：

• 信任主机的问题.。 采用https 的server 必须从CA （数字证书认证机构处于客户端与服务器双方均可信赖的第三方机构的 立场上）申请一个用于证实服务器用途类型的证书，该证书有了CA的签名，客户端才能知道访问的服务器是安全的。 目前基本全部的在线购物和网银等网站或系统,关键部分应用都是https 的，客户经过信任该证书,从而信任了该主机，这样才能保证安全。

• 通信过程当中的数据的泄密和被窜改 使用https协议，服务端和客户端之间的全部通信都是加密的。客户端和服务端各有本身的一对非对称的密钥,一把叫作私有密钥（private key），另外一把叫作公开密钥（public key），顾名思义，私有密钥不能让其余任何人知道，而公开密钥则能够随意发布，任何人均可以得到。使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用本身的私有密钥进行解密。利用这种方式，不须要发送用来解密的私有密钥，也没必要担忧密钥被攻击者窃听而盗走。要想根据密文和公开密钥，恢复到信息原文是异常困难的，由于解密过程就是在对离散对数进行求值，这并不是垂手可得就能办到。退一步讲，若是能对一个很是大的整数作到快速地因式分解，那么密码破解仍是存在但愿的。但就目前的技术来看是不太现实的。

  

简单点说就是：HTTP + 认证 + 加密 + 完整性保护 = HTTPS

HTTPS 的通讯步骤

• 步骤 1： 客户端经过发送 Client Hello 报文开始 SSL通讯。报文中包含客户端支持的 SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
• 步骤 2： 服务器可进行 SSL通讯时，会以 Server Hello 报文做为应答。和客户端同样，在报文中包含 SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
• 步骤 3： 以后服务器发送 Certificate 报文。报文中包含公开密钥证书。
• 步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL握手协商部分结束。
• 步骤 5： SSL第一次握手结束以后，客户端以 Client Key Exchange 报文做为回应。报文中包含通讯加密中使用的一种被称为 Pre-mastersecret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
• 步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文以后的通讯会采用 Pre-master secret 密钥加密。
• 步骤 7： 客户端发送 Finished 报文。该报文包含链接至今所有报文的总体校验值。此次握手协商是否可以成功，要以服务器是否可以正确解密该报文做为断定标准。
• 步骤 8： 服务器一样发送 Change Cipher Spec 报文。
• 步骤 9： 服务器一样发送 Finished 报文。
• 步骤 10： 服务器和客户端的 Finished 报文交换完毕以后，SSL链接就算创建完成。固然，通讯会受到 SSL的保护。今后处开始进行应用层协议的通讯，即发送 HTTP 请求。
• 步骤 11： 应用层协议通讯，即发送 HTTP 响应。
• 步骤 12： 最后由客户端断开链接。断开链接时，发送 close_notify 报文。上图作了一些省略，这步以后再发送 TCP FIN 报文来关闭与 TCP的通讯。

下面是对整个流程的图解。图中说明了从仅使用服务器端的公开密钥证书（服务器证书）创建 HTTPS 通讯的整个过程。

HTTPS的加密技术

• 共享密钥加密的困境

  加密和解密同用一个密钥的方式称为共享密钥加密（Common key crypto system），也被叫作对称密钥加密。以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能 安全地转交？在互联网上转发密钥时，若是通讯被监听那么密钥 就可会落入攻击者之手，同时也就失去了加密的意义。另外还得 设法安全地保管接收到的密钥。也就是说，发送密钥就存在被窃听的风险，不发送，对方就不能解密。再说若是密钥可以安全送达，那么数据也可以安全送达，那加密也就失去其意义了。

• 使用两把密钥的公开密钥加密

  公开密钥加密方式很好地解决了共享密钥加密的困难。公开密钥加密使用一对非对称的密钥。一把叫作私有密钥（private key），另外一把叫作公开密钥（public key）。顾名思义，私有密钥不能让其余任何人知道，而公开密钥则能够随意发布，任何人均可以得到。 使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进 行加密处理，对方收到被加密的信息后，再使用本身的私有密钥 进行解密。利用这种方式，不须要发送用来解密的私有密钥，也没必要担忧密钥被攻击者窃听而盗走。 另外，要想根据密文和公开密钥，恢复到信息原文是异常困难的，由于解密过程就是在对离散对数进行求值，这并不是垂手可得 就能办到。退一步讲，若是能对一个很是大的整数作到快速地因式分解，那么密码破解仍是存在但愿的。但就目前的技术来看是不太现实的。

• HTTPS 采用混合加密机制

  所以，HTTPS采用的是共享密钥加密和公开密钥加密二者并用的混合加密机制。若密钥可以实现安全交换，那么有可能会考虑仅使用公开密钥加密来通讯。可是公开密钥加密与共享密钥加密相比，其处理速度要慢。因此应充分利用二者各自的优点，将多种方法组合起来用于通讯。在交换密钥环节使用公开密钥加密方式，以后的创建通讯交换报文阶段则使用共享密钥加密方式。上图中生成的master secret即共享密钥，以后的交换的报文信息都将使用它来进行加密。

HTTPS的问题

• HTTPS足够安全吗？世界上没有绝对的安全。好比2014年的Heartbleed漏洞席卷全球，不少网站受到heartbleed威胁，其中就有雅虎，stackoverflow这样的网站。但总的来讲对于绝大部分人来讲HTTPS仍是相对安全的，至少比HTTP安全。
• HTTPS 还有一个问题，那就是当使用 SSL时，它的处理速度会变慢

SSL的慢分两种。一种是指通讯慢。另外一种是指因为大量消耗CPU 及内存等资源，致使处理速度变慢。

• 和使用 HTTP 相比，网络负载可能会变慢 2 到 100 倍。除去和TCP 链接、发送 HTTP 请求 • 响应之外，还必须进行 SSL通讯，所以总体上处理通讯量不可避免会增长。
• 另外一点是 SSL必须进行加密处理。在服务器和客户端都须要进行加密和解密的运算处理。所以从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，致使负载加强。 -针对速度变慢这一问题，并无根本性的解决方案，咱们会使用SSL加速器这种（专用服务器）硬件来改善该问题。该硬件为SSL通讯专用硬件，相对软件来说，可以提升数倍 SSL的计算速度。仅在 SSL处理时发挥 SSL加速器的功效，以分担负载。

为何不一直使用 HTTPS？

• 由于与纯文本通讯相比，加密通讯会消耗更多的CPU 及内存资源。若是每次通讯都加密，会消耗至关多的资源，平摊到一台计算机上时，可以处理的请求数量一定也会随之减小。所以，若是是非敏感信息则使用 HTTP 通讯，只有在包含我的信息等敏感数据时，才利用 HTTPS 加密通讯。特别是每当那些访问量较多的 Web 网站在进行加密处理时，它们所承担着的负载不容小觑。在进行加密处理时，并不是对全部内容都进行加密处理，而是仅在那些须要信息隐藏时才会加密，以节约资源。

• 想要节约购买证书的开销也是缘由之一。 要进行 HTTPS 通讯，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。证书价格可能会根据不一样的认证机构略有不一样。那些购买证书并不合算的服务以及一些我的网站，可能只会选择采用 HTTP 的通讯方式。

参考书籍

《图解HTTP》

《HTTP权威指南》