HTTP 常见的状态码

1xx : 请求正在被处理。

2xx : 请求处理成功

3xx : 需要进行重定向，资源位置发生移动

4xx : 客户端错误，服务器无法处理

5xx : 服务器错误, 服务器处理请求发生了错误

2xx:
- 200: 请求被成功处理
- 204: 请求被成功处理，但响应的主体部分为空，适用于只需要客户端向服务端发送数据的情况
- 206: 客户端进行了部分请求，服务端返回指定部分的内容
3xx:
- 301: 请求的资源已被分配了新的 URL，永久性重定向
- 302: 请求的资源已被分配了新的 URL，暂时性重定向
- 303: 同 302，区别在与服务端要求客户端使用 Get 方法请求新的 URL
- 304: 不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。
4xx:
- 401: 请求报文中存在语法错误
- 402: 发送的请求需要 HTTP 认证
- 403: 请求的资源被服务器拒绝
- 404: 服务器上没有请求的资源
5xx:
- 500: 服务器在处理请求时出现了错误
- 501: 客户端请求的功能还不支持
- 502: 服务器自身工作正常，访问后端服务器发生了错误
- 503: 服务器当前很忙，暂时无法响应客户端

get 和 post 的区别

主要区别是“约定和规范”上的区别，在规范中，定义 GET 请求是用来获取资源的，也就是进行查询操作的，而 POST 请求是用来传输实体对象的，因此会使用 POST 来进行添加、修改和删除等操作。所以 GET 是安全且幂等，POST 不安全不幂等
按照约定来说，GET 和 POST 的参数传递也是不同的，GET 请求是将参数拼加到 URL 上进行参数传递的，而 POST 是将请参数写入到请求正文中传递的
GET 请求一般会被缓存，POST 请求默认是不进行缓存的。
GET 请求参数通过 URL 传递， URL 长度有限制；POST 请求参数是存放在请求 body 中，没有大小限制
GET 可以直接进行回退和刷新，不会对用户和程序产生任何影响；POST 回退和刷新会把数据重新提交

HTTP/1.1 优缺点

优点

简单
基本报文格式是header + body,头部信息是key-value形式，易于理解
灵活和易于扩展
HTTP 工作在应用层（OSI第七层）,它下层可以随意变化,比如：
- HTTPS 在 HTTP 和 TCP 层之间增加了 SSL/TLS 安全传输层
- HTTP/1.1 和 HTTP/2.0 传输协议使用的是 TCP 协议，而到了 HTTP/3.0 传输协议改用了 UDP 协议
应用广泛和跨平台
应用广泛，各种应用都在使用，具有跨平台的优越性

缺点

无状态
服务器没有记忆能力，完成有关联性的操作时会非常麻烦。解决方法：是Cookie技术
不安全
- 明文传输，裸奔状态
- 不验证通信方的身份，可能遭遇伪装
- 无法证明报文的完整性，有可能已遭篡改

TCP 和 UDP 的区别

TCP 面向连接；UDP 是无连接的，即发送数据之前不需要建立连接。
TCP 提供可靠的服务；UDP 不保证可靠交付。
TCP 面向字节流，把数据看成一连串无结构的字节流；UDP 是面向报文的。
TCP 有拥塞控制；UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如实时视频会议等）。
每一条 TCP 连接只能是点到点的；UDP 支持一对一、一对多、多对一和多对多的通信方式。
TCP 首部开销 20 字节；UDP 的首部开销小，只有 8 个字节。

TCP 是如何确保可靠性的

首先，TCP 的连接是基于三次握手，而断开则是基于四次挥手。确保连接和断开的可靠性。
其次，TCP 的可靠性，还体现在有状态;TCP 会记录哪些数据发送了，哪些数据被接收了，哪些没有被接受，并且保证数据包按序到达，保证数据传输不出差错。
再次，TCP 的可靠性，还体现在可控制。它有数据包校验、ACK 应答、**超时重传(发送方)**、失序数据重传（接收方）、丢弃重复数据、流量控制（滑动窗口）和拥塞控制等机制。

URI 和 URL 的区别

