计算机基础前端面试专用

墨蓝 2022-09-04 11:48 362阅读 0赞

## 跨域 ##

*  **跨域怎么解决?**  
    a页面想获取b页面资源，如果a、b页面的协议、域名、端口、子域名不同，所进行的访问行动都是跨域的。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDE5NDI5OQ_size_16_color_FFFFFF_t_70]  
    **form表单提交没有跨域问题**  
    a页面有form表单，b页面的路径是提交地址。  
    a页面submit后，浏览器刷新页面，页面显示b页面的内容。  
    form表单是将数据提交给了b页面。a页面并没有读取b页面中的内容。  
    因此：  
    1、form表单不会出现跨域问题，因为页面进行了跳转，并且form表单页没有读取其他页面信息  
    2、ajax请求造成跨域是因为 要读取接口地址的信息 并且在不同源的情况下

**解决方法：**

1.  **nginx反向代理**  
    对nginx进行配置，监听某个端口，然后设置location进行对应url的请求转发，去请求对应的服务器。
2.  **JSONP**  
    网页通过添加一个script元素，向服务器请求 JSON 数据，服务器收到请求后，将数据放在一个指定名字的回调函数的参数位置传回来。
3.  **CORS**  
    1、普通跨域请求：只需服务器端设置Access-Control-Allow-Origin  
    2、带cookie跨域请求：前后端都需要进行设置  
    【前端设置】根据xhr.withCredentials字段判断是否带有cookie  
    前端：xhr.withCredentials = true;  
    后端：

// 允许跨域访问的域名：若有端口需写全（协议+域名+端口），若没有端口末尾不用加'/'
    response.setHeader("Access-Control-Allow-Origin", "http://www.domain1.com"); 
     
    // 允许前端带认证cookie：启用此项后，上面的域名不能为'*'，必须指定具体的域名，否则浏览器会提示
    response.setHeader("Access-Control-Allow-Credentials", "true");

**CORS中的简单请求和复杂请求**

CORS可以分成两种：

1、简单请求  
2、复杂请求

**简单请求**

1 .请求方法是以下三种方法之一：

*  HEAD
 *  GET
 *  POST

2.HTTP的头信息不超出以下几种字段:

*  Accept
 *  Accept-Language
 *  Content-Language
 *  Last-Event-ID
 *  Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

**复杂请求**  
复杂请求在正式请求前都会有预检请求，在浏览器中都能看到有OPTIONS请求，用于向服务器请求权限信息的。

axios 都是复杂请求，ajax 可以是简单请求。

复杂请求表面上看起来和简单请求使用上差不多，但实际上浏览器发送了不止一个请求。其中最先发送的是一种"预请求"，此时作为服务端，也需要返回"预回应"作为响应。预请求实际上是对服务端的一种权限请求，只有当预请求成功返回，实际请求才开始执行。

**客户端：预请求以OPTIONS**形式发送，当中同样包含域，并且还包含了两项CORS特有的内容

**Access-Control-Request-Method** – 该项内容是实际请求的种类，可以是GET、POST之类的简单请求，也可以是PUT、DELETE等等。  
**Access-Control-Request-Headers** – 该项是一个以逗号分隔的列表，当中是复杂请求所使用的头部。  
显而易见，这个预请求实际上就是在为之后的实际请求发送一个权限请求，在预回应返回的内容当中，服务端应当对这两项进行回复，以让浏览器确定请求是否能够成功完成。

**服务端：**  
复杂请求的部分响应头及解释如下：  
Access-Control-Allow-Origin（必含） – 和简单请求一样的，必须包含一个域。

Access-Control-Allow-Methods（必含） – 这是对预请求当中Access-Control-Request-Method的回复，这一回复将是一个以逗号分隔的列表。尽管客户端或许只请求某一方法，但服务端仍然可以返回所有允许的方法，以便客户端将其缓存。

Access-Control-Allow-Headers（当预请求中包含Access-Control-Request-Headers时必须包含） – 这是对预请求当中Access-Control-Request-Headers的回复，和上面一样是以逗号分隔的列表，可以返回所有支持的头部。这里在实际使用中有遇到，所有支持的头部一时可能不能完全写出来，而又不想在这一层做过多的判断，没关系，事实上通过request的header可以直接取到Access-Control-Request-Headers，直接把对应的value设置到Access-Control-Allow-Headers即可。

Access-Control-Allow-Credentials（可选） – 和简单请求当中作用相同

Access-Control-Max-Age（可选） – 以秒为单位的缓存时间。预请求的的发送并非免费午餐，允许时应当尽可能缓存。

**为什么需要预检请求？**  
preflight的引入是为了解决什么问题呢？

简单请求就是**普通 HTML Form** 也可以发出的请求，比如表单的 method 如果指定为 POST ，可以用 **enctype** 属性指定用什么方式对表单内容进行编码，合法的值就是你题目里提到的这三种。

