HTTP 是用于在网络中获取、提交资源的应用层协议，资源包括 HTML 网页、图片、脚本、JSON 接口等。
- 无状态
- 一对一
1.1 浏览器输入 URL 之后完整流程
- DNS 解析域名，得到服务器 IP
- 浏览器与服务器建立 TCP 连接（传输层）
- 浏览器发送 HTTP 请求报文（应用层协议，运行在 TCP 之上）
- 服务器处理请求，返回 HTTP 响应报文
- 浏览器解析 HTML，发现页面内图片、JS、API 资源，逐个发起新 HTTP 请求，所以一个页面会产生大量数据包。
补充重点：HTTP 是无状态协议，服务器不会记住用户，依靠 Cookie 来维持会话。
1.2 两组易混概念
Site（站点，SameSite 判定）：协议 + 主域名，子域名无关
Origin（源，CORS 同源策略）：协议 + 域名 + 端口，全部一致才算同源
1.3 Cookie 三大安全属性
举个例子： Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax
HttpOnly
禁止 JS document.cookie 读取 Cookie；防御 XSS 攻击
局限：Fetch/Ajax 仍然可以自动携带 Cookie，无法防御 CSRF。他们可异步请求。
Secure 这条 Cookie只在 HTTPS 加密通道传输；普通 HTTP 请求不会携带，防止中间人窃取 SameSite（3 种取值，可防御 CSRF） Strict：最严格，跨站点请求一律不携带 Cookie Lax：浏览器默认策略，普通链接放行，跨站异步请求拦截 None：允许跨站点携带 Cookie，强制必须搭配 Secure 属性，否则浏览器拒绝创建 Cookie
1.4 HTTPS
HTTP 是明文传输，容易被窃听、篡改；HTTPS = HTTP + TLS 加密 HTTPS 工作逻辑：先用非对称加密协商出对称密钥，后续所有数据通信使用对称加密。
1.5 CORS 拓展知识点
同源策略：浏览器安全机制，限制 JS 跨源读取响应 区分简单请求、OPTIONS 预检请求
CORS不能防御 CSRF，CORS 只管前端 JS 能否读取响应，无法阻止请求携带 Cookie
2.1实践
我们用burpsuit访问使用国内 httpbin 镜像 https://httpbin.ceshiren.com，根据抓到的数据包进行分析。完整观察 HTTP 请求响应、Cookie 完整交互流程、各类状态码：
httpbin.ceshiren.com/cookies/set…
| 字段 | 所在位置 | 作用 |
|---|---|---|
| Method | 请求起始行 | 请求方法（GET/POST 等） |
| Path | 请求起始行 | 请求资源路径 |
| Host | 请求头 | 目标服务器域名 |
| User-Agent | 请求头 | 浏览器客户端标识 |
| Cookie | 请求头 | 浏览器携带会话凭证 |
| Referer | 请求头 | 请求来源页面地址 |
| Origin | 请求头 | 仅 Fetch/Ajax 异步请求出现，用于 CORS 校验 |
数据包 1：GET /cookies/set?user=test
请求：首行是方法+目标路径+http版本
响应：状态码是302，代表临时重定向
数据包 2：GET /cookies
请求：Cookie: user=test ，请求头，浏览器自动携带刚刚收到的cookie
响应：状态码200，代表请求成功
Content-Type: application/json，代表这是API接口，返回JSON数据
数据包 3：favicon.ico 图标请求
请求：Referer: httpbin.ceshiren.com/cookies 记录从哪个页面跳转发起本次请求
响应：状态码 404 Not Found
状态码汇总：
2xx（请求成功）
- 200 OK：服务器成功处理请求，正常返回数据
3xx（重定向）
- 301 Moved Permanently：永久重定向；浏览器长期缓存跳转地址
- 302 Found：临时重定向；浏览器临时跳转，不缓存
4xx（客户端侧错误，请求格式 / 权限问题）
- 401 Unauthorized：缺少登录凭证，未登录
- 403 Forbidden：已识别身份，但禁止访问该资源
- 404 Not Found：请求的资源地址不存在
5xx（服务端侧错误）
- 500 Internal Server Error：服务器代码运行异常
- 502 Bad Gateway：反向代理无法连接后端真实业务服务器
