📚 前端题库

Question 1

**What is HTTP? What is its role in web development?**
- *考察点：基础概念理解。*

Answer

What is HTTP? What is its role in web development?

考察点：基础概念理解。

答案：

HTTP（HyperText Transfer Protocol，超文本传输协议）是一种用于客户端和服务器之间传输数据的应用层协议。它是Web通信的基础，规定了浏览器与服务器之间请求和响应的格式。HTTP采用无状态、请求-响应的工作模式，支持文本、图片、视频等多种数据类型的传输。

在Web开发中的作用：

浏览器与服务器之间的数据交换桥梁
支持网页内容的加载与交互
规范了请求方法、消息结构、状态码等通信细节
为前端与后端系统集成提供标准接口

协议特点：

简单快速：客户向服务器请求服务时，只需传送请求方法和路径
灵活：允许传输任意类型的数据对象
无连接：限制每次连接只处理一个请求
无状态：对于事务处理没有记忆能力

Question 2

**What are the differences between HTTP and HTTPS? How does HTTPS ensure security?**
- *考察点：安全协议基础。*

Answer

What are the differences between HTTP and HTTPS? How does HTTPS ensure security?

考察点：安全协议基础。

答案：

HTTP和HTTPS的主要区别在于安全性和传输方式：

主要区别：

安全性：HTTP是明文传输，HTTPS是加密传输
端口：HTTP使用80端口，HTTPS使用443端口
证书：HTTPS需要SSL证书，HTTP不需要
性能：HTTPS因加密解密会消耗更多资源

HTTPS如何保证安全：

加密传输：通过SSL/TLS协议对数据进行加密，防止窃听
身份验证：使用数字证书验证服务器身份，防止伪造
数据完整性：通过消息摘要算法确保数据未被篡改
防重放攻击：通过时间戳和随机数防止重放攻击

HTTPS工作原理：

客户端发起HTTPS请求
服务器返回数字证书
客户端验证证书合法性
双方协商加密算法并建立安全连接
后续通信全程加密

Question 3

**What are the common HTTP request methods? What are the differences between GET and POST?**
- *考察点：请求方法差异。*

Answer

What are the common HTTP request methods? What are the differences between GET and POST?

考察点：请求方法差异。

答案：

常用HTTP请求方法：

GET：获取资源，请求指定页面信息
POST：提交数据，向指定资源提交数据进行处理
PUT：更新资源，上传文件或更新数据
DELETE：删除指定资源
HEAD：获取报头，类似GET但只返回响应头
PATCH：部分更新资源
OPTIONS：获取服务器支持的HTTP方法

GET和POST的区别：

特性	GET	POST
数据位置	URL参数	请求体
数据长度	受URL长度限制(约2KB)	无限制
安全性	参数暴露在URL	相对安全
缓存	可缓存	不可缓存
幂等性	幂等	非幂等
书签	可收藏	不可收藏
后退/刷新	无副作用	数据会重新提交

使用场景：

GET：查询数据、获取资源
POST：提交表单、上传文件、创建资源

Question 4

**What are the differences between PUT and POST request methods? What scenarios are they used for?**
- *考察点：请求方法选择。*

Answer

What are the differences between PUT and POST request methods? What scenarios are they used for?

考察点：请求方法选择。

答案：

PUT和POST是两种不同用途的HTTP请求方法：

主要区别：

特性	PUT	POST
用途	更新/替换整个资源	创建资源或提交数据
幂等性	幂等（多次执行结果相同）	非幂等（多次执行可能产生不同结果）
资源定位	URL指向具体资源	URL指向资源集合
语义	完全替换	追加或处理

PUT特点：

如果资源不存在则创建，存在则完全替换
客户端指定资源的完整URI
多次执行相同PUT请求效果相同
要求客户端提供完整的资源表示

POST特点：

主要用于创建新资源或提交数据处理
服务器决定新资源的URI
每次执行可能产生不同效果
可以提交部分数据

使用场景：

PUT：更新用户信息、替换配置文件、上传指定文件
POST：用户注册、订单提交、文件上传、搜索请求

RESTful API中的应用：

PUT /users/123：更新ID为123的用户
POST /users：创建新用户

Question 5

**What are the classifications of HTTP status codes? What are the common status codes?**
- *考察点：状态码分类理解。*

Answer

What are the classifications of HTTP status codes? What are the common status codes?

考察点：状态码分类理解。

答案：

HTTP状态码是三位数字，用于表示服务器对请求的处理结果。按首位数字分为五大类：

状态码分类：

1xx（信息性状态码）：接收的请求正在处理
2xx（成功状态码）：请求正常处理完毕
3xx（重定向状态码）：需要进行附加操作以完成请求
4xx（客户端错误状态码）：客户端请求有误
5xx（服务器错误状态码）：服务器处理请求出错

常见状态码：

成功类（2xx）：

200 OK：请求成功
201 Created：资源创建成功
204 No Content：请求成功但无返回内容

重定向类（3xx）：

301 Moved Permanently：永久重定向
302 Found：临时重定向
304 Not Modified：资源未修改

客户端错误类（4xx）：

400 Bad Request：请求语法错误
401 Unauthorized：需要身份验证
403 Forbidden：服务器拒绝请求
404 Not Found：资源不存在

服务器错误类（5xx）：

500 Internal Server Error：服务器内部错误
502 Bad Gateway：网关错误
503 Service Unavailable：服务不可用

Question 6

**What do 2xx, 3xx, 4xx, 5xx status codes mean respectively?**
- *考察点：状态码含义区分。*

Answer

What do 2xx, 3xx, 4xx, 5xx status codes mean respectively?

考察点：状态码含义区分。

答案：

各类状态码的详细含义：

2xx 成功状态码：

表示请求被服务器正确理解并成功处理
客户端的请求已被接受、理解和处理
常见：200（成功）、201（已创建）、204（无内容）

3xx 重定向状态码：

表示需要客户端采取进一步的操作才能完成请求
通常用于URL重定向，资源位置发生变化
客户端需要执行额外的操作来完成请求
常见：301（永久重定向）、302（临时重定向）、304（未修改）

4xx 客户端错误状态码：

表示客户端提交的请求有错误
请求包含语法错误或无法完成请求
服务器无法处理客户端的请求
常见：400（请求错误）、401（未授权）、403（禁止访问）、404（未找到）

5xx 服务器错误状态码：

表示服务器在处理请求的过程中发生了错误
服务器遇到错误或异常情况无法完成请求
通常是服务器端程序错误或系统故障
常见：500（内部错误）、502（网关错误）、503（服务不可用）

状态码的作用：

帮助客户端了解请求处理结果
指导客户端下一步操作
便于调试和错误处理

Question 7

**What are the differences between 301 and 302 redirects? When to use them?**
- *考察点：重定向类型理解。*

Answer

What are the differences between 301 and 302 redirects? When to use them?

考察点：重定向类型理解。

答案：

301和302都是HTTP重定向状态码，但含义和使用场景不同：

主要区别：

特性	301 Moved Permanently	302 Found
重定向类型	永久重定向	临时重定向
搜索引擎处理	传递权重到新URL	保持原URL权重
浏览器缓存	会缓存重定向	通常不缓存
原URL状态	被新URL永久替代	原URL仍然有效

301永久重定向使用场景：

网站域名变更（如从HTTP迁移到HTTPS）
页面URL结构调整且不会再改回
网站重构后的永久性页面迁移
多个域名指向同一网站的主域名
删除重复内容，合并相似页面

302临时重定向使用场景：

网站临时维护，跳转到维护页面
用户未登录时跳转到登录页面
A/B测试中的临时页面跳转
临时的促销活动页面
根据用户地理位置或语言的临时跳转

SEO影响：

301：搜索引擎会更新索引，权重传递给新URL
302：搜索引擎保持原URL索引，不传递权重

技术实现：

HTTP/1.1 301 Moved Permanently
Location: https://new-url.com

HTTP/1.1 302 Found  
Location: https://temp-url.com

Question 8

**What is the basic structure of HTTP requests and responses?**
- *考察点：消息结构组成。*

Answer

What is the basic structure of HTTP requests and responses?

考察点：消息结构组成。

答案：

HTTP消息分为请求消息和响应消息，都遵循相似的结构：

HTTP请求结构：

请求行（Request Line）
请求头（Request Headers）
空行（Blank Line）
请求体（Request Body，可选）

请求示例：

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml
Connection: keep-alive

[请求体数据]

HTTP响应结构：

状态行（Status Line）
响应头（Response Headers）
空行（Blank Line）
响应体（Response Body，可选）

响应示例：

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
Server: Apache/2.4.1

<!DOCTYPE html>
<html>...

各部分说明：

请求行/状态行：包含方法、URL、协议版本或状态码
头部字段：包含请求/响应的元数据信息
空行：分隔头部和主体的必需分界线
消息体：实际传输的数据内容（可选）

特点：

文本格式，人类可读
头部字段采用键值对形式
每行以CRLF（\r\n）结束
头部与主体间必须有空行分隔

Question 9

**What are HTTP request headers? What are the common request headers?**
- *考察点：请求头字段作用。*

Answer

What are HTTP request headers? What are the common request headers?

考察点：请求头字段作用。

答案：

HTTP请求头是客户端发送给服务器的附加信息，用于描述请求的特性和客户端的能力。

请求头的作用：

提供请求的上下文信息
指定客户端能够接受的内容类型
传递认证信息和会话状态
控制缓存和连接行为

常见请求头：

基础信息类：

Host：请求的目标主机和端口号
User-Agent：客户端软件信息
Referer：请求来源页面URL

内容协商类：

