前端面试题之（网络原理篇）

花海海

已于 2023-09-06 13:21:46 修改

阅读量1.4k

点赞数 1

分类专栏：前端面试题文章标签： http https 安全 csrf xss

于 2021-06-26 18:59:39 首次发布

本文链接：https://blog.csdn.net/wqh_boss/article/details/117587144

版权

前端面试题专栏收录该内容

4 篇文章 1 订阅

订阅专栏

点进来的你是否也在为面试而发愁，是否还在取经的路上经历着九九八十一难。

同样在取经路上的我也是万分感慨啊🤧！ ~我懂你

这篇文章就是我遇到的一些关于 —— 网络原理——方面问题的汇总，希望可以助你一臂之力

HTTP与HTTPS区别

在介绍它们的区别之前先介绍一下它们的基本概念（以防万一）
HTTP（HyperText Transfer Protocol：超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。 简单来说就是一种发布和接收 HTML 页面的方法，被用于在 Web 浏览器和网站服务器之间传递信息。 默认工作在 TCP 协议 80 端口。

HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息

HTTPS（Hypertext Transfer Protocol Secure：超文本传输安全协议）是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。 默认工作在 TCP 协议443端口。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

它的工作流程一般如以下方式：
1、TCP 三次同步握手
2、客户端验证服务器数字证书
3、DH 算法协商对称加密算法的密钥、hash 算法的密钥
4、SSL 安全加密隧道协商完成
5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。

知道了这些，我们便可以谈谈他们之间的区别了······

HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP）数据传输过程是加密的，安全性较好。
使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构）申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。

觉得啰嗦的话总结起来就两句话：

HTTP：无状态，无连接，而且是明文传输，不安全；
HTTPS：对传输内容加密，身份验证，保证数据完整性。

下面👎这道面试题可以称之为”经典”了，千万别错过🤑

从输入URL到页面加载发生了什么总体来说分为以下几个过程:

总体来说分为一下几个过程：

1. DNS解析
DNS解析的过程就是寻找哪台机器上有你需要资源的过程。 先进行DNS域名解析，先查看本地hosts文件，查看有没有当前域名对应的ip地址，若有直接发起请求，没有的话会在本地域名服务器去查找，该查找属于递归查找，如果本地域名服务器没查找到，会从根域名服务器查找，该过程属于迭代查找，根域名会告诉你从哪个与服务器查找，最后查找到对应的ip地址后把对应规则保存到本地的hosts文件中。
这里顺便提一下DNS优化方案：
（1）DNS缓存（DNS存在着多级缓存，从离浏览器的距离排序的话，有以下几种: 浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存。）
（2）DNS负载均衡（DNS可以返回一个合适的机器的IP给用户，例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等，这种过程就是DNS负载均衡，又叫做DNS重定向。CDN(Content Delivery Network)就是利用DNS的重定向技术，DNS服务器会返回一个跟用户最接近的点的IP地址给用户，CDN节点的服务器负责响应用户的请求，提供所需的内容。）
2. TCP连接
进行http请求，三次握手四次挥手建立断开连接。
这里要提醒一点，Chrome 在同一个域名下要求同时最多只能有 6 个 TCP 连接，超过 6 个的话剩下的请求就得等待。

3. 发送HTTP请求
TCP连接建立完毕后，浏览器可以和服务器开始通信，发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议中发送到服务器指定端口(HTTP协议80/8080, HTTPS协议443)。
HTTP请求报文是由三部分组成:
请求行：

// 请求方法是GET，路径为根路径，HTTP协议版本为1.1
GET / HTTP/1.1

常用的方法有: GET, POST, PUT, DELETE, OPTIONS, HEAD。
请求头：请求报头允许客户端向服务器传递请求的附加信息和客户端自身的信息。
请求报头中常见的字段：

Accept用于指定客户端用于接受哪些类型的信息
Accept-Encoding与Accept类似，它用于指定接受的编码方式。
Connection设置为Keep-alive用于告诉客户端本次HTTP请求结束之后并不需要关闭TCP连接，这样可以使下次HTTP请求使用相同的TCP通道，节省TCP连接建立的时间。

