HTTP 和 HTTPS 的主要区别在于 HTTP 协议传递的是明文数据，而 HTTPS 传递的是加密过的数据，也就是说 HTTPS 更具备安全性。也正由 HTTPS 须要保证安全性，因此它的性能要比 HTTP 差一点。web
单说安全性确定是不够的，我打算扩展讲一下 HTTPS 是怎么解决安全性问题的，经过这些 HTTP 没有机制，反映出 HTTPS 与 HTTP 的区别。下面尝试把 HTTPS 加密的过程推导出来。推导过程不涉及复杂的实现细节：如何安全地进行数据传输？面试
假设如今 A 和 B 要进行安全的通讯，那么究竟怎样才算是安全的通讯？很天然地会想到：A 和 B 之间传递数据，这些数据只有 A 和 B 才看得懂，中间人就算截取了信息但也看不懂，这才算得上安全。redis
安全通讯的处理手段：算法
为了能让 A 和 B 才能看懂，就必需要对数据进行加密，并且首先想到的就是对称加密。对称加密的意思是 A 和 B 各持有一个相同的密钥，它们传递信息时会用密钥给信息加密，在消息到达端给消息解密，完成安全通讯。数据库
在对称加密中又会涉及到加密算法的选择问题。现实世界中，一般是多个客户端面向一个服务器的状况，不可能让每一个客户端和服务器之间都采用相同的加密算法，若是是这样那和没加密差很少。因此注定每一个客户端和服务器之间都会采用不一样的加密方式。如何让每一个客户端与服务器之间都采用不一样的加密方式？小程序
要想对不一样的机器使用不一样的加密方式，最直接想到的就是使用随机数。也就说客户端和服务器之间每次都基于一个随机数产生加密算法。（具体实现时为了保证随机，用到还不止一个随机数）后端
这个产生加密算法的过程称之为协商，如今问题是协商的过程是透明的，也就是说中间人能够截获协商的过程，从而知道咱们的加密方式。为了解决这个问题，咱们须要对协商的过程进行加密。如何对协商的过程进行加密？浏览器
之因此能来到这一步，是由于咱们一开始就选择使用了对称加密，也就说一开始的对称加密致使了如今的问题，因此这时咱们不能再使用对称加密了，不然会陷入死循环。缓存
在密码学领域，还有一种加密过程叫非对称加密，它的逻辑是这样的：通讯双方一方持有私钥，一方持有公钥，通过私钥加密的信息，都能经过公钥进行解密。可是通过公钥加密的数据，只有私钥能够解密。安全
按照非对称加密的规则，咱们让服务器持有私钥，让客户端持有公钥。这样就能保证客户端给服务器发送消息的时候是安全的（相反，服务器给客户端发送消息就是不安全的），咱们能够把协商时重要的逻辑安排在客户端给服务器发送信息的过程当中，从而保证了协商过程的安全性。客户端如何得到公钥？
如今用非对称加密算法解决了协商的安全问题，可是非对称加密的前提是客户端须要得到公钥，这又是一个问题了，客户端与服务器打交道以前是互不知道双方身份的，怎么才能让客户端得到公钥呢？
也就只有两种办法：
客户端向服务器要公钥
客户端向一个远程的公共服务器获取公钥
方法2显然是不行的，尚且不说多了一个访问节点，如何找到公共服务器的地址也是一个待解决的问题，因此仍是使用方法1。可是方法 1 存在一个问题：若是中间人把服务器发送给客户端的公钥调包了怎么办？也就是说客户端没法知道发送公钥的是不是正真的服务器。
引入第三方机构解决问题
客户端没法辨识服务端和中间人的问题称为“身份验证”问题，也就是说咱们须要为服务器向客户端发送公钥的过程进行加密。
这下完了，以前咱们因遇到对称加密的瓶颈选择了非对称加密，如今使用非对称加密也遇到了瓶颈。显然这两种加密方式都是不可用的了，不然会再次陷入死循环。
接下来咱们只好经过第三方机构的介入，解决这个问题。首先咱们本身保存有第三方权威机构的公钥，而后第三方机构使用私钥对服务器将要发送给客户端的公钥进行加密，客户端接收到这个经加密的公钥后（数字证书），就能经过本身保存的第三方机构公钥进行解密。
到这里为止，咱们解释了 HTTPS 中使用到的对称加密，非对称加密，CA，数字证书的概念，可是还差一个叫数字签名的概念没有解释。
在现实生活中，CA 不单止会给咱们正常公司发放证书，还会给中间人的坏公司发放证书，若是中间人把发放的证书调包了怎么办？这时咱们仍能用 CA 的私钥进行解密，可是证书已经被调包了。
那么客户端怎样验证证书的真伪呢？答案是证书自己会告诉客户端如何辨认真伪。比方说证书上面有一个证书编号，还有一个如何计算证书编号的方法，客户端能够根据计算证书编号的方法计算出本身要得到的证书的编号，而后把这个编号和证书上的编号进行比对，若是同样证实没有被调包。
这里的证书编号指的就是数字签名，证书指的就是数字证书。
总结一下 HTTPS ：HTTPS 想要保证客户端与服务器之间的通讯安全，就得使用对称加密算法进行加密。协商对称加密算法的过程经过非对称加密算法来保证。在非对称加密算法中，客户端得到公钥的过程须要第三方机构（CA）经过颁发数字证书保证安全性。
总得来讲经过这一系列机制协商出了一个对称加密算法后，客户端与服务器之间就能经过该算法进行安全的通讯了。
我的以为这个问题还能够扩展一下，试想一下在键入 URL 以前，也就是刚开完机的时候，须要联网，而后才能上网。这个阶段包括了获取本机 IP 地址，获取 DNS 服务器 IP 地址，得到网关路由器 IP 和 MAC 地址等操做，把这些一块儿答上去会不会好一些？如下是回答：获取本机 IP 地址，DNS 服务器地址，网关路由器地址。
首先咱们须要准备一个 DHCP 报文，封装在一个 UDP 报文段中，里面包括本机端口号 68 和目的端口号 67，而后到网络层封装成数据包里面包括了本机的初始 IP 0.0.0.0，和广播地址 255.255.255.255。接着到链路层封装成链路层帧。里面包括广播地址和本机网卡的 MAC 地址。最后发送到本地局域网中。
这个数据包最终会被局域网中的 DHCP 服务器发现（有可能有多个 DHCP 服务器），DHCP 服务器会把可用的 IP 地址返回给咱们的主机。而后操做系统选择一个 IP 地址并发送给 DHCP 服务器，最后 DHCP 服务器会返回一个包含本机 IP，DNS 服务器 IP，网关路由器 IP 的报文。
接下来咱们须要经过网关路由器的 IP 地址去得到网关路由器的 MAC 地址，这样咱们才能够把获取网站 IP 的 DNS 请求报文由网关发送给 DNS 服务器。这时候咱们须要准备一个 ARP 请求报文，请求获取网关路由器的 MAC 地址，这个报文一样是以广播的方式发送到局域网中，网关路由器接受到请求报文就会把本身的 MAC 地址返回给本机。
获取域名的 IP 地址
接下来一切都准备好了，能够开始讲键入 URL 以后的事情了：
首先咱们要访问 DNS 服务器得到网站对应的 IP 地址，这时咱们须要把 DNS 报文封装到一个 UDP 报文中，进而封装到网络层的数据包中，填上源 IP，目的 DNS 服务器 IP 地址。接着封装链路层，填上网卡 MAC 地址和网关路由器 MAC 地址。接下来这个 DNS 请求报文就会经网关路由器发送给 DNS 服务器。
咱们假设 DNS 服务器缓存有该网站的 IP 地址，（若是没有缓存会进一步向更高级的DNS服务器索要IP地址）。接着 DNS 服务器会返回该域名的 IP 地址。
三次握手创建 TCP 链接
拿到了该网站的 IP 地址后就能够与该网站的服务器创建 TCP 链接了。创建 TCP 链接须要通过三次握手，过程以下：（更详细的过程在开头）
本机的 TCP 首先生成一个不带任何数据，SYN 标志位为 1，序号字段假设为client_num 的 TCP 报文，通过下层一系列网络栈后发送给目的 ip 服务器。
该服务器接受到 TCP 请求报文后，会回应一个赞成链接的 TCP 报文，这个报文的 SYN 标志位也会被置 1，序号字段假设为 server_num，ACK 响应字段为 client_num + 1。
接受到赞成链接的报文后，我方主机会进行响应，此次的 TCP 报文 SYN 位会被置0，序号字段为 client_num + 1，ACK 响应字段为 server + 1。而且此次的响应报文是能够携带数据的。
创建链接后进行数据交互
在三次握手创建链接后，本机就能够向服务器发送 HTTP 请求了，服务器接受到了请求会作出响应的响应，把请求的数据发送给本机浏览器，最终浏览器把服务器响应的数据渲染显示出来，咱们就看到了五彩缤纷的网页。八、HTTP的常见状态码有哪些，表明什么含义？
首先状态码的开头不一样表明不一样的类型：
1xx：表明指示信息，表示请求已接收，继续处理
2xx：表明成功，表示请求已被成功接收，理解，接受
3xx：重定向，表示完成请求必须进行进一步的操做
4xx：客户端错误，请求有语法错误或请求没法实现
5xx：服务器端错误，服务器未能实现合法的请求 复制代码
常见状态码：
200 OK：正常返回信息
400 Bad Request：客户端请求有语法错误，不能被服务器所理解
403 Forbidden：服务器收到请求，可是拒绝提供服务
404 Not Found：请求资源不存在，输入了错误的URL
500 Internal Server Error：服务器发生不可预期错误
503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常复制代码
1.从 HTTP 报文层面来看，GET 请求将信息放在 URL，POST 将请求信息放在请求体中。这一点使得 GET 请求携带的数据量有限，由于 URL 自己是有长度限制的，而 POST 请求的数据存放在报文体中，所以对大小没有限制。并且从形式上看，GET 请求把数据放 URL 上感受不太安全，而 POST 请求把数据放在请求体里彷佛安全一些。实际上想要获取 POST 请求中的内容仍是很容易的，所以二者在安全性上其实没有太大差别，想要实现安全的信息传输仍是得靠 HTTPS。
2.从数据库层面来看，GET 符合幂等性和安全性，而 POST 请求不符合。这个其实和 GET/POST 请求的做用有关。按照 HTTP 的约定，GET 请求用于查看信息，不会改变服务器上的信息；而 POST 请求用来改变服务器上的信息。正由于 GET 请求只查看信息，不改变信息，对数据库的一次或屡次操做得到的结果是一致的，认为它符合幂等性。安全性是指对数据库操做没有改变数据库中的数据。
3.从其余层面来看，GET 请求可以被缓存，GET 请求可以保存在浏览器的浏览记录里，GET 请求的 URL 可以保存为浏览器书签。这些都是 POST 请求所不具有的。缓存是 GET 请求被普遍应用的根本，他可以被缓存也是由于它的幂等性和安全性，除了返回结果没有其余多余的动做，所以绝大部分的 GET 请求都被 CDN 缓存起来了，大大减小了 Web 服务器的负担。
因为 Http 协议是无状态协议，若是客户经过浏览器访问 web 应用时没有一个保存用户访问状态的机制，那么将不能持续跟踪应用的操做。好比当用户往购物车中添加了商品，web 应用必须在用户浏览别的商品的时候仍保存购物车的状态，以便用户继续往购物车中添加商品。
cookie 是浏览器的一种缓存机制，它可用于维持客户端与服务器端之间的会话。因为下面一题会讲到 session，因此这里要强调 cookie 会将会话保存在客户端（ session 则是把会话保存在服务端）
这里以最多见的登录案例讲解cookie的使用过程：
1.首先用户在客户端浏览器向服务器发起登录请求
2.登录成功后，服务端会把登录的用户信息设置 cookie 中，返回给客户端浏览器
3.客户端浏览器接收到 cookie 请求后，会把 cookie 保存到本地（多是内存，也多是磁盘，看具体使用状况而定）
4.之后再次访问该 web 应用时，客户端浏览器就会把本地的 cookie 带上，这样服务端就能根据 cookie 得到用户信息了
session 是一种维持客户端与服务器端会话的机制。可是与 cookie 把会话信息保存在客户端本地不同，session 把会话保留在浏览器端。
咱们一样以登录案例为例子讲解 session 的使用过程：
1.首先用户在客户端浏览器发起登录请求
2.登录成功后，服务端会把用户信息保存在服务端，并返回一个惟一的 session 标识给客户端浏览器。
3.客户端浏览器会把这个惟一的 session 标识保存在起来
4.之后再次访问 web 应用时，客户端浏览器会把这个惟一的 session 标识带上，这样服务端就能根据这个惟一标识找到用户信息。
看到这里可能会引发疑问：把惟一的 session 标识返回给客户端浏览器，而后保存起来，之后访问时带上，这难道不是 cookie 吗？
没错，session 只是一种会话机制，在许多 web 应用中，session 机制就是经过 cookie 来实现的。也就是说它只是使用了 cookie 的功能，并非使用 cookie 完成会话保存。与 cookie 在保存客户端保存会话的机制相反，session 经过 cookie 的功能把会话信息保存到了服务端。
进一步地说，session 是一种维持服务端与客户端之间会话的机制，它能够有不一样的实现。
以如今比较流行的小程序为例，阐述一个 session 的实现方案：
1.首先用户登录后，须要把用户登录信息保存在服务端，这里咱们能够采用 redis。好比说给用户生成一个 userToken，而后以 userId 做为键，以 userToken 做为值保存到 redis 中，并在返回时把 userToken 带回给小程序端。
2.小程序端接收到 userToken 后把它缓存起来，之后每当访问后端服务时就把 userToken 带上。
3.在后续的服务中服务端只要拿着小程序端带来的 userToken 和 redis 中的 userToken 进行比对，就能肯定用户的登录状态了。
通过上面两道题的阐述，这道题就很清晰了
1.cookie 是浏览器提供的一种缓存机制，它能够用于维持客户端与服务端之间的会话
2.session 指的是维持客户端与服务端会话的一种机制，它能够经过 cookie 实现，也能够经过别的手段实现。
3.若是用 cookie 实现会话，那么会话会保存在客户端浏览器中
4.session 机制提供的会话是保存在服务端的。