Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

梳理 #6

Open
derycktse opened this issue Apr 25, 2020 · 0 comments
Open

梳理 #6

derycktse opened this issue Apr 25, 2020 · 0 comments

Comments

@derycktse
Copy link
Owner

derycktse commented Apr 25, 2020

  • 词法作用域 语法作用域
    JavaScript深入之词法作用域和动态作用域 mqyqingfeng/Blog#3
  • microtask macrotask event loop, 浏览器端,服务器端
  • 负载均衡算法
  • 事件委托,哪些浏览器是冒泡的,哪些是捕获,哪些事件不会冒泡
  • amd commonjs es6 模块
  • this指向
  • 剪头函数
  • ssl 是在哪一层做的, 七层模型
  • 异步发展史 promise generator aysnc await
  • 如何防止ddos
  • mvc mvvm mvp
  • 基础 instanceof
  • 原型链
  • ssr会有什么问题知乎
  • cdn实现原理
  • 性能优化
    • 使用CDN
    • DNS-pre
  • tcp udp
  • script标签defer跟async的区别
  • js css 的加载以及解析,会不会阻塞其他资源的加载,以及dom的解析
  • cookie的属性

node

  • nodejs是一个单进程单线程的服务器引擎,不管有多么的强大硬件,只能利用到单个CPU进行计算
  • 而node.js采用单线程异步非阻塞模式,也就是说每一个计算独占cpu,遇到I/O请求不阻塞后面的计算,当I/O完成后,以事件的方式通知
  • 定位内存泄露
    • 压测

event loop

构建工具

webpack

  • loader 跟plugin的区别

算法

二叉树

二叉树

满二叉树:
除最后一层无任何子节点外,每一层上的所有结点都有两个子结点二叉树。
国内教程定义:一个二叉树,如果每一个层的结点数都达到最大值,则这个二叉树就是满二叉树。也就是说,如果一个二叉树的层数为K,且结点总数是(2^k) -1 ,则它就是满二叉树。
国外(国际)定义:a binary tree T is full if each node is either a leaf or possesses exactly two childnodes.
大意为:如果一棵二叉树的结点要么是叶子结点,要么它有两个孩子结点,这样的树就是满二叉树。

完全二叉树:
若设二叉树的深度为h,除第 h 层外,其它各层 (1~h-1) 的结点数都达到最大个数,第 h 层所有的结点都连续集中在最左边,这就是完全二叉树。

摘要

  • MD5
  • sha

加密算法

对称加密

非对称加密

排序算法

  • 事件复杂度,空间复杂度,这些复杂度是怎么算出来的
  • 快速排序
  • 数组的排序

https://blog.serenader.me/javascript-shu-zu-qu-zhong/

1,新建数组,使用indexOf
45eded44ab18063bfbbbef95b03e5e68.tiff

2,  使用一个对象辅助, hash形式
3feac93ab9f714d4a386a5473316a037.tiff

3,  使用es6 的 new set

前端

  • vue 跟 react的区别
    • vue通过getter/setter以及一些函数的劫持,双向绑定
    • react通过引用的方式,单向数据流
  • 使用状态管理的好处
    • 组件间的状态共享,避免一级级传
    • 单一的数据元,保存数据统一

js

原型链 & 继承

原型链

a437c623cada9706aa5958d3f355633f.tiff

283c2e28412ee4a9f2248e984b78db9c.tiff
new 出来的实例会有一个__proto__属性指向构造函数的prototype

异步

  • 异步的演变史

es6

import export

设计模式

正则表达

框架

虚拟dom

react

  • 题目
  • 虚拟dom
  • hook
  • 生命周期
  • pureComponent

redux

如何实现一个redux

html

  • 两个tab之间的通信

安全

xss跨站脚本攻击

类型

  • 存储型xss
  • 反射型xss

防御手段:

  • cookie 设置http-only
  • 输入检查,限制
  • 输出过滤,转移

