一、http定义
介绍
HTTP（超文本传输协议，英语：HyperText Transfer Protocol）是一个用于传输超媒体文档（例如 HTML）的应用层协议，是万维网的数据通信的基础。
版本
- 1999年6月公布的 RFC 2616，定义了 HTTP 协议中现今广泛使用的一个版本 HTTP 1.1。
- 2015年5月以 RFC 7540 正式发布 HTTP/2 标准，取代 HTTP 1.1 成为 HTTP 的实现标准。
- 2022年6月6日标准化为 RFC9114 的最新版本 HTTP/3，抛弃使用 TCP，通过 UDP 上使用 QUIC 来承载应用层数据。
通信过程
- 使用 TCP 协议，通过网页浏览器、网络爬虫或者其它的工具，客户端（user agent，用户代理程序）发起一个 HTTP 请求到服务器上指定端口（默认端口为80）。
- 应答的服务器（origin server）上存储着一些资源，比如 HTML 文件和图像，服务器在那个端口监听客户端的请求。在用户代理和源服务器中间可能存在多个“中间层”，比如代理服务器、网关或者隧道（tunnel）。
- 一旦收到请求，服务器会向客户端返回一个状态，比如"HTTP/1.1 200 OK"，以及返回的内容，如请求的文件、错误消息、或者其它信息。
- 每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。HTTP/2 中的连接具有复用性，即每个目标地址建立连接后，可以永久被利用，所以每个来源仅需要一个连接。
请求方法
它们都实现了不同的语义，但根据共同的特征由可以分类为：safe（安全）, idempotent（幂等）, 或 cacheable（可缓存）。
- GET 的请求应该只被用于获取数据。
- HEAD 方法请求一个与 GET 请求的响应相同的响应，但没有响应体。
- POST 方法用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用。
- PUT 方法用请求有效载荷替换目标资源的所有当前表示。
- DELETE 方法删除指定的资源。
- CONNECT 方法建立一个到由目标资源标识的服务器的隧道。
- OPTIONS 方法用于描述目标资源的通信选项。
- TRACE 方法沿着到目标资源的路径执行一个消息环回测试。
- PATCH 方法用于对资源应用部分修改。
Safe（安全）
- 指这是个不会修改服务器的数据的方法，也就是说，这是一个对服务器只读操作的方法。
- 浏览器调用安全的方法不用考虑会给服务端造成什么危害，这样，服务端就能允许客户端预加载资源。
- 这些方法是安全的：GET，HEAD 和 OPTIONS。所有安全的方法都是幂等的，但并非所有幂等方法都是安全的，例如，PUT 和 DELETE 都是幂等的，但不是安全的。
1.1协议分析
报文
方法
状态码
请求头
- HTTP 标头是用于 HTTP 请求或响应的字段，它传递关于请求或者响应的额外上下文和元数据。
- 例如，请求消息可以使用标头表明它首选的媒体格式，而响应可以使用标头表明返回主体的媒体格式。
- 标头是不区分大小写，开始于行首，后面紧跟着一个 ':' 和与之相关的值。字段值在一个换行符（CRLF）前或者整个消息的末尾结束。
- 根据不同的消息上下文，标头可以分为：
- 请求标头：包含要获取的资源或者客户端自身的更多信息。例如，Accept-* 标头指示响应的允许格式和首选格式。其他标头可用于提供身份验证凭据（Authorization、Token 授权等）、控制缓存或获取有关用户代理（user agent）或引荐来源网址（referrer）等的信息。
- 响应标头：包含有关响应的额外信息，例如响应的位置（Location）、响应时间（Date）、最后更新时间（Last-Modified）或者关于服务器自身的信息（Server，包括名字、版本等）。
- 表示标头：包含消息主体中资源的元数据（例如，编码、MIME 媒体类型、压缩方案等）。包括 Content-Type、Content-Encoding、Content-Language 和 Content-Location。
- 有效负荷标头：包含有关有效载荷数据表示的单独信息，包括内容长度和用于传输的编码。包括 Content-Length、Content-Range、Trailer 和 Transfer-Encoding。
- 并非所有可以出现在请求中的标头都被规范称为请求标头，并非所有出现在响应中的标头都根据规范将其归类为响应标头。例如，Content-Type 就是一个表示标头，在请求中 (如 POST 或 PUT)，客户端告诉服务器实际发送的数据类型；在响应中，Content-Type 标头告诉客户端实际返回的内容的内容类型。
响应头
缓存
强缓存
-
Expires，时间戳
-
Cache-Control
-
可缓存性
- no-cache：协商缓存验证
- no-store不使用任何缓存
-
到期
- max-age：单位秒，最大缓存周期，相当于请求时间
-
重新验证*重新加载
- must-revalidate：—旦资源过期．在成功向原始服务器验证之前,不能使用
-
协商缓存
- Etag/If-None-Match：资源的特定版本的标识符，类似于指纹
- Last-Modified/lf-Modified-Since:最后修改时间
下图是浏览器缓存的机制，所以不一定状态为200的都经过完整的TCP流程，可能数据来自于缓存
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
(HTTP 304状态码的详细讲解_web_blog的博客-CSDN博客)
cookie
Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据。HTTP 是无状态协议，这意味着服务器不会在两个请求之间保留任何数据（状态），而 Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。浏览器会存储 Cookie 并在下次向同一服务器再发起请求时携带并发送到服务器上。
工作机制如下：
服务器使用Set-Cookie 响应标头向用户代理（一般是浏览器）发送 Cookie 信息。例如：
Set-Cookie: <cookie-name>=<cookie-value>
这指示服务器发送标头告知客户端存储一对 Cookie：
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry
[页面内容]
现在，对该服务器发起的每一次新请求，浏览器都会将之前保存的 Cookie 信息通过Cookie 请求标头再发送给服务器。
GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
Secure 属性和 HttpOnly 属性可以确保 Cookie 被安全发送，并且不会被意外的参与者或脚本访问。
- 标记为 Secure 的 Cookie 只应通过被 HTTPS 协议加密过的请求发送给服务端。它永远不会使用不安全的 HTTP 发送（本地主机除外），这意味着中间人攻击者无法轻松访问它。不安全的站点（http）无法使用 Secure 属性设置 Cookie。但是，Secure 不会阻止对 Cookie 中敏感信息的访问。例如，有权访问客户端硬盘（如果未设置 HttpOnly 属性，则有权访问 JavaScript）的人可以读取和修改它。
- JavaScript Document.cookie 无法访问带有 HttpOnly 属性的 Cookie,此类 Cookie 仅作用于服务器。例如，持久化服务器端会话的 Cookie 不需要对 JavaScript 可用，而应具有 HttpOnly 属性。此预防措施有助于缓解跨站点脚本（XSS）攻击。
Cookie 主要用于以下三个方面：
- 会话状态管理 - 如用户登录状态、购物车、游戏分数或其它需要记录的信息
- 个性化设置 - 如用户自定义设置、主题和其他设置
- 浏览器行为跟踪 - 如跟踪分析用户行为等
Cookie 曾一度用于客户端数据的存储，因当时并没有其它合适的存储办法而作为唯一的存储手段，但现在推荐使用现代存储 API。新的浏览器 API 已经允许开发者直接将数据存储到本地，如使用 Web storage API（localStorage 和 sessionStorage）或 IndexedDB。
