【网络面试篇】HTTP（1）（笔记）——状态码、字段、GET、POST、缓存

一、相关问题

1. HTTP请求常见的状态码和字段？

（1）状态码

（2）字段

① Host 字段

② Content-length 字段

③ Connection 字段

④ Content-Type 字段

⑤ Content-Encoding 字段

2. GET 和 POST 的区别？

（1）作用不同

（2）参数传递方式不同

（3）安全性不同

（4）参数长度限制不同

（5）编码方式不同

（6）缓存机制不同

（7）时间消耗不同

3. GET 和 POST 方法都是安全和幂等的吗？

4. 什么是强缓存和协商缓存？

（1）强制缓存

（2）协商缓存

① 使用 ETag 字段实现的协商缓存过程

② 使用 last-modified 实现的协商缓存过程

一、相关问题

1. HTTP请求常见的状态码和字段？

（1）状态码

1xx 类状态码 属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx 类状态码 表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。
「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3xx 类状态码 表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。301 和 302 都会在响应头里使用字段 Location ，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。
「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。

4xx 类状态码 表示客户端发送的报文有误，服务器无法处理，也就是 错误码 的含义。

「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。
「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。
「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx 类状态码 表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于 服务器端的错误码。

「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
「501 Not Implemented」表示客户端请求的功能还不支持，类似 “即将开业，敬请期待" 的意思。
「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似 “网络服务正忙，请稍后重试” 的意思。

（2）字段

① Host 字段

客户端发送请求时，用来指定服务器的域名。

有了 Host 字段，就可以将请求发往「同一台」服务器上的不同网站。

② Content-length 字段

服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。

如上面是告诉浏览器，本次服务器回应的数据长度是 1000 个字节，后面的字节就属于下一个回应了。

③ Connection 字段

Connection 字段最常用于客户端要求服务器使用「HTTP 长连接」机制，以便其他请求复用。

④ Content-Type 字段

Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。

上面的类型表明，发送的是网页，而且编码是 UTF-8。

⑤ Content-Encoding 字段

Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式。

上面表示服务器返回的数据采用了 gzip 方式压缩，告知客户端需要用此方式解压。
客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。

2. GET 和 POST 的区别？

（1）作用不同

GET 用于从服务端获取资源。
POST 一般用来向服务器端提交数据。

（2）参数传递方式不同

GET 请求的参数一般写在 URL 中，且只接受 ASCII 字符。
POST 请求参数一般放在请求体中，对于数据类型也没有限制。

（3）安全性不同

因为参数传递方式的不同，所以两者安全性不同，GET 请求的参数直接暴露在 URL 中，所以更不安全，不能用来传递敏感信息。

（4）参数长度限制不同

GET 传送的数据量较小，不能大于2KB。
POST 传送的数据量较大，一般被默认为不受限制。
HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。

（5）编码方式不同

GET 请求只能进行 URL 编码（application/x-www-form-urlencoded）
POST 支持多种编码方式（application/x-www-form-urlencoded 或 multipart/form-data，二进制数据使用多种编码）

（6）缓存机制不同

GET 请求会被浏览器主动 cache，而 POST 不会，除非手动设置。
GET 请求参数会被完整保留在浏览器历史记录里，而 POST 中的参数不会被保留。
GET 产生的 URL 地址可以被保存为书签，而 POST 不可以。
GET 在浏览器回退时是无害的，而 POST 会再次提交请求。

（7）时间消耗不同

GET 产生一个 TCP 数据包。
POST 产生两个 TCP 数据包。
对于 GET 方式的请求，浏览器会把 header 和 data 一并发送出去，服务器响应 200（返回数据）。
而对于 POST，浏览器先发送 Header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）。

3. GET 和 POST 方法都是安全和幂等的吗？

安全和幂等的概念：

在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。

从 RFC 规范定义的语义来看：

GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且 每次的结果都是相同的。所以，可以对 GET 请求的数据做缓存，这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如 nginx），而且在浏览器中 GET 请求可以保存为书签。
POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以 不是幂等的。所以，浏览器一般不会缓存 POST 请求，也不能把 POST 请求保存为书签。

小结：

GET 的语义是请求获取指定的资源。GET 方法是安全、幂等、可被缓存的。
POST 的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 不安全，不幂等，（大部分实现）不可缓存。

4. 什么是强缓存和协商缓存？

对于一些具有重复性的 HTTP 请求，比如每次请求得到的数据都一样的，我们可以把这对「请求-响应」的数据都缓存在本地，那么下次就直接读取本地的数据，不必在通过网络获取服务器的响应了，这样的话 HTTP/1.1 的性能肯定肉眼可见的提升。

