话说HTTP（持续更新）

HTTP

概念

HTTP全称HyperText Transfer Protocol（超文本传输协议）

从这个名字中我们可以了解到什么？1.超文本；2.传输；3.协议

首先，什么是超文本，顾名思义是超越了普通文本的文本，包括了文字、图片、视频，以及能够从一个超文本跳转到另一个超文本的超链接

其次，传输二字我们可以获取到的信息是 HTTP是一个双向协议，用来在两点之间传输数据的约定和规范，注意这里的措辞，是两点之间，而不一定只指客户端和服务器之间的传输，但是这其中还有一个关键点就是这传输的过程中是允许中转或接力的，它的传输方式不一定是[A<---->B]，也可能是[A<-->X<-->Y<-->B]。

最后是协议，意思是两个以上的参与者之间交流通信的一种行为约定和规范。

HTTP请求和响应

常见字段

Host字段 客户端发起请求时使用，指定服务器域名

Content-Length字段 服务器返回数据时使用，表示本次回应的数据长度

Content-Type字段 服务器响应时告知服务器本次数据的格式

Content-Encoding字段 服务器返回数据时说明数据的压缩方法

Accept-Encoding字段 客户端请求时说明自己可以接受哪些压缩方法

Connection字段 常用于客户端要求服务器使用http长连接

ps：HTTP/1.1默认是长连接，但是为了兼容老版本，需要指定Connection: Keep-Alive

这里的HTTP Keep-Alive 和TCP Keep-Alive是不一样的，具体后续会说明

例：下列是请求访问百度的部分字段

HTTP请求

请求方法

• GET：获取资源，向服务器请求指定的资源。GET请求是幂等的，多次请求同一资源会得到相同的结果。

• POST：提交数据，向服务器提交数据并请求处理。POST请求不是幂等的，多次请求可能会得到不同的结果。

• PUT：替换资源，向服务器发送数据，用该数据替换指定的资源。

• DELETE：删除资源，向服务器请求删除指定的资源。

• HEAD：获取资源的元信息，类似于GET请求，但只返回响应头部，用于获取资源的元信息而不需要获取完整的资源内容。

• OPTIONS：获取服务器支持的HTTP方法。

• PATCH：局部更新资源，向服务器发送数据，用该数据对指定的资源进行部分更新。

• TRACE：用于追踪请求-响应的传输路径。

这些请求方法中最常见的HTTP请求方法是GET和POST。 GET用于获取资源，POST用于提交数据。这两个请求方法在Web开发中应用广泛。其他请求方法如PUT、DELETE、HEAD等在特定的应用场景中使用较多，但相对于GET和POST来说较为常见。

一个很常见的面试题：GET和POST有什么区别？

根据RFC规范

1. GET的语义是从服务器获取指定资源；POST的语义是根据请求报文body对指定资源做出处理

2. GET请求的参数位置一般在URL中，且参数只能是ASCII字符，虽然http协议本身对URL长度没有规定，但是浏览器对url长度是有限制的；POST的参数一般写在报文body中，可以是任意数据格式，浏览器对body大小无限制

3. GET是安全且幂等的；POST是不安全且不幂等的

当然，这所有的一切，都是建立在我写在第一行的前提下，[根据RFC规范]，如果这只是规范，那我是不是可以不遵守，在我看来，确实可以

首先我们需要先知道两个概念，安全和幂等：

在http协议中，安全是指请求方法不会破坏服务器上资源，幂等是指多次执行相同的操作得到的都是相同的结果

所以从RFC规范来看，GET方法确实是安全和幂等的，它是只读操作，所以多次执行操作，服务器的资源不会发生变化，得到的结果也是一样的；POST方法是不安全不幂等的，它是新增或提交数据操作，会修改服务器的资源，并且多次提交数据会创建多个资源，所以说不安全不幂等的。所以可以对GET请求的数据缓存到浏览器本身或代理上，也可以保存为浏览器中的书签，但是POST请求一般不会被缓存到浏览器上，也不能保存为书签

