This is an example page.
``` > 同样，和请求消息一样，响应消息也是二进制数据，客户端(主要指浏览器)需要根据 content-type 进行解析。 > 实操：使用 chrome 浏览器，打开开发者工具，查看网络请求，可以看到请求和响应的消息。或者使用 whistle 等代理工具.同时，可以复制请求为 curl 命令。 ### 使用 curl 或者 postman 发送 http 请求 shell复制代码 ```shell # -X 指定请求方法 curl -X GET http://www.baidu.com # -d 指定请求体 curl -X POST http://www.baidu.com -d "name=gopher" # -I 只显示响应头 curl -I http://www.baidu.com # -v 显示详细信息 curl -v http://www.baidu.com # -H 指定请求头 curl -H "Content-Type: application/json" http://www.baidu.com -d '{"name": "gopher"}' ``` 在浏览器的控制台，Network列表中，在“请求”中 **右键Copy请求** 的内容： ![[Pasted image 20260518152048.png]] 然后在终端模拟请求发送： ![[Pasted image 20260518152059.png|897]] ### 代理工具使用 [代理工具使用](https://campus.wps.cn/contentpreview/f4876c64-57d4-4641-baf6-939db1886870) # 状态码 ## 状态码分类 HTTP 状态码用于表示服务器对请求的处理结果： - **1xx**：信息性状态码，表示请求已接收，继续处理。 - **2xx**：成功状态码，表示请求已成功处理。 - **3xx**：重定向状态码，表示需要进一步操作以完成请求。注意 301 与 302 的区别。 - **4xx**：客户端错误状态码，表示请求包含错误。 - **5xx**：服务器错误状态码，表示服务器处理请求出错。 ![[Pasted image 20260518152142.png]] > 注意：上图也是正常的。 ## HTTP 缓存 HTTP 缓存是性能优化中的一个重要概念，它通过减少服务器请求次数来加快页面加载速度。以下是一份详细的 HTTP 缓存教程，包括原理、分类、设置方法和示例。 HTTP 缓存基于 HTTP 协议的头部信息来控制数据的存储和验证。主要分为两种类型：强制缓存和协商缓存。 ### 强制缓存 - **Expires**: HTTP/1.0 中使用，设置资源的过期时间。如果时间未到，直接使用缓存，不与服务器通信。 - **Cache-Control**: HTTP/1.1 中使用，提供了更多的控制选项，如`max-age`、`no-store`、`no-cache`等。 ### 协商缓存 协商缓存是一种服务器与客户端协商后决定是否使用缓存的机制。当浏览器对某个资源的请求没有命中强制缓存时，会发送请求到服务器，服务器根据请求头中的条件判断是否使用缓存。 ### 什么是协商缓存？ 想象一下： - 小明每天都要查看一个网站的最新内容 - 这个网站的内容并不是每时每刻都在更新 - 如果每次访问都重新下载完整内容，会浪费带宽和时间 - 那么如何既能获取最新内容，又能节省资源呢？ 这就是协商缓存要解决的问题。它允许浏览器和服务器"商量"一下资源是否发生了变化，如果没变化，就直接使用本地缓存。 ### 协商缓存的工作流程 1. 浏览器发起请求，携带上次响应中的某些特殊头部信息 2. 服务器根据这些信息判断资源是否有变化 3. 如果资源没有变化，返回 304 状态码，不返回资源内容 4. 如果资源有变化，返回 200 状态码和完整的资源内容 ### 与协商缓存相关的 HTTP 头部 **Last-Modified/If-Modified-Since** 这对头部基于资源的最后修改时间进行协商： - **Last-Modified**：服务器在响应中添加，表示资源的最后修改时间 - **If-Modified-Since**：客户端在后续请求中携带，值为上次收到的 Last-Modified 值 http复制代码 ```http # 服务器响应 HTTP/1.1 200 OK Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT Content-Type: text/html # 客户端后续请求 GET /index.html HTTP/1.1 Host: www.example.com If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT ``` **ETag/If-None-Match** 这对头部基于资源内容的唯一标识符进行协商： - **ETag**：服务器在响应中添加，是资源内容的唯一标识（通常是内容的哈希值） - **If-None-Match**：客户端在后续请求中携带，值为上次收到的 ETag 值 http复制代码 ```http # 服务器响应 HTTP/1.1 200 OK ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4" Content-Type: text/html # 客户端后续请求 GET /index.html HTTP/1.1 Host: www.example.com If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4" ``` ### Last-Modified 与 ETag 的对比 |特性|Last-Modified|ETag| |---|---|---| |精确度|秒级，无法识别 1 秒内多次修改|基于内容，可以精确识别任何变化| |性能开销|较小，只需记录时间|较大，需要计算内容哈希值| |应对场景|适合内容变化较慢的资源|适合内容频繁变化或需要精确控制缓存的资源| |应对特殊情况|无法处理资源周期性变化但内容不变的情况|可以应对时间变化但内容不变的情况| ### 304 状态码 当服务器收到带有条件请求头的请求，判断资源未发生变化时，会返回 304 Not Modified 状态码： http复制代码 ```http HTTP/1.1 304 Not Modified ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4" Cache-Control: max-age=0, must-revalidate Date: Thu, 22 Oct 2023 07:28:00 GMT ``` ### 实际应用建议 1. 对于不经常变化的静态资源（如 logo、库文件等），使用强制缓存。前端资源一般带 hash，hash 是根据内容生成的，内容不变，hash 不变。 2. 对于可能变化的资源（如 HTML、API 数据等），使用协商缓存 3. 对于 ETag 和 Last-Modified，优先使用 ETag，因为它更精确 4. 在实际项目中，通常两种缓存机制结合使用 # Cookie 与 Session ## Cookie Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。 ![[Pasted image 20260518145617.png]] ### Cookie 的特点 - **客户端存储**：Cookie 存储在用户的浏览器中，而不是服务器上 - **容量限制**：单个 Cookie 的大小通常不超过 4KB - **数量限制**：每个域名下的 Cookie 数量有限制（通常为 20-50 个） - **有效期**：可以设置过期时间，也可以是会话期 Cookie（关闭浏览器即失效） - **域名限制**：只能被特定域名的页面访问 ### Cookie 的常用属性 Cookie 有以下几个重要属性： - **name/value**：Cookie 的名称和值 - **domain**：指定 Cookie 对于哪个域是有效的 - **path**：指定 Cookie 在哪个路径下有效 - **expires/max-age**：设置 Cookie 的过期时间 - **secure**：只在 HTTPS 连接中传输 Cookie - **httpOnly**：防止 JavaScript 访问 Cookie，只能通过 HTTP 请求携带 - **sameSite**：控制 Cookie 在跨站请求时是否被发送 ### 设置与获取 Cookie 服务端通过设置响应头 `Set-Cookie` 来创建 Cookie： ```http HTTP/1.1 200 OK Content-Type: text/html Set-Cookie: username=张三; expires=Wed, 21 Oct 2023 07:28:00 GMT; path=/; domain=example.com Set-Cookie: sessionId=abc123; HttpOnly; Secure ``` 浏览器发送请求时会自动在请求头中携带 Cookie： ```http GET /index.html HTTP/1.1 Host: www.example.com Cookie: username=张三; sessionId=abc123 ``` ### Cookie 的应用场景 1. **用户认证**：存储登录状态和用户标识 2. **个性化设置**：保存用户偏好，如网站主题、字体大小等 3. **追踪与分析**：记录用户行为，如购物车、浏览历史等 4. **广告定向投放**：基于用户兴趣的广告推送 ## Session Session 是在服务端保持的一个状态，用来跟踪用户状态的机制，可以理解为服务器端的"会话"。 ### Session 的工作原理 1. 用户首次访问服务器时，服务器创建一个 Session 并生成一个唯一的 Session ID 2. 服务器将 Session ID 通过 Cookie 发送给浏览器 3. 浏览器后续的请求会携带这个 Session ID 4. 服务器通过 Session ID 识别用户并检索对应的 Session 数据 ### Session 的特点 - **服务端存储**：Session 数据存储在服务器端，不存在客户端容量限制 - **安全性更高**：敏感数据保存在服务器，不暴露给客户端 - **存储方式多样**：可以存储在内存、文件系统、数据库或分布式缓存中 - **有效期**：通常有超时机制，一段时间不活动后自动失效 - **依赖标识符**：通常依赖 Cookie 中的 Session ID 来识别用户 ### Session 的实现方式 服务端创建 Session 并通过 Cookie 传递 Session ID： go复制代码 ```go // Go语言的简单Session实现示例 func handleLogin(w http.ResponseWriter, r *http.Request) { // 验证用户身份 username := r.FormValue("username") password := r.FormValue("password") if authenticateUser(username, password) { // 创建Session sessionID := generateSessionID() sessions[sessionID] = &Session{ UserID: getUserID(username), Username: username, Created: time.Now(), } // 设置Cookie cookie := &http.Cookie{ Name: "sessionid", Value: sessionID, Path: "/", HttpOnly: true, MaxAge: 3600, // 1小时 } http.SetCookie(w, cookie) // 重定向到用户页面 http.Redirect(w, r, "/user", http.StatusFound) } else { http.Error(w, "Invalid credentials", http.StatusUnauthorized) } } ``` ### Cookie 与 Session 的区别 |特性|Cookie|Session| |---|---|---| |存储位置|客户端（浏览器）|服务端| |安全性|较低，可被客户端查看和修改|较高，数据存储在服务器| |存储容量|有限制（通常 4KB 以内）|理论上无限制| |生命周期|可长期保存|通常随会话结束而清除| |对服务器负担|较小|较大| |跨域支持|有限制|默认不支持跨域| ### 安全最佳实践 1. **使用 HttpOnly 标志**：防止 JavaScript 访问 Cookie，减少 XSS 攻击风险 2. **使用 Secure 标志**：确保 Cookie 只通过 HTTPS 传输 3. **设置合理的过期时间**：减少 Cookie 被盗用的风险 4. **加密敏感数据**：不在 Cookie 中存储明文的敏感信息 5. **使用 SameSite 属性**：防止 CSRF 攻击 6. **定期更新 Session ID**：尤其是在用户权限变更后 # 关于RESTFUL 扩展阅读：[阮一峰：RESTful API 设计指南](https://www.ruanyifeng.com/blog/2014/05/restful_api.html) > 注意： 有的服务的 API 并不是基于 RESTFUL 风格，只有 GET/POST，这是正常的。 > 例如：删除用户 `POST /api/deleteuser`，而不是 `DELETE /api/user/123` > 基于老项目开发新接口，如果老项目是基于 RESTFUL 风格，那么新接口也尽量保持一致。 # 其它需要了解的 - 什么是长连接，一般用于什么场景？ - websocket 是基于 http 协议的吗?主要用于什么场景？ - 什么是 auth2.0，主要用于什么场景？ - 什么是 JWT，主要用于什么场景？ - http 鉴权方案有哪些？