这是我参与「第五届青训营 」伴学笔记创作活动的第 5天
前置课程
web标准与前端开发
- 前端的起源、架构及变迁
- 前端的应用领域
- 开发中常用的语言框架及工具
- 前端学习路线推荐
前端的起源、架构及变迁
转译——通过一种语言转换为不同版本或者抽象程度相同的语言,比如babel将es6转译成es5语言
http
初识http
http协议版本
[HTTP]议状态码，是指在HTTP协议运行中由客户端发出请求连接，服务端建立连接；客户端发出HTTP请求（Request），服务端返回响应信息（Respond），而在这个过程中由于客户端或服务端的问题会返回相应的错误代码并显示给用户，对应的错误代码表示不同的错误信息，根据这个信息用户可以调整相应的操作来修改出现的错误，最终避免错误的再现。
链接复用：新的请求可以在上次建立的tcp连接之上发送，连接可以复用。——减少重复进行tcp三次握手的开销，提高效率
HTTP 缓存：304 代表表示告诉浏览器，本地有缓存数据，可直接从本地获取，无需从服务器获取浪费时间。
HTTP 头信息控制缓存
大致分为两种：强缓存和协商缓存。强缓存如果命中缓存不需要和服务器端发生交互，而协商缓存不管是否命中都要和服务器端发生交互，强制缓存的优先级高于协商缓存。具体内容下文介绍。
- 强缓存 对强缓存来说，响应头中有两个字段 Expires(指缓存过期的时间)/Cache-Control 来表明规则。 Cache-Control 可以由多个字段组合而成，主要有以下几个取值：
- max-age 指定一个时间长度，在这个时间段内缓存是有效的
- public 表明响应可以被任何对象（发送请求的客户端、代理服务器等等）缓存。
- no-cache 强制所有缓存了该响应的用户，在使用已缓存的数据前，发送带验证器的请求到服务器。
- no-store 禁止缓存，每次请求都要向服务器重新获取数据。
- 协商缓存——解决强缓存资源不能及时更新的问题
缓存的资源到期了，并不意味着资源内容发生了改变，如果和服务器上的资源没有差异，实际上没有必要再次请求。客户端和服务器端通过某种验证机制验证当前请求资源是否可以使用缓存。
浏览器第一次请求数据之后会将数据和响应头部的缓存标识存储起来。再次请求时会带上存储的头部字段，服务器端验证是否可用。
协商缓存服务端可以通过2种设置来实现：
- 第一种：last-modified 配合 If-Modified-Since
last-modified值是第一次请求发生时的时间戳,它会随着响应头返回,再次请求的时候请求头会携带上If-Modified-Since,该字段的值是上一次请求的last-modified的值.目的是让服务器知道上一次请求的时间,对比该资源在服务器上最后一次修改的时间,判断在这段时间内资源是否发生了改变
If-Modified-Since：请求时会带上的一个时间与last-modified保持一致。
- Etag 配合 If-None-Match etag的算法和资源内容有关。服务端会根据资源的内容生成一个唯一的etage.当我们修改资源时,资源内容改变会重新生成etag。
当你第一次发起HTTP请求时，服务器会返回一个Etag，
并在你第二次发起同一个请求时，客户端会同时发送一个If-None-Match，而它的值就是Etag的值（此处由发起请求的客户端来设置）。
然后，服务器会比对这个客服端发送过来的Etag是否与服务器的相同，
如果相同，就将If-None-Match的值设为false，返回状态为304， 客户端继续使用本地缓存，不解析服务器返回的数据（这种场景服务器也不返回数据，因为服务器的数据没有变化嘛）
如果不相同，就将If-None-Match的值设为true，返回状态为200，客户端重新解析服务器返回的数据
其实协商缓存机制粗暴来说就是304缓存机制
缓存应用：
考虑缓存的内容：
- css样式文件
- js文件
- logo、图标
- html文件
- 可以下载的内容
一些不应该被缓存的内容：
- 业务敏感的 GET 请求
二进制协议
相比 HTTP/1.1 的纯文本数据，二进制数据一个显而易见的好处是：更小的传输体积。这就意味着更低的负载。二进制的帧也更易于解析而且不易出错，纯文本帧在解析的时候还要考虑处理空格、大小写、空行和换行等问题，而二进制帧就不存在这个问题。
消息头和消息体均采用二进制格式，并称为帧(Frame)。目前有10个Frame，由Type字段来区分，各个Frame都有自己的二进制格式，都封装在Frame Payload中。其中有两个重要的Frame:Header Frame(Type=0x1)和Date Frame(Type=0x0)，分别对应HTTP/1.1中的消息头(Header)和消息体(Body),由此可见语义并没有太大变化，而是文本格式变成二进制的Frame。两者的转换关系如下图:
方法
方法特点
- 安全的——不修改服务器数据
- 幂等请求——同样的请求执行一次还是多次都是一样的
状态码
RESTful API
常用的请求头
content-type:表单 cookie：将无状态的请求转换成有状态的
响应头
HTTP2.0
http1中以文本形式进行传输
-
二进制分帧————>多路复用
-
头部压缩 http2.0在传输的时候，会维护一张请求头部信息的哈希表，并同时存储在客户端和服务端，每次传输的时候，如果发现传输的头部信息在哈希表中已经存在，则只传哈希表的index值，不再传输具体的内容
-
数据推送 服务端向客户端推送信息 服务端会根据文件中关联的其他文件，预判并主动推送下次请求中必须的数据。如获取html文件后，主动推送内联的js/css文件，减少请求次数
-
多路复用
HTTP2.0中,基于二进制分帧层，HTTP2.0可以在共享TCP连接的基础上同时发送请求和响应。 HTTP消息被分解为独立的帧，而不破坏消息本身的语义，交错发出去，在另一端根据流标识符和首部将他们重新组装起来。 通过该技术，可以避免HTTP旧版本的队头阻塞问题，极大提高传输性能。
二进制分帧是在当前HTTPS的TLS协议之上，抽象了一层（也就是说，使用HTTP2.0的前提是必须使用HTTPS）。可以在传输的时候把一个请求拆分成多个很小的数据包，多个请求可以同时拆成许多数据包一起发送，到了服务端，服务端再根据数据包的序号进行拼接，得到完整的每一个请求。
这些拆分的请求最小粒度叫frame，按照类型可分为两类结构：Headers frame和data frame。headers frame是对请求头做了抽象，data frame是针对请求体做了抽象。
http2以帧为单位进行传输，以二进制编码形式 帧 特性：
- 拆成多个帧后不需要按顺序发送，交错发送，接收方重新组织 2。 http2每个连接都是永久的，且仅需要每个来源一个连接
- 流控制：组织发送方向接收方发送大量数据的机制
- 服务器可以主动推送
https
场景分析
静态资源部署方案
静态资源方案
- 缓存——第二次打开快速，减少请求
- CDN——内容传输更快
- 文件hash
登陆_表单登陆
登陆时存在跨域问题——向其他域名 解决跨域
- CORS
跨域时首先使用options方法进行通信请求，询问服务端是否允许该跨域请求，如
Access-Control-Allow-Origin等协议头 - 代理服务器
- iframe
登录后登陆状态
鉴权（authentication）是指验证用户是否拥有访问系统的权利。 2种鉴权方案
-
session+cookie 访问时post方式将数据传到服务器，服务器进行校验 校验正确，生成session，并将session用setcookie方式保存为cookie 下次携带cookie即可
-
JWT (JSON web token)——通过Json方式来传输的令牌
JWT介绍
JWT的原则是在服务器身份验证之后，将生成一个JSON对象并将其发送回用户 之后，当用户与服务器通信时，客户在请求中发回JSON对象。服务器仅依赖于这个JSON对象来标识用户。为了防止用户篡改数据，服务器将在生成对象时添加签名 服务器不保存任何会话数据，即服务器变为无状态，使其更容易扩展。
JWT的三个部分如下。JWT头、有效载荷和签名
JWT使用方式
- 存储Cookie
- 放在 HTTP 请求的头信息
Authorization字段
跳转网站后自动登录
单点登录SSO:在一个大应用多个子应用下，一次登陆 单点登录就是在多个系统中，用户只需一次登录，各个系统即可感知该用户已经登录。 技术实现：共享 Session
具体细节：
-
同域下的： 通过设置一个登录系统sso.a.com进行登陆(设置cookie），将cookie的domain域设置为顶域，这样所有子域的系统都可以访问到顶域的cookie
-
跨域下的 这种将用户登录信息以cache的方式存放在sso.com，并且将cache的键当做cookie的值保存在各个分站的方式实现了跨域单点登录
这种方式的难点是：怎么在a.com登录的时候将cookie同时写到b.com中。我使用的方式是先在sso.com中维护一个分站集合，在登录成功后以轮询跳转的方式将cookie写到各个分站中。
