浏览器网络相关

1. 浏览器：repaint，reflow，cookie,session,跨域，缓存，URL参数解析
2. 网络：http1，http2，状态码，http，https，get，post，三次握手

reflow(回流)和repaint(重绘)优化

1. 重绘与回流

   • 重绘repaint: 非结构就如背景色变化时触发repaint。

   • 回流reflow:当页面布局和几何属性引起的改变触发reflow，比如宽高位置的变化。

   • 回流必将引起重绘，但是重绘不一定会引起回流；二者都会造成体验不佳

2. 如何减少重绘和回流?

   • 通过classname或cssText一次性修改样式, 而非一个一个改

   • 离线模式: 克隆要操作的结点, 操作后再与原始结点交换, 类似于虚拟DOM

   • 绝对布局的DOM, 不会造成大量reflow

   • p不要嵌套太深, 不要超过六层

   • js 尽量减少对样式的操作，能用 css 完成的就用 css

   • 对 dom 操作尽量少，能用 createDocumentFragment 的地方尽量用

   • 如果必须要用 js 操作样式，能合并尽量合并不要分多次操作

   • resize 事件 最好加上防抖，能尽量少触发就少触发

   • 加载图片的时候，提前写好宽高

一个页面从输入 URL 到页面加载显示完成，这个过程中都发生了什么？

• 首先会进行 url 解析，根据 dns 系统进行 ip 查找
• 根据 ip 就可以找到服务器，然后浏览器和服务器会进行 TCP 三次握手建立连接，如果此时是 https 的话，还会建立 TLS 连接以及协商加密算法，这里涉及到"https 和 http 的区别"
• 连接建立之后浏览器开始发送请求获取文件，这时这里还会出现一种情况就是缓存，建立连接后是走缓存还是直接重新获取，需要看后台设置，这里涉及到"浏览器缓存机制"，
• 首先获取 html 文件，构建 DOM 树，这个过程是边下载边解析，并不是等 html 文件全部下载完了，再去解析 html，这样比较浪费时间，而是下载一点解析一点
• 解析到 html 头部时候，去找相应的css文件，而css 放头部,js 放尾部，不同的位置会造成渲染的不同，
• 解析到了 html 头部发现有 css 文件，此时下载 css 文件，css 文件也是一边下载一边解析的，构建的是 CSSOM 树，当 DOM 树和 CSSOM 树全部构建完之后，浏览器会把 DOM 树和 CSSOM 树构建成渲染树。
• 样式计算, DOM树 和 CSSOM树有了之后，浏览器开始样式计算，主要是为 DOM 树上的节点找到对应的样式
• 构建布局树，样式计算完之后开始构建布局树。主要是为DOM树上的节点找到页面上对应位置以及一些"display:none"元素的隐藏。
• 构建分层树，布局树完成后浏览器还需要建立分层树，主要是为了满足滚动条，z-index，position 这些复杂的分层操作
• 将分层树图块化，利用光栅找到视图窗口下的对应的位图。主要是因为一个页面可能有几屏那么长，一下渲染出来比较浪费，所以浏览器会找到视图窗口对应的图块，将这部分的图块进行渲染
• 载入解析到的资源文件，渲染页面，完成。在渲染的过程中还会出现重排和重绘。

localStorage 与 sessionStorage

• 共同点: 都保存在浏览器端, 且同源
• localStorage 与 sessionStorage 统称webStorage,保存在浏览器,不参与服务器通信,大小为5M
• 生命周期不同: localStorage永久保存, sessionStorage当前会话, 都可手动清除
• 作用域不同: 不同浏览器不共享local和session, 不同会话不共享session
• Cookie: 设置的过期时间前一直有效, 大小4K.有个数限制, 各浏览器不同, 一般为20个.携带在HTTP头中, 过多会有性能问题.可自己封装, 也可用原生

cookie与session的区别总结

1.Cookie是将会话状态保存在浏览器的技术；Session是将会话状态保存在服务器的技术；

