《网络&浏览器》前端面试题

Cookie 的作用

Cookie 最初被设计出来是为了解决“状态管理”问题。在 Web 开发中，状态管理是指如何保持用户与网站交互的连续性和一致性，尤其是在 HTTP 协议这种无状态的通信协议中。 每当用户浏览器向服务器发送请求时，服务器都会把它当作一个全新的请求处理，而不知道它是同一个用户的连续请求。这个特性使得实现如用户登录等需要跟踪用户状态的网站功能变得非常困难。 为了解决这个问题，Cookie 被引入作为一种在客户端存储数据的方法，以便跟踪和识别用户。当用户首次访问一个网站时，服务器可以发送一个或多个 Cookie 到用户的浏览器。浏览器随后会存储这些 Cookie，并在以后每次用户再次访问该网站时，自动将这些 Cookie 发送回服务器。通过这种方式，服务器可以识别用户并维护用户的状态信息。

浏览器存储的几种方式

1. Cookies
特点：由服务器发送到浏览器，浏览器会存储这些信息，并在之后的请求中将其发送回服务器。Cookies通常用于会话管理、个性化设置和跟踪用户行为。
容量限制：每个域名的容量限制大约为4KB。
生命周期：可以设置过期时间，到期后自动删除。
2. LocalStorage
特点：提供了一个在浏览器中存储数据的简单键值对存储机制。数据在页面刷新和重新打开后依然可用，直到被明确删除。
容量限制：大约5MB。
生命周期：数据永久存储，除非通过JavaScript或用户清除浏览器缓存。
3. SessionStorage
特点：与LocalStorage类似，但存储的数据仅在当前会话（tab/window）中有效。关闭会话后数据将被清除。
容量限制：大约5MB。
生命周期：数据在页面会话期间可用，关闭页面或浏览器后数据被清除。
4. IndexedDB（非关系型数据库）
特点：一个低级API，提供了浏览器中存储大量结构化数据的能力。支持事务、索引、游标等数据库特性。适用于需要存储大量数据或需要在客户端进行复杂查询的应用。
容量限制：没有固定限制，但浏览器会提供一定的存储空间。用户可以管理这些数据。
生命周期：数据永久存储，除非通过JavaScript或用户清除浏览器数据。
5. Web SQL（不推荐使用）
特点：一种尝试在客户端提供关系数据库的解决方案。允许网页创建、查询和操作数据库。
容量限制：因浏览器而异，通常在5MB到50MB之间。
生命周期：数据永久存储，除非通过JavaScript或用户清除浏览器数据。
注意：Web SQL已被废弃，不再推荐使用。主要浏览器厂商已停止其开发。
使用场景
Cookies：适用于存储少量数据，如会话标识符（Session IDs）。
LocalStorage和SessionStorage：适用于存储不需要经常变动的数据，如用户偏好设置。
IndexedDB：适用于需要存储大量数据或进行复杂查询的应用，如离线应用或游戏。

缓存控制字段cache-control 缓存控制

no-cache: 数据内容不能被缓存, 每次请求都重新访问服务器, 若有max-age, 则缓存期间不访问服务器.
no-store: 不仅不能缓存, 连暂存也不可以(即: 临时文件夹中不能暂存该资源).
private(默认): 只能在浏览器中缓存, 只有在第一次请求的时候才访问服务器, 若有max-age, 则缓存期间不访问服务器.
public: 可以被任何缓存区缓存, 如: 浏览器、服务器、代理服务器等.
max-age: 相对过期时间, 即以秒为单位的缓存时间.
no-cache, private: 打开新窗口时候重新访问服务器, 若设置max-age, 则缓存期间不访问服务器.
-  private, 正数的max-age: 后退时候不会访问服务器.
-  no-cache, 正数的max-age: 后退时会访问服务器.

 http/http2/http3/https

HTTP协议(超文本传输协议)，它是基于TCP协议的应用层传输协议，简单来说就是客户端和服务端进行数据传输的一种规则。

