秋招面试准备网络

最新推荐文章于 2023-06-28 13:14:46 发布

104g惊蛰

最新推荐文章于 2023-06-28 13:14:46 发布

阅读量507

点赞数

原文链接：https://blog.csdn.net/qq_38289815/article/details/80969419

版权

HTTP与计算机网络

1 HTTPS与HTTP区别及实现方式（此题参考HTTP 和 HTTPS 的区别（面试常考题）_Tyler_Zx的博客-CSDN博客_http和https的区别，感谢博主分享！）

2 三次握手四次挥手机制及原因参考面试官，不要再问我三次握手和四次挥手 - 知乎 (zhihu.com)，感谢分享

3TCP和UDP的区别

4HTTP请求的方式，HEAD方式

5说一下wed Quality（无障碍）

6 HTTP状态码参考一文牢记HTTP状态码（图解HTTP状态码） - 云+社区 - 腾讯云 (tencent.com)

7 fetch发送2次请求的原因参考fetch发送2次请求的原因__牛客网 (nowcoder.com)

8 Cookie、sessionStorage、localStorage的区别参考Cookie、sessionStorage、localStorage的区别 (itheima.com)

9 Cookie如何防范XSS攻击

10Cookie和session的区别Cookie和Session是什么？它们的区别是什么？_qichangjian的博客-CSDN博客_cookie和session

17 301和302的区别状态码301和302的区别 - Wayne-Zhu - 博客园 (cnblogs.com)

18 状态码304和200

19 在地址栏里输入一个URL，到这个页面吧呈现出来，中间会发生什么？在地址栏里输入一个URL，到这个页面呈现出来，中间会发生什么？_小葵坤_易安的博客-CSDN博客

HTTP与计算机网络

1 HTTPS与HTTP区别及实现方式（此题参考HTTP 和 HTTPS 的区别（面试常考题）_Tyler_Zx的博客-CSDN博客_http和https的区别，感谢博主分享！）

一、HTTP和HTTPS的基本概念

HTTP：超文本传输协议是互联网上应用最为广泛的一种网络协议。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。它可以使浏览器更加高效。HTTP协议是以明文方式发送信息的，如果黑客截取了Web浏览器和服务器之间的传输报文，就可以直接获得其中的信息。

HTTP原理：①客户端的浏览器首先要通过网络与服务器建立连接，该连接是通过TCP来完成的，一般TCP连接的端口号是80，建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URI）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和许可内容。

②服务器接到请求后，给予响应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。

HTTPS：是以安全为目标的HTTP通道，是HTTP的安全版本。HTTPS的安全基础是SSL。SSL协议位于TPC/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层：SSL记录协议（SSL Record Protocol），它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。SSL握手协议（SSL Handshake Protocol），它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

HTTPS设计目标：（1）数据保密性：保证数据内容在传输的过程中不会被第三方查看。就像快递员传递包裹一样，都进行了封装，别人无法获知里面装了什么。

（2）数据完整性：及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途掉包，数据完整性就是指如果被掉包，我们能轻松发现并拒收。

（3）身份校验安全性：保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方，通过身份校验来确保送对了地方。

二、HTTP与HTTPS的区别

1、HTTPS协议需要到CA（Certificate Authority，证书颁发机构）申请证书，一般免费证书比较少，因而需要一定的费用。

2、HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的SSL加密传输协议。

3、HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443.

4、HTTP的连接很简单，是无状态的。HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。（无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是通信双方都不长久的维持对方的任何信息）。

三、HTTPS相对于HTTP的改进

双向的身份认证

客户端和服务端在传输数据之前，会通过基于x509证书对双方进行身份认证。具体流程如下：

客户端发起SSL握手信息给服务端要求连接。

服务端将证书发送给客户端。

客户端检查服务端证书，确认是否由自己信任的证书签发机构签发（客户端内置了所有所信任CA的证书）。如果不是，将是否继续通讯的决定权给用户选择（注意，这里将是一个安全缺陷）。如果检查无误或用户选择继续，则客户端认可服务端的身份。

服务器要求客户端发送证书，并检查是否通过验证。失败则关闭连接，认证成功则从客户端证书中获得客户端的公钥，一般为1024位或者2048位。到此，服务器客户端双方的身份认证结束，双方确保身份都是真实可靠的。

注意

（1）采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过才能继续访问。这套证书其实就是一堆公钥和私钥。

（2）互联网有太多的服务器需要使用证书来验证身份，以至于客户端（操作系统或浏览器等）无法内置所有证书，需要通过服务端将证书发送给客户端。

（3）客户端内置的是CA的根证书，HTTPS协议服务器会发送证书链给客户端。

数据传输的机密性

客户端和服务端在开始传输数据之前，会协商传输过程需要使用的加密算法。客户端发送协商请求给服务端，其中包含自己支持的非对称假币的密钥交换算法（一般是RSA），数据签名要摘要算法（一般是SHA或者MD5），加密传输数据的对称加密算法（一般是DES），以及加密密钥的长度。服务端接收到消息之后，选中安全性最高的算法，并将选中的算法发送给客户端，完成协商。客户端生成随机的字符串，通过协商好的非对称加密算法，使用服务端的公钥对该字符串进行加密，发送给服务端，服务端接受到之后，使用自己的私钥解密得到该字符串。在随后的数据传输当中，使用这个字符串作为密钥进行对称加密。