2.Cookie中的数据保存时间较长(可调)；Session中的数据保存时间较短，约为30分钟(可调)；

3.Cookie数据的安全性和稳定性较差(原因是数据保存在用户手中，用户可进行任意修改，病毒可轻易攻击)；

​ Session数据的安全性和稳定性较高(服务器的安全性高，数据存在服务器上安全性高)；

4.Cookie的大小有限制，大小约为4kb。Session的大小无限制，理论上可无限大

5 保存数据，cookie只能保存字符串类型的数据，session可以保存任意类型的数据。

​ cookie对象和session对象一样是用来保存特定的用户相关的数据，用户和服务器连接时，就建立了一个session，服务器为之分配了一个唯一的sessionID。很多时候session是和cookie共同使用的，客户端将请求和cookie发送至服务器，session根据唯一sessionID和cookie辨别用户。这样既增加了安全机制，也可以方便用户操作。

跨域，预检请求，同源策略

预检请求:

请求分为简单请求和非简单请求，非简单请求也就是options预检请求。需预检的请求要求必须首先使用 OPTIONS 方法发起一个预检请求到服务器，以获知服务器是否允许该实际请求。"预检请求“的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响。服务器若接受此次跨域请求，那么当options请求成功返回后，浏览器继续发起第二次请求，也就是真正的ajax请求。以后每次浏览器正常的CORS请求，就都跟简单请求一样，会有一个Origin头信息字段。

大概有三种方法会产生options预检请求：

​ 1、请求方法不是GET/HEAD/POST

​ 2、POST请求的Content-Type并非application/x-www-form-urlencoded, multipart/form-data, 或text/plain

​ 3、请求设置了自定义的header字段

同源策略

同源策略是浏览器的行为，是为了保护本地数据不被JavaScript代码获取回来的数据污染，因此拦截的是客户端发出的请求回来的数据接收，即请求发送了，服务器响应了，但是无法被浏览器接收

同源策略限制内容有：

• Cookie、LocalStorage、IndexedDB 等存储性内容
• DOM节点
• AJAX跨域请求的数据

跨域

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

同源策略限制了通过 XMLHttpRequest 的方式将站点数据发送给跨域的站点。所以就会发生开发中很常见的请求跨域问题

防止XSS、CSFR等攻击, 协议+域名+端口不同

解决跨域的方法

1. jsonp：动态添加script标签

实现：JSONP是通过 script 标签加载数据的方式去获取数据当做 JS 代码来执行。提前在页面上声明一个jsonp回调函数，函数名通过接口传参的方式传给后台，后台解析到函数名后在原始数据上「包裹」这个函数名，发送给前端。换句话说，JSONP 需要对应接口的后端的配合才能实现。

缺点：JSONP只能发GET请求，因为本质上script加载资源就是GET

2. cors(跨域资源共享)

a. 简单请求的实现

• 浏览器直接发出 CORS 请求（浏览器自动在请求头信息中添加 Origin 字段标识请求的来源，服务器根据配置的请求源决定是否返回这次请求）

• 请求源在服务器允许范围内，服务器在响应头中会增加以下几个字段

• //发起请求的请求源或者*，如果要允许浏览器发送 Cookie 则不能设置成*，必须是明确的请求源
  Access-Control-Allow-Origin: http://xxx.com 
  //值只能为 true，表示允许浏览器发送 Cookie 到服务器，需要客户端同时给 AJAX 请求设置 withCredentials = true 属性
  //服务器在不需要浏览器发送 Cookie 时直接去掉该字段
  Access-Control-Allow-Credentials: true 
  //CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：
  //Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、
  //Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。
  Access-Control-Expose-Headers: FooBar
       
  Content-Type: text/html; charset=utf-8复制代码
  