非简单请求就是普通 HTML Form 无法实现的请求。比如 PUT 方法、需要其他的内容编码方式、自定义头之类的。

CORS-preflight 就是这样一种机制，浏览器先单独请求一次，询问服务器某个资源是否可以跨源，如果不允许的话就不发实际的请求。注意先许可再请求等于默认禁止了跨源请求。如果允许的话，浏览器会记住，然后发实际请求，且之后每次就都直接请求而不用再询问服务器否可以跨源了。于是，服务器想支持跨源，就只要针对 preflight 进行跨源许可计算。本身真正的响应代码则完全不管这个事情。并且因为 preflight 是许可式的，也就是说如果服务器不打算接受跨源，什么事情都不用做。

但是这机制只能限于非简单请求。在处理简单请求的时候，如果服务器不打算接受跨源请求，不能依赖 CORS-preflight 机制。因为不通过 CORS，普通表单也能发起简单请求，所以默认禁止跨源是做不到的。

既然如此，简单请求发 preflight 就没有意义了，就算发了服务器也省不了后续每次的计算，反而在一开始多了一次 preflight。

## 计算机网络部分 ##

\*\*

*  **状态码**  
    1XX:信息型状态码 接受的请求正在处理  
    2XX:成功状态码 请求正常处理完毕  
    3XX:重定向状态码 需要进行附加操作来完成请求  
    4XX:客户端错误状态码 服务器无法处理请求  
    5XX:服务器错误状态码 服务器请求出错  
    其中需要了解的状态码：  
    206：成功返回**部分**资源  
    301：永久性重定向。会在头部字段返回新的URI，获取新的内容替换掉旧的网址。  
    302：临时性重定向。不会去替换旧的网址，比如判断用户是否登录来跳转。  
    304：协商缓存的返回状态码，资源没有更新，可以使用缓存。  
    404：无法找到请求的资源。  
    403：对资源的访问被服务器拒绝了。  
    500：服务器执行时出现故障。  
    503：服务器不可用，可能超负载或者正在维护。
 *  **协议栈**  
    有OSI的**七层协议，五层协议**，还有**TCP/IP的四层协议**。  
    其中TCP/IP四层协议分别是应用层，传输层，网络层，数据链路层；五层协议在TCP/IP的基础上最下面多了个物理层；而OSI的七层协议在五层协议的基础上，在应用层下面多了表示层和会话层。因为OSI的协议太复杂，太过理想化，更偏向理论，因此使用的比较少，而TCP/IP使用更多。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDE5NDI5OQ_size_16_color_FFFFFF_t_70_pic_center]
 *  **IP地址和MAC地址**  
    **IP地址：是网络层及以上各层使用的地址，是一种逻辑地址，一个主机可以有多个IP地址。  
    MAC地址：是数据链路层和物理层的地址，是物理地址。一个主机只有一个物理地址。  
    在使用IP地址的IP数据报一旦交给数据链路层，就封装成MAC帧了，MAC帧在传输时使用的源地址和目的地址都是MAC地址。  
    使用ARP协议**可以将IP地址映射成MAC地址，使用**DNS**可以将域名映射成IP地址。
 *  **TCP和UDP的区别**  
    UDP：无连接的，尽最大努力交付的，是面向报文的（传输层加上首部后直接乡向下传输，不会合并或者拆分），没有拥塞控制，支持一对一、一对多、多对多，首部开销小。  
    TCP：面向连接的，提供可靠的交付，提供全双工，面向字节流，会拆分报文，并且标记序号。
 *  **流量控制**  
    **滑动窗口协议。**  
    发送方有一个发送窗口，接收方有一个接收窗口，发送方发送字节后，接受方会进行确认，并且把接收窗口的大小发送给发送方，发送方可以根据接收方的窗口大小来进行调整，可以和接收窗口一样大或者更小。
 *  **三次握手**  
    why？因为如果之前有建立连接的请求发送但是没有按时到达，已经变得过期不可用了，如果后期到达，并且目的主机确认后（这里只有两次握手），就建立连接，但是并没有传输的东西，会浪费网络资源。
 *  **四次挥手**  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16]  
    **为什么需要四次？**  
    因为在建立连接时，服务端返回的ACK（确认）和SYN（同步）可以一起发送，但是在挥手中服务端FIN后，客户端可能还有数据要传输，因此ACK和FIN不能一起发送，因此需要四次。

**为什么客户端收到服务端的FIN还要等待两个MSL?**  
MSL：报文段最大生存时间。

因为在客户端发送ACK后，可能需要1MSL才能到达服务器端，如果没有到达，超时后服务器端会超时重传FIN，重传的报文又需要1MSL才能到达哦客户端，因此一共需要2MSL。如果在2MSL中客户端没有收到服务端的报文，就可以关闭连接。