请求体： 当使用POST, PUT等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求正文中。在请求头中有一些与请求正文相关的信息
4. 服务器处理请求并返回HTTP报文
HTTP 请求到达服务器，服务器进行对应的处理。最后要把数据传给浏览器，也就是返回网络响应。
HTTP响应报文也是由三部分组成:
状态码（下文有详细介绍）
响应头
响应头包含了服务器及其返回数据的一些信息, 服务器生成数据的时间、返回的数据类型以及对即将写入的Cookie信息。
常见的响应报头字段有: Server, Connection…。
响应体
服务器返回给浏览器的文本信息，通常HTML, CSS, JS, 图片等文件就放在这一部分。
5. 浏览器解析渲染页面
浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;**当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为repain。**页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。
6. 连接结束

注意啦👇👇👇
在这当中，面试官可能会问到你响应状态码这一回事，下面小编对此进行了简单整理，方便查找🚩🚩🚩

HTTP响应状态码

响应分为五类：信息响应(100–199)，成功响应(200–299)，重定向(300–399)，客户端错误(400–499)和服务器错误 (500–599)。

信息响应(100–199)——表示请求已被接受，但需要后续处理。例如：
- 100（Continue）客户端应继续发送请求。
- 101（Switching Protocols）需要切换协议，服务器通过的Upgrade响应头字段通知客户端。
成功响应(200–299)——表示请求已成功被服务器接收、理解、并接受。
- 200 请求已成功，请求所希望的响应头或数据体将随此响应返回。
- 201（Created）请求已经被实现，而且有一个新的资源已经依据请求的需要而创建。在RESTFul风格的URL设计中，通常用来响应POST请求。
- **202（Accepted）服务器已接受请求，但尚未处理。**比如POST一个资源应当返回201，但由于性能原因未能立即创建，可以返回202。
- 204（No Content）服务器成功处理了请求，但不需要返回任何实体内容，204响应禁止包含任何消息体。浏览器收到该响应后不应产生文档视图的变化。
- 205（Reset Content）服务器成功处理了请求，但不需要返回任何实体内容，205响应禁止包含任何消息体。与204不同的是，返回此状态码的响应要求请求者重置文档视图。比如用户刚刚提交一个表单，返回205后页面重置，用户可以立即填写下一个表单。
- 206（Partial Content）HTTP协议允许分片传输。请求头中包含Range字段时，响应需要只返回Range指定的那一段。响应中应包含Content-Range来指示返回内容的范围。
重定向(300–399)——这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，重定向目标在本次响应的Location头字段中指明。
- 301（Moved Permanently）被请求的资源已永久移动到新位置，也就是永久重定向。
  应用场景：域名更改，访问原始域名重定向到新的域名
- 302（Found）请求的资源现在临时从不同的URI响应请求。也就是临时重定向，
- 303（See Other）对应当前请求的响应可以在另一个URI上被找到，而且客户端应当采用GET的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。 303响应禁止被缓存。
  303会使得浏览器直接GET那个资源，不需用户同意。这是Web应用中最常见的重定向方式。
- 304（Not Modified）表示可以在缓存中取数据（协商缓存）
  304响应也是一种缓存机制。Web服务器对静态资源文件通常会采取缓存，因此在Web开发中你可以看到大量的304响应。服务器给出的相应中通常会包含Etag来标识资源ID
客户端错误(400–499)——这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个HEAD请求，否则服务器就应该返回一个解释当前错误状况的实体。
- 400（Bad Request）
  由于包含语法错误，当前请求无法被服务器理解。400通常在服务器端表单验证失败时返回。
- 401（Unauthorized）无权访问
  当前请求需要用户验证，响应中会包含一个WWW-Authenticate字段来询问用户的授权信息,输入验证信息并点击确定，浏览器会根据你的输入填写Authorization头并重新发送请求。
- 403（Forbidden）
  服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助。403和401一样，需要在相应消息体中需要给出原因。除非是一个HEAD请求。
- 404（Not Found）找不到资源
  这太常见了。就是请求所希望得到的资源未被在服务器上发现。当通常用于当服务器不想揭示到底为何请求被拒绝时，比如应当返回500时服务器不愿透露自己的错误。