HTTP 是一种无状态 (stateless) 协议, HTTP协议本身不会对发送过的请求和相应的通信状态进行持久化处理。这样做的目的是为了保持HTTP协议的简单性，从而能够快速处理大量的事务, 提高效率。

http和https区别    

1.       https协议需要到ca申请证书，一般免费证书很少，需要交费。
2.       http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
3.       http和https使用的是完全不同的连接方式用的端口也不一样，前者是80，后者是443。
4.       http的连接很简单，是无状态的。
5.       HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。

https加密原理：利用对称加密+非对称加密+CA数字证书结合进行加密

https加密原理-CSDN博客

http1大概有4-10个并发

HTTP/2 通过多路复用、二进制流、Header 压缩等等技术，极大地提高了性能

HTTP/3 中的底层支撑协议是QUIC ，QUIC基于 UDP 实现，又取了 TCP 中的精华，实现了即快又可靠的协议，解决了http2丢包问题

前端面试大全：HTTP/2 和 HTTP/3原理介绍及前景分析 - 小萌孩知道 www.xmhzd.com

UDP协议为什么不可靠？

1. 没有连接建立和拆除过程：UDP协议没有连接建立和拆除的过程，通信双方不需要进行握手过程，这使得UDP协议的通信效率比较高，但也导致它无法保证数据传输的可靠性。

2. 没有重传机制：UDP协议不提供重传机制，如果数据包在传输过程中丢失或损坏，UDP协议不会进行重传，而是直接丢弃该数据包，这导致了UDP协议的可靠性较差。

3. 没有流量控制和拥塞控制机制：UDP协议不提供流量控制和拥塞控制机制，这意味着它不能根据网络状况和接收方的处理能力来调整发送速度，可能会导致数据包的丢失和网络拥塞。

总之，UDP协议不可靠的主要原因是它没有连接建立和拆除过程、没有重传机制、没有流量控制和拥塞控制机制等，这使得UDP协议适合于那些对数据传输可靠性要求不高的应用，比如音视频实时传输、游戏数据传输等。

http2.0特性

1. 二进制协议： HTTP/2.0 在传输层上使用二进制格式而不是文本格式，这使得协议解析更加高效。二进制格式的帧可以更快地解析和传输，提高了传输效率。

2. 多路复用（Multiplexing）： HTTP/2.0 允许在单个 TCP 连接上同时发送多个请求和响应。这意味着可以在一个连接上并行发送和接收多个资源，消除了过去 HTTP/1.x 中的序列化请求和响应的限制，从而降低了延迟并提高了性能。

3. 头部压缩（Header Compression）： HTTP/2.0 使用 HPACK 算法对请求和响应头部进行压缩，减少了数据传输的大小。通过减少头部大小，可以降低延迟并提高传输速度，特别是对于带宽受限的情况。

4. 服务器推送（Server Push）： HTTP/2.0 允许服务器在客户端请求之前主动推送资源。服务器可以根据客户端的请求预测并推送可能需要的资源，从而减少了客户端发起额外请求的需求，加快了页面加载速度。

5. 流控制（Flow Control）： HTTP/2.0 支持流控制，可以控制每个流（stream）的传输速度，避免了网络拥塞。流控制允许客户端和服务器动态地调整数据流的传输速率，从而优化了资源利用和性能。

6. 服务器端的服务器推送（Server Hint）： HTTP/2.0 允许服务器在发送响应时提供提示，以指示客户端可能需要的资源。这种服务器端的提示可以帮助客户端提前获取所需资源，从而提高页面加载速度。

get和post的区别

• GET在浏览器回退时是无害的，而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数据包。对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）

axios 的拦截器：interceptors

1. 修改请求头的一些配置项

2. 给请求的过程添加一些请求的图标

3. 给请求添加参数

axios用的 fetch 还是 xhr

XMLHttpRequest

XMLHttpRequest.withCredentials 有什么用?

跨域请求是否提供凭据信息(cookie、HTTP认证及客户端SSL证明等)
也可以简单的理解为，当前请求为跨域类型时是否在请求中协带cookie。

 HTTP request报文结构是怎样的？