这样也可以保证本链接中的数据包不会再出现在下一次的连接中，在2MSL中本次的数据包都会过期。

## HTTP协议部分 ##

HTTP协议用于客户端和服务器之间的通信。  
HTTP协议是**无连接的**，虽然使用了TCP链接，但是通信双方在交换HTTP报文之前不需要先建立HTTP链接。  
HTTP协议是**无状态的**，简化了服务器的设计，是服务器支持大量并发的HTTP请求。  
在1997年之前使用的是HTTP/1.0，现在普遍使用HTTP/1.1。

*  **HTTP版本区别**  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDE5NDI5OQ_size_16_color_FFFFFF_t_70_pic_center 1]  
    **HTTP/0.9** 仅支持GET请求，不支持请求头  
    **HTTP/1.0** 默认短连接（一次请求建议一次TCP连接，请求完就断开），支持GET、POST、 HEAD请求。缺点：每次请求一个文档就需要2\*RTT(往返时间)的开销，如图所示，并且每次建立新的连接都要重新分配缓存和变量。  
    **HTTP/1.1**  
    HTTP 1.1引入了许多关键性能优化：keepalive连接，chunked编码传输，字节范围请求，请求流水线等。

1.  **keepalive连接**：默认长连接（一次TCP连接可以多次请求），即使用的是持续连接，在HTTP1.0中使用长连接需要添加请求头 Connection: Keep-Alive，而在HTTP 1.1 所有的连接默认都是长连接。在发送响应后仍然在一段时间内保持这条链接，同一个用户和服务器可以继续用这条链接传输，这样建立连接后每次传输只需要一个RTT时间
2.  支持PUT、DELETE、PATCH等六种请求，增加host头，支持虚拟主机，支持断点续传功能。
3.  **字节范围请求**：HTTP1.1支持传送内容的一部分。比方说，当客户端已经有内容的一部分，为了节省带宽，可以只向服务器请求一部分。该功能通过在请求消息中引入了**range**头域来实现，它允许只请求资源的某个部分。在响应消息中**Content-Range**头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码**206（Partial Content）**
4.  **缓存处理**：HTTP/1.1在1.0的基础上加入了一些cache的新特性，引入了实体标签，一般被称为e-tags，新增更为强大的Cache-Control头。

**HTTP/2.0**  
1. **多路复用**，降低开销（一次TCP连接可以处理多个请求），在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一一对应，避免了队头堵塞的问题,此双向的实时通信称为多工；这张图片就可以描述多路复用的情况,**同一域名下所有访问都是从同一个tcp连接中走**,ssl的数据包是并发的,原来http1.1的机制是client发出请求后必须等到服务器响应后才能发出第二个请求.现在所有请求都是同时发送的不需要等待.  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA5YiYU3VybWFu_size_37_color_FFFFFF_t_70_g_se_x_16]  
因为**二进制数据帧和流**，每个帧都有编号，不用等待，所以才能支持多路复用。![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA5YiYU3VybWFu_size_43_color_FFFFFF_t_70_g_se_x_16]

1.  **服务器主动推送**（相关资源一个请求全部推送），服务器可以对一个客户端请求发送多个响应。当客户端请求某个页面时，服务器可以主动将页面内引入的图片、js、css主动推送至客户端，节约请求时间以及流量。
2.  **二进制分帧**。头部信息和数据体都是二进制，解析基于二进制，解析错误少，更高效（HTTP/1.X解析基于文本）；
3.  **头部压缩**。报头压缩，降低开销，头信息使用gzip或compress压缩后再发送。在普通HTTP请求中分为三部分，\[请求头、消息主体、状态行\]，其中消息主体可以通过gzip压缩，而请求头跟状态行没办法进行压缩，随着web功能越来越复杂，一个页面的请求也越来越多，而头信息中有着大量的数据不会频繁变动，但是又要随每次请求发送，导致大量流量浪费，所以HTTP2.0引入了头部压缩技术。

**HTTP3:**  
使用UDP协议。上面增加了QUIC实现来进行流量控制、差错处理等工作。

# 关于HTTP2的头部压缩 #

一般而言，消息主体都会经过**gzip压缩**，但是状态行和头部多是没有经过任何压缩，而是直接以纯文本的方式进行传输的。因此，http2提出了对请求和响应的头部进行压缩，即不再只是压缩主题部分，这种压缩方式就是**HAPCK** 。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 1]  
**Hpack算法的过程：**

1.  消息发送端和消息接受端共同维护一份**静态表**和一份**动态表**（这两个合起来充当字典的角色），
2.  每次请求时，发送方根据字典的内容以及一些特定指定，**编码压缩**消息头部，
3.  接收方根据字典进行**解码**，并且根据指令来判断**是否需要更新动态表**  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 2]

**静态表**  
静态表很简单，**只包含已知的header字段**。分为两种：

