【网络面试篇】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。
  




免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。