1. 首行是Request-Line包括：请求方法，请求URI，协议版本
2. 若干行请求头
3. 消息实体

一个请求报文例子如下：

GET /Protocols/rfc2616/rfc2616-sec5.html HTTP/1.1 -->请求方法/请求URI/协议版本
Host: www.w3.org -->决定着访问哪个虚拟主机
Connection: keep-alive --> 表示是否需要持久连接
Cache-Control: max-age=0  -->强缓存过期时间
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8  -->客户端能够接收的内容类型, 一般是application/json , text/json , text/plain, text/html
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 -->发出请求的用户信息
Referer: https://www.google.com.hk/ -->告诉服务器该网页是从哪个页面链接过来的
Accept-Encoding: gzip,deflate,sdch -->浏览器发给服务器,声明浏览器支持的编码类型
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6 -->表示浏览器所支持的语言类型
Cookie: authorstyle=yes -->  HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器
If-None-Match: "2cc8-3e3073913b100"  //协商缓存唯一标识
If-Modified-Since: Wed, 01 Sep 2004 13:24:52 GMT -->记录页面的最后修改时间

name=qiu&age=25 //报文体

 浏览器的同源策略

同源策略指的是：协议，域名，端口相同，同源策略是一种安全协议
常见场景：

URL                                                                说明                               是否允许通信
http://www.domain.com/a.js
http://www.domain.com/b.js         同一域名，不同文件或路径                   允许
http://www.domain.com/lab/c.js

http://www.domain.com:8000/a.js
http://www.domain.com/b.js         同一域名，不同端口                            不允许
 
http://www.domain.com/a.js
https://www.domain.com/b.js        同一域名，不同协议                             不允许
 
http://www.domain.com/a.js
http://192.168.4.12/b.js               域名和域名对应相同ip                         不允许
 
http://www.domain.com/a.js
http://x.domain.com/b.js              主域相同，子域不同                               不允许
http://domain.com/c.js
 
http://www.domain1.com/a.js
http://www.domain2.com/b.js        不同域名                                         不允许

跨域

跨域是指一个域下的文档或脚本试图去请求另一个域下的资源

1、 通过jsonp跨域（只能实现get一种请求）
2、 document.domain + iframe跨域（此方案仅限主域相同，子域不同的跨域应用场景。实现原理：两个页面都通过js强制设置document.domain为基础主域，就实现了同域。）
3、 location.hash + iframe（实现原理： a欲与b跨域相互通信，通过中间页c来实现。 三个页面，不同域之间利用iframe的location.hash传值，相同域之间直接js访问来通信。）
4、 window.name + iframe跨域（实现原理：name值在不同的页面（甚至不同域名）加载后依旧存在，并且可以支持非常长的 name 值（2MB））
5、 postMessage跨域（h5新增api，可以实现：a.） 页面和其打开的新窗口的数据传递 b.） 多窗口之间消息传递 c.） 页面与嵌套的iframe消息传递 d.） 上面三个场景的跨域数据传递）
6、 跨域资源共享（CORS）（服务端设置Access-Control-Allow-Origin即可，读取的cookie为跨域请求接口所在域的cookie，而非当前页）
7、 nginx代理跨域（通过nginx配置一个代理服务器（域名与domain1相同，端口不同）做跳板机，反向代理访问domain2接口，并且可以顺便修改cookie中domain信息，方便当前域cookie写入，实现跨域登录。）
8、 nodejs中间件代理跨域（node中间件实现跨域代理，原理大致与nginx相同，都是通过启一个代理服务器，实现数据的转发）
9、 WebSocket协议跨域（h5新api，实现了浏览器与服务器全双工通信，同时允许跨域通讯）

跨域服务器会收到请求吗？

简单请求，服务器是能接受到请求的，也会返回响应，但是返回的时候，会被浏览器拦截;复杂请求，浏览器会先发一个预检请求，去验证服务器是否允许跨域，如果允许跨越，才会发起真正的 http 请求:否则服务器接受不到真正的 http请求。

cors简单请求和非简单请求的区别

简单请求：
方法为：post/get/head
绝对不是put和delete，put是传文件，delete是删文件肯定不安全，不可能不发option

