Day05：初识 HTTP 协议 ｜ 青训营笔记

Sefank
92 阅读7分钟

这是我参与「第五届青训营」伴学笔记创作活动的第 5 天。

HTTP协议及其基本特点

浏览器请求的全过程：

HTTP（Hyper Text Transfer Protocol）协议是OSI模型中应用层的协议，其基于传输层的TCP协议。

  • 基于请求（Request）与响应（Response）模型描述信息传输的模式
  • 简单可扩展：可以自定义请求/响应头部的许多属性，请求/响应体的内容也可以多种多样。
  • 无状态：每个请求都是独立的，HTTP请求本身不依赖于其他的请求承载的信息，即HTTP本身不记忆信息。

协议分析

协议发展

image.png

HTTP/2：更快、更稳定、更简单

帧（frame）：HTTP/2通信的最小单位，每个帧都包含帧头，至少也会标识出当前帧所属的数据流。

  • 二进制
  • 采用了新的压缩算法
  • 交错发送，接收方重组织

  • 消息：与逻辑请求或响应消息对应的完整的一系列帧。
  • 数据流：已建立的连接内的双向字节流，可以承载一条或多条消息。

  • HTTP/2连接都是永久的，而且仅需要每个来源一个连接
  • 流控制：阻止发送方向接收方发送大量数据的机制（现在客户端可以拒绝来自服务器的数据）
  • 服务端可以向客户端预先推送数据（需要服务器和浏览器支持）

HTTPS：HTTP的加密版本

HTTPS: HTTP Secure，经过TSL/SSL加密

  • 对称加密：加密和解密都是使用同一个密钥
  • 非对称加密，加密和解密需要使用两个不同的密钥：公钥（public key）和私钥（private key）

报文

以HTTP/1.1为例

Method

常用方法：

  • GET：请求一个指定资源的表示形式使用GET的请求应该只被用于获取数据
  • POST：用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用
  • PUT：用请求有效载荷替换目标资源的所有当前表示
  • DELETE：删除指定的资源

不太常用的方法：

  • HEAD：请求一个与GET请求的响应相同的响应，但没有响应体
  • CONNECT：建立一个到由目标资源标识的服务器的隧道
  • OPTIONS：用于描述目标资源的通信选项
  • TRACE：沿着到目标资源的路径执行一个消息环回测试
  • PATCH：用于对资源应用部分修改
  • 安全方法（Safe）：不会修改服务器的数据的方法
    • GET
    • HEAD
    • OPTIONS
  • 幂等方法（Idempotent）：同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的
    • GET
    • HEAD
    • OPTIONS
    • PUT
    • DELETE

所有安全方法都是幂等的！

状态码

  • 1XX：指示信息，表示请求已接收，继续处理
  • 2XX：成功，表示请求已被成功接收、理解、接受
  • 3XX：重定向，要完成请求必须进行更进一步的操作
  • 4XX：客户端错误，请求有语法错误或请求无法实现
  • 5XX：服务器端错误，服务器未能实现合法的请求

常见状态码：

  • 200：客户端请求成功
  • 301：资源（网页等）被永久转移到其它URL
  • 302：临时跳转
  • 401：请求未经授权
  • 404：请求资源不存在，可能是输入了错误的URL
  • 500：服务器内部发生了不可预期的错误
  • 504：网关或者代理的服务器无法在规定的时间内获得想要的响应

RESTful API

REST - Representational State Transfer

RESTful API是一种API设计风格，要求API设计满足以下特点：

  • 每一个URI代表一种资源
  • 客户端和服务器之间，传递这种资源的某种表现层
  • 客户端通过HTTP Method，对服务器端资源进行操作，实现“表现层状态转化”

例子：

请求返回码含义
GET /zoos200 OK列出所有动物园，服务器成功返回了结果
POST /zoos201 CREATED新建一个动物园，服务器创建成功
PUT /zoos/ID400 INVALID REQUEST更新某个指定动物园的信息（提供该动物园的全部信息）
用户发出的请求有错误，服务器没有进行新建或修改数据的操作
DELETE /zoos/ID204 NO CONTENT删除某个动物园，删除数据成功