1.  name和value都可以完全确定，比如:metho: GET、:status: 200
2.  只能够确定name：比如:authority、cookie

第一种情况很好理解，已知键值对直接使用**一个字符**表示；  
第二种情况稍微说明下：首先将**name部分先用一个字符**（比如cookie）来表示，同时，根据情况判断是否告知服务端，将 cookie: xxxxxxx 添加到动态表中（我们这里默认假定是从客户端向服务端发送消息）

**动态表**

1.  动态表最初是一个**空表**，当每次解压头部的时候，有可能会**添加条目**（比如前面提到的cookie，当解压过一次cookie时，cookie: xxxxxxx就有可能被添加到动态表了，至于是否添加要根据后面提到的**指令判断**）
2.  动态表允许包含重复的条目，也就是可能出现完全相同的键值对
3.  为了限制解码器的需求，动态表大小有严格限制的

有了这个索引空间以后，header的字段一共有以下几种表示方法：

1.  直接用索引值来表示（比如2表示method：get）
2.  字段的name使用索引值表示，字段的value直接使用原有字面的值的**八位字节序列**或者使用**静态哈夫曼编码**表示

其中八位字节指令的最高位也就是标志位，可以进行判断当前指令是否是静态表中的炫目以及需要更新动态表。

*  **报文结构**  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDE5NDI5OQ_size_16_color_FFFFFF_t_70 1]
 *  **GET,POST的区别**  
    GET是获取资源  
    POST传输数据，获取处理后的资源，是用来传输实体主体的。
 *  **首部行的一些常用字段**
    
    1.  ***通用首部字段***（请求报文和响应报文双方都会使用的首部）  
        Cache-Control：操作缓存的工作机制，有max-age等  
        Connection：控制不在转发给代理的首部字段，管理持久化连接（close,keep-alive）  
        Date：创建HTTP报文的日期和时间
    2.  ***请求首部字段***  
        Accept：想要的资源格式  
        Authorization：告诉服务器用户代理的认证信息  
        Host：请求的资源所处的互联网主机名和端口号  
        If-Match：当If-Match的字段值跟ETag匹配一致时，服务器才会接受请求。  
        If-Modified-Since：如果服务器在指定的时间之后更新过资源，则会接受请求  
        If-None-Match：和If-Match相反，当字段值与ETag不一致的时候，才会接受请求  
        User-Agent：浏览器的相关信息
    3.  ***响应首部字段***  
        Age：源服务器在多久前创建了响应  
        ETag：能告知客户端实体标识，它是一种将资源以字符串形式做唯一性标识的方法  
        Location：提示客户端去访问另一个地址  
        Retry-After：客户端应该子啊多久之后再次发送请求  
        Server：告诉客户端当前服务器上安装的HTTP服务器的信息
    4.  ***实体首部字段***  
        Allow：获取资源支持的HTTP方法  
        Content-Encoding  
        Content-Language  
        Content-Length  
        Expires：会将资源失效的日期告知客户端，会优先处理max-age  
        Last-Modified：资源最终修改的时间
    5.  ***为Cookie服务的首部字段***  
        Set-Cookie：  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDE5NDI5OQ_size_16_color_FFFFFF_t_70 2]  
        Cookie

## 操作系统部分 ##

*  **进程和线程**  
    **进程**
    
    1.  一个具有独立功能的可并发执行的程序，在一个数据集合上运行的过程
    2.  *进程 = 程序 + 数据 + PCB（进程控制块）*
    3.  进程实体是一个能独立运行的基本单位，可独立获得资源和独立调度
    4.  进程的三个状态：运行状态、就绪状态、阻塞状态。
    5.  进程的大致生命周期：从后备队列中选出进程，分配内存和PCB，成为进程，处于就绪状态；CPU空闲时被调度，成为运行状态；当进程有I/O请求时，会阻塞被挂起，成为阻塞状态；进程运行完毕后。成为完成状态，让出内存和CPU。  
        **线程**  
        进程使多个程序可以并发执行，而线程使得并发粒度更细，并发性更好，在切换时的代价比进程小。  
        线程是可以被系统**独立调度**的基本单位，但是不能独享资源。
 *  **死锁**  
    *什么是死锁*：多个进程因为竞争资源而造成的一种僵局，若无外力作用，这些进程将永远无法推进。
    
    *死锁产生的必要条件*：
    
    1.  **互斥**：至少有一个资源必须属于非共享模式，即一次只能被一个进程使用；若其他申请使用该资源，那么申请进程必须等到该资源被释放为止；
    2.  **占有并等待**：一个进程必须占有至少一个资源，并等待另一个资源，而该资源为其他进程所占有；
    3.  **非抢占**：进程不能被抢占，即资源只能被进程在完成任务后自愿释放
    4.  **循环等待**：若干进程之间形成一种头尾相接的环形等待资源关系
    
    *死锁处理的方法*：  
    死锁预防（破坏四个条件之一）、死锁避免（银行家算法，让系统出于安全状态）、死锁检测、死锁恢复（终止进程/资源抢占）