防止重放攻击

SSL使用序列号来保护通讯方免收报文重放攻击。这个这个序列号被加密后作为数据包的负载。在整个 SSL 握手中，都有一个唯一的随机数来标记 SSL 握手。这样防止了攻击者嗅探整个登录过程，获取到加密的登录数据之后，不对数据进行解密，而直接重传登录数据包的攻击手法。

可以看到，鉴于电子商务等安全上的需求，HTTPS 对比 HTTP 协议，在安全方面已经取得了极大的增强。总结来说，HTTPS 的改进点在于创造性的使用了非对称加密算法，在不安全的网路上，安全的传输了用来进行非对称加密的密钥，综合利用了非对称加密的安全性和对称加密的快速性。

四、HTTPS的优点

1、使用HTTPS协议可以认证用户和服务器，确保数据发送到正确的客户机和服务器。

2、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比HTTP协议安全，可防止数据在传输过程中不被窃听、修改、确保数据的完整性。

3、HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

五、HTTPS的缺点（对比优点）

1、HTTPS协议握手阶段比较费时，会使页面的加载时间延长。

2、HTTPS连接缓存不如HTTP高效，会增加数据开销，甚至已有的安全措施也会因此而受到影响。

3、HTTPS协议的安全是有范围的，在黑客攻击、拒绝服务攻击和服务器劫持等方面几乎起不到什么作用。

4、SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

5、成本增加。部署HTTPS之后，因为HTTPS协议的工作增加额外的计算资源消耗，例如SSL协议加密算法和SSL交互次数将占用一定的计算资源和服务器成本。

6、HTTPS协议的加密范围也比较有限。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

六、HTTPS连接过程

这里写图片描述

1、https请求

客户端向服务端发送https请求、

2、生成公钥和私钥

服务端收到请求之后，生成公钥和私钥，公钥相当于是锁，私钥相当于是钥匙，只有私钥才能够打开公钥锁住的内容；

3返回公钥

服务端将公钥（证书）返回给客户端，公钥里面包含很多信息，比如比如证书的颁发机构、过期时间等等；

4客户端验证公钥

客户端收到公钥之后，首先会验证其是否有效，如颁发机构或者过期日期等，如果发现有问题就会抛出异常，提示证书存在问题，如果没有问题，那么就生成一个随机值，作为客户端的密钥，然后用服务器端的公钥加密；

5发送客户端密钥

客户端用服务端的公钥加密密钥，然后发送给服务端。

6服务端收取密钥，对称加密内容

服务端收到经过加密的密钥，然后用私钥将其解密，得到客户端的密钥，然后服务端把要传输的内容和客户端的密钥进行对称加密，这样除非知道密钥，某则无法知道传输的内容

7加密传输

服务端将经过加密的内容传输给客户端。

8获取加密内容、解密

客户端获取加密内容后，用之前生成的密钥对其进行解密，获取到内容。

2 三次握手四次挥手机制及原因参考面试官，不要再问我三次握手和四次挥手 - 知乎 (zhihu.com)，感谢分享

1、三次握手

三次握手（Three-way Handshake）其实就是建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口、建立TCP连接，并同步连接双方的序列号和确认好，交换TCP窗口大小信息。

刚开始客户端处于Closed的状态，服务器端处于Listen状态。

进行三次握手：

第一次握手：客户端给服务端发一个SYN报文，并指明客户端的初始化序列号ISN©。此时客户端处于SYN_SEND状态。

首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

第二次握手：服务器收到客户端的SYN报文后，会以自己的SYN报文作为应答，并且也是指定了自己的初始化序列号ISN(s)。同时会把客户端的ISN+1作为ACK的值，表示自己已经收到了客户端的SYN，此时服务器处于SYN_REVD状态。

在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

第三次握手：客户端收到SYN报文之后，会发送一个ACK报文，当然也是一样把服务器的ISN+1作为ACK的值，表示已经收到了服务端的SYN报文，此时客户端处于ESTABLISHED状态。服务器收到ACK报文之后，也处于ESTABLISHED状态，此时，双方已经建立起了连接。

确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。

发送第一个SYN的异端将执行主动打开（active open），接收这个SYN并发回下一个SYN的另一端执行被动打开（passive open）

在soket编程中，客户端执行connect()时，将触发三次握手。

1.1为什么需要三次握手，两次不行吗？

弄清这个问题。我们需要先弄明白三次握手的目的是什么，能不能只用两次握手来达到同样的目的。

第一次握手：客户端发送网络包，服务端收到了。

这样服务端就能得到结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。

这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不确认客户端的接收能力是否正常。

第三次握手：客户端发包，服务端收到了

这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

因此，需要三次握手才能确认双方的接收与发送能力是否正常。

试想如果用两次握手，则会出现下面这种情况：

如果客户端发出连接请求，但因连接请求报文丢失而为收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到了服务端，但是第一个丢失的报文段只是在某些网络节点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出了一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一直等待客户端发送数据，浪费资源。

1.2 什么是半连接队列？

服务器第一次收到客户端的SYN之后，就会处于SYN_RCVD状态，此时双方还没有完全简历起连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中，如果队列满了就有可能出现丢包现象。

这里补充一点关于SYN_ACK重传次数的问题：