Accept：客户端能够接受的内容类型
Accept-Language：客户端接受的语言
Accept-Encoding：客户端支持的编码格式
Accept-Charset：客户端接受的字符集

缓存控制类：

Cache-Control：缓存控制指令
If-Modified-Since：条件请求，检查资源是否修改
If-None-Match：ETag条件验证

连接管理类：

Connection：连接管理（keep-alive/close）
Content-Length：请求体长度
Content-Type：请求体的媒体类型

认证授权类：

Authorization：身份认证信息
Cookie：会话标识和状态信息

自定义头部：

X-Requested-With：标识AJAX请求
X-Forwarded-For：原始客户端IP（代理环境）

Question 10

**What are HTTP response headers? What are the common response headers?**
- *考察点：响应头字段作用。*

Answer

What are HTTP response headers? What are the common response headers?

考察点：响应头字段作用。

答案：

HTTP响应头是服务器发送给客户端的元数据信息，用于描述响应内容的特征和服务器的状态。

响应头的作用：

描述响应内容的类型和编码
控制客户端的缓存行为
设置安全策略和CORS规则
传递服务器状态信息

常见响应头：

内容描述类：

Content-Type：响应体的媒体类型
Content-Length：响应体的字节长度
Content-Encoding：响应体的编码方式（gzip、deflate）
Content-Language：响应体的语言

缓存控制类：

Cache-Control：缓存控制策略
Expires：响应过期时间
ETag：资源标识符，用于缓存验证
Last-Modified：资源最后修改时间

服务器信息类：

Server：服务器软件信息
Date：响应生成时间
Location：重定向目标URL

安全相关类：

Set-Cookie：设置客户端Cookie
Access-Control-Allow-Origin：CORS跨域策略
X-Frame-Options：防止页面被嵌入frame
X-Content-Type-Options：防止MIME类型嗅探攻击

连接管理类：

Connection：连接状态控制
Transfer-Encoding：传输编码方式（chunked）

自定义头部：

X-Powered-By：技术栈信息
X-RateLimit-*：API限流信息

Question 11

**What is the role of the User-Agent request header?**
- *考察点：请求头具体应用。*

Answer

What is the role of the User-Agent request header?

考察点：请求头具体应用。

答案：

User-Agent是HTTP请求头中的重要字段，用于标识发起请求的客户端软件信息。

User-Agent的作用：

客户端识别：告知服务器请求来自什么设备和浏览器
内容适配：服务器根据客户端类型返回适配的内容
统计分析：帮助网站了解访客的技术环境
兼容性处理：针对不同浏览器提供兼容性方案

典型User-Agent示例：

// Chrome浏览器
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36

// Firefox浏览器
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