## HTTPS部分 ##

参考文章：https://juejin.cn/post/6844904065227292685\#heading-11

Q: HTTPS 为什么安全？  
A: 因为 HTTPS **保证了传输安全**，防止传输过程被监听、防止数据被窃取，可以确认网站的真实性。

*  **HTTP的缺点**
    
    1.  通信使用明文，内容可能会被窃听
    2.  不验证通信放的身份，可能遭遇伪装（证书）
    3.  无法证明报文的完整性，内容可能已经被篡改（中间人攻击）
 *  **HTTP + 加密 + 认证 + 完整性保护 = HTTPS**  
    HTTPS是身批SSL(安全套接层)外壳的HTTP。HTTPS是先和SSL通信，再由SSL和TCP通信。
 *  **加密**  
    **共享密钥加密**：加密解密用同一个密钥。  
    **公开密钥加密**：使用一对非对称密钥，一把叫私有密钥，一把叫公有密钥，发送密文的一方使用对方传输过来的公有密钥加密，然后将加密后的内容传给接受方，接收方用自己的私有密钥可以解密。  
    公开密钥加密更复杂，速度较慢，因此HTTPS采取两者并用的**混合加密机制**。
    
    ***先使用公开密钥中的公有密钥加密共享密钥，然后发送发就可以用私有密钥解密共享密钥，然后就可以用共享密钥进习性加密，但是不传输共享密钥。***
    
    问题：公有密钥传输的时候可能被攻击者替换了。  
    解决：使用由数字证书认证机构（CA）颁发的公开密钥证书。  
    服务器先向CA申请公开密钥证书，然后服务器将证书发给客户端。客户端验证域名、有效期等信息是否正确。客户端可以使用CA的公开密钥（不是服务端的，是CA的！）来验证证书上的数字签名。为了将CA的公开密钥给客户端，浏览器会是现在内部植入常用认证机关的公开密钥，因此不需要传输。  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 3]  
    ① 证书验证阶段

1.  浏览器发起 HTTPS 请求
2.  服务端返回 HTTPS 证书
3.  客户端验证证书是否合法，如果不合法则提示告警

② 数据传输阶段

1.  数据传输阶段当证书验证合法后，在本地生成随机数
2.  通过公钥加密随机数，并把加密后的随机数传输到服务端
3.  服务端通过私钥对随机数进行解密
4.  服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

**关于随机数的安全**：  
其实 HTTPS 并不包含对随机数的安全保证，HTTPS 保证的只是传输过程安全，而随机数**存储于本地**，本地的安全属于另一安全范畴，应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。

**为什么需要 CA 认证机构颁发证书？**  
否则可能会受到**中间人攻击。**  
过程原理：  
1. 本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器  
2. 中间人服务器返回中间人自己的证书  
3. 客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输  
4. 中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密  
5. 中间人以客户端的请求内容再向正规网站发起请求获取内容

## 前端安全 ##

攻击大致可以分为：主动攻击和被动攻击。  
**主动攻击**：攻击者直接访问Web页面，把攻击代码传入得攻击模式。比如**SQL注入，OS命令注入**。  
**被动攻击**：利用圈套策略引诱用户点击来执行攻击代码。比如**跨站脚本攻击，跨站请求伪造**。