服务器发送完SYN_ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户端确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。

注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为1s，2s，4s，8s....

1.3 ISN(intitial Sequence Number)是固定的吗？

当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1.这样选择序号的目的在于防止在网络延迟的分组在以后又被传送，而导致某个连接的一方对它做出错误的解释。

三次握手的其中一个重要功能是客户端和服务端交换ISN，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果ISN是固定的，攻击者很容易猜出后续的确认号，因此ISN是动态生成的。

1.4 三次握手过程中可以携带数据吗？

其实第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手不可以携带数据

为什么这样呢？大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的SYN报文中放入大量的数据，因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发SYN报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于ESTABLISHED 状态。对于客户端来说，他已经建立连接了，并且也已经知道服务器的接收发送能力是正常的，所以能携带数据也没啥毛病。

1.5 SYN攻击是什么？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成第三次握手时分配的，所以服务器更容易受到SYN洪泛攻击。SYN攻击就是让Client在短时间内伪造大量不存在的IP地址，并向Server不断发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN攻击是一种经典的DOS/DDos攻击。

检测SYN攻击非常方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上就可以断定这是一次SYN攻击。

常见的防御SYN攻击的方法有如下几种：

缩短超时时间

增加最大半连接数

过滤网关防护

SYN cookies技术

2.四次挥手

建立一个连接需要三次握手，而终止一个连接要经过四次挥手（也有将四次挥手叫做四次握手的）。这由TCP的半关闭造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。

TCP的连接的拆除需要发送四个包，因此称为四次挥手，客户端或服务端均可主动发起挥手动作。

刚开始双方都处在ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：

第一次挥手：客户端发送一个FIN报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。

即发出连接释放报文段（FIN=1，序列号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（关闭等待）状态，等待服务端的确认。

第二次挥手：服务端收到FIN之后，会发送ACK报文，且把客户端的序列号值+1作为ACK报文的序列号值，表明已经收到客户端的报文了，此时服务端处于CLOSE_WAIT状态。

即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2(终止等待2)状态，等待服务器发出的连接释放报文段。

第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发送FIN报文，且指定一个序列号，此时服务端处于LAST_ACK的状态。

即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认)状态，等待客户端的确认。

第四次挥手：客户端收到FIN之后，一样发送一个ACK报文作为应答，且把服务端的序列号值+1作为自己ACK报文的序列号值，此时客户端处于TIME_WAIT状态。需要过一阵子以确保服务端收到自己的ACK报文之后才会进入CLOSED状态，服务端收到ACK报文之后，就处于关闭连接了，处于CLOSED状态。

即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的2MSL后，客户端才进入CLOSED状态。

收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。

在socket编程中，任何一方执行close()操作即可产生挥手操作。

2.1 挥手为什么需要四次？

因为当服务器收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端：“你发的FIN报文我收到了”。只有等到我服务器所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送，故需要四次挥手。

2.2 2MSL等待状态

TIME_WAIT状态也称为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL，它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL文段。

对一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可以让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时并重发最后的FIN）

这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用，这个连接只能在2MSL结束后才能再被使用。

2.3 四次挥手释放连接时，等待2MSL的意义？

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文奖杯丢弃。

为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一旦这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

两个理由：

保证客户端发送的最后一个ACK报文段能够到达服务端

这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，服务端超时重传FIN+ACK报文段，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，若客户端再TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到服务端重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则服务器无法正常进入到CLOSED状态。

防止"已失效的连接请求报文段“出现在本连接中。

客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

2.4 为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态？

理论上，四个报文都发送完毕，就可以直接进入CLOSE状态了，但是可能网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

3TCP和UDP的区别

1 TCP是面向连接的，UDP是无连接的即发送数据前不需要先建立连接

2 TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达，UDP尽最大努力交付，即不保证可靠交付。并且因为TCP可靠，面向连接，不会丢失数据因此适合大数据量的交换

3 TCP是面向字节流的，UDP面向报文，并且网络出现拥塞不会使得发送速率降低（因此会出现丢包，对实时的应用比如IP电话和视频会议等）

4 TCP只能是1对1的，UDP支持1对1,1对多

5 TCP的首部较大为20字节，而UDP只有8字节

6 TCP是面向连接的可靠性传输，而UDP是不可靠的。

4HTTP请求的方式，HEAD方式

head：类似于get请求，只不过返回的响应中没有具体的内容，用户获取报头

options：允许客户端查看服务器的性能，比如说服务器支持的请求方式等。

5说一下wed Quality（无障碍）

能够被残障人士使用的网站才能称得上一个易用的（易访问的）网站

使用alt属性：

有时候浏览器会无法显示图像，具体的原因有：

用户关闭了图像显示

浏览器是不支持图像显示的迷你浏览器

浏览器是语言浏览器（供盲人和弱视人群使用）

如果使用了alt属性，那么浏览器至少可以显示或读出有关图像的描述。

6 HTTP状态码参考一文牢记HTTP状态码（图解HTTP状态码） - 云+社区 - 腾讯云 (tencent.com)

	类别
1XX	Informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

200 OK 请求成功，一般用于GET和POST请求

302 Found 临时重定向。该状态码表示请求的资源已经被分配给了新的URI，希望用户本次能使用新的URI访问。例如我访问一个微博的秒拍视频连接：http://t.cn/RuUMBnl，然后重定向到了实际的视频地址miaopai.com,状态码为302