Request header里面（注意是请求头，不是响应头）

无自定义头！！！！！
Content-Type为以下几种：
– text/plain
–multipart/form-data
–application/x-www-form-urlencoded

非简单请求

工作中常见的有：

• put,delete方法的ajax请求
• 发送json格式的ajax请求
• 带自定义头的ajax请求

如果是非简单请求，会先发一个命令，检查通过之后才会真正把跨域请求发出去。

预检命令

预检命令包含下面三个字段
access-control-request-headers
access-control-request-method
origin
预检命令是浏览器自动发出

预检命令的缓存

非简单请求每次会发出两条请求，自然会影响我们的效率，HTTP协议里面增加了一个响应头可以用来缓存我们的预检命令。
该响应头字段时access-control-max-age，即告诉浏览器在一个小时之内可以缓存这段信息，不需要再发送预检命令（后台处理）

滑动验证页面

 浏览器的缓存机制（http缓存）

强缓存：不会向服务器发送请求，直接命中内存中的缓存资源

请求头或者响应头中设置Cache-Control，如Cache-Control:max-age=300时，则代表在这个请求正确返回时间（浏览器也会记录下来）的5分钟内再次加载资源，就会命中强缓存。

命中强缓存条件

1. Cache-Control: max-age=xxx
2. 响应头有 Expires（有效期）
3. 响应头存在ETag和Last-Modified（协商缓存）且 不存在Cache-Control：no-cache

强缓存判断是否缓存的依据来自于是否超出某个时间或者某个时间段，而不关心服务器端文件是否已经更新，这可能会导致加载文件不是服务器端最新的内容，那我们如何获知服务器端内容是否已经发生了更新呢？此时我们需要用到协商缓存策略。

协商缓存：向服务器发送请求，服务器根据request header内的参数来判断是否需要更新此资源

协商缓存过程：

1. 第一次请求服务器，服务器返回200状态码、Last-Modified时间戳、ETag签名和完整资源
2. 浏览器保存资源内容,以及Last-Modified和ETag值
3. 再次请求浏览器带上If-Modified-Since（值为上次服务器返回的Last-Modified）和If-None-Match（上次服务器返回的ETag）请求头
4. 服务器收到请求后,对比当前资源文件的最后修改时间 是否等于 If-Modified-Since 以及资源文件的ETag 是否等于 If-None-Match （ETag优先级高于Last-Modified）
5. 如果相同则返回304，客户端使用缓存
6. 如果不相同则服务器返回资源，且返回新的ETag 和 Last-Modified，并更新到缓存

Last-Modified和If-Modified-Since

1. 第一次访问，服务器返回资源最后修改时间Last-Modified
2. 下次访问浏览器请求头中添加If-Modified-Since，值为上一次访问得到的Last-Modified
3. 服务器响应请求，会根据 If-Modified-Since 中的值与服务器中这个资源的最后修改时间对比，决定是否要更新

缺点：

• 如果本地打开缓存文件，即使没有对文件进行修改，但还是会造成 Last-Modified 被修改，服务端不能命中缓存导致发送相同的资源
• 因为 Last-Modified 只能以秒计时，如果在不可感知的时间内修改完成文件，那么服务端会认为资源还是命中了，不会返回正确的资源

ETag和If-None-Match

1. 第一次访问时服务器返回当前资源文件的一个唯一标识(由服务器生成)ETag，只要资源有变化，Etag就会重新生成。
2. 下次次访问会将上一次返回的Etag值放到request header里的If-None-Match里
3. 服务器响应请求，需要比较客户端传来的If-None-Match跟自己服务器上该资源的ETag是否一致，决定是否要更新

Etag和Last-Modified区别：

• 首先在精确度上，Etag要优于Last-Modified。
• 第二在性能上，Etag要逊于Last-Modified，毕竟Last-Modified只需要记录时间，而Etag需要服务器通过算法来计算出一个hash值。
• 第三在优先级上，服务器校验优先考虑Etag

使用场景：

1、频繁变动的资源