*  **XSS跨站脚本攻击**  
    攻击者实现布置好用于攻击的陷阱，比如修改URI得查询字段变成会在Web执行的代码，然后将连接用邮件发给用户，吸引用户点击。  
    分为**反射型（XSS攻击脚本被web server反射回来给浏览器执行）和持久型（存储在web server中）**。
    
    **防御方法：**
    
    1.  在Cookie中设置HttpOnly。可以防止XSS攻击后读取Cookie的值，但是不能方式XSS攻击。
    2.  输入检查，网上有很多开源的 XSS Filter
    3.  输出检查，所有需要输出到 HTML 页面的变量，全部需要使用编码或者转义来防御。
 *  针对 HTML 代码的编码方式是 **HTMLEncode**，它的作用是将字符串转换成 **HTMLEntities**。  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 4]  
    使用：![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 5]
 *  **JavaScriptEncode** 与 HTMLEncode 的编码方式不同，它需要用 \\ 对特殊字符进行转义。除了数字，字符之外的所有字符，小于127的字符编码都使用**十六进制** \\xHH 的方式进行编码，大于用**unicode**（非常严格模式）。
 *  **SQL注入（OS注入同理）**  
    防御方法：**sql语句预编译**  
    如果每次都需要经过上面的词法语义解析、语句优化、制定执行计划等，则效率就明显不行了。为了解决上面的问题，于是就有了预编译，预编译语句就是将这类语句中的值用占位符替代，可以视为将sql语句模板化或者说参数化。一次编译、多次运行，省去了解析优化等过程。
    
    1.  预编译阶段可以优化 sql 的执行。编译之后的 sql 多数情况下可以直接执行，DBMS 不需要再次编译，越复杂的sql，编译的复杂度将越大，预编译阶段可以合并多次操作为一个操作。可以提升性能。  
        防止SQL注入
    2.  使用预编译，而其后注入的参数将不会再进行SQL编译。也就是说其后注入进来的参数系统将不会认为它会是一条SQL语句，而默认其是**一个参数**，当成字符串，参数中的or或者and 等就不是SQL语法保留字了。
        
            String sql = "select id, no from user where id=?";
                    PreparedStatement ps = conn.prepareStatement(sql);
                    ps.setInt(1, id);
                    ps.executeQuery();
 *  **跨站点请求伪造CSRF**  
    攻击者通过设置好的陷阱，强制对完成认证的用户进行非预期的个人信息状态更新。  
    比如用户在登陆某网站后，浏览器保存了该网站的Cookie，这是攻击者将准备好的连接发邮件，用户点击后攻击者就可以在不知情的情况下运行脚本，使登陆后有权限的用户做不知道的事。  
    防御：
    
    1.  **验证 HTTP Referer 字段**  
        根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站。  
        但是每个浏览器对于 Referer 的具体实现可能有差别，并且有的用户认为这个会泄露隐私，可以手动关闭。
    2.  在请求地址中添加 **token** 并验证  
        要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
        
         *  **将CSRF Token输出到页面中**。首先，用户打开页面的时候，服务器需要给这个用户生成一个Token，该Token通过加密算法对数据进行加密，一般Token都包括**随机字符串和时间戳**的组合，显然在提交时Token不能再放在Cookie中了，否则又会被攻击者冒用。因此，为了安全起见Token最好还是**存在服务器的Session中**，之后在每次页面加载时，使用JS遍历整个DOM树，对于DOM中所有的a和form标签后加入Token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的HTML代码，这种方法就没有作用，还需要程序员在编码时手动添加Token。
         *  **页面提交的请求携带这个Token**
         *  **服务器验证Token是否正确**。当用户从客户端得到了Token，再次提交给服务器的时候，服务器需要判断Token的有效性，验证过程是先解密Token，对比加密字符串以及时间戳，如果加密字符串一致且时间未过期，那么这个Token就是有效的。
    
    但是，在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的。该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。
    
    1.  **在 HTTP 头中自定义属性并验证**  
        这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。  
        XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起，而且通过该类请求得到的页面不能被浏览器所记录下，从而进行前进，后退，刷新，收藏等操作，给用户带来不便。
 *  **页面劫持**

> 使用HTTP请求请求一个网站页面的时候，网络运营商会在正常的数据流中插入精心设计的网络数据报文，让客户端（通常是浏览器）展示“错误”的数据，通常是一些弹窗，宣传性广告或者直接显示某网站的内容。

常见劫持手段：

1.  **跳转型劫持：**  
    用户输入地址A，但是跳转到地址B
    
    > **DNS劫持**  
    > 在DNS服务器中，将www.xxx.com的域名对应的IP地址进行了变化。你解析出来的域名对应的IP，在劫持前后不一样；  
    > 地址栏输入freebuf.com 访问本机的hosts文件，查找 freebuf.com 所对应的 IP，若找到，则访问该IP  
    > 若未找到，则进行这一步，去（远程的）DNS服务器上面找freebuf.com 的IP，访问该IP  
    > 中间人劫持就发生在第三步：由于恶意攻击者控制了你的网关，当你发送了一个查找freebuf.com的IP的请求的时候，中间人拦截住，并返回给你一个恶意网址的IP,你的浏览器就会把这个IP当做你想要访问的域名的IP!!这个IP是攻击者搭建的一个模仿了目标网站前端界面的界面，当你在该界面输入用户名密码或者付款操作的时候，就会中招。
2.  **注入型劫持：**  
    指通过在正常的网页中注入广告代码(js、iframe等)，实现页面弹窗提醒或者底部广告等。注入js类劫持，iframe类劫持，篡改页面类劫持。
    
    > HTTP劫持:标识HTTP连接。在天上飞的很多连接中，有许多种协议，第一步做的就是在TCP连接中，找出应用层采用了HTTP协议的连接，进行标识；篡改HTTP响应体，可以通过网关来获取数据包进行内容的篡改；抢先回包，将篡改后的数据包抢先正常站点返回的数据包先到达用户侧，这样后面正常的数据包在到达之后会被直接丢弃。后面可以嵌入ifrme来展示服务器返回的页面。
    
    **防御：使用HTTPS!**

## 浏览器缓存 ##

分为 **强制缓存**和**协商缓存** 。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDE5NDI5OQ_size_16_color_FFFFFF_t_70 3]