400 Bad Request 该状态码表示请求报文中存在语法错误，当错误发生时，需修改请求的内从后再次发送请求。另外，浏览器会像200 OK一样对待该状态码

401 Unauthorized 该状态码表示发送请求需要有通过HTTP认证（BASIC认证、DIGEST认证）的认证信息。另外若之前已进行过1次请求，则表示用户认证失败。返回含有401的响应必须包含一个适用于被请求资源的WWW-Authenticate首部用于质询（challenge）用户信息。当浏览器初次接收到401响应，会弹出认证用的对话窗口。

403 Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求

500 internal Server Error 服务器内部错误，无法完成请求

502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器收到了一个无效的响应

7 fetch发送2次请求的原因参考fetch发送2次请求的原因__牛客网 (nowcoder.com)

面对这个问题，需要先理解三个点：

1 状态码204,：当服务器返回这个状态码时，就表示服务器已经成功收到请求，但是没有数据。对应到浏览器，不会刷新界面，也不会导向新界面。当我们只关注于请求是否发送成功，而无所谓返回数据时，就可以借助204状态码，省掉了多余的数据传输，从而节省开销。

2 option请求，属于请求中的复杂请求，该类请求有一个特点，在正式发送请求之前，都会先发送一个请求，进行一个预检查，简称：预检请求。

3 预检请求：可以向服务器请求权限信息，也可以获取目的资源所支持的通信选项（例如：检查HTTP请求方法），还可以用来检查服务器性能，

当时用fetch发送POST请求时，会先发送一个OPTION请求进行预检，用来获知服务端是否允许该跨域请求，服务器确认允许之后会返回204状态码，表示运气该跨域请求，这时才发起实际的HTTP请求。在预检请求的返回中，服务端也可以通知客户端，是否需要携带身份凭证（包括Cookies 和HTTP认证相关数据）

8 Cookie、sessionStorage、localStorage的区别参考Cookie、sessionStorage、localStorage的区别 (itheima.com)

共同点：都是保存在浏览器端

区别：

1）cookie数据始终在同源的http请求中携带（即使不需要），即cookie在浏览器和服务器间来回传递；存储大小限制也不同，cookie数据不能超过4k，同时因每次http请求都会携带cookie，所以cookie只适合保存很小的数据，如会话标识。而sessionStorage和localStorage不会自动把数据发送给服务器，仅在本地保存，sessionStorage和localStorage虽然也有存储大小的限制，但比cookie大得多，可以达到5M或更大。

2）数据有效期不同，sessionStorage：仅在当前浏览器窗口关闭前有效，自然也就不可能持久保持；localStorage：始终有效，窗口或浏览器关闭也一直保存，因此用作持久数据；cookie只在设置的cookie过期时间之前一直有效，即使窗口或浏览器关闭。

3）作用域不同，sessionStorage不在不同的浏览器窗口中共享，即使是同一个页面；localStorage在所有同源窗口中都是共享的；cookie也是在所有同源窗口中都是共享的。

9 Cookie如何防范XSS攻击

XSS（跨站脚本攻击）是指攻击者在返回的HTML中嵌入JavaScript脚本，为了减轻这些攻击，需要在HTTP头部配上，set-cookie：

httponly这个属性可以防止XSS，它会禁止JavaScript脚本来访问cookie

secure-这个属性告诉浏览器仅在请求为https的时候发送cookie。

10Cookie和session的区别Cookie和Session是什么？它们的区别是什么？_qichangjian的博客-CSDN博客_cookie和session

HTTP是一个无状态协议，就是说这一次请求和上一次请求时没有任何关系的，互不认识的，没有关联的，这种无状态的好处是快速。由于http的无状态性，为了使某个域名下的所有网页能够共享某些数据，session和cookie出现了。

什么是cookie？

cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个cookie，客户端会把cookie保存起来。

当浏览器再请求网站时，浏览器把请求的网址连同cookie一同提交给服务器。服务器检查该cookie，以此来辨认用户状态。服务器还可以根据需要修改cookie的内容。

信息保存的时间可以根据需要设置

如果没有设置cookie失效日期，它们仅保存到关闭浏览器程序位置

如果将cookie对象的expires属性设置为Minvalue，则表示cookie永远不会过期

cookie存储的数据量很受限制，大多数浏览器支持最大容量为4k，因此不要用来保存数据集及其他大量数据

由于并非所有的浏览器都支持cookie，并且数据信息是以明文文本的形式保存在客户端的计算机中，因此最好不要保存敏感的，未加密的数据，否则会影响网站的安全性。

什么是session？

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

每个用户访问服务器都会简历一个session，那服务器是怎么标识用户的唯一身份呢？事实上，用户与服务器建立连接的同时，服务器会自动为其分配一个sessionID

session和cookie的区别？

1、数据存储位置，cookie数据存放在客户的浏览器上，session数据存放在服务器上。

2、安全性：cookie不是很安全，别人可以分析存放在笨的的cookie并进行cookie欺骗，考虑到安全应该使用session

3、服务器性能，session会在一定时间内保存在服务器上。当访问增多，会比较占用服务器的性能，考虑到减轻服务器性能方面，应当使用cookie

4、数据大小：单个cookie保存的数据不能超过4k，很多浏览器都限制一个站点最多保存20个cookie

