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

淡淡的烟草味﹌ 2023-01-13 09:49 137阅读 0赞

### 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，即告诉浏览器在一个小时之内可以缓存这段信息，不需要再发送预检命令（后台处理）

### **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，实现了浏览器与服务器全双工通信，同时允许跨域通讯）

[https://segmentfault.com/a/1190000011145364][https_segmentfault.com_a_1190000011145364]

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

> **强缓存**：不会向服务器发送请求，直接命中内存中的缓存资源
> 
> 请求头或者响应头中设置Cache-Control，如Ca`che-Control:max-age=300`时，则代表在这个请求正确返回时间（浏览器也会记录下来）的5分钟内再次加载资源，就会命中强缓存。
> 
> 强缓存判断是否缓存的依据来自于是否超出某个时间或者某个时间段，而不关心服务器端文件是否已经更新，这可能会导致加载文件不是服务器端最新的内容，**那我们如何获知服务器端内容是否已经发生了更新呢**？此时我们需要用到协商缓存策略。
> 
> **协商缓存**：向服务器发送请求，服务器根据request header内的参数来判断是否需要更新此资源
> 
> **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-Matc**h里
> 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% 作为缓存时间。
> 
> [https://www.jianshu.com/p/54cc04190252][https_www.jianshu.com_p_54cc04190252]
> 
> **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 ：**表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dlYl9K_size_16_color_FFFFFF_t_70][]

###  **Cookie和Session的区别** ###

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

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

### 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://blog.csdn.net/Web\_J/article/details/114303946][https_blog.csdn.net_Web_J_article_details_114303946]
> 
> http1大概有4-10个并发
> 
> **HTTP/2** 通过多路复用、二进制流、Header 压缩等等技术，极大地提高了性能
> 
> **HTTP/3** 中的底层支撑协议是QUIC ，QUIC基于 UDP 实现，又取了 TCP 中的精华，实现了即快又可靠的协议，解决了http2丢包问题
> 
> [http://www.xmhzd.com/study/article/view-1290.html][http_www.xmhzd.com_study_article_view-1290.html]

###  浏览器渲染机制 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdWppYW5mZW5nMTIxNA_size_16_color_FFFFFF_t_70]

**①解析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
> 
> **传播顺序：**
> 
> 首是进入捕获阶段，直到达到目标元素，再进入冒泡阶段。
> 
> [https://blog.csdn.net/qq\_34416331/article/details/103791225][https_blog.csdn.net_qq_34416331_article_details_103791225]

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

> 不支持冒泡的事件：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.服务器缓存

[https_segmentfault.com_a_1190000011145364]: https://segmentfault.com/a/1190000011145364
[https_www.jianshu.com_p_54cc04190252]: https://www.jianshu.com/p/54cc04190252
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dlYl9K_size_16_color_FFFFFF_t_70]: /images/20221022/71ab18f3b2994f60aaaefbbc38fefdd2.png
[https_blog.csdn.net_Web_J_article_details_114303946]: https://blog.csdn.net/Web_J/article/details/114303946
[http_www.xmhzd.com_study_article_view-1290.html]: http://www.xmhzd.com/study/article/view-1290.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdWppYW5mZW5nMTIxNA_size_16_color_FFFFFF_t_70]: /images/20221022/205f652b0add43088390b51f160ea100.png
[https_blog.csdn.net_qq_34416331_article_details_103791225]: https://blog.csdn.net/qq_34416331/article/details/103791225