△ 46次从输入 URL 到展现页面的全过程困难

当你在浏览器中输入一个 URL 并按下回车键，直到页面展现，这个过程中涉及多个步骤，包括 DNS 解析、TCP 连接、HTTP 请求和响应、以及页面渲染等。以下是这个全过程的详细描述：

1. 输入 URL

用户在浏览器的地址栏输入一个 URL 并按下回车键。

2. URL 解析

浏览器解析输入的 URL，提取协议（如 HTTP、HTTPS）、主机名（如 \www.example.com）、端口号（如果指定）、路径（如 /index.html）和查询参数。

3. 检查缓存

浏览器会首先检查浏览器缓存、操作系统缓存、路由器缓存以及 ISP 缓存中是否有该 URL 对应的资源。如果缓存命中并且资源未过期，则直接从缓存中加载资源。

4. DNS 解析

如果缓存未命中，浏览器需要将主机名转换为 IP 地址。这个过程称为 DNS 解析。步骤如下：

浏览器缓存：检查浏览器的 DNS 缓存是否有该域名的 IP 地址。
操作系统缓存：如果浏览器缓存没有命中，检查操作系统的 DNS 缓存。
本地 HOSTS 文件：操作系统会查找本地的 HOSTS 文件，看是否有手动配置的域名-IP 映射。
DNS 服务器查询：如果以上步骤都没有命中，操作系统会向配置的 DNS 服务器（通常是 ISP 提供的或手动配置的 DNS 服务器）发起 DNS 查询。DNS 服务器会递归查询其他 DNS 服务器，直到找到对应的 IP 地址。

5. 建立 TCP 连接

DNS 解析得到 IP 地址后，浏览器与服务器建立 TCP 连接。具体步骤如下：

三次握手：TCP 使用三次握手来建立连接：
- 客户端发送一个 SYN 数据包给服务器，表示请求建立连接。
- 服务器收到后，发送一个 SYN-ACK 数据包给客户端，表示同意连接。
- 客户端收到 SYN-ACK 数据包后，发送一个 ACK 数据包给服务器，连接建立成功。

6. 发送 HTTP 请求

TCP 连接建立后，浏览器构建并发送 HTTP 请求。包括以下内容：

请求行：包括请求方法（如 GET、POST）、URL 和 HTTP 版本。
请求头：包括主机名、用户代理、接受的内容类型、接受的语言、Cookie 等信息。
请求体（可选）：主要用于 POST 请求，包含提交的数据。

7. 服务器处理请求

服务器收到请求后，处理请求并生成响应。服务器的处理过程包括：

请求解析：解析请求行和请求头，提取必要的信息。
身份验证（可选）：验证用户身份，如检查 Cookie 或 Token。
路由处理：根据请求的路径和方法，将请求路由到相应的处理程序。
业务逻辑：执行具体的业务逻辑，如查询数据库、调用外部 API、执行计算等。
生成响应：生成响应头和响应体。响应体可以是 HTML、JSON、XML、图像、文件等。

8. 发送 HTTP 响应

服务器将生成的 HTTP 响应通过已建立的 TCP 连接发送给客户端。响应包括：

状态行：包括 HTTP 版本、状态码（如 200、404、500）和状态描述。
响应头：包括内容类型、内容长度、日期、服务器信息、Cookie 等。
响应体：包含实际的响应数据，如 HTML 内容、图像数据等。

9. 浏览器接收响应

浏览器接收到服务器的响应后，开始处理响应数据：

解析 HTML：浏览器解析 HTML 文档，构建 DOM 树。
加载资源：解析 HTML 时，发现外部资源（如 CSS、JavaScript、图像等），会发起新的 HTTP 请求加载这些资源。
解析 CSS：浏览器解析 CSS，构建 CSSOM 树。
执行 JavaScript：浏览器解析并执行 JavaScript，可能会进一步修改 DOM 树和 CSSOM 树。
构建渲染树：根据 DOM 树和 CSSOM 树构建渲染树。

10. 页面渲染

浏览器根据渲染树，计算每个元素的位置和样式，进行页面布局（Layout）。接着，浏览器将渲染树绘制到屏幕上，展示完整的页面。

11. 持续加载和交互

页面加载完成后，用户可以与页面进行交互。JavaScript 可以继续执行，响应用户操作，发起异步请求（如 AJAX 或 Fetch），动态更新页面内容。

过程中的优化

在这个过程中，可以通过多种优化手段来提升页面加载速度和用户体验，例如：