- 405（Method Not Allowed）请求行中指定的请求方法不能被用于请求相应的资源。在Web开发中通常是因为客户端和服务器的方法不一致，比如客户端通过PUT来修改一个资源，而服务器把它实现为POST方法。开发中统一规范就好了。
- 413（Request Entity Too Large）上传的资源大小超过服务器限制的大小
  一般的服务器都会设置HTTP请求消息体的最大长度，当然这是一种阻挡攻击的手段。例如你在使用HTTP方式来访问Git仓库，如果你在仓库中加入了大的二进制文件（通常为目标文件或多媒体文件），在Push时服务器很可能会返回413错误。如果切换为ssh协议就不会有这样的问题了，服务器只能限制整个仓库的大小。
- 414（Request-URI Too Large）
  当URI太长时，服务器可以返回414. 当HTTP协议并未规定URI应当有多长。这取决于浏览器和服务器的设置，在服务器中当然你想设置多长都可以，但是浏览器是你决定不了的，而且不同的厂商在采用不同的长度限制，可以认为最短的是2K：
服务器错误 (500–599)
这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。并且响应消息体中应当给出理由，除非是HEAD请求。
- 500（Internal Server Error）服务器错误
  通常是代码出错，后台Bug。一般的Web服务器通常会给出抛出异常的调用堆栈。然而多数服务器即使在生产环境也会打出调用堆栈，这显然是不安全的。
- 502（Bad Gateway）
  作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
  如果你在用HTTP代理来翻墙，或者你配置了nginx来反向代理你的应用，你可能会常常看到它。
- 503 服务器超负荷
- 504（Gateway Time-out）
  作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器收到响应。
  注意与502的区别：502是接收到了无效响应比如Connection Refused； 504是响应超时，通常是被墙了。

注意啦👇👇👇
接着还可能会问到你一下一连串问题🌋

三次握手过程理解

第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

四次挥手过程理解

客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

理解之后就行了？
准备迎接面试官的“十万个为什么”吧😱

为什么要“三次握手，四次挥手”

三次握手
3次握手”的作用就是双方都能明确自己和对方的收、发能力是正常的。两次达不到让双方都得出自己、对方的接收、发送能力都正常的结论。其实每次收到网络包的一方至少是可以得到：对方的发送、我方的接收是正常的。而每一步都是有关联的，下一次的“响应”是由于第一次的“请求”触发，因此每次握手其实是可以得到额外的结论的。

在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。

四次挥手
TCP连接是双向传输的对等的模式，就是说双方都可以同时向对方发送或接收数据。当有一方要关闭连接时，会发送指令告知对方，我要关闭连接了。这时对方会回一个ACK，此时一个方向的连接关闭。但是另一个方向仍然可以继续传输数据，等到发送完了所有的数据后，会发送一个FIN段来关闭此方向上的连接。接收方发送ACK确认关闭连接。

为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方是否现在关闭发送数据通道，需要上层应用来决定，因此，己方ACK和FIN一般都会分开发送。

tcp 和udp有什么区别

对于这个问题可以从以下几个方面回答
1.连接方面

tcp面向连接，udp不需要连接
tcp需要三次握手四次挥手请求连接

2.可靠性

tcp是可靠传输；一旦传输过程中丢包的话会进行重传
udp是不可靠传输，但会最大努力交付

3.工作效率

UDP实时性高，比TCP工作效率高
因为不需要建立连接，更不需要复杂的握手挥手以及复杂的算法，也没有重传机制

4.是否支持多对多

TCP是点对点的
UDP支持一对一，一对多，多对多

5.首部大小

tcp首部占20字节
udp首部占8字节

到这里一般就差不多了，还有就是一些变态的问题了，小编也无法面对，被问到的时候时候就阿弥陀佛吧🙏🙏🙏
这里给大家找了一些其他相关的问题，充实一下大家神奇的脑回路🖖🖖🖖

OSI七层模型中，每一层的作用和对应的协议如下：

