复习3-三栏布局/htttp/判断登录

大复习

三栏布局

原理是靠margin移动盒子,不设置宽度; 配合浮动或者定位

margin百分比是相对父元素宽度,这里父元素body

方法1:左边左浮动,右边右浮动,中间不设置宽度,靠左右margin撑开举例

方法2:三栏全部左浮动, 不过中间栏宽度100%, 左边栏margin-left是-100%, 即左移一个body的宽度, 靠左遮住中间栏; 右盒子margin-left:-自身宽度px

方法3:绝对定位,不用浮动, 但还是靠margin值撑开中间这个自适应大小的盒子

js获取url中的某个参数值

使用js获取url中的某个参数值，主要通过把url的参数转换成数组形式，再通过for循环逐个查找数组元素，把参数值找出来。

1.使用location.href获得当前页面的链接, 此时是字符串形式

2.链接中的参数前有像? & 这种符号值, 为了一次用split分隔开, 可以先replace一些符号,然后变成数组

s=s.replace("?","?&").split("&");

3.数组里元素可能是这样[‘a=111’, ‘b=222’], 所以再按照等号split数组

4.最后遍历,找a[i+1]即可

闭包的作用

1.模仿块级作用域: 利用闭包会通过作用域链找变量,来模拟块级作用域

2.利用函数传的是值不是函数本身, 所以闭包里的改变不会污染外层全局变量

3.封装私有变量我们可以把函数当作一个范围，函数内部的变量就是私有变量，在外部无法引用，但是我们可以通过闭包的特点来访问私有变量。

WEB攻击(说了SQL注入，XSS,CSRF 让细讲了CSRF的过程)前端安全这块（问题，防范）

1. CSRF怎么盗取用户信息
2. 这样就能盗取用户信息了？（这一块我感觉不是很明白）

事件循环，宏任务微任务

http头部信息

https://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

根据维基百科对http header内容的组织形式，大体分为Request和Response两部分。

Request部分常用几个	解释	示例
Accept一类(-charset、-encoding，-language)	指定客户端能够接受的类型
Cache-Control	指定请求和响应遵循的缓存机制	Cache-Control: no-cache
Connection	表示是否需要持久连接。（HTTP 1.1默认进行持久连接）	Connection: close、keep-alive
Cookie	HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。	Cookie: $Version=1; Skin=new;
If-Modified-Since-触发协商缓存	如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码	If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-None-Match	如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变	If-None-Match: “737060cd8c284d8af7ad3082f209582d”
Host	指定请求的服务器的域名和端口号-http1.1新增, 支持断点重传	Host: www.zcmhi.com

Response部分常用几个	解释	举例
Accept-Ranges	表明服务器是否支持指定范围请求及哪种类型的分段请求	Accept-Ranges: bytes
Content(-Encoding, -Language, -Length)	响应体的信息	Content-Encoding: gzip
Cache-Control	告诉所有的缓存机制是否可以缓存及哪种类型	Cache-Control: no-cache
Last-Modified	请求资源的最后修改时间	Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Set-Cookie	设置Http Cookie	Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Location	用来重定向接收方到非请求URL的位置来完成请求或标识新的资源	Location: http://www.zcmhi.com/archives/94.html

Last-Modified/If-Modified-Since要配合Cache-Control使用, 判断是否触发协商缓存304;

http状态码

http状态码	举例
1xx：指示信息–表示请求已接收，继续处理
2xx：成功–表示请求已被成功接收、理解、接受	200 OK //客户端请求成功-触发强缓存
3xx：重定向–要完成请求必须进行更进一步的操作	301:
4xx：客户端错误–请求有语法错误或请求无法实现	400 Bad Request //客户端请求有语法错误，不能被服务器所理解 401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 403 Forbidden //服务器收到请求，但是拒绝提供服务 404 Not Found 请求资源不存在，eg：输入了错误的URL
5xx：服务器端错误–服务器未能实现合法的请求	500 Internal Server Error //服务器发生不可预期的错误 503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

200要么成功接到响应，要么表示强缓存，不会发送请求,因为本地缓存没有过期;cache control: max-age=1年

TLS握手

https://www.cnblogs.com/barrywxx/p/8570715.html

1. 客户端向服务器告知自己能接受的加密算法，并附带随机数1号
2. 服务器选择一个客户端的加密算法告知客户端，并附带随机数2号
3. 服务器向客户端发送自己的证书
4. 客户端验证证书通过后，用server的公钥， 加密生成的随机数3号；此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥;
5. 客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
6. 客户端结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;
7. 服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);

客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成;

Async，promise和generator