DNS 预解析：在 HTML 中使用 <link rel="dns-prefetch" href="//example.com"> 提前解析 DNS。
TCP 连接复用：使用 HTTP/2 或保持 TCP 连接来复用连接，减少握手延迟。
缓存优化：合理使用缓存控制头（如 Cache-Control、Expires）和浏览器缓存。
压缩和缩小资源：使用 Gzip 或 Brotli 压缩传输内容，缩小 CSS、JavaScript 和图像资源的大小。
异步加载资源：使用 async 或 defer 属性异步加载 JavaScript，减少阻塞渲染。

通过以上过程和优化手段，浏览器能够高效地将用户输入的 URL 展现为完整的网页。

△ 42次 TCP 怎么保证可靠传输？中等

TCP（Transmission Control Protocol，传输控制协议）通过以下几个机制来保证数据的可靠传输：

三次握手（Three-Way Handshake）：
- 目的：建立连接并同步双方的序列号和确认号，确保通信双方准备好进行数据传输。
- 过程：
  1. 客户端发送一个带有 SYN 标志的数据包给服务器，表示请求建立连接。
  2. 服务器收到后，回应一个带有 SYN 和 ACK 标志的数据包，表示同意连接并确认收到的序列号。
  3. 客户端收到服务器的 SYN-ACK 包后，发送一个带有 ACK 标志的数据包给服务器，表示连接建立成功。
四次挥手（Four-Way Handshake）：
- 目的：安全地终止连接，确保双方都已经完成数据传输。
- 过程：
  1. 客户端发送一个带有 FIN 标志的数据包，表示请求终止连接。
  2. 服务器收到后，回应一个带有 ACK 标志的数据包，确认收到请求。
  3. 服务器发送一个带有 FIN 标志的数据包，表示同意终止连接。
  4. 客户端收到后，回应一个带有 ACK 标志的数据包，确认连接终止。
序列号和确认号（Sequence Number and Acknowledgment Number）：
- 序列号：每个字节的数据都有一个序列号，用于确保数据按照正确的顺序接收。
- 确认号：接收方会发回确认号，告知发送方已收到数据的序列号范围。这样可以确认数据的接收情况。
流量控制（Flow Control）：
- 滑动窗口机制：TCP 使用滑动窗口机制来控制数据的发送速率，防止发送方发送的数据超出接收方的处理能力。
- 窗口大小：接收方会通知发送方当前可以接收的数据量（窗口大小），发送方根据这个值调整发送速率。
拥塞控制（Congestion Control）：
- 慢启动（Slow Start）：初始阶段，发送方以较慢的速度发送数据，然后逐步增加发送速率。
- 拥塞避免（Congestion Avoidance）：当发送速率达到一定阈值后，逐步增加发送窗口，以避免拥塞。
- 快速重传和快速恢复（Fast Retransmit and Fast Recovery）：检测到数据丢失后，发送方会快速重传丢失的数据包，并采取措施快速恢复发送速率。
重传机制（Retransmission Mechanism）：
- 超时重传：发送方在发送数据包后启动定时器，如果在规定时间内没有收到确认，重新发送数据包。
- 快速重传：当发送方连续收到三个重复的确认号（ACK）时，立即重传丢失的数据包，不必等待超时。
校验和（Checksum）：
- 数据完整性：每个 TCP 数据包都包含一个校验和，用于检测数据在传输过程中是否发生错误。接收方计算数据的校验和，并与包中的校验和进行比较，如果不匹配，则丢弃该数据包。

小结

TCP 通过上述机制实现可靠的数据传输，确保数据在不可靠的网络环境中能够准确、有序地传输到目标端。具体而言，TCP 的三次握手和四次挥手确保了连接的建立和关闭，序列号和确认号确保了数据的有序传输，流量控制和拥塞控制机制避免了网络拥塞，重传机制确保了数据包丢失时的重传，而校验和则确保了数据的完整性。通过这些机制，TCP 提供了一个可靠的端到端的数据传输服务。

△ 42次 TCP 中常见的拥塞控制算法有哪些？中等

慢启动
拥塞避免
快重传
快恢复

△ 40次 HTTP 与 HTTPS 有哪些区别？中等

HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

△ 38次简述常见的 HTTP 状态码的含义（301，304，401，403）简单

200 ok

请求成功。成功的含义取决于 HTTP 方法：

GET: 资源已被提取并在消息正文中传输。
HEAD: 实体标头位于消息正文中。
PUT or POST: 描述动作结果的资源在消息体中传输。
TRACE: 消息正文包含服务器收到的请求消息。
301 Moved Permanently
请求资源的 URL 已永久更改。在响应中给出了新的 URL。
302
临时重定向
304 Not Modified
这是用于缓存的目的。它告诉客户端响应还没有被修改，因此客户端可以继续使用相同的缓存版本的响应。