5、信息重要程度：可以考虑将登陆信息等重要信息存放为session，其他信息如果需要保存，就可以放在cookie中。

11一句话概括RESTFUL

就是用URL定位资源，用HTTP描述操作

12 viewport和移动端布局

13 http常用请求头

协议头	说明
Accept	可接受的响应内容类型（Content-Types）。
Accept-Charset	可接受的字符集
Accept-Encoding	可接受的响应内容的编码方式。
Accept-Language	可接受的响应内容语言列表。
Accept-Datetime	可接受的按照时间来表示的响应内容版本
Authorization	用于表示HTTP协议中需要认证资源的认证信息
Cache-Control	用来指定当前的请求/回复中的，是否使用缓存机制。
Connection	客户端（浏览器）想要优先使用的连接类型
Cookie	由之前服务器通过Set-Cookie（见下文）设置的一个HTTP协议Cookie
Content-Length	以8进制表示的请求体的长度
Content-MD5	请求体的内容的二进制 MD5 散列值（数字签名），以 Base64 编码的结果
Content-Type	请求体的MIME类型（用于POST和PUT请求中）
Date	发送该消息的日期和时间（以RFC 7231中定义的"HTTP日期"格式来发送）
Expect	表示客户端要求服务器做出特定的行为
From	发起此请求的用户的邮件地址
Host	表示服务器的域名以及服务器所监听的端口号。如果所请求的端口是对应的服务的标准端口（80），则端口号可以省略。
If-Match	仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对应的操作。主要用于像 PUT 这样的方法中，仅当从用户上次更新某个资源后，该资源未被修改的情况下，才更新该资源。
If-Modified-Since	允许在对应的资源未被修改的情况下返回304未修改
If-None-Match	允许在对应的内容未被修改的情况下返回304未修改（ 304 Not Modified ），参考超文本传输协议的实体标记
If-Range	如果该实体未被修改过，则向返回所缺少的那一个或多个部分。否则，返回整个新的实体
If-Unmodified-Since	仅当该实体自某个特定时间以来未被修改的情况下，才发送回应。
Max-Forwards	限制该消息可被代理及网关转发的次数。
Origin	发起一个针对跨域资源共享的请求（该请求要求服务器在响应中加入一个Access-Control-Allow-Origin的消息头，表示访问控制所允许的来源）。
Pragma	与具体的实现相关，这些字段可能在请求/回应链中的任何时候产生。
Proxy-Authorization	用于向代理进行认证的认证信息。
Range	表示请求某个实体的一部分，字节偏移以0开始。
Referer	表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接将浏览器带到了当前页面。Referer其实是Referrer这个单词，但RFC制作标准时给拼错了，后来也就将错就错使用Referer了。
TE	浏览器预期接受的传输时的编码方式：可使用回应协议头Transfer-Encoding中的值（还可以使用"trailers"表示数据传输时的分块方式）用来表示浏览器希望在最后一个大小为0的块之后还接收到一些额外的字段。
User-Agent	浏览器的身份标识字符串
Upgrade	要求服务器升级到一个高版本协议。
Via	告诉服务器，这个请求是由哪些代理发出的。
Warning	一个一般性的警告，表示在实体内容体中可能存在错误。

14强、协商缓存

浏览器缓存

浏览器缓存是浏览器将用户请求过的静态资源（html、css、js），存储到电脑本地磁盘中，当浏览器再次访问时，就可以直接从本地加载了，不需要再去服务端请求了。

但也不是说缓存没有缺点，如果处理不当，可能会导致服务端代码更新了，但是用户却还是老页面。所以前端们要针对项目中各个资源的实际情况，做出合理的缓存策略。

缓存的优点：

减少了冗余的数据传输，节省网费

减少服务器的负担，提升网站性能

加快了客户端加载网页的速度

2缓存流程

我们可以认为，浏览器里有一个专门存放缓存规则的一个数据库，也可以说是一个映射表，把缓存资源信息，同电脑磁盘中的实际文件的地址，对应起来。

浏览器第一次请求资源时

上面所说的缓存规则，就是声明所请求的资源，要采取哪种缓存策略，缓存多长时间等等，而这个规则，是在http的header中返回来的

注意，是response header，而不是request header

3 缓存规则

强缓存和协商缓存

强缓存

简单粗暴，如果资源没过期，就取缓存，如果过期了，则请求服务器

如何判断资源是否过期呢，也就是说强缓存的规则怎么看

主要是看response headers中的cache-control的值，图中的max-age=31xxxxxx，就是说在这些秒内，都直接使用缓存，超过了就继续请求服务器

而和cache-control并列的，还有一个expires，已经基本淘汰了，所以不用管

cache-control的几个取值含义：

private：仅浏览器可以缓存

public：浏览器和代理服务器都可以缓存（对于private和public，前端可以认为一样，不用深究）

max-age=xxx 过期时间（重要）

no-cache不进行强缓存（重要）

no-store 不强缓存，也不协商缓存，基本不用，缓存越多才越好

注意：规则可以同时多个

所以，对于强缓存，我们主要研究cache-control中的max-age和no-cache

所以，判断该资源是否命中强缓存，就看response中的cache-control的值，如果max-age=xxx秒，则命中强缓存。如果cache-control的值是no-cache，说明没命中强缓存，走协商缓存。

