前端面试——网络以及浏览器相关

TCP、UDP的区别 ？

（1）TCP是面向链接的（三次握手，四次挥手），UDP是无链接的； 

（2）TCP提供可靠的服务，经过TCP链接传输的数据无差错、不丢失、不重复，且按序到达（拥塞控制）；UDP则是尽最大努力交付，可是不保证可靠性； 

（3）TCP是面向字节流，UDP面向报文（UDP 只是报文的搬运工，不会对报文进行任何拆分和拼接操做）；

（4）TCP只能端对端；UDP支持一对1、多对多、一对多、多对一；

（5）TCP的首部较大，约有20字节；UDP有8字节（因此UDP具备高效性）；

拥塞控制相关博客：blog.csdn.net/m0_37962600…

TCP、UDP头部相关博客：blog.csdn.net/xiaoxianerq…

三次握手以及四次挥手？

三次握手：

1.客户端首先发送SYN=1；

2.服务端接收到，而后增长一个ACK=1返回给客户端。（返回给客户端的是ACK=1，SYN=1）

3.客户端须要发送一个消息给服务端进行确认，因此给服务端发送了一个ACK=1；

四次挥手：

1.首先客户端请求关闭与服务端的链接，客户端先发送一个FIN=1；

2.服务端接收到消息后，返回一个ACK=1；

3.在这个状态下实际上一个方向已经关闭了，因此服务端也须要给客户端发送一个FIN=1，ACK=1；

4.客户端接收到后发送ACK=1，表示接收到消息。

HTTP为何须要三次握手？

若是发送2次就能创建链接的话，可能会出现如下问题：

若是一个链接请求在网络中超时了，在这个时候客户端会从新发送请求，可是最终超时的请求仍是会到服务端，服务端接收了两个请求，就会建立出2个链接。浪费了资源。

可是在三次握手的状况下，发生这种状况，多出的一次请求会被抛弃掉。

HTTP为何须要四次分手？

TCP是双向的，因此须要在服务端和客户端都须要关闭。当客户端关闭和服务端的链接后，依旧是能够接收到服务端的消息的，只是客户端再也不往服务端发送消息。

FastTCP

FastTCP被认为是目前全球最早进的电信级TCP/IP协议单边部署加速技术。

FastTCP不修改TCP协议内TCP包头(TCP Packet Header)的标准格式，只对TCP包头里的（Sequence Number, Window Scaling ）等数值做修改，而且优化了流量控制的算法，大大提升了TCP流量的效率，从而提升了广域网带宽的利用率。FastTCP对TCP包自己的内容(Payload)和标准的TCP包格式并不做改变。

FastTCP技术特色包括：

一、在现有架构中即插即用，与主要厂商网络设备彻底兼容

二、单边部署，客户端不须要安装任何软、硬件

三、彻底兼容并加速各类标准及变种TCP协议流量

四、应用软件无须做任何改变

五、能对不可压缩或缓存内容进行加速

六、支持Bypass功能和高可靠组架构，保证网络不会因FastSoft加速器故障而中断

       

        与通常的TCP相比，FASTTCP的不一样主要表如今三个方面：首先，它是一个基于平衡(Equilibrium)的算法，所以消除了包级振荡；第二：它使用队列时延(Queuing Delay)做为主要的拥塞测量，在高速、长距离网络的中，队列时延对拥塞的测量比丢包率具备更高的可靠性；第三，它具备稳定的流动态性，可以在平衡状态得到加权指数级的公平性，且不会给长距离TCP流不公正的待遇。 FASTTCP拥塞控制算法可分为四个部分，其中，数据控制(Data Control)部分决定哪些包将要被发送，窗口控制(Window Control)部分决定要发送多少个包，爆发控制(Burstiness Control) 部分决定什么时候发送这些包，这些决定都是在估计(Estimation)部分提供的信息的基础上做出的。窗口控制以往返时间为时标控制TCP包传输，而爆发控制工做在一个较小的时标。

——估计部分：该估计信息被其它三部分使用。当收到确定确认，将RTT平滑计算到平均RTT；当收到否认确认，将生成丢失指示。

