基础班前端学习之路-Day6 | 青训营

Simple_WH
118 阅读9分钟

初识HTTP

1.1 什么是HTTP

HTTP：超文本传输协议（Hyper Text Transfer Protocol）

HTTP协议是应用层协议，其底层是基于TCP协议做的传输层协议，经过了TSL/SSL加密

对称加密：加密和解密都是使用同一个密钥

非对称加密：加密和解密需要使用两个不同的密钥—公钥和私钥

每个HTTP请求都分为请求和响应两部分，HTTP请求都是语义比较简单的请求，在设计上可以提供很多扩展的能力，即HTTP协议是一个简单可扩展的协议

HTTP是一个无状态的协议，每一个请求之间都是相互孤立的，当前的请求是无法获取之前携带过什么信息，做过什么事情

1.2 协议分析

发展

  • HTTP/0.9-单行协议

    • 只有GET和目标地址一行
    • 只能承载HTML文档

  • HTTP/1.0-构建可扩展性

    • 增加了Header和状态码
    • 可以支持多种文档
    • ……

  • HTTP/1.1-标准化协议

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

  • HTTP/2-更优异的表现

    • 二进制协议
    • 压缩header
    • 服务器推送
    • ……

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

    消息：与逻辑请求或响应消息对应的完整的一系列帧

    数据流：已建立的连接内的双向字节流，可以承载一条或多条消息

    交错发送，接收方重组织

    HTTP/2连接都是永久的，而且仅需要每个来源一个连接

    流控制：阻止发送方向接收方发送大量数据的机制

  • HTTP/3-草案

报文

Method

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

特性

  • Safe：不会修改服务器的数据的方法，如GET，HEAD，OPTIONS
  • Idempotent（幂等）：同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的，所有safe的方法都是幂等的，如GET，HEAD，OPTIONS，PUT，DELETE

状态码

用三位数字来表示，开头从1~5，不同的开头有不同的含义

  • 1XX：指示信息，表示请求已接收，继续处理，一般很少见

  • 2XX：成功，表示请求已被成功接收、理解、接受

    • 200 OK—客户端请求成功

  • 3XX：重定向，要完成请求必须进行更进一步的操作

    • 301—资源（网页等）被永久转移到其它URL
    • 302—临时跳转

  • 4XX：客户端错误，请求有语法错误或请求无法实现

    • 401 Unauthorized—请求未经授权
    • 404—请求资源不存在，可能是输入了错误的URL

  • 5XX：服务器端错误，服务器未能实现合法的请求

    • 500—服务器内部发生了不可预期的错误
    • 504 Gateway Timeout—网关或者代理的服务器无法在规定的时间内获得想要的响应

RESTful APL

RESTful APL：一种API设计风格

REST—Representational State Transfer

设计规则

  1. 每个URI代表一种资源
  2. 客户端和服务器之间，传递这种资源的某种表现层
  3. 客户端通过HTTP method，对服务器端资源进行操作，实现“表现层状态转化”
请求返回码含义
GET/zoos200 OK列出所有动物园，服务器成功返回了
POST/zoos201 CREATED新建一个动物园，服务器创建成功
PUT/zoos/ID400 INVALID REQUEST更新某个指定动物园的信息（提供该动物园的全部信息） 用户发出的请求有错误，服务器没有进行新建或修改数据的操作
DELETE/zoos/ID204 NO CONTENT删除某个动物园，删除数据成功

常用请求头

Accept接收类型，表示浏览器支持的MIME类型（对标服务器返回的Content-Type）
Content-Type客户端发送出去实体内容的类型
Cache-Control指定请求和响应遵循的缓存机制，如no-cache
If-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服务端返回的实体内容的类型
Cahe-Control指定请求和响应遵循的缓存机制，如no-cache
Last-Modified请求资源的最后修改时间
Expires应该在什么时候认为文档已经过期，从而不再缓存它
Max-age客户端的本地资源应该缓存多少秒，开启了Cache-Control后有效
ETag资源的特定版本的标识符，Etags类似于指纹
Set-Cookie设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端
Server服务器的一些相关信息
Access-Control-Allow-Orgin服务器允许的请求Origin头部（譬如为*）