// 移动端Safari
Mozilla/5.0 (iPhone; CPU iPhone OS 14_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.1 Mobile/15E148 Safari/604.1

// 爬虫工具
curl/7.68.0
Googlebot/2.1

应用场景：

响应式设计：根据设备类型返回PC版或移动版页面
功能降级：为老版本浏览器提供兼容性支持
反爬虫：识别和阻止恶意爬虫访问
数据统计：分析用户的浏览器和操作系统分布
安全防护：检测可疑的访问行为

注意事项：

User-Agent可以被客户端伪造
不应完全依赖User-Agent进行安全验证
需要考虑隐私保护，避免过度收集用户信息

Question 12

**What are URL and URI? What are the differences between them?**
- *考察点：地址标识概念。*

Answer

What are URL and URI? What are the differences between them?

考察点：地址标识概念。

答案：

URI和URL都是用于标识网络资源的字符串，但概念范围不同：

URI（Uniform Resource Identifier，统一资源标识符）：

是一个更广泛的概念，用于唯一标识资源
包括两个子集：URL和URN
语法：scheme:[//authority]path[?query][#fragment]

URL（Uniform Resource Locator，统一资源定位符）：

是URI的一个子集，不仅标识资源还指明获取资源的方法
必须包含访问资源的具体位置和方法
语法：scheme://host[:port]/path[?query][#fragment]

主要区别：

特性	URI	URL
范围	更广泛的概念	URI的子集
作用	标识资源	标识并定位资源
访问方式	不一定包含访问方法	必须包含访问方法
示例	`urn:isbn:0451450523`	`https://example.com/page`

关系图：

URI
├── URL (定位符)
│   ├── http://example.com/page
│   └── ftp://ftp.example.com/file
└── URN (名称)
    └── urn:isbn:0451450523

实际应用：

日常开发中常说的"URL"大多指Web地址
RESTful API设计中更多使用"URI"概念
URL是URI在Web环境下的具体实现

记忆技巧：

URL = 统一资源定位符（告诉你资源在哪里以及如何获取）
URI = 统一资源标识符（只需要能唯一标识资源即可）

Question 13

**What are the components of a URL? What is the role of each part?**
- *考察点：URL结构解析。*

Answer

What are the components of a URL? What is the role of each part?

考察点：URL结构解析。

答案：

URL的标准格式为：scheme://[userinfo@]host[:port]/path[?query][#fragment]

URL组成部分详解：

示例URL：
https://user:[email protected]:443/path/to/page?id=123&name=test#section1

各部分说明：

Scheme（协议）：https
- 指定访问资源的协议
- 常见：http、https、ftp、file、mailto
Userinfo（用户信息）：user:pass@（可选）
- 包含用户名和密码
- 现代应用中很少使用，安全性差
Host（主机）：www.example.com
- 服务器的域名或IP地址
- 必需组件，标识资源所在服务器
Port（端口）：443（可选）
- 服务器监听的端口号
- 默认端口：HTTP(80)、HTTPS(443)
Path（路径）：/path/to/page
- 服务器上资源的具体路径
- 以"/"分隔的层级结构
Query（查询参数）：?id=123&name=test（可选）
- 传递给服务器的参数
- 以"?“开始，”&"分隔多个参数
Fragment（片段标识符）：#section1（可选）
- 指向页面内的特定位置
- 仅在客户端使用，不发送给服务器

各部分作用总结：

协议+主机+端口：确定目标服务器
路径：定位服务器上的具体资源
查询参数：传递动态数据
片段：页面内导航定位

编码规则：

特殊字符需要进行URL编码（%编码）
空格编码为%20或+
中文字符需要UTF-8编码

Question 14

**What is Cookie? What is the role of Cookie?**
- *考察点：会话管理基础。*

Answer

What is Cookie? What is the role of Cookie?

考察点：会话管理基础。

答案：

Cookie是一种在用户浏览器中存储少量数据的机制，用于在HTTP无状态协议中维持状态信息。

Cookie的定义：

服务器发送给浏览器并存储在本地的小型文本文件
后续请求时浏览器会自动携带相关Cookie发送给服务器
通过HTTP头部的Set-Cookie和Cookie字段进行传输

Cookie的作用：

会话管理：
- 用户登录状态保持
- 购物车内容记录
- 游戏进度保存
个性化设置：
- 用户偏好设置（语言、主题）
- 自定义界面配置
- 地理位置信息
行为追踪：
- 用户行为分析
- 广告推荐优化
- 网站使用统计

Cookie属性：

Name=Value：Cookie的名称和值
Domain：Cookie的有效域名
Path：Cookie的有效路径
Expires/Max-Age：Cookie的过期时间
Secure：只在HTTPS连接中传输
HttpOnly：防止JavaScript访问
SameSite：防止CSRF攻击

Cookie示例：

Set-Cookie: sessionId=abc123; Domain=example.com; Path=/; Expires=Wed, 21 Oct 2024 07:28:00 GMT; Secure; HttpOnly

限制：

大小限制：每个Cookie最大4KB
数量限制：每个域名最多几十个Cookie
安全风险：可能被XSS攻击利用
隐私问题：可能泄露用户信息

Question 15

**What are the differences between Cookie and Session?**
- *考察点：会话存储方式。*

Answer

What are the differences between Cookie and Session?

考察点：会话存储方式。

答案：

Cookie和Session都是Web应用中维持用户状态的技术，但实现方式和特点不同：

主要区别对比：

特性	Cookie	Session
存储位置	客户端浏览器	服务器端
存储容量	4KB限制	无明确限制
安全性	相对较低	相对较高
网络传输	每次请求都传输	只传输Session ID
生命周期	可设置长期有效	通常随会话结束而失效
性能影响	占用带宽	占用服务器内存

Cookie特点：

数据存储在客户端，减轻服务器压力
可以设置较长的过期时间
存在被篡改和窃取的风险
受浏览器设置影响（可被禁用）

Session特点：

数据存储在服务器，安全性更高
可以存储复杂的数据类型和大量数据
依赖Cookie传输Session ID（通常）
占用服务器内存，需要考虑存储和清理

工作原理：

Cookie机制：

1. 服务器通过Set-Cookie响应头设置Cookie
2. 浏览器自动存储Cookie
3. 后续请求自动携带Cookie

Session机制：

1. 服务器创建Session并生成Session ID
2. 通过Cookie将Session ID发送给客户端
3. 客户端请求时携带Session ID
4. 服务器根据Session ID查找对应Session数据

实际应用：

Cookie：记住登录状态、用户偏好设置
Session：存储敏感信息、复杂的用户状态

最佳实践：

敏感信息使用Session存储
简单状态信息可使用Cookie
两者结合使用以平衡安全性和性能

Question 16

**HTTP is a stateless protocol, what does this mean?**
- *考察点：协议特性理解。*

Answer

HTTP is a stateless protocol, what does this mean?

考察点：协议特性理解。

答案：

HTTP无状态协议是指服务器不保留客户端请求之间的任何状态信息，每个请求都是独立的。

无状态的含义：

请求独立性：每个HTTP请求都是完全独立的，服务器不记住之前的请求
无记忆能力：服务器不保存客户端的历史信息和上下文
事务隔离：每次请求-响应构成一个完整的事务，互不影响

具体表现：

服务器不知道当前请求来自哪个用户
服务器不记住用户的操作历史
每次请求都需要重新提供身份验证信息
服务器处理完请求后立即"忘记"这次交互

无状态的优势：

简化设计：
- 服务器实现更简单
- 减少了状态管理的复杂性
- 降低了系统设计难度
提高性能：
- 服务器不需要维护连接状态
- 减少内存占用
- 提高并发处理能力
增强可靠性：
- 服务器崩溃不会影响客户端状态
- 容易实现故障恢复
- 支持负载均衡和集群部署
良好的可扩展性：
- 易于水平扩展
- 任意服务器都可处理任意请求
- 支持分布式部署

无状态的缺陷：

无法直接实现用户会话
需要额外机制维持状态（Cookie、Session）
每次请求可能需要重复传输相同信息

解决方案：

使用Cookie保持客户端状态
通过Session在服务端维护用户状态
使用Token进行身份验证
在请求中携带状态信息

Question 17

**What is Content-Type? What are the common Content-Types?**
- *考察点：内容类型标识。*

Answer

What is Content-Type? What are the common Content-Types?

考察点：内容类型标识。

答案：

Content-Type是HTTP头部字段，用于指示资源的媒体类型（MIME类型），告诉接收方如何解析和处理传输的内容。

Content-Type的作用：

指定数据格式：告诉接收方数据的具体格式
正确解析：帮助客户端或服务器正确解析内容
安全防护：防止文件类型伪装攻击
内容协商：支持多种格式的内容协商

语法格式：

Content-Type: media-type[; charset=encoding][; boundary=string]

常见Content-Type类型：

文本类型：

text/plain：纯文本
text/html：HTML文档
text/css：CSS样式表
text/javascript：JavaScript代码

应用程序类型：

application/json：JSON数据格式
application/xml：XML文档
application/pdf：PDF文件
application/zip：ZIP压缩文件
application/x-www-form-urlencoded：表单数据（默认）

图像类型：

image/jpeg：JPEG图片
image/png：PNG图片
image/gif：GIF动画
image/svg+xml：SVG矢量图

多媒体类型：

audio/mpeg：MP3音频
video/mp4：MP4视频
audio/wav：WAV音频

多部分类型：

multipart/form-data：文件上传表单
multipart/mixed：混合内容

实际应用示例：

// JSON API响应
Content-Type: application/json; charset=utf-8

// HTML页面
Content-Type: text/html; charset=utf-8

// 文件上传
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

// 表单提交
Content-Type: application/x-www-form-urlencoded

注意事项：

设置正确的Content-Type对Web安全很重要
浏览器会根据Content-Type决定如何处理响应
错误的Content-Type可能导致内容无法正确显示

Question 18

**What are the differences between query parameters and request body in HTTP requests?**
- *考察点：数据传输方式。*

Answer

What are the differences between query parameters and request body in HTTP requests?

考察点：数据传输方式。

答案：

查询参数和请求体是HTTP请求中传输数据的两种不同方式，各有特点和适用场景。

主要区别对比：

特性	查询参数（Query Parameters）	请求体（Request Body）
位置	URL中，?后面	HTTP消息体中
可见性	完全可见	相对隐蔽
长度限制	受URL长度限制（2KB左右）	无明确限制
缓存	可被缓存	通常不缓存
历史记录	会保存在浏览器历史	不会保存
书签	可以收藏	无法收藏
日志记录	会被服务器日志记录	不会被记录

查询参数特点：

GET /search?q=javascript&page=1&limit=10 HTTP/1.1

优点：

简单直观，易于理解和调试
支持浏览器书签和分享
RESTful API中用于过滤和分页

缺点：

长度受限，不适合大量数据
参数暴露在URL中，安全性较低
特殊字符需要编码

请求体特点：

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

{"name": "John", "email": "[email protected]"}

优点：

可传输大量数据
支持复杂数据结构（JSON、XML等）
相对安全，不会暴露在URL中

缺点：

不能被浏览器直接缓存
调试相对复杂
无法通过URL分享

使用场景：

查询参数适用于：

GET请求的过滤条件
分页参数（page, limit）
排序参数（sort, order）
搜索关键词
简单的配置选项

请求体适用于：

POST/PUT请求的数据提交
文件上传
复杂的JSON/XML数据
敏感信息传输
大量数据传输

最佳实践：

GET请求使用查询参数
POST/PUT请求使用请求体
敏感数据放在请求体中
简单过滤条件可用查询参数

Question 19

**What is the workflow of HTTP? What steps are involved from entering a URL to page display?**
- *考察点：协议工作原理。*

Answer

What is the workflow of HTTP? What steps are involved from entering a URL to page display?

考察点：协议工作原理。

答案：

从输入URL到页面显示是一个复杂的过程，涉及多个网络层和组件的协作。

详细步骤：

1. URL解析

浏览器解析输入的URL
提取协议、域名、端口、路径等信息
检查URL格式的合法性

2. DNS解析

检查浏览器DNS缓存
检查操作系统DNS缓存
向DNS服务器查询域名对应的IP地址
获得服务器IP地址

3. 建立TCP连接

浏览器与服务器进行三次握手
建立可靠的TCP连接
如果是HTTPS，还需要进行TLS握手

4. 发送HTTP请求

构造HTTP请求报文
包含请求行、请求头、请求体
通过TCP连接发送给服务器

5. 服务器处理请求

服务器接收并解析HTTP请求
根据请求路径和方法处理业务逻辑
生成响应数据

6. 返回HTTP响应

构造HTTP响应报文
包含状态行、响应头、响应体
通过TCP连接返回给浏览器

7. 浏览器接收响应

接收HTTP响应数据
解析响应头信息
根据Content-Type处理响应体

8. 渲染页面

解析HTML构建DOM树
解析CSS构建样式树
执行JavaScript代码
渲染页面并显示给用户

9. 资源加载

加载页面中的图片、CSS、JS等资源
可能并发发起多个HTTP请求
逐步完善页面显示效果

10. 关闭连接

根据Connection头决定是否保持连接
可能立即关闭或复用连接

性能优化点：

DNS预解析和缓存
TCP连接复用（Keep-Alive）
资源压缩和缓存
CDN加速
HTTP/2多路复用

Question 20

**What is HTTP Keep-Alive? What problems does it solve?**
- *考察点：连接复用机制。*

Answer

What is HTTP Keep-Alive? What problems does it solve?

考察点：连接复用机制。

答案：

HTTP Keep-Alive（持久连接）是一种连接复用机制，允许在单个TCP连接上发送多个HTTP请求和响应。

Keep-Alive的原理：

在HTTP/1.0中需要显式指定：Connection: keep-alive
在HTTP/1.1中默认启用持久连接
服务器和客户端都可以主动关闭连接

解决的问题：

1. 减少连接开销

传统方式：每个请求都需要新建TCP连接
GET /page1 -> 建立连接 -> 传输 -> 关闭连接
GET /page2 -> 建立连接 -> 传输 -> 关闭连接

Keep-Alive方式：复用同一个连接
GET /page1 -> 建立连接 -> 传输
GET /page2 -> 复用连接 -> 传输 -> 保持连接

2. 提升性能

避免重复的TCP三次握手和四次挥手
减少网络延迟和CPU消耗
特别适用于加载多个小资源的场景

3. 降低服务器负载

减少服务器的连接数
降低系统资源消耗
提高并发处理能力

Keep-Alive配置参数：

Connection: keep-alive
Keep-Alive: timeout=5, max=100

timeout：连接空闲超时时间（秒）
max：连接最大请求数

工作流程：

客户端发送带有Connection: keep-alive的请求
服务器响应也包含Connection: keep-alive
连接保持打开状态
后续请求复用该连接
达到超时时间或最大请求数后关闭

优势：

显著提升页面加载速度
减少网络拥塞
改善用户体验
节省带宽和系统资源

局限性：

长时间空闲连接占用服务器资源
需要合理配置超时时间
在高并发场景下需要注意连接池管理

实际应用：

现代浏览器默认启用
Web服务器（如Nginx、Apache）支持配置
CDN和负载均衡器中广泛使用

Question 21

**How does HTTP caching mechanism work? What are the differences between strong cache and negotiated cache?**
- *考察点：缓存策略理解。*

Answer

How does HTTP caching mechanism work? What are the differences between strong cache and negotiated cache?

考察点：缓存策略理解。

答案：

HTTP缓存是提升Web性能的重要机制，通过在客户端存储资源副本来减少网络请求和服务器负载。

HTTP缓存工作流程：

浏览器发起资源请求
检查本地缓存是否存在且有效
如果缓存有效，直接使用（强缓存）
如果缓存过期，向服务器验证（协商缓存）
服务器返回304（未修改）或200（新内容）

强缓存 vs 协商缓存：

强缓存（Strong Cache）：

特点：不向服务器发送请求，直接使用本地缓存
控制头部：Cache-Control、Expires
状态码：200（from cache）
性能：最快，完全避免网络请求

Cache-Control: max-age=3600  // 缓存1小时
Expires: Wed, 21 Oct 2024 07:28:00 GMT

协商缓存（Negotiated Cache）：

特点：向服务器验证缓存是否有效
控制头部：ETag/If-None-Match、Last-Modified/If-Modified-Since
状态码：304（Not Modified）或200（新内容）
性能：需要网络请求但节省带宽

// 服务器响应
ETag: "abc123"
Last-Modified: Wed, 20 Oct 2024 07:28:00 GMT

// 客户端请求
If-None-Match: "abc123"
If-Modified-Since: Wed, 20 Oct 2024 07:28:00 GMT

缓存决策流程：

请求资源
    ↓
检查强缓存
    ↓
有效？ ——是——→ 使用缓存（200 from cache）
    ↓否
检查协商缓存
    ↓
发送验证请求
    ↓
未修改？ ——是——→ 使用缓存（304 Not Modified）
    ↓否
下载新资源（200 OK）

缓存类型对比：

特性	强缓存	协商缓存
网络请求	无	有（验证请求）
服务器压力	最小	较小
实时性	较差	较好
带宽消耗	无	最小
适用场景	静态资源	可能变化的资源

实际应用策略：

静态资源（CSS、JS、图片）：使用强缓存，设置较长过期时间
HTML文件：使用协商缓存，确保内容更新
API数据：根据业务需求配置适当的缓存策略
版本化资源：文件名包含哈希值，可设置永久缓存

Question 22

**What are the differences between Cache-Control and Expires? How to configure caching strategies?**
- *考察点：缓存控制头部。*

Answer

What are the differences between Cache-Control and Expires? How to configure caching strategies?

考察点：缓存控制头部。

答案：

Cache-Control和Expires都是控制HTTP缓存的头部字段，但在功能和优先级上有重要区别。

主要区别对比：

特性	Cache-Control	Expires
HTTP版本	HTTP/1.1引入	HTTP/1.0引入
优先级	高（优先生效）	低
时间表示	相对时间（秒）	绝对时间
功能	更丰富的控制选项	仅指定过期时间
时钟依赖	不依赖客户端时钟	依赖客户端时钟

Cache-Control详解：

语法：

Cache-Control: <directive>[, <directive>]*

常用指令：

max-age=<seconds>：缓存最大时间
no-cache：需要验证缓存
no-store：禁止缓存
public：可被任何缓存存储
private：只能被浏览器缓存
must-revalidate：过期后必须验证

示例：

Cache-Control: max-age=3600, public
Cache-Control: no-cache, must-revalidate
Cache-Control: private, max-age=0

Expires详解：

语法：

Expires: <http-date>

示例：

Expires: Wed, 21 Oct 2024 07:28:00 GMT

缓存策略配置：

1. 静态资源（CSS、JS、图片）：

// 长期缓存
Cache-Control: public, max-age=31536000  // 1年
Expires: Wed, 21 Oct 2025 07:28:00 GMT

2. HTML文件：

// 禁用缓存或短期缓存
Cache-Control: no-cache, must-revalidate
Cache-Control: max-age=300  // 5分钟

3. API数据：

// 根据业务需求
Cache-Control: private, max-age=60  // 私有，1分钟
Cache-Control: no-store  // 敏感数据不缓存

4. 版本化资源：

// 永久缓存（文件名包含哈希）
Cache-Control: public, max-age=31536000, immutable

最佳实践：

缓存层次设计：

浏览器缓存：用户本地存储
CDN缓存：边缘节点缓存
代理缓存：企业网关缓存
服务器缓存：应用层缓存

配置建议：

优先使用Cache-Control（向后兼容可同时设置Expires）
静态资源设置长期缓存 + 文件指纹
动态内容使用协商缓存
敏感数据禁用缓存

常见配置模式：

// 强缓存 + 协商缓存
Cache-Control: max-age=3600
ETag: "abc123"
Last-Modified: Wed, 20 Oct 2024 07:28:00 GMT

// 仅协商缓存
Cache-Control: no-cache
ETag: "def456"

Question 23

**What are the roles of ETag and Last-Modified? How do they implement negotiated caching?**
- *考察点：缓存验证机制。*

Answer

What are the roles of ETag and Last-Modified? How do they implement negotiated caching?

考察点：缓存验证机制。

答案：

ETag和Last-Modified是HTTP协商缓存的两种验证机制，用于判断缓存资源是否仍然有效。

ETag（实体标签）：

资源的唯一标识符，通常是内容的哈希值或版本号
由服务器生成，客户端存储并在后续请求中使用
精确度更高，能检测到任何内容变化

Last-Modified（最后修改时间）：

资源的最后修改时间戳
精确度较低（秒级），可能存在时间同步问题
实现简单，服务器负载较小

协商缓存工作流程：

1. 首次请求：

// 客户端请求
GET /api/data HTTP/1.1

// 服务器响应
HTTP/1.1 200 OK
ETag: "abc123def"
Last-Modified: Wed, 20 Oct 2024 07:28:00 GMT
Content: {...}

2. 后续请求验证：

// 客户端验证请求
GET /api/data HTTP/1.1
If-None-Match: "abc123def"
If-Modified-Since: Wed, 20 Oct 2024 07:28:00 GMT

// 资源未修改 - 服务器响应
HTTP/1.1 304 Not Modified

// 资源已修改 - 服务器响应
HTTP/1.1 200 OK
ETag: "xyz789new"
Last-Modified: Wed, 21 Oct 2024 08:30:00 GMT
Content: {...}

对比分析：

特性	ETag	Last-Modified
精确度	高（基于内容）	低（基于时间）
性能开销	高（需计算哈希）	低（文件系统时间）
可靠性	高	受时钟同步影响
适用场景	内容频繁变化	文件修改场景

ETag生成策略：

// 强ETag（精确匹配）
ETag: "686897696a7c876b7e"

// 弱ETag（语义等价）
ETag: W/"686897696a7c876b7e"

实现协商缓存的机制：

ETag验证：

客户端发送 If-None-Match: "etag-value"
服务器比较当前资源ETag与请求中的值
相同返回304，不同返回200和新内容

Last-Modified验证：

客户端发送 If-Modified-Since: date
服务器比较资源修改时间与请求中的时间
未修改返回304，已修改返回200和新内容

优先级规则：

ETag优先级高于Last-Modified
如果都存在，ETag不匹配则认为资源已修改
只有ETag匹配且Last-Modified未修改才返回304

最佳实践：

同时使用ETag和Last-Modified提高兼容性
动态内容优先使用ETag
静态文件可只使用Last-Modified
根据资源特性选择强ETag或弱ETag

Question 24

**What is CORS? Why do cross-origin problems occur?**
- *考察点：跨域安全机制。*

Answer

What is CORS? Why do cross-origin problems occur?

考察点：跨域安全机制。

答案：

CORS（Cross-Origin Resource Sharing，跨源资源共享）是一种基于HTTP头部的机制，允许服务器标示除了它自己以外的其他源，浏览器应该允许加载来自这些源的资源。

跨域问题产生的原因：

同源策略限制：

浏览器的同源策略阻止从一个源加载的脚本获取或操作另一个源的资源
同源定义：协议、域名、端口三者完全相同
目的：防止恶意脚本访问敏感数据，保护用户安全

跨域场景示例：

当前页面：https://www.example.com:443
请求目标：
- http://www.example.com    ❌ 协议不同
- https://api.example.com   ❌ 域名不同  
- https://www.example.com:8080  ❌ 端口不同
- https://www.example.com/api   ✅ 同源

CORS工作原理：

简单请求：

方法：GET、POST、HEAD
头部：Accept、Accept-Language、Content-Language、Content-Type（限定值）
直接发送请求，服务器在响应中添加CORS头部

预检请求：

非简单请求会先发送OPTIONS请求
服务器返回允许的方法和头部
通过预检后发送实际请求

CORS头部字段：

服务器响应头：

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400

浏览器请求头（预检）：

Origin: https://example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

跨域问题的影响：

AJAX请求被阻止：无法获取跨域API数据
资源加载限制：某些资源无法跨域加载
Cookie限制：跨域请求默认不携带Cookie
DOM访问限制：无法操作跨域iframe内容

为什么需要跨域：

前后端分离架构中，前端和API服务通常部署在不同域名
微服务架构中，不同服务可能使用不同端口
CDN资源分发需要跨域访问
第三方API集成需求

Question 25

**How to solve CORS cross-origin problems? What are the solutions?**
- *考察点：跨域解决方法。*

Answer

How to solve CORS cross-origin problems? What are the solutions?

考察点：跨域解决方法。

答案：

跨域问题有多种解决方案，从服务器配置到代理转发，各有适用场景。

1. 服务器端CORS配置（推荐）：

// Node.js Express示例
app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', '*');
  res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');
  res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  next();
});

