应用层

在浏览器中输入一个 URL 并按下回车，直到页面显示出来，中间经历了哪些完整的网络过程？

参考：当你输入一个网址的时候，实际会发生什么?

HTTP/1.0、HTTP/1.1、HTTP/2.0 和 HTTP/3.0 各有什么主要的演进和区别？

• HTTP/1.0：发布于 1996 年 5 月，只支持短连接，每次请求都要建立一次tcp连接。

• HTTP/1.1：发布于 1997 年 1 月，支持长连接（Keep-Alive），在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟。同时支持断点续传（Range字段）。

• HTTP/2.0：发布于 2015 年 5 月，支持二进制分帧、多路复用、头部压缩（HPACK）等，在传输机制上有革命性的优化。

• HTTP/3.0：发布于 2022 年 6 月，底层彻底抛弃了 TCP ，从而解决 TCP 队头阻塞的问题。改用基于 UDP 的 QUIC 协议，在应用层做可靠性保障，QUIC 使用一个唯一的 Connection ID 来标识连接，即使网络切换（如从wifi切换到5G），只要 ID 不变，连接就能无缝保持。

常见的 HTTP 状态码有哪些？

• 200 OK: 表示请求成功
• 301 Moved Permanently: 重定向转移
• 400 Bad request： 请求不能被服务器理解
• 403 Forbidden：服务器端有能力处理该请求，但是拒绝授权访问
• 404 Not Found： 请求的对象在服务器上找不到
• 500 Internal Server Error：服务器已收到请求，但服务器内部出错导致无法响应
• 502 Bad Gateway：网关从上游服务器中接收到的响应是无效的

HTTPS 是如何保证数据安全的？

参考：安全的 http 协议： https

Cookie、Session 和 Token 有什么区别？

HTTP 协议是无状态的，本质上，这三种技术都是为了解决“记住用户是谁”这一问题。

Cookie

Cookie 本质是存储在浏览器的一个字符串，在用户首次访问网页时，服务器会在 Response Header 中包含 Set-Cookie 字段，之后，用户浏览器会把这个字段存储起来，之后每次访问都会带上它。Cookie 由浏览器自动管理和发送。

Cookie存在的问题：数据以明文（或简单编码）存在客户端，容易被篡改或发生跨站脚本攻击（XSS）和跨站请求伪造（CSRF）。

Session

用户登录成功后，服务器会在自己的内存或数据库中创建一个 Session，并生成一个唯一的 Session ID。服务器把这个 Session ID 通过 Cookie 发送给浏览器。用户再次请求时，浏览器会带上包含 Session ID 的 Cookie，服务器通过对比 ID 找到对应的档案，从而认出用户。

Session 存在的问题：集群服务器下，需要引入 Redis 作为共享存储。

Token

最常见的 Token 是 JWT（JSON Web Token），它是一种数字令牌。用户登录成功后，服务器会根据用户信息生成一串包含数据的字符串（Token），并用服务器的密钥为其签名，然后发给客户端。客户端将其存起来（通常放在 localStorage 或 sessionStorage，也可以是存在 Cookie 里）。以后每次请求，客户端都需要手动将 Token 放在 HTTP 头的 Authorization 字段中发给服务器。服务器收到后，只需用密钥验证签名是否被篡改过，无需去数据库里查档案。常用于前后端分离项目、单点登录（SSO）、RESTful API 认证。

Token 存在的问题：一旦 Token 签发，在过期之前它都是有效的。如果想在服务端主动让其失效，需要引入额外的黑名单机制。

对于大型互联网平台与安全要求高的网站，常采用双 Token 机制（Access Token + Refresh Token）：

• Access Token（访问令牌）： 寿命极短（例如 15 分钟），放在前端每次请求时携带。即使被黑客截获，也很快作废。
• Refresh Token（刷新令牌）： 寿命较长（例如 7 天），保存在 HTTP-Only 的 Cookie 或服务端。当短令牌过期时，前端默默用长令牌去向服务器换取新的短令牌。