对于频繁变动的资源，首先需要使用Cache-Control: no-cache 使浏览器每次都请求服务器，然后配合 ETag 或者 Last-Modified 来验证资源是否有效。这样的做法虽然不能节省请求数量，但是能显著减少响应数据大小。

2、不常变化的资源

通常在处理这类资源时，给它们的 Cache-Control 配置一个很大的 max-age=31536000 (一年)，这样浏览器之后请求相同的 URL 会命中强制缓存。而为了解决更新的问题，就需要在文件名(或者路径)中添加 hash， 版本号等动态字符，之后更改动态字符，从而达到更改引用 URL 的目的，让之前的强制缓存失效 (其实并未立即失效，只是不再使用了而已)。

如果什么缓存策略都没设置，那么浏览器会怎么处理？

对于这种情况，浏览器会采用一个启发式的算法，通常会取响应头中的 Date 减去 Last-Modified 值的 10% 作为缓存时间。

深入理解浏览器的缓存机制 - 简书

cache-control中no-cache和no-store的区别

1.no-cache：是把资源进行了本地缓存，在浏览器使用缓存之前，会使用last-Modified和Etag往返浏览器进行对比，判断时间和唯一标识符和服务器的是否一致，一致的话304使用缓存，不一致的话请求服务器。

2.no-store：才是真正的完完全全的禁止本地缓存。

资源预加载preload和资源预读取prefetch的区别

1. preload主要用于预加载当前页面需要的资源；而prefetch主要用于加载将来页面可能需要的资源
2. preload需要使用as属性指定特定的资源类型以便浏览器为其分配一定的优先级，并能够正确加载资源
3. 不论资源是否可以缓存，prefecth会存储在net-stack cache中至少5分钟；
4. preload和prefetch都没有同域名的限制；
5. 当一个资源被 preload 或者 prefetch 获取后，它将被放在内存缓存中等待被使用，如果资源位存在有效的缓存极致（如 cache-control 或 max-age），它将被存储在 HTTP 缓存中可以被不同页面所使用。
6. 对于 preload 来说，一旦页面关闭了，它就会立即停止 preload 获取资源，而对于 prefetch 资源，即使页面关闭，prefetch 发起的请求仍会进行不会中断。

 http常见状态码

• 200 ：请求成功
• 301 ：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；
• 302 ：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；
• 400 ：表示请求报文中存在语法错误；
• 401 ：未经许可，需要通过HTTP认证；
• 403 ：服务器拒绝该次访问（访问权限出现问题）
• 404 ：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用；
• 500 ：表示服务器在执行请求时发生了错误，也有可能是web应用存在的bug或某些临时的错误时；
• 503 ：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；

 Cookie和Session的区别

session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而session保存在服务器上,客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上，这就是session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了

• cookie数据存放在客户的浏览器上，session数据放在服务器上（一般以内存、数据库、文件形式）。
• session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能 考虑到减轻服务器性能方面,应当使用Cookie;
• 单个cookie保存的数据不能超过4K，Session没有大小限制；
• 总结：Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在内存，集群、数据库、文件中；Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。

 浏览器渲染机制

①解析HTML生成DOM树
②解析CSS生成CSSOM规则树
③将DOM树与CSSOM规则树合并在一起生成渲染树
④遍历渲染树开始布局，计算每个节点的位置大小信息
⑤将渲染树每个节点绘制到屏幕

 CDN原理

内容分发网络。基本原理是避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容能够传输的更快、更稳定。

资源上传cdn之后，当用户访问cdn的资源地址之后会经历下面的步骤：

1. 首先经过本地的dns解析，请求cname指向的那台cdn专用的dns服务器。
2. dns服务器返回全局负载均衡的服务器ip给用户
3. 用户请求全局负载均衡服务器，服务器根据ip返回所在区域的负载均衡服务器ip给用户
4. 用户请求区域负载均衡服务器，负载均衡服务器根据用户ip选择距离近的，并且存在用户所需内容的，负载比较合适的一台缓存服务器ip给用户。当没有对应内容的时候，会去上一级缓存服务器去找，直到找到资源所在的源站服务器，并且缓存在缓存服务器中。用户下一次在请求该资源，就可以就近拿缓存了。