400 Bad Request

由于被认为是客户端错误（例如，错误的请求语法、无效的请求消息帧或欺骗性的请求路由），服务器无法或不会处理请求。

401 Unauthorized

虽然 HTTP 标准指定了”unauthorized”，但从语义上来说，这个响应意味着”unauthenticated”。也就是说，客户端必须对自身进行身份验证才能获得请求的响应。

403 Forbidden

客户端没有访问内容的权限；也就是说，它是未经授权的，因此服务器拒绝提供请求的资源。与 401 Unauthorized 不同，服务器知道客户端的身份。

404 Not Found

服务器找不到请求的资源。在浏览器中，这意味着无法识别 URL。在 API 中，这也可能意味着端点有效，但资源本身不存在。服务器也可以发送此响应，而不是 403 Forbidden，以向未经授权的客户端隐藏资源的存在。这个响应代码可能是最广为人知的，因为它经常出现在网络上。

405 Method Not Allowed

服务器知道请求方法，但目标资源不支持该方法。例如，API 可能不允许调用DELETE来删除资源。

500 Internal Server Error

服务器遇到了不知道如何处理的情况。

502 Bad Gateway

此错误响应表明服务器作为网关需要得到一个处理这个请求的响应，但是得到一个错误的响应。

503 Service Unavailable

服务器没有准备好处理请求。常见原因是服务器因维护或重载而停机。请注意，与此响应一起，应发送解释问题的用户友好页面。这个响应应该用于临时条件和如果可能的话，HTTP 标头 Retry-After 字段应该包含恢复服务之前的估计时间。网站管理员还必须注意与此响应一起发送的与缓存相关的标头，因为这些临时条件响应通常不应被缓存。

504 Gateway Timeout

当服务器充当网关且无法及时获得响应时，会给出此错误响应。

△ 38次简述 TCP 三次握手以及四次挥手的流程。为什么需要三次握手以及四次挥手？中等

TCP 的特性

TCP 提供一种面向连接的、可靠的字节流服务
在一个 TCP 连接中，仅有两方进行彼此通信。广播和多播不能用于 TCP
TCP 使用校验和，确认和重传机制来保证可靠传输
TCP 给数据分节进行排序，并使用累积确认保证数据的顺序不变和非重复
TCP 使用滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制

注意：TCP 并不能保证数据一定会被对方接收到，因为这是不可能的。TCP 能够做到的是，如果有可能，就把数据递送到接收方，否则就（通过放弃重传并且中断连接这一手段）通知用户。因此准确说 TCP 也不是 100% 可靠的协议，它所能提供的是数据的可靠递送或故障的可靠通知。
TCP（Transmission Control Protocol，传输控制协议）使用三次握手（Three-Way Handshake）和四次挥手（Four-Way Handshake）来建立和终止连接。每个过程都有其特定的目的，以确保数据传输的可靠性和连接管理的正确性。

三次握手

目的：三次握手的主要目的是确保双方都准备好开始通信，并同步初始序列号。这为可靠的数据传输提供了基础。

第一次握手（SYN）：
- 客户端发送一个带有 SYN（同步）标志的数据包给服务器。这个数据包包含一个初始序列号 seq=x。
- 目的：客户端告诉服务器它想建立连接，并发送一个初始序列号。
第二次握手（SYN-ACK）：
- 服务器收到 SYN 数据包后，回应一个带有 SYN 和 ACK（确认）标志的数据包。这个数据包包含服务器的初始序列号 seq=y，并对客户端的序列号进行确认 ack=x+1。
- 目的：服务器同意建立连接，并确认收到客户端的初始序列号。
第三次握手（ACK）：
- 客户端收到 SYN-ACK 数据包后，发送一个带有 ACK 标志的数据包给服务器，确认收到服务器的初始序列号 ack=y+1。
- 目的：客户端确认连接已经建立，并告知服务器自己也准备好了。

为什么需要三次握手

双向确认：三次握手确保了客户端和服务器双方都知道对方准备好了，并且初始序列号已经同步。这避免了因为过期的 SYN 数据包导致的错误连接。
防止重复连接：在网络延迟或其他原因导致的重复数据包情况下，三次握手能够防止重复连接的产生。

四次挥手

目的：四次挥手的主要目的是确保双方都安全地终止连接，并且所有的数据传输都已经完成。