解决: 有哪些字符需要转义?
&     –>     &
<     –>     &lt;
>     –>     &gt;
”     –>     &quot;
‘     –>     &#x27;
/     –>     &#x2f;
http://www.freebuf.com/articles/web/9977.html

有哪些场景场景

https://juejin.im/entry/5a09b9a55188254d2b6da217

文章:
https://juejin.im/entry/59310d4ca0bb9f0058b4f7c2

https://segmentfault.com/a/1190000012693772
03ec6b18a497e6718436bf0516d5d45a.png

如何利用 xss 进行csrf, (会话伪造)
利用了浏览器隐式认证

bfa5e22717b369ad41bb4f82322cbbc8.png

如何预防XSS:

  • 输入过滤,不信任用户的任何输入,过滤其中的“<”、“>”、“/”等可能导致脚本注入的特殊字符,
    或者过滤“script”、“javascript”等脚本关键字,或者对输入数据的长度进行限制等等,
    还得考虑攻击者使用十六进制编码来输入脚本的方式。
  • 输出进行编码,和输入过滤类似,不过是从输出上着手,数据输出到页面时,经过HtmlEncoder等工具编码,这样就不会存在直接输出可执行的脚本了
  • cookie设置http-only,这样用脚本就无法获取cookie了
    (这样只有浏览器向Web服务器发起请求的时才会带上cookie字段,避免了XSS攻击利用JavaScript的document.cookie获取cookie)
  • Cookie防盗,尽可能地避免在Cookie中泄露隐私,如用户名、密码等;
    或者,为了防止重放攻击,可以将Cookie和IP进行绑定,这样也可以阻止攻击者冒充正常用户的身份。
  • 注意,特别是后台,一定不能信任前端的输入,需要过滤与校验

csrf

防御手段

- 检验referer, 容易误伤,容易伪造,302跳转的时候,容易丢
- token, 存储在哪里
- cookie samesite

csrf token  如何生成?

需不需要没关闭网站的情况下打开恶意网站?
https://github.com/pillarjs/csrf

http://web.jobbole.com/94062/

https://www.2cto.com/article/201511/449909.html

https://segmentfault.com/a/1190000010791483

https://fed.renren.com/2018/01/20/cross-origin/

https://blog.csdn.net/sophia1010/article/details/79189602

场景

3bcae3ff7ea30e804ce81846e9f25bb1.tiff

  1. 验证HTTP Referer字段(非常简单,但是鉴于客户端并不可信任,所以并不是很安全)
    (防止CSRF,检查Referer字段简单直接,但是其完全依赖浏览器发送正确的Referer字段。
    虽然http协议对此字段的内容有明确的规定,但并无法保证来访的浏览器的具体实现,
    亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器,篡改其Referer字段的可能。)

  2. 在请求地址中添加token并验证
    (譬如post中,以参数的形式加入一个随机产生的token)

fce3b76a0bf05f8667d9c3dcf8cf9623.tiff

如何防止运营商劫持

  • 上https
  • csp 加载策略

跨域

跨域方法

  • window.name + iframe
  • document.domain + iframe(要求主域名相同)
  • 设置cors头
    缺点:
    需要后端配合

https://juejin.im/post/5ab21717518825611a405da3

http://www.cnblogs.com/yongshaoye/p/7424326.html

https://juejin.im/post/5a7359876fb9a0634a38e389

什么是简单请求?

找一下那篇跨域文章

7f7de39b276d3965ff87d0f58fad2220.tiff

CORS与JSONP的使用目的相同,但是比JSONP更强大。
JSONP只支持GET请求,CORS支持所有类型的HTTP请求。JSONP的优势在于支持老式浏览器,以及可以向不支持CORS的网站请求数据。

Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Allow-Headers
Access-Control-Expose-Headers
Access-Control-Allow-Methods
Access-Control-Max-Age
Origin

03c1646fd12f28636a61357ccb115893.tiff

  • postmessage
    otherWindow.postMessage(message, targetOrigin, [transfer]);

window.addEventListener("message", receiveMessage, false);

