一、讲一下 HTTP 与 HTTPS 的区别
HTTP 和 HTTPS 的主要区别在于 HTTP 协议传递的是明文数据，而 HTTPS 传递的是加密过的数据，也就是说 HTTPS 更具有安全性。也正由 HTTPS 需要保证安全性，所以它的性能要比 HTTP 差一点。
单说安全性肯定是不够的，我打算扩展讲一下 HTTPS 是怎么解决安全性问题的，通过这些 HTTP 没有机制，反映出 HTTPS 与 HTTP 的区别。下面尝试把 HTTPS 加密的过程推导出来。推导过程不涉及复杂的实现细节：如何安全地进行数据传输？
假设现在 A 和 B 要进行安全的通信，那么究竟怎样才算是安全的通信？很自然地会想到：A 和 B 之间传递数据，这些数据只有 A 和 B 才看得懂，中间人就算截取了信息但也看不懂，这才算得上安全。
安全通信的处理手段：
为了能让 A 和 B 才能看懂，就必须要对数据进行加密，而且首先想到的就是对称加密。对称加密的意思是 A 和 B 各持有一个相同的密钥，它们传递信息时会用密钥给信息加密，在消息到达端给消息解密，完成安全通信。
在对称加密中又会涉及到加密算法的选择问题。现实世界中，通常是多个客户端面向一个服务器的情况，不可能让每个客户端和服务器之间都采用相同的加密算法，如果是这样那和没加密差不多。所以注定每个客户端和服务器之间都会采用不同的加密方式。如何让每个客户端与服务器之间都采用不同的加密方式？
要想对不同的机器使用不同的加密方式，最直接想到的就是使用随机数。也就说客户端和服务器之间每次都基于一个随机数产生加密算法。（具体实现时为了保证随机，用到还不止一个随机数）
这个产生加密算法的过程称之为协商，现在问题是协商的过程是透明的，也就是说中间人可以截获协商的过程，从而知道我们的加密方式。为了解决这个问题，我们需要对协商的过程进行加密。如何对协商的过程进行加密？
之所以能来到这一步，是因为我们一开始就选择使用了对称加密，也就说一开始的对称加密导致了现在的问题，所以这时我们不能再使用对称加密了，否则会陷入死循环。
在密码学领域，还有一种加密过程叫非对称加密，它的逻辑是这样的：通信双方一方持有私钥，一方持有公钥，经过私钥加密的信息，都能通过公钥进行解密。但是经过公钥加密的数据，只有私钥可以解密。
按照非对称加密的规则，我们让服务器持有私钥，让客户端持有公钥。这样就能保证客户端给服务器发送消息的时候是安全的（相反，服务器给客户端发送消息就是不安全的），我们可以把协商时重要的逻辑安排在客户端给服务器发送信息的过程中，从而保证了协商过程的安全性。客户端如何获得公钥？
现在用非对称加密算法解决了协商的安全问题，但是非对称加密的前提是客户端需要获得公钥，这又是一个问题了，客户端与服务器打交道之前是互不知道双方身份的，怎么才能让客户端获得公钥呢？
也就只有两种办法：
客户端向服务器要公钥
客户端向一个远程的公共服务器获取公钥
方法2显然是不行的，尚且不说多了一个访问节点，如何找到公共服务器的地址也是一个待解决的问题，所以还是使用方法1。但是方法 1 存在一个问题：如果中间人把服务器发送给客户端的公钥调包了怎么办？也就是说客户端无法知道发送公钥的是否是正真的服务器。
引入第三方机构解决问题
客户端无法辨识服务端和中间人的问题称为“身份验证”问题，也就是说我们需要为服务器向客户端发送公钥的过程进行加密。
这下完了，之前我们因遇到对称加密的瓶颈选择了非对称加密，现在使用非对称加密也遇到了瓶颈。显然这两种加密方式都是不可用的了，否则会再次陷入死循环。
接下来我们只好通过第三方机构的介入，解决这个问题。首先我们自己保存有第三方权威机构的公钥，然后第三方机构使用私钥对服务器将要发送给客户端的公钥进行加密，客户端接收到这个经加密的公钥后（数字证书），就能通过自己保存的第三方机构公钥进行解密。
到这里为止，我们解释了 HTTPS 中使用到的对称加密，非对称加密，CA，数字证书的概念，但是还差一个叫数字签名的概念没有解释。
在现实生活中，CA 不单止会给我们正常公司发放证书，还会给中间人的坏公司发放证书，如果中间人把发放的证书调包了怎么办？这时我们仍能用 CA 的私钥进行解密，但是证书已经被调包了。
那么客户端怎样验证证书的真伪呢？答案是证书本身会告诉客户端如何辨认真伪。比方说证书上面有一个证书编号，还有一个如何计算证书编号的方法，客户端可以根据计算证书编号的方法计算出自己要获得的证书的编号，然后把这个编号和证书上的编号进行比对，如果一样证明没有被调包。
这里的证书编号指的就是数字签名，证书指的就是数字证书。
总结一下 HTTPS ：HTTPS 想要保证客户端与服务器之间的通信安全，就得使用对称加密算法进行加密。协商对称加密算法的过程通过非对称加密算法来保证。在非对称加密算法中，客户端获得公钥的过程需要第三方机构（CA）通过颁发数字证书保证安全性。
总得来说通过这一系列机制协商出了一个对称加密算法后，客户端与服务器之间就能通过该算法进行安全的通信了。
二、在地址栏键入 URL 后，网络世界发生了什么？
个人觉得这个问题还可以扩展一下，试想一下在键入 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 请求了，服务器接受到了请求会做出响应的响应，把请求的数据发送给本机浏览器，最终浏览器把服务器响应的数据渲染显示出来，我们就看到了五彩缤纷的网页。8、HTTP的常见状态码有哪些，代表什么含义？
首先状态码的开头不同代表不同的类型：
1xx：代表指示信息，表示请求已接收，继续处理
2xx：代表成功，表示请求已被成功接收，理解，接受
3xx：重定向，表示完成请求必须进行进一步的操作
4xx：客户端错误，请求有语法错误或请求无法实现
5xx：服务器端错误，服务器未能实现合法的请求 常见状态码：
200 OK：正常返回信息
400 Bad Request：客户端请求有语法错误，不能被服务器所理解
403 Forbidden：服务器收到请求，但是拒绝提供服务
404 Not Found：请求资源不存在，输入了错误的URL
500 Internal Server Error：服务器发生不可预期错误
503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常三、GET 请求和 POST 请求的区别
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 服务器的负担。
四、什么是 Cookie，Cookie 的使用过程是怎么样的？
由于 Http 协议是无状态协议，如果客户通过浏览器访问 web 应用时没有一个保存用户访问状态的机制，那么将不能持续跟踪应用的操作。比如当用户往购物车中添加了商品，web 应用必须在用户浏览别的商品的时候仍保存购物车的状态，以便用户继续往购物车中添加商品。
cookie 是浏览器的一种缓存机制，它可用于维持客户端与服务器端之间的会话。由于下面一题会讲到 session，所以这里要强调 cookie 会将会话保存在客户端（ session 则是把会话保存在服务端）
这里以最常见的登陆案例讲解cookie的使用过程：
1.首先用户在客户端浏览器向服务器发起登陆请求
2.登陆成功后，服务端会把登陆的用户信息设置 cookie 中，返回给客户端浏览器
3.客户端浏览器接收到 cookie 请求后，会把 cookie 保存到本地（可能是内存，也可能是磁盘，看具体使用情况而定）
4.以后再次访问该 web 应用时，客户端浏览器就会把本地的 cookie 带上，这样服务端就能根据 cookie 获得用户信息了
五、什么是 session，有哪些实现 session 的机制？
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 进行比对，就能确定用户的登陆状态了。
六、session 和 cookie 有什么区别
经过上面两道题的阐述，这道题就很清晰了
1.cookie 是浏览器提供的一种缓存机制，它可以用于维持客户端与服务端之间的会话
2.session 指的是维持客户端与服务端会话的一种机制，它可以通过 cookie 实现，也可以通过别的手段实现。
3.如果用 cookie 实现会话，那么会话会保存在客户端浏览器中
4.session 机制提供的会话是保存在服务端的。
