总结面试HTTP和HTTPS，图文并茂版~

HTTP是什么？

超文本传输协议，两点之间传输 超文本数据的 约定 。

HTTP特性

明文传输，遵循key-value模式，简单易懂；灵活可扩展，字段等都不是固定的，应用广泛和跨平台

HTTP缺点

1. 无状态（每次请求都是独立的，服务器不会保存任何客户端的上下文信息）
2. 明文传输
3. 信息泄露（信息被盗取，报文未校验可能被修改）

HTTP只能用于服务器与客户端之间吗？

不仅只有通过互联网服务器获取资源到浏览器，还有服务器和服务器之间的通信，比如负载均衡，跨服务器等会话管理方面使用，反向代理等。

反向代理：客户端把请求先发给代理的服务器，服务器再把请求转发给后端服务器，代理服务器再把所需资源发送给客户端。这样既可以隐藏后端服务器的IP地址（安全）又可以达到负载均衡的效果，还可以缓存！

Http不能用于客户端与客户端之间？

HTTP本身不支持客户端与客户端之间的通信，由于HTTP是基于请求-响应，需要依赖一个中央服务器的角色来接受请求。

不过，如果要在客户端与客户端之间通信，可以采取WebSocket（WebSocket：它提供了一个全双工通信通道，允许服务器与客户端之间进行实时、双向的信息交换。）等，考虑中间采取一种机制达成。

HTTP常见的状态码有哪些？有什么含义？

• 1xxx：表示请求正在处理
• 2xxx： 204表示服务器成功处理请求，没有返回信息 206服务器处理了部分GET请求，服务器返回的body数据是资源的一部分
• 3xxx：301资源位置永久改变 302表示资源临时改变，需要新访问一个URL才可以 304资源未修改主要用于缓存协商的。
• 4xxx：404资源路径不存在 403服务器禁止访问 401未授权 （403，你被拦，401，你未权）
• 5xxx：500服务端出问题了（通常是服务端出 Bug 了） 502错误网关服务端返回的却是一个错误的响应。

HTTP常见的状态码有哪些？有什么含义？

1. 各个状态码的具体含义，写的很好！
2. 1xxx 表示正在处理当中
3. 2xxx主要表示请求成功
4. 204 服务器无需发送新内容，请求体为空
5. 200 正常被处理
6. 3xxx资源位置发送改变
7. 304 缓存重定向
8. 302 临时性重定向
9. 301 永久性重定向
10. 4xxx客户端的失误导致无法请求到资源
11. 404 资源路径不存在
12. 403 服务器禁止访问
13. 400 请求报文有误
14. 5xxx服务器的问题无法请求到资源
15. 503 服务器正忙
16. 502 服务器作为网关或代理时返回的错误码
17. 501 服务器不支持
18. 500 笼统的错误

HTTP常见字段有哪些？

host：服务器的域名

content-type：内容的类型

content-encoding:编码方式

connection：是否使用长连接

Authorization：⽤于进⾏身份验证的凭据。

Cache-Control：指定缓存策略。

请求方式

• GET
• POST

幂等，目的，对服务器是否安全，传参方式，资源大小，浏览器是否主动缓存....

版本演变

HTTP1.0-HTTP1.1

1. 长连接（节省三次握手建立连接的开销）

1. 管道复用？（可以减少整体的响应时间。 ）

在同⼀个 TCP 连接⾥⾯，客户端可以发起多个请求，只要第⼀个请求发出去了，不必等其回来，就可以发第⼆个请求出去

注意：服务器必须按照接收请求的顺序发送对这些管道化请求的响应。 那么如果处理请求1过久，对导致后序请求阻塞（队头阻塞）

1. 宽带优化

Range头部可以申请部分资源

但是 HTTP1.1 仍然存在着不少问题：

• 头部冗余，每个请求和响应都要带有一定的头部信息
• 服务器顺序响应请求，可能存在队头阻塞
• 并发数有限6
• 请求只能有客户端开始发送

HTTP1.1-HTTP2.0

1. 二进制帧：将信息分割为二进制进行传输，提高效率
2. 服务器推送：服务器向客户端发送一个或者多个请求，无需客户端发送

1. 头部压缩：利用HPACK算法减少了头部数据量（核心就是客户端和服务器共同维护一个字典）

• 静态字典：包含了61个常见的HTTP头部字段和它们的值，通过索引号来引用。
• 动态字典：在同一个连接上，重复传输相同的HTTP头部时，当需要交换新的头部字段动态加入
• Huffman编码：频繁出现的字符会被分配更短的编码，而不常见的字符则分配更长的编码，这样整体上可以减少数据的传输大小。

1. 并发传输：

注意：HTTP2是基于TCP协议传输，而TCP保存收到的字节数据是完整有序才会将缓冲区里的数据传输给HTTP应用，因此HTTP2也会存在队头阻塞。

问题：

• 队头阻塞
• TCP与TLS的握⼿时延迟 （3RTT）

• ⽹络迁移需要重新连接

HTTP2.0-HTTP3.0

1. 基于UDP协议（无队头阻塞）

⼀个连接上的多个stream之间没有依赖, 如果⼀个stream丢了 ⼀个UDP包，不会影响后⾯的stream，不存在 TCP 队头阻塞

