https为什么更安全，怎么验证证书
这一次，彻底理解 https 原理 https防的是服务器中间人
浏览器 --访问--> B站
浏览器 --访问--> 中间人 --转接--> B站
中间人可以通过基站或不安全的wifi等插入进来，此时你的访问被接管，是否转发到目标访问都取决于中间人，且上送数据都被接收
https给访问目标如B站，添加认证，每次访问都需要符合认证。
浏览器会查看访问目标服务器的证书是否和域名匹配 但是证书是公开的，也就是中间人可以下载目标服务器的证书到自己的服务器里，让浏览器检查
除了校验证书内容，还会校验颁发者，当然颁发者也是公开的，中间人也可以配置自己证书为相应的颁发者
这些公开不加密的证书信息可以伪造，但是真正校验证书的是加密签名(签名只能用一次)，服务器上除了要有证书还要有个公开的共钥和不公开的私钥，用于解密证书信息
RSA非对称加密，只能用一次的签名防篡改
CDN
内容分发网络
- 全局负载均衡
- 请求发送到主CDN服务器，智能调度匹配出最佳(近,负载没有超的)节点服务器
- 缓存系统(重点更新缓存,同步源服务器)
- 命中率(取CDN服务器缓存的数量)
- 回源率(取源服务器资源的数量)
网络和并发
http1.0/1.1/2 的区别
- http1.0 每个TCP连接只能发起一次请求，服务器响应后关闭连接。每个请求单独一个TCP连接
- http1.1 TCP连接默认是持久连接，在http1.0中加一个Connetion:keep-alive即可开启,http1.1中手动关闭一个持久连接是 Connetion:close
- 基于TCP持久连接，可以做到一个TCP,多个请求同时发送,管道机制。请求可以同时发送但是响应只能一个一个响应，当一个响应很久时，其他同时发送的请求会一直等待，也就是对头阻塞（请求可以并发，响应不是并发）
webpack的chunk、bundle、module
- bundle：打包后的文件
- chunk：代码块，一个chunk由多个模块module组合
- module：开发过程的模块
webpack的loader、plugin
- loader：处理某一类型的文件，加载器或转化器
- plugin：拓展的webpack的打包方式，由webpack的时机钩子触发
- 一个插件是一个包含aplay方法的对象
各种cssloader的作用
- style-loader: 把处理后的css文件内容插入到
html的head中 - css-loader: 处理css中的模块化,如
背景图和@import css的操作 - sass-loader: 预处理器样式语法的解析器
- postcss-loader: 类似babel对js的作用,通过给样式属性添加前缀来兼容各种高低版本的浏览器
iframe的优缺点
优点 可以解决第三方静态内容加载缓慢的问题； iframe无刷新文件上传； iframe跨域通信；
缺点 iframe会阻塞主页面的onload事件； 无法被搜索引擎捕获到导致不利于SEO； iframe和主页面共享连接池，而浏览器对相同域的连接有限制，所以会影响页面的并行加载 - 增加服务器的http请求； 内存开销大；
通过javascript动态给iframe添加src属性值，这样可以绕开以上两个问题
浏览器内核引擎
浏览器内核主要分成两部分，渲染引擎和JS引擎，渲染引擎负责页面内容（HTML、XML、图像等）输出到网页中，浏览器的内核不同渲染的效果也不同；JS引擎则是解析和执行javascript进而实现网页的动态效果，且两者越来独立化。
浏览器可以通过cookie、ssessionStorage、localStorage进行对数据进行存储，同源策略下均可以访问，但具有一下不同点：
性质不同，cookies是为了标识用户身份而存储用户本地终端上的数据，自动在同源http请求头中携带，cookies在浏览器和服务器间来回传递信息，而sessionstorage和localstorage不会自动把数据发给服务器，仅在本地保存；
存储大小的限制不同，cookie仅可以保存4Kb且数量不超过20条，sessionstorage和localstorage保存的数据可达到5M；
生命周期不同，cookie可以设置生命周期且在过期之前均有效，sessionstorage仅在浏览器窗口关闭之前有效，若不手动删除localstorage则永久有效；
作用域不同，cookie和localStorage在所有的同源标签页（不同页面但域名端口相同）都是共享，而不同标签页面的sessionStorage不共享
HTML页面的渲染过程
浏览器解析HTMLl源码标签，根据标签嵌套创建DOM树，并行加载静态资源文件，每一个HTML标签都是文档树中的一个节点，构成了由documentElement节点为根节点的DOM树；
浏览器解析CSS代码，计算得出样式数据，构建CSSOM树，非法的语法被直接忽略掉，解析CSS的时候按照顺序来定义优先级浏览器默认设置 < 用户设置 < 外链样式 < 内联样式 < !important的规则进行解析；
DOM树和CSSOM树组成渲染树并绘制渲染树到屏幕上；
如果渲染树中的节点被移除、位置改变、元素的显示隐藏等属性改变都会重新执行上面的流程，这一个行为称为回流；
重绘是渲染树上的某一个属性需要更新且仅影响外观、风格，不影响布局，例如：修改background-color就属于重绘只是重新绘制到屏幕中上，回流必定造成重绘；
JS内存
JSBridge原理
Event Bus
贪心算法
javascript精度问题的原因
性能优化的点，webpack分包，首页资源大小，请求优化，gzip之前还是之后，React重新渲染
国际化站点，cdn, 在页面什么阶段加载国际化文件，如果有20多个语言该怎么做
ssr有没有用过
项目中websocket是解决了什么问题
DOM, BOM, js的关系
React dom绑定事件，与原生事件有什么区别
http2多路复用
http状态 301，302， 304,缓存相关字段
cookie、ws是否跨域
触发bfc的方式
介绍下如何实现 token 加密
- 后端 使用一个固定秘钥加密用户标识(uid)+创建token时间(ttl) 通过对称加密(收到客户端提交的token需要解开所有使用堆成加密)的加密算法生成一个字符串,这个字符串就是一个token
- 每次客户端请求都将token放到请求头header中(body参数也可以,无所谓在哪)
- 服务器端收到该请求并使用相同的秘钥解开token,查看token是否过期,也可以通过token中的uid和其他参数比较验证用户的合法性(例如:请求参数中也有一个uid必填参数,这样就可以对比两个uid是否相同
- 如果相同则说明是同一个人,如果单纯的只验证token,只要另外的用户拿到了没过期的token就可以伪造用户身份进行服务器端api的请求)
传统身份验证的方法:
HTTP 是一种没有状态的协议，也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端，客户端使用用户名还有密码通过了身份验证，不过下回这个客户端再发送请求时候，还得再验证一下。
解决的方法就是，当用户请求登录的时候，如果没有问题，我们在服务端生成一条记录，这个记录里可以说明一下登录的用户是谁，然后把这条记录的 ID 号发送给客户端，客户端收到以后把这个 ID 号存储在 Cookie 里，下次这个用户再向服务端发送请求的时候，可以带着这个 Cookie ，这样服务端会验证一个这个 Cookie 里的信息，看看能不能在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端。
上面说的就是 Session，我们需要在服务端存储为登录的用户生成的 Session ，这些 Session 可能会存储在内存，磁盘，或者数据库里。我们可能需要在服务端定期的去清理过期的 Session 。
基于 Token 的身份验证方法:
使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：
- 客户端使用用户名跟密码请求登录
- 服务端收到请求，去验证用户名与密码
- 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
- 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
- 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
- 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
伪代码实现下懒加载
实现一下some, every flatten 函数组件怎么阻止重复渲染
AST作用 or babel实现原理 实现自定义hooks,usePrevious。setcount(count => count + 1)后输出上一次count的值
不同域名共享cookie on, emit, 实现 防抖的实现 输入url到页面返回结果 缓存的实现方式 React组件重复渲染 webpack分包
webWorker的使用：为什么不在worker里面发出请求，做数据转换呢？
generate函数和async区别 webpack插件实现
父子组件的mounted 调用顺序
$nextTick实现原理
子元素水平垂直居中
算法- “abcdabcda” 求最长的不重复字符串
web安全，pwa，workers，http2 webpack的优化
小程序的架构? 双线程分别做的什么事情?
为什么小程序里拿不到dom相关的api