OSI中的层	功能	TCP/IP协议族
应用层	文件传输，电子邮件，文件服务，虚拟終端	TFTP、HTTP、SNMP、 FTP、SMTP、DNS、Telnet
表示层	数据格式化，代码转换，数据加密	无协议
会话层	解除或建立与别的接点的联系	无协议
传输层	提供端对端的接口	TCP、UDP
网络层	为数据包选择路由	IP、ICMP、 RIP、 OSPF、BGP、 IGMP
数据链路层	传输有地址的帧以及错误检测报告	SLIP， CSLIP， PPP，ARP，RARP， MTU
物理层	以二进制数据形式在物理媒体上传输数据	ISO2110, IEEE802， IEEE802.2

浏览器缓存作为性能优化的重要一环，对于前端而言，重要性不言而喻。面试也可能会问到,下面是小编用来九牛二虎之力对此进行的一些总结与归纳,还望对大家有用🤞

缓存机制

首先我们来总体感知一下它的匹配流程，如下：

浏览器发送请求前，根据请求头的expires和cache-control判断是否命中（包括是否过期）强缓存策略，如果命中，直接从缓存获取资源，并不会发送请求。
如果没有命中，则进入下一步。没有命中强缓存规则，浏览器会发送请求，根据请求头的last-modified和etag判断是否命中协商缓存，如果命中，直接从缓存获取资源。如果没有命中，则进入下一步。
如果前两步都没有命中，则直接从服务端获取资源。

什么是浏览器缓存？

浏览器缓存保存着用户通过 HTTP 获取的所有资源，再下一次请求时可以避免重复向服务器发出多余的请求。
通俗的说，就是在你访问过一次某个网站之后，这个站点的文字、图片等所有资源都被下载到本地了，下次再访问该网站时判断是否满足缓存条件，如果满足就不用再花费时间去等待资源的获取了。

浏览器缓存的分类？

一般来说浏览器缓存可以分为两类：

强缓存 —(不会向服务器发送请求，直接从缓存中读取资源)

浏览器在加载资源时，会先根据本地缓存资源的 header 中的信息判断是否命中强缓存，如果命中则直接使用缓存中的资源不会再向服务器发送请求。

协商缓存—(发求情到服务器判断浏览器本地缓冲是否失效，若可以使用服务器不会返回资源信息)

当强缓存没有命中的时候，浏览器会发送一个请求到服务器，服务器根据请求头中的部分信息来判断是否命中缓存。如果命中，则返回 304 ，告诉浏览器资源未更新，可使用本地的缓存。

我们需要知道的是，浏览器在加载资源时，会先判断是否命中强缓存再验证是命中协商缓存。

其它的的具体细节，慢慢展开来说。

强缓存一般是这样一个流程：

强缓存流程

查看 header 头中的 Expire 和 Cache-control 来判断是否满足规则；
如果满足规则，就返回缓存的数据；
如果不满足规则，就向服务器发送请求；
服务器返回数据；
将新数据存入缓存。

所以我们主要就是关注 Expire 和 Cache-control 这两个字段。

协商缓存一般是这样一个流程：

在这里插入图片描述

把资源标识，比如 If-Modify-Since 或 Etag 发送到服务器，确认资源是否更新；
如果资源未更新，请求响应返回的http状态为 304 并且会显示一个 Not Modified 的字符串，告诉浏览器使用本地缓存;
如果资源已经更新，返回新的数据；
将新数据存入缓存。

总结
当浏览器再次访问一个已经访问过的资源时，它会这样做：

看看是否命中强缓存，如果命中，就直接使用缓存了；
如果没有命中强缓存，就发请求到服务器检查是否命中协商缓存；
如果命中协商缓存，服务器会返回 304 告诉浏览器使用本地缓存；
否则，返回最新的资源。

HTTP keep-alive

HTTP keep-alive也称为 HTTP 长连接。它通过重用一个 TCP 连接来发送/接收多个 HTTP请求，来减少创建/关闭多个 TCP 连接的开销。

什么是 keep-alive?

keep-alive 是客户端和服务端的一个约定，如果开启 keep-alive，则服务端在返回 response 后不关闭 TCP 连接；同样的，在接收完响应报文后，客户端也不关闭连接，发送下一个 HTTP 请求时会重用该连接。

在 HTTP/1.0 协议中，如果请求头中包含

Connection: keep-alive