——窗口控制：使用队列时延做为其主要的拥塞测量。在通常的网络条件下，FastTCP周期性的根据平均RTT来更新拥塞窗口。当网络的流式样或者拓扑结构改变时平衡点会发生偏移，FASTTCP采用平衡性和公平性算法实现效率最大化。

——数据控制：从候选池中选择下一次要发送的数据包：新数据包，被否认确认的包，或传输后还未被确认的包。数据控制部分决定如何将三个候选池中数据包混合发送。特别是在当前带宽-时延积愈来愈大的状况下，这个决定变得尤为重要。

——爆发控制：爆发控制部分经过使用一种类流方式追踪可用带宽，以达到平滑数据包发送的目的。FASTTCP使用两种爆发控制机制，一个补充流出的单个包的自同步，另外一个使用小爆发使窗口平滑的增长。

什么是XSS，如何防护？什么是CSRF，如何防护？

XSS（跨站脚本攻击）

XSS攻击指的是攻击者在网站上注入恶意的代码，经过恶意脚本对客户端网页进行篡改，从而在客户浏览网页的时候，对用户浏览器进行控制或获取用户的隐私数据。

XSS防护

1.httpOnly防止劫取Cookie，浏览器禁止JavaScript去访问带有HttpOnly属性的Cookie。（注意：HttpOnly并非阻止了XSS，而是可以阻止XSS攻击后的Cookie劫持攻击。）

2.输入、输出检查（针对<>这一类的特殊字符）。

3.CSP

CSP 本质上也是创建白名单，规定了浏览器只可以执行特定来源的代码。

一般能够经过 HTTP Header 中的 Content-Security-Policy 来开启 CSP

只容许加载本站资源    Content-Security-Policy: default-src ‘self’

只容许加载 HTTPS 协议图片   Content-Security-Policy: img-src https://*

容许加载任何来源框架  Content-Security-Policy: child-src 'none'

CSRF（跨站请求伪造）

CSRF指的是劫持受信任用户向服务器发送非预期请求。

CSRF防护

1.验证码

2.token

3.referer，http头中又一个字段叫作referer，它记录了该HTTP请求的来源地址。经过Referer Check可以检查请求是否来自合法的源。

4.SameSite

能够对 Cookie 设置 SameSite 属性。该属性设置 Cookie 不随着跨域请求发送。

其余网络安全相关（包含XSS、CSRF、SQL注入、clickjacking攻击）：www.cnblogs.com/liqiongming…

介绍下如何实现 token 加密

1. 须要一个secret

2. 后端利用secret和加密算法，返回前端

3. 前端每次request在header中带上token

4. 后端用一样的算法解密

强缓存和协商缓存（包括浏览器机制）

缓存分为强缓存和协商缓存。

强缓存不过服务器，协商缓存须要过服务器，协商缓存返回的状态码是304。

两类缓存机制能够同时存在，强缓存的优先级高于协商缓存。当执行强缓存时，如若缓存命中，则直接使用缓存数据库中的数据，再也不进行缓存协商。

强缓存

Expires（HTTP1.0）：

Expires的值为服务端返回的数据到期时间。当再次请求时的请求时间小于返回的此时间，则直接使用缓存数据。

缺点：使用的是绝对时间，若是服务端和客户端的时间产生误差，那么会致使命中缓存产生误差。

Pragma（HTTP1.0）:

当值为"no-cache"时强制验证缓存，服务端响应添加'Pragma': 'no-cache'，浏览器表现行为和刷新(F5)相似。

Cache-Control（HTTP1.1）：

• private：客户端能够缓存

• public：客户端和代理服务器均可以缓存

• max-age=t：缓存内容将在t秒后失效

• no-cache：须要使用协商缓存来验证缓存数据

• no-store：全部内容都不会缓存 

协商缓存

一、浏览器第一次请求数据时，服务器会将缓存标识与数据一块儿响应给客户端，客户端将它们备份至缓存中。

二、再次请求时，客户端会将缓存中的标识发送给服务器，服务器根据此标识判断。若未失效，返回304状态码，当浏览器拿到此状态码就能够直接使用缓存数据了。

相关的http头部

1.etag -- if-none-match

        1）若是缓存中有ETag 令牌，客户端请求时会自动在“If-None-Match” HTTP 请求标头内提供 ETag 令牌。

        2）服务器根据当前资源核对令牌，验证是否发生变化，将验证结果通知给客户端，客户端根据结果看看是否须要从缓存中读取仍是发送资源请求。

