常见的http面试问题

最新推荐文章于 2024-04-14 01:51:27 发布

zj134_

最新推荐文章于 2024-04-14 01:51:27 发布

阅读量1.6k

点赞数

分类专栏：计算机网络

原文链接：https://blog.csdn.net/qq_34827674/article/details/104732605

版权

计算机网络专栏收录该内容

11 篇文章 4 订阅

订阅专栏

原文：硬核！30 张图解 HTTP 常见的面试题，给你整明白_小林coding-CSDN博客

原文的作者好几个系列的写的特别好，墙裂推荐。

文章目录

前言

在面试过程中，HTTP 被提问的概率还是比较高的。

小林我搜集了 5 大类 HTTP 面试常问的题目，同时这 5 大类题跟 HTTP 的发展和演变关联性是比较大的，通过问答 + 图解的形式由浅入深的方式帮助大家进一步的学习和理解 HTTP 。

HTTP 基本概念
Get 与 Post
HTTP 特性
HTTPS 与 HTTP
HTTP/1.1、HTTP/2、HTTP/3 演变

正文

01 HTTP 基本概念

HTTP 是什么？描述一下

HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。

能否详细解释「超文本传输协议」？

HTTP的名字「超文本协议传输」，它可以拆成三个部分：

超文本
传输
协议

三个部分

1. 「协议」

在生活中，我们也能随处可见「协议」，例如：

刚毕业时会签一个「三方协议」；
找房子时会签一个「租房协议」；

三方协议和租房协议

生活中的协议，本质上与计算机中的协议是相同的，协议的特点:

「协」字，代表的意思是必须有两个以上的参与者。例如三方协议里的参与者有三个：你、公司、学校三个；租房协议里的参与者有两个：你和房东。
「议」字，代表的意思是对参与者的一种行为约定和规范。例如三方协议里规定试用期期限、毁约金等；租房协议里规定租期期限、每月租金金额、违约如何处理等。

针对 HTTP 协议，我们可以这么理解。

HTTP 是一个用在计算机世界里的协议。它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范（两个以上的参与者），以及相关的各种控制和错误处理方式（行为约定和规范）。

2. 「传输」

所谓的「传输」，很好理解，就是把一堆东西从 A 点搬到 B 点，或者从 B 点搬到 A 点。

别轻视了这个简单的动作，它至少包含两项重要的信息。

HTTP 协议是一个双向协议。

我们在上网冲浪时，浏览器是请求方 A ，百度网站就是应答方 B。双方约定用 HTTP 协议来通信，于是浏览器把请求数据发送给网站，网站再把一些数据返回给浏览器，最后由浏览器渲染在屏幕，就可以看到图片、视频了。

请求 - 应答

数据虽然是在 A 和 B 之间传输，但允许中间有中转或接力。

就好像第一排的同学想传递纸条给最后一排的同学，那么传递的过程中就需要经过好多个同学（中间人），这样的传输方式就从「A < — > B」，变成了「A <-> N <-> M <-> B」。

而在 HTTP 里，需要中间人遵从 HTTP 协议，只要不打扰基本的数据传输，就可以添加任意额外的东西。

针对传输，我们可以进一步理解了 HTTP。

HTTP 是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。

3. 「超文本」

HTTP 传输的内容是「超文本」。

我们先来理解「文本」，在互联网早期的时候只是简单的字符文字，但现在「文本」的涵义已经可以扩展为图片、视频、压缩包等，在 HTTP 眼里这些都算作「文本」。

再来理解「超文本」，它就是超越了普通文本的文本，它是文字、图片、视频等的混合体，最关键有超链接，能从一个超文本跳转到另外一个超文本。

HTML 就是最常见的超文本了，它本身只是纯文字文件，但内部用很多标签定义了图片、视频等的链接，再经过浏览器的解释，呈现给我们的就是一个文字、有画面的网页了。

OK，经过了对 HTTP 里这三个名词的详细解释，就可以给出比「超文本传输协议」这七个字更准确更有技术含量的答案：

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

那「HTTP 是用于从互联网服务器传输超文本到本地浏览器的协议，这种说法正确吗？

这种说法是不正确的。因为也可以是「服务器< – >服务器」，所以采用两点之间的描述会更准确。

HTTP 常见的状态码，有哪些？

五大类 HTTP 状态码

1xx

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

2xx

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

「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。

「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。

「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3xx

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

「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。

「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。

4xx

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

「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。

「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。

「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx

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

「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。

「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。

「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

「503 Service Unavailable」表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。