第一次挥手（FIN）：
- 客户端发送一个带有 FIN（终止）标志的数据包，表示不再发送数据了。这个数据包包含一个序列号 seq=u。
- 目的：客户端告知服务器它已经发送完数据，请求终止连接。
第二次挥手（ACK）：
- 服务器收到 FIN 数据包后，回应一个带有 ACK 标志的数据包，确认收到客户端的终止请求 ack=u+1。
- 目的：服务器确认收到客户端的终止请求，但可能仍有数据要发送。
第三次挥手（FIN）：
- 服务器发送一个带有 FIN 标志的数据包，表示它也准备好终止连接。这个数据包包含一个序列号 seq=v。
- 目的：服务器告知客户端它也已经发送完数据，请求终止连接。
第四次挥手（ACK）：
- 客户端收到 FIN 数据包后，发送一个带有 ACK 标志的数据包，确认收到服务器的终止请求 ack=v+1。
- 目的：客户端确认连接已经终止。

为什么需要四次挥手

双向独立关闭：TCP 连接是全双工的，即双方都可以独立地关闭各自的发送和接收通道。四次挥手确保了每一方向的连接都能安全关闭。
数据完整性：通过四次挥手，确保所有未发送的数据都能被正确接收，防止数据丢失。

总结

三次握手：用于建立连接，确保双方都准备好开始通信，并同步初始序列号。三次握手提供了双向确认，防止重复连接，确保连接的可靠性。
四次挥手：用于安全地终止连接，确保双方都完成数据传输，并独立地关闭各自的连接。四次挥手确保了数据的完整性和连接的正确关闭。

这两个过程共同确保了 TCP 连接的可靠性、数据的完整性和连接管理的正确性。

△ 34次简述 HTTPS 的加密与认证过程中等

SSL 握手

客户端给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
服务端确认双方使用的加密方法，并给出数字证书、一个服务端生成的随机数（Server random）。
客户端确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用证书中的公钥，对其进行加密后发给客户端。
客户端使用自己的私钥，换算出服务端的新随机数（Premaster secret）。
双方根据约定好的加密方法，使用前面三个随机数，生成“对话秘钥”（session key），用来加密接下来的整个对话过程。

△ 34次什么是跨域，什么情况下会发生跨域请求？中等

跨域（Cross-Origin）是指从一个域向另一个域发出请求的行为。浏览器的同源策略（Same-Origin Policy）限制了这种行为，以保护用户的安全和隐私。同源策略规定，只有当请求的源（协议、域名、端口）与当前页面的源相同时，才能共享资源。

什么是同源策略

同源策略是一种安全机制，限制一个源的文档或脚本与来自另一个源的资源进行交互。具体来说，同源策略要求以下三者必须完全相同：

协议（如 http、https）
域名（如 example.com）
端口（如 80、443）

什么是跨域请求

跨域请求是指当前页面向不同源的服务器发出 HTTP 请求。以下情况都会触发跨域请求：

不同的协议（例如，从 https://example.com 请求 http://example.com 的资源）
不同的域名（例如，从 example.com 请求 api.example.com 的资源）
不同的端口（例如，从 example.com:80 请求 example.com:8080 的资源）

常见的跨域请求场景

Ajax 请求：
- 通过 JavaScript 发出的 XMLHttpRequest 或 Fetch 请求，目标服务器与当前页面的源不同。
图片、脚本、样式：
- 在 HTML 中引入的 <img>、<script>、<link> 等标签的 src 或 href 属性指向不同源。
Web 字体：
- 使用 @font-face 在 CSS 中加载不同源的字体文件。
嵌入框架：
- 使用 <iframe> 加载不同源的页面内容。
表单提交：
- HTML 表单的 action 属性指向不同源。
WebSockets：
- 使用 WebSocket 连接到不同源的服务器。

解决跨域问题的方法

浏览器默认会阻止不符合同源策略的跨域请求，但可以通过以下几种方式来解决跨域问题：

JSONP（JSON with Padding）：
- 利用 <script> 标签不受同源策略限制的特点，通过动态插入 <script> 标签来实现跨域请求。JSONP 只能用于 GET 请求。
CORS（跨域资源共享）：
- 服务器在响应头中设置适当的 CORS 头信息，例如 Access-Control-Allow-Origin，来指示浏览器允许跨域请求。CORS 是最常用、最灵活的跨域解决方案。
代理服务器：
- 使用服务器端的代理，将跨域请求发送到自己的服务器，然后由服务器向目标服务器发出请求，并将结果返回给客户端。这种方式可以完全绕过浏览器的同源策略。
跨域资源嵌入：
- 某些标签（如 <script>、<img>、<link>、<iframe> 等）可以直接嵌入跨域资源。这种方式虽然简单，但不适用于需要进行复杂数据交互的情况。