参考文献：www.jianshu.com/p/3e2afe089…

2.last-modified -- if-modified-since

Last-Modified 是由服务器往客户端发送的 HTTP 头，另外一个 If-Modified-Since是由客户端往服务器发送的头。

blog.csdn.net/tianmohust/…

缓存的场景

一、不须要缓存使用 Cache-control: no-store。

二、频繁变更的资源使用 Cache-Control: no-cache 并配合 ETag 使用，表示该资源已被缓存，可是每次都会发送请求询问资源是否更新。

三、对于代码文件来讲，一般使用 Cache-Control: max-age=31536000 配合策略缓存使用，而后对文件进行指纹处理，一旦文件名变更就会马上下载新的文件。

DNS解析时，有什么算法和方式减小重复操做？

DNS解析的时候可使用DNS缓存去减小重复操做。

DNS缓存有浏览器DNS缓存、系统DNS缓存、路由DNS缓存、服务商DNS缓存。

DNS有两种查询的方式，分为递归查询和迭代查询。

递归查询是访问根域名服务器，根域名服务器层层下发，找到目标域名的IP地址后返回。

迭代查询是访问根域名服务器后，根域名服务器返回一个其余DNS服务器的地址，而后再向其余DNS服务器去查询。

DNS缓存

在浏览器中输入URL的时候，DNS会根据域名找到对应的IP地址。

在DNS查找目标域名对应的IP地址的时候，首先会去访问浏览器缓存，看最近访问的网址中有没有目标域名。若是没有则会访问系统DNS缓存中的是否存在，依旧不存在则会去路由缓存中查找，可是仍是不存在的话就会去ISP服务商的缓存中查找是否有目标域名的IP地址。

若是缓存中都不存在则会访问根域名服务器去查找目标域名的IP地址，根域名服务器会层层下发直到找到对应域名的IP地址为止。

Cookie 和Session、LocalStorage

生命周期：

cookie：可设置失效时间，没有设置默认是关闭浏览器后失效。

localStorage：除非被手动清除，不然将会永久保存。

sessionStorage： 仅在当前网页会话下有效，关闭页面或浏览器后就会被清除。

存放数据大小：

cookie：4KB左右

localStorage和sessionStorage：能够保存5MB的信息。

http请求：

cookie：每次都会携带在HTTP头中，若是使用cookie保存过多数据会带来性能问题

localStorage和sessionStorage：仅在客户端（即浏览器）中保存，不参与和服务器的通讯

缓存位置

1.from Service Worker

2.from memory cache

3.from disk cache

Service Worker

Service Worker相比于LocalStorage、SessionStorage，后二者只是单纯的接口数据缓存，而前者能够缓存静态资源，甚至拦截网络请求，根据网络情况做出不一样的缓存策略。

memory cahce

事实上，全部的网络请求都会被浏览器缓存到内存中。可是缓存不能无限存放在内存中，由于内存是有限的。 内存缓存的控制权在浏览器，先后端都不能干涉。

disk cache 

disk cache也叫http cahce，它将资源缓存在硬盘中，由于其严格遵照http响应头的字段来判断哪些资源是否要被缓存，哪些资源是否已通过期。缓存的控制权在后端。

localStorage和sessionStorage

localStorage永久保存在浏览器里面（在没被清除的状况下），sessionStorage是关闭网页就清除了信息。

localStorage能够用来跨页面（跨窗口）传递参数，而sessionStorage用来保存一些临时的数据，防止用户刷新页面以后丢失了一些参数。

WebSocket

WebSocket 是在最初创建链接时须要借助于现有的HTTP协议，通讯是基于TCP的。

经过WebSocket能够在客户端和服务器之间以数据流的形式实现各类应用数据交换（包括JSON 及自定义的二进制消息格式），并且两端均可以随时向另外一端发送数据。

Keep-alive

Connection:Keep-alive

HTTP协议采用“请求-应答”模式。

在不开启KeepAlive模式时，每一个req/res客户端和服务端都要新建一个链接，完成后当即断开链接（HTTP协议为无链接的协议）；