// Nginx配置
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE';

2. 代理转发：

开发环境：webpack devServer、Vite proxy
生产环境：Nginx反向代理

// webpack.config.js
devServer: {
  proxy: {
    '/api': {
      target: 'http://localhost:3000',
      changeOrigin: true
    }
  }
}

3. JSONP（仅支持GET）：

function jsonpRequest(url, callback) {
  const script = document.createElement('script');
  script.src = `${url}?callback=${callback}`;
  document.head.appendChild(script);
}

4. postMessage（跨域通信）：

// 发送方
window.parent.postMessage(data, 'https://target.com');

// 接收方
window.addEventListener('message', (event) => {
  if (event.origin === 'https://trusted.com') {
    console.log(event.data);
  }
});

5. 其他方案：

document.domain（子域名跨域）
window.name
location.hash
WebSocket（天然支持跨域）

Question 26

**What is the same-origin policy? What does it restrict?**
- *考察点：浏览器安全策略。*

Answer

What is the same-origin policy? What does it restrict?

考察点：浏览器安全策略。

答案：

同源策略是浏览器的重要安全机制，限制一个源加载的脚本如何与另一个源的资源进行交互。

同源定义： 协议、域名、端口完全相同

限制内容：

DOM访问限制：无法访问跨域iframe的DOM
AJAX请求限制：XMLHttpRequest和Fetch API受限
Cookie限制：无法访问跨域Cookie
localStorage限制：无法访问跨域存储

