前端八股——浏览器和网络

1.浏览器缓存

主要分为HTTP缓存(主要对于页面静态资源：HTML、CSS、JS、图片等静态文件资源)和非HTTP缓存(应对动态内容，和复杂的场景变换)

HTTP缓存有两部分，强缓存和协商缓存。非HTTP缓存有多部分组。重点介绍强缓存和协商缓存。

强制缓存不会向服务器发送请求，使用浏览器的缓存数据。在强缓存失效的情况下采用协商缓存，向服务器发送请求。

细分：1.浏览器查询浏览器缓存，不存在该缓存结果和缓存标识，向服务器发送HTTP请求 强缓存失效

           2.浏览器查询浏览器缓存，存在该缓存标识，但结果已经失效，携带缓存标识向服务器发送HTTP请求 强缓存失效

           3.浏览器查询浏览器缓存，存在该缓存结果和缓存标识，结果未失效，直接返回该结果 强缓存生效

协商缓存在强缓存失效的情况下进行：在(1)情况下，此时没有缓存标识协商缓存不生效，那么浏览器就会和第一次访问页面时一样访问服务器，已经和缓存脱离关系了。在(2)情况下，有缓存标识，携带缓存标识向服务器发送HTTP请求，即使用协商缓存。再判断协商缓存是否生效：

若服务器端和缓存相比没有更新资源，返回304标识协商缓存生效，重新使用已失效的缓存结果；

若服务器端和缓存相比有更新资源，返回200标识重新更新请求结果，协商缓存失效。

优先级：强缓存优先于协商缓存

接下来就要看浏览器是否采取强缓存和协商缓存，主要根据请求头和响应头中是否有某些字段决定

控制强制缓存的字段分别是Expires和Cache-Control，其中 Cache-Control优先级比Expires高。

控制协商缓存的字段分别有：Last-Modified / If-Modified-Since和Etag / If-None-Match。

其中Etag / If-None-Match的优先级比Last-Modified / If-Modified-Since高。

可自行了解不同请求字段的作用

tip：请求头和响应头。请求头是浏览器发送的，响应头是服务端发送的。服务器端通过响应头设置缓存策略，浏览器根据这些策略自动管理后续的缓存请求。

2.同源策略和跨域

同源策略是浏览器的安全机制，用于限制不同源的网页脚本之间相互影响，防止恶意窃取信息。

同源指的是协议、域名、端口号三者一致，跨域问题则是在三者不一致的情况下发生

同源策略限制了什么?

访问DOM限制，不同的页面不能读取其DOM元素内容。

cookie和LocalStorage，存储信息也不能读取。

ajax请求，不能向不同源的服务器发送请求

如何绕过同源策略，解决跨域问题

1.CORS，在服务器的响应头上添加对应字段，允许特定的源访问即可

2.代理服务器，向代理服务器发送请求，再由该服务器向目标服务器发送请求返回内容  

3.JSONP,利用JavaScript标签<script>不受同源策略的影响，获取数据

tip：nginx反向代理服务器。   正向代理由浏览器配置代理服务器，反向代理由服务器配置代理服务器

3.浏览器的渲染过程

第一阶段：

1.解析HTML和CSS分别生成DOM树和CSSOM树

2.生成render树，根据DOM树和CSSOM树生成render树

3.布局，遍历render树，确定各个元素的屏幕上的位置，生成布局树

4.分层，根据布局分成多层，每层独立于其他层

4.绘制，为每一层生成绘制指令，并没有真正绘制

第二阶段：

5.分块，将每一层分成多个块级区域，进一步细分分层结果

6.光栅化，为每个块绘制位图，提供给GPU

7.合成,GPU根据位图的位置，最终呈现到页面当中

4.回流和重绘

顾名思义

回流：页面DOM节点改变，影响到页面布局，需要重新构建布局再次进行渲染  会影响性能

重绘：元素的颜色、背景等样式发生改变，不影响整体布局，重现渲染页面元素

有重绘不一定有回流，页面布局DOM结构不一定发生变化。有回流一定有重绘。

如何优化：