https://es6.ruanyifeng.com/#docs/promise

https://es6.ruanyifeng.com/#docs/async

ES6的新特性（说了块级作用域、箭头函数、promise顺便问了事件循环，扩展运算符，Symbol和新增的几个API

排序-快排/冒泡/插入

CSS的position(重点relative 和absolute的区别)

css垂直水平居中

https://www.cnblogs.com/tllw/p/10374110.html

ES6中，promise,asynic ,await,setTimeout的异同

eventloop/宏微任务

flex布局

首屏等待时间长是怎么进行优化的？

首屏过长原因:

由抓包数据结合以上分析可能导致的原因有：

1. 静态资源CSS、JS等体积过大；
2. HTTP请求数量过多；
3. 首页列中图片体积大、没有进行压缩；
4. 未使用HTTP缓存；
5. 网络波动造成速度不稳定。

https://zhuanlan.zhihu.com/p/88639980

https://blog.51cto.com/u_15127571/2665856

1.利用好script标签的async和defer这两个属性。功能独立且不要求马上执行的js文件，可以加入async属性。如果是优先级低且没有依赖的js，可以加入defer属性。

2.减少请求的数量。这点在http1.1的优势很明显，因为http1.1的请求是串行的（尽管有多个tcp通道），每个请求都需要往返后才能继续下个请求; 比如用: 精灵图

3.引入http2.0。http2.0对比http1.1，最主要的提升是传输性能，在接口小而多的时候会更加明显。

4.前端的资源动态加载：

a. 路由动态加载，最常用的做法，以页面为单位，进行动态加载。
b. 组件动态加载(offScreen Component)，对于不在当前视窗的组件，先不加载。
c. 图片懒加载(offScreen Image)，同上。值得庆幸的是，越来越多的浏览器支持原生的懒
   加载，通过给img标签加上loading="lazy来开启懒加载模式。 

5.cdn分发（减少传输距离）。通过在多台服务器部署相同的副本，当用户访问时，服务器根据用户跟哪台服务器距离近，来决定哪台服务器去响应这个请求。

6.（少用）选择先进的图片格式。使用 WebP 的图片格式来代替现有的jpeg和png，当页面图片较多时，这点作用非常明显。把部分大容量的图片从BaseLine JPEG切换成Progressive JPEG（理解这两者的差别）也能缩小体积。

说说滑动到底加载下一轮数据用原生是怎么实现的？

如果加载接下来的东西，会造成维持这个列表队列里的其它东西被重复渲染，造成性能浪费，有没有解决这个问题的方法？

防抖和节流

防抖和节流及应用场景？

常见的性能优化怎么做的

渲染方式、数据处理，后端、网络通信相关的所有内容；

入手：基于http请求响应的这一系列过程，有几个问题：

如何让网络通信更快，发请求更快？

1. 尽量用http2不要用http1；首先http2有头部压缩机制，谷歌专门提出一个HPACK压缩算法，传一个索引表（只存常用头信息），辅助哈夫曼编码来encode头id；其次http2真正实现了多路复用（2进制帧传数据）；

2. 服务器层面：物理距离无法更改，但是如果有多个服务器，选择近距离的服务器,但是如果最近点负载过高，就选择次近点；CDN: content delivery network服务器通信层面；原理像物流仓库

   如果只能http1，以下方法用来优化http1：

3. 合并资源（雪碧图），减少http请求数量，避免不停建立链接

4. 域名分片：HTTP 里“并发连接”（concurrent connections），也就是同时对一个域名发起多个长连接，用数量来解决质量的问题。

   如果每个客户端都想自己快，建立很多个连接，用户数×并发数就会是个天文数字。服务器的资源根本就扛不住，或者被服务器认为是恶意攻击，反而会造成“拒绝服务”。HTTP 协议和浏览器不是限制并发连接数量吗？好，那我就多开几个域名，比如 shard1.chrono.com、shard2.chrono.com，而这些域名都指向同一台服务器 www.chrono.com，这样实际长连接的数量就又上去了

5. 缓存机制（强缓存，协商缓存）。做法：第一次请求后，服务器给客户端设置头部cache-control或者expires，让客户端自己决定下次请求是否触发强缓存；客户端第二次请求时头部有if-modified-since给自己设定时间，服务器再根据lastmodified判断是否触发协商缓存；

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lyk6iryw-1621958664017)(…/…/AppData/Roaming/Typora/typora-user-images/image-20210427155436132.png)]

6. 用算法进行数据压缩（gzip、br）

7. 代码文件压缩：HTML/CSS/JS中的注释，空格，长变量名等等，webpack打包工具；less/sass等

