HTTP常见的状态响应码
2XX：一般都表示成功
- 200（OK）：服务器成功处理了客户端的请求
- 204（No Content）：与200相同，只不过响应的Body里面没有数据
- 206（Partial Content）：应用于HTTP分块下载和断点续传，表示响应的Body是部分资源
3XX：一般表示客户端请求的资源发生了变动，客户端需要用新的URL再次访问
- 301（Moved Peromanently）：永久重定向，请求的资源不存在，使用新的URL访问
- 302（Not Found）：临时重定向，请求的资源还在，暂时使用另一个URL访问
- 304（Not Modified）：表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制
301和302都会在响应头里使用Location字段，指明后续要跳转的URL
4XX：表示客户端发送的报文有错误
- 400（Bad Request）：表示客户端请求的报文有错误
- 403（Forbidden）：服务器禁止访问资源
- 404（Not Found）：客户端请求的资源未找到
5XX：服务器内部处理错误
- 500（Internal Server Error）：服务器内部错误
- 501（Not Implemented）：客户端请求的功能不支持
- 502（Bad Gateway）：服务器自身工作正常，但访问后端服务发生错误，通常是服务器作为网关或代理时返回（比如Nginx）
- 503（Service Unavailable）：服务器繁忙，无法响应
Http的常见字段
Request Headers
- Host：服务器域名
- Connection：HTTP/1.1默认都是长连接，为了兼容老版本HTTP，指定此字段的值为keep-alive
- Accept：客户端指定自己能够接收的数据格式
- Accept-Encoding：客户端指定自己能够接收的数据压缩方式
Response Headers
- Content-Length：服务器响应数据的长度
- Content-Type：告诉客户端服务器返回的数据格式
- Content-Encoding：告诉客户端服务器返回的数据使用的压缩格式
HTTP请求方式的幂等性？
- GET：幂等
- PUT：幂等
- DELETE：幂等
- POST：不幂等
HTTP的优点
- 简单：报文就是header body，形式就是key-value
- 灵活易于扩展：HTTP请求中的各个字段都没有被固定死，允许自定义扩展
- 跨平台
HTTP的缺点
- 无状态：无法记录一些用户登录信息，一些关联的操作比较麻烦（购物车）
- 不安全
HTTP不安全表现
- 明文传输，内容被窃听，导致账号信息容易泄漏
- 不验证通信双方身份，容易遭遇伪装，比如访问假的拼夕夕
- 无法验证报文完整性，内容被篡改，比如网页植入广告
HTTP与HTTPS的区别
- HTTP明文传输不安全，HTTPS在TCP和HTTP之间引入SSL/TLS协议可以加密传输
- HTTP连接建立简单，TCP三次握手以后便可以传输，HTTPS需要在TPC三次握手以后进行SSL/TSL握手，成功以后才可以传输
- HTTP的端口是80，HTTPS是443
- HTTPS需要向CA申请数字证书，用来验证服务器身份可靠
HTTPS如何解决安全问题
- 混合加密解决窃听风险：通信建立前使用非对称加密交换会话密钥，通信过程中使用对称加密加密数据
- 摘要算法保证数据完整性
- 数字证书保证服务器可靠
SSL/TLS的握手过程
- 首先是由客户端发出加密通信请求（ClientHello），请求中包含的信息如下：
- 客户端支持的协议版本，比如TLS1.0还是TLS1.2
- 一个客户端生成的随机数，后面用于生成会话秘钥
- 客户端支持的加密方式，比如RSA加密算法
- 支持的压缩方法
- 服务器收到ClientHello请求后，进行响应（ServerHello），响应的信息如下：
- 确认使用的协议版本，如果浏览器与服务器支持的版本不一致，则关闭加密通信
- 服务器生成的随机数，后面用于生成会话密钥
- 确认使用的加密方法，比如RSA加密算法
- 服务器的数字证书
- 客户端收到服务端的响应以后需要进行回应，在回应之前会首先通过浏览器或操作系统预置的CA公钥验证数字证书的有效性，如果证书不是可信机构颁发、或者证书中的域名和实际域名不一致，或者证书已过期都会给访问者一个警告，由访问者决定是否继续通信。
如果证书验证没问题，就从证书中取出服务器的公钥，然后使用它加密报文，向服务器发送以下信息：
- 一个随机数(pre-master key)，该随机数会被服务器的公钥加密
- 加密通信算法改变通知，表示随后的通信都使用会话密钥加密通信
- 客户端结束握手通知，表示客户端的握手阶段已经结束，同时把之前的内容做个摘要，用来供服务端验证
此时一共有3个随机数，服务器和客户端会通过这三个随机数以及协商好的加密算法，各自生成本次通信的会话密钥。
- 服务器在收到客户端的随机数以后（pre-master）,通过协商的加密算法，计算出本次通信的会话密钥，向客户端发送以下信息：
- 加密算法改变通知，表示随后的通信都使用会话密钥加密通信
- 服务器结束握手通知，表示服务端握手结束，同时把之前的内容做个摘要发送给客户端用来验证
至此，SSL/TLS握手结束，后续就是普通HTTP协议，只不过会使用会话秘钥来加密
HTTP1.1的优点
- 使用长连接的方式减少了HTTP1.0短连接的性能开销
- 支持管道传输，请求发出以后不必等待响应即可发送第二个请求
HTTP1.1的缺点
- 请求响应头部在发送时没有压缩，只能压缩Body
- 首部过于冗长，相同的首部发送浪费资源
- 服务器是按照请求顺序响应，容易导致队头阻塞
- 无法控制请求优先级
- 请求只能由客户端发起，服务端只能响应
HTTP2的优点
- 基于HTTPS，安全性得到保障
- 头部压缩（HPACK算法），提高发送速度
- 报文采用二进制格式，统称为帧，头信息为头信息帧，数据体为数据帧，接收端在收到报文后无需再解析
- 数据流，每个请求或响应的所有数据报称为数据流，每个数据流有唯一编号，通过指定数据流的优先级，服务器会根据优先级顺序进行响应
- 多路复用，响应顺序可以和请求顺序不对应，解决对头阻塞问题
- 服务器可以主动向客户端发送消息
HTTP2的缺点
- 多个HTTP请求复用一个TCP连接，如果TCP发生了重传，所有的HTTP请求都必须等待丢了的包被重传回来
基于上述问题HTTP3的下层协议由TCP改为UDP，然后通过QUIC协议保证传输的可靠性，但目前普及速度缓慢，这里就不说了。