强缓存流程：

所以强缓存步骤已经很清晰了：

1第一次请求a.js,缓存表中没改信息，直接请求后端服务器

2后端服务器返回了a.js,且http response header中cache-control为max-age=xxx，所以是强缓存规则，存入缓存表中

3 第二次请求a.js，缓存表中是max-age，那么命中强缓存，然后判断是否过期，如果没过期，直接读缓存的a.js,如果过期了，则执行协商缓存的步骤了。

注意

这里有个问题，就是max-age=0，和no-cache有啥区别，我理解的是，no-cache直接不进行强缓存，让你去走协商缓存，而max-age=0是进行强缓存，但是过期了，需要更新，，，实际上看起来两者效果是一样的

协商缓存

触发条件：

1.cache-control的值为no-cache（不强缓存）

2 或者max-age过期了（强缓存，但总有过期的时候）

也就是说，不管怎样，都可能最后要进行协商缓存（no-store除外）

这个图，虽然强缓存命中，但是也有ETag和Last-Modified，这两个就是协商缓存的相关规则。虽然之前的强缓存流程和他俩没关。

ETag：每个文件有一个，改动文件了就变了，可以看似md5

Last-Modified：文件的修改时间

也就是说，每次http返回来response header中的ETag和Last-Modified，在下次请求时在request header 就把这两个带上（但是名字改变了ETag-->If-None-Match,Last-Modified-->if-Modifed-Since)，服务端把你带来的标识，资源目前的标识，进行对比，然后判断资源是否更改了。

这个过程是循环往复的，即缓存表在每次请求成功后都会更新规则

1第n次请求成功时：

2缓存表中更新该资源的ETag值

3第n+1次请求

从缓存表中取该资源最新的ETag，然后加在request header中，注意变名字了，由ETag-->If-None-Match

图

所以协商缓存步骤总结：

1.请求资源时，把用户本地资源的ETag同时带到服务端，服务端和最新资源做对比

2如果资源未改动，返回304，浏览器读取本地缓存

3如果资源有改动，返回200，返回最新资源

4.缓存命中显示

1从服务器获取新的资源

2命中强缓存，且资源没过期，直接读取本地缓存

3命中协商缓存，且资源未改动，读取本地缓存

注意：协商缓存无论结果，都要向服务器发请求的，只不过，资源未更改时，返回的只是header信息，所以size很小；而资源有改动时，还要返回body数据，所以size会大。

补充

浏览器第一次请求时：

浏览器在后续再进行请求时

如果没有命中强缓存，浏览器会发送请求到服务器，请求会携带第一次请求返回的有关缓存的header字段信息（Last-Modified/If-Modified-Since和Etag/If-None-Match），由服务器根据请求中的相关header信息来比对结果是否协商缓存命中，若命中，则服务器返回新的响应header信息更新缓存中的对应header信息，但是不返回资源内容，它会告知浏览器可以直接从缓存获取，否则返回最新的资源内容

强缓存与协商缓存的区别：

15 讲讲304

客户端在请求一个文件的时候，发现自己缓存的文件有Last Modified（截止时间），那么在请求中会包含if Modified Since，这个时间就是缓存文件的Last Modified。因此，如果请求中包含if Modified Since，就说明已经有缓存在客户端。服务器只要判断这个时间和当前请求的文件的修改时间就可以确实是返回304还是200，返回304，则代表浏览器可以继续使用缓存数据。如此，可以减少传输的数据量，同时，服务器也不需要进一步执行相关数据的查询。

16GET和POST的区别

1 HTTP接口传递数据最常用的方式：

GET方式是从服务器获取数据，在做数据查询时，建议用GET方式；如：商品信息接口、搜索接口、博客访客接口等。

POST方式是向服务器传送数据；在做数据添加、修改或删除时，建议使用POST方式；如：微博图片上传图片接口、登录注册接口等。

POST和GET的区别：

1）GET请求只是简单的获取数据，不修改请求的资源；而POST请求会修改请求的资源。导致的后果是相同的GET请求能获取相同的资源，而相同的POST请求不能保证相同的资源。

2）GET请求的参数在HTTP中是通过URL传递的，POST请求的数据是通过requestbody体传递的

3）GET请求资源在服务器上能够缓存，而POST就不能够了

4）GET请求的参数的数据长度是有限制的，而POST请求的数据长度没有限制

5）GET请求无法传递二进制数据到服务器，而POST可以

1get用来从服务器上获得数据，而POST是用来向服务器上传递数据

2get将表单中的数据按照variable=value的形式，添加到action所指向的URL后面，并且两者使用“?”连接，而各个变量之间使用“&”连接；Post是将表单中的数据放在form的数据体中，按照变量和值相对应的方式，传递到action所指向URL。

3、Get是不安全的，因为在传输过程，数据被放在请求的URL中，而如今现有的很多服务器、代理服务器或者用户代理都会将请求URL记录到日志文件中，然后放在某个地方，这样就可能会有一些隐私的信息被第三方看到。另外，用户也可以在浏览器上直接看到提交的数据，一些系统内部消息将会一同显示在用户面前。Post的所有操作对用户来说都是不可见的。

4、Get传输的数据量小，这主要是因为受URL长度限制；而Post可以传输大量的数据，所以在上传文件只能使用Post（当然还有一个原因，将在后面的提到）。

