计算机网络知多少面试---第2篇

强缓存与协商缓存

强缓存

Cache-Control和Expires都是用于控制强缓存的HTTP头部字段，但它们之间有一些关键的区别。

1. 时间表示方式：
   • Cache-Control: 使用秒数来表示缓存的有效时间，例如Cache-Control: max-age=3600表示缓存有效期为3600秒（1小时）。
   • Expires: 使用日期时间来表示缓存的过期时间，例如Expires: Wed, 05 Mar 2024 08:00:00 GMT表示缓存在这个具体的日期时间过期。
2. 依赖时间机制：
   • Cache-Control: 不依赖于本地时间，使用相对时间来计算缓存的有效期。
   • Expires: 依赖于本地时间，浏览器通过比较本地时间和Expires字段的时间来判断缓存是否过期。
3. 精确度：
   • Cache-Control: 提供了更灵活、精确的缓存控制，可以根据秒数精确指定缓存的有效期。
   • Expires: 在某些情况下，由于本地时间不准确，可能导致缓存的时间判断不够精确，尤其是在跨时区的情况下。
4. 兼容性：
   • Cache-Control: 是HTTP/1.1引入的新标准，更现代，广泛被支持。
   • Expires: 是早期的HTTP/1.0标准，虽然仍然有效，但相对来说较为陈旧，容易受到本地时间设置的影响。

协商缓存

基于Last-Modified和基于ETag的协商缓存都是用于在客户端和服务器之间进行资源的条件请求和响应，判断是否需要返回新的资源。以下是它们的主要区别：

基于 Last-Modified 的协商缓存

1. 机制：
   • 服务器在响应头中添加Last-Modified字段，表示资源的最后修改时间。
   • 客户端在下一次请求时，会在请求头中携带If-Modified-Since字段，值为上次服务器返回的Last-Modified时间。
2. 验证过程：
   • 服务器通过比较请求头中的If-Modified-Since和资源的实际最后修改时间来决定是否返回新的资源。
   • 如果没有修改，服务器返回304状态码表示资源未修改，客户端继续使用缓存；如果有修改，返回新的资源。
3. 优点：
   • 相对简单，只涉及到时间的比较。
4. 缺点：
   • 时间精度只到秒，可能导致缓存未能及时更新。
   • 依赖于服务器时间，可能存在时间不准确的问题。

基于 ETag 的协商缓存

1. 机制：
   • 服务器在响应头中添加ETag字段，表示资源的唯一标识（通常是文件内容的哈希值）。
   • 客户端在下一次请求时，会在请求头中携带If-None-Match字段，值为上次服务器返回的ETag。
2. 验证过程：
   • 服务器通过比较请求头中的If-None-Match和资源的实际ETag来决定是否返回新的资源。
   • 如果两者匹配，服务器返回304状态码表示资源未修改，客户端继续使用缓存；如果不匹配，返回新的资源。
3. 优点：
   • 不依赖于文件修改时间，更精确地判断资源是否被修改。
   • 通过文件内容的哈希值作为唯一标识，解决了基于Last-Modified的缺陷。
4. 缺点：
   • 计算哈希值可能会增加服务器负担。
   • 依然需要与服务器通信，增加请求时延。

总体而言，基于ETag的协商缓存在资源变更的精准度和灵活性上优于基于Last-Modified的协商缓存。在实际应用中，可以根据具体场景和需求选择使用其中一种或结合两者的方式。

设置文件的缓存策略（强缓存或协商缓存）通常取决于文件的变化频率以及缓存的需求。哈希值通常与缓存策略结合使用，但并非唯一的因素。

强缓存与哈希值的文件：

• 哈希值的用途： 哈希值通常是通过对文件内容计算而得，它能唯一地标识文件的内容。当文件内容发生变化时，哈希值也会改变。
• 强缓存优势： 对于哈希值变化频繁的文件，强缓存是合适的，因为它能够快速判断文件是否过期，而不需要与服务器通信。这适用于静态资源，如JavaScript、CSS、图像等，它们的内容经常发生变化，但往往不需要进行详细的协商。

协商缓存与没有哈希值的文件：

• 没有哈希值的情况： 有些文件可能没有明确的哈希值，或者文件内容不会经常变化。
• 协商缓存优势： 对于这类文件，设置协商缓存更为合适。服务器可以根据文件的修改时间（Last-Modified）或其他方式生成唯一标识（ETag），用于在客户端和服务器之间进行协商，确定是否需要返回新的文件。这种方式更为灵活，能够避免频繁更新哈希值，节省服务器计算资源。

HTTP/1.0 和 HTTP/1.1 的区别

HTTP/1.0是一台老旧的电视，而HTTP/1.1是一台升级后的现代电视。

1. 连接管理：
   • HTTP/1.0： 这台老电视，每次想切换频道都需要重新开启电视，这就是HTTP/1.0默认使用短连接的感觉。
   • HTTP/1.1： 支持长连接，每一个TCP连接上可以传送多个HTTP请求和响应，默认开启 Connection:Keep-Alive。这台现代电视，在切换频道的时候不需要重启，可以保持一直开启。