则代表开启 keep-alive，而服务端的返回报文头中，也会包含相同的内容。

在 HTTP/1.1 协议中，默认开启 keep-alive，除非显式地关闭它：

Connection: close

什么是CDN

CDN（Content Delivery Network，简称CDN）内容分发网络：是建立并覆盖在承载网之上，由分布在不同区域的边缘节点服务器群组成的分布式网络。
CDN应用广泛，支持多种行业、多种场景内容加速，例如：图片小文件、大文件下载、视音频点播、直播流媒体、全站加速、安全加速。

CDN技术消除了不同运营商之间互联的瓶颈造成的影响，实现了跨运营商的网络加速，保证不同网络中的用户都能得到良好的访问质量
广泛分布的CDN节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵以及降低各种DDoS攻击对网站的影响，同时保证较好的服务质量

CDN组成

一般来讲，CDN网络主要由中心节点、边缘节点两部分构成

中心节点----中心节点包括CDN网管中心和全局负载均衡DNS重定向解析系统，负责整个CDN网络的分发及管理。
边缘节点----CDN边缘节点主要指异地分发节点，由负载均衡设备、高速缓存服务器两部分组成。
回源是什么意思？
当 cdn 缓存服务器中没有符合客户端要求的资源的时候，缓存服务器会请求上一级缓存服务器，以此类推，直到获取到。最后如果还是没有，就会回到我们自己的服务器去获取资源。
那都有哪些时候会回源呢？没有资源，资源过期，访问的资源是不缓存资源等都会导致回源。

几种常见的网络攻击方式及防御技巧

1. XSS攻击

XSS(Cross-Site Scripting，跨站脚本攻击)是一种代码注入攻击。攻击者在目标网站上注入恶意代码，当被攻击者登陆网站时就会执行这些恶意代码，这些脚本可以读取 cookie，session tokens，或者其它敏感的网站信息，对用户进行钓鱼欺诈，甚至发起蠕虫攻击等。

XSS 的本质是：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。由于直接在用户的终端执行，恶意代码能够直接获取用户的信息，利用这些信息冒充用户向网站发起攻击者定义的请求。

XSS分类

根据攻击的来源，XSS攻击可以分为存储型(持久性)、反射型(非持久型) 和 DOM型三种。

防御方法

编码：对用户输入的数据进行HTML Entity 编码。把字符转换成转义字符。Encode的作用是将$var等一些字符进行转化，使得浏览器在最终输出结果上是一样的。
过滤：移除用户输入的和事件相关的属性。
输入内容限制,输入内容长度控制
Content Security Policy
在服务端使用 HTTP的 Content-Security-Policy 头部来指定策略，或者在前端设置 meta 标签。

2. CSRF

CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的

防御方法

添加验证码(体验不好)
验证码能够防御CSRF攻击，但是我们不可能每一次交互都需要验证码，否则用户的体验会非常差，但是我们可以在转账，交易等操作时，增加验证码，确保我们的账户安全。
使用Token(主流)，每次用户提交表单时需要带上token（伪造者访问不到），如果token不合法，则服务器拒绝请求
判断请求的来源：检测Referer(并不安全，Referer可以被更改)
Samesite Cookie属性
为了从源头上解决这个问题，Google起草了一份草案来改进HTTP协议，为Set-Cookie响应头新增Samesite属性，它用来标明这个 Cookie是个“同站 Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方Cookie，Samesite 有两个属性值，分别是 Strict 和 Lax。
部署简单，并能有效防御CSRF攻击，但是存在兼容性问题。

3. 点击劫持

点击劫持是指在一个Web页面中隐藏了一个透明的iframe，用外层假页面诱导用户点击，实际上是在隐藏的frame上触发了点击事件进行一些用户不知情的操作。
点击劫持防御

frame busting
需要注意的是: HTML5中iframe的 sandbox 属性、IE中iframe的security 属性等，都可以限制iframe页面中的JavaScript脚本执行，从而可以使得 frame busting 失效。
X-Frame-Options
可以设置为以下值：
DENY: 拒绝任何域加载
SAMEORIGIN: 允许同源域下加载
ALLOW-FROM: 可以定义允许frame加载的页面地址