function receiveMessage(event)
{
if (event.origin !== "http://example.org:8080")
return;

// ...

适用对象:between a page and a pop-up that it spawned, or between a page and an iframe embedded within it.
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

script 标签只能支持get 请求

csp

  • http://www.ruanyifeng.com/blog/2016/09/csp.html
  • CSP 的实质就是白名单制度,开发者明确告诉客户端,哪些外部资源可以加载和执行,等同于提供白名单。它的实现和执行全部由浏览器完成,开发者只需提供配置。
  • CSP 大大增强了网页的安全性。攻击者即使发现了漏洞,也没法注入脚本,除非还控制了一台列入了白名单的可信主机。
    两种方法可以启用 CSP。一种是通过 HTTP 头信息的Content-Security-Policy的字段。

网络

  • 输入URL到返回数据,中间会发生生么
    1. DNS解析
    2. TCP连接
    3. 发送HTTP请求
    4. 服务器处理请求并返回HTTP报文
    5. 浏览器解析渲染页面

相关文:
sunyongjian/blog@feec170...d88c530
sunyongjian/blog#34
https://github.com/alex/what-happens-when
https://juejin.im/entry/5a1258bc6fb9a044fd115cd2
https://zhuanlan.zhihu.com/p/34453198?utm_medium=social&utm_source=wechat_session
http://web.jobbole.com/94150/

  • 正向代理与反向代理的区别

https://www.jianshu.com/p/208c02c9dd1d

49203be6dba9fd2f901fda7770a3a7ea.tiff

七层模型

  • 哪个是上层哪个是下层

be7d9a8c767fdd5f90a172a76083b577.tiff

ffb118a8fcb43680cb1e94bf242b1433.tiff

简单请求 & 非简单请求

简单请求
非简单请求

03c1646fd12f28636a61357ccb115893.tiff

方法

  • post与get区别
    GET在浏览器回退时是无害的,而POST会再次提交请求。
    GET产生的URL地址可以被Bookmark,而POST不可以。
    GET请求会被浏览器主动cache,而POST不会,除非手动设置。
    GET请求只能进行url编码,而POST支持多种编码方式。
    GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
    GET请求在URL中传送的参数是有长度限制的,而POST么有。
    对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
    GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。
    GET参数通过URL传递,POST放在Request body中。
    GET产生一个TCP数据包;POST产生两个TCP数据包。

    1. GET与POST都有自己的语义,不能随便混用。
    2. 据研究,在网络环境好的情况下,发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下,两次包的TCP在验证数据包完整性上,有非常大的优点。
    3. 并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。
  • 防止运营商劫持:CSP & https

https

  • ssl是在哪一层
  • https(https://mp.weixin.qq.com/s/StqqafHePlBkWAPQZg3NrA)(https://mp.weixin.qq.com/s/1ojSrhc9LZV8zlX6YblMtA)
    • 主要核心的思想是通过非堆成加密的形式传输堆成加密的密钥,为之后的通信做铺垫
    • 建立TCP链接,服务端发送证书(里边包含有服务端的公钥,信息和数字签名)
    • 服务端检验,简单说就是,通过CA的公钥解析数字签名,对比服务端的公钥&信息做消息摘要看看是不是一致,如果一致的话,说明这个公钥是没有被篡改过的,可以使用
    • 客户端生成随机数,用服务端的公钥加密,发送给服务端

证书包括:服务端的加密密钥+ 数字签名 

RSA : 非对称加密
https中的s表示SSL或者TLS
最终对称加密的密钥是由客户端发出
4184cc3c5efe74a04ab843205f05205a.tiff

7aee83cd449a8eac78be8a58c182b5ca.tiff

2384393222a9248ba44d61ecc874bcec.tiff

a0ae46a50bbe4584cdac9f35617affd0.tiff

https://mp.weixin.qq.com/s?__biz=MzUyODMzMjY3OQ==&amp;mid=2247483770&amp;idx=1&amp;sn=763e0e768fbeee4802caee851f428e2f&amp;chksm=fa70a392cd072a844f05429368a85faed7c84d1476252926558bd84293ed1a1c57684512f264&amp;scene=21#wechat_redirect

https://mp.weixin.qq.com/s?__biz=MzUyODMzMjY3OQ==&amp;mid=2247483777&amp;idx=1&amp;sn=79e1ced2fe3048d445c8776dc3e74677&amp;chksm=fa70a369cd072a7f6d9f1fd351f94df9e99cbc118ecafafe79dbacc5ea248bb19ed6be65ba38&amp;scene=21#wechat_redirect

https://mp.weixin.qq.com/s?__biz=MzUyODMzMjY3OQ==&amp;mid=2247483815&amp;idx=1&amp;sn=d2af7ac5d78ab5991e84ff092ff0ec81&amp;chksm=fa70a34fcd072a597c171c7077677fbe5ca05ae8fbb3b580e9c8e0aa18c31dafb5a5253dbdc9&amp;scene=21#wechat_redirect

https://mp.weixin.qq.com/s/hy0qauQ_hvAJNMYOHvnxLg?utm_medium=hao.caibaojian.com&amp;utm_source=hao.caibaojian.com

TCP

79d1a8ade9bb808548000692a125b03a.tiff

df2c51959c08dc3acee0f5d3175a1f4d.tiff

833a912ddb189e873df946d55417f5de.tiff

7233a00485fbfa3bcb033a23ced2baa8.tiff

https://juejin.im/entry/5b51473c6fb9a04fd16011a2

https://www.zhihu.com/question/24853633
https://juejin.im/post/5a0444d45188255ea95b66bc

https://www.jianshu.com/p/448f37ed29fe

https://www.jianshu.com/p/a57a40163d4b

jawil/blog#14

https://juejin.im/post/5a7ef7ce5188257a856f38b0

https://juejin.im/post/5a7fea206fb9a06333151e99
为什么要三次?
为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手,为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。

位码即tcp标志位,有6种标示:
1)SYN(synchronous建立联机)
2)ACK(acknowledgement 确认)
3)PSH(push传送)
4)FIN(finish结束)
5)RST(reset重置)
6)URG(urgent紧急)
7)Sequence number(顺序号码)
8)Acknowledge number(确认号码)