5、Get限制Form表单的数据集的值必须为ASCII字符；而Post支持整个ISO10646字符集。

6、Get是Form的默认方法。

总结：

一、get参数通过URL传递，post放在request body中

二、get请求在URL中传递的参数是有长度限制的，而post没有

三、get比post更不安全，因为参数直接暴露在URL中，所以不能用来传递敏感信息

四、get请求只能进行URL编码，而post支持多种编码方式

五、get请求参数会被完整保留在浏览历史记录里，而POST中的参数不会被保留

get和post本质上就是tcp连接，并无差别，但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

get产生一个TCP数据包；POST产生两个TCP数据包

17 301和302的区别状态码301和302的区别 - Wayne-Zhu - 博客园 (cnblogs.com)

301 moved permanently 被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URL之一。如果可能，拥有连接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。

302Found请求的资源现在临时从不用的URL响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在cache-control或expires中进行了指定的情况下，这个响应才是可缓存的。

字面上的区别就是301是永久重定向，而302是临时重定向。当然，他们之间也是有共同点的，就是用户都可以看到URL替换为了一个新的，然后发出请求

301适合永久重定向

301比较常用的场景是使用域名跳转

比如，我们访问http://www.baidu.com会跳转到https://www.baidu.com，发送请求之后，就会返回301状态码，然后返回一个location，提示新的地址，浏览器就会拿着这个新的地址去访问

注意：301请求时可以缓存的，即通过看status code，可以发现后面写着from cache。

或者你把你的网页的名称从php修改为html，这个过程中，也会发生永久重定向

302用来做临时跳转

比如未登录的用户访问用户中心重定向到登录页面

访问404页面会重定向到首页。

rewrite后面接上permenent就代表301跳

//把来自veryyoung.me的请求301跳到 www.veryyoung.me
if ($host != 'veryyoung.me') {
    rewrite ^/(.*)$ http://www.veryyoung.me/$1 permanent;
}

接上redirect就代表302跳

//把来自veryyoung.me的请求302跳到 www.veryyoung.me
if ($host != 'veryyoung.me') {
    rewrite ^/(.*)$ http://www.veryyoung.me/$1 redirect;
}

301重定向和302重定向的区别

302重定向只是暂时的重定向，搜索引擎会抓取新的内容而保留旧的地址，因为服务器返回302，所以，搜索引擎认为新的网址是暂时的

而301重定向是永久的重定向，搜索引擎在抓取新的内容的同时也将旧的网址替换为了重定向之后的网址。

18 状态码304和200

状态码200：请求已成功，请求所希望的响应头或数据体将随此响应返回。即返回的数据为全量的数据，如果文件不通过GZIP压缩的话，文件是多大，则要有多大传输量。

状态码304：如果客户端发送了一个带条件的GET请求且该请求已被允许，而文档的内容（自上次访问以后或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。即客户端和服务端只需要传输很少的数据量来做文件的校验，如果文件没有修改过，则不需要返回全量的数据。

19 在地址栏里输入一个URL，到这个页面吧呈现出来，中间会发生什么？在地址栏里输入一个URL，到这个页面呈现出来，中间会发生什么？_小葵坤_易安的博客-CSDN博客

一、DNS域名解析

根据输入的URL域名找到真实IP地址，在查找的过程中，浏览器首先会寻找缓存，查看缓存中是否有记录，缓存的查找记录为：

1.浏览器缓存→操作系统缓存→路由器缓存；

2缓存中没有则查找系统的hosts文件中是否有记录

3如果没有则查询DNS服务器，首先从顶级域名（一般顶级域名已经在缓存中了），再到二级域名，以此类推。

二、建立TCP连接

根据IP地址，客户端与服务端进行三次握手，建立连接。

为了准确无误地把数据送到目标处，TCP采用了三次握手策略；用TCP把数据包发送出去后，TCP不会对传送后的数据置之不理，它一定会向对方确认是否成功送达。

1 发送端首先给接收端发送一个带SYN标志的数据包

2 接收端收到后，回传一个带有SYN/ACK标志的数据包以表示正确传达，并确认信息。

3 最后，发送端再回传一个带ACK标志的数据包，代表“握手”结束。

注：

握手过程中使用了TCP的标志，即SYN和ACK

若在握手过程中的某个阶段莫名中断，TCP会再次以相同的顺序发送相同的数据包

三、传输数据

连接后，客户端向服务端发起HTTP请求，服务器接收到请求后，返回请求静态资源，并同时调用apache服务器请求接口数据。

注：得到服务器的IP地址后，浏览器根据这个IP以及相应的端口号，构造一个HTTP请求，这个请求报文会包括这次请求的信息，主要是请求方法，请求说明和请求附带的数据，并将这个HTTP请求封装在一个TCP包中，这个TCP包会依次经过传输层，网络层，数据链路层，物理层到达服务器

四、关闭TCP连接

数据传输完成，客户端与服务端进行四次挥手，关闭连接。

断开一个TCP连接则需要四次挥手

五、渲染页面

对于浏览器根据服务端返回的静态资源，浏览器使用Native GUI引擎渲染HTML和CSS；使用JS引擎加载JS。

1 将HTML节点解析成DOM树结构