不受限制的跨域资源：

<script src="">：JavaScript文件
<link href="">：CSS文件
<img src="">：图片
<iframe src="">：页面嵌入
<video>/<audio>：媒体资源

Question 27

**What are the differences between HTTP/1.0 and HTTP/1.1? What new features were added in HTTP/1.1?**
- *考察点：协议版本差异。*

Answer

What are the differences between HTTP/1.0 and HTTP/1.1? What new features were added in HTTP/1.1?

考察点：协议版本差异。

答案：

HTTP/1.1新增特性：

1. 持久连接（Keep-Alive）：

HTTP/1.0每次请求都要建立新连接
HTTP/1.1默认启用持久连接，显著提升性能

2. 管道化（Pipelining）：

允许在同一连接上发送多个请求而不等待响应
减少延迟，提高效率

3. 增强的缓存机制：

新增Cache-Control头部
支持ETag验证
更灵活的缓存策略

4. 分块传输编码：

Transfer-Encoding: chunked

支持动态生成内容的传输
无需预先知道内容长度

5. Host头部支持：

支持虚拟主机
同一IP可托管多个域名

6. 新增请求方法：

PUT：更新资源
DELETE：删除资源
OPTIONS：获取服务器支持的方法
TRACE：诊断用途

Question 28

**What is HTTP pipelining? What are its advantages and disadvantages?**
- *考察点：请求优化技术。*

Answer

What is HTTP pipelining? What are its advantages and disadvantages?

考察点：请求优化技术。

答案：

HTTP管道化是HTTP/1.1的一个特性，允许客户端在同一个TCP连接上发送多个请求，而无需等待每个响应。

工作原理： 客户端可以连续发送多个请求，服务器按顺序处理并返回响应。

优点： 减少延迟，提高连接利用率，改善页面加载性能

缺点： 队头阻塞问题，实现复杂，浏览器支持有限，现已被HTTP/2多路复用替代

Question 29

**What are the differences between Content-Encoding and Transfer-Encoding?**
- *考察点：编码方式理解。*

Answer

What are the differences between Content-Encoding and Transfer-Encoding?

考察点：编码方式理解。

答案：

Content-Encoding： 对原始内容进行编码压缩（如gzip），端到端编码，客户端需要解码获取原始内容

Transfer-Encoding： 对传输过程进行编码（如chunked），逐跳编码，用于传输优化，不影响最终内容

主要区别： Content-Encoding关注内容压缩，Transfer-Encoding关注传输方式

Question 30

**What is HTTP authentication? What are the differences between Basic and Bearer authentication?**
- *考察点：身份验证方式。*

Answer

What is HTTP authentication? What are the differences between Basic and Bearer authentication?

考察点：身份验证方式。

答案：

HTTP认证： 通过Authorization头部提供身份验证信息的机制

Basic认证：

格式：Authorization: Basic base64(username:password)
简单但安全性低，需HTTPS保护
适用于简单场景

Bearer认证：

格式：Authorization: Bearer <token>
基于令牌，安全性高
适用于API认证，支持过期机制

Question 31

**What are XSS and CSRF attacks? How does HTTP prevent these attacks?**
- *考察点：Web安全防护。*

Answer

What are XSS and CSRF attacks? How does HTTP prevent these attacks?

考察点：Web安全防护。

答案：

XSS（跨站脚本攻击）： 恶意脚本注入到网页中执行

防范措施：

Content-Security-Policy头部限制资源加载
X-XSS-Protection启用浏览器XSS过滤
输入验证和输出转义

CSRF（跨站请求伪造）： 利用用户身份执行非预期操作

防范措施：

SameSiteCookie属性
CSRF Token验证
检查Referer头部
双重提交Cookie

Question 32

**What is the role of Range requests? How to implement resumable uploads?**
- *考察点：分片传输技术。*

Answer

What is the role of Range requests? How to implement resumable uploads?

考察点：分片传输技术。

答案：

Range请求： 允许客户端只请求资源的特定部分，而不是整个资源

断点续传实现：

客户端发送Range: bytes=start-end头部
服务器返回206状态码和部分内容
Content-Range头部标识返回的字节范围
客户端可以多次请求不同范围直到获取完整文件

应用场景： 大文件下载、视频流媒体、文件续传

Question 33

**What is HTTP proxy? What are the differences between forward proxy and reverse proxy?**
- *考察点：代理服务器概念。*

Answer

What is HTTP proxy? What are the differences between forward proxy and reverse proxy?

考察点：代理服务器概念。

答案：

HTTP代理： 位于客户端和服务器之间的中介服务器

正向代理：

代理客户端向服务器发送请求
服务器不知道真实客户端
用途：访问控制、缓存、匿名访问

反向代理：

代理服务器接收客户端请求
客户端不知道真实服务器
用途：负载均衡、SSL终止、缓存

Question 34

**How does HTTP compression work? What are the common compression algorithms?**
- *考察点：数据传输优化。*

Answer

How does HTTP compression work? What are the common compression algorithms?

考察点：数据传输优化。

答案：

HTTP压缩机制：

客户端发送Accept-Encoding头部表明支持的压缩算法
服务器选择算法压缩响应内容
服务器添加Content-Encoding头部标识压缩算法
客户端根据头部信息解压内容

常见压缩算法：

gzip： 最广泛支持，压缩比好
deflate： 较少使用
br（Brotli）： Google开发，压缩率更高
compress： 已废弃

示例：

Accept-Encoding: gzip, deflate, br
Content-Encoding: gzip

Question 35

**What improvements does HTTP/2 have over HTTP/1.1? How is multiplexing implemented?**
- *考察点：协议演进与性能优化。*

Answer

What improvements does HTTP/2 have over HTTP/1.1? How is multiplexing implemented?

考察点：协议演进与性能优化。

答案：

HTTP/2相比HTTP/1.1有重大改进，主要解决了HTTP/1.1的性能瓶颈问题。

主要改进：

1. 多路复用（Multiplexing）：

在单个TCP连接上并行发送多个请求和响应
解决了HTTP/1.1的队头阻塞问题
不需要建立多个连接，减少延迟

2. 二进制分帧：

将HTTP消息分解为独立的帧
帧可以交错发送，接收端重新组装
提高传输效率和可靠性

3. 头部压缩（HPACK）：

使用HPACK算法压缩HTTP头部
维护头部字段表，避免重复传输
显著减少带宽消耗

4. 服务器推送：

服务器可以主动向客户端推送资源
减少往返次数，提前加载关键资源

5. 流优先级：

为不同流设置优先级和依赖关系
确保重要资源优先传输

多路复用实现原理：

帧结构：

+-----------------------------------------------+
|                 Length (24)                   |
+---------------+---------------+---------------+
|   Type (8)    |   Flags (8)   |
+-+-------------+---------------+-------------------------------+
|R|                 Stream Identifier (31)                      |
+=+=============================================================+
|                   Frame Payload (0...)                      ...
+---------------------------------------------------------------+

工作机制：

流（Stream）：逻辑上的请求-响应对
帧（Frame）：最小通信单位
连接（Connection）：承载多个流的TCP连接

性能提升效果：

延迟降低：减少连接建立时间
吞吐量提升：更好的连接利用率
带宽节省：头部压缩减少传输数据量
更好的缓存利用：单连接复用

与HTTP/1.1对比：

HTTP/1.1：串行请求，连接数限制，头部冗余
HTTP/2：并行请求，单连接复用，头部压缩

Question 36

**What is HTTP/2 server push? What problems does it solve?**
- *考察点：主动推送机制。*

Answer

What is HTTP/2 server push? What problems does it solve?

考察点：主动推送机制。

答案：

HTTP/2服务器推送（Server Push）允许服务器在客户端请求之前主动发送资源，优化页面加载性能。

工作原理：

客户端请求HTML页面
服务器分析页面依赖资源（CSS、JS、图片等）
服务器主动推送这些资源到客户端
客户端缓存推送的资源，避免额外请求

解决的问题：

减少往返次数：避免等待客户端发现并请求资源
提前加载关键资源：CSS、JS等阻塞渲染的资源
优化首屏加载时间：更快的页面呈现

实现机制：

PUSH_PROMISE Frame:
- Stream ID: 客户端请求的流ID
- Promised Stream ID: 推送资源的新流ID  
- 推送资源的请求头部信息

注意事项：

客户端可以拒绝推送（RST_STREAM）
需要careful设计避免推送不需要的资源
现实中应用较少，浏览器支持逐渐减少

Question 37

**What advantages does HTTP/3 based on QUIC protocol have? What problems of HTTP/2 does it solve?**
- *考察点：新协议技术特性。*

Answer

What advantages does HTTP/3 based on QUIC protocol have? What problems of HTTP/2 does it solve?

考察点：新协议技术特性。

答案：

HTTP/3基于QUIC协议，解决了HTTP/2在TCP层面的限制，带来显著性能提升。

QUIC协议优势：

基于UDP：避免TCP的队头阻塞问题
内置加密：默认TLS 1.3加密，安全性更高
连接迁移：支持IP地址变化时保持连接
0-RTT连接建立：减少握手延迟

解决HTTP/2的问题：

TCP队头阻塞：HTTP/2虽然解决了HTTP层阻塞，但TCP层仍存在
连接建立延迟：QUIC合并了传输和加密握手
网络切换：移动环境下的连接稳定性

Question 38