CORS 详细说明

CORS（Cross-Origin Resource Sharing）是目前最常用的跨域解决方案，通过在 HTTP 头中设置适当的 CORS 头信息来实现。以下是一些常见的 CORS 头信息及其含义：

**Access-Control-Allow-Origin**：
- 指定允许哪些域可以访问资源。可以是具体的域名或通配符 *。
**Access-Control-Allow-Methods**：
- 指定允许的 HTTP 方法（如 GET、POST、PUT、DELETE）。
**Access-Control-Allow-Headers**：
- 指定允许的请求头字段。
**Access-Control-Allow-Credentials**：
- 是否允许发送凭据（如 Cookie）。如果设置为 true，Access-Control-Allow-Origin 不能为 *，必须指定具体的域名。
**Access-Control-Expose-Headers**：
- 指定哪些响应头可以被客户端 JavaScript 访问。
**Access-Control-Max-Age**：
- 指定预检请求的结果可以缓存多长时间。

示例：使用 CORS 允许跨域请求

假设有一个服务器的域名为 api.example.com，我们希望允许 www.example.com 访问其资源，可以在 api.example.com 的响应头中设置：

Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Credentials: true

这样，当 www.example.com 发起跨域请求时，浏览器会检查这些 CORS 头信息，确定是否允许跨域请求。如果头信息匹配，则请求成功，否则浏览器会阻止请求。

通过这些方法，可以在确保安全的前提下，实现跨域请求和数据共享。

△ 28次 DNS 查询服务器的基本流程是什么？DNS 劫持是什么？中等参考1 参考2

1
2
3

主机名.次级域名.顶级域名.根域名
# 即
host.sld.tld.root

DNS 查找的 8 个步骤：

用户在 Web 浏览器中键入 “example.com”，查询传输到 Internet 中，并被 DNS 递归解析器接收。
接着，解析器查询 DNS 根域名服务器（.）。
然后，根服务器使用存储其域信息的顶级域（TLD）DNS 服务器（例如 .com 或 .net）的地址响应该解析器。在搜索 example.com 时，我们的请求指向 .com TLD。
然后，解析器向 .com TLD 发出请求。
TLD 服务器随后使用该域的域名服务器 example.com 的 IP 地址进行响应。
最后，递归解析器将查询发送到域的域名服务器。
example.com 的 IP 地址而后从域名服务器返回解析器。
然后 DNS 解析器使用最初请求的域的 IP 地址响应 Web 浏览器。
DNS 查找的这 8 个步骤返回 example.com 的 IP 地址后，浏览器便能发出对该网页的请求：
浏览器向该 IP 地址发出 HTTP 请求。
位于该 IP 的服务器返回将在浏览器中呈现的网页（第 10 步）。

△ 26次 TCP的拥塞控制具体是怎么实现的？UDP有拥塞控制吗？中等

慢启动(Slow start)

拥塞窗口的初始值为1
每收到一个对发出的数据段的ACK确认，便将拥塞窗口的值增加1,cwnd++ (呈线性上升)
每当过了一个RTT(Round Trip Time)，cwnd = cwnd*2; 呈指数让升
阈值ssthresh（slow start threshold），是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法”

拥塞避免(Congestion avoidance)

达到阈值（一般是16）开始加法递增
TCP连接进行初始化的时候，cwnd=1,ssthresh=16
在慢启动算法开始时，cwnd的初始值是1，每次发送方收到一个ACK拥塞窗口就增加1，当ssthresh =cwnd时，就启动拥塞控制算法，拥塞窗口按照规律增长
当cwnd=24时，网络出现超时，发送方收不到确认ACK，此时设置ssthresh=12（二分之一cwnd），设置cwnd=1，然后重新开始慢启动算法，当cwnd=ssthresh=12，慢启动算法变为拥塞控制算法，cwnd按照线性的速度进行增长

快速重传(Fast retransmit)

3次受到重复 ack 报文，立刻重传该报文
把ssthresh设置为cwnd的一半
把cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3*MSS)
重新进入拥塞避免阶段（加法递增）

快速恢复(Fast Recovery)

当收到3个重复ACK时，把ssthresh设置为cwnd的一半，把cwnd设置为ssthresh的值加3，然后重传丢失的报文段，加3的原因是因为收到3个重复的ACK，表明有3个“老”的数据包离开了网络，(cwnd = sshthresh + 3 * MSS (3的意思是确认有3个数据包被收到了))
重传Duplicated ACKs指定的数据包
如果再收到重复的ACK时，拥塞窗口增加1。
当收到新的数据包的ACK时，把cwnd设置为第一步中的ssthresh的值。原因是因为该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。
乘法减半 + 加法递增

