学习自：xiaolincoding.com
前言
HTTP是应用层非常重要的一个协议，不管是考试还是面试，都有很大概率考到。本文给出了关于HTTP的一些高频问题及简单解答思路，读者可以在思路的基础上，查阅资料然后自行进行细化。本文大部分问题都来自于图解网络介绍 | 小林coding (xiaolincoding.com)，如果没有看过的读者建议先阅读小林图解系列，等到临时抱佛脚时，再阅读本文章加深印象。
问题
1.HTTP是什么？
HTTP全称是HyperText Transfer Protocol，也就是超文本传输协议。超文本指的是超越了普通文本的文本，其中包括文字、图片、视频等。传输协议是指是两个实体间进行信息传输的规范和标准。所起合起来，HTTP就是一个定义了两个实体间传输包括文字、图片、视频等超文本数据的标准和规范。
2.HTTP常见状态码有哪些？
1xx为提示信息，表示目前协议还处于中间状态，还需要一些额外的操作。
2xx为成功信息，报文被收到且正确处理了。
3xx为重定向信息，需要客户端重新访问重定向后的地址。
4xx为客户端错误，发送的请求有误，服务端无法请求。
5xx为服务器错误信息，服务器内部发生了一些错误
3.HTTP常见字段有哪些？
**Host 字段：**域名。
**Content-Length 字段：**表示此次响应消息的长度。
**Connection 字段：**如果值是Keep-Alive，则表示这是一个长连接，当客户端发送请求时，会使用一个长连接，直到某一方断开链接。
**Content-Type 字段：**表示响应信息的格式
Content-Encoding 字段：表示响应信息的压缩格式。
4.GET 和 POST 有什么区别？
从RFC规范来说，GET用于请求某个资源，是只读的。POST包含一个body，请求对服务器上的某些资源做出处理。
GET的参数通常在URL里面包含了，POST的参数通常在body里面。但是并不是说POST包含在body里面数据就安全了，攻击者仍可以截获POST的body，获取里面的数据，所以想要安全通信，需要使用https。
5.GET和POST是安全和幂等的嘛？
安全指的是请求不会破坏服务器上的一些资源。幂等是指相同的请求多次发送给服务器，会获得相同的结果。
根据规范来说，GET是安全和幂等的，因为GET请求是一个只读的请求，不会对服务器资源产生一些额外的修改。POST请求是不安全且部幂等的，因为POST请求对服务器上的一些资源做出一些处理。
但是如果部按照规范来做的话，GET也可以包含一些对服务器进行修改的请求，这取决于服务器的代码编写。
6.HTTP 缓存有哪些实现方式 ？
对于一些变化很少的数据，没必要每次都去服务器请求，而是可以缓存在本地，在下次请求的时候直接进行展示。
HTTP的实现方式主要有强制缓存（主动缓存）和协商缓存。
7.什么是强制缓存 ？
强制缓存的意思是，只要浏览器判断某一个请求可以使用本地的缓存，就会直接使用本地的数据，而不会发送数据给服务器，由于是否使用缓存的决定权在浏览器，所以也叫做主动缓存。
强制缓存通过以下两个字段完成：
Cache-Control， 是一个相对时间；Expires，是一个绝对时间；
具体流程如下：
-
用户第一次通过浏览器发送请求给服务器时，服务器返回请求时可以设置这两个字段，表示返回的资源过期时间。
-
在浏览器第二次发送相同的请求，可以查看之前的请求的这两个字段，检查缓存是否过期了，如果没过期就直接使用本地的数据，如果过期了才会再次请求
-
服务器再次接受到请求后，可以重新设置这两个字段进行返回。
8.什么是协商缓存 ？
有些请求的响应码是304，这代表服务器告诉客户端，可以使用本地的某个资源，这种服务端告诉浏览器是否可以使用缓存的方式叫做协商缓存。一般通过请求头部中的 If-Modified-Since 字段与响应头部中的 Last-Modified 字段实现协商缓存。
9. HTTP/1.1 的优点有哪些 ？
- 跨平台，只要实现HTTP协议，就可以使用HTTP协议进行通信交互。
- 简单，上手很快。
- 灵活且易于扩展，是一个应用层协议，底层的协议可变，比如加上TLS握手
10. HTTP/1.1 的缺点有哪些 ？
- 不够安全，明文传输，无法校验消息完整新，且没有校验服务器的身份的过程。
- 无状态，完成一些有关联性的操作时比较麻烦。但是可以使用cookie技术进行解决，在每次请求的时候带上cookie，服务器就知道上次交互的一些信息了。
11. HTTP/1.1 的性能如何 ？
性能比较一般，但是对比HTTP/1.0已经有了很大的改善。
- 长连接
HTTP/1.0 每发送一次请求就要经历一次三次握手、四次挥手的操作，时间和资源消耗都很大。HTTP/1.1采用长连接，在三次握手后，可以在一轮TCP通信中，客户端和服务端可以进行多次HTTP协议的交互，直到某方主动断开链接，或者时间太长后，服务器主动断开链接。
- 管道传输和队头阻塞
实现长连接后，客户端就可以一次性顺序发送多个请求给服务端，而不同于老版本，只有等到每次响应回复后，才能发出下一个请求。但是在服务器端还是只能一个请求一个请求的进行处理，当顺序发送的请求中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会导致客户端一直请求不到数据，这也就是队头阻塞。
后续的HTTP/2.0和HTTP/3.0主要就是针对HTTP/1.1的性能进行优化。
12. HTTP 与 HTTPS 有哪些区别 ？
-
HTTP不安全，HTTPS通过一些密码学的方案在HTTP的基础上添加了SSL/TLS安全协议，主要实现了完整性校验、服务端身份认证、数据加密的功能。
-
HTTP只需要TCP三次握手之后就可以进行数据的传输，HTTPS还需要SSL/TLS 的握手过程才能进行传输
-
两者的端口不一样，HTTP是80端口，HTTPS是443端口
13. HTTPS 解决了 HTTP 的哪些问题？
- 数据传输时。使用混合加密算法，实现机密性，使用非对称加密算法完成密钥交换，使用对称加密算法完成后续的对话。
- 使用哈希函数保证整个内容无法被纂改。
- 使用数字证书机制保证服务端的真实性，避免中间人攻击。
14. HTTPS 是如何建立连接的？其间交互了什么？
建立链接的时候主要有三个目标：
- 客户端验证服务端证书，获取服务端正确的真实的公钥
- 基于非对称密码交换对称会话密钥
- 使用会话密钥在后续的交互中完成加密通信
15. HTTPS 的应用数据是如何保证完整性的？
**保证完整性的核心，就是哈希函数。**具体来讲，就是首先把消息分割成多个分片，然后对每个分片进行压缩，再对每个压缩后的分片使用哈希函数变成MAC识别码，后续验证MAC码就可以识别这个数据是否被篡改过。
16. HTTPS 一定安全可靠吗？
从协议的角度讲，目前是很安全可靠的，这个安全的来源是密码学原理，比如离散对数问题就保证了从公钥无法推出私钥等，所以只要密码学难题没被破解，那么HTTPS就没有安全问题。
但是有时候有些针对服务器或者针对客户端的攻击会导致安全出现问题，具体来说，比如服务器的私钥被泄露了，那么攻击者就可以伪装成服务器去和客户端进行通信，也就是中间人攻击。针对客户端的话，如果客户端的机器上，根证书库被修改了，被添加了某个恶意节点的证书，那么恶意节点就可以伪装成正常节点来与客户端进行通信。
17. HTTP/1.1 相比 HTTP/1.0 提高了什么性能？
- 使用了长连接，不需要每次请求都经历三次握手和四次挥手的过程。
- 采用管道机制，可以一次发送很多请求，而不需要实时的等到回复了再发送下一个请求。
但是目前还有一些问题。
- 头部没有压缩，首部越大越慢；
- 请求只能从客户端开始，服务器只能被动响应；
- 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
18. HTTP/2 做了什么优化？
主要完成了以下工作：
- 头部压缩
- 二进制格式
- 支持stream，也就支持了并发传输
- 服务器可以主动推送工作
1.头部压缩
HTTP/2会进行头部压缩，如果连续的请求，有相同的请求头，就会删除重复的部分。
2.二进制格式
HTTP/1.1中的字段都是字符串结构，而在HTTP/2中，将一部分的字段变成了二进制位（标志位）
3.支持Stream，并发传输，服务器主动推送
在HTTP/1.1中，一个TCP链接里面，请求只能一个一个的处理，如果某个请求处理的速度很慢，那么后面的请求就会阻塞，这就是队头阻塞。
HTTP/2中，引入了Stream的概念，多个Stream复用一个TCP链接。
针对不同的HTTP请求，可以封装成一个个不同的Stream，每个 Stream 有不同的 Stream ID ，可以并发的进行传输，然后并发的接受，后面可以通过Stream ID进行请求和响应的组装。
对于服务器来说，可以主动的建立一个Stream，发送给客户端，客户端建立的Stream为奇数，服务器的为偶数。
目前来说,HTTP/2由于底层使用的是TCP协议，所以性能限制上，主要是由于TCP协议的性能限制，比如TCP保证收到的字节必须是完整的，就会导致后续的请求已经到了，但是前面的请求还没接收到，TCP就不会将数据往上层进行交付。
19. HTTP/3 做了哪些优化？
HTTP/3最大的改变就是将底层的TCP协议改成了UDP协议，同时在应用层实现了QUIC（发音为“quick”），提高性能。目前HTTP/3的RFC已经发布，但是普及率仍不高。
20.HTTP/1.1 优化思路？
- 减少发送请求的次数
- 减少服务器端响应的大小
针对第一个思路，首先可以大量使用缓存的思想，对于一些静态数据，多将数据保存在本地，就可以减少很多发送请求的次数。其次，在客户端，可以将原本想要多次请求的小文件们，合并成一个一个请求，一次请求一个大资源，比如将多个图片使用BASE64进行编码后，就可以一次性传输多个图片了。最后还可以延迟发送请求，也就是说，对于一些不是很必须的资源，暂时不发送请求，等需要的时候，再向服务器进行请求。
针对第二个思路，就是压缩，压缩分为无损压缩和有损压缩，这个要根据具体的业务场景选择合适的，如果业务场景对数据的精度没那么高，比如一些小的贴图，那么可以使用有损压缩，大幅减少数据量。
21.HTTPS如何优化？
HTTPS是基于HTTP添加了一层TSL,主要实现了：
- 证书认证，客户端需要检验服务器的证书来确认真实身份。
- 使用混合密码机制，即使用非对称密码学来交互对称秘钥，ECDHE。
- 后续使用对称秘钥进行加密通信
首先考虑一些常见的优化方案：
- 硬件优化，即使用支持高效加解密的硬件支持，提升速度。
- 软件优化，优化一些算法
还可以针对以上HTTPS增加的三点分别进行优化：
针对证书来说，首先可以减少证书的大小，即可以使用椭圆曲线加密，因为相同的安全性下，椭圆曲线参数所需要的字节数更少，其次可以减少证书校验时的步骤，传统校验的时候要查验证书链，且要下载证书吊销列表，查看证书是否过期。可以改为，查询证书状态。服务器定期向CA查询证书状态，然后CA会返回带签名的状态，所以，服务器在返回客户端的请求时，带上有CA签名的证书状态，就可以直接进行校验了，避免了繁琐的证书链查询过程。
针对秘钥交换算法来说，尽量使用椭圆曲线加密来交换，可以增加速度，且TLS升级后握手可以从4次改成3次。
针对对称秘钥来说，如果每次请求都需要协商一些会话秘钥的话，就会非常的麻烦，为了解决这种情况，可以采取，session ID的方案，就是客户端和服务端都会保存这个秘钥，然后通过Session ID来标识，下次传输时，用户就可以带上session ID，服务端查询Session Id 的状态，如果仍存在的话，就直接通过此对称秘钥进行后续通信。还可以使用Session Ticket方案，即服务端使用自己的某个秘钥对对称秘钥进行加密，然后传输给客户端，客户端下次传送的时候，将这个加密后的秘钥和使用此秘钥加密的消息传回来，服务端如果能使用自己的秘钥对消息进行解密，且解密后的秘钥能正常使用，皆可使用此秘钥进行直接通信，避免了服务端要维护很多个客户端的对称秘钥。为了保证安全性，要注意设置一个过期时间。
22. 有HTTP协议后，为什么还需要RPC协议
HTTP和大部分的RPC协议目前都是基于TCP的，所以要先讲讲TCP协议。TCP只提供了可靠的，面向连接的，基于字节流的服务，对于上层来说，只能看到字节流，即消息是没有边界的。所以基于TCP就出现了RPC和HTTP，这两个实际上是两个不同的方向，HTTP出现，主要是为了适应浏览器，因为各个公司的主页不一样，用的技术也有差异，为了能在同一个浏览器上显示出来，所以就都用HTTP。而RPC目前主要用于公司内部，特别是现在APP和客户端兴起之后，RPC协议因为定制性更强，可以针对性的优化，定制化的开发每个公司内部的通信协议，提升性能。所以来说，两者是两个方向，所以都需要。
23. 有 HTTP 协议，为什么还要有 WebSocket？
WebSocket主要是为了实现双方的全双工通信，即服务器可以主动推送消息给客户端。
实现服务器主动推送给客户端信息，如扫码登录，有哪些实现方式呢？
-
不断轮询。即客户端不断的向服务器发送请求，直到服务器返回扫码成功登录的信息。
-
长轮询。客户端向服务器发送一个请求，等待一个较长的时间，如果时间结束没有成功则再发送一个请求。直到返回成功信息。
-
使用WebSocket协议进行通信。WebSocket和HTTP一样都是基于TCP的协议。其经历了三次TCP握手之后，利用 HTTP 协议升级为 WebSocket 协议。后续的通信使用WebSocket协议的格式。