如果不按照RFC规范来实现GET和POST方法的话，那么：

• 可以使用GET方法进行新增或删除的操作，那么GET就是不安全不幂等的

• 可以使用POST方法进行查询数据的操作，那么POST就是安全且幂等的

但是这其中的安全的定义也可以有不同，如果安全定义信息是否会被泄露，那么POST因为数据存储在body中，而GET数据直接写在URL中进行传输，所以数据会在地址栏被看到，但是因为HTTP是明文传输的，所以只要抓个包，body中的数据也很容易被看到，所以使用https进行加密传输会更加安全

请求报文

请求报文是客户端（浏览器）向服务器发送的HTTP请求的内容。它包括以下几个部分：

1. 请求行：包括请求方法（GET、POST等）、请求的URL和HTTP协议版本。

2. 请求头部：包括请求的各种附加信息，如Host、User-Agent、Content-Type等。

3. 空行：用于分隔请求头部和请求体的空行。

4. 请求体：可选的，用于存放请求的数据，例如表单数据或上传的文件。

请求报文的格式通常是ASCII码文本，每个部分以特定的格式进行标识和分隔。当客户端发送请求报文时，服务器接收并处理请求，然后返回相应的响应报文。

HTTP响应

HTTP状态码

1xx 提示信息，协议中处理的中间状态

2xx 成功

200 成功，如果是非HEAD请求，服务器返回的响应头部都会有body数据

204 成功，但是响应头没有body数据

206 成功，用于HTTP分块下载或者断点续传，表示响应的body数据不是资源的全部

3xx 重定向，缓存

301 永久重定向，请求的资源不存在，需要该用新的URL再次访问

302 临时重定向，请求的资源还在，但是需要暂时使用另一个URL进行访问

*304 缓存重定向，告知客户端可以继续使用缓存资源，用于缓存控制

ps：304这个状态码比较重要，和后续http缓存中的协商缓存有关系

307

308

4xx 客户端错误

400 客户端请求报文有误，是一个笼统的错误

403 服务器禁止访问资源，不是客户端的请求错误

404 请求的资源不存在或未找到

5xx 服务器错误

500 和400是一个类型的，是服务器的错误但是具体错误不知道

501 客户端请求的功能暂不支持

502 服务器作为网关或代理时返回的错误码，服务器正常，但是访问后端服务器发生问题

503 服务器繁忙，暂时无法响应

HTTP缓存

强制缓存

协商缓存

HTTP/1.0、HTTP/1.1、HTTP2.0、HTTP3.0

HTTP/1.0

短连接

HTTP/1.1

长连接，解决了HTTP/1.0短连接造成的性能开销

使用管道技术

HTTP/2.0

HTTP/3.0

HTTPS

HTTP和HTTPS的区别

HTTPS连接

HTTPS连接包括TCP三次握手+SSL四次握手

SSL四次握手过程

1. 客户端发送clientHello，包括它所支持的最高TLS版本、生成的第一个随机数（或者叫做不重数）和密码套件(支持哪些加密算法)

2. 服务器发送serverHello，确认使用的TLS版本、生成第二个随机数以及确定双方使用的加密算法，发送服务器的CA证书

3. 客户端通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，包括1. 被服务器公钥加密的第三个随机数，我们称为预主密钥，以及2.加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信（下一次通信使用对称加密算法），3.客户端握手结束通知，这一项同时把之前所有内容的发生的数据做个摘要使用会话秘钥加密，用来供服务端校验（检验双方是否可以使用这个会话密钥进行加解密）

4. 服务器收到预主密钥后，通过协商的加密算法，计算出本次通信的「会话秘钥」，然后，向客户端发送1. 加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信和2. 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验

SSL握手一定是四次吗？

不是，TLS1.2握手是四次，因为它使用的非对称加密算法是RSA算法，而如果是TLS1.3的话，则握手是三次，它使用的非对称加密算法是目前比较主流的算法，叫做ECDHE算法。如今更加主流使用ECDHE算法是因为RSA算法的一些缺陷，比如不具备前向安全性等