注意： 因为cdn的负载均衡和就近选择缓存都是根据用户的ip来的，服务器只能拿到local dns的ip，也就是网络设置中设置的dns ip，如果这个设置的不合理，那么可能起不到加速的效果。可能就近找到的缓存服务器实际离得很远。

总结

通过dns解析到全局负载均衡服务器，然后再到区域的负载均衡，之后根据一些条件来找合适的缓存服务器，如果第一次访问就从源站拿过来缓存。 需要注意的是一切都是根据请求的ip来的，如果ip不合理，那么可能起不到加速效果。缓存和负载均衡的思想在减轻服务器压力方面其实是很常见的

dns预解析

概念： 

• DNS预解析是浏览器试图在用户访问链接之前解析域名，这是计算机的正常DNS解析机制。
• 域名解析后，如果用户确实访问该域名，那么DNS解析时间将不会有延迟。
• 遇到网页中的超链接，DNS prefetching从中提取域名并将其解析为IP地址，这些工作在用户浏览网页时，使用最少的CPU和网络在后台进行解析。
• 当用户点击这些已经预解析的域名，可以平均减少200毫秒耗时（假设用户最近还未访问过该域名）。

用法：

可以在页面的html标签中添加dns-prefetch告诉浏览器对指定域名预解析，如下：

<link rel="dns-prefetch" href="//domain.com">

HTML5 的离线储存怎么使用，工作原理能不能解释一下 ？

1.在用户没有与因特网连接时，可以正常访问站点或应用，在用户与因特网连接时，更新用户机器上的缓存文件

2.HTML5的离线存储是基于一个新建的 .appcache 文件的缓存机制（不是存储技术），通过这个文件上的解析清单离线存储资源

这些资源会像cookie一样被存储了下来。之后当网络在处于离线状态下时，浏览器会通过被离线存储的数据进行页面展示

3.如何使用：

• 页面头部像下面一样加入一个 manifest 的属性；
• 在 cache.manifest文件的编写离线存储的资源
• 在离线状态时，操作window.applicationCache进行需求实现

浏览器是怎么对 HTML5 的离线储存资源进行管理和加载的呢？

在线的情况下,浏览器发现html 头部有 manifest 属性,他会请求manifest 文件,如果时第一次访问app,那么浏览器就会根据manifest 文件的内容下载相应的资源并进行离线存储。

                     如果已经访问过app并且资源已经离线存储了，那么浏览器就会使用离线资源加载页面，

                     然后浏览器会对比新的manifest 文件与旧的manifest 文件，如果文件没有发生改变，就不做任何操作，如果文件改变了，那么就会重新下载文件中的资源并进行离线存储

离线情况下，浏览器就直接使用离线存储的资源

请描述一下 cookie ， sessionStorage 和 localStorage 的区别 ？

1.cookie 是网站为了标示用户身份储存在用户本地终端上的数据（通常经过加密）
2.cookie数据始终在同源的http请求中携带（即使不需要），即会在浏览器和服务器间来回传递
3.sessionStorage 和 localStorage 不会主动把数据发给服务器，仅在本地保存
4.存储限制：
    1）cookie 数据不能超过4k
    2）sessionStorage 和 localStorage 虽然也有存储大小的限制，但比 cookie 大得多，可以达到5M或更多
5.有期时间：
    1）localStorage 持久存储数据，浏览器关闭后数据不丢失除非主动删除数据，相同浏览器的不同页面间可以共享相同的localStorage的的（页面属于相同域名和端口）
    2）sessionStorage 数据在当前的生命周期为当前窗口或标签页，关闭后主动删除，不同页面或标签页间无法共享的的sessionStorage的信息，这里需要注意的是，页面及标签页仅指顶级窗口，如果一个标签页包含多个IFRAME标签且他们属于同源页面，              那么他们之间是可以共享的的sessionStorage的。
    3）cookie 设置的 cookie 过期时间之前一直有效，即使窗口或浏览器关闭