多个属性能够简写时就简写。boder可以代替boder-width、boder-color、boder-style

避免使用table布局

避免多层嵌套，多层节点样式

避免频繁的用js操纵dom元素和样式

使用 visibility 代替 display:none, 前者只会引起重绘，后者引起回流

5.浏览器的进程和线程

进程是一个正在运行的应用程序，进程之间相互独立。线程是进程内部的执行单元，一个进程可有多个线程。

进程被分配了资源，线程不拥有资源

浏览器的主要进程有：

浏览器主进程，界面显示切换、用户交互、管理子进程

渲染进程，管理浏览器页面元素渲染

GPU进程，渲染浏览器图形元素等

网络进程，管理网络请求

插件进程，管理浏览器插件

多进程优势：增强浏览器的稳定性和稳定性，某个页面崩溃并不会影响其他页面；同时多进程提高资源利用率，CPU多核处理等

浏览器的主要线程有：

js线程，解析js代码，执行js

GUI渲染线程，解析构建dom树、布局树等，进行布局和绘制

(js线程和GUI渲染线程两者互斥不能同时进行)

事件触发线程，控制事件循环，处理异步操作

tip：浏览器是多进程和多线程，但JavaScript是单线程操作，同时操纵dom会有复杂的同步问题，单线程更易于调试和理解。

6.cookie session token

cookie存储在本地客户端，存储的是一个标识符id，用来识别用户的身份信息。这里有个误区，cookie并不是直接存储数据信息，而是通过标识符从数据库里间接识别到对应id的数据信息。

session会话控制，存储在服务器端。存储用户真实的数据信息，和cookie相互配合，当用户通过HTTP请求访问服务器时，服务端会生成一个session-ID,存储在cookie里发送给客户端，这样在下一次访问时，服务器端通过识别ID将对应的数据信息返回给客户端。

token也是被包含在cookie中在客户端和服务器之间相互传递，token三部分组成：Header(头部)、Payload(负载)、Signature(签名)。其中Payload(负载)存储着数据信息，他和session最大的不同即它本身携带着数据信息，而session存储在服务器当中。当服务器从cookie里拿到token时需要对其进行解析然后从Payload中获取到数据返回给客户端。

tip：为什么客户端和服务器之间需要存在这样的逻辑去处理用户数据信息。因为HTTP是无状态的，每次浏览器发送请求都是独立请求，这样的逻辑变相于让无状态模拟成有状态。

7.OSI七层模型(理论)和TCP/IP四层模型(实践),每一层常见协议

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

TCP/IP四层模型:应用层 | 传输层 | 网络层 | 网络接口层

应用层:HTTP、HTTPS、FTP、DNS

传输层:TCP、UDP

网络层:IP、ICMP、ARP、RARP

网络接口层:WIFI(无线)、以太网(有线)

8.TCP和UDP

TCP(传输控制协议)和UDP(用户数据报协议)都是传输层的协议

TCP基于连接进行传输，UDP基于非连接进行传输

TCP更为可靠，要确保在连接成功的状态下，确保数据已经准确发送给对面，UDP建立于非连接基础上，只管发送，无论是否被接收到。

UDP相对于TCP更为迅速，直接进行传输,延迟低，而TCP为确保传输的质量因此速度会慢一点，延迟更高。

根据其优缺点，应用场景不同。TCP应用于发送邮件、浏览网页、传输文件等；UDP应用于视频会议、直播、语音通话等。

9.TCP三次握手和四次挥手(为什么是三次，为什么是四次)

TCP通信过程：三级握手、传输确认、四次挥手

三次握手:这是客户端和服务端建立连接的过程。首先客户端发送一个请求报文称为SYN包(第一次)，服务端接受到报文后并向客户端发送一个SYN+ACK包(第二次)，客户端接受到包之后，在向服务端发送一个ACK包(第三次)，至此正式两者间正式建立连接。

为什么是三次而不是两次?目的是防止失效的连接请求报文发送到服务器导致错误连接。

如果是两次握手:当客户端第一次发送请求包SYN时，因网络影响没有到达服务端，因而导致客户端超时未收到响应而再次发送一个SYN,然后正常接收到SYN+ACK，此时如果第一次发送的SYN突然被服务端成功接受到后，服务器会发送SYN+ACK包，客户端因为已经建立连接而忽视此次回应，导致错误连接，服务端会一直空等导致浪费资源。

三次足以，四次也可以，但没必要。

四次挥手:首先客户端发送一个FIN包告诉服务端--客户端要关闭了，客户端进入终止等待1状态(第一次)；服务端向客户端发送一个包ACK，告诉客户端--服务端进入关闭等待状态，客户端接受到ACK包进入终止等待状态2(第二次)；此时服务端可能还有数据没有传输完，客户端仍能接受数据，等待服务端传输完数据后，服务端发送一个包FIN进入最后确认状态(第三次)；客户端接受到FIN后回复一个包ACK，进入超时等待状态，服务端接受到ACK包后立刻关闭，而服务端在超时等待状态结束后关闭(第四次)。

在最后一次挥手时，如果ACK包在网络中丢失了，此时服务端将无法关闭，会再向客户端发送FIN报文，然后客户端再次发送ACK包确保服务端进行关闭。如果客户端没有超时等待状态而是直接关闭，那么服务端可能因为不稳定的网络而导致无法关闭。

10.TCP可靠传输

确认和重传，接受方在收到一组数据后会发送一个ACK确认报文告诉发送方确认接受；接受方如果一直没发送确认报文，发送方在超时等待后会再次发送数据重新传输。

序列号和确认号，发送方会给发送的一组数据的头部加上一个序列号，接收方在收到数据后在发送的ACK确认报文中会添加一个确认号，表示下次收到的数据的头部的序列号和这个对应。

流量控制，使用滑动窗口机制防止数据量过大导致接收方无法响应，接受方在发送确认报文时，会在TCP头部添加字段告诉发送方当前接受方的缓冲区间，这样发送方发送的数据将不会超过接收方当前的缓冲区间。

拥塞控制，降低网络堵塞和防止瘫痪。

11.TCP滑动窗口

通信双方都拥有两个窗口分别是接受窗口和发送窗口

发送窗口:发送数据多少的缓冲区，接受窗口:接受数据多少的缓冲区，会根据情况随时调整大小优化数据传输性能。

因为双方是相互通信的，既是发送者又是接受者。发送方会根据接受方的接受窗口字段来调整自己发送窗口的大小。

12.TCP流量控制和拥塞控制

有关TCP传输两个重要的知识点，流量控制主要是根据滑动窗口这一机制来实现，不再描述

拥塞控制:四个核心算法 两个重要参数拥塞窗口(cwnd)和慢启动阈值(ssthresh)

慢开始:cwnd一般设置为1，发送方每次接受到一个ACK报文，cwnd翻倍增长，数据的传输速率变大

拥塞避免:当cwnd的值超过ssthresh的值时，进入拥塞避免阶段，此时每次收到确认报文ACK，cwnd加1。一直等到发送方进入超时等待状态导致重新传输，此时认为网络已经堵塞，更新cwnd的值为1，ssthresh为此时阈值的一半，然后再进入慢开始，以此循环。

快重传:如果发送方连续接到三个重复的确认报文，则表明数据包在传输的过程中丢失，此时启动快重传算法，不需要超时等待结束后再重新传输，直接重新传输。

tip:为什么会收到三个重复的确认报文，这是因为确认报文是按照序号顺序来的，如果中间缺失，仍会传输对应的确认报文，来表示有数据包没接受到。

这也是区分丢包和拥塞的关键，拥塞是接收方无法接受到数据因此也不会传输确认报文。

快恢复:在快重传出现后，将cwnd和ssthresh的值都设置为当前拥塞窗口(cwnd)的一半。

13.HTTP协议的理解

HTTP是什么?有什么特点?请求方法有什么?请求报文和响应报文是什么?HTTP状态码对应的含义?

HTTP是超文本传输协议,是客户端和服务端之间通信的规则，基于TCP/IP四层模型的应用层协议

特点:HTTP是无状态的，每一次请求都是独立的；

     HTTP连接模式:短连接和长连接

     短连接:每次HTTP请求都要重新建立TCP连接，从三次握手到通信再到四次挥手，响应成功后即关闭通路。

     长连接:建立TCP连接后，可以发送多次HTTP请求，响应成功也不会关闭。

tip:观察长连接开启状态，请求头字段Connection: keep-alive/close

HTTP工作原理:请求报文和响应报文

请求报文组成:请求行(请求方法、URL、协议版本)、请求头、空行、请求数据

响应报文组成:响应行(协议版本、状态码、服务信息)、响应头、空行、响应数据

tip:URL的理解。URL实际包含:协议、域名、端口号、路径、参数。Base URL包含的是:协议、域名、端口号。

    域名和IP不是一个东西，IP是由数字组成如:122.0.0.0 域名像:www.baidu.com。浏览器的访问URL一般我们看到的都是域名访问，但是实际上还是对IP地址的访问，这样的话其实使用域名是能够让我们实际看到访问的是什么网站(域名更像一层皮囊)。这样当IP地址更换时，我们也不用更改域名，因为其实际已经更改过IP了，但是名字可以不变。端口号一般设置默认的,因此会被隐藏

HTTP请求响应过程:建立TCP连接、客户端发送请求报文、服务端接受报文并返回HTTP响应、客户端接受响应显示内容、释放TCP连接

请求头和响应头不必多说，里边多个字段分别标识客户端请求和服务器响应之间的通信设置。

空行表示，请求头或响应头到此结束

请求/响应数据，进行请求时发送的数据和响应成功后接受的数据。

14.HTTP的状态码

1XX(信息),表示请求被接受,继续处理

2XX(成功),表示请求成功完成

3XX(重定向),表示完成请求需要附加操作

4XX(客户端错误),客户端发送请求有错误

5XX(服务端错误),服务端处理请求有错误

常见的:200 客户端请求成功

       301 永久重定向，服务器URL改变，后续请求转到新URL

       302 临时重定向，当前临时改变，请求转到新URL

       304 针对缓存，服务器资源未改变，不返回资源

       400 客户端请求格式存在错误

       401 客户端未通过身份验证不能访问

       403 客户端通过身份验证但权限不够，不能访问

       404 客户端地址查询错误或者服务端资源已被删除

       500 服务器内部错误

       503 服务器当前不能处理请求，过段时间恢复

15.HTTP的请求方法

GET 从服务器请求资源

POST 往服务器上提交资源

HEAD 请求服务器资源，但只请求响应头(Headers)的资源

PUT  往服务器上更新数据

DELETE 删除服务器数据

16.GET和POST区别

GET在浏览器回退/刷新时,不会重新提交,POST会重新提交请求

GET请求会被浏览器缓存,POST不会被浏览器缓存

GET参数会被浏览器历史记录,POST参数不会被记录

GET的参数写在URL里有长度限制,POST参数放置在请求报文的请求数据中没有限制

GET的安全性差一点,参数会被暴露显示,POST不会暴露更加安全

tip:举个例子

GET方法的请求报文：

请求行：GET/www.baidu.com?name=ChopChoo&age=20 HTTP/1.1

请求头： Host: localhost

空行:

请求数据：空

POST方法的请求报文

请求行：POST/www.baidu.com HTTP/1.1

请求头：Content-Type: application/x-www-form-urlencoded Host: localhost

空行:

请求数据：name=ChopChoo&age=20

还有一个要理解的点,POST也是能获取数据的,相对于GET直接获取较为特殊。POST在提交资源后,服务器要返回处理的结果,这个便是得到的数据。一般常见的像:提交username、password资源，然后获取到对应的服务器验证后的数据。

17.HTTP1.0、HTTP1.1、HTTP2.0

HTTP1.0和HTTP1.1

HTTP1.0默认短连接,1.1默认长连接

1.1支持请求管道化,可以连续发送多个HTTP请求,无需等待一个一个请求进行。

