HTTP 知识体系导图（检索提要）
一、HTTP基础核心（入门与进阶）
1. HTTP核心认知
定义：HTTP（HyperText Transfer Protocol，超文本传输协议）是客户端与服务器之间通信的应用层协议，基于TCP/IP协议，用于传输超文本（HTML、图片、视频等），核心特点是无状态、无连接（HTTP/1.1后通过Keep-Alive优化）。
HTTP的核心作用：规范客户端与服务器的请求/响应格式，实现数据的可靠传输，是前端与后端交互的核心桥梁。
HTTP的核心特性（重点）：
无状态：协议本身不记录客户端的会话信息，每次请求都是独立的（需通过Cookie、Session弥补）。
无连接：HTTP/1.0默认每次请求都建立TCP连接，请求结束后关闭连接；HTTP/1.1支持Keep-Alive长连接，复用TCP连接。
可扩展：协议头支持自定义字段（如X-Requested-With、Authorization），适配不同业务场景。
基于请求-响应模型：客户端发起请求，服务器返回响应，单向通信。
HTTP与HTTPS的核心区别（重点）：
安全性：HTTP明文传输，易被窃听、篡改；HTTPS基于TLS/SSL加密传输，保障数据安全。
端口：HTTP默认80端口；HTTPS默认443端口。
开销：HTTPS需进行SSL握手，增加额外的时间和带宽开销。
证书：HTTPS需要CA证书验证服务器身份，HTTP无需证书。
2. HTTP请求与响应结构（重点）
HTTP请求结构（三部分，结构固定）：
请求行：包含请求方法、请求URL、HTTP版本（核心）。
- 示例：GET /api/user HTTP/1.1
请求头：键值对形式，传递请求的附加信息（如Cookie、Content-Type、User-Agent）。
请求体：可选，传递POST、PUT等方法的请求数据（如表单数据、JSON数据），GET请求无请求体。
HTTP响应结构（三部分，结构固定）：
响应行：包含HTTP版本、状态码、状态短语（核心）。
- 示例：HTTP/1.1 200 OK
响应头：键值对形式，传递响应的附加信息（如Content-Type、Set-Cookie、Cache-Control）。
响应体：服务器返回的具体数据（如HTML、JSON、图片）。
关键细节：请求头与响应头的键名不区分大小写，值区分大小写；请求体的格式需与Content-Type一致。
3. HTTP请求方法（重点，区分常用与冷门）
核心常用方法（常用方法，注意语义与场景区别）：
GET：获取资源，请求参数拼接在URL后（可见、有长度限制），幂等、可缓存，无请求体。
- 实战场景：查询列表、详情页数据。
POST：提交资源，请求参数放在请求体中（不可见、无长度限制），非幂等、不可缓存。
- 实战场景：提交表单、创建数据。
PUT：更新资源（全量更新），请求体传递完整资源，幂等。
- 实战场景：修改用户信息（需传递所有字段）。
DELETE：删除资源，幂等。
- 实战场景：删除一条数据。
拓展方法（高级，了解用法）：
PATCH：更新资源（部分更新），非幂等，请求体传递需要修改的字段（区别于PUT）。
OPTIONS：获取服务器支持的请求方法，常用于预检请求（CORS跨域）。
HEAD：与GET用法一致，但只返回响应头，不返回响应体（用于检查资源是否存在）。
TRACE：回显服务器收到的请求，用于调试，实际开发中很少用。
关键概念（重点）：幂等性——多次执行同一请求，结果一致（GET、PUT、DELETE是幂等，POST、PATCH非幂等）。
4. HTTP状态码（按类别速查）
状态码分类（5大类，核心是2xx、3xx、4xx、5xx）：
1xx（信息性状态码）：请求已接收，继续处理（很少用到）。
- 示例：100 Continue（预检请求后，服务器允许继续发送请求体）。
2xx（成功状态码）：请求成功处理。
200 OK：请求成功（最常用，返回正常数据）。
204 No Content：请求成功，但无响应体（如DELETE请求成功）。
206 Partial Content：部分请求成功（用于断点续传、分片下载）。
3xx（重定向状态码）：需要客户端进一步操作才能完成请求。
301 Moved Permanently：永久重定向（域名迁移，SEO友好，浏览器会缓存）。
302 Found：临时重定向（临时跳转，浏览器不缓存）。
304 Not Modified：协商缓存命中，服务器返回304，客户端使用本地缓存（核心常见）。
307 Temporary Redirect：临时重定向，不允许修改请求方法（区别于302）。
4xx（客户端错误）：请求存在错误，服务器无法处理。
400 Bad Request：请求参数错误（如格式错误、缺少必填参数）。
401 Unauthorized：未授权（需要登录，如未携带Token）。
403 Forbidden：禁止访问（已授权，但无权限操作，如普通用户访问管理员接口）。
404 Not Found：请求的资源不存在（最常见）。
405 Method Not Allowed：请求方法不被允许（如用GET请求需要POST的接口）。
409 Conflict：请求冲突（如创建已存在的资源）。
429 Too Many Requests：请求过于频繁（限流，如接口调用次数超限）。
5xx（服务器错误）：服务器处理请求时发生错误。
500 Internal Server Error：服务器内部错误（最常见，如代码报错）。
502 Bad Gateway：网关错误（服务器作为网关，接收上游服务器非法响应）。
503 Service Unavailable：服务不可用（如服务器过载、维护中）。
504 Gateway Timeout：网关超时（服务器作为网关，等待上游服务器响应超时）。
常见要点：304状态码的触发条件、401与403的区别、502与504的区别。
二、HTTP高级特性（进阶核心）
1. HTTP缓存机制（核心）
缓存的核心作用：减少HTTP请求次数，降低服务器压力，提升页面加载速度（前端性能优化核心手段）。
缓存分类（2类，核心区别：是否向服务器发起请求）：
强缓存（本地缓存，不发起请求）：
核心原理：通过响应头设置过期时间，客户端判断缓存是否过期，未过期则直接使用本地缓存。
核心响应头（重点）：
Expires：HTTP/1.0，绝对时间（如Expires: Wed, 20 Jun 2026 16:00:00 GMT），存在时区偏差问题。
Cache-Control：HTTP/1.1，相对时间（优先级高于Expires），常用值：
max-age=xxx：缓存过期时间（单位：秒），如max-age=3600（1小时）。
no-cache：不使用强缓存，需发起协商缓存。
no-store：禁止缓存（不缓存任何数据，每次都请求服务器）。
public：允许所有缓存（如CDN缓存）。
private：仅允许客户端缓存（默认值，不允许CDN等中间缓存）。
失效场景：缓存过期、手动清除缓存、URL变更（如加版本号：app.js?v=1.0）。
协商缓存（对比缓存，发起请求但不返回数据）：
核心原理：客户端发起请求时，携带缓存标识，服务器对比标识，判断缓存是否有效，有效则返回304，无效则返回新数据和新标识。
核心标识组合（2组，重点）：
组合1（Last-Modified + If-Modified-Since）：
Last-Modified（响应头）：服务器返回的资源最后修改时间。
If-Modified-Since（请求头）：客户端下次请求时，携带上次的Last-Modified值。
缺点：只能精确到秒，秒内修改的资源无法识别；文件重命名但内容不变，会误判为新资源。
组合2（ETag + If-None-Match）：
ETag（响应头）：服务器根据资源内容生成的唯一标识（如哈希值），内容变则标识变。
If-None-Match（请求头）：客户端下次请求时，携带上次的ETag值。
优点：精度高，能识别秒内修改的资源；优先级高于Last-Modified。
缓存执行流程（重点）：
1. 客户端发起请求，先检查强缓存，未过期则直接使用本地缓存。
2. 强缓存过期，发起请求，携带协商缓存标识（If-Modified-Since/If-None-Match）。
3. 服务器对比标识，有效则返回304，客户端使用本地缓存；无效则返回200和新数据、新标识。
实战场景：静态资源（CSS、JS、图片）用强缓存+协商缓存，接口数据用协商缓存或禁止缓存。
2. HTTP 请求头与响应头（进阶要点）
常见请求头（常用项与作用）：
Host：指定服务器的域名和端口（HTTP/1.1必填，如Host: www.baidu.com）。
User-Agent（UA）：标识客户端的浏览器、系统、设备信息（用于适配不同设备）。
Cookie：携带客户端的会话信息（如登录态，由服务器通过Set-Cookie设置）。
Content-Type：指定请求体的格式（如application/json、application/x-www-form-urlencoded、multipart/form-data）。
Authorization：携带身份验证信息（如Token、Basic Auth，如Authorization: Bearer xxx）。
If-Modified-Since / If-None-Match：协商缓存相关（上文已讲）。
Origin：跨域请求时，标识请求的来源（协议+域名+端口，如https://www\.xxx\.com）。
Referer：标识请求的来源页面（如从A页面跳转到B页面，Referer为A页面的URL）。
常见响应头（常用项与作用）：
Content-Type：指定响应体的格式（如application/json、text/html、image/png）。
Set-Cookie：设置客户端的Cookie（如登录态、会话ID，可设置过期时间、域名、路径）。
Cache-Control / Expires：强缓存相关（上文已讲）。
Last-Modified / ETag：协商缓存相关（上文已讲）。
Access-Control-Allow-Origin：CORS跨域相关，允许访问的来源（如*、https://www\.xxx\.com）。
Access-Control-Allow-Methods：CORS跨域相关，允许的请求方法（如GET、POST、PUT）。
Access-Control-Allow-Credentials：CORS跨域相关，允许携带Cookie（需配合前端withCredentials: true）。
Location：重定向相关，指定重定向的URL（如301、302状态码配合使用）。
Content-Disposition：用于文件下载，指定文件名（如Content-Disposition: attachment; filename="test.pdf"）。
高级拓展：自定义请求头（如X-Token、X-Request-Id），用于业务标识、追踪请求等。
3. CORS跨域资源共享（实战常见，重点）
核心定义：CORS（Cross-Origin Resource Sharing）是解决浏览器跨域限制的标准方案，允许不同域名的客户端访问服务器资源（浏览器默认禁止跨域请求，同源策略限制）。
同源策略（跨域的前提，重点）：
定义：浏览器规定，只有当请求的协议、域名、端口三者都相同时，才视为同源，否则为跨域。
示例：https://www\.xxx\.com:8080 与 https://www\.xxx\.com:8081（端口不同，跨域）；https://www\.xxx\.com 与 https://blog\.xxx\.com（域名不同，跨域）。
限制范围：AJAX请求、Fetch请求受限制，静态资源（CSS、JS、图片）不受限制。
CORS请求分类（2类，核心区别：是否发起预检请求）：
简单请求（无需预检，直接发起请求）：
满足条件（同时满足）：
请求方法为GET、POST、HEAD。
请求头仅包含简单头（Host、User-Agent、Cookie、Content-Type等）。
Content-Type仅为application/x-www-form-urlencoded、multipart/form-data、text/plain。
执行流程：客户端直接发起请求，服务器返回响应时携带CORS相关响应头，浏览器验证通过则允许访问。
预检请求（Preflight，需先发起OPTIONS请求，再发起实际请求）：
触发条件（满足任一）：
请求方法为PUT、DELETE、PATCH、OPTIONS等非简单方法。
请求头包含自定义头（如X-Token、Authorization）。
Content-Type为application/json等非简单类型。
执行流程：
1. 客户端发起OPTIONS预检请求，携带Origin、Access-Control-Request-Method、Access-Control-Request-Headers。
2. 服务器返回响应，携带Access-Control-Allow-Origin、Access-Control-Allow-Methods等头，允许客户端的请求。
3. 预检通过后，客户端发起实际的请求（如PUT、POST）。
CORS核心响应头（重点）：
Access-Control-Allow-Origin：允许访问的来源（必填，如*表示允许所有来源，不建议生产环境使用）。
Access-Control-Allow-Methods：允许的请求方法（预检请求必填）。
Access-Control-Allow-Headers：允许的请求头（预检请求必填，如X-Token）。
Access-Control-Allow-Credentials：允许携带Cookie（值为true，此时Access-Control-Allow-Origin不能为*）。
Access-Control-Max-Age：预检请求的缓存时间（单位：秒，如86400，避免频繁发起预检）。
实战问题：跨域携带Cookie的配置（前端withCredentials: true + 后端Access-Control-Allow-Credentials: true + Access-Control-Allow-Origin指定具体域名）。
4. HTTP版本演进（高级重点，区分版本差异）
HTTP/1.0（基础版本，已淘汰）：
核心特点：每次请求都建立TCP连接，请求结束后关闭连接（无Keep-Alive）。
缺点：TCP连接建立和关闭开销大，并发性能差（队头阻塞）。
HTTP/1.1（目前主流版本）：
核心改进（重点）：
支持Keep-Alive长连接：复用TCP连接，减少连接建立/关闭开销。
支持管道化请求：同一TCP连接中，可连续发送多个请求（但响应需按顺序返回，仍存在队头阻塞）。
新增请求方法（PUT、DELETE、OPTIONS等）、状态码（409、410等）。
支持Chunked编码：分块传输响应体（无需提前知道响应体大小）。
缺点：队头阻塞（一个请求阻塞，后续所有请求都需等待）；头部信息冗余（每次请求都携带重复头部）。
HTTP/2（高级拓展，主流框架已支持）：
核心改进（重点）：
二进制传输：请求/响应体采用二进制编码（帧结构），效率更高。
多路复用：同一TCP连接中，可并行发送多个请求/响应（解决队头阻塞）。
头部压缩（HPACK）：压缩请求/响应头，减少冗余数据（如重复的Cookie、User-Agent）。
服务器推送（Server Push）：服务器主动向客户端推送静态资源（如HTML引用的CSS、JS），提前加载。
注意：HTTP/2需基于HTTPS（大部分浏览器仅支持HTTPS下的HTTP/2）。
HTTP/3（最新版本，逐步推广）：
核心改进（重点）：
基于QUIC协议（而非TCP）：解决TCP队头阻塞问题，握手速度更快（0-RTT/1-RTT握手）。
多路复用：基于QUIC的UDP传输，进一步优化并发性能。
更好的移动网络适配：解决TCP在移动网络下的连接不稳定问题。
现状：目前支持度逐步提升，主流浏览器和服务器（如Nginx、Apache）已开始支持。
5. 会话管理（Cookie与Session，实战常见）
核心作用：解决HTTP无状态的问题，实现客户端与服务器的会话保持（如登录态）。
Cookie（客户端存储，重点）：
定义：服务器通过Set-Cookie响应头，在客户端存储的小型文本数据（最大4KB），每次请求都会自动携带。
核心属性（重点）：
name=value：Cookie的键值对。
expires：绝对过期时间（如expires=Wed, 20 Jun 2026 16:00:00 GMT），过期后Cookie失效。
max-age：相对过期时间（单位：秒），优先级高于expires，如max-age=3600。
domain：指定Cookie生效的域名（如domain=xxx.com，子域名也可访问）。
path：指定Cookie生效的路径（如path=/api，仅/api路径下的请求携带）。
httpOnly：禁止前端通过JS（document.cookie）访问Cookie，防止XSS攻击。
secure：仅在HTTPS协议下，Cookie才会被携带（防止HTTP协议下被窃听）。
SameSite：防止CSRF攻击，取值：Strict（仅同源请求携带）、Lax（部分跨域请求携带）、None（所有请求携带，需配合secure）。
缺点：容量小（4KB）、明文传输（需加密）、每次请求都携带（增加带宽开销）。
Session（服务器存储，重点）：
定义：服务器在内存或数据库中存储的会话信息，每个客户端对应一个SessionID（通过Cookie传递）。
执行流程：
1. 客户端登录成功，服务器创建Session（存储用户信息），生成SessionID。
2. 服务器通过Set-Cookie将SessionID返回给客户端。
3. 客户端后续请求时，携带SessionID，服务器通过SessionID查询对应的Session信息，确认登录态。
缺点：服务器存储，增加服务器压力；分布式系统中，Session共享需额外配置（如Redis存储）。
Cookie与Session的区别（重点）：
存储位置：Cookie在客户端，Session在服务器。
安全性：Cookie相对不安全（可被篡改、窃听），Session更安全（服务器存储）。
容量：Cookie最大4KB，Session无容量限制（取决于服务器）。
开销：Cookie每次请求都携带，Session仅携带SessionID，开销更小。
进阶：Token替代Cookie+Session（如JWT），无状态，适合分布式系统、前后端分离项目。
三、HTTP实战应用（贴合前端业务，重点）
1. 前端请求封装（实战重点）
核心需求：统一请求格式、拦截请求/响应、处理错误、携带Token、配置缓存等。
常用工具：Axios（主流）、Fetch API（原生）。
Axios封装核心（重点）：
请求拦截器（request interceptor）：
添加请求头（如Authorization携带Token、Content-Type设置为application/json）。
处理请求参数（如统一序列化、添加公共参数）。
加载状态提示（如显示loading）。
响应拦截器（response interceptor）：
统一处理响应数据（如提取response.data，简化前端使用）。
统一处理错误（如401未授权跳转登录页、403禁止访问提示、500服务器错误提示）。
关闭加载状态（如隐藏loading）。
请求配置：baseURL（基础路径）、timeout（超时时间）、withCredentials（携带Cookie）等。
实战问题：请求超时处理、重复请求取消（如防止多次点击提交）、接口重试机制。
2. 常见HTTP异常与解决方案（实战常见）
401 Unauthorized（未授权）：
原因：未携带Token、Token过期、Token无效。
解决方案：跳转登录页重新登录、自动刷新Token（如刷新Token接口）。
403 Forbidden（禁止访问）：
原因：已授权，但无操作权限（如普通用户访问管理员接口）。
解决方案：提示用户无权限、跳转至对应权限页面。
404 Not Found（资源不存在）：
原因：请求URL错误、服务器资源未部署、资源已删除。
解决方案：检查URL、提示用户页面不存在、跳转404页面。
429 Too Many Requests（限流）：
原因：接口调用次数超过服务器限制。
解决方案：提示用户请求过于频繁、添加请求节流、优化接口调用频率。
500 Internal Server Error（服务器错误）：
原因：服务器代码报错、数据库异常、服务器过载。
解决方案：提示用户服务器繁忙、记录错误日志、联系后端排查问题。
跨域请求失败：
原因：未配置CORS、CORS响应头错误、预检请求失败。
解决方案：协调后端配置CORS、检查请求头是否符合要求、本地开发用代理（如Vue CLI proxy）。
3. HTTP性能优化（前端核心，重点）
缓存优化（核心）：
静态资源（CSS、JS、图片）：配置强缓存+协商缓存，添加版本号/哈希值（如app.js?v=1.0.0）。
接口数据：根据业务需求配置协商缓存（如Cache-Control: no-cache），或禁止缓存（如Cache-Control: no-store）。
请求优化：
减少请求次数：合并接口（如将多个GET请求合并为一个）、懒加载（图片、组件）、预加载（关键资源）。
减少请求体积：压缩请求参数（如JSON.stringify后压缩）、避免不必要的参数。
并行请求：合理使用Promise.all，并行发起多个无依赖的请求。
避免跨域预检：尽量使用简单请求，减少自定义请求头。
响应优化：
压缩响应数据：开启Gzip/Brotli压缩（服务器配置，如Nginx），减少响应体积。
分块传输：大文件采用Chunked编码，避免一次性返回大量数据。
服务器推送：HTTP/2下，服务器主动推送关键静态资源，提升加载速度。
其他优化：
使用HTTPS：提升安全性，同时支持HTTP/2、HTTP/3，优化传输效率。
CDN加速：静态资源部署到CDN，就近访问，减少延迟。
4. 安全相关（高级重点）
常见HTTP安全风险及防御（重点）：
XSS（跨站脚本攻击）：
定义：注入恶意JS代码，窃取Cookie、篡改页面内容。
防御：输入过滤（过滤特殊字符）、输出编码、设置Cookie的httpOnly属性、使用CSP（内容安全策略）。
CSRF（跨站请求伪造）：
定义：利用用户的登录态，伪造请求，执行非法操作（如转账、删除数据）。
防御：设置Cookie的SameSite属性、添加CSRF Token（请求时携带，服务器验证）、验证Referer/Origin。
中间人攻击：
定义：拦截客户端与服务器的通信，窃听、篡改数据。
防御：使用HTTPS、验证服务器CA证书。
SQL注入：
定义：注入SQL语句，窃取、篡改数据库数据（前端主要配合后端防御）。
防御：前端输入过滤、后端参数化查询。
安全相关响应头：
CSP（Content-Security-Policy）：限制页面可加载的资源（如禁止加载外部JS），防御XSS。
X-XSS-Protection：开启浏览器XSS防护（如X-XSS-Protection: 1; mode=block）。
X-Content-Type-Options：禁止浏览器自动推断文件类型（如X-Content-Type-Options: nosniff）。
四、HTTP 高级进阶
1. HTTPS工作原理（进阶重点）
核心原理：HTTPS = HTTP + TLS/SSL，通过TLS/SSL协议对HTTP请求/响应进行加密，保障数据传输安全。
TLS/SSL握手流程（简化版，重点）：
1. 客户端发起HTTPS请求，向服务器发送客户端支持的TLS版本、加密套件。
2. 服务器返回CA证书（包含服务器公钥）、选定的加密套件。
3. 客户端验证CA证书的合法性（通过本地CA根证书验证），验证通过后，生成随机数（预主密钥），用服务器公钥加密后发送给服务器。
4. 服务器用自身私钥解密，获取预主密钥，双方基于预主密钥生成会话密钥（对称密钥）。
5. 双方使用会话密钥对后续的HTTP请求/响应进行对称加密，完成握手。
关键概念：
对称加密：加密和解密使用同一密钥（效率高，用于传输数据）。
非对称加密：加密用公钥，解密用私钥（安全性高，用于传输会话密钥）。
CA证书：由权威机构颁发，用于验证服务器身份，防止中间人攻击。
进阶：TLS 1.2与TLS 1.3的区别（TLS 1.3简化握手流程，提升速度，如0-RTT握手）。
2. RESTful API设计规范（实战高级，重点）
核心定义：RESTful API是一种基于HTTP协议的API设计规范，强调资源导向，使用HTTP方法表示操作，无状态、可缓存。
核心设计原则（重点）：
资源导向：URL中使用名词表示资源（如/users，而非/getUser），不使用动词。
HTTP方法表示操作：GET（查询）、POST（创建）、PUT（全量更新）、DELETE（删除）、PATCH（部分更新）。
使用状态码表示结果：如200（成功）、404（资源不存在）、500（服务器错误）。
无状态：每个请求都包含所有必要信息，服务器不存储会话信息。
可缓存：遵循HTTP缓存机制，提升性能。
版本控制：URL中包含版本（如/api/v1/users），便于迭代升级。
返回统一格式：如JSON格式，包含状态码、消息、数据（如{ "code": 200, "msg": "success", "data": [] }）。
示例（规范API）：
GET /api/v1/users：查询所有用户。
GET /api/v1/users/1：查询ID为1的用户。
POST /api/v1/users：创建新用户。
PUT /api/v1/users/1：全量更新ID为1的用户。
PATCH /api/v1/users/1：部分更新ID为1的用户。
DELETE /api/v1/users/1：删除ID为1的用户。
3. 其他高级拓展
HTTP/2服务器推送（Server Push）：
原理：服务器在客户端请求HTML后，主动推送HTML引用的CSS、JS等静态资源，无需客户端再次请求。
优势：减少请求次数，提升页面加载速度。
QUIC协议（HTTP/3基础）：
- 基于UDP协议，解决TCP队头阻塞、握手慢的问题，支持多路复用、0-RTT握手。
WebSocket与HTTP的区别：
HTTP：单向通信（客户端请求，服务器响应），无状态，基于TCP。
WebSocket：双向通信（客户端与服务器可互相发送消息），有状态，基于TCP，适合实时通信（如聊天、直播）。
HTTP代理与反向代理：
正向代理：客户端通过代理服务器访问目标服务器（如VPN），隐藏客户端身份。
反向代理：客户端访问代理服务器，代理服务器转发请求到后端服务器（如Nginx），隐藏后端服务器身份，实现负载均衡、缓存。