*  **强制缓存**  
    强制缓存就是向**浏览器缓存**查找该请求结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程。有三种可能情况:  
    （1）不存在该缓存结果和缓存标识（即没有缓存），强制缓存失效，则直接向服务器发起请求（跟第一次发起请求一致。  
    （2）存在该缓存结果和缓存标识，但是结果已经失效（过期了），强制缓存失效，则使用协商缓存。  
    （3）存在该缓存结果和缓存标识，且该结果没有还没有失效，强制缓存生效，直接返回该结果。
    
    控制强制缓存的字段分别是**Expires**和**Cache-Control**，其中Cache-Conctrol的优先级比Expires高。  
    **Expires**：Expires是HTTP/1.0控制网页缓存的字段，其值为**服务器返回该请求的结果缓存的到期时间**，即再次发送请求时，如果客户端的时间小于Expires的值时，直接使用缓存结果。到了HTTP/1.1，Expires已经被Cache-Control替代，原因在于Expires控制缓存的原理是使用客户端的时间与服务端返回的时间做对比，但是客户端与服务端的时间由于某些原因有误差。  
    **Cache-Control**：在HTTP/1.1中，Cache-Control是最重要的规则，主要用于控制网页缓存，主要取值为：
    
        （1）public：所有内容都将被缓存（客户端和代理服务器都可缓存）
          
          （2）private：所有内容只有客户端可以缓存，Cache-Control的默认取值
          
          （3）no-cache：客户端缓存内容，但是是否使用缓存则需要经过协商缓存来验证决定
          
          （4）no-store：所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存
          
          （5）max-age=xxx (xxx is numeric)：缓存内容将在xxx秒后失效
    
    HTTP响应报文中expires的时间值，是一个绝对值，HTTP响应报文中Cache-Control为max-age=600，是相对值。这两个属性都是**响应报文中**的头部属性。
 *  **协商缓存**  
    协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程，主要有以下两种情况：  
    （1）协商缓存生效，服务器返回304。则标识该资源无更新，缓存中的资源还可以使用，于是客户端重新请求浏览器缓存中的资源。  
    （2）协商缓存失败，返回200和请求结果，标识资源有更新，并且返回了新的请求结果，浏览器再将新的结果重新进行缓存。
    
    控制协商缓存的字段分别有：**Last-Modified / If-Modified-Since**和**Etag / If-None-Match**，其中Etag / If-None-Match的优先级比Last-Modified / If-Modified-Since高。  
    **Last-Modified / If-Modified-Since**：  
    Last-Modified是服务器响应请求时，返回该资源文件在服务器最后被修改的时间，If-Modified-Since则是客户端再次发起该请求时，携带上次请求返回的Last-Modified值，通过此字段值告诉服务器该资源上次请求返回的最后被修改时间。  
    服务器收到该请求，发现请求头含有If-Modified-Since字段，则会根据If-Modified-Since的字段值与该资源在服务器的最后被修改时间做对比，若服务器的资源最后被修改时间大于If-Modified-Since的字段值，则重新返回资源，状态码为200；否则则返回304，代表资源无更新，可继续使用缓存文件。  
    **Etag / If-None-Match**  
    Etag是服务器响应请求时，返回当前资源文件的一个唯一标识(由服务器生成)，If-None-Match是客户端再次发起该请求时，携带上次请求返回的唯一标识Etag值，通过此字段值告诉服务器该资源上次请求返回的唯一标识值。如果服务器资源进行了更新的话，会重新生成ETAG。  
    服务器收到该请求后，发现该请求头中含有If-None-Match，则会根据If-None-Match的字段值与该资源在服务器的Etag值做对比，一致则返回304，代表资源无更新，继续使用缓存文件；不一致则重新返回资源文件，状态码为200。

## Web Store ##

**sessionStorage**和**localStorage**  
都是存储在客户端的。不会于服务端有交互。  
sessionStorage 和 locatlStorage 区别在于 数据存在**时间范围** 和 **页面范围**。  
sessionStorage: 数据**只保存到存储它的窗口或标签关闭时**，数据在构建它们的窗口或标签内也可见  
localStorage: 数据的生命周期比窗口或浏览器的生命周期长，数据可被**同源的每个窗口或者标签共享**

## Hash表 ##

Hash 表的物理存储其实是一个数组，如果我们能够根据 Key 计算出数组下标，那么就可以快速在数组中查找到需要的 Key 和 Value。最简单的方法就是余数法，使用 Hash 表的数组长度对 HashCode 求余， 余数即为 Hash 表数组的下标，使用这个下标就可以直接访问得到 Hash 表中存储的 Key、Value。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 6]  
事实上，(“abc”,“hello”) 这样的 Key、Value 数据并不会直接存储在 Hash 表的数组中，因为数组要求存储固定数据类型，主要目的是每个数组元素中要存放固定长度的数据。所以，数组中存储的是 Key、Value 数据元素的地址指针。一旦发生 Hash 冲突，只需要将相同下标，不同 Key 的数据元素添加到这个链表就可以了。查找的时候再遍历这个链表，匹配正确的 Key。![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 7]  
如果所有 Key 的数组下标都冲突，那么 Hash 表就退化为一条链表，查询的时间复杂度是 O(N)。但是平时说的话，Hash 表的时间复杂度为什么是 O(1)是没有问题的。

