从HTTP到HTTPS，原来这么简单
一、HTTP Begin
1、什么是 HTTP
HTTP 是基于文本传输的协议，它位于 OSI 七层模型的应用层（Application） ，HTTP 是通过客户端向服务器发送请求，服务器响应请求来进行通讯，截止到目前位置 HTTP 协议分别由 6 个独立的协议说明组成，这 6 个协议说明分别是 RFC 7230 、 RFC 7231 、 RFC 7232 、 RFC 7233 、 RFC 7234 、 RFC 7235 。
说到 HTTP 就不得不说通讯报文，下面我们来看看 HTTP 通讯报文。通讯报文分为 请求报文 和 响应报文 。
①请求报文
HTTP请求报文通常由请求行（request line）、请求头部（header）、空行和请求数据4个部分组，如下图所示：
请求行包含请求方法、URL 和 HTTP 协议版本三个字段组成，在这里需要说的是 请求方法可以实 GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT，但是常见的经常用到的就是 GET、POST、DELETE和 PUT。
请求头部由大量键值对组成，请求头部的数据都是向服务器告知客户端的信息，比较常见的请求头有 User-Agent 浏览器类型，Accept 客户端可识别的内容类型列表，Host 请求的主机名。接下来是一个空行，它主要用来通知服务器从当前行开始往下就不再是请求头了。
请求数据主要是在 POST 和 PUT 方法中使用，用来向服务器提交客户端的表单信息，一般需要配合着 Content-Type和Content-Length 使用。
②响应报文
响应报文也是由三部分组成，状态行、消息报头和响应正文。状态行用来告知客户端所请求资源的情况，状态行由 HTTP 版本、服务器回发响应状态码和状态码文本描述组成。这里要说一下响应状态码，状态码类型如下表所示：
上表看着响应状态码很多，但是大部分在实际运用中很少遇到，经常遇到的状态码一共 7 中，如下表所示：
2、HTTP 致命缺点
HTTP 有一个致命的缺点，就是 HTTP 的报文都是以明文的方式进行传输，这样就会导致中间人攻击问题。什么是中间人攻击了，下面我们通过图文的形式讲一下。
A 在客户端向服务器发送了一句话“我今天很好”，这时在数据还没有到达服务器的时候被 B 拦截到，B 将发送的内容改为“我昨天很好”并发送给服务器，最后服务器接收到的信息就是“我昨天很好”而不是“我今天很好”。
在这里 B 就是中间人，B 所执行的所有操作就叫做中间人攻击，一图胜千言我们来看图。
3、HTTP 预防致命缺点手段
要想预防中间人攻击我们就需要对发送的报文信息进行加密处理，一般来说我们会采用两种加密手段来预防中间人攻击：对称加密和非对称加密。
①对称加密
首先 A 发送一条信息告诉服务器我要和你通讯了，服务器收到这条信息后响应一条信息告诉 A 的加密方式（例如 AES 加密）和密钥，最后 A 用和服务器协商好的加密方式对信息进行加密并发送，服务器收到信息后利用密钥进行解密即可。
通过上图看出点什么没？发送的内容虽然已经加密了，但是加密方式和密钥依然是明文，中间人如果拦截到第一次通信的话，它就可以拿着拦截到的加密方式和密钥就可以对后面的通信进行解密，修改内容后再以同样的加密方式和密钥进行加密后发送个服务器。
②非对称加密
针对前面所说的情况我们可以使用非对称加密对密钥进行加密处理。同样首先 A 发送一条信息告诉服务器我要和你通讯了，服务器收到这条信息后先利用非对称加密（例如RSA）生成一个公钥和一个私钥，然后服务器将公钥发发送给 A ，A 在本地生成一个密钥并利用服务器发回的公钥进行加密，完成后发送给服务器，服务器收到后利用私钥进行解密得到对称加密的密钥，最后双方利用约定好的加密方式和密钥进行通信。
到目前为止看起来不错密钥和信息都加密了，应该就没问题了吧。真的是这样吗，如果真的是这样的话 HTTPS 就没有出现的必要了。
既然密钥都加密了，那么中间人在拦截到第一次通信时可以拿到服务器发给客户端的加密方式和公钥，然后自己生成一个私钥和一个公钥，并将拦截到的服务器发来的公钥替换成自己生成的公钥后发送给客户端，这时客户端加密 AES 密钥的公钥就是中间人的了。
客户端对 AES 密钥加密后发送给服务器，中间人再次拦截并利用自己的私钥解析密文得到AES 密钥，然后使用服务器的公钥对 AES 密钥加密并发送给服务器。最后在客户端和服务器的整个通讯期间中间人就可以用接获到 AES 密钥对信息解密并修改。
到这里一定会由同学问，这两种方法都无法完全避免中间人攻击，还有其他的办法吗？下面我们伟大的 HTTPS 就要登场了，它可以完全避免中间人攻击。
二、HTTPS End
1.什么是 HTTPS
HTTPS 就是 HTTP 和 TLS 的简称，以前的 HTTPS 使用的是 SSL ，现在的 HTTPS 使用的是 SSL 。TLS 整体上来说和非对称加密是一样的，主要是对 AES 密钥加密的。
简单来说就是 A 发送一条信息给服务器告诉服务器我要和你通信，然后服务器返回 TLS/SSL 证数，客户端在收到证书后校验证书的有效性，如果证书有效就生成生成 AES 密钥并用证书中的公钥加密，然后发送给服务器。服务器确认收到后，就可以利用 AES 密钥进行加密通信了。
2.关于 CA 认证体系
CA 认证体系是 HTTPS 防止中间人攻击的核心，客户端需要对服务器发来的证书进行安全性校验。那么客户端是怎么校验证书的安全性呢？下面我们来讲解一下。
证书都是由权威的认证机构颁发的，并且这些认证机构办法的证书目前已经内置到了操作系统中（Windows 是这样，其他的操作系统不慎了解），这些证书被称为 CA 根证书。
当我们的服务器需要使用 HTTPS 的时候，就需要将服务器生成的公钥和网站相关信息发给权威认证机构，然后权威认证机构通过服务器发送的相关信息用进行加签，由此得到了服务器证书，这个证书对应的生成证书内容的签名，并将该这个签名使用权威认证机构的私钥进行加密得到证书指纹，并且和上级证书生成关系链（上级证书最后都是 CA 根证书）。
当客户端收到服务器发来的证书后，首先会通过层级关系找到上级证书，然后利用上级证书里的公钥解密服务器证书的证书指纹，解密后得到签名。
然后通过签名算法算出服务器证书的签名，并对比两个签名是否一样，一样就说明服务器发来的证书是不存在问题的。
这里证书校验用的 RSA 是通过私钥加密证书签名，公钥解密来巧妙的验证证书有效性的。通过 CA 认证体系就可以避免了中间人窃取 AES 密钥并发起拦截和修改 HTTP 通讯的报文。
三、总结
这篇文章唠唠叨叨的讲了这么多关于 HTTP 和 HTTPS 的知识，看似很基础其实在很多时候我们发出去或接受到的数据不准确其实就是因为中间人攻击造成的，因此我们在开发部署网站的时候应该尽可能的使用 HTTPS 。