8. 静态资源：字体图标，缩小尺寸，使用jpg/webp格式

9. 头与报文：http1.1压缩头部，http2就有这个机制；

10. 我自己的话用了精灵图和less

服务器如何让数据处理更快，处理数据，回复请求更快？

1. 服务器端AB分析工具，没有深入学习，学node时再学这个

客户端如何让数据处理更快，客户端拿到数据后，怎么更快显示

1. 优化前端代码：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NXH4zPUt-1621958664020)(…/…/AppData/Roaming/Typora/typora-user-images/image-20210427162507215.png)]

2. 渲染方案：不用纯客户端渲染（CSR）,而是辅助服务器渲染（SSR），比如把首屏，先在服务器端把用到的css/html/css整合成一段html字符串，客户端接收到这一串字符串之后就能直接显示，避免了多次请求等待响应；

怎么判断一个用户的登录来源，怎么进行存储操作

登录成功后生成Cookie响应给客户端
登录成功之后将登录用户的id，用户类型，用户来源平台，登录时间等信息序列化成字符串，然后再通过对称加密，生成一个字符串作为cookie的value值响应给客户端。

java的HttpServletResponse对象包含登录用户的id，用户类型，用户来源平台，登录时间等信息, 代码如下：

public void createCookieAndRegisterDevice(LoginVO loginVO, HttpServletRequest httpServletRequest,
                                          HttpServletResponse httpServletResponse,String[] cookieDomains) throws Exception {
    AuthCookieItem authCookieItem = CookieUtils.createCookie(userType2ApiType(loginVO.getUserType()), loginVO.getUserType(), loginVO.getUserId());
    //设置登录时间戳
    long now = System.currentTimeMillis();
    authCookieItem.setTimestamp(now);
    String deviceId = httpServletRequest.getHeader("DeviceId");
    if (StringUtils.isNotBlank(deviceId)) {
        doUserSysRedis(authCookieItem.getUserId(), now, deviceId);
    }
    String cookieValue = CookieUtils.encryptCookie(authCookieItem, AES.CookieKey).replaceAll("\\n|\\r", "");
    writeCookie(httpServletResponse,cookieDomains,cookieValue);
}

js怎么写存储cookie:https://www.jb51.net/article/162229.htm

js存放cookie一般的写法，如：document.cookie="userName=admin";，如果是多个键值对：document.cookie="userName=admin; userPass=123";

前端监控&前端埋点

https://segmentfault.com/a/1190000015864670

实现前端监控有三个步骤：前端埋点和上报、数据处理和数据分析。

我对数据处理和分析不太了解，不过试过前端埋点和上报；

埋点分三种，简单的需求可以代码埋点直接获取数据，然后上报方式的话可以用Image实例的src上传，get请求，无跨域兼容问题；或者navigator.sendBeacon("/log", analyticsData);navigator对象的sendBeacon方法；

更多的关于浏览器渲染方面的数据，可以用performance接口获取；

---

1.目前常见的前端埋点方法分为三种：代码埋点、可视化埋点和无痕埋点。

(1) 代码埋点

代码埋点，就是以嵌入代码的形式进行埋点，比如需要监控用户的点击事件，会选择在用户点击时，插入一段代码，保存这个监听行为或者直接将监听行为以某一种数据格式直接传递给server端。

(2)可视化埋点

通过可视化交互的手段，代替代码埋点。将业务代码和埋点代码分离，提供一个可视化交互的页面，输入为业务代码，通过这个可视化系统，可以在业务代码中自定义的增加埋点事件等等，最后输出的代码耦合了业务代码和埋点代码。

可视化埋点听起来比较高大上，实际上跟代码埋点还是区别不大。也就是用一个系统来实现手动插入代码埋点的过程。

(3)无埋点

无埋点并不是说不需要埋点，而是全部埋点，前端的任意一个事件都被绑定一个标识，所有的事件都别记录下来。通过定期上传记录文件，配合文件解析，解析出来我们想要的数据，并生成可视化报告供专业人员分析因此实现“无埋点”统计。

从语言层面实现无埋点也很简单，比如从页面的js代码中，找出dom上被绑定的事件，然后进行全埋点。

---

2.埋点监控到数据后，怎么传给服务器

可以用img的ping方法提交简单的信息，数据通过 Image 对象实例的 src 属性指向后端脚本并携带参数

可以用fetch和POST方法提交表单，可以XMLHttpRequest

---

Performance 接口可以获取到当前页面中与性能相关的信息。它是 High Resolution Time API 的一部分，同时也融合了 Performance Timeline API、Navigation Timing API、 User Timing API 和 Resource Timing API。