常用请求头

  • Accept：允许接收资源的类型，表示浏览器支持的MIME类型（对标服务端返回的Content-Type）
  • Content-Type：客户端发送出去实体内容的类型
  • Cookie：有cookie并且同域访问时会自动带上
  • Referer：该页面的来源URL（适用于所有类型的请求，会精确到详细页面地址，CSRF拦截常用到这个字段）
  • Origin：最初的请求是从哪里发起的（只会精确到端☐），Origin比Referer更尊重隐私
  • User-Agent：用户客户端的一些必要信息，如UA头部等

缓存相关：

  • Cache-Control：指定请求和响应遵循的缓存机制，如no-cache
  • If-Modified-Since：对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内
  • Expires：缓存控制，在这个时间内不会请求，直接使用缓存，服务端时间
  • Max-age：代表资源在本地缓存多少秒，有效时间内不会请求，而是使用缓存
  • If-None-Match：对应服务端的ETag，用来匹配文件内容是否改变（非常精确）

常用响应头

  • Content-Type：服务端返回的实体内容的类型
  • Set-Cookie：设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端
  • Server：服务器的一些相关信息
  • Access-Control-Allow-Origin：服务器端允许的请求Origin头部（譬如为*）

缓存相关：

  • Cache-Control：指定请求和响应遵循的缓存机制，如no-cache
  • Last-Modified：请求资源的最后修改时间
  • Expires：应该在什么时候认为文档已经过期，从而不再缓存它
  • Max-age：客户端的本地资源应该缓存多少秒，开启了Cache-Control后有效
  • ETag：资源的特定版本的标识符，Etags类似于指纹

缓存

  • 强缓存：本地有就用本地的，不再进一步检查
    • Expires：超过此时间即过期
    • Cache-Control：指定请求和响应遵循的缓存机制
      • 可缓存性控制
        • no-cache：协商缓存验证
        • no-store：不使用任何缓存
      • 到期时间
        • max-age：允许缓存的时长（自请求时间起计算），单位是秒
      • 重新验证/重新加载
        • must-revalidate：一旦资源过期，在成功向原始服务器验证之前，不能使用（未设置该选项，即使资源过期，在连接断开无法恢复的场景中缓存依然可用）
  • 协商缓存：本地有的时候仍然要和服务端协商看看能不能用
    • Etag/If-None-Match：资源的特定版本的标识符，类似于指纹
    • Last-Modified/If-Modified-Since：最后修改时间

缓存全流程：

缓存全流程

Cookie

响应头中的Set-Cookie字段可以携带以下内容：

  • <cookie-name>=<cookie-value>：Cookie键值对（实际保存的内容）
  • Expires=<date>（可选）：Cookie的最长有效时间。未指定则在会话结束（客户端被关闭）时过期
  • Path=<path-value>（可选）：限制指定Cookie的发送范围的文件目录，默认为当前URL
  • Domain=<domain-value>（可选）：限制Cookie生效的域名，默认为创建Cookie的服务域名
  • Secure：只有在请求使用https协议（localhost不受此限制）的时候才会被发送到服务器，用于阻止“中间人攻击”。
  • HttpOnly：用于阻止 JavaScript 通过Document.cookie属性访问 cookie。但是通过AJAX技术发送请求时这些Cookie仍然会被发送。
  • SameSite=<samesite-value>：允许服务器设定cookie是否随着跨站请求一起发送，这样可以在一定程度上防范跨站请求伪造攻击（CSRF）。可选值：
    • Strict：仅对同一站点（协议、域名、端口相同）的请求发送
    • Lax（默认值）：不会在跨站请求中被发送（如加载图像或iframe）；但cookie在用户从外部站点导航到源站时则会发送
    • None：跨站和同站请求中均发送；在设置这一属性值时，必须同时设置 Secure 属性
avatar
文章
阅读
粉丝