前端中高级-网络篇
- css变量
- js: 链表
- 加密
- 劫持
-
浏览器缓存 cookie 、session、localStorage和sessionStorage的异同
解答：
cookie 数据存放在客户端浏览器上，大小限制为4k左右，数量限制根据不同浏览器限制在20个到50个。需设置过期时间，如未设置会随浏览器关闭而消失。会在客户端和服务器端进行传递，每次都携带在HTTP头中，会有安全问题，使用cookie保存过多数据会存在性能问题。主要用于保存登录信息如用户名和密码。session数据放在服务器上，保存一定时间，会比较占用服务器性能，为减轻服务器性能方面压力应当使用cookie，考虑到安全应当使用session，建议将登录信息等重要信息存放为session，其它需要保存的信息存放在cookie中。
localStorage和sessionStorage 仅保存在客户端本地，不与服务器进行交互通信，不担心被截获安全性比cookie高一些，但存在被伪造问题，只能存储字符串类型，对于复杂对象可以用json对象的stringfy和parse来处理，大小限制在5M左右，有setItem()、getItem、removeItem()、clear()、key()等方法。
localstorage会一直存在除非你主动删除它。可用于保存用户购物车信息，也通常用于H5游戏产生的本地数据。
sessionstorage仅在当前会话下有效，在同源的窗口中始终存在，会随浏览器关闭被删除。可用于分步骤填写的表单。
- Cookie在客户机上是如何存储的
解答：当你浏览网站的时候，cookie会记录下你输入的文字和一些选择操作，当你下一次再访问同一个网站，web服务器会先查找有没有上次它留下的cookie资料，如果有就会依据cookie里的内容来判断使用者，从而送出特定的网页内容供你浏览
- tag
-
请详细说明在哪些情况下会出现跨域问题？解决跨域的方案有哪些？
解答：浏览器执行的一个脚本与其他资源如果不同源即为跨域。解决方式有
Jsonp：利用script标签src外联引入文件不受同源策略限制，可以在页面动态添加script ，引入后端api接口地址，并以get的方式将前端回调处理函数名称告诉后端，后端响应请求时将回调返回，并将数据以参数形式传递回去
document.domin: 两个域名必须属于同一基础域名，所有协议端口完全一致，才能以此实现跨域，如beijing.58.com tianjin.58.com
iframe、hash： 父向子页面传输数据 将数据添加到子页面的url的hash值上，通过location.hash并添加定时器试时动态接收父页面传来的数据。子页面向父页面传输数据 利用window.name 的特性及页面重新加载当前页的name值不变， 需要三个页面配合使用，应用页面、数据页面和代理文件（空html文件，和应用页面在同一域下），此时将数据页面的窗口换成代理页面，代理页面通过window.name获取数据页面留下的数据，应用页面访问同源的代理页面就实现了跨域。
H5新增的 window.postMessage 和 WebSocket。
其他方式的服务器端实现跨域。 -
如何实现跨页面间的数据通讯，请结合事件机制、路由、应用状态管理方案、PostMessage等方面聊聊你的想法。
解答：
一、同源页面间的通讯
BroadCast Channel Service Worker Shared Worker IndexedDB window.open + window.opener
Localstorge 利用localstorge变化时会触发storage事件，我们可以在发送消息时把消息写入到localstorge中，然后在各个页面内监听storage事件即可收到通知
Window.addEventListener('storage', function (e) { if (e.key === 'ctc - msg'){ Const data = Json.parse(e.newValue); Const text = '[receive]'+ data.msg + '--tab'+ data.from; Console.log('[storage I] receive message: ', text) }})二、非同源页面间通信可以使用iframe作为桥 iframe与父页面间可以通过制定origin来忽略同源限制，在每一个页面嵌入一个iframe 而这些 iframe 由于使用的是一个 url，因此属于同源页面。页面与 iframe 通信需要在页面中监听 iframe 发来的消息，做相应的业务处理
window.addEventListener('message', function (e) {
// …… do something
});
然后，当页面要与其他的同源或非同源页面通信时，会先给 iframe 发送消息：
window.frames[0].window.postMessage(mydata, '*')
其中为了简便此处将
postMessage的第二个参数设为了'*'，你也可以设为 iframe 的 URL。iframe 收到消息后，会使用某种跨页面消息通信技术在所有 iframe 间同步消息，例如下面使用的 Broadcast Channel：const bc = new BroadcastChannel('AlienZHOU');
// 收到来自页面的消息后，在 iframe 间进行广播
window.addEventListener('message',function(e){
bc.postMessage(e.data);
});
其他 iframe 收到通知后，则会将该消息同步给所属的页面：
// 对于收到的（iframe）广播消息，通知给所属的业务页面
bc.onmessage = function (e) {
window.parent.postMessage(e.data, '*');
};
-
HTTP中GET与POST的区别？
GET从指定的资源请求数据，POST向指定的资源提交要被处理的数据；
GET请求有长度限制，而POST没有；
GET的安全性较差，而POST比GET更安全
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留；
GET请求能被缓存、收藏为书签，而POST不能；
GET请求只能进行url编码，而POST支持多种编码方式
GET数据在URL中对所有人都是可见的，而POST数据不会显示在URL中；
GET和POST本质上就是TCP连接，但GET产生一个TCP数据包，而POST产生两个TCP数据包。 -
浏览器中输入url之后都发生了什么？请详细阐述？
答：
1）由域名→IP地址 寻找IP地址的过程依次经过了浏览器缓存、系统缓存、hosts文件、路由器缓存、 递归搜索根域名服务器。
2）解析url 到 dns 服务器
3）建立TCP/IP连接（三次握手具体过程）
4）浏览器向服务器发送一个HTTP请求
HTTP协议是一种基于TCP/IP的应用层协议，进行HTTP数据请求必须先建立TCP/IP连接
可以这样理解：HTTP提供了封装或者显示数据的具体形式；Socket提供了网络通信的能力。两个计算机之间的交流无非是两个端口之间的数据通信,具体的数据会以什么样的形式展现是以不同的应用层协议来定义的。
5）浏览器接收到服务器返回的数据包
6）浏览器读取html文件和关联的 css ,js 进行渲染
7）渲染完成的页面展现给用户 -
在浏览器地址栏键入URL，按下回车之后会经历以下流程：
1、解析 url 到 dns 服务器 2、dns 服务器返回 ip 地址到浏览器 3、跟随协议将 ip 发送到网络中 4、经过局域网到达服务器 5、进入服务器的 MVC 架构 Controller 6、经过逻辑处理，请求分发，调用 Model 层 7、Model 和数据进行交互，读取数据库，将最终结果通过 view 层返回到网络回到浏览器 8、浏览器根据请求回来的 html 和关联的 css, js 进行渲染 9、在渲染的过程中，浏览器根据 html 生成 dom 树，根据 css 生成 css 树 10、将 dom 树和 css 树进行整合，最终知道 dom 节点的样式，在页面上进行样式渲染 11、浏览器去执行 js 脚本 12、最终展现页面 -
浏览器渲染的过程，大致可以分为五步：
html代码转化为dom css代码转化为cssom 结合dom和cssom，生成一颗渲染树 生成布局，即将所有的渲染树的节点进行平面合成 将布局绘制在屏幕上 -
TCP/IP连接三次握手：
第一次握手：客户端发送一个SYN包给服务器，表示请求连接； 第二次握手：服务器发送SYN+ACK包给客户端，表示收到你的请求，并同意连接； 第三次握手：客户端发送确认包ACK给服务器，表示确认并开始连接。 - TCP/IP断开四次挥手：
第一次挥手：客户端发送一个FIN包给服务器，表示将要关闭客户端到服务器这个方向的连接； 第二次挥手：服务器发送一个ACK包给客户端，表示同意客户端关闭连接的请求，但还没有准备好关闭连接； 第三次挥手：服务器发送一个FIN包给客户端，表示将要关闭服务器到客户端这个方向的连接； 第四次挥手：客户端发送一个确认包ACK给服务器，表示确认并关闭连接。 -
为什么TCP建立连接需要三次握手，而断开连接需要四次挥手？
因为当服务器收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务器端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，”你发的FIN报文我收到了”。只有等到服务器端所有的报文都发送完了，服务器才能发送FIN报文，因此不能一起发送，故需要四步握手。
-
介绍下304过程
a. 浏览器请求资源时首先命中资源的Expires 和 Cache-Control，Expires 受限于本地时间，如果修改了本地时间，可能会造成缓存失效，可以通过Cache-control: max-age指定最大生命周期，状态仍然返回200，但不会请求数据，在浏览器中能明显看到from cache字样。
b. 强缓存失效，进入协商缓存阶段，首先验证ETagETag可以保证每一个资源是唯一的，资源变化都会导致ETag变化。服务器根据客户端上送的If-None-Match值来判断是否命中缓存。
c. 协商缓存Last-Modify/If-Modify-Since阶段，客户端第一次请求资源时，服务服返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间。再次请求该资源时，request的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存。
-
请列举三种禁止浏览器缓存的头字段, 并写出相应的设置值
对于一些动态数据，很多时候我们希望每当用户在浏览器地址栏敲了回车之后，就可以看到最新的数据，但是很多时候，浏览器会自动的帮你去缓存该数据。
所以在此种情况下我们就看到最新的数据了，那么怎么办呢？
这个时候就要告诉浏览器不要缓存这些数据。
这个时候就要用到这三个http响应头来实现禁用浏览器缓存。
Cache-Control : no-cache Pragma : no-cache Expires: Thu, 01 Dec 1994 16:00:00 GMT (非常特殊，转换特定日期格式才可以)有些动态页面，每次访问内容都不同 ----- 如果浏览器缓存页面，无法查看最近内容
存放缓存文件夹： 工具---internet选项 --- 设置 --- 查看文件
response.setHeader("Cache-Control", "no-cache"); response.setHeader("Pragma", "no-cache"); response.setDateHeader("Expires", -1);这三个头，一般用在实时性比较高的页面或网站，主要为了通知浏览器来不要缓存。
注意：禁用浏览器缓存，有这样三个头，主要是因为目前市场上存在的浏览器比较多，不同的浏览器支持的禁用缓存的头也不一样，所以就出现这么几个，所以为了保险起见，一般将这三个头都设置上，那么就可以保证所有的浏览器都不会缓存该页面的内容了。
-
TCP和UDP协议
tcp协议的三次握手和四次挥手探究
假设两次握手，当失效的连接请求报文段突然又传送到服务端，它以为客户端又请求了，就发确认邮件到客户端，客户端一看，这不是我去年发的吗，就不理它了，服务器端却以为连接已经建立了，等等等，浪费服务器资源。 网络TCP建立连接为什么需要三次握手而结束要四次 。
udp协议（User Data Protocol，用户数据报协议）
（1） UDP是一个非连接的协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。
（2） 由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。
（3） UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。
（4） 吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。
（5）UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表（这里面有许多参数）。
（6）UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。 - TCP与UDP的区别
TCP是面向连接的协议，UDP是无连接协议； TCP是可靠、有序、无界的，TCP保证数据正确性，TCP保证数据顺序， UDP不可靠、无序、有界，UDP可能丢包，UDP不保证数据顺序； 对系统资源的要求TCP较多，UDP少； TCP有流量控制（拥塞控制），而UDP 没有； TCP传输速度慢，而UDP传输速度快； TCP是重量级的，UDP是轻量级的，TCP的头部比 UDP大； TCP面向字节流，而UDP面向报文； TCP是点对点连接的，而UDP一对一，一对多，多对多都可以； TCP适合用于网页，邮件等，而UDP适合用于视频，语音广播等。 流模式与数据报模式 -
安全问题
sql注入：利用引号截断sql语句
防御：用户输入进行过滤，sql语句预处理。xss：理论上，所有可输入的地方没有对输入数据进行处理的话，都会存在XSS漏洞，漏洞的危害取决于攻击代码的威力，攻击代码也不局限于script（改变样式什么的）。（可以盗取用户cookie)
XSS攻击及防御
开发者对用户输入进行处理，个人不要随便点击连接。
vue、react等框架已经很好的预防了xss攻击，除非使用v-html将用户输入直接放到页面中。csrf：伪造请求，冒充用户在站内的正常操作。
要完成一次CSRF攻击，受害者必须依次完成两个步骤：
1.登录受信任网站A，并在本地生成Cookie。
2.在不登出A的情况下，访问危险网站B。 - 关于Http 2.0 你知道多少
HTTP/2引入了“服务端推（server push）”的概念，它允许服务端在客户端需要数据之前就主动地将数据发送到客户端缓存中，从而提高性能。
HTTP/2提供更多的加密支持
HTTP/2使用多路技术，允许多个消息在一个连接上同时交差。
它增加了头压缩（header compression），因此即使非常小的请求，其请求和响应的header都只会占用很小比例的带宽
- HTTP1.0 / 1.1 / 2.0 及HTTPS
HTTP1.0 和 HTTP1.1 相比
HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD 方法。HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
缓存处理：在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
带宽优化及网络连接的使用：HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
错误通知的管理：在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
Host头处理：在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
长连接：HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。通过设置http的请求头部和应答头部，保证本次数据请求结束之后，下一次请求仍可以重用这一通道，避免重新握手。
HTTP2.0 和 HTTP1.X 相比
新的二进制格式（Binary Format）：HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
多路复用（MultiPlexing）：即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
header压缩：如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用了专门为首部压缩而设计的 HPACK 算法，使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
服务端推送（server push）：服务端推送能把客户端所需要的资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤。正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。 HTTPS 与 HTTP 相比
HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。