当开启Keep-Alive模式（又称持久链接、链接重用）时，Keep-Alive功能使客户端到服务器端的链接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了创建或者从新创建链接。

HTTP各个版本

相对于HTTP1.0，HTTP1.1的优化：

一、缓存处理：多了Entity tag，If-Unmodified-Since, If-Match, If-None-Match等缓存信息（HTTTP1.0 If-Modified-Since,Expires）

二、带宽优化及网络链接的使用

三、错误通知的管理

四、Host头处理

五、长链接： HTTP1.1中默认开启Connection： keep-alive。

相对于HTTP1.1，HTTP2的优化：

• HTTP2支持二进制传送（实现方便且健壮），HTTP1.x是字符串传送

• HTTP2支持多路复用（多路复用容许同时经过单一的 HTTP/2 链接发起多重的请求-响应消息）

• HTTP2采用HPACK压缩算法压缩头部，减少了传输的体积

• HTTP2支持服务端推送

HTTP/2的多路复用

HTTP/2引入二进制数据帧和流的概念，其中帧对数据进行顺序标识，以下图所示，这样浏览器收到数据以后，就能够按照序列对数据进行合并，而不会出现合并后数据错乱的状况。一样是由于有了序列，服务器就能够并行的传输数据，这就是流所作的事情。

• 解决第二个问题：HTTP/2对同一域名下全部请求都是基于流，也就是说同一域名无论访问多少文件，也只创建一路链接。

而后还多了个HTTP3.0

QUIC新功能

一、0-RTT

经过使用相似 TCP 快速打开的技术，缓存当前会话的上下文，在下次恢复会话的时候，只须要将以前的缓存传递给服务端验证经过就能够进行传输了。0RTT 建连能够说是 QUIC 相比 HTTP2 最大的性能优点。

二、多路复用

同HTTP2.0同样，同一条 QUIC链接上能够建立多个stream，来发送多个HTTP请求，可是，QUIC是基于UDP的，一个链接上的多个stream之间没有依赖。假如stream2丢了一个UDP包，不会影响后面跟着 Stream3 和 Stream4，不存在 TCP 队头阻塞。虽然stream2的那个包须要从新传，可是stream三、stream4的包无需等待，就能够发给用户。

另外QUIC 在移动端的表现也会比 TCP 好。由于 TCP 是基于 IP 和端口去识别链接的，这种方式在多变的移动端网络环境下是很脆弱的。可是 QUIC 是经过 ID 的方式去识别一个链接，无论你网络环境如何变化，只要 ID 不变，就能迅速重连上。

三、加密认证的报文

TCP 协议头部没有通过任何加密和认证，因此在传输过程当中很容易被中间网络设备篡改，注入和窃听。可是 QUIC 的 packet中除了个别报文好比 PUBLIC_RESET 和 CHLO，全部报文头部都是通过认证的，报文 Body 都是通过加密的。

四、向前纠错机制

QUIC协议可以向前纠错 ，因为每一个数据包除了它自己的内容以外，还包括了部分其余数据包的数据，所以少许的丢包能够经过其余包的冗余数据直接组装而无需重传。

HTTP2.0的多路复用和HTTP1.X中的长链接复用有什么区别？

• HTTP/1.* 一次请求-响应，创建一个链接，用完关闭；每个请求都要创建一个链接；

• HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能得到执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；

• HTTP/2多个请求可同时在一个链接上并行执行。某个请求任务耗时严重，不会影响到其它链接的正常执行；

websocket和长链接区别

长链接：创建SOCKET链接后无论是否使用都保持链接。

长链接：链接->传输数据->保持链接 -> 传输数据-> ........ ->关闭链接。

WebSocket： 浏览器和服务器只须要要作一个握手的动做，在创建链接以后，双方能够在任意时刻，相互推送信息。同时，服务器与客户端之间交换的头信息很小。

长轮询和短轮询是什么？

 短轮询指浏览器向服务器发送一个请求，询问是否有数据更新，服务里马上返回响应。一段时间后浏览器又发起一个到服务器的新请求。 

长轮询指浏览器向服务器发送一个请求，服务一直保持链接打开，直到有数据可发送，发送完数据后，浏览器关闭链接，随即又发起一个到服务器的新请求。（使用XHR对象和setTimeout()实现） 

