1。说说HTTP和HTTPS的区别HTTP和HTTPS的主要区别在于HTTP协议传输的是明文数据，而HTTPS传输的是加密数据，也就是说HTTPS更安全。也是因为HTTPS需要保证安全，所以它的性能比HTTP差一点。光谈安全肯定是不够的。打算展开讲讲HTTPS是如何解决安全问题的。通过这些HTTP，没有任何机制，体现了HTTPS和HTTP的区别。下面我们来尝试推导一下HTTPS加密的过程。推导过程不涉及复杂的实现细节：如何安全传输数据？假设现在A和B要安全通信，那么安全通信到底是什么？很自然地会想到：A和B传输数据，只有A和B能看懂数据，即使中间人截获了信息也看不懂，这也算是安全的。安全通信的处理方式：为了让A和B都能理解，必须对数据进行加密，首先想到的就是对称加密。对称加密意味着A和B各自持有相同的密钥。他们在传输信息时，会使用密钥对信息进行加密，并在消息到达端对消息进行解密，完成安全通信。在对称加密中，会涉及到加密算法的选择。在现实世界中，通常是多个客户端面对一个服务器的情况。每个客户端和服务器之间不可能使用相同的加密算法。如果是这样的话，那几乎就和没有加密一样了。所以就注定了各个客户端和服务器之间使用不同的加密方式。如何在每个客户端和服务器之间使用不同的加密方式？如果你想对不同的机器使用不同的加密方式，你能想到的最直接的就是使用随机数。也就是说每次在客户端和服务端之间，加密算法都是根据一个随机数生成的。（在具体实现中为了保证随机性，使用了多个随机数。）生成加密算法的过程称为协商。现在的问题是协商过程是透明的，也就是说中间人可以拦截协商过程，知道我们的加密方式。为了解决这个问题，我们需要对协商过程进行加密。如何加密谈判过程？之所以能走到这一步，是因为我们一开始就选择了使用对称加密，也就是说一开始的对称加密导致了现在的问题，所以此时不??能再使用对称加密，否则我们将陷入死循环。在密码学领域，还有一种加密过程叫做非对称加密。它的逻辑是这样的：通信双方其中一方持有私钥，另一方持有公钥。用私钥加密的信息可以用公钥解密。.但是，只有私钥才能解密公钥加密的数据。根据非对称加密的规则，我们让服务端持有私钥，让客户端持有公钥。这样就可以保证client向server发送消息是安全的（反之，server向client发送消息是不安全的），我们可以安排重要的逻辑客户端向服务器端发送信息过程中的协商过程。从而保证了协商过程的安全性。客户端如何获得公钥？现在采用非对称加密算法来解决协商的安全问题，但是非对称加密的前提是客户端需要获得公钥。让客户端拿到公钥？只有两种方式：客户端向服务器请求公钥，客户端从远程公共服务器获取公钥。方法2显然是行不通的，且不说多了一个接入节点，如何找到公共服务器的地址也是一个需要解决的问题。问题解决了，所以还是用方法一。但是方法一有个问题：如果中间人把服务端发来的公钥传给客户端怎么办？也就是说，客户端无法知道发送的公钥是否是真正的服务器端。引入第三方机构解决问题客户端无法识别服务器和中介的问题称为“认证”问题，也就是说我们需要对服务器向客户端发送公钥的过程进行加密.一切都结束了。之前遇到对称加密的瓶颈我们选择的是非对称加密，现在使用非对称加密也遇到了瓶颈。显然，这两种加密方式是不行的，否则又会陷入死循环。接下来，我们只好通过第三方机构的介入来解决这个问题。首先，我们保存第三方机构的公钥，然后第三方机构使用私钥加密服务器发送给客户端的公钥。客户端收到加密后的公钥（数字证书）后，可以用您保管的第三方机构的公钥进行解密。至此，我们已经解释了HTTPS中使用的对称加密、非对称加密、CA、数字证书等概念，但是还有一个叫做数字签名的概念没有解释。现实生活中，CA不仅会给我们正常的公司发证书，还会通过中间人给不好的公司发证书。如果中间人重新打包颁发的证书怎么办？这个时候我们还是可以用CA的私钥解密，但是证书已经被打包了。那么客户端如何验证证书的真伪呢？答案是证书本身会告诉客户端如何鉴别真伪。比如证书上有证书编号，还有如何计算证书编号的方法。客户端可以根据证书编号的计算方法计算出自己想要获取的证书编号，然后将这个编号与证书上的编号进行比较，如果相同，则证明没有被转移。这里的证书号是指数字签名，certificate是指数字证书。总结一下HTTPS：HTTPS要想保证客户端和服务器端的通信安全，就必须使用对称加密算法进行加密。协商对称加密算法的过程由非对称加密算法保证。在非对称加密算法中，客户端获取公钥的过程需要第三方机构（CA）通过签发数字证书来保证安全。一般来说，通过这一系列机制协商出一个对称加密算法后，客户端和服务端就可以通过这个算法进行安全的通信了。2.在地址栏中输入网址后，网络世界会发生什么？个人觉得这个问题可以展开。试想一下，在输入网址之前，也就是电脑刚开机的时候，需要先连接到互联网，然后才能上网。这个阶段包括获取机器的IP地址，获取DNS服务器的IP地址，获取网关路由器的IP和MAC地址等，这些一起回答会不会更好？以下是答案：获取本机IP地址、DNS服务器地址、网关路由器地址。首先我们需要准备一个DHCP报文，封装在一个UDP报文段中，其中包括本地端口号68和目的端口号67，然后在网络层封装成一个数据包，其中包括机器的初始IP0.0.0.0和广播地址255.255.255.255。然后在链路层封装成链路层帧。它包括本地网卡的广播地址和MAC地址。最后发送到局域网。这个数据包最终会被局域网中的DHCP服务器发现（可能有多个DHCP服务器），DHCP服务器会将可用的IP地址返回给我们的主机。然后操作系统选择一个IP地址发送给DHCP服务器，最后DHCP服务器返回一个包含本地IP、DNS服务器IP和网关路由器IP的消息。接下来我们需要通过网关路由器的IP地址获取网关路由器的MAC地址，这样我们就可以从网关向DNS服务器发送DNS请求报文获取网站IP。这时我们需要准备一个ARP请求报文，请求网关路由器的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首先生成一个没有任何数据的TCP报文，SYN标志为1，sequencenumber字段假设为client_num.经过一系列的网络栈，发送到目的ip服务器。服务器收到TCP请求报文后，会回应一个同意连接的TCP报文。该报文的SYN标志位也会被设置为1，序号字段假设为server_num，ACK响应字段为client_num+1。我们的主机收到同意连接的报文后会进行响应。这次TCP报文的SYN位会被设置为0，序列号字段为client_num+1，ACK响应字段为server+1。此时响应报文可以携带数据。建立连接后，建立数据交互。三向握手建立连接后，机器可以向服务器发送HTTP请求。服务器将响应请求并将请求的数据发送到本地浏览器。最后，浏览器向服务器发送HTTP请求。显示服务器响应的数据渲染，我们看到了五颜六色的网页。8、HTTP常见的状态码有哪些，分别代表什么意思？首先，不同开头的状态码代表不同的类型：1xx：代表指令信息，表示已经接收到请求，继续处理2xx：代表成功，代表成功接收、理解、接受请求3xx：重定向，表示请求必须进一步处理操作4xx：客户端错误，请求有语法错误或请求无法执行5xx：服务器端错误，服务器未能执行合法请求常见状态码：200OK：正常返回信息400BadRequest：客户端请求有语法错误，服务器无法理解403Forbidden：服务器收到请求，但拒绝提供服务404NotFound：请求的资源不存在，并且wrongURLwasentered500InternalServerError:服务器发生意外错误503ServerUnavailable:服务器当前无法处理客户端的请求Request，过一段时间可能会恢复正常3.GET请求和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服务器的负担。4、什么是cookie，使用cookie的过程是怎样的？由于Http协议是无状态协议，如果客户端在通过浏览器访问Web应用时没有保存用户访问状态的机制，将无法持续跟踪应用的运行情况。例如，当用户将商品添加到购物车时，Web应用程序必须在用户浏览其他商品时仍然保存购物车的状态，以便用户可以继续将商品添加到购物车。cookie是浏览器的一种缓存机制，可以用来维持客户端和服务器之间的会话。由于后面的问题会讲session，所以这里要强调一下，cookies会在client端保存session（session会在server端保存session）。下面以最常见的登录案例来说明cookies的使用：1.首先，用户登录客户端浏览器向服务器端发起登录请求2.登录成功后，服务器端会设置登录用户信息在cookie中返回给客户端浏览器3.客户端浏览器收到cookie请求后，会把cookie保存到本地（可以是内存也可以是磁盘，根据具体使用情况而定）4.再次访问web应用时以后客户端浏览器会带上本地的cookie，这样服务器就可以根据cookie获取用户5、什么是session，session的实现机制有哪些？会话是一种在客户端和服务器之间维护会话的机制。但与cookie在客户端本地保存session信息不同，session在浏览器端保存session。我们同样以登录案例为例，说明一下session的使用过程：1.首先用户在客户端浏览器发起登录请求2.登录成功后，服务器会将用户信息保存在服务器上并返回客户端浏览器的唯一会话ID。3.客户端浏览器将保存这个唯一的会话ID。4、以后再次访问web应用时，客户端浏览器会带上这个唯一的sessionID，这样服务器就可以根据这个唯一的ID信息找到用户。看到这里可能会产生疑问：把唯一的sessionID返回给客户端浏览器，然后保存起来，以后访问的时候带上。这不是饼干吗？没错，session只是一种会话机制。在很多web应用中，session机制是通过cookie来实现的。也就是说，它只是利用了cookies的功能，并没有利用cookies来保存session。与cookies在客户端保存session的机制相反，session是通过cookies的作用将session信息保存到服务端的。再者，session是一种维持服务端和客户端之间会话的机制，它可以有不同的实现。本文以流行的小程序为例，描述一个session的实现方案：1、首先，用户登录后，需要在服务器上保存用户登录信息。这里我们可以使用redis。比如为用户生成一个userToken，然后以userId为key，将userToken作为value保存在redis中，返回时将userToken带回给小程序。2、小程序收到userToken后缓存起来，每次访问后端服务时都带上userToken。3、在后续服务中，服务端只需要将小程序带来的userToken与redis中的userToken进行比对即可判断用户的登录状态。6、session和cookie有什么区别上面两个问题解释完后，这个问题就很清楚了1.cookie是浏览器提供的一种缓存机制，可以用来维持客户端和服务端的会话2.session是指一种维持客户端与服务器端会话的机制，可以通过cookies或者其他方式实现。3.如果session是用cookie实现的，session会保存在客户端浏览器中。4、session机制提供的session保存在server端。面试指导视频教程：https://www.3mooc.com/front/learning/routesecond?subjectid=1232