怎么清除

删除某条数据
localStorage.removeItem(“tKey“);
批量删除数据
localStorage.clear();

页面渲染触发的事件

页面加载时，大致可以分为以下几个步骤：

1. 　　开始解析HTML文档结构
2. 　　加载外部样式表及的的JavaScript的脚本
3. 　　解析执行的的JavaScript的脚本
4. 　　DOM树渲染完成
5. 　　加载未完成的外部资源（如图片）
6.        页面加载成功

   触发的事件

1. document readystatechange事件（ readyState  属性描述了文档的加载状态，在整个加载过程中document.readyState会不断变化，每次变化都会触发readystatechange事件。）
2. document DOMContentLoaded事件（DOM树渲染完成时触发DOMContentLoaded事件，此时可能外部资源还在加载.jquery中的ready事件就是同样的效果）

3.  window load事件（所有的资源全部加载完成会触发window的加载事件。）

捕获和冒泡

1.W3C 中定义事件的发生经历三个阶段：捕获阶段、目标阶段、冒泡阶段
2.冒泡型事件：当你使用事件冒泡时，子级元素先触发，父级元素后触发
3.捕获型事件：当你使用事件捕获时，父级元素先触发，子级元素后触发
4.DOM 事件流：同时支持两种事件模型：捕获型事件和冒泡型事件

指定触发时机：

使用 addEventListener 监听事件，默认是监听冒泡阶段的事件，但可以通过 useCapture 参数，来指定在什么阶段触发事件。

若 useCapture为 true，则是在捕获阶段就触发事件。若 useCapture为 false，则是在冒泡阶段触发事件。

阻止事件传播：

• 阻止冒泡：在 W3c 中，使用 stopPropagation() ；在IE下设置 cancelBubble = true
• 阻止捕获：阻止事件的默认行为，例如 click - <a> 后的跳转。在 W3c 中，preventDefault() ，在 IE 下设置 window.event.returnValue = false

传播顺序：

首是进入捕获阶段，直到达到目标元素，再进入冒泡阶段。

JS 事件触发机制-CSDN博客

浏览器中哪些事件冒泡，哪些不冒泡？

不支持冒泡的事件：resize scroll focus blur mouseenter mouseleave load unload media相关事件

所有点击事件，键盘事件和滚轮事件以及拖拽事件支持冒泡，打字composition事件，mousemove，mouseout，mouseup，mousedown，select选定文本

 从输入url到页面呈现给用户，经历了哪些阶段 

1.输入url，浏览器进行dns解析，如果本地host有对应的ip就会对这个ip对应的服务器发起请求，如果没有就会查找浏览器是否有dns缓存，若有缓存就会读取缓存，若没有缓存，就会在dns解析服务器中解析dns

2.建立tcp链接，中间有三次握手

3.发起http请求

4.服务端接收并处理http请求

5.服务端响应请求

6.浏览器接收服务端响应的请求数据

7.浏览器解析html，css，js

收到的 HTML 如果包含几十个图片标签，这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢？
如果图片都是 HTTPS 连接并且在同一个域名下，那么浏览器在 SSL 握手之后会和服务器商量能不能用 HTTP2，如果能的话就使用 多路复用（Multiplexing ）功能在这个连接上进行多路传输。不过也未必会所有挂在这个域名的资源都会使用一个 TCP 连接去获取，但是可以确定的是多路复用（Multiplexing ） 很可能会被用到。
如果发现用不了 HTTP2 呢？或者用不了 HTTPS（现实中的 HTTP2 都是在 HTTPS 上实现的，所以也就是只能使用 HTTP/1.1）。那浏览器就会在一个 HOST 上建立多个 TCP 连接，连接数量的最大限制取决于浏览器设置，这些连接会在空闲的时候被浏览器用来发送新的请求，如果所有的连接都正在发送请求呢？那其他的请求就只能等等了。

从用户刷新网页开始，一次 js 请求一般情况下有哪些地方会有缓存处理 ？

1.dns 缓存
2.cdn 缓存
3.浏览器缓存
4.服务器缓存