选择性应答( selective acknowledgement,SACK)算法

△ 26次 TCP 与 UDP 在网络协议中的哪一层，他们之间有什么区别？

传输层协议

TCP 面向连接（如打电话要先拨号建立连接）提供可靠的服务，UDP 是无连接的，即发送数据之前不需要建立连接，UDP 尽最大努力交付，即不保证可靠交付。
UDP 具有较好的实时性，工作效率比 TCP 高，适用于对高速传输和实时性有较高的通信或广播通信。
每一条 TCP 连接只能是一对一的，UDP 支持一对一，一对多，多对一和多对多的交互通信。
UDP 分组首部开销小，TCP 首部开销 20 字节，UDP 的首部开销小，只有 8 个字节。
TCP 面向字节流，实际上是 TCP 把数据看成一连串无结构的字节流，UDP 是面向报文的一次交付一个完整的报文，报文不可分割，报文是 UDP 数据报处理的最小单位。
UDP 适合一次性传输较小数据的网络应用，如 DNS，SNMP 等。

△ 24次

什么是 TCP 粘包和拆包？简单

△ 24次简述 HTTP 1.0，1.1，2.0 的主要区别简单

HTTP（HyperText Transfer Protocol）是用于在客户端和服务器之间传输超文本的协议。HTTP 协议从 1.0 发展到 2.0，经历了多次改进，主要体现在连接管理、性能和安全性等方面。

HTTP/1.0

发布时间：1996年

特点：

无连接：
- 每个请求/响应对使用单独的 TCP 连接。这意味着每次请求都需要建立和关闭 TCP 连接，导致额外的开销。
请求/响应模型：
- 客户端发送请求，服务器处理后返回响应。
缺少持久连接：
- 每次请求完成后连接就关闭，不能复用连接。
有限的缓存控制：
- 使用 Expires 头部来控制缓存，功能有限。

HTTP/1.1

发布时间：1997年

主要改进：

持久连接：
- 默认使用持久连接（连接复用），通过 Connection: keep-alive 头部保持连接，使得多个请求可以复用同一个 TCP 连接，减少连接建立和关闭的开销。
管道化：
- 支持请求管道化，即在收到前一个请求的响应之前，客户端可以继续发送后续请求，虽然服务器仍然是按顺序处理请求。
分块传输编码：
- 使用 Transfer-Encoding: chunked，允许服务器逐步发送响应数据，而无需事先知道内容的总长度。
缓存控制：
- 增加了更复杂的缓存机制，使用 Cache-Control 头部提供更精确的缓存指令（如 max-age、no-cache、no-store 等）。
范围请求：
- 支持部分内容请求，通过 Range 头部，客户端可以请求资源的特定部分（用于断点续传、视频流等）。
更多的请求/响应头：
- 增加了许多新的请求和响应头（如 Host 头部），使得请求可以包含更多的信息。

HTTP/2.0

发布时间：2015年

主要改进：

二进制分帧：
- HTTP/2 引入了二进制分帧层，所有数据在传输时都被分成更小的二进制帧。这种方式更高效且易于解析，取代了 HTTP/1.1 的纯文本格式。
多路复用：
- 在一个 TCP 连接中允许同时发送多个请求和响应，不再按顺序排队。这解决了 HTTP/1.x 中存在的队头阻塞（Head-of-Line Blocking）问题，大大提升了性能。
头部压缩：
- 使用 HPACK 算法对 HTTP 头部进行压缩，减少传输的数据量，提升性能。
服务器推送：
- 服务器可以主动向客户端推送资源，而无需客户端明确请求。这对于提升页面加载速度非常有利，例如预加载样式表和脚本。
优先级和依赖性：
- 客户端可以指定请求的优先级和依赖关系，服务器可以根据优先级来决定响应的顺序和速度。

对比总结

HTTP/1.0 vs HTTP/1.1：
- HTTP/1.0 使用无连接的请求/响应模型，每个请求都需要新的连接，缺少持久连接和先进的缓存机制。
- HTTP/1.1 引入了持久连接、管道化、分块传输编码、更复杂的缓存控制、范围请求等，提升了效率和灵活性。
HTTP/1.1 vs HTTP/2.0：
- HTTP/1.1 使用纯文本格式，尽管支持持久连接和管道化，但仍存在队头阻塞的问题，性能受限。
- HTTP/2.0 引入二进制分帧、多路复用、头部压缩、服务器推送等，显著提升了传输效率和性能，解决了 HTTP/1.x 的一些固有问题。

