HTTP、HTTPS 与 DNS 校招面试题｜计算机网络应用层

厨子2026/10/5大约 82 分钟计算机基础计算机网络计算机校招计算机网络面试题HTTPHTTPSDNSCookie 与 Session

HTTP、HTTPS 与 DNS 校招面试题｜计算机网络应用层

本章适合计算机专业学生、应届生和 Java 后端校招求职者，围绕 HTTP、HTTPS、TLS、DNS、Cookie 与 Session，系统梳理应用层协议的核心原理和高频面试问题。

HTTP

1. 请说一下 HTTP 的状态码？

面试题剖析

这道题既考察状态码分类，也考察遇到错误时能否判断发生在哪一环。回答时先说五类含义，再讲高频状态码及场景，尤其注意缓存、重定向、认证授权和网关错误的区别。

面试题解答

HTTP 状态码是响应中的三位数字，表示服务器对请求的处理结果。第一位定义所属类别。

成功类与信息类

100 Continue 表示可继续发送请求内容；101 Switching Protocols 用于 HTTP/1.1 的协议切换；103 Early Hints 可提前发送资源提示。200 OK 表示成功，201 Created 表示创建资源，202 Accepted 只表示已接受处理，不能当作业务完成。204 No Content 不携带响应内容，206 Partial Content 用于成功的范围请求。

重定向与缓存

例如提交表单后返回 303，再 GET 结果页，可以避免刷新结果页时重发原 POST。强缓存命中通常无需请求服务器，304 则意味着发生过缓存验证请求。方法与状态码语义见 RFC 9110。

高频客户端错误

400：请求格式或参数等存在问题。
401：缺少有效认证凭据，通常通过 WWW-Authenticate 提供认证挑战。
403：服务器理解请求但拒绝执行；有凭据也可能无权访问。
404：找不到资源，或服务器不愿暴露资源存在。
405：资源不支持该方法，应通过 Allow 告知支持的方法。
409：与当前资源状态冲突，例如版本或业务状态冲突。
413：请求内容过大；415：媒体类型不受支持。
429：请求过多，客户端应按服务端策略退避重试。

高频服务端错误

500 是服务端内部错误；502 是网关从上游收到无效响应；503 表示服务暂时不可用，例如过载或维护；504 是网关等待上游响应超时。

状态码不等于完整业务结果。接口即使返回 200，也可能在 JSON 中带业务错误；接口设计应尽量让 HTTP 状态与真实语义一致。反过来，客户端超时也不代表服务器没有完成写操作，重试前仍需考虑幂等性。

面试时可以总结为：先用首位判断结果类别，再结合方法和上下文理解具体状态。重点区分 200 与 202、强缓存与 304、认证 401 与拒绝访问 403，以及网关的 502、503、504。

可能追问的问题

301、302 与 307、308 对 POST 重定向有什么区别？
强缓存命中和返回 304 有什么区别？
401 和 403 分别适合什么场景？
502、503、504 应分别排查什么？
HTTP 返回 200 就能说明订单已经创建成功吗？

2. 请说下转发和重定向的区别？

面试题剖析

考察候选人对 Web 请求处理机制的理解，是否掌握转发和重定向在执行主体、请求次数、浏览器地址栏、数据共享、访问范围及性能等方面的区别，并能结合实际业务场景正确选择。

转发和重定向都是 Web 开发中实现页面跳转的方式，但它们的执行过程不同。

面试题解答

转发（Forward）

转发发生在服务器内部。当客户端发送请求后，服务器将该请求转交给另一个资源继续处理，客户端并不知道服务器内部发生了转发。

在 Java Web 中通常使用：

request.getRequestDispatcher("/target.jsp").forward(request, response);

转发具有以下特点：

整个过程只有一次请求和一次响应。
浏览器地址栏中的 URL 不会改变。
转发前后的资源可以共享同一个 request 对象，因此能够通过 request 传递数据。
只能转发到当前服务器或当前 Web 应用中的资源，不能直接转发到其他网站。
转发由服务器内部完成，网络请求次数较少，效率通常更高。
可以访问 WEB-INF 目录下不能被浏览器直接访问的资源。

例如，用户请求登录接口，服务器验证成功后，将请求转发到用户首页。虽然服务器实际返回了首页内容，但浏览器地址栏仍然显示原来的登录地址。

重定向（Redirect）

重定向是服务器通知客户端重新访问另一个地址。服务器第一次响应时会返回重定向状态码和新的地址，浏览器收到后，再向新地址发送一次请求。

在 Java Web 中通常使用：

response.sendRedirect("/target");

重定向具有以下特点：

整个过程至少包含两次请求和两次响应。
浏览器地址栏会变成重定向后的地址。
两次请求使用不同的 request 对象，因此不能直接通过 request 属性共享数据，可以使用 URL 参数、Cookie 或 Session 传递数据。
既可以重定向到当前应用中的资源，也可以重定向到其他网站。
因为浏览器需要重新发送请求，所以开销通常比转发大。
不能直接访问 WEB-INF 目录下的资源。

例如，用户提交订单成功后，服务器可以将浏览器重定向到订单详情页。此时浏览器地址栏会显示订单详情页的地址，用户刷新页面时也不会再次提交原来的订单请求。这种方式也称为 PRG，即“提交—重定向—查询”模式；通常使用 303 明确要求后续 GET，不能用保留 POST 的 307/308 来达成同样目的。

两者的核心区别

转发是服务器内部将同一个请求交给另一个资源处理，浏览器地址不变，并且可以共享 request 数据；重定向是服务器让浏览器重新请求一个地址，地址栏会改变，前后属于两个不同的请求，还可以跳转到其他网站。

面试时可以总结为：转发由服务器内部继续处理同一个请求，浏览器地址通常不变；重定向通过状态码和 Location 让客户端发起新请求，地址会变化。是否保留请求方法取决于重定向状态码，不能笼统认为重定向都会变成 GET。

可能追问的问题

转发和重定向过程中，浏览器分别会发送几次 HTTP 请求？地址栏会发生什么变化？
转发和重定向时，原请求中的参数及 request、session 数据是否还能使用？
哪些业务场景适合使用转发，哪些适合使用重定向？为什么提交表单后通常采用重定向？

3. 请说一下 HTTP 长连接和短连接

面试题剖析

这道题主要考察候选人对 HTTP 底层连接复用机制的理解，包括长连接与短连接的工作过程、性能差异、适用场景，以及不同 HTTP 版本对连接的管理方式。

回答时需要注意：HTTP 长连接和短连接本质上讨论的是底层 TCP 连接是否被复用，而不是 HTTP 协议本身建立了一条连接。

面试题解答

HTTP 短连接和长连接的主要区别是：一次 HTTP 请求完成后，底层 TCP 连接是立即关闭，还是继续保留给后续 HTTP 请求复用。

HTTP 短连接

短连接是指客户端与服务器建立 TCP 连接后，通常完成一次 HTTP 请求和响应，随后便关闭 TCP 连接。下一次发送 HTTP 请求时，需要重新建立新的 TCP 连接。

其过程可以简单表示为：

建立 TCP 连接 → 发送 HTTP 请求 → 返回 HTTP 响应 → 关闭 TCP 连接

短连接具有以下特点：

每次通信都需要重新建立和关闭 TCP 连接。
TCP 三次握手和四次挥手会产生额外的时间与网络开销。
如果使用 HTTPS，通常还需要重新进行 TLS 握手，开销会更加明显。
请求完成后及时释放连接，连接管理相对简单。
在请求频率较低、请求之间间隔较长的场景下，可以减少空闲连接对服务器资源的占用。

HTTP/1.0 默认使用短连接。服务器返回响应后通常会关闭 TCP 连接，也可以通过 Connection: keep-alive 请求复用连接，但这并不是 HTTP/1.0 的默认行为。

HTTP 长连接

长连接也称为持久连接，是指一次 HTTP 请求和响应完成后不立即关闭底层 TCP 连接，而是保留该连接，使后续 HTTP 请求能够继续使用。

其过程可以简单表示为：

建立 TCP 连接 → 第一次 HTTP 请求和响应 → 第二次 HTTP 请求和响应 → 更多 HTTP 请求和响应 → 超时或主动关闭连接

长连接具有以下特点：

多个 HTTP 请求可以复用同一条 TCP 连接。
减少了反复进行 TCP 握手和挥手的开销。
HTTPS 场景下还可以减少重复进行 TLS 握手的开销。
能够降低请求延迟，提高网络传输效率。
服务器需要维护一定数量的连接，会占用文件描述符、内存等资源。
长连接并不表示连接永远不会关闭。当连接空闲时间超过客户端、服务器或代理设置的超时时间时，仍然会被关闭。

HTTP/1.1 默认使用长连接。如果希望服务器在响应完成后关闭连接，可以在请求或响应中设置：

Connection: close

在 HTTP/1.1 中，虽然多个请求可以复用同一条 TCP 连接，但通常仍然需要按照一定顺序处理。HTTP/2 在长连接的基础上增加了多路复用能力，允许多个请求和响应在同一条连接上并发传输，进一步提高了连接利用率。

两者的核心区别

例如，浏览器打开一个网页时，通常需要请求 HTML、CSS、JavaScript 和图片等多个资源。如果使用短连接，每个资源都重新建立 TCP 连接，会产生大量握手开销；使用长连接后，这些请求可以复用已有连接，从而提高页面加载速度。

面试时可以总结为：

HTTP 短连接是每次通信结束后关闭底层 TCP 连接，后续请求需要重新建立连接；HTTP 长连接是在请求完成后保留 TCP 连接，使多个 HTTP 请求能够复用同一条连接。长连接可以减少 TCP 和 TLS 握手开销、降低请求延迟，但服务器需要消耗一定资源维护连接。HTTP/1.0 默认使用短连接，HTTP/1.1 默认使用长连接，而 HTTP/2 还支持在一个连接上进行多路复用。

可能追问的问题

HTTP 长连接是永久不关闭的吗？通常会在什么情况下关闭？
HTTP/1.0 和 HTTP/1.1 在连接管理方面有什么区别？
HTTP 长连接、HTTP 长轮询和 WebSocket 有什么区别？
HTTP/1.1 长连接为什么仍然可能出现队头阻塞？
HTTP/2 多路复用是如何提高连接利用率的？

4. GET 和 POST 请求方式有什么不同？

面试题剖析

这道题主要考察候选人对 HTTP 请求方法语义的理解，包括 GET 和 POST 在用途、参数传递、幂等性、缓存、数据长度及安全性等方面的区别。

回答时不能简单地认为 GET 只能通过 URL 传参、POST 只能通过请求体传参，也不能认为 POST 天然比 GET 安全。两者最本质的区别是 HTTP 协议定义的请求语义不同。

面试题解答

GET 和 POST 都是 HTTP 请求方法。

GET 主要用于获取资源，通常不应该修改服务器中的数据；POST 主要用于向服务器提交数据，让服务器对数据进行处理，例如创建订单、提交表单或上传文件。