• 请求源不在服务器允许范围内，服务器会返回一个正常的（不带上述几个字段）的响应。浏览器发现响应头中没有 Access-Control-Allow-Origin 字段，则在XMLHttpRequest 对象的 onerror 回调函数中捕捉错误（这种错误无法通过 HTTP 的状态码来识别，状态码有可能是 200）

b. 非简单请求的实现

• 发起预检请求

• -- 在正式通信之前，发起一次HTTP查询请求，当前网页所在的域名是否在服务器的许可名单之中，可以使用哪些 HTTP 动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。OPTIONS /cors HTTP/ 1.1 //预检请求的方法
  Origin:xxx.com // 请求源
  Access-Control-Request-Method:POST //表明后续发送的 CORS 请求会应用到的请求方法
  Access-Control-Request-Headers://指定后续发送的 CORS 请求会携带哪些额外的请求头字段复制代码
  

• 预检请求回应

•   -- 服务器收到"预检"请求以后，检查了 Origin、Access-Control-Request-Method 和Access-Control-Request-Headers 字段以后，确认允许跨域请求，做出回应// 表示服务器允许浏览器在下面字段值定义的域中进行跨域请求，
  // * 号则表示允许所有域进行跨域请求
  Access-Control-Allow-Origin: http://xxx.com
  // 表明服务器支持的所有跨域请求的方法
  Access-Control-Allow-Methods: GET, POST, PUT
  // 表明服务器支持的所有头信息字段，不限于浏览器在"预检"中请求的字段
  Access-Control-Allow-Headers: X-Custom-Header
  //值只能为 true，表示允许浏览器发送 Cookie 到服务器，需要客户端同时给 AJAX 请求设置 withCredentials = true 属性
  //服务器在不需要浏览器发送 Cookie 时直接去掉该字段
  Access-Control-Allow-Credentials: true
         --  如果浏览器否定"预检"请求（即服务器器不会返回 Access-Control-Allow-Origin 响应头），此时服务器会返回一个正常的HTTP回应，但是没有任何CORS相关的头信息字段。然后浏览器就会认定，服务器不同意预检请求，因此触发一个错误，被XMLHttpRequest 对象的 onerror 回调函数捕获。控制台会抛出错误：XMLHttpRequest cannot load http://xxx.com.
  Origin http://xxx1.com is not allowed by Access-Control-Allow-Origin.复制代码
  

• 浏览器发起正常的 CORS 请求（跟简单请求时一样）

c. 操作cookie的条件：

• 服务的响应头中需要携带Access-Control-Allow-Credentials并且为true。
• 浏览器发起ajax需要指定withCredentials 为true
• 响应头中的Access-Control-Allow-Origin一定不能为*，必须是指定的域名

3. 代理

正向代理

nginx反向代理

浏览器的缓存机制

1. 浏览器缓存就是把一个已经请求过的资源拷贝一份存储起来，当下次需要该资源时，浏览器会根据缓存机制决定直接使用缓存资源还是再次向服务器发送请求.

2. 作用: 减少网络传输的损耗以及降低服务器压力。

3. 优先级: 强制缓存 > 协商缓存; cache-control > Expires > Etag > Last-modified

4. http缓存机制是根据HTTP报文的缓存标识进行的，浏览器每次发起请求，都会先在浏览器缓存中查找该请求的结果以及缓存标识，浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中。

强缓存

​ 强制缓存就是向浏览器缓存查找该请求结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程，如果不存在缓存结果和缓存标识，直接向服务器发送请求。如果存在缓存结果和缓存标识，但失效了，就使用协商缓存。如果缓存结果和缓存标识没有失效，就使用强缓存，强缓存是在浏览器端查找，不和服务器交互。当浏览器向服务器发送请求的时候，服务器会将缓存规则放入HTTP响应的报文的HTTP头中和请求结果一起返回给浏览器， ​ 控制强制缓存的字段分别是Expires和Cache-Control，其中Cache-Conctrol的优先级比Expires高。Expires是HTTP/1.0的字段，到了HTTP/1.1，Expires已经被Cache-Control替代，原因在于Expires控制缓存的原理是使用客户端的时间与服务端返回的时间做对比，如果客户端与服务端的时间由于某些原因（时区不同；客户端和服务端有一方的时间不准确）发生误差，那么强制缓存直接失效，那么强制缓存存在的意义就毫无意义。