客户端TCP状态迁移:
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
服务器TCP状态迁移:
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

137c2b0bb75de68892d79e8893faa905.tiff

a6da63c829f5b6184608c7a3d9b693e0.tiff

spdy

1.	降低延迟,针对HTTP高延迟的问题,SPDY优雅的采取了多路复用(multiplexing)。多路复用通过多个请求stream共享一个tcp连接的方式,解决了HOL blocking的问题,降低了延迟同时提高了带宽的利用率。
2.	请求优先级(request prioritization)。多路复用带来一个新的问题是,在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级,这样重要的请求就会优先得到响应。比如浏览器加载首页,首页的html内容应该优先展示,之后才是各种静态资源文件,脚本文件等加载,这样可以保证用户能第一时间看到网页内容。
3.	header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
4.	基于HTTPS的加密协议传输,大大提高了传输数据的可靠性。
5.	服务端推送(server push),采用了SPDY的网页,例如我的网页有一个sytle.css的请求,在客户端收到sytle.css数据的同时,服务端会将sytle.js的文件推送给客户端,当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到,不用再发请求了。SPDY构成图:

2184984a6ff3c123047326d820e67283.tiff

HTTP2.0 支持明文 HTTP 传输,而 SPDY 强制使用 HTTPS

HTTP2.0 消息头的压缩算法采用 HPACK,而非 SPDY 采用的 DEFLATE

http2

- 多路复用,
- 首部压缩,使用报头压缩(如果你同时发出多个请求,他们的头是一样的或是相似的,那么,协议会帮你消除重复的部分。这就是所谓的HPACK算法)
- 请求优先级
- 服务端推送
- 二进制分帧,采用二进制格式而非文本格式, 二进制传输

http://www.alloyteam.com/2016/07/httphttp2-0spdyhttps-reading-this-is-enough/#prettyPhoto