总体来说，HTTP 从 1.0 到 2.0 的发展，主要是为了提高传输效率、降低延迟、减少开销以及提升安全性。HTTP/2.0 尤其通过多路复用和头部压缩，显著提高了网络性能，改善了用户体验。

△ 22次简述对称与非对称加密的概念简单

对称加密和非对称加密是两种主要的加密技术，分别用于保护数据的安全性。它们在密钥管理和使用上存在显著差异。

对称加密

概念：
对称加密（Symmetric Encryption）使用相同的密钥进行数据的加密和解密。也就是说，加密和解密使用的是同一个密钥。

特点：

单一密钥：
- 加密和解密使用同一个密钥，必须确保密钥的保密性。
速度快：
- 对称加密算法相对简单，处理速度快，适合对大量数据进行加密。
密钥分发问题：
- 密钥需要在通信双方之间安全传输，确保不被第三方截获。

常见算法：

DES（Data Encryption Standard）
3DES（Triple DES）
AES（Advanced Encryption Standard）
RC4
Blowfish

应用场景：

数据库加密
文件加密
网络通信中的数据加密（如 TLS 会话中的对称加密部分）

非对称加密

概念：
非对称加密（Asymmetric Encryption）使用一对密钥进行加密和解密：公钥（public key）和私钥（private key）。公钥用于加密数据，私钥用于解密数据。

特点：

密钥对：
- 由一对密钥组成，公钥公开分发，私钥保密。
加密解密过程：
- 公钥加密的数据只能由对应的私钥解密，私钥加密的数据只能由对应的公钥解密。
速度较慢：
- 非对称加密算法相对复杂，处理速度较慢，不适合对大量数据进行加密。
无需共享私钥：
- 公钥可以公开分发，无需安全传输私钥，解决了对称加密中的密钥分发问题。

常见算法：

RSA
ECC（Elliptic Curve Cryptography）
DSA（Digital Signature Algorithm）

应用场景：

数字签名
数字证书
安全电子邮件（如 PGP）
密钥交换（如 TLS 中的密钥协商）

对比总结

密钥管理：
- 对称加密使用单一密钥，需要安全传输和存储。
- 非对称加密使用公钥和私钥对，公钥公开，私钥保密，简化了密钥分发。
速度：
- 对称加密速度快，适合加密大数据量。
- 非对称加密速度慢，适合加密小数据量和密钥交换。
安全性：
- 对称加密的安全性依赖于密钥的保密性。
- 非对称加密通过私钥的保密和数学难题（如大整数分解）确保安全。

结合使用

在实际应用中，对称加密和非对称加密常常结合使用。非对称加密用于安全地交换对称加密密钥，而对称加密用于加密实际的数据内容。这样既能确保密钥的安全传输，又能利用对称加密的高效性。一个典型的例子是 HTTPS 协议，其中使用非对称加密进行密钥交换，然后使用对称加密保护数据传输。

△ 22次

简述 OSI 七层模型，TCP，IP 属于哪一层？简单参考1

△ 20次 HTTP 的方法有哪些？简单

Get
Post
Head
Delete
Patch等

△ 18次

简述 TCP 滑动窗口以及重传机制简单参考1

△ 16次

简述 JWT 的原理和校验机制中等

△ 16次

Cookie 和 Session 的关系和区别是什么？简单

△ 16次简述 RPC 的调用过程简单

客户端调用
序列化
发送请求
服务端接收请求
反序列化
执行调用逻辑
序列化响应
客户端接收响应
反序列化响应
返回结果

△ 15次

TCP 挥手时出现大量 CLOSE_WAIT 或 TIME_WAIT 怎么解决？简单参考1 参考2

△ 14次

为什么需要序列化？有什么序列化的方式？中等

△ 12次 HTTP 中 GET 和 POST 区别简单

HTTP 协议中的 GET 和 POST 是最常见的两种请求方法，它们在使用场景、参数传递、安全性等方面有显著区别。

对比总结

传递方式：
- GET：参数在 URL 中传递，适合少量数据。
- POST：参数在请求体中传递，适合大量数据和文件上传。
安全性：
- GET：参数暴露在 URL 中，不适合传递敏感信息。
- POST：参数在请求体中，稍微安全，但仍需 HTTPS。
幂等性：
- GET：幂等，多次请求不会改变服务器状态。
- POST：非幂等，多次请求可能会改变服务器状态。
缓存：
- GET：响应可以被缓存。
- POST：响应通常不被缓存。
长度限制：
- GET：受 URL 长度限制，适合少量参数。
- POST：无明显长度限制，适合大量参数和数据。