URI，表示统一资源标志符，主要作用是唯一标识一个资源（URL 像是身份证，可以唯一标识一个人）
URL，表示统一资源定位符，主要作用是提供资源的路径。

如何理解 HTTP 是无状态的

当浏览器第一次发送请求给服务器时，服务器响应了；如果同个浏览器发起第二次请求给服务器时，它还是会响应，但是呢，服务器不知道你就是刚才的那个浏览器。简言之，服务器不会去记住你是谁，所以是无状态协议。

HTTP 如何实现长连接

通过在头部（请求和响应头）设置Connection字段指定为keep-alive，HTTP/1.0 协议支持，但是是默认关闭的，从 HTTP/1.1 以后，连接默认都是长连接。

HTTPS 与 HTTP 的区别

HTTP 是超文本传输协议，信息是明文传输；HTTPS 则是具有安全性的 SSL/TLS 加密传输协议。
HTTP 和 HTTPS 用的端口不一样，HTTP 端口是 80，HTTPS 是 443。
HTTPS 协议需要到 CA 机构申请证书，一般需要一定的费用。
HTTP 运行在 TCP 协议之上；HTTPS 运行在 SSL 协议之上，SSL 运行在 TCP 协议之上。

作用范围不同，Cookie 保存在客户端，Session 保存在服务器端。
有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
隐私策略不同，Cookie 存储在客户端，容易被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
存储大小不同，单个 Cookie 保存的数据不能超过 4K；对于 Session 来说存储没有上限，但出于对服务器的性能考虑，Session 内不要存放过多的数据，并且需要设置 Session 删除机制。

HTTP1.1 和 HTTP2.0 的区别

HTTP2.0 相比 HTTP1.1 支持的特性：

头部压缩: HTTP2.0 会压缩头，如果同时发出多个请求，它们的头是一样或相似的，协议会消除重复部分。HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了
新的二进制格式：HTTP1.1 基于文本格式传输数据；HTTP2.0 采用二进制格式传输数据，对计算机非常友好，增加了数据传输地效率。
并发传输：在一个连接里，允许同时发送多个请求或响应，并且这些请求或响应能够并行的传输而不被阻塞，避免 HTTP1.1 出现的”队头堵塞”问题。
针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。
服务端推送：HTTP2.0 允许服务器向客户端推送资源，无需客户端发送请求到服务器获取。
客户端建立的 Stream 必须是奇数号，服务器建立的 Stream 必须是偶数号

非对称加密算法

非对称加密

服务器的私钥对数字签名加密，然后客户端通过公钥对数字签名进行解密，能被解密，说明消息由服务器发送的。

TLS 协议建立流程

ClientHello: 客户端发起加密通信请求,并发送以下信息：
- 客户端支持的 TLS 版本
- 客户端生产的随机数(CLient Random),后面用于生成会话秘钥条件之一。
- 客户端支持的加密算法列表，如 RSA 算法。
SeverHello: 服务器收到客户端请求后，向客户端发出相应，回应如下内容：
- 确认 TLS 协议版本，如果浏览器不支持，则关闭通信。
- 服务器生产的随机数(Server Random),生成会话秘钥条件之一。
- 确认密码加密算法，如 RSA 算法。
- 服务器的数字证书。
客户端回应：通过 CA 公钥确认服务器数字证书的真实性。如果证书没有问题，则从数字证书中取出服务器公钥，然后用它加密报文,向服务器发送如下信息：
- 一个随机数(pre-master key)。该随机数会被公钥加密。
- 加密通信算法改变通知，随后使用会话秘钥进行通信。
- 握手结束通知，并把之前所有产生的数据做个摘要，给服务端进行校验。

**客户端和服务端有了三个随机数（Client Random, Server Random, pre-master key）,接着用双方协商的加密算法，各自生成本次通信的[会话秘钥]**。

服务器最后回应：向客户端发送最后信息：
- 加密通信算法改变通知，随后使用会话秘钥进行通信。
- 服务器握手结束，把之前所有产生的数据做个摘要，给服务端进行校验。

至此，整个 TLS 的握手阶段全部结束，接下来，客户端和服务端进入加密通信，就完全使用普通的 HTTP 通信，只不过用会话秘钥加密内容