缓存

  • 强缓存

    • Expires，时间戳

    • Cache-Control

      • 可缓存性

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

      • 到期

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

      • 重新验证*重新加载

        • must-revalidate：一旦资源过期，在成功向原始服务器验证之前，不能使用

  • 协商缓存

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

HTTP-1.png

cookie

Set-Cookie-response

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

场景分析

2.1 静态资源

今日头条

  1. 打开chrome

  2. 打开网站链接

  3. 打开控制台

    • 右键 → 检查
    • F12

  4. 切换至network（网络）

状态码200也不一定就发起了请求

HTTP-2.png

  • 缓存策略

    • 强缓存
    • Cache-control：一年

  • 允许所有域名访问

  • 资源类型：CSS

静态资源方案：缓存+CDN+文件名hash

CDN：Content Delivery Network

通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务

2.2 登录

业务场景

  • 表单登录
  • 扫码登录

技术方式：SSO

HTTP-3.png

  • 账号密码登录
  • 打开控制台 → network → 勾选preserve log → 过滤quick_login
  • 观察请求

HTTP-4.png

跨域，cross-origin导致了options的请求

流程

  1. 向什么地址做了上面动作

  2. 携带了哪些信息，返回了哪些信息

    • 携带信息

      • Post body，数据格式为form
      • 希望获取的数据格式为json
      • 已有的cookie

    • 返回信息

      • 数据格式json
      • 种cookie的信息

“same-origin” “cross-origin”

HTTP-5.png

HTTP-6.png

  • CORS（Cross-Origin Resource Sharing）

  • 预请求：获取服务端是否允许该跨源请求（复杂请求）

  • 相关协议头

    • Access-Control-Allow-Origin
    • Access-Control-Expose-Headers
    • Access-Control-Max-Age
    • Access-Control-Allow-Credentials
    • Access-Control-Allow-Methods
    • Access-Control-Allow-Headers
    • Access-Control-Request-Method
    • Access-Control-Request-Headers
    • Origin

HTTP-7.png

跨域解决方案

  • 代理服务器

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

  • Iframe

    诸多不便

鉴权

HTTP-8.png

SSO-单点登录（Single Sign On）

HTTP-9.png

实战

3.1 浏览器篇

AJAX之XHR

XHR：XMLHttpRequest

readyState

0UNSENT代理被创建，但尚未调用open()方法
1OPENEDopen()方法已经被调用
2HEADERS_RECEIVEDsend()方法已经被调用，并且头部和状态已经可获得
3LOADING下载中；responseText属性已经包含部分数据
4DONE下载操作已完成

HTTP-10.png

AJAX之Fetch

  • XMLHttpRequet的升级版
  • 使用Promise
  • 模块化设计，Response，Request，Header对象
  • 通过数据流处理对象，支持分块读取

HTTP-11.png

3.2 node篇

标准库：HTTP/HTTPS

  • 默认模块，无需安装其他依赖
  • 功能有限/不是十分友好

HTTP-12.png

常用的请求库：axios

  • 支持浏览器、nodejs环境
  • 丰富的拦截器

HTTP-13.png

3.3 用户体验

网络优化

HTTP-14.png

CDN开启H2的性能会更好

预解析、预连接

 <link rel="dns-prefetch" href="//example.com">
 <link rel="preconnect" href="//cdn.example.com" crossorigin>

稳定性

HTTP-15.png

  • 重试是保证稳定的有效手段，但要防止加剧恶劣情况
  • 缓存合理使用，作为最后一道防线

3.4 扩展

通信方式

WebSocket

  • 浏览器与服务器进行全双工通讯的网络技术
  • 典型场景：实时性要求高，例如聊天室
  • URL使用ws://或wss://等开头

HTTP-16.png

QUIC（Quick UDP Internet Connection）

  • 0-RTT建联（首次建联除外）
  • 类似TCP的可靠传输
  • 类似TLS的加密传输，支持完美前向安全
  • 用户空间的拥塞控制，最新的BBR算法
  • 支持h2的基于流的多路复用，但没有TCP的HOL问题
  • 前向纠错FEC
  • 类似MPTCP的Connection migration

HTTP-17.png

HTTP-18.png

avatar
文章
阅读
粉丝