选择使用

GET：
- 用于获取资源或数据，不会改变服务器状态的请求。
- 数据量小，参数无需隐藏。
POST：
- 用于提交数据、上传文件或任何会改变服务器状态的请求。
- 数据量大，参数包含敏感信息或需要隐藏。

△ 12次

什么是中间人攻击？如何防止攻击？中等

△ 2次

简述 iPv4 和 iPv6 的区别简单

△ 46次 从输入 URL 到展现页面的全过程 困难

1. 输入 URL

2. URL 解析

3. 检查缓存

4. DNS 解析

5. 建立 TCP 连接

6. 发送 HTTP 请求

7. 服务器处理请求

8. 发送 HTTP 响应

9. 浏览器接收响应

10. 页面渲染

11. 持续加载和交互

过程中的优化

△ 42次 TCP 怎么保证可靠传输？ 中等

小结

△ 42次 TCP 中常见的拥塞控制算法有哪些？ 中等

△ 40次 HTTP 与 HTTPS 有哪些区别？ 中等

△ 38次 简述常见的 HTTP 状态码的含义（301，304，401，403） 简单

200 ok

301 Moved Permanently

302

304 Not Modified

400 Bad Request

401 Unauthorized

403 Forbidden

404 Not Found

405 Method Not Allowed

500 Internal Server Error

502 Bad Gateway

503 Service Unavailable

504 Gateway Timeout

△ 38次 简述 TCP 三次握手以及四次挥手的流程。为什么需要三次握手以及四次挥手？ 中等

TCP 的特性

三次握手

为什么需要三次握手

四次挥手

为什么需要四次挥手

总结

△ 34次 简述 HTTPS 的加密与认证过程 中等

SSL 握手

△ 34次 什么是跨域，什么情况下会发生跨域请求？ 中等

什么是同源策略

什么是跨域请求

常见的跨域请求场景

解决跨域问题的方法

CORS 详细说明

示例：使用 CORS 允许跨域请求

△ 28次 DNS 查询服务器的基本流程是什么？DNS 劫持是什么？ 中等 参考1 参考2

DNS 查找的 8 个步骤：

DNS 查找的这 8 个步骤返回 example.com 的 IP 地址后，浏览器便能发出对该网页的请求：

△ 26次 TCP的拥塞控制具体是怎么实现的？UDP有拥塞控制吗？ 中等

慢启动(Slow start)

拥塞避免(Congestion avoidance)

快速重传(Fast retransmit)

快速恢复(Fast Recovery)

选择性应答( selective acknowledgement,SACK)算法

△ 26次 TCP 与 UDP 在网络协议中的哪一层，他们之间有什么区别？

△ 24次 简述 HTTP 1.0，1.1，2.0 的主要区别 简单

HTTP/1.0

特点：

HTTP/1.1

主要改进：

HTTP/2.0

主要改进：

对比总结

△ 22次 简述对称与非对称加密的概念 简单

对称加密

非对称加密

对比总结

结合使用

△ 20次 HTTP 的方法有哪些？ 简单

△ 16次 简述 RPC 的调用过程 简单

△ 12次 HTTP 中 GET 和 POST 区别 简单

对比总结

选择使用

△ 46次从输入 URL 到展现页面的全过程困难

△ 42次 TCP 怎么保证可靠传输？中等

△ 42次 TCP 中常见的拥塞控制算法有哪些？中等

△ 40次 HTTP 与 HTTPS 有哪些区别？中等

△ 38次简述常见的 HTTP 状态码的含义（301，304，401，403）简单

△ 38次简述 TCP 三次握手以及四次挥手的流程。为什么需要三次握手以及四次挥手？中等

△ 34次简述 HTTPS 的加密与认证过程中等

△ 34次什么是跨域，什么情况下会发生跨域请求？中等

△ 28次 DNS 查询服务器的基本流程是什么？DNS 劫持是什么？中等参考1 参考2

△ 26次 TCP的拥塞控制具体是怎么实现的？UDP有拥塞控制吗？中等

△ 24次简述 HTTP 1.0，1.1，2.0 的主要区别简单

△ 22次简述对称与非对称加密的概念简单

△ 20次 HTTP 的方法有哪些？简单

△ 16次简述 RPC 的调用过程简单

△ 12次 HTTP 中 GET 和 POST 区别简单