2. 缓存控制：
   • HTTP/1.0： 老电视只能按照播放表来看电影，无法灵活选择。这就是HTTP/1.0使用简单的缓存控制方式。
   • HTTP/1.1： 而HTTP/1.1，有各种缓存控制选项，可以根据需要智能地选择，就像你可以灵活选择电视节目一样。
3. 管道化：
   • **HTTP/1.1：**引入的管道化，可以在同一连接上并行传输多个请求。 就像现代电视支持画中画，可以同时播放多个频道。但是响应必须按照请求发出的顺序依次返回。
4. Host字段：
   • HTTP/1.1： 让我们想象现代电视有多个输入插槽，每个插槽代表一个站点。HTTP/1.1引入了Host字段，就像你可以选择不同的插槽一样，让同一台服务器能够创建多个Web站点。
5. 状态码：
   • HTTP/1.1： 新增24个错误状态码
6. 带宽优化：
   • HTTP/1.1： 想象你的现代电视支持按需观看，只需下载你想要的部分。HTTP/1.1引入了Range头部，就像你可以选择观看电影的某个片段一样，实现了带宽的更好利用和断点续传功能。

HTTP/2.0 和 HTTP/1.1 的区别

1. 二进制分帧：

• 联想图像： 想象一辆超级快的列车，在原有的列车上增加了一个专门传递信息的车厢。
• 关键特性： HTTP/2.0引入了二进制分帧层，就像列车上的专用车厢一样，能够更高效地传递和处理数据，突破了HTTP/1.1的性能限制。

2. 多路复用（Multiplexing）：

• 联想图像： 想象列车上的多节车厢，每个车厢可以独立运行，不再依赖前后车厢。
• 关键特性： HTTP/2.0支持多路复用，就像列车上的多节车厢，允许同时通过单个连接发起多重请求-响应消息，提高了性能，降低了延迟。

3. 首部压缩：

• 联想图像： 想象数据经过专门设计的压缩算法，就像将一本厚书压缩成了一小包。
• 关键特性： HTTP/2.0使用HPACK算法对header数据进行压缩，就像将信息压缩成小包一样，减少了传输数据的体积，提高了传输速度。

4. 服务端推送（Server Push）：

• 联想图像： 想象列车站台上的服务员主动推送了你可能会需要的东西，而无需你明确要求。
• 关键特性： HTTP/2.0允许服务器主动向客户端推送资源，就像服务员主动提供可能需要的东西一样，减少了客户端的请求延迟。

HTTPS 的工作原理

1. 请求建立连接：
   • 场景： 客户端站在服务器门口，请求进入。
   • 动作： 客户端发送请求报文，希望与服务器建立连接。
2. 生成密钥对与数字证书：
   • 场景： 服务端打开了一扇门，门后有两把锁。
   • 动作： 服务端产生了一把公钥和一把私钥，将公钥发送给CA机构。CA机构用自己的私钥加密服务端的公钥，产生了数字证书，类似一把“双重锁”。
3. 发送数字证书：
   • 场景： 服务端将数字证书贴在门上，告诉客户端“这是我的身份证”。
   • 动作： 服务端将CA生成的数字证书发送给客户端。
4. 验证数字证书：
   • 场景： 客户端检查门上的身份证是否真实有效。
   • 动作： 客户端使用自己保存的CA机构的公钥，解密数字证书，验证其合法性。如果合法，取出服务端的公钥。
5. 生成对称密钥：
   • 场景： 客户端带着服务端的公钥回到家。
   • 动作： 客户端在家生成了一个随机码（对称密钥）。
6. 传输对称密钥：
   • 场景： 客户端通过门口的邮箱将随机码送回给服务端。
   • 动作： 客户端将生成的随机码通过加密后发送给服务端。
7. 解密对称密钥：
   • 场景： 服务端在门口的邮箱里找到了一封信，里面是一串解锁密码。
   • 动作： 服务端用自己的私钥解密客户端发来的随机码，得到了相同的对称密钥。
8. 对称加密传输：
   • 场景： 双方都有了同一把锁，可以用来传递信件。
   • 动作： 客户端和服务端通过对称密钥进行加密和解密，实现了安全的数据传输。

HTTP多个TCP连接怎么实现

多个TCP连接是靠服务器对Connection: keep-alive头部进行了支持。

也就是服务器需要理解并支持Connection: keep-alive头部。如果服务器支持保持连接，它将在响应中包含相同的头部，表示同意继续保持连接。

想象你在和朋友打电话。每次你想告诉朋友一件事情，你都得先打一个电话，说完后挂断。下次再想说一件新的事情，就得重新拨号，说完再挂断。这样的话费和时间都挺多的。

现在，如果你和朋友约好，在一个电话里可以说很多事情，说完一个，不用挂断，直接说下一个。这样省事省钱，而且信息传递更迅速。

在计算机通信中，就好像你和服务器建立了一个电话连接，而Connection: keep-alive就是告诉服务器，我们之间的电话不要挂断，我可能还会在这个电话上告诉你更多的事情。这样服务器就不用为每个请求都重新建立连接，提高了效率，也减少了一些开销。