HTTP2.0 支持明文 HTTP 传输,而 SPDY 强制使用 HTTPS

HTTP2.0 消息头的压缩算法采用 HPACK,而非 SPDY 采用的 DEFLATE
https://juejin.im/entry/5a51e6cd6fb9a01c9b65c5eb

•	二进制分帧
•	首部压缩
•	流量控制
•	多路复用
•	请求优先级
•	服务器推送

https://imququ.com/post/http2-resource.html

HTTP/2 协议本身并没有要求必须基于 TLS 部署,但当前所有浏览器均只支持 HTTP/2 Over TLS。这样做一方面更安全,另一方面利用 TLS 的加密机制可以更好地穿透网络中间节点。

cdn

  • 为什么要拆分多个cdn
    1. CDN缓存更方便
    2. 突破浏览器并发限制
    3. Cookieless, 节省带宽,尤其是上行带宽 一般比下行要慢
    4. 对于UGC的内容和主站隔离,防止不必要的安全问题( 上传js窃取主站cookie之类的
    5. 数据做了划分,甚至切到了不同的物理集群

缓存机制

强缓存:

  • 不会发起请求。
  • cache-control(缓存控制): max-age=number(单位是秒),它规定了一个到期时间,http1.1规范。
  • expires(到期时间),它的值是个时间的GMT格式的时间字符串,老规范。

协商缓存:

  • 会发起一次请求。
  • 这两组搭档都是成对出现的,即第一次请求的响应头带上某个字段(Last-Modified或者Etag),则后续请求则会带上对应的请求字段(If-Modified-Since或者If-None-Match),若响应头没有Last-Modified或者Etag字段,则请求头也不会有对应的字段。
  • etag,顾名思义,它会把一个资源打上一个 “二维码”,和请求头If-None-Match(如果有的话),就不会重新请求,负责 返回304。具体可见mdn
    Last-Modified,也是一个时间的GMT格式的时间字符串。和请求头If-Modified-Since(如果有的话)对比,没变返回304

cache control

  • “no-cache”表示必须先与服务器确认返回的响应是否发生了变化,然后才能使用该响应来满足后续对同一网址的请求。 因此,如果存在合适的验证令牌 (ETag),no-cache 会发起往返通信来验证缓存的响应,但如果资源未发生变化,则可避免下载。
  • “no-store”则要简单得多。 它直接禁止浏览器以及所有中间缓存存储任何版本的返回响应,例如,包含个人隐私数据或银行业务数据的响应。 每次用户请求该资产时,都会向服务器发送请求,并下载完整的响应。

  • Cookie和Session的区别
    • Cookie是存放在浏览器端的数据,每次都随请求发送给 Server。存储cookie是浏览器提供的功能。cookie 其实是存储在浏览器中的纯文本,浏览器的安装目录下会专门有一个 cookie 文件夹来存放各个域下设置的cookie。
    • 而Session是存放在服务器端的内存中,其 Session ID 是通过 Cookie 发送给客户端的,这个Session ID每次都随请求发送给 Server。
  • Cookie 和 LocalStorage 的区别
    • Cookie一般比较小,大约4k左右,而LocalStorage大约能用5M
  • LocalStorage永久有效,除非用户手动清理localStorage.clear()。不会自动过期
  • 但是SessionStorage在会话结束后就会失效,也就是用户关闭了页面,就失效了。会自动过期
  • Cache-Control: max-age=1000 缓存 与 ETag 的「缓存」有什么区别?
    • Cache-Control: max-age=1000的缓存 是直接不发请求的,1000秒内相同URL的用户请求资源的时候,不会再去发请求访问服务器了,直接从本地内存的缓存里面获取
    • ETag的缓存是不管怎么样都要发起请求,第二次访问的是时候会多一个请求头If-None-Match : md5值,如果两次请求之间的MD5值相同就不会去下载新的文件,响应体是第一次下载的;如果MD5值变了,就要去下载新的文件。

监控

  • 服务器性能监控
  • 日志分析监控
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant