前言
【精简版】前端面试宝典(网络/浏览器),精简前端各个模块的知识点,方便熟记
计算机网络
一、HTTP,超文本传输协议
概念:HTTP(Hyper Text Transfer Protocol)定义了客户端和服务器之间交换报文的格式和方式,默认使用 80 端口。它使用 TCP 作为传输层协议,保证了数据传输的可靠性。
优点:
- 支持客户端/服务器模式
- 简单快速:客户向服务器请求服务时,只需传送请求方法和路径。由于 HTTP 协议简单,使得 HTTP 服务器的程序规模小,因而通信速度很快。
- 无连接:无连接就是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接,采用这种方式可以节省传输时间。
- 无状态:HTTP 协议是无状态协议,这里的状态是指通信过程的上下文信息。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能会导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就比较快。
- 灵活:HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。
缺点:
- 无状态协议,HTTP 服务器不会保存关于客户的任何信息。
- 明文传输,不安全
1. 常见的HTTP请求方法
- GET: 向服务器获取数据;
- POST:将实体提交到指定的资源,通常会造成服务器资源的修改;
- PUT:上传文件,更新数据;
- DELETE:删除服务器上的对象;
- HEAD:获取报文首部,与GET相比,不返回报文主体部分;
- OPTIONS:询问支持的请求方法,用来
跨域请求; - CONNECT:要求在与代理服务器通信时建立隧道,使用隧道进行TCP通信;
- TRACE: 回显服务器收到的请求,主要⽤于测试或诊断。
(1) GET 和 POST 的请求的区别
区别:
| GET | POST | |
|---|---|---|
| 作用 | 多用于从服务端获取资源 | 一般用来向服务端提交资源 |
| 应用场景 | 一个幂等的请求,一般用于对服务器资源不会产生影响的场景,比如请求网页的资源 | 不是一个幂等的请求,一般用于对服务器资源会产生影响的情景,比如注册用户 |
| 是否缓存 | 浏览器一般会缓存 | 不缓存 |
| 参数长度限制 | 传送的数据量较小,不能大于2KB | 传送的数据量较大,一般被默认为不受限制 |
| 发送的报文格式 | 实体部分为空 | 实体部分一般为向服务器发送的数据 |
| 数据 | 浏览器对url有长度限制,get只能发送ASCII字符 | post能发送更多的数据类型,且发送的数据量更大 |
- 安全性: Get 请求可以将请求的参数放入 url 中向服务器发送,这样的做法相对于 Post 请求来说是不太安全的,因为请求的 url 会被保留在历史记录中。
冥等性:对于同一个请求,请求一次或多次,对服务端数据的影响都是一样的
(2) POST 和 PUT 请求的区别
- PUT请求是更新数据,向服务器端发送数据,从而修改数据的内容,但是不会增加数据的种类等。
- POST请求是创建数据,向服务器端发送数据,该请求会改变数据的种类等资源,它会创建新的内容。
(3) 与缓存相关的HTTP请求头有哪些
- 强缓存:
Expires和Cache-Control - 协商缓存:
Etag、If-None-Match和Last-Modified、If-Modified-Since
二、HTTPS,超文本传输安全协议
概念:HTTPS(Hypertext Transfer Protocol Secure)是一种通过计算机网络进行安全通信的传输协议,HTTPS经由HTTP进行通信,利用SSL/TLS来加密数据包。
作用:建立一个信息安全通道,提供对网站服务器的身份认证,确保数据传输的隐私与完整性,确保网站的真实性。
HTTP协议采用明文传输信息,存在信息窃听、信息篡改和信息劫持的风险,而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能,可以避免此类问题发生。
安全层的主要职责就是对发起的HTTP请求的数据进行加密操作 和 对接收到的HTTP的内容进行解密操作。
优点:
- 使用HTTPS协议可以认证用户和服务器,确保数据发送到正确的客户端和服务器;
- 使用HTTPS协议可以进行加密传输、身份认证,通信更加安全,防止数据在传输过程中被窃取、修改,确保数据安全性;
- HTTPS是现行架构下最安全的解决方案,虽然不是绝对的安全,但是大幅增加了中间人攻击的成本;
缺点:
- HTTPS需要做服务器和客户端双方的加密个解密处理,耗费更多服务器资源,过程复杂;
- HTTPS协议握手阶段比较费时,增加页面的加载时间;
- SSL证书是收费的,功能越强大的证书费用越高;
- HTTPS连接服务器端资源占用高很多,支持访客稍多的网站需要投入更大的成本;
- SSL证书需要绑定IP,不能再同一个IP上绑定多个域名。
三、HTTP 和 HTTPS 的区别
| http | https | |
|---|---|---|
| 默认端口号 | 80 | 443 |
| 开头格式 | http:// | https:// |
| 安全性 | 不安全,明文传输 | 安全,具有安全性的 ssl 加密传输协议 |
| 费用 | 不需要 | 需要 ca 证书,费用较高 |
- http 的信息是明文传输的,https 是具有安全性的 ssl 加密传输协议,可防止数据在传输过程中被窃取、改变,确保数据的完整性(当然这种安全性并非绝对的,对于更深入的 Web 安全问题,此处暂且不表)。
- http 的连接很简单,是无状态的。https 握手阶段比较费时,会使页面加载时间延长 50%,增加 10%~20%的耗电。
- https 缓存不如 http 高效,会增加数据开销。
- Https 协议需要 ca 证书,费用较高,功能越强大的证书费用越高。
- SSL 证书需要绑定
IP,不能再同一个 IP 上绑定多个域名,IPV4 资源支持不了这种消耗。
TLS/SSL,安全传输层协议
TLS/SSL(Transport Layer Security)是介于TCP和HTTP之间的一层安全传输层协议,不影响原有的TCP协议和HTTP协议。
TLS/SSL的功能实现主要依赖三类基本算法:散列函数hash、对称加密、非对称加密。这三类算法的作用如下:
- 基于散列函数验证信息的完整性
- 对称加密算法采用协商的秘钥对数据加密
- 非对称加密实现身份认证和秘钥协商
四、HTTP状态码
常见状态码:200、304、401、403、404、500
状态码类别
(1) 1XX Informational(信息性状态码):状态码1XX 表示接受的请求正在处理
(2) 2XX 成功:表示请求被正常处理了。
- 200 OK:从客户端发来的请求在服务器端被正常处理
- 204 No content:请求成功,但响应报文不含实体的主体部分
- 205 Reset Content:请求成功,但响应报文不含实体的主体部分,但与 204 响应不同在于要求请求方重置内容
- 206 Partial Content:客户端进行了范围请求,而服务端执行了这部分的GET请求
(3) 3XX 重定向:表明浏览器需要执行某些特殊的处理以正确处理请求
- 301 moved permanently:永久重定向,表示请求的资源已被分配了新的 URL
- 302 found:临时重定向,表示请求的资源临时(本次)被分配了新的 URL
- 303 see other:表示请求的资源存在着另一个 URL,应使用 GET 方法定向获取资源
- 304 not modified:与浏览器缓存相关,表示服务器允许访问资源,但因发生请求未满足条件的情况
- 307 temporary redirect:临时重定向,和302含义类似,但是期望客户端保持请求方法不变向新的地址发出请求
(4) 4XX 客户端错误:表明客户端是发生错误的原因所在,服务器无法处理请求
- 400 bad request,请求报文存在语法错误
- 401 unauthorized,表示发送的请求需要有通过 HTTP 认证的认证信息
- 403 forbidden,服务器拒绝请求。(一般为客户端的用户权限不够)
- 404 not found (未找到),服务器上没有找到请求的资源
(5) 5XX 服务器错误:表明服务器本身发生错误
- 500 internal sever error:表示服务器端在执行请求时发生了错误
- 502 Bad Gateway:表明扮演网关或代理角色的服务器,从上游服务器中接收到的响应是无效的
- 501 Not Implemented:服务器不支持当前请求所需要的某个功能
- 503 service unavailable:表明服务器暂时处于超负载或正在停机维护,无法处理请求
- 504 Gateway Timeout:表示网关或者代理的服务器无法在规定的时间内获得想要的响应,HTTP1.1新加入的
HTTP状态码304是多好还是少好
服务器为了提高网站访问速度,对之前访问的部分页面指定缓存机制,当客户端在此对这些页面进行请求,服务器会根据缓存内容判断页面与之前是否相同,若相同便直接返回304,此时客户端调用缓存内容,不必进行二次下载。
状态码304不应该认为是一种错误,而是对客户端有缓存情况下服务端的一种响应。
搜索引擎蜘蛛会更加青睐内容源更新频繁的网站。通过特定时间内对网站抓取返回的状态码来调节对该网站的抓取频次。若网站在一定时间内一直处于304的状态,那么蜘蛛可能会降低对网站的抓取次数。相反,若网站变化的频率非常之快,每次抓取都能获取新内容,那么日积月累,的回访率也会提高。
产生较多304状态码的原因:
- 页面更新周期长或不更新
- 纯静态页面或强制生成静态html
304状态码出现过多会造成以下问题:
- 网站快照停止;
- 收录减少;
- 权重下降。
五、跨域问题
详细介绍:【专题版】前端面试知识点(跨域问题)
同源策略:是浏览器对 JavaScript 实施的安全限制,只要协议、域名、端口有任何一个不同,都被当作是不同的域。
URL的组成部分:
跨域,是指浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的。
跨域原理,即是通过各种方式,避开浏览器的安全限制。
解决跨域方案
(1) CORS,跨域资源共享
(2) Node 正向代理
思路:利用服务端请求不会跨域的特性,让接口和当前站点同域。
(3) Nginx 反向代理
(4) JSONP
原理:JSONP 主要就是利用了 script 标签没有跨域限制的这个特性来完成的。
(5) Websocket
(6) window.postMessage
(7) document.domain + Iframe:
- 只能用于
二级域名相同的情况下适用该方法 - 原理:两个页面都通过js强制设置document.domain为基础主域,就实现了同域。
(8) window.location.hash + Iframe
(9) window.name + Iframe
- 原理:利用在一个浏览器窗口内,载入所有的域名都是共享一个window.name
(10) 关闭浏览器策略
相关资料:
-
解决方案
最初做项目的时候,使用的是jsonp,但存在一些问题,使用get请求不安全,携带数据较小,后来也用过iframe,但只有主域相同才行,也是存在些问题,后来通过了解和学习发现使用代理和proxy代理配合起来使用比较方便,就引导后台按这种方式做下服务器配置,在开发中使用proxy,在服务器上使用nginx代理,这样开发过程中彼此都方便,效率也高;现在h5新特性还有 windows.postMessage()
-
CORS CORS(Cross-origin resource sharing)跨域资源共享 服务器设置对CORS的支持原理:服务器设置Access-Control-Allow-Origin HTTP响应头之后,浏览器将会允许跨域请求
-
proxy代理 目前常用方式,通过服务器设置代理
-
window.postMessage() 利用h5新特性window.postMessage()
-
六、网络模型
OSI七层模型
ISO为了更好的使网络应用更为普及,推出了OSI参考模型。
-
应用层:
OSI参考模型中最靠近用户的一层,是为计算机用户提供应用接口,也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有:HTTP,HTTPS,FTP,POP3、SMTP等。 -
表示层:表示层提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。
-
会话层:负责建立、管理和终止表示层实体之间的通信会话
-
传输层:建立了主机端到端的链接,作用是为上层协议提供端到端的可靠和透明的数据传输服务,包括处理差错控制和流量控制等问题。
TCPUDP就是在这一层。端口号既是这里的“端” -
数据链路层:
-
物理层:实际最终信号的传输是通过物理层实现的
TCP/IP五层协议
五层:应用层、传输层、网络层、数据链路层、物理层
TCP/IP五层协议和OSI的七层协议对应关系如下
-
应用层 (application layer) :直接为应用进程提供服务。应用层协议定义的是应用进程间通讯和交互的规则,不同的应用有着不同的应用层协议,如 HTTP协议(万维网服务)、FTP协议(文件传输)、SMTP协议(电子邮件)、DNS(域名查询)等。
-
传输层 (transport layer) :有时也译为运输层,它负责为两台主机中的进程提供通信服务。TCP协议与UDP协议就在该层。
-
网络层 (internet layer) :有时也译为网际层,它负责为两台主机提供通信服务,并通过选择合适的路由将数据传递到目标主机。
-
数据链路层 (data link layer) :负责将网络层交下来的 IP 数据报封装成帧,并在链路的两个相邻节点间传送帧,每一帧都包含数据和必要的控制信息(如同步信息、地址信息、差错控制等)。
-
物理层 (physical Layer) :确保数据可以在各种物理媒介上进行传输,为数据的传输提供可靠的环境。
七、TCP与UDP
TCP 和 UDP都是传输层协议,他们都属于TCP/IP协议族
UDP,用户数据报协议
UDP(User Datagram Protocol)在网络中它与TCP协议一样用于处理数据包,是一种无连接的协议。在OSI模型中,在传输层,处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点,也就是说,当报文发送之后,是无法得知其是否安全完整到达的。
特点:
1)面向无连接
首先 UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的,想发数据就可以开始发送了。并且也只是数据报文的搬运工,不会对数据报文进行任何拆分和拼接操作。
具体来说就是:
- 在发送端,应用层将数据传递给传输层的 UDP 协议,UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议,然后就传递给网络层了
- 在接收端,网络层将数据传递给传输层,UDP 只去除 IP 报文头就传递给应用层,不会任何拼接操作
2)有单播,多播,广播的功能
UDP 不止支持一对一的传输方式,同样支持一对多,多对多,多对一的方式,也就是说 UDP 提供了单播,多播,广播的功能。
3)面向报文
发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。因此,应用程序必须选择合适大小的报文
4)不可靠性
首先不可靠性体现在无连接上,通信都不需要建立连接,想发就发,这样的情况肯定不可靠。
并且收到什么数据就传递什么数据,并且也不会备份数据,发送数据也不会关心对方是否已经正确接收到数据了。
再者网络环境时好时坏,但是 UDP 因为没有拥塞控制,一直会以恒定的速度发送数据。即使网络条件不好,也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包,但是优点也很明显,在某些实时性要求高的场景(比如电话会议)就需要使用 UDP 而不是 TCP。
5)头部开销小,传输数据报文时是很高效的。
UDP 头部包含了以下几个数据:
- 两个十六位的端口号,分别为源端口(可选字段)和目标端口
- 整个数据报文的长度
- 整个数据报文的检验和(IPv4 可选字段),该字段用于发现头部信息和数据中的错误
因此 UDP 的头部开销小,只有8字节,相比 TCP 的至少20字节要少得多,在传输数据报文时是很高效的。
TCP,传输控制协议
TCP(Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议
特点:
1) 面向连接:面向连接,是指发送数据之前必须在两端建立连接。建立连接的方法是“三次握手”,这样能建立可靠的连接。建立连接,是为数据的可靠传输打下了基础。
2)仅支持单播传输:每条TCP传输连接只能有两个端点,只能进行点对点的数据传输,不支持多播和广播传输方式。
3)面向字节流:TCP不像UDP一样那样一个个报文独立地传输,而是在不保留报文边界的情况下以字节流方式进行传输。
4)可靠传输:对于可靠传输,判断丢包、误码靠的是TCP的段编号以及确认号。TCP为了保证报文传输的可靠,就给每个包一个序号,同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK);如果发送端实体在合理的往返时延(RTT)内未收到确认,那么对应的数据(假设丢失了)将会被重传。
5)提供拥塞控制:当网络出现拥塞的时候,TCP能够减小向网络注入数据的速率和数量,缓解拥塞。
6)提供全双工通信:TCP允许通信双方的应用程序在任何时候都能发送数据,因为TCP连接的两端都设有缓存,用来临时存放双向通信的数据。当然,TCP可以立即发送一个数据段,也可以缓存一段时间以便一次发送更多的数据段(最大的数据段大小取决于MSS)
TCP和UDP的区别
| UDP | TCP | |
|---|---|---|
| 是否连接 | 无连接 | 面向连接 |
| 是否可靠 | 不可靠传输,不使用流量控制和拥塞控制 | 可靠传输(数据顺序和正确性),使用流量控制和拥塞控制 |
| 连接对象个数 | 支持一对一,一对多,多对一和多对多交互通信 | 只能是一对一通信 |
| 传输方式 | 面向报文 | 面向字节流 |
| 首部开销 | 首部开销小,仅8字节 | 首部最小20字节,最大60字节 |
| 适用场景 | 适用于实时应用,例如IP电话、视频会议、直播 | 适用于要求可靠传输的应用,例如文件传输 |
TCP和UDP使用场景
- TCP应用场景: 效率要求相对低,但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作,相比之下效率没有UDP高。例如:文件传输(准确高要求高、但是速度可以相对慢)、接受邮件、远程登录。
- UDP应用场景: 效率要求相对高,对准确性要求相对低的场景。例如:QQ聊天、在线视频、网络语音电话、广播通信(广播、多播)。
TCP的三次握手和四次挥手
三次挥手
三次握手是指建立一个TCP连接时,需要客户端与服务器总共发送3个包
简单回答:
- 首先建立连接时,客户端向服务器发送一个
SYN连接请求报文段和一个随机序号,等待服务端确认 - 服务端接收到
SYN包后确认并同时向服务器端发送一个 SYN ACK报文段,确认连接请求,并且也向客户端发送一个随机序号 - 客户端接收服务器的
SYN和ACK包后,进入连接建立的状态,同时向服务器也发送一个 ACK 确认报文段,服务器端接收到确认后,也进入连接建立状态,此时双方的连接就建立起来了。
过程
-
第一次握手:
建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。 -
第二次握手:
服务器收到syn包并确认客户的SYN(ack=j+1),同时也发送一个自己的SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态; -
第三次握手:
客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。
为什么需要三次握手,两次不行吗
- 为了确认双方的接收能力和发送能力都正常
- 为了防止当已失效的连接请求报文段突然又传到服务端,造成双方的不一致,导致资源的浪费
三次握手过程中可以携带数据吗
- 第三次握手的时候,可以携带数据,但是第一二次握手不可以携带数据
四次挥手
简单回答::若客户端认为数据发送完成,则它需要向服务端发送连接释放请求。服务端收到连接释放请求后,会告诉应用层要释放 TCP 链接。然后会发送 ACK 包,并进入 CLOSE_WAIT 状态,此时表明客户端到服务端的连接已经释放,不再接收客户端发的数据了。但是因为 TCP 连接是双向的,所以服务端仍旧可以发送数据给客户端。服务端如果此时还有没发完的数据会继续发送,完毕后会向客户端发送连接释放请求,然后服务端便进入 LAST-ACK 状态。客户端收到释放请求后,向服务端发送确认应答,此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL(最大段生存期,指报文段在网络中生存的时间,超时会被抛弃) 时间,若该时间段内没有服务端的重发请求的话,就进入 CLOSED 状态。当服务端收到确认应答后,也便进入 CLOSED 状态。
过程:
- 第一次挥手:Clien发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。
- 第二次挥手:Server收到FIN后,发送一个ACK给Client,Server进入CLOSE_WAIT状态。
- 第三次挥手: Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。
- 第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,发送ACK给Server,Server进入CLOSED状态,完成四次握手。
TCP粘包
多个数据包被连续存储于连续的缓存中,在对数据包进行读取时由于无法确定发生方的发送边界,而采用某一估测值大小来进行数据读出,若双方的size不一致时就会使指发送方发送的若干包数据到接收方接收时粘成一包,从接收缓冲区看,后一包数据的头紧接着前一包数据的尾。
CDN
对 CDN 的理解
CDN(Content Delivery Network)就是内容分发网络。
为了突破现实生活中的光速、传输距离等物理限制,CDN 投入了大量资金,在全球范围内各大枢纽城市建立机房,部署大量高存储高带宽的节点,构建跨运营商、跨地域的专用高速传输网络。
其中分为中心节点、区域节点、边缘节点等,在用户接入网络后,首先通过全局负载均衡 (Global Sever Load Balance),简称 GSLB 算法负责调度,找到离用户最合适的节点。然后通过 HTTP 缓存代理技术进行缓存,缓存命中就返回给用户,否则就回源站去取。CDN 擅长缓存静态资源(图片、音频等),当然也支持动态内容的缓存。
WebSocket
对 WebSocket 的理解
WebSocket 是一种基于 TCP 的轻量级网络通信协议。和 HTTP/2 一样,都是为了解决 HTTP 某些方面的缺陷而诞生的。不过解决方式略有不同,HTTP/2 针对的是“队头阻塞 ”,WebSocket 针对的是“请求-应答”的通信模式。
我们知道“请求-应答”是半双工的通信模式,不具备服务器推送能力。这就限制了 HTTP 在实时通信领域的发展。虽然可以使用轮询来不停的向服务器发送 HTTP 请求,但是缺点也很大,反复的无效请求占用了大量的带宽和 CPU 资源。所以,WebSocket 应运而生。
WebSocket 是一个全双工通信协议,具备服务端主动推送的能力。本质上是对 TCP 做了一层包装,让它可以运行在浏览器环境里。
浏览器原理
一、浏览器渲染
从输入网址到浏览器完成渲染的过程
简单版回答:
- 浏览器地址栏输入 URL 并回车
- 浏览器查找当前 URL 是否存在缓存,并比较缓存是否过期
- DNS 解析 URL 对应的 IP
- 根据 IP 建立 TCP 连接(三次握手)
- 发送 http 请求
- 服务器处理请求,浏览器接受 HTTP 响应
- 浏览器解析并渲染页面
- 关闭 TCP 连接(四次握手)
渲染页面过程:
- 解析HTML,生成DOM树,解析CSS,生成CSSOM规则树
- 将DOM树和CSSOM树结合,生成渲染树(Render Tree)
- Layout(回流):根据生成的渲染树,进行回流(Layout),得到节点的几何信息(位置,大小)
- Painting(重绘):根据渲染树以及回流得到的几何信息,得到节点的绝对像素
- Display:将像素发送给GPU,展示在页面上。
DNS,域名系统
概念: DNS(Domain Name System)提供的是一种主机名到 IP 地址的转换服务,就是常说的域名系统。它是一个由分层的 DNS 服务器组成的分布式数据库,是定义了主机如何查询这个分布式数据库的方式的应用层协议。能够使人更方便的访问互联网,而不用去记住能够被机器直接读取的IP数串。
作用: 将域名解析为IP地址,客户端向DNS服务器(DNS服务器有自己的IP地址)发送域名查询请求,DNS服务器告知客户机Web服务器的 IP 地址。
二、浏览器缓存
缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。当 web 缓存发现请求的资源已经被存储,它会拦截请求,返回该资源的拷贝,而不会去源服务器重新下载。
缓存好处:
- 减少了服务器的负担,提高了网站的性能
- 加快了客户端网页的加载速度
- 减少冗余的数据传输,节省网络带宽;
分类:缓存在宏观上可以分成两类:
- 私有缓存: 只能用于单独用户,最常见的就是浏览器缓存
- 共享缓存: 够被多个用户使用的缓存,也就是那些能被各级代理的缓存。
浏览器的缓存策略:浏览器对于缓存的处理是根据第一次请求资源时返回的响应头来确定的。
根据响应头,浏览器缓存策略分为:强缓存、协商缓存 和 启发式缓存。
强缓存
概念:不会向服务器发送请求,直接从缓存中读取资源,在chrome控制台的Network选项中可以看到该请求返回200的状态码,并且Size显示from disk cache或from memory cache。
简单理解:给浏览器缓存设置过期时间,超过这个时间之后缓存就是过期,浏览器需要重新请求。
主要是通过http请求头中的 Cache-Control 和 Expires 两个字段控制。
协商缓存
概念:强制缓存失效后,浏览器携带缓存标识向服务器发起请求,由服务器根据缓存标识决定是否使用缓存的过程
协商缓存解决了无法及时获取更新资源的问题。它利用下面会讲到的两组字段,对资源做标识.然后由服务器做分析,如果资源未更新,则返回304状态码。那么浏览器则会从缓存中读取资源,否则重新请求资源。
协商缓存是利用的是 Last-Modified,If-Modified-Since 和ETag、If-None-Match 这两对Header来管理的。
缓存过程
相关资料:深入理解浏览器的缓存机制
浏览器的本地缓存
浏览器的本地存储主要分为Cookie、WebStorage和IndexDB, 其中WebStorage又可以分为localStorage和sessionStorage。它们都是保存在浏览器中,且是同源的。
cookie、localStorage 和 sessionStorage的区别
生命周期:
- cookie:只在设置的cookie过期时间之前有效,可设置失效时间,没有设置的话,默认是关闭浏览器后失效
- localStorage:除非被手动清除,否则将会永久保存。
- sessionStorage: 仅在当前网页会话下有效,关闭页面或浏览器后就会被清除。
存放数据大小:
- cookie:4KB左右
- localStorage 和 sessionStorage:可以保存5MB的信息
http请求:
- cookie:每次都会携带在HTTP头中,如果使用cookie保存过多数据会带来性能问题
- localStorage 和 sessionStorage:仅在客户端(即浏览器)中保存,不参与和服务器的通信
易用性:
- cookie:需要程序员自己封装,源生的Cookie接口不友好
- localStorage和sessionStorage:源生接口可以接受,亦可再次封装来对 Object 和 Array 有更好的支持
应用场景:
从安全性来说,因为每次http请求都会携带cookie信息,这样无形中浪费了带宽,所以cookie应该尽可能少的使用,另外cookie还需要指定作用域,不可以跨域调用,限制比较多。但是用来识别用户登录来说,cookie还是比storage更好用的。其他情况下,可以使用storage,就用storage。
localStorage和sessionStorage唯一的差别一个是永久保存在浏览器里面,一个是关闭网页就清除了信息。localStorage可以用来夸页面传递参数,sessionStorage用来保存一些临时的数据,防止用户刷新页面之后丢失了一些参数。
POST的content-type几种方式
POST 方法中对发送数据编码的方式,也就是 Content-Type 有四种方式,其中默认是 application/x-www-form-urlencoded,最方便的是 application/json 。
四种方式包括:
application/x-www-form-urlencoded (URL encoded) multipart/form-data (键值对型数据) application/json (Json 类型数据) text/xml (xml) 传统的ajax请求时候,Content-Type默认为"文本"类型。
传统的form提交的时候,Content-Type默认为"Form"类型。
axios传递字符串的时候,Content-Type默认为"Form"类型。
axios传递对象的时候,Content-Type默认为"JSON"类型 ———————————————— 版权声明:本文为CSDN博主「有两把刷子」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:blog.csdn.net/qq_54753561…
三、浏览器安全
常用的攻击手段:SQL注入、XSS攻击、CSRF攻击
SQL 注入
SQL 注入漏洞(SQL Injection)是 Web 开发中最常见的一种安全漏洞
原理:主要是利用前端表单提交,比如输入框、富文本框,输入sql语句提交到后端,当后端服务通过提交的字段拼接成sql语句进行数据库查询的时候,恶意sql被执行,从而达到攻击的目的。
防御措施:
- 转义过滤用户的输入的某些
sql关键字,如select、from、and、or等。 - 使用
ORM框架如MyBatis,减少sql的手动拼接。
XSS 攻击
概念:指的是跨站脚本攻击,是一种代码注入攻击。
本质:网站没有对恶意代码进行过滤,与正常代码混合在一起执行了。
攻击者可以进行的操作:
- 获取页面的数据,如DOM、cookie、localStorage;
- DOS攻击,发送合理请求,占用服务器资源,从而使用户无法访问服务器;
- 破坏页面结构;
- 流量劫持(将链接指向某网站);
攻击类型:存储型、反射型和 DOM 型
如何防御:
- 从浏览器的执行来进行预防
- 使用 CSP(内容安全策略)
CSP 本质是建立一个白名单,告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则,如何拦截由浏览器自己来实现。有两种方式来开启 CSP,一种是设置 HTTP 首部中的 Content-Security-Policy,一种是设置 meta 标签的方式
CSRF 攻击,跨站请求伪造攻击
概念:CSRF(Cross-site request forgery)指的是跨站请求伪造攻击,攻击者诱导用户进入一个第三方网站,然后该网站向被攻击网站发送跨站请求。
本质:利用 cookie 会在同源请求中携带发送给服务器的特点,以此来实现用户的冒充。
攻击类型:GET 类型的 CSRF 攻击、POST 类型的 CSRF 攻击、链接类型的 CSRF 攻击
危害:
- 利用虚假输入表单骗取用户 如何防御:
- 进行同源检测
- 使用 CSRF Token 进行验证
浏览器事件机制
事件:是用户操作网页时发生的交互动作(click/move)或者网页本身的一些操作(文档加载,窗口滚动和大小调整),
三种事件模型:DOM0 级事件模型、IE 事件模型、DOM2 级事件模型
如何阻止事件冒泡:
- 普通浏览器使用:event.stopPropagation()
- IE浏览器使用:event.cancelBubble = true;
事件委托(事件代理)
概念:把子节点的监听函数定义在父节点上,由父节点的监听函数统一处理多个子元素的事件
事件委托本质上是利用了浏览器事件冒泡的机制。
特点:减少内存消耗、动态绑定事件
局限性:
- focus、blur 之类的事件没有事件冒泡机制,所以无法实现事件委托;
- mousemove、mouseout 这样的事件,虽然有事件冒泡,但是只能不断通过位置去计算定位,对性能消耗高,因此也是不适合于事件委托的。
缺点:事件委托会影响页面性能,主要影响因素有:
- 元素中,绑定事件委托的次数;
- 点击的最底层元素,到绑定事件元素之间的
DOM层数;
优化处理:
- 只在必须的地方,使用事件委托
- 尽量减少绑定的层级,不在
body元素上,进行绑定 - 减少绑定的次数,如果可以,那么把多个事件的绑定,合并到一次事件委托中去,由这个事件委托的回调,来进行分发。