协商缓存

​ 协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程，协商缓存生效之后直接返回304，资源没有更新。如果协商缓存失败，重新返回200和请求的结果，资源也更新了。 ​ Last-Modified是服务器响应请求时，返回该资源文件在服务器最后被修改的时间。 ​ Etag是服务器响应请求时，返回当前资源文件的一个唯一标识(由服务器生成)

http和https

• http: 最广泛网络协议，BS模型，浏览器高效。
• https: 安全版，通过SSL加密，加密传输，身份认证，密钥

1. https相对于http加入了ssl层, 加密传输, 身份认证;
2. 需要到ca申请收费的证书;
3. 安全但是耗时多，缓存不是很好;
4. 连接方式不同, 端口号也不同, http是80, https是443

http请求头

1. Accept: 浏览器接受的格式
2. Accept-Encoding: 浏览器接受的编码格式
3. Accept-Language: 浏览器接受的语言，用于服务器判断多语言
4. Cache-Control: 控制缓存的时效性
5. Connection: 连接方式，keep-alive且服务端支持，则会复用TCP连接
6. Host: HTTP访问使用的域名
7. If-Modifided-Since: 上次访问时的更改时间，如果服务端认为此时间后自己没有更新，则会给出304响应
8. If-None-Match: 上次访问时使用的E-Tag，通常是页面的信息摘要，比更改时间更加准确一些
9. User-Agent: 客户端标识，因为一些历史原因，多数浏览器的这个字段十分复杂包括操作系统，浏览器内核，版本号等待
10. Cookie:客户端存储的cookie字符串

http状态码

100  Continue  继续，一般在发送post请求时，已发送了http header之后服务端将返回此信息，表示确认，之后发送具体参数信息
200  OK   正常返回信息
201  Created  请求成功并且服务器创建了新的资源
202  Accepted  服务器已接受请求，但尚未处理
301  Moved Permanently  请求的网页已永久移动到新位置。
302 Found  临时性重定向。
303 See Other  临时性重定向，且总是使用 GET 请求新的 URI。
304  Not Modified  自从上次请求后，请求的网页未修改过。

400 Bad Request  服务器无法理解请求的格式，客户端不应当尝试再次使用相同的内容发起请求。
401 Unauthorized  请求未授权。
403 Forbidden  禁止访问。
404 Not Found  找不到如何与 URI 相匹配的资源。

500 Internal Server Error  最常见的服务器端错误。
503 Service Unavailable 服务器端暂时无法处理请求（可能是过载或维护）。

http,tcp,UDP

• TCP（Transmission Control Protocol：传输控制协议；面向连接，可靠传输

• UDP（User Datagram Protocol）：用户数据报协议；面向无连接，不可靠传输

  osi七层应用模型:

  1、应用层协议：HTTP、FTP、SMTP、DNS、TELNET、HTTPS等；

  2、表示层不需要协议；

  3、会话层不需要协议；

  4、传输层协议：TCP、UDP等；

  5、网络层协议：ICMP、IGMP、IP（IPV4 IPV6）、ARP、RARP等； IP地址 32位，

  6、数据链路层协议：802.11、802.16、Wi-Fi、WiMAX、ATM、DTM、GPRS、EVDO、HSPA等；MAC地址 48位

  7、物理层协议：FTP、Telnet、SMTP、SNTP、REXEC、TFTP、LPD、SNMP、NFS、INETD等 。

http1.0， http1.1，http2.0详解

HTTP1.0与HTTP 1.1的主要区别

1. 长连接