常见的HTTP状态码

100：表示请求头已经发送到服务端，服务端表示容许访问，须要客户端再发送主体部分

200：表示请求成功

204：No content，表示请求成功，但响应报文不含实体的主体部分

206：处理了部分请求

301：永久重定向，请求的网页已永久移动到新地址。

302：临时重定向

303：see other，请求者应当对不一样的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。 

304：no modify，自从上次请求后，请求的网页未修改过。

305：请求者只能使用代理访问请求的网页

307：临时重定向

400：服务器不理解请求的语法

401：请求要求身份验证 

403：服务器拒绝请求 

404：服务器找不到请求的网页

405：禁用请求中指定的方法

406：没法使用请求的内容特性响应请求的网页

500：服务器内部错误，没法完成请求

501：服务器不具有完成请求的功能

502：错误网关

503：服务不可用

504：网关超时

浏览器是如何渲染页面的

一、编码： 先将HTML的原始字节数据转换为文件指定编码的字符。 

二、令牌化： 而后浏览器会根据HTML规范来将字符串转换成各类令牌（如<html>、<body>这样的标签以及标签中的字符串和属性等都会被转化为令牌，每一个令牌具备特殊含义和一组规则）。

三、生成对象： 接下来每一个令牌都会被转换成定义其属性和规则的对象。 

四、构建完毕： DOM树构建完成，整个对象集合就像是一棵树形结构。 

五、当HTML代码碰见<link>标签时，浏览器会发送请求得到该标签中标记的CSS文件，构建CSSOM树。  

六、在构建了DOM树和CSSOM树以后，将DOM树与CSSOM树结合在一块儿成渲染树。 

七、渲染树构建完毕后，浏览器获得了每一个可见节点的内容与其样式，而后计算每一个节点在窗口内的确切位置与大小，也就是布局阶段。 

八、当Layout布局事件完成后，浏览器会当即发出Paint Setup与Paint事件，开始将渲染树绘制成像素。

GET和POST的区别

一、Get 请求能缓存，Post 不能。

二、Post 相对 Get 安全一点点，由于Get 请求都包含在 URL 里，且会被浏览器保存历史纪录，可是Post 不会。在抓包的状况下都是同样的。

三、Post 能够经过 request body来传输比 Get 更多的数据，可是Get不行。

四、URL有长度限制，会影响 Get 请求，这个长度限制是浏览器规定的。

五、Post 支持更多的编码类型且不对数据类型限制。

URL输入浏览器的整个过程

（1）、DNS缓存

（2）、TCP的三次握手

（3）、浏览器页面的渲染

（4）、TCP的四次握手

回流和重绘

何时会发生回流：

一、添加或删除可见的DOM元素

二、元素的位置发生变化

三、元素的尺寸发生变化（包括外边距、内边框、边框大小、高度和宽度等）

四、内容发生变化，好比文本变化或图片被另外一个不一样尺寸的图片所替代。

五、浏览器的窗口尺寸变化（由于回流是根据视口的大小来计算元素的位置和大小的）

什么时候发生重绘（回流必定会触发重绘）：

当页面中元素样式的改变并不影响它在文档流中的位置时（例如：color、background-color、visibility等），浏览器会将新样式赋予给元素并从新绘制它，这个过程称为重绘。

如何避免触发回流和重绘：

CSS：

一、避免使用table布局。

二、尽量在DOM树的最末端改变class。

三、避免设置多层内联样式。

四、将动画效果应用到position属性为absolute或fixed的元素上

五、避免使用CSS表达式（例如：calc()）

六、CSS3硬件加速（GPU加速）

JavaScript：

一、避免频繁操做样式，最好一次性重写style属性，或者将样式列表定义为class并一次性更改class属性

二、避免频繁操做DOM，建立一个documentFragment，在它上面应用全部DOM操做，最后再把它添加到文档中

三、也能够先为元素设置display: none，操做结束后再把它显示出来。由于在display属性为none的元素上进行的DOM操做不会引起回流和重绘

四、避免频繁读取会引起回流/重绘的属性，若是确实须要屡次使用，就用一个变量缓存起来

五、对具备复杂动画的元素使用绝对定位，使它脱离文档流，不然会引发父元素及后续元素频繁回流 