1. 零RTT建立连接

• 首次连接（1 RTT）用来交换加密的参数和密钥
• 后序连接（0 RTT）浏览器从缓存中获取密钥信息，不需要等待服务器的响应就可以开始数据传输

1. 连接迁移

QUIC 允许在⽹络切换（如从 Wi-Fi 到移动⽹络）时，将连接迁移到新的 IP 地址，从⽽减少连接的中断时间。

1. 向前纠错机制：

每个数据包除了它本身的内容之外，还包括了部分其他数据包的数据，因此少量的丢包可以通 过其他包的冗余数据直接组装⽽⽆需重传。向前纠错牺牲了每个数据包可以发送数据的上限，但是减少了因为 丢包导致的数据重传。

HTTPS和HTTP的区别

HTTPS是什么

HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证。默认端口号是 443

1. SSL/TSL（保证通信双方合法性）

SSL/TLS 的核心要素是非对称加密。加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。

非对称加密：采用两个密钥——一个公钥，一个私钥。

公钥：可以公开分享，用于加密信息。公钥加密的信息只能用相应的私钥来解密。

持有公钥的人：验证签名确实是由持有私钥的人所生成的

私钥：必须保密，用于解密由公钥加密的信息。私钥签名的信息可以用相应的公钥来验证签名。

持有私钥的人：解密用公钥加密的信息

对称加密：为私钥加密，使⽤相同的密钥来进⾏加密和解密。

2. 摘要算法（类似于协商缓存Etage，保证传输内容的安全性）

为了保证传输的内容不被修改，可以将传输的内容计算出⼀个【指纹】，对⽅收到后，也把接收的内容计算出⼀个 【指纹】，然后进⾏对⽐，如果【指纹】相同，则说明内容没有被篡改

常常会使⽤摘要算法（哈希函数）来计算 出内容的哈希值，通过摘要算法可以⽣成数据的唯⼀标识，从⽽验证数据的完整性。

3. 数字证书（进行双方信息验证的中间人//类似于一个裁判）

why：

• 身份验证：确保持有者的身份，确保用户/服务器是他们声称的那个实体
• 公钥分发：证书包含公钥，用于加密会话密钥或其他敏感数据。用户可以信任证书中的公钥，因为它是经过CA验证的。
• 加密通信：在SSL/TLS握手过程中，服务器向客户端发送其数字证书，客户端使用CA的公钥验证证书的有效性。验证成功后，客户端和服务器使用证书中的公钥和私钥进行加密通信。

how：

4. 加密传输

混合加密：

通信建⽴前：采⽤⾮对称加密的⽅式交换【会话密钥】，后续不再使⽤⾮对称加密;

通信过程中：全部使⽤对称加密的【会话密钥】⽅式，加密明⽂数据。

采⽤「混合加密」的⽅式的原因：

对称加密：只使⽤⼀个密钥，运算速度快，密钥必须保密，⽆法做到安全的密钥交换;

⾮对称加密：使⽤两个密钥，公钥可以任意分发⽽私钥保密，解决密钥交换问题，但速度慢。

5. 建立连接过程

HTTPS和HTTP的区别

明⽂的⽅式在⽹络中传输数据，HTTPS 解决了HTTP 不安全的缺陷，在 TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。

HTTPS 在 TCP 三次握⼿之后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。

HTTP 的端⼝号是 80，HTTPS 的端⼝号是 443。

HTTPS 协议需要向 CA（证书权威机构） 申请数字证书，来保证服务器的身份是可信的。

HTTP版本演变

HTTP2的改变

HTTP3的改变

HTTP缓存

强制缓存（浏览器中的缓存没有过期，不会向服务器发送请求）

• Expires强缓存：拿本地时间戳与强缓存时间进行比较，很明显当本地时间不准是一个大问题
• Cache-Control强缓存：

协商缓存（检查到过期，向服务器发送请求，询问服务器该资源是否有更新）

协商缓存这两个字段都需要配合强制缓存中 Cache-Control 字段来使⽤，只有在未能命中强制缓存的时候，

才能发起带有协商缓存字段的请求。

1. 基于 Last-Modified(请求后) 和 If-Modified-Since（请求时） 的协商缓存

缺点：

因为是根据⽂件修改时间来判断的，⽂件内容本身不修改的情况下，依然有可能更新⽂件修改时间 （⽐如修改⽂件名再改回来），这样，就有可能⽂件内容明明没有修改，但是缓存依然失效了。

如果文件修改在极短时间内发生，而未被记录，修改丢失。

1. 基于 ETag 的协商缓存

缺点：

ETag需要更多的计算开销。如果⽂件尺⼨⼤，数量多，并且计算频繁，那么ETag的计算就会影响服务器的性能。

ETag有强验证和弱验证，所谓将强验证，ETag⽣成的哈希码深⼊到每个字节。哪怕⽂件中只有⼀个字节改变 了，也会⽣成不同的哈希值，它可以保证⽂件内容绝对的不变。但是，强验证⾮常消耗计算量。

ETag还有⼀ 个弱验证，弱验证是提取⽂件的部分属性来⽣成哈希值。因为不必精确到每个字节，所以他的整体速度会⽐强 验证快，但是准确率不⾼。会降低协商缓存的有效性。