GET 请求

GET 请求通常将参数放在 URL 的查询字符串中，例如：

GET /users?id=1001&name=tom HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive

GET 请求具有以下特点：

主要用于从服务器查询或获取资源。
参数通常拼接在 URL 后面，因此可以在浏览器地址栏中直接看到。
URL 可以被收藏、复制和分享。
请求结果可以根据 HTTP 缓存规则被浏览器或代理服务器缓存。
GET 在 HTTP 语义上是安全且幂等的。
URL 长度可能受到浏览器、服务器或代理的限制，但 HTTP 协议本身没有统一规定具体的长度上限。

“安全”表示该请求原则上只读取数据，不应该修改服务器状态；“幂等”表示对同一资源执行一次或多次相同请求，产生的预期效果应该相同。

例如，多次查询同一个用户信息，不应该因为查询次数增加而改变用户数据：

GET /users/1001

POST 请求

POST 请求通常将提交的数据放在请求体中，例如：

POST /users HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 33
User-Agent: Mozilla/5.0
Accept: */*
Connection: keep-alive

{"id":1001,"name":"tom","age":22}

POST 请求具有以下特点：

主要用于向服务器提交数据或触发数据处理。
数据通常放在请求体中，不会直接显示在浏览器地址栏里。
请求体可以使用 JSON、表单、XML、二进制等多种数据格式。
POST 请求默认不会像普通 GET 请求一样被广泛缓存。
POST 在 HTTP 语义上通常不是幂等的。
POST 更适合传输数据量较大的内容或上传文件，但实际大小仍然可能受到服务器配置的限制。
浏览器刷新 POST 请求页面时，可能提示用户是否重新提交表单。

例如，使用 POST 创建订单时，如果连续发送两次相同的请求，服务器可能创建两个订单，因此 POST 默认不具备幂等性：

POST /orders

需要注意，POST 并不一定不能实现幂等。实际业务中可以使用幂等键、唯一业务编号或数据库唯一约束，避免重复提交产生多条数据。

GET 和 POST 的核心区别

关于安全性的常见误区

POST 并不天然比 GET 安全。

GET 参数通常出现在 URL 中，可能被保存在浏览器历史记录、服务器访问日志或代理日志中，因此不适合在 URL 中传递密码等敏感信息。POST 数据虽然放在请求体中，但如果使用的是 HTTP 明文传输，数据仍然可能被窃听。

真正保护传输数据安全的是 HTTPS。即使使用 HTTPS，密码、令牌等敏感信息也不应该随意放在 URL 中，因为 URL 仍可能被应用日志或浏览器历史记录保存。

关于参数位置的说明

GET 参数通常放在 URL 中，POST 数据通常放在请求体中，但这并不是绝对限制：

POST 请求也可以在 URL 中携带查询参数。
GET 请求体在 HTTP 中没有通用且明确的业务语义，很多客户端、服务器和代理并不支持，因此实际开发中不应该依赖 GET 请求体传递数据。

面试时可以总结为

GET 主要用于获取资源，参数通常放在 URL 中，具有安全、幂等和可缓存的语义；POST 主要用于提交数据，数据通常放在请求体中，默认不具备幂等性，也通常不会被缓存。GET 的数据更容易出现在地址栏和日志中，但 POST 并不天然安全，两者都应该通过 HTTPS 保护敏感数据。

可能追问的问题

HTTP 中的安全和幂等分别是什么意思？
POST 请求一定不是幂等的吗？如何保证 POST 请求的幂等性？
GET 请求是否可以携带请求体？POST 请求是否可以在 URL 中传参？
GET 请求的长度是否有限制？限制来自哪里？
为什么不能使用 GET 请求传递密码等敏感信息？

5. GET 有没有 Request Body 呢？

面试题剖析

这道题主要考察候选人能否区分“HTTP 报文格式是否允许 GET 携带请求体”和“GET 请求体是否具有标准语义”。

面试时不能简单回答“GET 没有 Request Body”，更准确的说法是：GET 请求在报文格式上可以携带 Request Body，但 HTTP 规范没有为它定义通用语义，实际开发中也不应该依赖 GET 请求体传递参数。

面试题解答

GET 请求在 HTTP 报文格式上可以携带 Request Body，例如：

GET /users/search HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 19

{"name":"zhangsan"}

HTTP 的消息结构并没有根据请求方法禁止请求体，因此某些客户端确实可以构造出带有 Request Body 的 GET 请求，部分服务器和 Web 框架也可能接收到并解析这些数据。

但是，RFC 9110 明确说明，GET 请求中的内容没有被定义通用语义。客户端不应该发送带有内容的 GET 请求，除非客户端已经确认目标服务器明确支持这种用法。

在实际开发中，不推荐使用 GET Request Body，主要有以下原因：

浏览器、服务器、网关和代理对它的支持并不一致。
某些服务器可能直接忽略或拒绝 GET 请求体。
浏览器的 fetch() API 不允许 GET 和 HEAD 请求携带 Body，否则会抛出 TypeError，这是 Fetch Standard 明确规定的行为。
缓存系统通常根据请求方法和 URL 识别资源，不会将 GET 请求体作为缓存键的一部分，可能导致不同请求命中同一份缓存。
某些中间组件对 GET 请求体的解析方式不一致，可能造成兼容性问题，甚至带来 HTTP 请求走私风险。

因此，GET 请求的查询条件通常应该放在 URL 的查询字符串中：

GET /users/search?name=zhangsan&age=20 HTTP/1.1

如果查询条件非常复杂、数据量较大或需要传递结构化 JSON，可以根据接口设计改用 POST：

POST /users/search HTTP/1.1
Content-Type: application/json

{"name":"zhangsan","age":20}

需要注意，使用 POST 实现复杂查询并不代表这个操作一定会修改数据。请求方法的选择既要考虑 HTTP 语义，也要考虑参数复杂度和各类客户端、中间件的兼容性。

面试时可以总结为：

GET 在 HTTP 报文格式上可以携带 Request Body，但 HTTP 规范没有为 GET 请求体定义通用语义，不同客户端、服务器和代理对它的支持也不一致。浏览器的 fetch() API 甚至会直接禁止这种用法。因此，实际开发中不应该依赖 GET 请求体传参，简单查询参数应放在 URL 中，复杂查询可以根据接口设计改用 POST。

可能追问的问题

GET 请求的查询参数和 Request Body 有什么区别？
为什么浏览器的 fetch() 不允许 GET 请求携带 Body？
复杂查询应该使用 GET 还是 POST？
GET 携带 Request Body 可能对缓存产生什么影响？
POST 用于查询数据时是否仍然可以设计成幂等操作？

6. GET 和 POST 请求发送的数据包有什么不同？

面试题剖析

这道题主要考察候选人是否理解 HTTP 请求报文的结构，以及 GET 和 POST 在请求行、请求头和请求体中的区别。

需要注意，在 HTTP/1.1 和 HTTP/2 的 TCP 承载场景中，“GET 数据包”和“POST 数据包”使用相同的 TCP/IP 封装；HTTP/3 则通过 QUIC/UDP 承载。两者的主要区别发生在 HTTP 请求报文内部。

面试题解答

一个 HTTP/1.1 请求报文通常由以下三部分组成：

请求行：第一行，包含请求方法、请求 URL、HTTP 版本

示例：POST /users HTTP/1.1

请求头（Header）：多行键值对，存放元信息（Host、Content-Type、User-Agent 等）
请求体（Body）：请求头后面，空行隔开，存放 POST 等方法提交的数据；GET 请求一般没有请求体。

请求行 → 请求头 →（空行）→ 请求体

POST /users HTTP/1.1                     ← 请求行
Host: example.com                        ← 请求头
Content-Type: application/json           ← 请求头
Content-Length: 33                       ← 请求头
← 必须的空行
{"id":1001,"name":"tom","age":22}        ← 请求体

以下以 HTTP/1.1 文本报文为例，说明参数通常存放的位置；HTTP/2、HTTP/3 不使用同样的文本请求行格式。

GET 请求报文

GET 请求通常将数据放在 URL 的查询字符串中，因此参数会出现在请求行里：

GET /users?id=1001&name=tom HTTP/1.1
Host: example.com
Accept: application/json

该请求可以拆分为：

请求方法：GET
请求路径：/users
查询参数：id=1001&name=tom
HTTP 版本：HTTP/1.1
请求体：通常为空

GET 请求的数据结构可以简单表示为：

请求行 → 请求头 →（空行）→ 请求体

POST 请求报文

POST 请求通常将数据放在 Request Body 中，请求行一般只包含资源路径：

POST /users HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 24

{"id":1001,"name":"tom"}

该请求可以拆分为：

请求方法：POST
请求路径：/users
请求头：描述请求体的类型和长度
请求体：{"id":1001,"name":"tom"}

POST 请求的数据结构可以简单表示为：

请求行 → 请求头 → 空行 → 请求体

POST 请求通常会通过以下请求头描述 Request Body：

Content-Type：表示请求体的数据格式。
Content-Length：表示请求体的字节长度。

常见的 Content-Type 包括：

两种请求报文的核心区别

需要注意的两个问题

第一，参数位置并不是由请求方法绝对限制的。POST 请求也可以在 URL 中携带查询参数：

POST /users?source=admin HTTP/1.1

GET 在报文格式上也可以携带 Request Body，但其请求体没有标准的通用语义，很多浏览器、服务器和代理不支持，因此实际开发中不应该依赖 GET Request Body 传递数据。

第二，GET 和 POST 与底层数据包数量没有固定关系。在 HTTP/1.1 和 HTTP/2 场景中，HTTP 数据会交给 TCP，TCP 再根据 MSS、拥塞窗口等因素将数据拆分成一个或多个 TCP 报文段。因此，不能认为 GET 一定只有一个数据包，也不能认为 POST 一定会被拆分成多个数据包。

如果使用 HTTPS，HTTP 请求行、请求头以及请求体都会经过 TLS 加密。通过网络抓包通常只能看到加密后的 TLS 数据，不能直接看到 GET 的查询参数或 POST 的请求体。

面试时可以总结为：

GET 和 POST 在 TCP/IP 层发送的数据包结构没有本质区别，都会经过 TCP 和 IP 层封装。它们的区别主要体现在 HTTP 请求报文中：GET 通常把参数放在 URL 查询字符串中，请求体一般为空；POST 通常把数据放在 Request Body 中，并使用 Content-Type 和 Content-Length 等请求头描述数据。最终产生多少个 TCP 报文段，取决于数据大小和 TCP 的分段机制，与请求方法没有固定关系。

可能追问的问题

一个完整的 HTTP 请求报文由哪些部分组成？
GET 请求能否携带 Request Body？POST 请求能否在 URL 中传参？
Content-Type 和 Content-Length 分别有什么作用？
一个 HTTP 请求为什么可能被拆分成多个 TCP 报文段？
使用 HTTPS 后，GET 参数和 POST 请求体是否都会被加密？

7. 请说一下 HTTP 1.1 的特点

面试题剖析

这道题主要考察候选人是否理解 HTTP/1.1 相比 HTTP/1.0 进行的改进，包括持久连接、Host 请求头、管线化、分块传输、缓存机制和范围请求等。

除了介绍这些特点，还应说明 HTTP/1.1 存在的队头阻塞问题，这也是后来 HTTP/2 引入多路复用的重要原因。

面试题解答

HTTP/1.1 是一种基于请求和响应模型的应用层协议，通常使用 TCP 提供可靠传输。它保留了 HTTP 协议无状态、文本报文等特点，并在 HTTP/1.0 的基础上重点改进了连接复用、传输效率、缓存和资源访问能力。

1. 默认使用持久连接

HTTP/1.0 默认使用短连接，每完成一次请求和响应，通常就会关闭 TCP 连接。HTTP/1.1 默认使用持久连接，也就是长连接，允许多个 HTTP 请求复用同一条 TCP 连接。

建立 TCP 连接 → 请求资源 A → 返回资源 A → 请求资源 B → 返回资源 B → 关闭连接

持久连接减少了反复进行 TCP 三次握手和四次挥手的开销。如果使用 HTTPS，还可以减少重复进行 TLS 握手的开销，从而降低请求延迟。

HTTP/1.1 不需要显式设置 Connection: keep-alive 即可使用持久连接。如果客户端或服务器不希望继续复用连接，可以设置：

Connection: close

长连接并不表示连接永久不会关闭。当连接空闲时间超过客户端、服务器或代理设置的超时时间时，连接仍然会被关闭。RFC 9112 将持久连接规定为 HTTP/1.1 的默认行为。

2. 必须携带 Host 请求头

HTTP/1.1 请求必须包含 Host 请求头，用于表示客户端希望访问的目标主机和端口：

GET /index.html HTTP/1.1

Host: www.example.com

引入 Host 请求头后，一台服务器可以使用同一个 IP 地址和端口部署多个网站。服务器收到请求后，可以根据 Host 将请求交给不同的网站处理，这种机制称为虚拟主机。

如果 HTTP/1.1 请求没有 Host 请求头、携带多个 Host 请求头或者 Host 格式错误，服务器应返回 400 Bad Request。

3. 支持管线化请求

HTTP/1.1 支持管线化，也就是客户端不必等待前一个请求的响应，就可以继续发送后续请求：

发送请求 A → 发送请求 B → 发送请求 C → 接收响应 A → 接收响应 B → 接收响应 C

但是，服务器必须按照请求到达的顺序返回响应。如果请求 A 的处理时间很长，即使请求 B 和请求 C 已经处理完成，也需要等待响应 A 返回，这就是 HTTP/1.1 的应用层队头阻塞问题。

由于兼容性和队头阻塞等问题，HTTP/1.1 管线化在实际环境中使用得并不广泛。浏览器通常会为同一个域名建立多条 TCP 连接来提高并发能力，但这种方式仍然会增加连接开销。

需要注意，HTTP/1.1 管线化不等于 HTTP/2 多路复用。管线化要求响应按顺序返回，而 HTTP/2 可以让多个请求和响应在同一条连接中交错传输。

4. 支持分块传输

当服务器无法提前确定响应体的完整长度时，可以使用分块传输编码，将数据分成多个数据块逐步发送：

Transfer-Encoding: chunked

分块传输的过程可以表示为：

生成一部分数据 → 发送一个数据块 → 继续生成数据 → 发送下一个数据块 → 发送结束标记

每个数据块前面会标明该块的大小，最后通过长度为 0 的数据块表示传输结束。

分块传输适用于动态页面、流式响应等无法提前计算 Content-Length 的场景。接收方可以据此判断消息边界，同时继续复用当前连接。RFC 9112 对分块传输编码进行了具体定义。

5. 完善了缓存和条件请求机制

HTTP/1.1 提供了更加完善的缓存控制能力，常见字段包括：

Cache-Control：控制资源是否缓存以及缓存多长时间。
ETag：表示资源当前版本。
Last-Modified：表示资源最后修改时间。
If-None-Match：根据 ETag 判断资源是否发生变化。
If-Modified-Since：根据修改时间判断资源是否发生变化。

以 ETag 为例，缓存验证过程如下：

首次请求资源 → 服务器返回资源和 ETag → 再次请求携带 If-None-Match → 服务器验证资源是否变化

如果资源没有发生变化，服务器可以返回 304 Not Modified，不再传输完整响应体，从而减少网络流量。

6. 支持范围请求

HTTP/1.1 支持通过 Range 请求头获取资源的某一部分：

Range: bytes=0-1023

如果服务器支持范围请求，可以返回 206 Partial Content，只发送指定范围的数据。

范围请求常用于：

文件断点续传。
视频拖动和分段加载。
大文件分块下载。
下载失败后从指定位置继续传输。

7. HTTP 本身是无状态的

HTTP/1.1 的每个请求在语义上都是相互独立的，服务器不会仅仅因为两个请求使用同一条 TCP 连接，就认为它们来自同一个用户。

如果应用需要维护登录状态或会话状态，通常需要使用 Cookie、Session 或 Token 等机制。需要注意，无状态是 HTTP 协议的特点，而长连接只是对底层连接的复用，两者并不冲突。

HTTP/1.1 的主要局限

HTTP/1.1 虽然通过长连接减少了连接建立开销，但一条连接上的响应需要保持顺序，容易产生队头阻塞。浏览器通过建立多条 TCP 连接缓解这个问题，又会带来额外的连接和资源开销。

此外，HTTP/1.1 的请求头通常以文本形式重复发送，在 Cookie 等请求头较大时也会浪费网络带宽。HTTP/2 因此引入了多路复用、二进制分帧和头部压缩等机制。

面试时可以总结为：

HTTP/1.1 的主要特点包括默认使用持久连接，多个请求可以复用同一条 TCP 连接；请求必须携带 Host 请求头，从而支持虚拟主机；支持管线化、分块传输、条件缓存和范围请求。它提高了连接和网络资源的利用率，但由于响应需要按照请求顺序返回，仍然存在队头阻塞问题，这也是 HTTP/2 引入多路复用的重要原因。

可能追问的问题

HTTP/1.0 和 HTTP/1.1 在连接管理方面有什么区别？
HTTP/1.1 的 Host 请求头有什么作用？
Content-Length 和 Transfer-Encoding: chunked 有什么区别？
HTTP/1.1 管线化为什么会产生队头阻塞？
HTTP/1.1 和 HTTP/2 的主要区别是什么？

8. 请说一下 HTTP 2.0 的特点？

面试题剖析

这道题主要考察候选人是否理解 HTTP/2 为解决 HTTP/1.1 性能问题所做的改进，包括二进制分帧、多路复用、头部压缩、流量控制和服务器推送等机制。

回答时还需要说明：HTTP/2 解决了 HTTP/1.1 的应用层队头阻塞，但因为底层仍然使用 TCP，所以没有解决 TCP 层的队头阻塞。

面试题解答

HTTP/2 没有改变 HTTP 的基本语义，GET、POST、URL、请求头和状态码等概念仍然保留。它主要改变了 HTTP 数据的组织和传输方式，从而提高网络传输效率。

1. 使用二进制分帧

HTTP/1.1 使用文本形式传输报文，而 HTTP/2 将一个 HTTP 消息拆分成多个二进制帧。

常见的帧包括：

HEADERS：传输请求头或响应头。
DATA：传输请求体或响应体。
SETTINGS：传输连接配置信息。
WINDOW_UPDATE：更新流量控制窗口。
RST_STREAM：取消指定的流。
PUSH_PROMISE：通知客户端服务器准备推送资源。

一个 HTTP 响应可以被拆分为：

HEADERS 帧 → DATA 帧 → DATA 帧 → 结束

每个帧都包含长度、类型、标志位和 Stream ID 等信息，接收方可以根据这些信息解析和重新组装数据。

二进制分帧不表示 HTTP/2 只能传输二进制业务数据。HTML、JSON 和文本等内容仍然可以传输，只是它们会被封装在二进制帧中。

2. 支持多路复用

多路复用是 HTTP/2 最核心的特点。

HTTP/2 可以在一条 TCP 连接中创建多个相互独立的流，每个请求和响应属于一个流，并通过不同的 Stream ID 区分。不同流中的帧可以交错传输，接收方再根据 Stream ID 进行组装。

例如，浏览器同时请求 HTML、CSS 和图片时，数据可能按照以下顺序传输：

HTML 请求帧

→ CSS 请求帧

→ 图片请求帧

→ CSS 响应帧

→ HTML 响应帧

→ 图片响应帧

HTTP/1.1 管线化要求响应按照请求顺序返回，如果前面的请求处理较慢，后面的响应就会被阻塞。

HTTP/2 中不同流的响应不需要保持全局顺序，所以可以解决 HTTP/1.1 的应用层队头阻塞，同时减少浏览器为同一个服务器建立的 TCP 连接数量。

3. 使用 HPACK 压缩请求头

HTTP 请求中经常包含大量重复的头部，例如：

Host: www.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Cookie: session_id=123456

HTTP/1.1 通常会在每次请求中重复发送这些请求头，浪费网络带宽。

HTTP/2 使用 HPACK 压缩请求头和响应头。HPACK 通过静态表、动态表和 Huffman 编码等机制，将重复的头部字段替换成较短的索引。

其过程可以简单表示为：

第一次发送完整请求头

→ 将部分请求头保存到动态表

→ 后续请求只发送索引和发生变化的字段

这样可以明显减少重复头部带来的网络开销，尤其适合请求数量较多或者 Cookie 较大的场景。

4. 支持流量控制

HTTP/2 提供连接级别和流级别的流量控制，用于避免发送方发送数据过快，导致接收方来不及处理。

连接级流量控制：限制整条 HTTP/2 连接可以接收的数据量。
流级流量控制：限制某一个 Stream 可以接收的数据量。

接收方通过 WINDOW_UPDATE 帧告诉发送方还可以发送多少数据，发送方不能超过接收方设置的窗口大小。

HTTP/2 流量控制属于应用层机制，TCP 本身也有流量控制，两者控制的层次不同。

5. 支持请求优先级

多个请求通过同一条连接传输时，客户端可以提供优先级信息，使服务器优先处理和发送重要资源。

例如：

HTML、核心 CSS → 高优先级

JavaScript → 中优先级

非关键图片 → 低优先级

需要注意，早期 HTTP/2 设计的复杂优先级信号在实际应用中并没有得到统一、有效的实现，现行规范已经废弃原来的 PRIORITY 帧机制。面试中可以将其概括为 HTTP/2 具备资源优先调度能力。

6. 支持服务器推送

HTTP/2 允许服务器在客户端还没有主动请求资源时，提前将可能需要的资源推送给客户端。

例如，客户端请求 HTML 页面时，服务器知道该页面还会使用某个 CSS 文件，可以提前推送：

客户端请求 HTML

→ 服务器返回 HTML

→ 服务器主动推送 CSS

服务器推送可以减少客户端等待 HTML 解析完成后再请求资源的往返时间。

但是，如果客户端已经缓存了该资源，或者服务器预测错误，推送的数据就会浪费带宽。因此，服务器推送是可选能力，客户端也可以关闭它。

7. 实际使用中通常基于 HTTPS

HTTP/2 标准本身没有强制要求必须使用 HTTPS，也存在明文 HTTP/2，即 h2c。

但主流浏览器通常只在 HTTPS 环境下使用 HTTP/2。客户端和服务器会在 TLS 握手阶段通过 ALPN 协商是否使用 h2：

建立 TCP 连接

→ 进行 TLS 握手

→ 通过 ALPN 协商使用 h2

→ 开始 HTTP/2 通信

HTTP/2 仍然存在 TCP 队头阻塞

HTTP/2 的所有流通常共享同一条 TCP 连接，而 TCP 必须按照顺序向上层交付数据

如果一个 TCP 数据包丢失，即使后续数据包已经到达，也需要等待丢失的数据包完成重传。因此，同一条 TCP 连接中的所有 HTTP/2 流都可能受到影响：

一个 TCP 数据包丢失

→ 等待数据包重传

→ 同一连接中的所有 HTTP/2 流暂停交付

所以，HTTP/2 解决的是 HTTP/1.1 的应用层队头阻塞，没有解决 TCP 层的队头阻塞。HTTP/3 使用基于 UDP 的 QUIC，使不同流能够相对独立地处理丢包。

HTTP/1.1 和 HTTP/2 的核心区别

面试时可以总结为：

HTTP/2 在不改变 HTTP 基本语义的情况下，引入了二进制分帧、多路复用、HPACK 头部压缩、流量控制、资源优先调度和服务器推送等机制。它允许多个请求和响应通过不同的流在同一条 TCP 连接中交错传输，解决了 HTTP/1.1 的应用层队头阻塞，提高了连接利用率。但是 HTTP/2 仍然基于 TCP，当 TCP 数据包丢失时，同一连接上的所有流都可能被阻塞，因此仍然存在 TCP 层的队头阻塞问题。

可能追问的问题

HTTP/2 多路复用与 HTTP/1.1 管线化有什么区别？
HTTP/2 为什么仍然存在队头阻塞？
HPACK 是如何减少 HTTP 请求头大小的？

9. HTTP/3、QUIC 和之前有什么不同？

面试题剖析

这道题主要考察候选人是否理解 HTTP/3、QUIC 与 HTTP/1.1、HTTP/2 的关系，以及 QUIC 为什么能够降低连接延迟、缓解队头阻塞并支持连接迁移。

回答时需要先明确：HTTP/3 是应用层协议，QUIC 是 HTTP/3 使用的传输协议。HTTP/3 保留了 HTTP 的请求方法、状态码和请求头等语义，主要改变了底层传输方式。

正式名称是 HTTP/3，通常不写作 HTTP 3.0。

面试题解答

HTTP/1.1 和 HTTP/2 通常基于 TCP 传输，而 HTTP/3 将底层传输协议替换成了 QUIC。QUIC 基于 UDP 实现，并在协议内部提供可靠传输、多路复用、拥塞控制、流量控制和加密等能力。

三者的协议结构可以表示为：

图：HTTP/2 一栏按浏览器常见的 TLS 部署展示；QUIC 同时提供传输与安全能力。图中的性能比较表示设计收益，实际快慢取决于网络和实现。

根据 RFC 9114，HTTP/3 是 HTTP 语义在 QUIC 传输协议上的映射。它与之前版本的主要区别包括以下几个方面。

1. 底层从 TCP 改为 QUIC

HTTP/1.1 和 HTTP/2 主要依赖 TCP 提供可靠、有序的数据传输。HTTP/3 不再使用 TCP，而是使用基于 UDP 实现的 QUIC。

UDP 本身不保证可靠传输，但这并不表示 QUIC 不可靠。QUIC 在 UDP 之上重新实现了很多传输层能力，包括：

数据确认与超时重传。
拥塞控制。
流量控制。
多路复用。
丢包检测。
可靠、有序的流传输。

因此，QUIC 可以简单理解为一个基于 UDP 实现的、安全且支持多路复用的可靠传输协议。RFC 9000 对 QUIC 的传输机制进行了定义。

2. 减少连接建立时间

HTTP/2 使用 HTTPS 时，需要先建立 TCP 连接，再进行 TLS 握手：

TCP 三次握手 → TLS 握手 → 发送 HTTP 请求

在常见情况下，建立新的 HTTP/2 安全连接需要分别完成 TCP 和 TLS 的握手过程。

QUIC 将传输层握手和 TLS 1.3 握手结合起来。首次建立连接时，通常经过一个往返时间就可以完成连接建立并开始传输应用数据：

QUIC 与 TLS 1.3 联合握手 → 发送 HTTP/3 请求

如果客户端之前连接过该服务器，并保存了有效的会话信息，还可以使用 0-RTT，在握手完成前发送部分应用数据：

使用已有会话信息 → 直接发送 0-RTT 数据 → 完成连接确认

0-RTT 并不是每次连接都能使用，服务器也可以拒绝 0-RTT 数据。此外，0-RTT 存在重放风险，因此通常只适合不会因为重复执行而产生副作用的请求。RFC 9001 定义了 QUIC 对 TLS 1.3 和 0-RTT 的使用方式。

3. 缓解 TCP 层的队头阻塞

HTTP/2 已经支持多路复用，可以在一条 TCP 连接上同时传输多个请求。但是，TCP 提供的是整个连接范围内的有序字节流。

如果一个 TCP 数据包丢失，即使后续数据已经到达，也必须等待丢失的数据完成重传。在此期间，同一条 HTTP/2 连接上的所有流都可能被阻塞：

一个 TCP 数据包丢失 → 等待重传 → HTTP/2 所有流暂停交付

QUIC 将一条连接划分成多个相互独立的流，每个流分别保证自身数据可靠、有序地交付。某个流发生丢包时，主要阻塞该流，其他流仍然可以继续向应用层交付数据：

流 A 丢包 → 流 A 等待重传

流 B 正常 → 流 B 继续传输

流 C 正常 → 流 C 继续传输

因此，HTTP/3 缓解了 HTTP/2 因 TCP 有序交付而产生的跨流队头阻塞。

不过，不同流仍然共享整条 QUIC 连接的网络路径和拥塞控制。发生丢包时，连接整体的发送速度可能下降，只是不会要求所有流都等待某个流的数据完成重传。

4. 原生支持多路复用

HTTP/2 的多路复用由 HTTP/2 自己的二进制分帧层实现，TCP 并不知道不同数据属于哪个流。

HTTP/3 的多路复用则由 QUIC 直接提供。一个请求和响应通常对应一个独立的 QUIC 双向流，流之间可以并发传输：

QUIC 连接

├── Stream 0：请求和响应 A

├── Stream 4：请求和响应 B

└── Stream 8：请求和响应 C

HTTP/3 仍然使用类似 HTTP/2 的二进制帧，例如 HEADERS 帧和 DATA 帧，但这些帧会在不同的 QUIC 流中传输。

5. 支持连接迁移

TCP 使用以下四元组识别一条连接：

源 IP + 源端口 + 目标 IP + 目标端口

当用户从 Wi-Fi 切换到移动网络时，设备的 IP 地址可能发生变化。原来的 TCP 连接通常会失效，需要重新建立 TCP 和 TLS 连接。

QUIC 使用 Connection ID 标识连接，不完全依赖 IP 地址和端口。当客户端网络发生变化时，可以在验证新网络路径后继续使用原有连接：

使用 Wi-Fi 建立 QUIC 连接

→ 切换到移动网络

→ 验证新的网络路径

→ 使用原连接继续通信

连接迁移对于移动设备、实时通信和弱网环境非常有价值。不过，它并不意味着任何网络切换都绝对无感，实际效果仍然取决于路径验证、服务器配置和网络环境。

6. 使用 QPACK 压缩请求头

HTTP/2 使用 HPACK 压缩请求头，但 HPACK 的动态表依赖不同头部块按照一定顺序处理。如果直接将 HPACK 用在相互独立的 QUIC 流上，可能重新引入头部压缩层面的阻塞。

因此，HTTP/3 使用 QPACK 代替 HPACK。QPACK 在保留静态表、动态表等压缩能力的同时，针对 QUIC 流之间不保证全局有序到达的特点进行了设计，可以在压缩率和阻塞风险之间进行平衡。

RFC 9204 对 QPACK 头部压缩机制进行了定义。

7. 默认提供加密保护

HTTP/2 从协议标准上并非绝对要求 TLS，但实际浏览器通常只在 HTTPS 环境中使用 HTTP/2。

QUIC 则将 TLS 1.3 集成到协议握手中，HTTP/3 依赖 QUIC 提供数据机密性、完整性和身份认证。因此，HTTP/3 不需要在 QUIC 之外再单独增加一层 TLS。

需要注意，集成 TLS 并不是“没有 TLS”，而是 TLS 1.3 已经成为 QUIC 协议的一部分。

HTTP/1.1、HTTP/2 和 HTTP/3 的核心区别

面试时可以总结为：

HTTP/3 保留了 HTTP 的基本语义，但将底层的 TCP 替换成了基于 UDP 实现的 QUIC。QUIC 自己提供可靠传输、多路复用、拥塞控制、流量控制和 TLS 1.3 加密。它通过独立的流缓解了 HTTP/2 的 TCP 跨流队头阻塞，同时减少了连接建立时间，并利用 Connection ID 支持网络切换时的连接迁移。HTTP/3 还使用 QPACK 代替 HTTP/2 的 HPACK，适应 QUIC 流之间没有全局顺序的特点。

可能追问的问题

QUIC 基于 UDP，为什么仍然能够保证可靠传输？
HTTP/2 和 HTTP/3 的队头阻塞有什么区别？
QUIC 的 0-RTT 和连接迁移分别是如何实现的？

10. 请说一下 HTTP 的局限性？

面试题剖析

这道题主要考察候选人能否从安全性、状态管理、传输效率、实时通信和可靠性等方面分析 HTTP 协议的局限。

回答时需要注意，HTTP 包含多个版本，不同版本的缺点并不完全相同。例如，HTTP/2 解决了 HTTP/1.1 的应用层队头阻塞，但仍然存在 TCP 层的队头阻塞；HTTP/3 又通过 QUIC 进一步改善了这个问题。

面试题解答

HTTP 是一种简单、通用的请求—响应协议，但它也存在无状态、明文传输、额外头部开销以及实时通信能力有限等问题。

1. HTTP 是无状态协议

HTTP 协议不会自动保存前后两次请求之间的关系。对于服务器来说，每个请求在语义上都是独立的。

例如，用户先登录，再请求订单页面：

第一次请求：用户登录

→ 第二次请求：查询订单

→ HTTP 本身无法自动判断两个请求属于同一个用户

为了维护用户状态，应用通常需要额外使用：

Cookie。
Session。
Token。
JWT。

例如，服务器登录成功后向客户端返回 Session ID，客户端后续请求通过 Cookie 携带该标识：

Cookie: session_id=abc123

无状态有利于服务器水平扩展，但也意味着登录状态、购物车和权限信息等功能需要由应用层额外实现。

2. HTTP 明文传输不安全

普通 HTTP 传输的数据默认不加密，请求路径、请求头、Cookie、请求体和响应内容都可能被中间人读取或修改。

可能面临的风险包括：

窃听：攻击者可以读取账号、密码等敏感数据。
篡改：传输内容可能被恶意修改。
冒充：客户端无法可靠确认正在访问的服务器身份。

其风险可以表示为：

客户端发送 HTTP 数据

→ 中间人截获、查看或修改数据

→ 数据继续发送到服务器

HTTPS 通过 HTTP + TLS 解决这些问题，提供：

加密：防止传输内容被直接读取。
完整性校验：防止数据被篡改。
身份认证：通过数字证书验证服务器身份。

需要注意，HTTPS 只能保护数据传输过程，不能自动解决 SQL 注入、XSS、越权访问等应用层安全漏洞。

3. HTTP 请求头可能产生较大开销

HTTP 请求通常会重复携带大量请求头，例如：

Host: www.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Cookie: session_id=abc123
Authorization: Bearer xxxxxx

在请求数量较多时，重复传输 Cookie、User-Agent 等字段会占用网络带宽。如果业务数据本身很小，请求头占整个请求的比例可能非常高。

不同版本采用了不同的优化方式：

HTTP/1.1：请求头通常不压缩。
HTTP/2：使用 HPACK 压缩请求头。
HTTP/3：使用 QPACK 压缩请求头。

4. HTTP/1.1 的并发能力有限

HTTP/1.1 虽然默认使用持久连接，但同一条连接处理多个请求时仍然存在明显限制。

HTTP/1.1 管线化允许连续发送多个请求，但服务器必须按照请求顺序返回响应：

发送请求 A → 发送请求 B → 发送请求 C

接收响应 A → 接收响应 B → 接收响应 C

如果请求 A 处理较慢，即使请求 B 和请求 C 已经处理完成，也需要等待响应 A，这就是应用层队头阻塞。

浏览器通常通过为同一个域名建立多条 TCP 连接缓解这个问题，但会增加 TCP 握手、TLS 握手、拥塞控制和服务器连接资源的开销。

HTTP/2 使用多路复用解决了 HTTP/1.1 的应用层队头阻塞，但它的多个流共享一条 TCP 连接。如果 TCP 数据包丢失，同一连接中的所有流仍然可能等待重传。

HTTP/3 使用 QUIC，让不同流可以相对独立地处理丢包，进一步缓解了 TCP 层的队头阻塞。

5. 请求—响应模型不适合所有实时通信场景

传统 HTTP 通常由客户端主动发起请求，服务器收到请求后返回响应。服务器不能像客户端一样随时主动发起普通 HTTP 请求。

如果客户端需要实时获取服务器状态，可能需要定时轮询：

客户端发送请求 → 服务器返回暂无数据

→ 等待一段时间

→ 客户端再次发送请求

频繁轮询会产生大量无效请求，增加网络和服务器开销。

常见的改进方式包括：

长轮询：服务器等待有新数据后再返回响应。
SSE：服务器通过一个长连接持续向客户端推送事件。
WebSocket：在客户端与服务器之间建立全双工通信。
WebHook：服务器在事件发生时调用客户端提供的回调地址。

HTTP/2 的服务器推送主要用于提前推送页面资源，并不等同于面向业务消息的双向实时通信。

6. 请求超时后难以确认服务端是否执行成功

HTTP 客户端发送请求后，如果发生网络超时，客户端可能无法确定服务器是否已经完成业务处理。

例如，客户端提交支付请求：

客户端发送支付请求

→ 服务器已经扣款

→ 响应在网络中丢失

→ 客户端认为请求失败并重新提交

如果接口没有幂等机制，重复请求可能造成重复扣款、重复下单等问题。

这类问题通常需要通过以下方式解决：

幂等键。
唯一业务编号。
数据库唯一约束。
请求结果查询接口。
重试和补偿机制。

这并不是 TCP 可靠传输就能完全解决的问题，因为连接中断或超时时，客户端仍然可能无法判断服务器的业务操作是否已经完成。

不同 HTTP 版本的主要局限

面试时可以总结为：

HTTP 的主要缺点包括协议本身无状态，需要通过 Cookie、Session 或 Token 维护用户状态；普通 HTTP 使用明文传输，存在窃听、篡改和身份冒充风险，需要 HTTPS 提供安全保护；请求头可能重复传输，产生额外带宽开销；HTTP/1.1 并发能力有限并存在队头阻塞；传统请求—响应模式也不适合高实时、全双工通信场景。此外，请求超时后，客户端可能无法确认服务器是否已经完成业务操作，因此重要接口还需要设计幂等机制。

可能追问的问题

HTTP 无状态是什么意思？Cookie、Session 和 Token 如何维护用户状态？
HTTP 与 HTTPS 有什么区别，HTTPS 如何保证数据安全？
HTTP/1.1、HTTP/2 和 HTTP/3 分别存在哪些队头阻塞问题？

11. 请说一下 HTTP 请求过程

面试题剖析

这道题主要考察候选人对一次完整 HTTP 请求链路的理解，包括 URL 解析、缓存判断、DNS 解析、连接建立、TLS 握手、HTTP 报文传输、服务器处理以及浏览器解析响应等过程。

回答时可以假设用户在浏览器中首次访问一个 HTTPS 地址。如果存在浏览器缓存、DNS 缓存或可复用连接，部分步骤可能会被跳过。

面试题解答

假设用户在浏览器中访问：

https://www.example.com/users?id=1001

一次完整的 HTTP 请求过程可以概括为：

解析 URL → 检查缓存 → DNS 解析 → 建立连接 → TLS 握手 → 发送 HTTP 请求 → 服务器处理 → 返回 HTTP 响应 → 浏览器处理响应 → 复用或关闭连接

1. 浏览器解析 URL

浏览器首先解析用户输入的 URL，识别其中的各个组成部分：

协议：https

域名：www.example.com

端口：443

路径：/users

查询参数：id=1001

如果 URL 中没有显式指定端口，浏览器会使用协议的默认端口：

HTTP 默认使用 80 端口。
HTTPS 默认使用 443 端口。

如果 URL 中包含 # 后面的片段标识，例如：

https://www.example.com/index.html#title

#title 只由浏览器在本地处理，不会发送给服务器。

2. 检查浏览器缓存

发送网络请求之前，浏览器会根据缓存规则检查本地是否已经保存了该资源。

如果缓存仍然有效，浏览器可以直接使用本地资源，不再向服务器发送请求：

检查缓存 → 缓存有效 → 直接使用本地资源

如果缓存已经过期，但保存了 ETag 或 Last-Modified，浏览器可以向服务器发送条件请求：

If-None-Match: "resource-v1"

If-Modified-Since: Sat, 29 Aug 2026 10:00:00 GMT

服务器判断资源没有变化时，会返回 304 Not Modified，浏览器继续使用本地缓存；如果资源已经变化，则返回新的资源内容。

如果没有可用缓存，浏览器继续执行后续网络请求过程。

3. 通过 DNS 解析域名

网络通信需要使用 IP 地址，而用户输入的通常是域名，因此浏览器需要通过 DNS 将域名解析成 IP 地址。

DNS 查询通常会依次检查：

浏览器 DNS 缓存 → 操作系统 DNS 缓存 → 本地 DNS 服务器 → 权威 DNS 服务器

解析完成后，浏览器可以得到目标服务器的 IPv4 或 IPv6 地址，例如：

www.example.com → 93.184.216.34

实际访问大型网站时，DNS 也可能返回 CDN 节点或负载均衡服务的地址，使用户访问距离更近的服务器。

4. 建立网络连接

获得服务器 IP 地址后，浏览器需要与服务器建立连接。具体过程取决于使用的 HTTP 版本。

HTTP/1.1 和 HTTP/2 通常基于 TCP，需要先通过三次握手建立 TCP 连接：

客户端 → 服务器：SYN

服务器 → 客户端：SYN + ACK

客户端 → 服务器：ACK

其过程可以表示为：

发送 SYN → 接收 SYN + ACK → 发送 ACK → TCP 连接建立

如果浏览器与该服务器之间已经存在可以复用的连接，就不需要再次进行 TCP 三次握手。

HTTP/3 使用基于 UDP 的 QUIC，不需要建立 TCP 连接，而是通过 QUIC 建立安全连接。

5. 进行 TLS 握手

因为访问的是 HTTPS 地址，所以建立 TCP 连接后，客户端还需要与服务器进行 TLS 握手。

TLS 握手主要完成以下工作：

协商 TLS 版本和加密算法。
服务器向客户端发送数字证书。
客户端验证证书是否合法、是否过期以及域名是否匹配。
双方协商生成会话密钥。
后续 HTTP 数据使用会话密钥加密传输。

其过程可以简单表示为：

协商加密参数 → 验证服务器证书 → 生成会话密钥 → 建立加密通道

如果使用 HTTP/2，客户端和服务器还会通过 ALPN 协商是否使用 h2 协议。

如果使用 HTTP/3，TLS 1.3 已经集成在 QUIC 的握手过程中，不需要先建立 TCP 连接再单独进行 TLS 握手。

6. 浏览器构造并发送 HTTP 请求

连接建立后，浏览器根据 URL、Cookie 和自身信息构造 HTTP 请求。

以 HTTP/1.1 为例，请求报文可能如下：

GET /users?id=1001 HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Encoding: gzip, br
Cookie: session_id=abc123
Connection: keep-alive

HTTP 请求通常包含：

请求行：请求方法、资源路径和 HTTP 版本。
请求头：域名、数据格式、Cookie、压缩方式等信息。
空行：分隔请求头和请求体。
请求体：POST、PUT 等请求可能携带需要提交的数据。

使用 HTTPS 时，包括请求路径、查询参数、请求头和请求体在内的 HTTP 数据都会经过 TLS 加密，然后再通过网络发送。

7. 请求经过网络到达服务器

HTTP 数据会依次经过传输层和网络层封装，最终通过路由器、网关、运营商网络等设备到达目标服务器。

在实际系统中，请求通常不会直接到达业务应用，而是可能依次经过：

客户端 → CDN → 负载均衡器 → 反向代理服务器 → Web 应用

其中：

CDN 可以直接返回缓存的静态资源。
负载均衡器将请求分配给某台服务器。
反向代理负责转发请求、TLS 终止、限流或缓存。
Web 应用负责执行具体业务逻辑。

具体经过哪些组件取决于系统架构，并不是每个请求都会经过上述全部组件。

8. 服务器处理请求

Web 服务器接收到请求后，会解析请求方法、路径、请求头和请求体，然后将请求交给对应的业务程序处理。

服务器处理过程可能包括：

匹配路由 → 身份认证 → 参数校验 → 执行业务逻辑 → 查询数据库或缓存 → 构造响应

例如，请求路径是：

GET /users?id=1001

服务器可能根据 id=1001 查询用户信息，将结果序列化为 HTML 或 JSON，再生成 HTTP 响应。

9. 服务器返回 HTTP 响应

服务器处理完成后，会向客户端返回 HTTP 响应。

以 HTTP/1.1 为例：

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 24
Cache-Control: max-age=3600
Set-Cookie: session_id=abc123
Connection: keep-alive

{"id":1001,"name":"tom"}

HTTP 响应通常包含：

状态行：HTTP 版本、状态码和状态描述。
响应头：数据格式、缓存规则、Cookie 和数据长度等信息。
空行：分隔响应头和响应体。
响应体：服务器返回的 HTML、JSON、图片或其他数据。

浏览器会根据状态码决定后续操作：

200：请求成功，处理响应内容。
301、302：根据 Location 地址重新发送请求。
304：使用浏览器本地缓存。
404：请求的资源不存在。
500：服务器内部发生错误。

10. 浏览器处理响应

浏览器收到响应后，会先进行 TLS 解密和内容解压缩，然后根据 Content-Type 决定如何处理响应体。

如果服务器返回的是 HTML 页面，浏览器通常会执行：

解析 HTML 生成 DOM

→ 解析 CSS 生成 CSSOM

→ 执行 JavaScript

→ 请求 CSS、JavaScript、图片等子资源

→ 生成渲染树

→ 页面布局和绘制

请求页面中的 CSS、JavaScript 和图片时，会再次经历缓存检查、发送 HTTP 请求和处理响应等过程，但通常可以复用已经建立的连接。

如果响应是接口返回的 JSON 数据，则一般由 JavaScript 或客户端程序解析后更新页面。

11. 复用或关闭连接

响应完成后，连接是否关闭取决于 HTTP 版本、请求头以及客户端和服务器的配置。

HTTP/1.1 默认使用持久连接，可以继续发送后续请求。
HTTP/2 可以通过一条 TCP 连接并发传输多个流。
HTTP/3 可以通过一条 QUIC 连接并发传输多个流。
如果设置了 Connection: close，或者连接空闲时间超过限制，连接会被关闭。

一次典型的 HTTPS 请求最终可以总结为：

面试时可以总结为：

浏览器首先解析 URL 并检查本地缓存。如果需要访问服务器，就通过 DNS 将域名解析成 IP 地址，然后与服务器建立 TCP 连接；如果使用 HTTPS，还需要完成 TLS 握手。连接建立后，浏览器发送 HTTP 请求，服务器经过反向代理和业务应用处理后返回 HTTP 响应。浏览器根据状态码、响应头和响应体处理缓存、Cookie 及页面内容，最后解析和渲染页面。请求结束后，连接可以继续复用，也可以在超时或明确要求关闭时释放。

可能追问的问题

DNS 域名解析的完整过程是什么？
HTTPS 中 TLS 握手的过程是什么？
浏览器收到 HTML 后，是如何完成页面渲染的？

12. 能不能详细介绍一下 HTTPS？

面试题剖析

这道题主要考察候选人对 HTTPS 工作原理的理解，包括 HTTPS 与 HTTP 的关系、TLS 握手、数字证书验证、密钥协商、数据加密以及 HTTPS 能够解决和不能解决的安全问题。

回答时需要重点说明：

HTTPS 并不是一种全新的 HTTP 协议，而是运行在安全传输通道上的 HTTP。
非对称加密主要用于身份认证和密钥协商，真正传输 HTTP 数据时主要使用对称加密。
HTTPS 不仅提供加密，还提供完整性保护和服务器身份认证。

面试题解答

HTTPS 的全称是 HyperText Transfer Protocol Secure，可以理解为运行在 TLS 安全通道之上的 HTTP。下面是 HTTP 不同版本的结构

根据 RFC 9110，HTTPS 需要对服务器进行身份认证，并为 HTTP 通信提供机密性和完整性保护。

一、HTTPS 主要解决什么问题

普通 HTTP 使用明文传输，可能面临三类风险。

1. 数据被窃听

攻击者可以读取客户端和服务器之间传输的数据，例如账号、密码、Cookie 和业务数据。

客户端发送 HTTP 数据

→ 中间人读取数据

→ 数据继续发送到服务器

HTTPS 对数据进行加密，没有会话密钥的第三方无法直接读取数据，从而保证数据的机密性。

2. 数据被篡改

攻击者可能在传输过程中修改请求或响应，例如替换网页内容、修改订单金额或者向页面中插入恶意代码。

TLS 使用带认证的加密算法保护数据。接收方可以检测数据是否被修改，从而保证数据的完整性。

3. 服务器被冒充

攻击者可能伪装成目标网站，诱导用户向错误的服务器提交账号和密码。

HTTPS 通过数字证书验证服务器身份，确认当前服务器有权代表用户访问的域名提供服务。

因此，HTTPS 主要提供三项安全能力：

二、HTTPS 使用了哪些密码学技术

HTTPS 不是只使用一种加密算法，而是组合使用多种密码学技术。

1. 非对称密码与数字签名

服务器拥有一对密钥：

公钥：可以公开，通常包含在数字证书中。
私钥：只能由服务器保存，不能泄露。

在现代 TLS 握手中，服务器主要使用私钥对握手信息进行数字签名，证明自己确实持有证书对应的私钥。

客户端使用证书中的公钥验证签名，从而确认：

服务器持有证书对应的私钥。
当前握手信息没有被篡改。

需要注意，TLS 1.3 通常不是使用证书公钥直接加密会话密钥，而是通过 ECDHE 等密钥交换机制协商共享密钥。

2. ECDHE 密钥协商

客户端和服务器分别生成临时密钥材料，并交换各自的公开参数。双方可以根据自己的私有参数和对方的公开参数计算出相同的共享秘密。

客户端临时私钥 + 服务器临时公钥 → 共享秘密

服务器临时私钥 + 客户端临时公钥 → 相同的共享秘密

监听网络的攻击者虽然可以看到双方交换的公开参数，但无法由此计算出共享秘密。

双方再使用 HKDF 等密钥派生函数，从共享秘密和握手上下文中派生出真正用于通信的会话密钥。

ECDHE 还可以提供前向保密：即使服务器的证书私钥以后发生泄露，攻击者通常也无法使用该长期私钥解密之前保存的历史通信数据。

大家感兴趣的话，可以了解调研一下，为什么会是相同的共享秘密

3. 对称加密

TLS 握手完成后，HTTP 请求和响应主要使用协商出的对称会话密钥进行加密。

常见的 TLS 1.3 加密算法包括：

AES-GCM。
ChaCha20-Poly1305。

对称加密的速度远高于非对称加密，更适合加密大量业务数据。

因此，不能简单地说“HTTPS 使用非对称加密传输数据”。更准确的说法是：

证书和数字签名 → 验证服务器身份

ECDHE → 协商共享秘密

HKDF → 派生会话密钥

对称加密 → 加密实际 HTTP 数据

图：以证书认证与 ECDHE 路径说明 TLS 1.3 的机制分工；PSK 恢复另有路径，此图不是握手报文时序。

三、数字证书是如何证明服务器身份的

数字证书可以理解为由可信机构签发的服务器身份证明，通常包含：

证书对应的域名。
服务器公钥。
证书有效期。
CA : 证书颁发机构。
数字签名。
密钥用途等扩展信息。

服务器通常不会只发送一张证书，而是发送一条证书链：

服务器证书 → 中间 CA 证书 → 根 CA 证书

其中：

服务器证书证明服务器公钥属于对应域名。
中间 CA 负责签发服务器证书。
根 CA 是证书链的信任起点，通常预先保存在操作系统或浏览器的信任库中。

客户端收到证书链后，主要检查：

证书链中的数字签名是否有效。
证书是否在有效期内。
证书中的域名是否与当前访问域名匹配。
证书用途是否允许用于服务器身份认证。
是否能够最终连接到客户端信任的根证书。
根据客户端策略检查证书是否已经被吊销。

例如，用户访问：

https://www.example.com

如果服务器返回的证书只适用于：

api.example.com

那么域名不匹配，浏览器会提示证书错误。

如果攻击者拦截请求并返回自己的证书，由于该证书无法形成一条通向客户端可信根 CA 的有效证书链，浏览器也会发出安全警告。

四、TLS 1.3 握手过程

下面以常见的单向认证为例，也就是客户端验证服务器身份，但服务器不要求客户端提供证书。

对于基于 TCP 的 HTTPS，请求过程可以概括为：

DNS 解析

→ TCP 三次握手

→ TLS 握手

→ 发送加密的 HTTP 请求

→ 接收加密的 HTTP 响应

TLS 1.3 的核心握手过程如下。

1. 客户端发送 ClientHello

客户端向服务器发送 ClientHello，其中通常包含：

客户端支持的 TLS 版本。
客户端支持的密码套件。
客户端随机数。
ECDHE 的客户端公开参数，即 key_share。
SNI，表示客户端希望访问的域名。
ALPN，表示客户端支持的应用层协议，例如 HTTP/1.1 或 HTTP/2。

ClientHello
├── supported_versions：支持 TLS 1.3
├── cipher_suites：支持的密码套件
├── key_share：客户端 ECDHE 公开参数
├── server_name：www.example.com
└── ALPN：h2、http/1.1

SNI 使一台服务器能够为多个域名选择不同证书；ALPN 用于协商 TLS 建立后使用 HTTP/1.1 还是 HTTP/2。

2. 服务器发送 ServerHello

服务器从客户端提供的选项中选择 TLS 版本、密码套件和密钥交换参数，然后发送 ServerHello。

ServerHello
├── selected_version：TLS 1.3
├── cipher_suite：选择的密码套件
└── key_share：服务器 ECDHE 公开参数

客户端和服务器根据双方的 ECDHE 参数计算共享秘密，并由此派生出握手阶段使用的密钥。从 ServerHello 之后，TLS 1.3 的大部分握手消息已经受到加密保护。

3. 服务器发送证书和身份证明

服务器随后发送：

EncryptedExtensions：已协商的扩展信息。
Certificate：服务器证书链。
CertificateVerify：服务器对握手上下文的数字签名。
Finished：对完整握手过程的校验信息。

EncryptedExtensions

→ Certificate

→ CertificateVerify

→ Finished

客户端验证证书链和域名，并使用证书公钥验证 CertificateVerify 中的数字签名，从而确认服务器身份。

Finished 用于确认双方拥有正确的握手密钥，并验证之前的握手消息没有被篡改。

4. 客户端完成握手

证书验证通过后，客户端向服务器发送自己的 Finished 消息。

客户端验证服务器证书

→ 验证服务器数字签名

→ 验证 Finished

→ 客户端发送 Finished

→ 客户端完成本端握手；应用数据密钥按 TLS 密钥计划派生

至此 TLS 握手完成，客户端和服务器可以使用会话密钥加密 HTTP 请求和响应。

完整过程可以概括为：ClientHello → ServerHello → 加密的服务端认证与 Finished → 客户端 Finished。

RFC 8446 对 TLS 1.3 的握手和密钥派生过程进行了完整定义。

五、HTTP 数据是如何被加密传输的

TLS 握手完成后，浏览器构造正常的 HTTP 请求，例如：

GET /users?id=1001 HTTP/1.1

Host: www.example.com

Cookie: session_id=abc123

Accept: application/json

TLS 会将 HTTP 数据分割并封装成 TLS 记录，使用会话密钥进行认证加密，再交给 TCP 发送：

HTTP 请求

→ TLS 分割并加密

→ 生成 TLS 记录

→ TCP 分段

→ IP 数据包

→ 发送到服务器

服务器收到数据后执行相反的过程：

接收 IP 数据包

→ TCP 重组数据

→ TLS 验证并解密

→ 得到 HTTP 请求

→ 交给 Web 服务器处理

服务器返回 HTTP 响应时，同样会经过 TLS 加密。

六、HTTPS 中哪些内容会被加密

TLS 握手完成后，HTTP 请求和响应的主要内容都会被加密，包括：

URL 中的路径。
URL 中的查询参数。
HTTP 请求头。
Cookie 和 Authorization。
请求体。
响应头。
响应体。

例如：

https://www.example.com/orders?id=1001

其中 /orders?id=1001 会在 TLS 通道中加密。

但是，HTTPS 无法隐藏所有网络信息。网络中的设备通常仍然可能看到：

目标服务器的 IP 地址。
目标端口。
数据包的大小。
数据包发送时间和通信持续时间。
在未使用加密 DNS 时，DNS 查询的域名。
在未使用 ECH 等保护机制时，TLS SNI 中的目标域名。

因此，HTTPS 保护的是通信内容，而不是完全隐藏通信行为。

另外，即使查询参数会被 TLS 加密，也不应该将密码或 Token 放在 URL 中。URL 可能被浏览器历史记录、服务器访问日志、监控系统或其他应用组件保存。

七、TLS 会话恢复和 0-RTT

完整的 TLS 握手涉及证书验证和密钥协商，会产生一定的计算和网络开销。

TLS 1.3 支持通过 Session Ticket 恢复之前的会话。客户端再次连接服务器时，可以使用之前获得的会话信息减少握手开销：

首次连接 → 完整 TLS 握手 → 服务器返回 Session Ticket → 再次连接 → 使用 Session Ticket 恢复会话

在满足条件的情况下，客户端还可以发送 0-RTT 数据，即在握手完全结束前发送应用数据。

发送 ClientHello 和 0-RTT 数据 → 服务器验证会话恢复信息 → 接受或拒绝 0-RTT 数据

0-RTT 数据存在被重放的风险，因此不适合直接执行支付、转账、创建订单等具有副作用且没有幂等保护的操作。

八、单向认证和双向认证

普通 HTTPS 通常使用单向认证：

客户端验证服务器证书

服务器通过证书向客户端证明身份，但客户端通常使用账号密码、Cookie 或 Token 向服务器证明身份。

在金融系统、企业内部系统等安全要求较高的场景中，可以使用双向 TLS，也称为 mTLS：

客户端验证服务器证书

服务器验证客户端证书

mTLS 可以在建立连接时同时验证客户端和服务器身份，但证书签发、更新和吊销等管理成本也更高。

九、HTTPS 与 HTTP 的核心区别

现代 TLS 的性能开销通常可以通过以下方式降低：

TLS 1.3 减少握手往返次数。
TLS 会话恢复。
HTTP 长连接。
HTTP/2 和 HTTP/3 的连接复用。
CPU 对常见加密算法的硬件加速。

十、HTTPS 的常见误区

误区一：HTTPS 使用服务器公钥加密所有数据

实际上传输业务数据时主要使用对称会话密钥。证书公钥主要用于验证数字签名和服务器身份。

误区二：使用 HTTPS 就表示网站绝对安全

HTTPS只能保护传输通道。如果服务器存在 SQL 注入、XSS、弱密码或越权漏洞，攻击者仍然可能获取数据。

误区三：HTTPS 会隐藏所有访问目标

HTTPS 会加密 URL 的路径和查询参数，但服务器 IP、流量大小以及部分域名信息仍可能被观察到。

误区四：有证书就一定可信

客户端还需要验证证书链、有效期、域名和证书用途。用户如果忽略浏览器的证书警告，仍然可能受到中间人攻击。

面试时可以总结为：

HTTPS 本质上是运行在 TLS 安全通道上的 HTTP，主要提供机密性、完整性和服务器身份认证。客户端与服务器先通过 TLS 握手协商协议版本和加密算法，服务器发送数字证书证明身份，双方通过 ECDHE 协商共享秘密并派生会话密钥。握手完成后，实际 HTTP 数据使用高效的对称加密算法传输。数字证书和非对称密码主要负责身份认证，ECDHE 负责密钥协商，对称密码负责加密业务数据。HTTPS 可以防止传输数据被窃听和篡改，但不能解决服务器漏洞，也不能完全隐藏 IP、流量特征等通信元数据。

可能追问的问题

TLS 1.3 握手的完整过程是什么，相比 TLS 1.2 有哪些变化？
浏览器如何验证服务器数字证书，证书链的作用是什么？
HTTPS 为什么同时使用非对称密码、密钥协商和对称加密？

13. HTTPS 与 HTTP 的区别

面试题剖析

本题侧重对比和选型，与前面的 HTTPS 原理题不同。回答要说明 HTTP 语义与 TLS 安全通道的关系，比较保护能力、端口、握手和开销，不把证书或 HTTPS 等同于网站业务绝对安全。

面试题解答

HTTPS 是运行在安全传输通道上的 HTTP，保留请求方法、状态码、头部等 HTTP 语义，通过 TLS 提供机密性、完整性和身份认证。

图：建连一行以新建 TCP 连接上的 HTTPS 为例；HTTP/3 使用 QUIC，复用连接也可跳过建连。性能需结合版本、网络和复用情况比较。

加密保护到哪里

HTTPS 会保护路径、查询参数、Cookie、请求体和响应内容。IP、端口、流量大小及时间等元数据通常仍可观察；未受保护的 DNS 或 SNI 也可能暴露域名。TLS 终止在反向代理时，代理能够看到明文，代理到后端是否继续加密取决于部署。

两个常见误区

第一，直接访问 https:// 不必先连接 80 端口。只有访问 HTTP 地址后收到跳转等情况下才可能切换，浏览器也可能依据 HSTS 直接使用 HTTPS。

第二，HTTPS 证明的是通信目标身份并保护通道，不能自动解决 XSS、越权、弱密码或恶意网站问题。证书验证不能跳过，敏感凭据也不应随意写入 URL。

面试时可以总结为：HTTP 规定如何交换请求和响应，HTTPS 在保留这些语义的基础上增加 TLS 安全保护。它的成本主要是握手和加解密，通常可通过现代 TLS、连接复用和会话恢复降低。

可能追问的问题

HTTPS 的 URL 路径和查询参数是否加密？
HTTPS 反向代理到后端一定也是加密的吗？
为什么 HTTPS 不能防止 XSS？
直接访问 HTTPS 为什么不需要先访问 HTTP？

DNS

14. 请说一下在浏览器输入网址显示页面的过程

面试题剖析

这是综合题，考察能否将应用层、传输层、网络层和浏览器渲染串成完整链路。建议先给总流程，再展开 DNS 和渲染，避免把缓存检查当成每次都联网，或误认为访问 HTTPS 必须先访问 HTTP。

面试题解答

以首次访问 https://www.example.com/ 为例，总体过程是：解析 URL → 检查缓存 → 必要时解析域名和建立连接 → 发送请求 → 处理响应 → 解析、布局、绘制与合成页面。

图：缓存或连接可以复用时会跳过部分步骤；HTTP/3 通过 QUIC 建立安全连接。

解析地址与检查缓存

浏览器识别协议、主机、端口、路径和查询参数；URL 中 # 后的片段不作为 HTTP 请求目标发给服务器。明确的 HTTPS 地址可以直接建立安全连接，无须先访问 80 端口。

可用的 HTTP 新鲜缓存能够直接提供资源；需要重新验证的缓存则要发送条件请求，服务器可能返回 304，浏览器据此复用缓存。DNS 缓存保存域名记录，HTTP 缓存保存资源响应，两者不能混为一谈。Service Worker 等机制还可能拦截请求，具体路径取决于页面和浏览器配置。

DNS：从域名得到地址

浏览器可能利用自己的缓存或解析器，系统解析过程也可能查询缓存和 hosts 文件。检查顺序受平台与浏览器配置影响，不应背成所有环境固定不变的顺序。需要外部查询时，通常交给配置的递归解析器，它不一定是运营商 DNS，也可能是企业或公共解析器。

图：以相关缓存未命中为前提，递归解析器分别查询根、顶级域和权威服务器。

客户端要求递归解析器返回最终结果；解析器若没有缓存，通常先询问根服务器得到 .com 的委派，再询问 .com 得到 example.com 的权威服务器，最后查询权威服务器获得记录。这是解析器逐次发起的迭代查询，不是根服务器替客户端一路查到底。权威数据和缓存记录按 TTL 管理，完整层级见 RFC 1034。

常见记录包括 A（IPv4）、AAAA（IPv6）、CNAME（别名）、NS（权威服务器）、MX（邮件交换）。有 CNAME 时还可能继续解析别名目标；DNS 可返回多个地址或 CDN 节点地址。记录不存在和解析暂时失败也应区分。

传统 DNS 常用 UDP 53，也支持 TCP 53；响应被截断等情况下可以通过 TCP 重试，并非只能使用 UDP。浏览器还可能使用 DoH 等加密解析方式，因此不能将“DNS 一律走 UDP 53”写死。

路由与传输连接

操作系统查路由，选择出口与下一跳；以太网 IPv4 下通过 ARP 找下一跳 MAC，IPv6 使用 NDP。这些动作发生在实际发包过程中，DNS 请求本身也要经过网络。

如果已有可复用连接，可能不再新建。否则 HTTP/1.1、HTTP/2 通常先建立 TCP；HTTPS 再进行 TLS 握手、证书验证和密钥协商，可通过 ALPN 选择 HTTP 版本。HTTP/3 使用 QUIC，把 TLS 1.3 与传输握手结合，不经过 TCP 三次握手。

请求与服务端处理

浏览器发送请求，可能先到 CDN、负载均衡或反向代理，再进入应用。服务端完成路由、认证、业务处理后返回状态码、响应头和内容。缓存节点命中时可直接返回，不必每次访问业务服务器。重定向会引出新请求，且可能涉及新的域名与连接。

解析与渲染

浏览器处理 TLS 解密、内容解压缩、缓存和 Cookie。收到 HTML 后可以边接收边解析，构建 DOM；下载并解析 CSS 形成 CSSOM，再进行样式计算、布局、绘制和合成。解析过程中发现 CSS、脚本、图片时会发起子资源请求，多项工作可以交错进行，而不是等主文档全部结束才开始。

普通没有 async、defer 的经典脚本可能阻塞 HTML 解析；defer 脚本在解析后按序执行，async 脚本就绪后执行，执行时也可能打断解析。不能简单说所有 JavaScript 都以同样方式阻塞页面。布局确定元素几何位置，绘制生成绘制指令，合成将相关图层组合输出；后续资源或交互还会触发页面更新。

连接复用

资源加载后，连接可能保留供后续请求使用，也可能因超时、对端关闭或网络变化终止。网页显示完成不意味着立即进行 TCP 四次挥手。

面试时可以总结为：浏览器先确定访问目标和缓存策略，需要网络时解析地址、准备传输与安全连接，完成请求响应后逐步解析和渲染。DNS 缓存、HTTP 缓存、连接复用与不同 HTTP 版本都会改变实际路径，流程不是每次原封不动地执行。

可能追问的问题

DNS 的递归查询与迭代查询分别由谁发起？
DNS 为什么也需要支持 TCP？
强缓存、304 和 DNS 缓存各自省掉什么步骤？
async、defer 与普通脚本有什么区别？
页面显示后，TCP 连接一定立即关闭吗？

面试题剖析

本题侧重 Cookie 自身的保存、携带规则和安全属性。需要区分浏览器中的 Cookie 与服务器端 Session，也要说明“浏览器保存”不等于“服务器可以信任其中的数据”。

面试题解答

Cookie 是浏览器保存的一小段名称和值及相关属性，用于在符合条件的后续请求中携带状态。常见用途包括保存偏好、会话标识和统计标识。

设置与发送

服务器使用 Set-Cookie 响应头设置 Cookie，浏览器按规则存储，再通过 Cookie 请求头发送名称和值。例如：

HTTP/1.1 200 OK
Set-Cookie: session_id=example_token; Path=/; Secure; HttpOnly; SameSite=Lax
Content-Length: 0

后续请求可能包含 Cookie: session_id=example_token。Path、HttpOnly 等属性不会原样作为 Cookie 值一起发回。非 HttpOnly 的 Cookie 也可由同源脚本通过相关 API 设置或读取。

关键属性

没有设置持久有效期的称为会话 Cookie，生命周期由浏览器会话管理；浏览器恢复会话时可能恢复它，不能保证关闭窗口就一定消失。浏览器可因用户清理、容量限制或隐私策略提前移除 Cookie。基础存储与发送规则见 RFC 6265。

安全与容量

Cookie 有大小、数量和浏览器策略限制，适合少量标识，不适合存放大块业务数据。用户可修改客户端可控数据，服务器不能仅凭 role=admin 就授予权限。签名可用于校验篡改，但不代表加密。

HttpOnly 降低凭据被脚本直接读取的风险，不能阻止 XSS 以当前用户身份发请求。SameSite 能缓解部分 CSRF 风险，但不能代替所有 CSRF 防护。跨站与跨源是不同概念，CORS、SameSite 和浏览器第三方 Cookie 策略也不是同一套规则。

面试时可以总结为：Cookie 是浏览器保存并按范围和安全规则自动携带的状态数据，服务端通常用它传递 Session ID。它的作用取决于属性与浏览器策略，敏感身份信息仍需服务端校验和 HTTPS 等保护。

可能追问的问题

Cookie 的 Domain 与 Path 分别控制什么？
HttpOnly 为什么不能彻底防止 XSS？
会话 Cookie 在关闭浏览器后一定消失吗？
SameSite 和 CORS 解决的是同一问题吗？

16. 请简单介绍一下 Session

面试题剖析

本题重点是服务端如何借助会话标识关联多次请求，及会话的创建、失效与共享。回答不能只停留在“Session 在服务端”，还应说明 Session ID 被盗后仍会产生风险。

面试题解答

Session 是一种服务端会话管理机制。服务器保存会话数据，使用一个难以预测的 Session ID 关联客户端请求，常通过 Cookie 传递该标识。

图：这里展示服务端 Session。会话数据留在服务端减少直接暴露，但仍须保护 Session ID；不能据此认定 Session 天然安全。

登录后的完整流程

用户提交凭据 → 服务器验证身份 → 创建或更新会话 → 生成新的 Session ID → 用 Set-Cookie 返回 → 后续请求携带标识 → 服务器查询会话并进行授权。

例如服务端会话存储中保存 session_id → {user_id: 1001, expires_at: ...}，浏览器只保存 Session ID。会话也可以在匿名访问阶段创建，并非一定登录后才存在；登录或权限提升时应轮换标识，防止会话固定。

有效期与退出登录

服务端可以设置空闲超时和绝对有效期。浏览器 Cookie 到期与服务端 Session 到期是两个不同的控制点：Cookie 消失不意味着服务端数据立刻删除，服务端会话失效后旧 Cookie 也不应继续登录。

退出登录时应使服务端会话或相关凭据失效，同时让客户端 Cookie 过期。单纯删除浏览器 Cookie 无法让已被复制的 Session ID 立即失效。

多实例如何共享

单机可以保存于内存；多台服务器之间需要共享存储、复制机制或会话保持。Redis 共享会话方便扩展，但要考虑过期、可用性、并发更新以及与业务权限变更的一致性。会话保持部署简单，却会增加实例故障与扩缩容时的处理成本。

安全边界

使用足够随机的 Session ID、HTTPS、Secure、HttpOnly 和合理的 SameSite 属性。Session ID 往往是持有即授权的凭据，不能写入可泄露的 URL 或普通日志。服务端仍须逐请求校验资源权限，不能因为找到一个 Session 就允许全部操作。

面试时可以总结为：Session 把会话数据放在服务端，用 Session ID 将请求关联起来。Cookie 是常见的标识传递方式；真正的管理难点在于标识保护、登录轮换、过期失效和多实例共享。

可能追问的问题

浏览器关闭后，服务端 Session 会立即删除吗？
退出登录为什么不能只删除 Cookie？
登录成功后为什么需要更换 Session ID？
Redis Session 共享与负载均衡会话保持有什么取舍？

面试题剖析

本题要求比较 Cookie 与 Session 的职责、保存位置、生命周期和安全性，并解释它们经常配合使用。不能将二者视为同层次的互斥方案，也不能把 Token 一概等同于无状态。

面试题解答

Cookie 和 Session 的联系

Cookie 和 Session 经常配合工作，完整过程如下：

用户登录

→ 服务器验证账号和密码

→ 服务器创建 Session

→ 服务器生成 Session ID

→ 通过 Set-Cookie 返回 Session ID

→ 浏览器保存 Session ID

→ 后续请求自动携带 Session ID

→ 服务器根据 Session ID 查询 Session

→ 确认用户身份

因此，Cookie 和 Session 并不是相互替代的关系。常见的 Session 机制本身就依赖 Cookie 传递 Session ID：

Cookie 保存 Session ID

服务器保存 Session 数据

完整的会话管理

如果浏览器禁用了 Cookie，也可以通过 URL 重写等方式传递 Session ID：

https://www.example.com/orders;jsessionid=a1b2c3d4

但是 Session ID 出现在 URL 中，可能被浏览器历史记录、服务器日志等保存，容易造成泄漏，实际开发中通常不推荐这种方式。

Cookie 和 Session 的核心区别

生命周期的区别

Cookie 的有效期由 Cookie 属性控制：

没有设置 Expires 或 Max-Age：通常是会话 Cookie。
设置了 Expires 或 Max-Age：可以在浏览器关闭后继续保存。
用户也可以主动清除 Cookie。

Session 的有效期由服务器控制：

长时间没有访问，超过空闲超时时间。
用户退出登录，服务器主动销毁 Session。
服务器重启且 Session 没有持久化。
Session 被后台清理。

浏览器关闭后，会话 Cookie 可能消失，但服务器中的 Session 不一定立即删除，通常需要等待服务器超时清理。

安全性的区别

Session 数据保存在服务器端，重要数据不会直接暴露给客户端，因此通常比直接把业务数据保存在 Cookie 中更容易控制。

但这并不代表 Session 绝对安全。Session ID 相当于用户的临时身份凭证，如果攻击者获得有效的 Session ID，仍然可以冒充用户。

常见安全措施包括：

Set-Cookie: JSESSIONID=a1b2c3d4; Secure; HttpOnly; SameSite=Lax

Secure：只通过 HTTPS 发送 Cookie。
HttpOnly：禁止 JavaScript 直接读取 Cookie。
SameSite：限制跨站请求携带 Cookie，降低 CSRF 风险。
登录成功后重新生成 Session ID，防止 Session 固定攻击。
退出登录后立即让服务器端 Session 失效。
设置合理的 Session 超时时间。

另外，不应该直接在 Cookie 中保存密码、银行卡号等敏感信息。即使 Cookie 中的数据经过签名，签名通常只能防止篡改，并不等于数据已经加密。

分布式系统中的 Session

单机系统可以将 Session 保存在服务器内存中，但分布式系统中，请求可能被发送到不同服务器：

第一次请求 → 服务器 A 创建 Session

第二次请求 → 服务器 B 找不到 Session

常见的解决方式包括：

使用 Redis 等共享存储保存 Session。
使用负载均衡的会话保持，将同一用户请求发送给同一服务器。
使用自包含 Token 等方案减少集中查询；吊销、退出登录和权限更新仍需要额外设计。

面试时可以总结为：

Cookie 保存在客户端，Session 通常保存在服务器端。Cookie 适合保存少量用户状态或标识，而 Session 适合保存登录状态、权限等服务端会话数据。两者通常配合使用：服务器创建 Session 并生成 Session ID，通过 Cookie 将 Session ID 返回给浏览器；浏览器后续请求自动携带该 Session ID，服务器再根据它查找对应的 Session。Session 数据虽然不直接暴露给客户端，但 Session ID 一旦被窃取仍可能造成会话劫持，因此需要配合 HTTPS、Secure、HttpOnly、SameSite 和超时失效等安全措施。

可能追问的问题

如果浏览器禁用 Cookie，如何传递会话标识，有什么风险？
分布式系统如何解决 Session 共享问题？
Cookie、Session、Token 和 JWT 是什么关系？
服务端会话失效后，旧 Cookie 为什么不能继续使用？

继续阅读

上一章：OSI、TCP/IP 与 REST API 校招面试题
下一章：IP、MAC 与数据传输校招面试题

阅读导航

返回计算机网络目录