**How to design a high-performance HTTP service? What factors need to be considered?**
- *考察点：服务架构设计。*

Answer

How to design a high-performance HTTP service? What factors need to be considered?

考察点：服务架构设计。

答案：

架构设计考虑因素：

连接管理：Keep-Alive、连接池、超时设置
缓存策略：多层缓存、CDN、反向代理缓存
负载均衡：水平扩展、健康检查、故障转移
压缩优化：gzip、Brotli压缩
安全性：HTTPS、防DDoS、速率限制
监控告警：性能指标、错误率、可用性

Question 39

**How to optimize HTTP performance in large-scale web applications? What strategies are available?**
- *考察点：性能优化策略。*

Answer

How to optimize HTTP performance in large-scale web applications? What strategies are available?

考察点：性能优化策略。

答案：

前端优化： 资源合并压缩、懒加载、预加载、Service Worker缓存

网络优化： CDN分发、HTTP/2、域名分片、DNS优化

后端优化： 缓存策略、数据库优化、异步处理、微服务架构

基础设施： 负载均衡、自动扩缩容、容器化部署

Question 40

**What is CDN? How does it improve HTTP request performance?**
- *考察点：内容分发网络。*

Answer

What is CDN? How does it improve HTTP request performance?

考察点：内容分发网络。

答案：

CDN（内容分发网络）是分布式的服务器网络，将内容缓存到离用户最近的边缘节点。

性能提升机制：

减少延迟：就近访问，降低网络延迟
减轻源站压力：分散流量，提高可用性
带宽优化：边缘缓存减少长距离传输
负载分布：全球节点分担流量

Question 41

**How to design a distributed HTTP caching system? What issues need to be considered?**
- *考察点：缓存架构设计。*

Answer

How to design a distributed HTTP caching system? What issues need to be considered?

考察点：缓存架构设计。

答案：

分布式HTTP缓存系统需要在多个节点间协调缓存数据，保证性能、一致性和可用性。

核心架构组件：

缓存节点：分布在不同地理位置的缓存服务器
负载均衡器：请求分发和节点健康检查
一致性哈希环：数据分片和节点扩展
监控系统：性能指标和故障检测

关键设计考虑：

1. 数据分布策略：

一致性哈希算法：减少节点变更时的数据迁移
虚拟节点：提高负载均衡效果
副本策略：提高可用性和容错能力

2. 缓存策略：

过期策略：TTL、LRU、LFU组合使用
缓存粒度：页面级、对象级、片段级缓存
更新策略：Write-through、Write-back、Write-around

3. 一致性保证：

最终一致性：容忍短期不一致
版本控制：ETag、时间戳版本管理
失效策略：主动失效、被动失效

4. 故障处理：

节点故障转移：自动切换到备用节点
数据恢复：从副本节点重建缓存
降级策略：缓存未命中时的回源处理

5. 性能优化：

预热策略：系统启动时的缓存预加载
热点数据：识别并优化热点数据分布
网络优化：压缩、Keep-Alive、HTTP/2

Question 42

**What strategies are available for HTTP load balancing? How to choose appropriate load balancing algorithms?**
- *考察点：负载分配策略。*

Answer

What strategies are available for HTTP load balancing? How to choose appropriate load balancing algorithms?

考察点：负载分配策略。

答案：

HTTP负载均衡将客户端请求分发到多个后端服务器，提高系统性能和可用性。

主要负载均衡策略：

1. 轮询（Round Robin）：

请求依次分发给每个服务器
简单易实现，适用于服务器性能相近的场景
无法考虑服务器当前负载状况

2. 加权轮询（Weighted Round Robin）：

根据服务器性能分配不同权重
性能强的服务器处理更多请求
适用于服务器性能差异较大的场景

3. 最少连接（Least Connections）：

将请求分发给当前连接数最少的服务器
考虑服务器实时负载情况
适用于连接保持时间差异较大的场景

4. 加权最少连接：

结合服务器权重和当前连接数
平衡服务器性能和实时负载
更精确的负载分配

5. IP哈希（IP Hash）：

根据客户端IP计算哈希值选择服务器
保证同一客户端请求路由到相同服务器
适用于需要会话保持的场景

6. 响应时间：

选择响应时间最短的服务器
实时反映服务器性能状况
需要额外的健康检查开销

选择算法的考虑因素：

应用特性：

会话保持需求：选择IP哈希或Cookie亲和性
请求处理时间：长短不一选择最少连接
服务器同构性：相同选轮询，差异大选加权

流量特性：

突发流量：选择响应时间算法
稳定流量：选择轮询算法
地理分布：选择地理位置算法

系统要求：

高可用性：支持故障转移的算法
高性能：低开销的算法（如轮询）
扩展性：支持动态节点调整

Question 43

**How to implement idempotency of HTTP requests? What is its significance in distributed systems?**
- *考察点：接口设计原则。*

Answer

How to implement idempotency of HTTP requests? What is its significance in distributed systems?

考察点：接口设计原则。

答案：

HTTP幂等性是指同一个请求执行多次的效果与执行一次相同，这是RESTful API设计的重要原则。

HTTP方法的幂等性：

天然幂等的方法：

GET：只读操作，多次执行不改变服务器状态
PUT：完全替换资源，多次执行结果相同
DELETE：删除资源，重复删除不存在的资源结果相同
HEAD、OPTIONS：元数据操作，天然幂等

非幂等的方法：

POST：创建资源，多次执行可能创建多个资源

实现幂等性的策略：

1. 幂等键（Idempotency Key）：

POST /api/orders
Idempotency-Key: order_2024_001
Content-Type: application/json

{"product_id": 123, "quantity": 1}

客户端提供唯一标识符
服务器根据key检查是否已处理
相同key返回相同结果

2. 乐观锁：

PUT /api/users/123
If-Match: "version_123"

{"name": "Updated Name", "version": 124}

使用版本号或ETag
并发修改时检测冲突
防止重复更新

3. 状态机设计：

// 订单状态转换
PENDING -> PROCESSING -> COMPLETED
         -> CANCELLED

// 重复操作不改变最终状态

4. 去重机制：

-- 数据库层面的唯一约束
CREATE UNIQUE INDEX idx_order_key ON orders(idempotency_key);

在分布式系统中的意义：

1. 网络重试安全：

网络超时或失败时可以安全重试
避免因重试导致的重复操作
提高系统可靠性

2. 分布式事务：

支持分布式事务的补偿机制
简化错误恢复逻辑
保证数据一致性

3. 消息队列：

消息重复投递时的安全处理
避免重复消费带来的副作用
提高系统容错能力

4. 微服务通信：

服务间调用的安全保障
降低服务耦合度
简化错误处理逻辑

最佳实践：

API设计时明确定义幂等性
使用标准HTTP方法的语义
提供幂等键机制
在文档中明确标注幂等性要求

Question 44

**What is the TLS handshake process in HTTP secure transmission? How to optimize handshake performance?**
- *考察点：安全协议实现。*

Answer

What is the TLS handshake process in HTTP secure transmission? How to optimize handshake performance?

考察点：安全协议实现。

答案：

TLS握手是HTTPS建立安全连接的关键过程，涉及身份验证、密钥协商和加密参数确定。

TLS 1.3握手过程：

1. Client Hello：

- 支持的TLS版本
- 随机数（Client Random）
- 支持的密码套件
- 扩展信息（SNI、ALPN等）
- Key Share（密钥交换参数）

2. Server Hello：

- 选择的TLS版本和密码套件
- 随机数（Server Random）
- Key Share（服务器密钥交换参数）
- Certificate（服务器证书）
- Certificate Verify（证书签名）
- Finished（握手完成消息）

3. Client Finished：

- Certificate（客户端证书，如需要）
- Certificate Verify（客户端证书签名）
- Finished（客户端握手完成）

TLS 1.2 vs TLS 1.3对比：

特性	TLS 1.2	TLS 1.3
往返次数	2-RTT	1-RTT
0-RTT支持	无	有（复用连接）
加密范围	部分握手消息	除Hello外全部加密
密码套件	复杂组合	简化的AEAD

握手性能优化策略：

1. 会话复用：

// Session ID复用
Session-ID: abc123...

// Session Ticket
NewSessionTicket: encrypted_session_state

避免重复完整握手
减少CPU计算开销
降低延迟

2. 0-RTT数据传输：

// TLS 1.3 Early Data
GET /api/data HTTP/1.1
Host: example.com
// 在握手完成前发送应用数据

复用之前的连接参数
首次请求即可发送数据
注意重放攻击风险

3. OCSP Stapling：

// 服务器主动提供证书状态
Certificate Status: good
OCSP Response: [证书状态信息]

避免客户端查询OCSP服务器
减少额外的网络请求
提高握手速度

4. 证书链优化：

使用较短的证书链
预加载中间证书
选择高效的签名算法（如ECDSA）

5. 密码套件优化：

// 优先选择高效算法
Cipher Suites:
- TLS_AES_128_GCM_SHA256
- TLS_CHACHA20_POLY1305_SHA256

6. 硬件加速：

使用支持AES-NI的CPU
专用加密芯片
GPU加速计算

监控指标：

握手延迟
握手成功率
证书验证时间
密钥协商时间

Question 45

**How to design RESTful API HTTP interfaces? What principles need to be followed?**
- *考察点：API设计规范。*

Answer

How to design RESTful API HTTP interfaces? What principles need to be followed?

考察点：API设计规范。

答案：

RESTful API设计遵循REST架构风格，通过HTTP协议提供清晰、一致的Web服务接口。

核心设计原则：

1. 资源导向（Resource-Oriented）：