1.1新增HOST字段,使得一个服务器可以承载多个域名

1.0Expires字段控制缓存,1.1新增Cache-Control字段来控制缓存

tip:HOST字段的进一步理解。域名其实是IP的扩充标识,告诉服务器访问的是哪一处资源,使得客户端加载显示。这样一台服务器可以拥有多个域名,运行多个网站(即一个服务器IP拥有多个域名,这样的网站技术被称为虚拟主机)

1.1的缺点:队头阻塞,1.1支持请求管道化,但是服务器是按顺序返回响应的,当一个请求阻塞时,后边的请求即使处理完毕也要等待前边的请求成功后返回响应。

头部信息冗余,发送的HTTP请求头部字段重复。每次发送请求都会重复携带头部字段,造成信息冗余,浪费传输资源。

HTTP2.0和HTTP1.1

HTTP2.0使用二进制分层帧的方式将传输的数据变成更小的帧来传递,并采用二进制格式。

2.0多路复用,解决1.1队头阻塞问题,在二进制分层帧传递数据的方法上,解决队头阻塞问题,防止阻塞的请求影响其他请求的进行。

2.0头部压缩,解决1.1头部信息冗余问题,压缩头部信息字段,提高传输效率,减少信息冗余。

服务器主动推送其认为客户端需要的资源,减少请求次数。

tip:HTTP和HTTPS,HTTPS是在HTTP的基础上,对通信进行加密,防止信息泄露。(这块请自行了解)

18.输入URL确认后发生了什么

1.域名解析

2.建立TCP连接(三次握手确认)

3.客户端发送请求报文

4.服务端发送响应报文

5.浏览器解析渲染页面

6.结束TCP连接(四次挥手)

19.DNS协议

用来解析域名转换为IP地址,整个解析的流程就是不断去查询的过程

浏览器缓存->操作系统缓存hosts文件->本地DNS服务器(递归查询)->根域名服务器(开始迭代查询)->顶级域名服务器->权威域名服务器->本地DNS服务器进行缓存->然后浏览器和操作系统进行缓存

客户端成功解析域名

主机向本地域名服务器查询一般采用递归查询；本地域名服务器向其他域名服务器的查询是迭代查询。

递归就是查到底,迭代指本地DNS在某个域名服务器查不到再去找另一个继续查找。

20.前端网站攻击

XSS跨站脚本攻击:往服务端通过各种方式塞恶意的代码脚本,窃取用户敏感信息。

防范:过滤用户输入的特殊符号,使服务端无法识别并执行恶意代码。设置cookie安全属性,保护用户信息。

CSRF跨站请求伪造,攻击者利用用户登录cookie信息没有过期,通过诱导用户发送恶意请求从而骗过网站的登录保护,让用户在不知情的状态下，进行账户操作。

防范:验证请求来源,阻挡恶意域名的请求。限制请求方法和cookie属性,敏感信息不允许get请求获取,cookie仅允许特定网站请求,这样从其他恶意网站将无法获取到用户信息和恶意操纵。

21.前端性能优化(这里简单介绍)

1.HTML优化:删除多余的属性和注释；使用语义化标签；减少iframe的数量；减少dom层级数量；减少HTTP请求次数；减少dom回流和重绘

2.JavaScript优化:js脚本放到底部加载；从外部引入js脚本代码；删除重复的脚本；防抖和节流；优化代码结构(代码合理合规的存放)

3.懒加载:图片、视频、音频等数据资源

4.浏览器缓存策略

5.服务器优化:服务器设置缓存策略；减少页面重定向；使用HTTP2协议；合理存放服务端资源；优化服务器渲染

个人认为常考的两个点:防抖和节流 懒加载

防抖:在事件回调触发后，等待一段时间后执行，如果在这个时间段内再次触发要重新计时等待，直到等待时间结束后执行事件

节流:在特定的一段时间内，只允许执行一次事件回调，即使不断触发也只执行一次

懒加载:只在资源进入用户所需要的区域时再进行资源加载，并非在初始化阶段加载所有资源(即用户当前需要的和不需要的全部加载出来)