在DOM树的构建过程中如果遇到JS脚本和外部JS连接，则会停止构建DOM数来执行和下载相应的代码，这会造成阻塞，这就是为什么推荐JS代码应该放在html代码的后面

从HTML字节码到DOM树结构的流程：字节（Bytes）==>字符串(Characters)==>tokens==>节点(Nodes)==>DOM

计算机智能识别0和1的字节，根据字节的编码规则将字节转换成字符串，再将字符串转化为W3C定义的各种标签，生成tokens(令牌），匹配字符串，将tokens按照规则转换为包含属性和规则的节点对象(nodes)，根据每个节点的层次关系（父子节点关系）和规则转换为直观的树形结构。HTML是增量构建的，在HTML文件还在传输时，这个转换过程就已经开始了。最终得到完整的DOM(Document Object Module文档对象模型)

2 将CSS解析成CSSOM规则树

这里主要做的是排除非视觉节点，比如scrip，meta标签和排除display为none的节点；有了Render Tree，浏览器已经能知道网页中有哪些节点、各个节点和CSS定义以及他们的从属关系

CSS构建的过程和DOM差不多，只不过CSS会涉及到复杂的计算，如CSS的属性来源，匹配不同的类（id或者class），确认复写规则及权重，最后确定每个节点的样式值，形成CSSOM(CSS Object Module CSS对象模型)。

3将DOM与CSSOM组合成Render-tree（渲染书）

4布局：计算出每个节点在屏幕中的位置

5绘制：即遍历render树，并使用UI后断层绘制每个节点

六、加载JavaScript脚本

虽然HTML\CSS与JS是通过不同的引擎加载，但是却是互斥的，即加载HTML\CSS时，js会停止加载，反之亦然，这是因为JS引擎可以操作DOM，改变样式、内容等。所以当执行了JS之后，渲染树要重新构建。

当然在这些所有的请求中我们还需要关注的就是缓存，缓存一般通过cache-control、Last-Modify、Expires等首部字段控制。Cache-Control和Expires的区别在于cache-control使用相对时间，Expires使用的是基于服务器端的绝对时间，因为存在时差问题，一般采用cache-control，在请求这些有设置了缓存的数据时，会先查看是否过期，如果没有过期则直接使用本地缓存，过期则请求并在服务器校验文件是否修改，如果上一次响应设置了ETag值会在这次请求的时候作为If-None-Match的值交给服务器校验，如果一致，继续校验Last-Modified，没有设置ETag则直接验证Last-Modified，再决定是否返回304

HTTP: 在浏览器输入 URL 回车之后发生了什么？（超详细版）_菜不是原罪-CSDN博客

20CSRF和XSS的网络攻击以及防范CSRF和XSS的网络攻击及防范_Gary Leong-CSDN博客

CSRF（cross-site request forgery）：跨域请求伪造：当用户访问A（信任网站）网站并登陆成功时，在用户处产生A的Cookie。这时用户访问了B（危险网站）网站，当B要求访问第三方站点（A)的时候，浏览器会带着用户最开始登陆A的时候产生的cookie访问A，而A网站并不能分辨请求时由用户发出的还是由B发出的，这时候B网站就能模拟用户操作，例如转账等操作

如何防范CSRF攻击

1使用token

可以再HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求

2检查http头部的refer

根据HTTP协议，在HTTP头中有一个字段叫refer，它记录了该HTTP请求的来源地址。例如我们要在网上银行执行转账，那么我们发出的请求的http中的refer通常是以bank.example域名开头的地址，即该银行的页面上的url，而黑客执行CSRF攻击的时候，http中的refer是黑客自己网站的url。如果refer是其他网站的话，则有可能是黑客的CSRF攻击，拒绝该请求。

3在HTTP头中自定义属性并验证

这种方法也是使用token并进行验证，和上一种方法不同的是，这里并不是把token以参数的形式置于HTTP请求之中，而是把它放到HTTP头中自定义的属性里

4使用验证码

在表单中增加一个随机的数字或字母验证码，通过强制用户和应用进行交互，来有效地遏制CSRF攻击。

XSS全程是Cross Site Scripting即跨站脚本，当目标网站目标用户浏览器渲染HTML文档的过程中，出现了不被预期的脚本指令并执行时，XSS就发生了。

如何防御XSS

1对用户的输入进行检查

不信任任何用户的输入，对每个用户的输入都做严格检查，过滤，在输出的时候，对某些特殊字符进行转义、替换等

2cookie设置为httpOnly属性

httponly这个属性可以防止xss，它会禁止JavaScript脚本来访问cookie

21怎么看网站的性能如何

检测页面加载时间一般有两种方式，一种是被动去测：就是在被检测的页面置入脚本或探针，当用户访问网页时，探针自动采集数据并传回数据库进行分析。另一种主动监测的方式，即主动的搭建分布式受控环境，模拟用户发起页面访问请求，主动采集性能数据并分析。

在检测的精准度上，专业的第三方工具效果更佳，比如性能极客

22介绍HTTP协议（特征）

HTTP协议的主要特点可概括如下：1支持客户/服务器模式。2简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度快。3灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。4无连接，无连接的含义是限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。5无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力，缺少状态意味着后续处理需要前面的信息，则它必须重传，这样可能导致每次连接发送的数据量增大，另一方面，在服务器不需要先前信息时它的应答就较快。