## CDN ##

**内容分发网络**。其目的是在用户和服务器之间通过现有的网络建立一个类似于Cache的网络架构，将网站的内容发布到最接近用户的网络“边缘”,使得用户可以很快的访问到自己所需要的资源，节省了用户访问的时间。CDN系统能够**实时地**根据网络流量和各节点的连接和负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上，加快访问速度。

***优势：***

1.  CDN节点解决了跨运营商和跨地域访问的问题，访问延时大大降低；
2.  大部分请求在CDN边缘节点完成，CDN起到了分流作用，减轻了源站的负载。

***实现过程***

1.  当用户点击网站页面上的内容URL，经过**本地DNS系统解析**，DNS 系统会最终将域名的解析权交给 CNAME 指向的 **CDN 专用 DNS 服务器**。
2.  CDN 的 DNS 服务器将 CDN 的**全局负载均衡设备** IP 地址返回用户。
3.  用户向 CDN 的全局负载均衡设备发起内容 URL 访问请求。
4.  CDN 全局负载均衡设备根据用户 IP 地址，以及用户请求的内容URL，选择一台用户所属区域的**区域负载均衡设备**，告诉用户向这台设备发起请求。  
    基于以下这些条件的综合分析之后，区域负载均衡设备会向全局负载均衡设备返回一台**缓存服务器**的IP地址：

*  根据用户 IP 地址，判断哪一台服务器距用户最近；
 *  根据用户所请求的 URL 中携带的内容名称，判断哪一台服务器上有用户所需内容；
 *  查询各个服务器当前的负载情况，判断哪一台服务器尚有服务能力。

1.  全局负载均衡设备把服务器的 IP 地址返回给用户。
2.  用户向缓存服务器发起请求，缓存服务器响应用户请求，将用户所需内容传送到用户终端。如果这台缓存服务器上并没有用户想要的内容，而区域均衡设备依然将它分配给了用户，那么这台服务器就要向它的上一级缓存服务器请求内容，直至追溯到网站的源服务器将内容拉到本地。

**1. 负载均衡技术**  
网络中的负载均衡就是将网络的流量尽可能均匀分配到几个能完成相同任务的服务器或网络节点上，由此来避免部分网络节点过载。

**2. 动态分发与复制技术**  
多数情况下，网站响应速度和访问者与网站服务器之间的**距离**有密切的关系。如果访问者和网站之间的距离过远的话，它们之间的通信一样需要经过重重的路由转发和处理，网络延误不可避免。一个有效的方法就是利用内容分发与复制技术，将占网站主体的大部分静态网页、图像和流媒体数据**分发复制**到各地的加速节点上。

**3. 缓存技术**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDE5NDI5OQ_size_16_color_FFFFFF_t_70]: /images/20220829/9a002d17befb4723ab386ce5657cbf9e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDE5NDI5OQ_size_16_color_FFFFFF_t_70_pic_center]: /images/20220829/280ccfc527aa4d12bf398855fe922ec0.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/89283e9c85b5474aa9bfbeed6318aaef.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDE5NDI5OQ_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20220829/181189874a824ef19e706df425229304.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA5YiYU3VybWFu_size_37_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/25c2b17af9cb4a3bba72844009c1452f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBA5YiYU3VybWFu_size_43_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/9a9d832836c74593b01c5a025d1443e2.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220829/99679d9afaa1451a923ec3c6800c514f.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220829/264c644e47154a93862ab6d3da001ce1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDE5NDI5OQ_size_16_color_FFFFFF_t_70 1]: /images/20220829/6aae44f5f5aa49298938574759fc4978.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDE5NDI5OQ_size_16_color_FFFFFF_t_70 2]: /images/20220829/fb72e3ca423443be8c7af252cb2855ef.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220829/de0a9b3bf08e4230a5a7a447bd86bace.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220829/e80054d6fb6d44f5b270fc3877900211.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 5]: /images/20220829/42233916f88b4be6a61943dc84275298.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDE5NDI5OQ_size_16_color_FFFFFF_t_70 3]: /images/20220829/065e387aa2904a08a3880e264bb07b3d.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 6]: /images/20220829/9ef634ea6b284c8f8f5872b21d44cd71.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYU3VybWFu_size_20_color_FFFFFF_t_70_g_se_x_16 7]: /images/20220829/e92ccfe5d44a4a8baf6f00faa3ec46a9.png