注释：本文章架构跟随小林coding，在此基础上加深个人理解
小林coding：https://xiaolincoding.com/network/2_http/http_interview.html
HTTP基本概念
HTTP是什么？
http的中文名是超文本传输协议，超文本就是html，css，照片视频等不仅限于文档的资源，他是一个在计算机世界专门在两点间传输超文本数据的约定和规范，为什么说两点，因为不止是客户端和服务端之间传输，也可以是服务端之间传输。
HTTP常见的状态码？
状态码可以分为五大类
|-------|------------------------------|-----------------|
| 类别 | 含义 | 常见状态码 |
| 1** | 提示信息，表示目前是协议处理的中间状态，还需要后续的操作 | |
| 2** | 成功，报文已经收到并被正确处理 | 200 204 206 |
| 3** | 重定向，资源位置发生变动 | 301 302 304 |
| 4** | 客户端错误，请求报文有误，服务器无法处理 | 400 403 404 |
| 5** | 服务器错误，服务器在处理请求时内部发生错误 | 500 501 502 503 |
HTTP常见字段有哪些？
**Host:**表示请求的域名
Content-Length：服务器响应数据的长度
Connection:如果这个字段的值为Keep-Alive,说明开启长连接，所谓长连接，就是只用进行一次TCP握手，然后就可以在发生中断请求以前进行没有次数限制的HTTP请求响应，HTTP1.1默认都是开启的，但是老版本需要手动设置。
Content-Type:表示服务器响应数据的格式
GET与POST
GET和POST的区别？
GET在RFC规范里是从服务器获取指定的资源，一般是只读操作，而且参数是在url中的，而且浏览器会对url长度作出限制，而POST是根据请求报文中的内容对指定资源做出处理，参数是写在报文body中，且无长度限制。
GET和POST方法都是安全和幂等吗？
先说安全，从两个方面来讲，第一点是对于我们使用者来讲，我们要发送的数据安全吗？显然使用get是最不安全的，因为我们的参数信息就在url路径中，有眼睛就可以看到，难道post就是安全的吗？对一些懂行的人来说，也不安全，因为在http报文中的信息是明文，也就是未经加密的数据。另一个人角度就是对于服务器的资源来讲，使用get请求，因为是只读操作，所以并不会对服务器的资源造成影响，是安全的，对于post请求来讲就不是了，因为他会对服务器的资源造成修改，所以不安全。当然按照这个角度安不安全取决于你对于服务器资源的操作，只读就安全，更新就不安全。
再说幂等，什么是幂等？就是多次操作，可以获得同一个结果，显然易见，get幂等，因为只读，post非幂等，因为更新，当然这些说法是按照RFC规定的，在现实中谁会管你怎么操作呢？所以安不安全，幂不幂等，取决于你对服务器资源的操作。
HTTP特性
HTTP1.1的优点有哪些？
首先HTTP1.1的优缺点可以一起说，可以说是一把双刃剑
第一点：无状态，所谓无状态，就是客户端信息不会存储在服务器，这极大的节省了服务器的资源，但是也面临一些问题，比如对一些需要连续验证客户端权限的操作：注册-登录-购买-付款等等，这就需要在每一步的操作中都要去对客户端的权限进行校验，但是这个问题已经有解决办法了，就是Cookie，这个就不介绍了，之前的文章已经介绍过了，一个携带SessionID的存储机制。
第二点：明文传输，明文传输的最大优点方便查阅，但同时这也是他的最大缺点，会在下一章讲解解决方法。
还有一个优点就是HTTP1.1结构简单，头部header+报文body，而且参数是key-value形式。
HTTP1.1的缺点有哪些？
缺点就是明文传输，相当于裸奔，不穿衣服，解决方案就是使用加密协议，SSL/TSL加密协议，这是HTTPS协议和HTTP协议最本质的区别，SSL/TSL协议是怎么加密的呢？对称与非对称混合机加密，现在说有点晦涩，但是后文会讲解。
HTTP/1.1的性能如何？
长连接：在HTTP1.0采用的是串行请求，即短连接，在一次请求-响应之后，需要重新建立TCP三次握手，这就麻烦了，所以1.1采用了长连接的形式，也就是只要进行一次TCP三次握手，就可以进行多次的请求-响应，除非进行终端请求。
管道传输：因为采用了长连接，这使得管道传输成为了可能，使用管道传输，就可以不用等待上一次请求的响应，就可以直接进行第二次请求，可以减少整体的响应时间，但是这也带来了另一个问题，就是队头阻塞，假如服务器处理我的第一个请求时间很长，那么后续的请求就被阻塞了，这就是对头阻塞。
HTTP缓存技术
HTTP缓存的实现方式？
强制缓存，协商缓存
强制缓存（强缓存）
浏览器判断通过HTTP头部的字段（Cache-Controller，expire）判断本地缓存的资源是否过期，若果没有过期，则可以使用，使用缓存的主动性在浏览器。状态码为200，则表示使用了强缓存。
协商缓存（弱缓存）
如果本地缓存的资源过期，那么就要浏览器就要和服务端进行协商，服务端要判断缓存资源和服务器资源是否一致，如果一致，接着使用，若不一致，返回新的资源。状态码为304，则表示使用了弱缓存。
HTTP与HTTPS
二者的区别
HTTPS在HTTP的基础上使用了SSL/TLS协议，HTTP端口为80，HTTPS端口为443，HTTPS使用了CA，数字签名的技术。
HTTPS解决了HTTP哪些区别？（对称和非对称算法）
解决了明文传输所带来的安全问题：信息加密，校验机制，安全证书。那是怎么解决的呢？
先说信息加密，TSL采用对称和非对称混合算法进行加密，先介绍一下什么是对称和非对称算法：
对称算法：采用相同的私钥进行加密和解密，这个私钥必须保密，不安全但快。
非对称算法：采用公钥和私钥，公钥公开，私钥私密，安全但慢，加密和解密没有规定使用哪个钥匙，使用不同的钥匙会有不同的效果，第一种情况：使用私钥加密，公钥解密，如果公钥可以解密，就可以确定发送方的正确性，因为私钥不可泄露，也保证了消息来源的正确性。第二种情况：使用公钥加密，私钥解密，保证了内容传输的安全，因为如果使用私钥解密成功，就确保了该内容是由配对的公钥进行加密的。
再说校验机制，校验机制的核心是哈希算法+数字签名，所谓哈希算法，就是对发送的内容计算一个哈希值，而且不能通过哈希值推导出内容，服务端会通过相同的哈希算法计算出收到内容的哈希值，这不就是我们之前说的对称加密吗，这个哈希算法就是密钥，然后比较这个哈希值是否相同，但是如果内容和哈希值都被篡改了呢？这种情况是很可能发生的，所以服务端为了杜绝这个隐患，就要判断发送方的正确性，就要使用到非对称算法，使用私钥对哈希值进行加密，这就是数字签名，然后将内容和数字签名一起发送给服务器。
过程如下：
然后是安全证书，现在又出现一个问题，如果这对公私钥被伪造，是不是又出现新的问题了，所以这对钥匙该如何保证合法性呢，这就引入了安全证书，为什么安全证书有这么大本事呢，因为是一个叫做CA的机构颁发的，类似于发身份证的警察局，没有人会质疑吧。这份安全证书包括了：内容+公钥+数字签名，服务器拿到证书后，会校验其合法性，所以就不用担心公私钥被伪造了。
HTTPS是如何建立连接的？
首先客户端向服务端索要并验证加密的公钥，然后双方协商会话的私钥，然后使用私钥进行通信，前两步就是TLS的握手阶段。
HTTP的演变
HTTP1.1相比于HTTP1.0提高了什么性能？
HTTP1.1采用了长连接，不必经常建立TCP连接，减少了开销，而且HTTP1.1实现了管道传输，发送请求可以连续发送，不必等前一个请求响应，但是有可能会造成服务端阻塞。
HTTP2做了什么优化
HTTP2实现了并发传输，在管道通信中又引入了流的概念，缓解了服务端对头阻塞的问题。HTTP2的报文采用了二进制的数据，摒弃了HTTP1.1报文的纯文本格式，增加了传输效率。
HTTP3做了什么优化
在之前版本的HTTP协议中不管怎么样，我们都会面临阻塞的问题，根本原因是HTTP所依赖的TCP协议，所以HTTP3使用了UDP协议，解决了阻塞的问题。