HTTPS的握手

一、客户端向服务端发送消息，发送的信息包含 SSL 版本、客户端支持的加密套件和使用的数据压缩算法及随机数1。

二、服务器响应客户端消息，返回的信息包含选定的加密套件、选定的数据压缩方法、会话标识，数字证书及另外一个随机数2。

三、客户端验证服务器的SSL数字证书的有效性，若是不经过则提示警告。

四、客户端发送密钥交换的消息。消息包含随机数3。

五、客户端使用加密运算将全部随机数转化为 master secret。

六、服务器使用加密运算将全部随机数转化为 master secret。

七、客户端告知服务器以后使用协商好的对称加密算法生成的密钥通讯。

八、服务器告知客户端以后使用协商好的对称加密算法生成的密钥通讯。

九、SSL握手结束，接下去使用对称加密算法进行加密通讯。

介绍下 HTTPS 中间人攻击

中间人攻击过程以下：

1. 服务器向客户端发送公钥。

2. 攻击者截获公钥，保留在本身手上。

3. 而后攻击者本身生成一个【伪造的】公钥，发给客户端。

4. 客户端收到伪造的公钥后，生成加密hash值发给服务器。

5. 攻击者得到加密hash值，用本身的私钥解密得到真秘钥。

6. 同时生成假的加密hash值，发给服务器。

7. 服务器用私钥解密得到假秘钥。

8. 服务器用加秘钥加密传输信息

防范方法：

1. 服务端在发送浏览器的公钥中加入CA证书，浏览器能够验证CA证书的有效性

为何利用多个域名来存储网站资源会更有效？

1.CDN缓存更方便;

2.突破浏览器并发限制;

3.节约cookie带宽;

4.节约主域名的链接数，优化页面响应速度;

5.防止没必要要的安全问题。

谈一谈对CDN的理解

(1)节省骨干网带宽，减小带宽需求量；

(2)提供服务器端加速，解决因为用户访问量大形成的服务器过载问题；

(3)服务商能使用Web Cache技术在本地缓存用户访问过的Web页面和对象，实现相同对象的访问无须占用主干的出口带宽，并提升用户访问因特网页面的相应时间的需求；

(4)能克服网站分布不均的问题，而且能下降网站自身建设和维护成本；

(5)下降“通讯风暴”的影响，提升网络访问的稳定性。

osi模型

物理层、数据链路层、网络层、传输层、会话层、表示层、应用层；

前端性能优化

网络相关

一、尽可能减小 HTTP 请求个数——须权衡

二、使用 CDN（内容分发网络）

三、为文件头指定 Expires 或 Cache-Control ，使内容具备缓存性

四、使用 gzip 压缩内容

五、减小 DNS 查找次数

六、配置 ETags

七、减小 Cookie 的大小

八、使用无 cookie 的域

九、避免 404

十、DNS预解析

css相关

一、避免使用 CSS 表达式

二、用 <link> 代替 @import

三、避免使用滤镜

js相关

一、精简 CSS 和 JS

二、剔除重复的 JS 和 CSS

三、开发智能事件处理程序

html相关

一、避免空的 src 和 href

二、把 CSS 放到顶部

三、把 JS 放到底部

四、将 CSS 和 JS 放到外部文件中

五、避免跳转

六、使 AJAX 可缓存

七、尽早刷新输出缓冲

八、使用 GET 来完成 AJAX 请求

九、减小 DOM 元素个数

十、根据域名划分页面内容

十一、尽可能减小 iframe 的个数

十二、减小 DOM 访问

1三、预渲染

图像、文件相关

一、延迟加载

二、预加载

三、优化图像

四、优化 CSS Spirite

五、不要在 HTML 中缩放图像——须权衡

六、保持单个内容小于25K

七、favicon.ico要小并且可缓存

八、打包组件成复合文本

Webpack相关

一、对于 Webpack4，打包项目使用 production 模式，这样会自动开启代码压缩

二、使用 ES6 模块来开启 tree shaking，这个技术能够移除没有使用的代码

三、优化图片，对于小图可使用 base64 的方式写入文件中

四、按照路由拆分代码，实现按需加载

五、给打包出来的文件名添加哈希，实现浏览器缓存文件