所以，避免发送 HTTP 请求的方法就是通过缓存技术，HTTP 设计者早在之前就考虑到了这点，因此 HTTP 协议的头部有不少是针对缓存的字段。HTTP 缓存有两种实现方式，分别是 强制缓存和协商缓存。

（1）强制缓存

强缓存就是浏览器本地根据服务器设置的过期时间来判断是否使用缓存，决定是否使用缓存的主动性在于浏览器这边。如下图中，返回的是 200 状态码，但在 size 项中标识的是 from disk cache，就是使用了强制缓存。

强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期：

Cache-Control，是一个相对时间；
Expires，是一个绝对时间；

如果 HTTP 响应头部同时有 Cache-Control 和 Expires 字段的话，Cache-Control 的优先级高于 Expires。

Cache-control 选项更多一些，设置更加精细，所以建议使用 Cache-Control 来实现强缓存。具体的实现流程如下：

当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 Cache-Control，Cache-Control 中设置了过期时间大小；
浏览器再次请求访问服务器中的该资源时，会先通过请求资源的时间与 Cache-Control 中设置的过期时间大小，来计算出该资源是否过期，如果没有，则使用该缓存，否则重新请求服务器；
服务器再次收到请求后，会再次更新 Response 头部的 Cache-Control。

（2）协商缓存

当在浏览器使用开发者工具的时候，可能会看到过某些请求的响应码是 304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。

上图就是一个协商缓存的过程，所以 协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存，即浏览器每一次都要发送请求到服务器询问是否使用缓存。协商缓存可以基于两种头部来实现。

第一种：请求头部中的 If-Modified-Since 字段与响应头部中的 Last-Modified 字段 实现，这两个字段的意思是：

响应头部中的 Last-Modified：标示 这个响应资源的最后修改时间；
请求头部中的 If-Modified-Since：当资源过期了，发现响应头中具有 Last-Modified 声明，则再次发起请求的时候带上 Last-Modified 的时间，服务器收到请求后发现有 If-Modified-Since 则与被请求资源的 最后修改时间进行对比（Last-Modified），如果最后修改时间较新（大），说明资源又被改过，则返回最新资源，HTTP 200 OK；如果最后修改时间较旧（小），说明资源无新修改，响应 HTTP 304 走缓存。

第二种：请求头部中的 If-None-Match 字段与响应头部中的 ETag 字段，这两个字段的意思是：

响应头部中 Etag：唯一标识响应资源；
请求头部中的 If-None-Match：当资源过期时，浏览器发现 响应头里有 Etag，则再次向服务器发起请求时，会将请求头 If-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对，如果资源没有变化返回 304，如果资源变化了返回 200。

第一种实现方式是基于时间实现的，第二种实现方式是基于一个唯一标识实现的，相对来说后者可以更加准确地判断文件内容是否被修改，避免由于时间篡改导致的不可靠问题。

注意：协商缓存这两个字段都需要配合强制缓存中 Cache-Control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。

① 使用 ETag 字段实现的协商缓存过程

当浏览器初次请求访问服务器资源时，服务器会在返回这个资源的同时，同时生成一个 Etag 值携带在响应头里返回给浏览器，这个唯一标识的值是根据当前请求的资源生成的。
当浏览器再次请求访问服务器中的该资源时，首先会先检查强制缓存是否过期。如果没有过期，则直接使用本地缓存；如果缓存过期了，会在请求头加上 If-None-Match 字段，该字段的值就是之前服务器返回的 Etag 的值。
服务器收到之后拿该值与资源文件最新的 Etag 值做对比。如果没有变化则返回 304，告诉浏览器继续使用缓存（不返回资源文件）；如果变化，则返回 200 状态码和资源，并在请求头加上新的 ETag 值。

② 使用 last-modified 实现的协商缓存过程

当浏览器初次请求访问服务器资源时，服务器端读出文件修改时间，将读出来的修改时间赋给响应头的 last-modified 字段，返回给浏览器。
当客户端读取到 last-modified 的时候，会在下次的请求标头中携带 If-Modified-Since 字段，而这个请求头中的 If-Modified-Since 就是之前服务器返回的 last-modified 字段。
和 ETag 字段相同的，之后每次对该资源的请求，都会带上 If-Modified-Since 这个字段。而服务端就需要拿其中表示时间与最新读取该资源的修改时间进行对比，来决定是读取缓存还是返回新的资源。

如果在第一次请求资源的时候，服务端返回的 HTTP 响应头部同时有 Etag 和 Last-Modified 字段，那么客户端再下一次请求的时候，如果带上了 ETag 和 Last-Modified 字段信息给服务端，这时 Etag 的优先级更高，也就是服务端先会判断 Etag 是否变化了，如果 Etag 有变化就不用在判断 Last-Modified 了，如果 Etag 没有变化，然后再看 Last-Modified。