• a. 短连接：客户端和服务器每进行一次http操作，就建立一次连接，任务结束就中断连接。

   - 短连接的操作步骤是：
     建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接
  

  b. 长连接：客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用一条已经建立的连接。

  长连接的操作步骤是：
  建立连接——数据传输...（保持连接）...数据传输——关闭连接
  

• c. HTTP实现长连接的方式

   HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接，而HTTP1.1默认支持长连接。
  
  HTTP是基于TCP/IP协议的，创建一个TCP连接是需要经过三次握手的,有一定的开销，如果每次通讯都要重新建立连接的话，对性能有影响。因此最好能维持一个长连接，可以用一个长连接来发多个请求。
  

2. 节约带宽

   • HTTP 1.1支持只发送header信息(不带任何body信息)，如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接收到100，才开始把请求body发送到服务器。这样当服务器返回401的时候，客户端就可以不用发送请求body了，节约了带宽。
   • 另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。

3. 增加catch-control缓存字段

4. 增加HOST域

​ HTTP1.0是没有host域的，HTTP1.1才支持这个参数。

HTTP1.1与HTTP 2.0的主要区别

• 多路复用

  HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。

  当然HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。

  TCP连接有一个预热和保护的过程，先检查数据是否传送成功，一旦成功过，则慢慢加大传输速度。因此对应瞬时并发的连接，服务器的响应就会变慢。所以最好能使用一个建立好的连接，并且这个连接可以支持瞬时并发的请求。

• 二进制分帧

  HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。

• 首部压缩

  HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

• 服务器推送

  HTTP 2.0 新增的一个强大的新功能，就是服务器可以对一个客户端请求发送多个响应。换句话说，除了对最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确地请求。

  有了HTTP2.0的服务器推送，HTTP1.x时代的内嵌资源的优化手段也变得没有意义了。而且使用服务器推送的资源的方式更加高效，因为客户端还可以缓存起来，甚至可以由不同的页面共享（依旧遵循同源策略

总结如下：

http1.0

无状态无连接

http1.1

持久连接

请求管道化

增加缓存处理(新的字段如cache-control)

增加Host字段，支持断点传输等

http2.0

二进制分帧

多路复用(或连接共享)

头部压缩

服务器推送

get请求和post请求的区别

GET：一般用于信息获取，使用URL传递参数，对所发送信息的数量也有限制，一般在2000个字符
POST：一般用于修改服务器上的资源，对所发送的信息没有限制。

GET方式需要使用Request.QueryString来取得变量的值，而POST方式通过Request.Form来获取变量的值，
也就是说Get是通过地址栏来传值，而Post是通过提交表单来传值。

在以下情况中，只能使用 POST 请求：
无法使用缓存文件（更新服务器上的文件或数据库）
向服务器发送大量数据（POST 没有数据量限制）
发送包含未知字符的用户输入时，POST 比 GET 更稳定也更可靠

正向代理和反向代理

正向代理(客户端)

（1）访问原来无法访问的资源，如google （2） 可以做缓存，加速访问资源 （3）对客户端访问授权，上网进行认证 （4）代理可以记录用户访问记录（上网行为管理），对外隐藏用户信息

反向代理(服务器端)

（1）保证内网的安全，可以使用反向代理提供WAF功能，阻止web攻击大型网站，

​ 通常将反向代理作为公网访问地址，Web服务器是内网。

（2）负载均衡，通过反向代理服务器来优化网站的负载

三次握手四次挥手

为了准确无误地把数据送达目标处，TCP协议采用了三次握手策略。用TCP协议把数据包送出去后，TCP不会对传送  后的情况置之不理，它一定会向对方确认是否成功送达。握手过程中使用了TCP的标志：SYN和ACK。
发送端首先发送一个带SYN标志的数据包给对方。接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息。最后，发送端再回传一个带ACK标志的数据包，代表“握手”结束
若在握手过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包。

1. 第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；

2. 第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；

3. 第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。 完成了三次握手，客户端和服务器端就可以开始传送数据。

第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接

四次挥手：客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文，断开连接。

url查询参数解析