HTTP 使用指南 | 青训营

无敌矿工
544 阅读5分钟

初识HTTP

  • Hyper Text Transfer Protocol 超文本传输协议
  • 应用层协议，基于TCP协议
  • 请求响应
  • 简单可扩展 Header中可以配置信息
  • 无状态 每个请求都是孤立的，

协议分析

  • HTTP/0.9 单行协议

    • 响应只有HTML文档
    • 请求 GET/mypage.html

  • HTTP/1.0 构建可扩展性

    • 增加了Header
    • 有了状态码
    • 支持多种文档类型

  • HTTP/1.1 标准化协议

    • 链接复用
    • 缓存
    • 内容协商

  • HTTP/2.0 更优异的表现

    • 二进制协议
    • 压缩Header
    • 服务区推送

协议分析-报文

Method

Method用途
Get请求一个指定资源形式，使用Get请求要改制备用于获取数据
Post用于将实体提交到指定资源通常导致在服务器上的状态变化或副作用
PUT用于请求有效载荷替换目标资源的所有当前表示
DELETE删除指定资源
HEAD请求一个与GET请求的响应相同的响应，但没有响应体
CONNECT建立一个由目标资源表示的服务器隧道
OPTIONS用于描述目标资源的通信选项
TRACE沿着目标资源的路径执行一个消息环测试
PATCH用于对资源应用的部分修改

安全的请求是不会修改服务器的数据，只读的

状态码

状态码代表含义
1xx指示信息，表示请求已接收
2xx成功表示请求已被唱功理解接收，接受
3xx重定向 要完成请求必须进行更进一步的操作
4xx客户端错误，请求有语法错误或请求无法实现
5xx服务端错误，服务器未能实现合法的请求

常见请求头

请求头含义
Accept接收类型，表示浏览器支持的MIME类型 (对标服务端返回的Content-Type)
Content-Type客户端发送出去实体内容的类型
Cache-Control指定请求和响应遵循的缓存机制，如no-cache
f-Modified-Since对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内
Expires缓存控制，在这个时间内不会请求，直接使用缓存，服务端时间
Max-age代表资源在本地缓存多少秒，有效时间内不会请求，而是使用缓存
If-None-Match对应服务端的ETag，用来匹配文件内容是否改变 (非常精确)
Cookie有cookie并且同域访问时会自动带上
Referer该页面的来源URL(适用于所有类型的请求，会精确到详细页面地址，csrf拦截常用到这个字段)
Origin最初的请求是从哪里发起的 (只会精确到端口)Origin比Referer更尊重隐私
User-Agent用户客户端的一些必要信息，如UA头部等

常用响应头

响应头含义
Content-Type服务端返回的实体内容的类型
Cache-Control指定请求和响应遵循的缓存机制，如no-cache
Last-Modified请求资源的最后修改时间
Expires应该在什么时候认为文档已经过期,从而不再缓存它
Max-age客户端的本地资源应该缓存多少秒，开启了Cache-Control后有效
ETag资源的特定版本的标识符，Etags类似于指纹
Set-Cookie设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端
Server服务器的一些相关信息
Access-Control-Allow-Origin服务器端允许的请求Origin头部 (警如为*)

缓存

强制缓存

  • Expires。时间戳
  • Cache-Control

    • 可缓存性

      • no-cache：协商缓存验证
      • no-stire： 不使用任何缓存

    • 到期

      • max-age：单位是秒，存储的最大周期，相对于请求的时间

    • 重新验证*重新加载

      • must-revalidate ：资源一旦国企在重新向原始服务器验证之前不能使用

协商缓存

  • Etag/if-None-Match ： 资源的特定版本标识符，类似于指纹
  • Last-Modified/ifModified-Since 最后修改时间

image.png

Cookie

Cookie
Name=value各种cookie的名称和值
Expires=DateCookie 的有效期，缺省时Cookie仅在浏览器关闭之前有效。
Path=Path限制指定Cookie 的发送范围的文件目录，默认为当前
Domain=domain限制cookie生效的域名，默认为创建cookie的服务域名
secure仅在HTTPS 安全连接时，才可以发送Cookie
HttpOnlyJavaScript 脚本无法获得Cookie
SameSite=[NonelStrictlLax]None 同站、跨站请求都可发送Strict 仅在同站发送允许与顶级导航一起发送，并将与第三方网站发起的GET请求一起发送

协议发展

HTTP/2.0 更快，更稳定，更简单

  • HTTP/2 链接都是永久的，而且仅需要每个来源一个连接
  • 流控制： 阻止发送方向接受发送大量数据的机制
  • 服务器推送

HTTPS

  • 经过TSL/SSL 加密
  • 对称加密： 加密和解密都是使用同一个密钥
  • 非对称加密： 加密和解密 需要使用两个不同的密钥。公钥和私钥

image.png

场景分析-静态资源

以下是一个静态资源的请求信息

强缓存。Cache-control ：一个月

允许所有类型域名访问， 资源类型CSS

image.png

场景分析跨域

解决方案：

  • CORS

  • 代理服务器

    • 同源策略是浏览器的安全策略不是HTTP的

  • Ifram 比较麻烦

登录场景

鉴权

  1. Session + cookie

image.png

  1. jwt（jsonweb+token）

image.png

适合使用jwt的场景: 有效期短，只希望被使用一次，比如注册后发送一封邮件，让其激活账号，通胀邮箱中有一个链接具备以下特性，能够表示用户（通常几个小时内激活）不能纂改已激活其他账号，一次性的，这种场景就是和使用jwt。而jwt具有一次性的特性。单点登录和会话管理非常不适合使用jwt。如果服务器部署额外的逻辑存储jwt的状态，那还不如使用session，基于session有很成熟的框架可以开箱即用，但是用jwt还要自己实现逻辑

avatar
文章
阅读
粉丝