CCNAIVE

HTTP-常见面试题

2023/9/21

# HTTP-常见面试题

https://xiaolincoding.com/network/2_http/http_interview.html

# HTTP

# HTTP 基本概念

HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。

# HTTP 常见的状态码有哪些

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」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。

# GET 与 POST

# GET 和 POST 有什么区别

1.请求负荷大小的限制：是因为浏览器对URL做了限制，HTTP协议本身没有

2.传输参数的位置

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

先说明下安全和幂等的概念：

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

安全：从明文方面考虑，都不安全，body能抓包看到，可以用HTTPS

幂等：从是否影响到服务器：从根本上分析GET、POST的具体业务是否改变了服务器上的数据，改变了就不安全不幂等，没改变安全且幂等。

# HTTP 缓存技术

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

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

HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存。

# 强制缓存

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，用不用缓存是我游览器说了算！

返回的是 200 状态码，但在 size 项中标识的是 from disk cache，就是使用了强制缓存。

# 协商缓存

协商缓存就是客户端问服务器：

1.服务器大哥，请问xxx数据有更新吗？

大哥：没有更新

服务器：好的，那我用缓存咯

2.或者这样问：这个缓存有过期吗？

大哥：没过期捏

服务器：那我就查询缓存咯~

这里判断数据是否更新（请求时带上Etag）、缓存是否过期（请求时带上If-Modified-since）都是在服务器上进行判断。
服务器大哥说了算

# HTTP 特性

# HTTP/1.1 的优点有哪些？

HTTP 最突出的优点是「简单、灵活和易于扩展、应用广泛和跨平台

1. 简单

HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式

2. 灵活和易于扩展

HTTPS就是在HTTP与TCP层加了SSL/TLS安全传输层

3. 应用广泛和跨平台

# HTTP/1.1 的缺点有哪些？

1.无状态

好：服务器不用记住你，减少服务器压力

坏：没人记住你，每一次操作都需要问你是谁！（可以把个人信息放cookie）

2.明文传输**

好：可以直接看

坏：不安全 （使用HPPTS引入SSL/TLS）

# HTTP/1.1 的性能如何？

HTTP 协议是基于 TCP/IP，并且使用了「请求 - 应答」的通信模式，所以性能的关键就在这两点里。

1.长连接

HTTP1.0 很垃圾，每次请求都要新建TCP连接（三次握手），居然还是串行请求，每次TCP连接、断开就没意义，纯纯大冤种。

so：HTTP1.1提出了长连接，减少了TCP的重复连接。

2.管道网络传输

因为HTTP1.1有长连接，所以有了管道网络传输

原来是发送A请求，响应后才能发送B请求。现在可以同时发送A、B请求。

HTTP1.1解决了请求队头阻塞，但是还有响应队头阻塞，哈哈哈哈哈哈

3.队头阻塞

就是发送A、B两个请求，但是响应是有顺序的，要先响应完A，才能响应B，如果A一直在阻塞，那么B也要等等等，这就是队头阻塞。好比堵车，前面的人堵住了走不了，你也跟着等。

# HTTP 与 HTTPS

# HTTP 与 HTTPS 有哪些区别？

1.安全：明文，加密

2.建立方式：http：3次握手建立TCP。https：在http基础上还要和SSL/TLS握手

3.默认端口：http: 80 。https: 443

4.https需要CA机构的数字证书，认同服务器ojbk

# HTTPS 解决了 HTTP 的哪些问题？

1.不安全、你号没了---------信息加密------混合加密

2.搏一搏单车变摩托，防植入广告---------校验机制------摘要算法+数字签名

3.别人冒充你---------身份证明

# 相关算法

# 1.混合加密

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

非对称加密（对称密钥），对称密钥加密明文

# 2.摘要算法+数字签名

摘要：哈希算法

数字：非对称加密

# 3.数字证书

真是繁琐啊，没想到还能伪造公钥、私钥，

所有还得用一个数字证书来解决

举个例子：

请假需要家长签名，家长-公钥，老师-私钥，但是你投了你爸的公钥自己伪造了请假条，

为了解决你伪造，来了警察（公钥、私钥），你爸把公钥注册到警察局，

警察使用私钥加密你爸，

老师拿到后去警察局，如果能解密说明没问题。警察给解密。

老师再用私钥解密，批准你请假

# HTTPS 是如何建立连接的？其间交互了什么？

TODO

# HTTPS 的应用数据是如何保证完整性的？

TODO

# HTTPS 一定安全可靠吗？

TODO

# HTTP/1.1、HTTP/2、HTTP/3 演变

# HTTP/1.1 相比 HTTP/1.0 提高了什么性能？

HTTP/1.1 相比 HTTP/1.0 性能上的改进：

  • 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
  • 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

但 HTTP/1.1 还是有性能瓶颈：

  • 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
  • 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
  • 服务器是按请求的顺序响应的，响应队头阻塞
  • 没有请求优先级控制；
  • 请求只能从客户端开始，服务器只能被动响应

# HTTP/2 做了什么优化？

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

那 HTTP/2 相比 HTTP/1.1 性能上的改进：

  • 头部压缩
  • 二进制格式
  • 并发传输
  • 服务器主动推送资源

# 1. 头部压缩

发送多个请求，会消除头部重复的部分，

HPACK算法：维护头部信息，有索引，重复字段发送索引就好了

# 2.二进制格式

1.HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文

2.头信息和数据体都用二进制，统称帧 frame：头信息帧、数据帧

3.静态表：存储常见的一些头信息

# 3.并发传输

HTTP1.1一次只能发送一个请求，且得响应结束才能进行下一个。

这个解决了队头阻塞

一个TCP包含多个Stream，Stream里包含多个Message（对应http/1中的请求或响应），Message里面有多个frame（http/2最小单位，以二进制存储http/1中的内容（头部和包体））

# 4.服务器推送

改善传统的【请求-响应】，服务器可以主动向客户端发送消息

比如客户端请求一个html，服务器响应，客户端发现渲染还要css，然后又请求服务器的css，所以在http/2服务器可以主动把css发送给客户端

HTTP/2有什么缺陷？

HTTP/2基于TCP协议传输，TCP是字节流协议，TCP层必须保证收到的字节数据是完整且连续的，这样才会进行响应，如果有一个字节数据没有，那就阻塞了，而且多个请求共用同一个TCP，一个请求阻塞了还会阻塞所有的HTTP请求，这就是HTTP/2中的TCP层队头阻塞。

# HTTP/3 做了哪些优化？

  1. 彻底没了队头阻塞
  2. 更快的建立连接
  3. 连接迁移

# 1.无队头阻塞

  1. 使用UDP，UDP不管顺序、不管丢包。
  2. 在UDP基础上的QUIC协议可以实现类似TCP的可靠传输
  3. QUIC和http/2类似，同一连接上多个Stream，但是某个流发生丢包，其他流不受影响，不存在队头阻塞。

# 2.更快的建立连接

TODO

对于 HTTP/1 和 HTTP/2 协议，TCP 和 TLS 是分层的，分别属于内核实现的传输层、openssl 库实现的表示层，因此它们难以合并在一起，需要分批次来握手，先 TCP 握手，再 TLS 握手。

HTTP/3 在传输数据前虽然需要 QUIC 协议握手，但是这个握手过程只需要 1 RTT，握手的目的是为确认双方的「连接 ID」，连接迁移就是基于连接 ID 实现的。

但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层，而是 QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS/1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商

# 3.连接迁移

TODO

Spring