# 正确：以资源为中心
GET    /users          # 获取用户列表
GET    /users/123      # 获取特定用户
POST   /users          # 创建新用户
PUT    /users/123      # 更新用户
DELETE /users/123      # 删除用户

# 错误：以动作为中心
POST   /getUsers
POST   /createUser
POST   /updateUser

2. 标准HTTP方法：

GET：获取资源（安全、幂等）
POST：创建资源（非幂等）
PUT：完整更新资源（幂等）
PATCH：部分更新资源
DELETE：删除资源（幂等）
HEAD：获取资源元数据
OPTIONS：获取支持的方法

3. 合理的状态码：

# 成功响应
200 OK          # 成功获取资源
201 Created     # 成功创建资源
204 No Content  # 成功但无返回内容

# 客户端错误
400 Bad Request      # 请求格式错误
401 Unauthorized     # 需要身份验证
403 Forbidden        # 权限不足
404 Not Found        # 资源不存在
409 Conflict         # 资源冲突

# 服务器错误
500 Internal Server Error  # 服务器内部错误
502 Bad Gateway           # 网关错误
503 Service Unavailable   # 服务不可用

4. 统一的URL设计：

# 资源层次结构
/users                    # 用户集合
/users/123               # 特定用户
/users/123/orders        # 用户的订单
/users/123/orders/456    # 特定订单

# 查询参数
/users?page=1&limit=10&sort=name
/products?category=books&price_min=10

5. 版本控制：

# URL版本控制
/v1/users
/v2/users

# Header版本控制
Accept: application/vnd.api.v1+json
API-Version: v2

# 参数版本控制
/users?version=v2

高级设计模式：

1. HATEOAS（超媒体驱动）：

{
  "id": 123,
  "name": "John Doe",
  "links": {
    "self": "/users/123",
    "orders": "/users/123/orders",
    "edit": "/users/123",
    "delete": "/users/123"
  }
}

2. 内容协商：

# 请求
Accept: application/json, application/xml
Accept-Language: zh-CN, en-US

# 响应
Content-Type: application/json; charset=utf-8
Content-Language: zh-CN

3. 条件请求：

# 缓存验证
If-None-Match: "abc123"
If-Modified-Since: Wed, 21 Oct 2024 07:28:00 GMT

# 并发控制
If-Match: "version123"

错误处理：

{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "请求数据验证失败",
    "details": [
      {
        "field": "email",
        "message": "邮箱格式不正确"
      }
    ]
  }
}

最佳实践：

使用名词而非动词
保持URL的可预测性
提供完整的API文档
实现适当的错误处理
考虑安全性（认证、授权、HTTPS）
提供合理的默认值和分页

Question 46

**What challenges exist in HTTP communication in microservice architecture? How to ensure reliability of inter-service communication?**
- *考察点：分布式通信设计。*

Answer

What challenges exist in HTTP communication in microservice architecture? How to ensure reliability of inter-service communication?

考察点：分布式通信设计。

答案：

微服务架构中的HTTP通信面临网络不可靠、服务依赖复杂等挑战，需要专门的可靠性保障机制。

主要挑战：

1. 网络不可靠性：

网络延迟和超时
网络分区和连接中断
丢包和重传问题

2. 服务依赖复杂：

服务间调用链路长
级联故障风险
部分失败处理困难

3. 性能问题：

远程调用延迟高
序列化/反序列化开销
连接池管理复杂

可靠性保障策略：

1. 超时和重试机制：

// 指数退避重试
const retry = async (fn, maxRetries = 3) => {
  let delay = 1000; // 初始延迟1秒
  
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await fn();
    } catch (error) {
      if (i === maxRetries - 1) throw error;
      
      await new Promise(resolve => setTimeout(resolve, delay));
      delay *= 2; // 指数退避
    }
  }
};

2. 熔断器模式：

class CircuitBreaker {
  constructor(threshold = 5, timeout = 60000) {
    this.threshold = threshold;
    this.timeout = timeout;
    this.failureCount = 0;
    this.state = 'CLOSED'; // CLOSED, OPEN, HALF_OPEN
  }
  
  async call(fn) {
    if (this.state === 'OPEN') {
      if (Date.now() - this.lastFailureTime < this.timeout) {
        throw new Error('Circuit breaker is OPEN');
      }
      this.state = 'HALF_OPEN';
    }
    
    try {
      const result = await fn();
      this.onSuccess();
      return result;
    } catch (error) {
      this.onFailure();
      throw error;
    }
  }
}

3. 服务发现和负载均衡：

# 服务注册配置
service:
  name: user-service
  instances:
    - host: 192.168.1.10
      port: 8080
      health_check: /health
    - host: 192.168.1.11  
      port: 8080
      health_check: /health
  
load_balancer:
  strategy: round_robin
  health_check_interval: 30s

4. 限流和降级：

// 令牌桶限流
class TokenBucket {
  constructor(capacity, refillRate) {
    this.capacity = capacity;
    this.tokens = capacity;
    this.refillRate = refillRate;
    this.lastRefill = Date.now();
  }
  
  consume(tokens = 1) {
    this.refill();
    if (this.tokens >= tokens) {
      this.tokens -= tokens;
      return true;
    }
    return false;
  }
}

// 服务降级
const getUserProfile = async (userId) => {
  try {
    return await userService.getProfile(userId);
  } catch (error) {
    // 降级返回缓存数据或默认值
    return getCachedProfile(userId) || getDefaultProfile();
  }
};

5. 分布式追踪：

# 追踪头部
Trace-Id: 123e4567-e89b-12d3-a456-426614174000
Span-Id: a456-426614174001
Parent-Span-Id: a456-426614174000

6. 健康检查：

// 健康检查端点
app.get('/health', (req, res) => {
  const health = {
    status: 'healthy',
    timestamp: new Date().toISOString(),
    checks: {
      database: checkDatabase(),
      cache: checkCache(),
      external_service: checkExternalService()
    }
  };
  
  const isHealthy = Object.values(health.checks)
    .every(check => check.status === 'healthy');
    
  res.status(isHealthy ? 200 : 503).json(health);
});

通信模式选择：

同步通信：

HTTP REST API
GraphQL
gRPC

异步通信：

消息队列（RabbitMQ、Apache Kafka）
事件驱动架构
发布-订阅模式

最佳实践：

设计幂等的API接口
实现优雅的错误处理
使用连接池管理
监控关键指标（延迟、错误率、吞吐量）
实现服务的向后兼容性

Question 47

**How to monitor and diagnose HTTP performance issues? What are the key metrics?**
- *考察点：性能监控体系。*

Answer

How to monitor and diagnose HTTP performance issues? What are the key metrics?

考察点：性能监控体系。

答案：

HTTP性能监控需要建立完整的指标体系，从多个维度收集数据，及时发现和诊断性能问题。

关键性能指标：

1. 响应时间指标：

- 平均响应时间 (Average Response Time)
- P50/P90/P95/P99响应时间百分位数
- 最大响应时间 (Max Response Time)
- DNS解析时间
- TCP连接建立时间
- SSL握手时间
- 首字节时间 (TTFB)

2. 吞吐量指标：

- 每秒请求数 (RPS/QPS)
- 每秒事务数 (TPS)  
- 带宽利用率
- 并发连接数
- 连接池使用率

3. 错误率指标：

- HTTP错误率 (4xx/5xx)
- 超时率
- 连接失败率
- 可用性 (Availability)
- 成功率 (Success Rate)

4. 资源利用率：

- CPU使用率
- 内存使用率
- 网络I/O
- 磁盘I/O
- 连接数

监控工具和方法：

1. 应用性能监控 (APM)：

// 使用APM工具埋点
const tracer = require('dd-trace').init({
  service: 'web-app',
  env: 'production'
});

app.use((req, res, next) => {
  const span = tracer.startSpan('http.request');
  span.setTag('http.method', req.method);
  span.setTag('http.url', req.url);
  
  res.on('finish', () => {
    span.setTag('http.status_code', res.statusCode);
    span.finish();
  });
  
  next();
});

2. 日志分析：

# Nginx访问日志格式
log_format main '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent" '
                '$request_time $upstream_response_time';

# 分析慢请求
tail -f access.log | awk '$NF > 1.0 { print $0 }'

3. 实时监控：

# Prometheus监控配置
- job_name: 'web-app'
  static_configs:
    - targets: ['localhost:3000']
  metrics_path: /metrics
  scrape_interval: 15s
  
# 告警规则
- alert: HighResponseTime
  expr: histogram_quantile(0.95, http_request_duration_seconds) > 2
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: "High response time detected"

诊断方法：

1. 分层分析：

应用层 -> 中间件层 -> 网络层 -> 基础设施层

- 应用代码性能
- 数据库查询优化
- 缓存命中率
- 网络延迟
- 服务器资源

2. 链路追踪：

// 分布式追踪
const opentelemetry = require('@opentelemetry/api');

const tracer = opentelemetry.trace.getTracer('my-service');

app.get('/api/user/:id', async (req, res) => {
  const span = tracer.startSpan('get-user');
  
  try {
    // 数据库查询追踪
    const dbSpan = tracer.startSpan('db-query', { parent: span });
    const user = await db.users.findById(req.params.id);
    dbSpan.end();
    
    // 外部API调用追踪
    const apiSpan = tracer.startSpan('external-api', { parent: span });
    const profile = await externalAPI.getUserProfile(req.params.id);
    apiSpan.end();
    
    res.json({ user, profile });
  } finally {
    span.end();
  }
});

3. 性能剖析：

// Node.js性能分析
const v8Profiler = require('v8-profiler-next');