http 常见字段有哪些？

Host 字段

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

Host: www.A.com

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

Content-Length 字段

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

Content-Length: 1000

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

Connection 字段

Connection 字段最常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用。

HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。

Connection: keep-alive

一个可以复用的 TCP 连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段。

Content-Type 字段

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

Content-Type: text/html; charset=utf-8

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

客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。

Accept: */*

上面代码中，客户端声明自己可以接受任何格式的数据。

Content-Encoding 字段

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

Content-Encoding: gzip

上面表示服务器返回的数据采用了 gzip 方式压缩，告知客户端需要用此方式解压。

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

Accept-Encoding: gzip, deflate

02 GET 与 POST

说一下 GET 和 POST 的区别？

详细的看这里：GET和POST请求的区别_zj-CSDN博客

Get 方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等。

比如，你打开我的文章，浏览器就会发送 GET 请求给服务器，服务器就会返回文章的所有文字及资源。

GET 请求

而POST 方法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报文的 body 里。

比如，你在我文章底部，敲入了留言后点击「提交」，浏览器就会执行一次 POST 请求，把你的留言文字放进了报文 body 里，然后拼接好 POST 请求头，通过 TCP 协议发送给服务器。

POST 请求

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

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

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

那么很明显 GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。

POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。

03 HTTP 特性

你知道的 HTTP（1.1）的优点有哪些，怎么体现的？

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

1. 简单

HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。

2. 灵活和易于扩展

HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。

同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。

HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，HTTP/3 甚至把 TCP 层换成了基于 UDP 的 QUIC。

3. 应用广泛和跨平台

互联网发展至今，HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应用片地开花，同时天然具有跨平台的优越性。

那它的缺点呢？

HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。

1. 无状态双刃剑

无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。

无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。

例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。

这样每操作一次，都要验证信息，这样的购物体验还能愉快吗？别问，问就是酸爽！

对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。

Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。

相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了。

Cookie 技术

2. 明文传输双刃剑

明文意味着在传输过程中的信息，是可方便阅读的，通过浏览器的 F12 控制台或 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。

但是这正是这样，HTTP 的所有信息都暴露在了光天化日下，相当于信息裸奔。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取，如果里面有你的账号密码信息，那你号没了。

3. 不安全

HTTP 比较严重的缺点就是不安全：

通信使用明文（不加密），内容可能会被窃听。比如，账号信息容易泄漏，那你号没了。
不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了。
无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了。

HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。

那你再说下 HTTP/1.1 的性能如何？

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

1. 长连接

早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。

为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。

持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

短连接与长连接

2. 管道网络传输

HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。

即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

举例来说，客户端需要请求两个资源。以前的做法是，在同一个TCP连接里面，先发送 A 请求，然后等待服务器做出回应，收到后再发出 B 请求。管道机制则是允许浏览器同时发出 A 请求和 B 请求。

管道网络传输

但是服务器还是按照顺序，先回应 A 请求，完成后再回应 B 请求。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为「队头堵塞」。

3. 队头阻塞

「请求 - 应答」的模式加剧了 HTTP 的性能问题。

因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」。好比上班的路上塞车。

队头阻塞

总之 HTTP/1.1 的性能一般般，后续的 HTTP/2 和 HTTP/3 就是在优化 HTTP 的性能。

04 HTTP 与 HTTPS

HTTP 与 HTTPS 有哪些区别？

HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。
HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。
HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的（四次）握手过程，才可进入加密报文传输。
HTTP 的端口号是 80，HTTPS 的端口号是 443。
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS 解决了 HTTP 的哪些问题？

HTTP 由于是明文传输，所以安全上存在以下三个风险：

窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTP 与 HTTPS 网络层

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险：

信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

可见，只要自身不做「恶」，SSL/TLS 协议是能保证通信是安全的。

HTTPS 是如何解决上面的三个风险的？

混合加密的方式实现信息的机密性，解决了窃听的风险。
摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。
将服务器公钥放入到数字证书中，解决了冒充的风险。

1. 混合加密

通过混合加密的方式可以保证信息的机密性，解决了窃听的风险。

混合加密

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

在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

更详细的解释：浅谈对称加密与非对称加密 - 知乎

常见的对称加密算法有: DES、IDEA、3DES、Blowfish、RC4、RC5、RC6 和 AES

常见的非对称加密算法有: RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）

2. 摘要算法

摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改的风险。

校验完整性

客户端在发送明文之前会通过摘要算法算出明文的「指纹」，发送的时候把「指纹 + 明文」一同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的「指纹」和当前算出的「指纹」做比较，若「指纹」相同，说明数据是完整的。

摘要算法（哈希算法）特别的地方在于它是一种单向算法，用户可以通过hash算法对目标信息生成一段特定长度的唯一hash值，却不能通过这个hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。

常见的摘要算法有: MD5、HAVAL、SHA、MD2、MD4

3. 数字证书

客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

这就存在些问题，如何保证公钥不被篡改和信任度？

所以这里就需要借助第三方权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。

数子证书工作流程

通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。

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

SSL/TLS 协议基本流程：

客户端向服务器索要并验证服务器的公钥。
双方协商生产「会话秘钥」。
双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。

SSL/TLS 的「握手阶段」涉及四次通信，可见下图：

HTTPS 连接建立过程

SSL/TLS 协议建立的详细流程：

1. ClientHello

首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

在这一步，客户端主要向服务器发送以下信息：

（1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。

（2）客户端生产的随机数（Client Random），后面用于生产「会话秘钥」。

（3）客户端支持的密码套件列表（加密算法），如 RSA 加密算法。

2. SeverHello

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：

（1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。

（2）服务器生产的随机数（Server Random），后面用于生产「会话秘钥」。

（3）确认的密码套件列表（加密算法），如 RSA 加密算法。

（4）服务器的数字证书（证书包含了服务器公匙）。

3.客户端回应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性（验证证书）。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

（1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。

（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信（会话密匙由三个随机数计算而来）。

（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

4. 服务器的最后回应

服务器收到客户端的第三个随机数（pre-master key）之后，使用自己的私钥解密出随机数，然后通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息：

（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

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

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

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

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

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

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

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

那上面的 HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？

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

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

1. 头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。

这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

2. 二进制格式

HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。

报文区别

这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。

3. 数据流

HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。

每个请求或回应的所有数据包，称为一个数据流（Stream）。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数

客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。

HTT/1 ~ HTTP/2

4. 多路复用

HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。

移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。

举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。

多路复用

5. 服务器推送

HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。

举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。

HTTP/2 有哪些缺陷？HTTP/3 做了哪些优化？

HTTP/2 主要的问题在于，多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP/1.1 中的管道（ pipeline）传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住了
HTTP/2 多个请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。

这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

HTTP/1 ~ HTTP/3

UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞和 HTTP/2 的一个丢包全部重传问题。

大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响。
TLS3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack。
HTTPS 要建立一个连接，要花费 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。

TCP HTTPS（TLS/1.3）和 QUIC HTTPS

所以， QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。

QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题。所以 HTTP/3 现在普及的进度非常的缓慢，不知道未来 UDP 是否能够逆袭 TCP。

巨人的肩膀

[1] 上野宣.图解HTTP.人民邮电出版社.

[2] 罗剑锋.透视HTTP协议.极客时间.

[3] 陈皓.HTTP的前世今.酷壳CoolShell.https://coolshell.cn/articles/19840.html

[4] 阮一峰.HTTP 协议入门.阮一峰的网络日志.http://www.ruanyifeng.com/blog/2016/08/http.html

读者问答

读者问：“https和http相比，就是传输的内容多了对称加密，可以这么理解吗？”

建立连接时候：https 比 http多了 TLS 的握手过程；
传输内容的时候：https 会把数据进行加密，通常是对称加密数据；

读者问：“ 我看文中 TLS 和 SSL 没有做区分，这两个需要区分吗？”

这两实际上是一个东西。

SSL 是洋文 “Secure Sockets Layer 的缩写，中文叫做「安全套接层」。它是在上世纪 90 年代中期，由网景公司设计的。

到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是 “Transport Layer Security” 的缩写），中文叫做「传输层安全协议」。

很多相关的文章都把这两者并列称呼（SSL/TLS），因为这两者可以视作同一个东西的不同阶段。

读者问：“为啥 ssl 的握手是 4 次？”

SSL/TLS 1.2 需要 4 握手，需要 2 个 RTT 的时延，我文中的图是把每个交互分开画了，实际上把他们合在一起发送，就是 4 次握手：

另外， SSL/TLS 1.3 优化了过程，只需要 1 个 RTT 往返时延，也就是只需要 3 次握手：

个人记录

http协议的特性（简要）

1、支持客户端/服务器模式
2、简单快速：客户向服务器请求服务时，只需传送请求方法和路径
3、灵活：HTTP允许传输任意类型的数据对象
4、无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5、无状态：HTTP协议是无状态协议，无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

其实文章里面总结的更好。

http协议各个版本的区别

参考：http协议各个版本的区别_me_never的博客-CSDN博客

HTTP/0.9 – 单行协议：HTTP/0.9 极其简单，请求由单行指令构成，而且只有get方法。
HTTP/1.0 – 构建可扩展性：
1、协议版本信息：协议版本信息现在会随着每个请求发送（HTTP/1.0被追加到了GET行）。
2、状态码：状态码会在响应开始时发送，使浏览器能了解请求执行成功或失败，并相应调整行为（如更新或使用本地缓存）。
3、HTTP头：引入了HTTP头的概念，无论是对于请求还是响应，允许传输元数据，使协议变得非常灵活，更具扩展性。
4、Content-Type：在新HTTP头的帮助下，具备了传输除纯文本HTML文件以外其他类型文档的能力。
5、三种请求方法： GET, POST 和 HEAD方法
HTTP/1.1 – 标准化的协议：
1、使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
2、支持管道（pipeline）网络传输（流水线操作），只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
3、新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
4、支持响应分块。
5、引入内容协商机制，包括语言，编码，类型等，并允许客户端和服务器之间约定以最合适的内容进行交换。
HTTP 2.0（基于 HTTPS）：
1、安全性也是有保障的（不再是明文传输）。
2、多路复用 (Multiplexing)：多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。
3、首部压缩（Header Compression）：在客户端和服务端之间使用首部表来跟踪和存储之前发送的键值对，如果首部没有改变或只改变了少部分，就在原来的首部表里修改或者追加，首部表在HTTP2.0的链接存续期内始终存在，减少每次通讯的数据量，对性能有提升。
4、服务端推送（Server Push，比如通知消息）:一个请求多个响应，同时客户端可以拒绝推送，将推送的数量限制为0即可，推送的时候先推送头部，如果客户端同意才会推送数据。
5、二进制格式（分帧）：头信息帧和数据帧，对计算机非常友好。
6、请求优先级
7、数据流：数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。每个请求或回应的所有数据包，称为一个数据流（Stream）。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数。
HTTP/3
把 HTTP 下层的 TCP 协议改成了 UDP + QUIC协议！

一定要客户端用公钥加密，服务端用私钥解密吗？反过来会怎么样？

如果反过来，即服务端加密会话密钥发送给客户端，然后客户端解密的话（也就是第三个随机数是服务端加密后发给客户端），因为客户端只能拥有服务端的公钥，那么服务端只能用自己的私钥加密（这样客户端才能使用公钥解密出这个随机数，计算出会话密匙）。但是中间方可以截获服务端的数字证书获得服务端的公钥，那么中间方也可以用服务端的公钥解密出会话秘钥，那样会话秘钥就泄漏了，会话也就不安全了。

什么是数字签名？

数字签名算法可以看做是一种带有密钥（公钥+私钥）的消息摘要算法，也就是说，数据签名算法是非对称加密算法和消息摘要算法的结合体。该算法包含签名和验证两项操作，遵循 “私钥签名，公钥验证” 的签名/验证方式。

可以看这儿的解释：数字签名是什么？ - 阮一峰的网络日志，写的很不错。

数字签名就是用私钥将摘要加密的结果，这样能够保证数据的完整性、放篡改、以及不可抵赖性。
在这里插入图片描述

要是HTTPS请求被拦截，伪造一个公钥证书证书和客户端进行通信，存在这种可能性吗？

这种攻击一般成为中间人攻击。

针对SSL的中间人攻击方式主要有两类，分别是SSL劫持攻击和SSL剥离攻击。

SSL劫持攻击：

SSL劫持攻击即SSL证书欺骗攻击（也就是伪造证书的情况），攻击者为了获得HTTPS传输的明文数据，需要先将自己接入到客户端和目标网站之间；在传输过程中伪造服务器的证书，将服务器的公钥替换成自己的公钥，这样，中间人就可以得到明文传输的Key1、Key2和Pre-Master-Key，从而窃取客户端和服务端的通信数据。

但是对于客户端来说，如果中间人伪造了证书，在校验证书过程中会提示证书错误（浏览器一般会检查出来），由用户选择继续操作还是返回，由于大多数用户的安全意识不强，会选择继续操作，此时，中间人就可以获取浏览器和服务器之间的通信数据。

所以，只要用户安全意识强的话，伪造证书和客户端通信基本是不可能的。

SSL剥离攻击：

这种攻击方式也需要将攻击者设置为中间人，之后将HTTPS范文替换为HTTP返回给浏览器，而中间人和服务器之间仍然保持HTTPS服务器。由于HTTP是明文传输的，所以中间人可以获取客户端和服务器的传输数据。
在这里插入图片描述
SSL剥离攻击，尤其手机浏览器，或者APP，防不胜防_hcname_新浪博客

攻击方式主要是利用用户并不会每次都直接在浏览器上输入https://xxx.xxx.com来访问网站，或者有些网站并非全网HTTPS，而是只在需要进行敏感数据传输时才使用HTTPS的漏洞。中间人攻击者在劫持了客户端与服务端的HTTP会话后，将HTTP页面里面所有的https://超链接都换成http://，用户在点击相应的链接时，是使用HTTP协议来进行访问。这样，就算服务器对相应的URL只支持HTTPS链接，但中间人一样可以和服务建立HTTPS连接之后，将数据使用HTTP协议转发给客户端，实现会话劫持。

这种攻击手段更让人难以提防，因为它使用HTTP，不会让浏览器出现HTTPS证书不可信的警告，而且用户很少会去看浏览器上的URL是https://还是http://。特别是App的WebView中，应用一般会把URL隐藏掉，用户根本无法直接查看到URL出现异常。

客户端如何验证证书

数字证书原理_zj-CSDN博客

（1）验证证书所有者、证书有效期：读取证书中的证书所有者、有效期等信息进行校验，校验证书的网站域名是否与证书颁发的域名一致，校验证书是否在有效期内
（2）验证证书颁发机构：查看服务器发来的证书中的颁发机构CA是否是操作系统信任的证书发布机构，如果不是，说明颁发机构可能是假冒伪劣的，程序会给出错误信息
（4）使用颁发机构的公钥解密获取证书里面的指纹和指纹算法信息
（5）使用步骤4获取的指纹算法，计算该证书的指纹（实际上就是哈希算法计算出一个hashcode），将这个计算的指纹与放在证书中的指纹（步骤4中计算的指纹）进行对比，如果相同，则证明服务器发来的证书合法

ps:

1、制作证书：作为服务端的A compancy，首先把自己的公钥key1发给证书颁发机构CA，向证书颁发机构CA进行申请证书；证书颁发机构有一套自己的公私钥，CA通过自己的私钥来加密key1，并且通过服务端网址等信息生成（使用一个哈希算法/指纹算法）一个证书签名(指纹)，证书签名同样使用机构的私钥进行加密；制作完成后，机构将证书发给A。
一个证书包含下面的具体内容：

证书的发布机构
证书的有效期
公钥
证书所有者（Subject）
签名所使用的算法
指纹以及指纹算法

2、中间人是否会拦截发送假证书到客户端B呢？

因为证书的签名是由服务器端网址等信息生成的，并且通过第三方机构的私钥加密的，中间人无法篡改。

http常用的请求头和响应头

JavaWeb - 常用的HTTP请求头与响应头_qq_40395278的博客-CSDN博客

HTTP请求的种类中，最基本的有4种，分别是GET、POST、PUT、DELETE。一个URL地址用于描述一个网络上的资源，而HTTP中GET、POST、PUT、 DELETE就对应着对这个资源的查、改、增、删4个操作，我们最常见的就是GET和POST了。

常用的HTTP请求头与响应头 - codedot - 博客园
 http协议的构成及字段说明（请求头、请求体、响应头）
在这里插入图片描述

在这里插入图片描述

GET与POST请求过程

GET和POST请求的区别_zj-CSDN博客
两个请求本质上都是tcp连接，请求过程类似tcp三次握手，但是稍有区别：

GET请求的过程：get请求头和数据一次性发送

1、浏览器请求tcp连接（第一次握手）
2、服务器答应进行tcp连接（第二次握手）
3、浏览器确认，并发送get请求头和数据（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
4、服务器返回200OK响应

POST请求的过程：post请求头和数据分两次发送

1、浏览器请求tcp连接（第一次握手）
2、服务器答应进行tcp连接（第二次握手）
3、浏览器确认，并发送post请求头（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
4、服务器返回100 Continue响应
5、浏览器发送数据（发了两次）
6、服务器返回200 OK响应

URI和URL的区别

在这里插入图片描述
URI 在于Identifier是统一资源标识符，可以唯一标识一个资源。

URL在于Locater，一般来说（URL）统一资源定位符，可以提供找到该资源的路径，比如http://www.zhihu.com/question/21950864，但URL又是URI，因为它可以标识一个资源，所以URL又是URI的子集。

Md5加密和普通加密的区别?

md5是一种哈希算法。MD5加密指的是利用MD5算法来计算摘要，作为文件校验的hashcode。

可以利用MD5的优势解决了公开网络中交换密钥、认证的问题。

DNS解析错误，怎么排查？

DNS解析失败怎么办？ - 知乎
一、用nslookup来判断是否真的是DNS解析故障
二、查询Dns服务器工作是否正常
三、清除DNS缓存信息
四、修改hosts文件

电脑应用使用正常，但是浏览器无法打开网页，怎么定位问题?

可以查看http的返回码，确认问题出在哪一步。

或者，可以使用ping，ping不通的话可能的原因有：网络不可达，主机不可达，协议不可达，端口不可达，需要设置分片却无法分片或者超时等。如果ping通的话，可以换一个浏览器查看一下或者检查防火墙设置。

HTTP请求/响应报文组成部分

在这里插入图片描述

用户反映你开发的网站访问很慢可能会是什么原因？

经典面试题：用户反映你开发的网站访问很慢可能会是什么原因_Victor Lv的博客-CSDN博客

问题场景：某个用户向你反映说你开发的网站访问速度很慢，但是该用户访问其他网站很正常，分析下原因、有哪些工具分析原因、怎么解决问题？

首先访问其他网站没有问题，那么可以理解为server端出现的问题，而不是client端（用户网络不好或者DNS解析出错等可能）。那么可能的原因有：

1、服务器出口带宽不够用。这是一个很常见的瓶颈。一方面，可能是本身购买的服务器出口带宽就很小（企业购买带宽相当昂贵），一旦用户访问量上来了，并发量大了，自然均分给用户的出口带宽就更小了，所以某些用户的访问速度就会下降很多。另一个，就是跨运营商网络导致带宽缩减，例如很多公司的网站（服务器）是放在电信的网络上的，而如果用户这边对接的是长城或者说联通的宽带，运营商之间网络传输在对接时是会有限制的，这就可能导致带宽的缩减。

2、服务器负载过大忙不过来，比如说CPU和内存消耗过大，来不及处理。

3、网站的开发代码优化不够，例如mysql语句没有进行优化，导致数据库的读写相当耗费时间。

4、数据库的瓶颈，也是很常见的一个瓶颈，这点跟上面第三个原因可以一起来说。当我们的数据库变得愈发庞大，比如好多G好多T这么大，那对于数据库的读写就会变得相当缓慢了，索引优化固然能提升一些效率，但数据库已经如此庞大的话，如果每次查询都对这么大的数据库进行全局查询，自然会很慢。这个学过数据库的话也是挺容易理解的。

针对上面可能的原因，有哪些方法和工具去检测呢？

（1）某个用户反馈网站访问变慢，怎么去定位问题。首先你自己也打开下网站，看是否会出现用户反映的问题，如果你这边访问没问题，那就可能是用户那边的问题了，这块就是要先确定是用户那一方的问题还是自身比如说服务器或者网站的问题。

（2）发现确实是自己服务器或者网站的问题，那么可以利用浏览器的调试功能（一般浏览器都会有），调试网络看看各种数据加载的速度，哪一项消耗了多少时间都可以看到，是哪块数据耗时过多，是图片加载太慢，还是某些数据加载老半天都加载不出来。

（3）然后针对服务器的负载情况，可以去查看下服务器硬件（网络带宽、CPU、内存）的消耗状况。带宽方面查看流量监控看是不是已经到了峰值，带宽不够用了，如果是公司自己买服务器搭的网站服务器的话，需要自己搭建监控环境；如果用的是阿里云腾讯云这些的，那这些平台那边会提供各方面的监控比如CPU、带宽等等，在后台就可以看到了。

（4）如果发现硬件资源消耗都不高，都比较充裕，那要去看看是不是程序的问题了。这个可以通过查日志来找，比如PHP日志、Apache日志、mysql日志等等的错误日志，特别如mysql有个慢查询的日志功能，可以看到是不是某条mysql语句特别慢，如果某条语句花的时间太长，那这条语句很有可能有问题。

（5）至于说到的数据库太庞大，这个直接看就看得到了，比如一个表的文件大小变得特别大了。

针对上面的这些问题，有哪些解决和优化的办法呢？

（1）出口带宽的问题，这个很简单，加带宽，有钱就多买带宽，很简单。

（2）mysql语句优化，开发人员职责。

（3）数据库太庞大，为了读写速度，进行“拆表”、“拆库”，就是把数据表或者数据库进行拆分。

（4）上面的拆库拆表都是针对数据库实在太庞大才会这样做，一般在此之前会有其他优化方法，比如mysql的主从复制，一台主服务器专门用于写，然后其他从服务器用来读，写完之后会同步更新到其他读的服务器中。例如阿里的双十一活动，都不知道用了多少万台服务器一起在扛着。

（6）还有这几年用得比较多的非关系型数据库，它使用了缓存机制，它把数据缓存到了内存，用户访问数据直接从内存读取，读取速度就比在磁盘中读取快了很多，还有它的一个key-value读取机制，这个听师兄说之后没听懂。

（7）CDN（content-delivery-network：内容分发网络），鸡蛋放在多个篮子里，把数据放在离用户更近的位置（例如网站的一些静态文件比如图片或者js脚本），用户访问时判断IP来源是广州，那就通过智能DNS解析到广州的服务器上，直接从广州的篮子里去获取数据，速度就快了。这里有个静态数据和动态数据的概念，例如图片和一些js文件一般是不变的，那就可以把它们的映像分布到全国各地，加快速度，而一些需要在网站后台动态产生的一些数据，则需要去到网站所在的服务器去产生并得到。这个涉及到两种数据的显示的问题，这就交由浏览器处理了。同时异步加载的技术例如前端的Ajax技术，异步请求数据，可以使这些动态数据延迟加载，这块自己不怎么了解，可能表述不好。前端开发的人员应该更懂一些。

（8）上面都没有说到架构的优化，如果网站扛不住，是不是网站架构已经不能适应了，比如做个小博客把数据库服务器和web服务器都用同一台服务器，那所有负载都在同一台服务器上了。但是访问量上来扛不住了，就得加服务器了，就得在架构上优化了，比如在数据库上做集群，在web服务器上也做集群，比如web服务器集群，在服务器前面加一个负载均衡，负载均衡就是专门负责分发，把用户的请求均匀分布到各个服务器上。

网页/应用访问慢突然变慢，如何定位问题?

1、top、iostat查看cpu、内存及io占用情况
2、内核、程序参数设置不合理：查看有没有报内核错误，连接数、用户打开文件数这些有没有达到上限等等
3、链路本身慢：是否跨运营商、用户上下行带宽不够、dns解析慢、服务器内网广播风暴什么的
4、程序设计不合理：是否程序本身算法设计太差，数据库语句太过复杂或者刚上线了什么功能引起的
5、其它关联的程序引起的：如果要访问数据库，检查一下是否数据库访问慢
6、是否被攻击了：查看服务器是否被DDos了等等
7、硬件故障这个一般直接服务器就挂了，而不是访问慢

HTTP 断点续传

HTTP 断点续传协议头部分析_巫山老妖-CSDN博客

断点续传，就是要从文件已经下载的地方开始继续下载。以前版本的 HTTP 协议是不支持断点的，HTTP/1.1 开始支持。一般断点续传时才用到 Range(请求头) 和 Content-Range（响应头）实体头。

Range ：
用于请求头中，指定第一个字节的位置和最后一个字节的位置，一般格式：

Range:(unit=first byte pos)-[last byte pos]

Content-Range：
用于响应头，指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。一般格式：

Content-Range: bytes (unit first byte pos) - [last byte pos]/[entity legth]

http断点续传-Note-51CTO博客

请求下载整个文件:

GET /test.rar HTTP/1.1
Connection: close
Host: 116.1.219.219
Range: bytes=0-801 //一般请求下载整个文件是bytes=0- 或不用这个头

一般正常回应：

HTTP/1.1 200 OK
Content-Length: 801
Content-Type: application/octet-stream
Content-Range: bytes 0-800/801 //801:文件总大小
If-Range = “If-Range” “:” ( entity-tag | HTTP-date )

IF-Range头部需配合Range，如果没有Range参数，则If-Range会被视为无效。

如果If-Range匹配上，那么客户端已经存在的部分是有效的，服务器将返回缺失部分，也就是Range里指定的，然后返回206（Partial content，服务器已经成功处理了部分内容)；

否则证明客户端的部分已无效（可能已经更改），那么服务器将整个实体内容全部返回给客户端，同时返回200OK。

浅谈HTTP断点续传原理_小马过河-CSDN博客

注意上面的，什么时候客户端的部分会失效呢？终端发起续传请求时，URL对应的文件内容在服务端已经发生变化，此时续传的数据就是错误的。那要如何解决这个问题呢：

我们需要有一个标识文件唯一性的方法。在RFC2616中也有相应的定义，比如实现Last-Modified来标识文件的最后修改时间，这样即可判断出续传文件时是否已经发生过改动。同时RFC2616中还定义有一个ETag的头，可以使用ETag头来放置文件的唯一标识，比如文件的MD5值。

然后终端在发起续传请求时应该在HTTP头中申明If-Match 或者If-Modified-Since 字段，帮助服务端判别文件变化。如果匹配成功，才会发起续传，否则发生的是重传。

另外RFC2616中同时定义有一个If-Range头，终端如果在续传是使用If-Range。If-Range中的内容可以为最初收到的ETag头或者是Last-Modfied中的最后修改时候。服务端在收到续传请求时，通过If-Range中的内容进行校验，校验一致时返回206的续传回应，不一致时服务端则返回200回应，回应的内容为新的文件的全部数据。

HTTP缓存字段

http头字段缓存详解（1） - 假程序猿 - 博客园

1、Cache-Control / Pragma
这个HTTP Head字段用于指定所有缓存机制在整个请求/响应链中必须服从的指令。可选值：
Public：所有内容都将被缓存，在响应头中设置
Private：内容只缓存在私有缓存中，在响应头中设置
no-cache：所有内容都不会被缓存，在请求头和响应头中设置
no-store：所有内容都不会被缓存在缓存或Internet临时文件中，在响应头中设置

2、Expires（失效）
它通常的使用格式是Expires:Fri ,24 Dec 2027 04:24:07 GMT，后面跟的是日期和时间，
超过这个时间后，缓存的内容将失效，浏览器在发出请求之前会先检查这个页面的这个字段，查看页面是否已经过期，过期了就重新向服务器发起请求；

3、Last-Modified / If-Modified：
它一般用于表示一个服务器上的资源最后的修改时间，资源可以是静态或动态的内容，
通过这个最后修改时间可以判断当前请求的资源是否是最新的。

一般服务端在响应头中返回一个Last-Modified字段，告诉浏览器这个页面的最后修改时间，浏览器再次请求时会在请求头中增加一个If-Modified字段，询问当前缓存的页面是否是最新的，如果是最新的就返回304状态码，告诉浏览器是最新的，服务器也不会传输新的数据（ps:也就是服务器省略了具体内容的传输，只需返回一个标识状态码）

4、Etag/If-None-Match：
Etag与Last-Modified有类似的功能，它的作用是让服务端给每个页面分配一个唯一的编号，然后通过这个编号来区分当前这个页面是否是最新的，这种方式更加灵活，但是后端如果有多台Web服务器时不太好处理，因为每个Web服务器都要记住网站的所有资源，否则浏览器返回这个编号就没有意义了。

在这里插入图片描述

可以明显的看到上面介绍的几个字段。
    1、Cache-Control:max-age=2592000：缓存内容将在2592000秒后失效（30天）。
    2、ETag:"58d48c15-f7b"：页面编号
    3、Expires:Wed, 12 Jul 2017 05:42:41 GMT：缓存内容将在2017年7月12日后过时。
    4、Last-Modified:Fri, 24 Mar 2017 03:01:41 GMT：服务端资源最后修改时间。

HTTP缓存有什么安全威胁吗？

产生缓存的条件:
1、Get请求
2、请求地址不发生改变

缓存可以提升响应效率。

缓存命中率：从缓存中得到数据的请求数与所有请求数的比率。

安全威胁：缓存攻击，利用缓存欺骗获取他人敏感信息。

http用户代理

什么是HTTP用户代理？

HTTP代理又称Web缓存或代理服务器(Proxy Server)，是一种网络实体，能代表浏览器发出HTTP请求，并将最近的一些请求和响应暂存在本地磁盘中，当请求的Web页面先前暂存过，则直接将暂存的页面发给客户端(浏览器)，无须再次访问Internet。

使用HTTP代理的Web访问过程
在这里插入图片描述

zj134_

关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
1
评论
常见的http面试问题

原文：硬核！30 张图解 HTTP 常见的面试题，给你整明白_小林coding-CSDN博客原文的作者好几个系列的写的特别好，墙裂推荐。文章目录前言正文01 HTTP 基本概念02 GET 与 POST03 HTTP 特性04 HTTP 与 HTTPS05 HTTP/1.1、HTTP/2、HTTP/3 演变巨人的肩膀读者问答个人记录前言在面试过程中，HTTP 被提问的概率还是比较高的。小林我搜集了 5 大类 HTTP 面试常问的题目，同时这 5 大类题跟 HTTP 的发展和演变关联性是比较大的，
复制链接

扫一扫