// CPU性能分析
const profiler = v8Profiler.startProfiling('CPU profile');
setTimeout(() => {
  const profile = v8Profiler.stopProfiling('CPU profile');
  profile.export()
    .pipe(fs.createWriteStream('cpu-profile.cpuprofile'));
}, 30000);

// 内存快照
const snapshot = v8Profiler.takeSnapshot('heap snapshot');
snapshot.export()
  .pipe(fs.createWriteStream('heap-snapshot.heapsnapshot'));

告警和通知：

# 告警规则配置
alerts:
  - name: http_performance
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.1
        for: 2m
        
      - alert: SlowResponse
        expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 2
        for: 5m
        
    notifications:
      - webhook: "https://hooks.slack.com/..."
      - email: "[email protected]"

优化建议：

建立基准性能指标
设置合理的告警阈值
定期进行性能回归测试
关注用户体验指标
建立性能优化流程

Question 48

**What is the role of HTTP gateway? How to design a highly available API gateway?**
- *考察点：网关架构设计。*

Answer

What is the role of HTTP gateway? How to design a highly available API gateway?

考察点：网关架构设计。

答案：

HTTP网关（API Gateway）是微服务架构中的关键组件，作为客户端和后端服务之间的统一入口，提供路由、认证、限流等功能。

API网关的核心作用：

1. 请求路由：

# 路由配置示例
routes:
  - path: /api/users/*
    service: user-service
    load_balancer: round_robin
    
  - path: /api/orders/*
    service: order-service
    load_balancer: least_connections
    
  - path: /api/payments/*
    service: payment-service
    timeout: 30s

2. 认证授权：

// JWT token验证
const authenticateToken = (req, res, next) => {
  const token = req.headers['authorization']?.split(' ')[1];
  
  if (!token) {
    return res.status(401).json({ error: 'Access token required' });
  }
  
  jwt.verify(token, process.env.JWT_SECRET, (err, user) => {
    if (err) return res.status(403).json({ error: 'Invalid token' });
    req.user = user;
    next();
  });
};

3. 限流控制：

// 基于用户的限流
const rateLimiter = {
  windowMs: 15 * 60 * 1000, // 15分钟
  max: 100, // 最大请求数
  keyGenerator: (req) => req.user?.id || req.ip,
  message: { error: 'Too many requests' }
};

高可用架构设计：

1. 多实例部署：

# Docker Compose示例
version: '3.8'
services:
  gateway-1:
    image: api-gateway:latest
    environment:
      - INSTANCE_ID=gateway-1
      - CONSUL_URL=consul:8500
    
  gateway-2:
    image: api-gateway:latest
    environment:
      - INSTANCE_ID=gateway-2
      - CONSUL_URL=consul:8500
      
  load-balancer:
    image: nginx:latest
    depends_on:
      - gateway-1
      - gateway-2

2. 负载均衡：

# Nginx配置
upstream api_gateway {
    least_conn;
    server gateway-1:3000 max_fails=3 fail_timeout=30s;
    server gateway-2:3000 max_fails=3 fail_timeout=30s;
    server gateway-3:3000 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    
    location /api/ {
        proxy_pass http://api_gateway;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }
}

3. 健康检查：

// 健康检查端点
app.get('/health', async (req, res) => {
  const checks = {
    status: 'healthy',
    timestamp: new Date().toISOString(),
    services: {}
  };
  
  // 检查后端服务状态
  for (const service of ['user-service', 'order-service']) {
    try {
      const response = await axios.get(`http://${service}/health`, {
        timeout: 5000
      });
      checks.services[service] = {
        status: 'healthy',
        responseTime: response.headers['x-response-time']
      };
    } catch (error) {
      checks.services[service] = {
        status: 'unhealthy',
        error: error.message
      };
    }
  }
  
  const isHealthy = Object.values(checks.services)
    .every(service => service.status === 'healthy');
    
  res.status(isHealthy ? 200 : 503).json(checks);
});

4. 熔断和降级：

const CircuitBreaker = require('opossum');

const options = {
  timeout: 3000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000
};

const breaker = new CircuitBreaker(callBackendService, options);

breaker.fallback(() => ({
  error: 'Service temporarily unavailable',
  fallback: true
}));

breaker.on('open', () => console.log('Circuit breaker opened'));
breaker.on('halfOpen', () => console.log('Circuit breaker half-open'));

5. 配置管理：

// 动态配置更新
const consul = require('consul')({ host: 'consul-server' });

const updateConfig = async () => {
  try {
    const result = await consul.kv.get('gateway/config');
    const config = JSON.parse(result.Value);
    
    // 更新路由配置
    updateRoutes(config.routes);
    
    // 更新限流配置
    updateRateLimits(config.rateLimits);
    
  } catch (error) {
    console.error('Failed to update config:', error);
  }
};

// 定期检查配置更新
setInterval(updateConfig, 30000);

6. 监控和日志：

// 请求监控中间件
app.use((req, res, next) => {
  const start = Date.now();
  
  res.on('finish', () => {
    const duration = Date.now() - start;
    
    // 记录指标
    metrics.requestDuration.observe(
      { method: req.method, route: req.route?.path, status: res.statusCode },
      duration / 1000
    );
    
    // 记录日志
    logger.info({
      method: req.method,
      url: req.url,
      statusCode: res.statusCode,
      duration,
      userAgent: req.get('User-Agent'),
      ip: req.ip
    });
  });
  
  next();
});

容错和恢复：

1. 优雅降级：

// 服务降级策略
const degradeService = (serviceName, error) => {
  switch (serviceName) {
    case 'recommendation-service':
      // 推荐服务降级，返回默认推荐
      return getDefaultRecommendations();
      
    case 'user-profile-service':
      // 用户画像服务降级，返回基础信息
      return getBasicUserInfo();
      
    default:
      throw error;
  }
};

2. 自动故障恢复：

// 自动重启机制
process.on('uncaughtException', (error) => {
  logger.error('Uncaught Exception:', error);
  
  // 优雅关闭
  server.close(() => {
    process.exit(1);
  });
});

// PM2进程管理配置
module.exports = {
  apps: [{
    name: 'api-gateway',
    script: './app.js',
    instances: 'max',
    exec_mode: 'cluster',
    max_restarts: 3,
    min_uptime: '10s'
  }]
};

安全考虑：

HTTPS终端
防DDoS攻击
API密钥管理
请求验证和过滤
安全头部设置

什么是HTTP？它在Web开发中的作用是什么？

📝 参考答案

HTTP和HTTPS有什么区别？HTTPS是如何保证安全的？

📝 参考答案

HTTP有哪些常用的请求方法？GET和POST有什么区别？

📝 参考答案

PUT和POST请求方法有什么区别？分别用于什么场景？

📝 参考答案

HTTP状态码有哪些分类？常见的状态码有哪些？

📝 参考答案

2xx、3xx、4xx、5xx状态码分别表示什么含义？

📝 参考答案

301和302重定向有什么区别？什么时候使用？

📝 参考答案

HTTP请求和响应的基本结构是什么？

📝 参考答案

什么是HTTP请求头？常见的请求头有哪些？

📝 参考答案

什么是HTTP响应头？常见的响应头有哪些？

📝 参考答案

User-Agent请求头的作用是什么？

📝 参考答案

什么是URL和URI？它们有什么区别？

📝 参考答案

URL的组成部分有哪些？每部分的作用是什么？

📝 参考答案

什么是Cookie？Cookie的作用是什么？

📝 参考答案

Cookie和Session有什么区别？

📝 参考答案

HTTP是无状态协议，这意味着什么？

📝 参考答案

什么是Content-Type？常见的Content-Type有哪些？

📝 参考答案

HTTP请求中的查询参数和请求体有什么区别？

📝 参考答案

HTTP的工作流程是什么？从输入URL到页面显示经历了哪些步骤？

📝 参考答案

什么是HTTP Keep-Alive？它解决了什么问题？

📝 参考答案

HTTP缓存机制是如何工作的？强缓存和协商缓存有什么区别？

📝 参考答案

Cache-Control和Expires有什么区别？如何配置缓存策略？

📝 参考答案

ETag和Last-Modified的作用是什么？它们如何实现协商缓存？

📝 参考答案

什么是CORS？为什么会出现跨域问题？

📝 参考答案

如何解决CORS跨域问题？有哪些解决方案？

📝 参考答案

什么是同源策略？它限制了什么？

📝 参考答案

HTTP/1.0、HTTP/1.1有什么区别？HTTP/1.1新增了哪些特性？

📝 参考答案

什么是HTTP管道化？它有什么优缺点？

📝 参考答案

Content-Encoding和Transfer-Encoding有什么区别？

📝 参考答案

什么是HTTP认证？Basic认证和Bearer认证有什么区别？

📝 参考答案

什么是XSS和CSRF攻击？HTTP如何防范这些攻击？

📝 参考答案

Range请求的作用是什么？如何实现断点续传？

📝 参考答案

什么是HTTP代理？正向代理和反向代理有什么区别？

📝 参考答案

HTTP压缩是如何工作的？常见的压缩算法有哪些？

📝 参考答案

HTTP/2相比HTTP/1.1有哪些改进？多路复用是如何实现的？

📝 参考答案

什么是HTTP/2的服务器推送？它解决了什么问题？

📝 参考答案

HTTP/3基于QUIC协议有什么优势？解决了HTTP/2的哪些问题？

📝 参考答案

如何设计一个高性能的HTTP服务？需要考虑哪些因素？

📝 参考答案

大规模Web应用中如何优化HTTP性能？有哪些策略？

📝 参考答案

什么是CDN？它如何提升HTTP请求的性能？

📝 参考答案