面试宝典-前后端交互

秋招季，总结一下前后端交互部分面经~

一. 跨域问题：

什么是跨域？

跨域，指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的，是浏览器对JavaScript施加的安全限制。
所谓同源是指，协议，域名，端口均相同。
注意：
如果是协议和端口造成的跨域问题“前台”是无能为力的；
在跨域问题上，域仅仅是通过“URL的首部”来识别

解决方案：

特别注意两点：
第一，如果是协议和端口造成的跨域问题“前台”是无能为力的，
第二：在跨域问题上，域仅仅是通过“URL的首部”来识别而不会去尝试判断相同的ip地址对应着两个域或两个域是否在同一个ip上。
1. JSONP方式解决跨域问题
script标签src属性中的链接却可以访问跨域的js脚本，利用这个特性，服务端不再返回JSON格式的数据，而是返回一段调用某个函数的js代码，在src中进行了调用，这样实现了跨域。
2. CORS解决跨域问题
对后台进行配置，例如：PHP端修改header，然后配置Apache web服务器跨域
3. 代理请求方式解决接口跨域问题
前端对接口进行代理：（前端ajax请求的是本地接口；本地接口接收到请求后向实际的接口请求数据，然后再将信息返回给前端；一般用node.js即可代理；）
详情参考https://segmentfault.com/a/1190000012469713

二. Jsonp实现原理

1. 拥有”src”这个属性的标签都拥有跨域的能力，比如<\script>、<\img>、<\iframe>
   当需要通讯时，本站脚本创建一个script元素，地址指向第三方的API网址，形如：

<script src="http://www.example.net/api?param1=1¶m2=2"></script>

并提供一个回调函数localHandler来接收数据（函数名可约定，或通过地址参数传递）。

<script src="http://www.example.net/api?param1=1&callback=localHandler" type="text/javascript">
var localHandler = function(data){
    alert('我是本地函数，可以被跨域的remote.js文件调用，远程js带来的数据是：' + data.result);
};
</script>

2. 第三方产生的响应为json数据的包装（故称之为jsonp，即json padding），形如：

localHandler(
    {
        "result":"hax",
        "gender":"Male"
    }
)

3. 这样浏览器会调用localHandler函数，并传递解析后json对象作为参数。

三. 前后端分离的好处

1. 最大的好处就是前端JS可以做很大部分的数据处理工作，对服务器的压力减小到最小。
2. 后台错误不会直接反映到前台，错误接秒较为友好。
3. 由于后台是很难去探知前台页面的分布情况，而这又是JS的强项，而JS又是无法独立和服务器进行通讯的。所以单单用后台去控制整体页面，又或者只靠JS完成效果，都会难度加大，前后台各尽其职可以最大程度的减少开发难度。

四. 从输入一个URL到页面加载完成的过程中都发生了什么事情？

主要分为6步：

1. DNS域名解析
2. 浏览器与服务器建立TCP连接（3次握手过程）
3. 浏览器向服务器发起HTTP请求
4. 服务器接受请求，进行响应结果，将生成的html返回给客户端
5. 浏览器解析HTML,并请求html代码中的资源
6. 浏览器对页面进行渲染呈现给用户

网络通信的整个流程：

流程描述：
第一步：打开浏览器，想要请求访问京东，在地址栏输入了网址：www.jd.com。（www.jd.com是域名就是一个IP地址的名称，IP地址不好记，所有有了域名。）
第二步：先将请求信息发给了交换机，然后交给了路由器，路由发给DNS服务器，通过DNS协议去找我们要访问的京东的IP地址：
　　第三步：查到的京东服务器对应的IP地址之后，路由器通过路由协议找到一个路由转发的最优路径，将你的请求信息还送给这个IP地址的京东的路由器
　　第四步：京东的路由器发给了京东网站的服务器上
　　第五步：京东网站服务器按照来的时候的路径，在返回给你他自己的网站
　　第六步：当你打开浏览器的时候，你的电脑给你的浏览器这个运行起来的程序给了一个编号，叫做端口号，当你的电脑收到京东发送过来的消息的时候，你的电脑通过端口号找到你的浏览器，你的浏览器拿到了京东的网站信息，然后将网站呈现在了自己的浏览器上

五. 进程和线程的区别

• 进程：是并发执行的程序在执行过程中分配和管理资源的基本单位，是一个动态概念，竞争计算机系统资源的基本单位。

• 线程：是进程的一个执行单元，是进程内科调度实体。比进程更小的独立运行的基本单位。线程也被称为轻量级进程。
  一个程序至少一个进程，一个进程至少一个线程。

• 对资源的管理和保护要求高，不限制开销和效率时，使用多进程。
  要求效率高，频繁切换时，资源的保护管理要求不是很高时，使用多线程。

• 线程共享进程资源，进程之间的资源独立
  一个进程崩溃后，在保护模式下不会对其他进程产生影响，但是一个线程崩溃整个进程都死掉。所以多进程要比多线程健壮。进程切换时，消耗的资源大，效率高

• 线程与进程的区别：
  a. 一个程序至少有一个进程，一个进程至少有一个线程
  b. 线程的划分尺度小于进程，使得多线程程序的并发性高
  c. 进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率
  d. 每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制
  e. 多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配

六. 队列和栈介绍

• 队列：先进先出，表尾插入，表头删除。
  队列可以模拟很多现实的生产环境，例如排队，队列是先进先出，不允许有任何元素插队，这对于解决现实生产问题有很大帮助。
  栈：先进后出，表尾删除插入。
  可以很好的控制访问，栈的数据访问是有很严格的，只能访问最后加入的数据，这对数据访问控制严格的应用很有好处。现实中，字符串倒序输出，使用栈的原理就可以很好的实现。

• 栈与队列的相同点：
  1.都是线性结构。
  2.插入操作都是限定在表尾进行。
  3.都可以通过顺序结构和链式结构实现。
  4.插入与删除的时间复杂度都是O(1)，效率非常高，在空间复杂度上两者也一样。
  5.多链栈和多链队列的管理模式可以相同。

• 栈与队列的不同点：

  1. 队列先进先出，栈先进后出。
  2. 对插入和删除操作的”限定”不同。
     栈是限定只能在表的一端进行插入和删除操作的线性表。
     队列是限定只能在表的一端进行插入和在另一端进行删除操作的线性表。
  3. 遍历数据速度不同。
     栈只能从头部取数据，也就最先放入的需要遍历整个栈最后才能取出来，而且在遍历数据的时候还得为数据开辟临时空间，保持数据在遍历前的一致性。
     队列则不同，它基于地址指针进行遍历，而且可以从头或尾部开始遍历，但不能同时遍历，无需开辟临时空间，因为在遍历的过程中不影像数据结构，速度要快的

七. HTTP状态码及常见举例

1** ：信息，服务器收到请求，需要请求者继续执行操作
2** ：成功，操作被成功接收并处理
3** ：重定向，需要进一步的操作以完成请求
4** ：客户端错误，请求包含语法错误或无法完成请求
5** ：服务器错误，服务器在处理请求的过程中发生了错误
100 ：继续。客户端应继续其请求。
101 ：切换协议，服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
200 ：OK。请求成功，一般用于Get和post请求。
201 ：已创建。成功请求并创建了新的资源。
202 ：已接受。已经接受请求，但未处理完成
203 ：非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本。
204：无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档。
300：多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择。
301 ：永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替。
302：临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI。
304：服务端资源无变化，可使用缓存资源
307：临时重定向。与302类似。使用GET请求重定向。
400：客户端请求的语法错误，服务器无法理解
401：请求要求用户的身份认证
403：服务端禁止访问该资源
404：服务器无法根据客户端的请求找到资源（网页）。
408：服务器等待客户端发送的请求时间过长，超时。
410：客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置。
411：服务器无法处理客户端发送的不带Content-Length的请求信息
414：请求的URI过长（URI通常为网址），服务器无法处理
417：服务器无法满足Expect的请求头信息。
500：服务器内部错误，无法完成请求。
501：服务器不支持请求的功能，无法完成请求。
502：充当网关或代理的服务器，从远端服务器接收到了一个无效的请求
503：由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中。
504：充当网关或代理的服务器，未及时从远端服务器获取请求。
505：服务器不支持请求的HTTP协议的版本，无法完成处理。

八. Http请求方法

• Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE，对URL地址（网络上的资源）的查，改，增，删4个操作。5、HEAD；6、TRACE；7、OPTIONS；

• GET与POST方法有以下区别：
  1. 在客户端，Get方式在通过URL提交数据，数据在URL中可以看到；POST方式，数据放在HTTP包的body中。
  2. GET方式提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST则没有此限制。
  3. 安全性问题。正如在（1）中提到，使用 Get 的时候，参数会显示在地址栏上，而 Post 不会。所以，如果这些数据是中文数据而且是非敏感数据，那么使用 get；如果用户输入的数据不是中文字符而且包含敏感数据，那么还是使用 post为好。
  4. 服务器取值方式不一样。GET方式取值，如php可以使用$_GET来取得变量的值，而POST方式通过$_POST来获取变量的值。
     
• Post和put区别
  PUT请求：如果两个请求相同，后一个请求会把第一个请求覆盖掉。（所以PUT用来改资源）
  Post请求：后一个请求不会把第一个请求覆盖掉。（所以Post用来增资源）

九. 计算机网络的七层OSI

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

十. TCP/IP五层模型的协议

应用层、传输层、网络层、数据链路层、物理层

十一. TCP和UDP的区别是什么

UDP协议和TCP协议都是传输层协议。

TCP（Transmission Control Protocol，传输控制协议）

• TCP（Transmission Control Protocol，传输控制协议）提供的是面向连接，可靠的字节流服务。即客户和服务器交换数据前，必须现在双方之间建立一个TCP连接，之后才能传输数据。并且提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。

  1. 优点：可靠，稳定　
     TCP的可靠性体现在传输数据之前，三次握手建立连接（四次挥手释放连接），并且在数据传递时，有确认、窗口、重传、拥塞控制机制，数据传完之后，断开连接用来节省系统资源。
  2. 缺点：慢，效率低，占用系统资源高，易被攻击　
     传数据之前建立连接，这样会消耗时间，而且在消息传递时，确认机制、重传机制和拥塞控制机制都会消耗大量的时间，而且要在每台设备上维护所有的传输连接。而每个连接都会占用系统的CPU、内存等硬件软件资源。并且TCP的取而机制、三次握手，这些也导致TCP容易被人利用，实现DOS，DDOS攻击。
  3. 协议：
     • HTTP
     • HTTPS
     • SSH
     • Telnet
     • FTP
     • SMTP
  4. TCP应用场景：
     • 效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。
  5. TCP粘包问题
     • 首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包；
     • 在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段；
     • 站在传输层的角度, TCP是一个一个报文过来的，按照序号排好序放在缓冲区中；
     • 站在应用层的角度, 看到的只是一串连续的字节数据. 那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包。
  6. 那么如何避免粘包问题呢?
     • 归根结底就是一句话, 明确两个包之间的边界.
     1. 对于定长的包, 保证每次都按固定大小读取即可;
     2. 对于变长的包, 可以在报头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
     3. 对于变长的包, 还可以在包和包之间使用明确的分隔符。
     4. TLV格式的数据传输

UDP（User Data Protocol，用户数据报协议）

• UDP（User Data Protocol，用户数据报协议）是一个简单的面向数据报的运输层协议。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。由于UDP在传输数据报前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。

  1. 优点：快，比TCP稍安全　
     UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，udp是一个无状态的传输协议，所以他在传输数据时非常快。M没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。UDP也是无法避免攻击的，比如：UDP flood攻击
  2. 缺点：不可靠，不稳定
     因为UDP没有TCP的那些可靠机制，在网络质量
     不好时很容易丢包。
  3. 协议：
     • NFS: 网络文件系统
     • TFTP: 简单文件传输协议
     • DHCP: 动态主机配置协议
     • BOOTP: 启动协议(用于无盘设备启动)
     • DNS: 域名解析协议
  4. UDP应用场景：
     • 效率要求相对高，对准确性要求相对低的场景。举几个例子：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。

TCP与UDP区别总结：

1. `TCP面向连接`（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2. `TCP提供可靠的服务`。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
3. `TCP面向字节流`，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的

UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）

4. 每一条`TCP连接只能是点到点的`;UDP支持一对一，一对多，多对一和多对多的交互通信
5. TCP`首部开销`20字节;UDP的首部开销小，只有8个字节
6. TCP的逻辑通信信道是`全双工`的`可靠信道`，UDP则是不可靠信道

十二. TCP与HTTP的不同，HTTP是什么，HTTPS是什么

• HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。
• HTTPS即加密的HTTP，HTTPS并不是一个新协议，而是HTTP+SSL（TLS）。原本HTTP先和TCP（假定传输层是TCP协议）直接通信，而加了SSL后，就变成HTTP先和SSL通信，再由SSL和TCP通信，相当于SSL被嵌在了HTTP和TCP之间。
• TCP是传输层，而http是应用层，http是要基于TCP连接基础上的。
  TCP就是单纯建立连接，不涉及任何我们需要请求的实际数据，简单的传输。
  http是用来收发数据，即实际应用上来的。

十三. TCP的三次握手,为什么不是两次？

• 三次握手：请求，确认，建立连接
  第一次：客户端C发送一个请求连接的位码SYN(1)和一个随机产生的序列号Seq(x)给服务器S，C进入SYN_SEND状等待服务器确认。
  第二次：S收到了这个请求连接的位码SYN(1)，实现确认一下，发送了一个确认码ACK（x+1)+SYN(1)+Seq（y）给进入SYN_RECV状态。
  第三次：C收到了SYN＋ACK，一比较一样，于是他又发送了一个ACK(y+1)+Seq(z)给S，S收到以后就确定建立连接，C和S进入ESTABLISHED状态，TCP连接建立完成。
• 为什么不是两次？
  三次是①C能和S通信②S能和C通信③S和C建立连接，
  两次的话，不能确定S和C是否能通信，会产生问题
  

十四. 四次挥手：确保数据能够完整传输。

1. 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。C没数据传输了
2. 第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。S说我也没了
3. 第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。C请求关闭
4. 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。S同意并关闭

十五. 一次js请求一般情况下有哪些地方会有缓存处理？

1. 浏览器端存储
2. 浏览器端文件缓存
3. HTTP缓存304
4. 服务器端文件类型缓存
5. 表现层&DOM缓存

十六. HTTP缓存机制

Web 缓存大致可以分为：数据库缓存、服务器端缓存（代理服务器缓存、CDN 缓存）、浏览器缓存。浏览器缓存也包含很多内容： HTTP 缓存、indexDB、cookie、localstorage 等等。

浏览器缓存分类浏览器缓存分为强缓存和协商缓存，浏览器加载一个页面的简单流程如下：

1. 浏览器先根据这个资源的http头信息来判断是否命中强缓存。如果命中则直接加在缓存中的资源，并不会将请求发送到服务器。
2. 如果未命中强缓存，则浏览器会将资源加载请求发送到服务器。服务器来判断浏览器本地缓存是否失效。若可以使用，则服务器并不会返回资源信息，浏览器继续从缓存加载资源。
3. 如果未命中协商缓存，则服务器会将完整的资源返回给浏览器，浏览器加载新资源，并更新缓存。

缓存规则解析

为方便大家理解，我们认为浏览器存在一个缓存数据库,用于存储缓存信息。在客户端第一次请求数据时，此时缓存数据库中没有对应的缓存数据，需要请求服务器，服务器返回后，将数据存储至缓存数据库中。　　

　　HTTP缓存有多种规则，根据是否需要重新向服务器发起请求来分类，我将其分为两大类(强制缓存，协商缓存)在详细介绍这两种规则之前，先通过时序图的方式，让大家对这两种规则有个简单了解。　　已存在缓存数据时，仅基于强制缓存，请求数据的流程如下：　　

　　已存在缓存数据时，仅基于协商缓存，请求数据的流程如下：

　　对缓存机制不太了解的同学可能会问，基于协商缓存的流程下，不管是否使用缓存，都需要向服务器发送请求，那么还用缓存干什么？这个问题，我们暂且放下，后文在详细介绍每种缓存规则的时候，会带给大家答案。　　我们可以看到两类缓存规则的不同，强制缓存如果生效，不需要再和服务器发生交互，而协商缓存不管是否生效，都需要与服务端发生交互。两类缓存规则可以同时存在，强制缓存优先级高于协商缓存，也就是说，当执行强制缓存的规则时，如果缓存生效，直接使用缓存，不再执行协商缓存规则。

1. 强缓存

• 强缓存命中强缓存时，浏览器并不会将请求发送给服务器。在Chrome的开发者工具中看到http的返回码是200，但是在Size列会显示为(from cache)。

• 强缓存是利用http的返回头中的Expires或者Cache-Control两个字段来控制的，用来表示资源的缓存时间。

Expires

• 缓存过期时间，用来指定资源到期的时间，是服务器端的具体的时间点。也就是说，Expires=max-age + 请求时间，需要和Last-modified结合使用。但在上面我们提到过，cache-control的优先级更高。 Expires是Web服务器响应消息头字段，在响应http请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据，而无需再次请求。
• 该字段会返回一个时间，比如Expires:Thu,31 Dec 2037 23:59:59 GMT。这个时间代表着这个资源的失效时间，也就是说在2037年12月31日23点59分59秒之前都是有效的，即命中缓存。这种方式有一个明显的缺点，由于失效时间是一个绝对时间，所以当客户端本地时间被修改以后，服务器与客户端时间偏差变大以后，就会导致缓存混乱。于是发展出了Cache-Control。

Cache-Control

• Cache-Control是一个相对时间，例如Cache-Control:3600，代表着资源的有效期是3600秒。由于是相对时间，并且都是与客户端时间比较，所以服务器与客户端时间偏差也不会导致问题。
  Cache-Control与Expires可以在服务端配置同时启用或者启用任意一个，同时启用的时候Cache-Control优先级高。

2. 协商缓存

• 若未命中强缓存，则浏览器会将请求发送至服务器。服务器根据http头信息中的Last-Modify/If-Modify-Since或Etag/If-None-Match来判断是否命中协商缓存。如果命中，则http返回码为304，浏览器从缓存中加载资源。

Last-Modify/If-Modify-Since

• 浏览器第一次请求一个资源的时候，服务器返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间，例如Last-Modify: Thu,31 Dec 2037 23:59:59 GMT。
• 当浏览器再次请求该资源时，发送的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存。
• 如果命中缓存，则返回http304，并且不会返回资源内容，并且不会返回Last-Modify。由于对比的服务端时间，所以客户端与服务端时间差距不会导致问题。但是有时候通过最后修改时间来判断资源是否修改还是不太准确（资源变化了最后修改时间也可以一致）。于是出现了ETag/If-None-Match。

ETag/If-None-Match

• 与Last-Modify/If-Modify-Since不同的是，Etag/If-None-Match返回的是一个校验码（ETag: entity tag）。ETag可以保证每一个资源是唯一的，资源变化都会导致ETag变化。ETag值的变更则说明资源状态已经被修改。服务器根据浏览器上发送的If-None-Match值来判断是否命中缓存。

十七. CDN（内容分发网络，Content Distribute Network）的概念以及使用CDN加速的优点。

cdn加速是什么？

• CDN解决的是如何将数据快速可靠从源站传递到用户的问题。用户获取数据时，不需要直接从源站获取，通过CDN对于数据的分发，用户可以从一个较优的服务器获取数据，从而达到快速访问，并减少源站负载压力的目的。
• 简单来讲云服务商会在全国各地部署节点服务器，当你的网站购买使用了他们的cdn，那么会把你网站可以缓存的内容都缓存在各地区的节点服务器上。这样不同地区的用户访问你的网站时，就可以在它最近的节点上访问，不需要到你的主站，通过这个方式达到加速的效果。
• 在通俗一点讲，比如京东自营，当你在网站上购买一件商品，需要快递到厦门，如果是从北京发货那么3天时间是需要的，但京东在厦门设立了仓库，并且提前把货存在仓库中，这时就可以直接从厦门仓发货，当天或隔天就可以收到商品，速度跟体验都非常好。

那么除了速度加快，使用cdn还有什么好处呢？

1. 网站不容易宕机
   如果你的网站没有使用cdn，当同个时间出现巨大的访问量时，网站很可能会宕机，比如双十一，凌晨过后突然有大量用户访问，如果不做负载处理那么页面打开会非常缓慢，在使用cdn后，就可以减少网站宕机的情况，承载更多的流量。
2. 保障网站安全
   cdn的负载均衡和分布式存储技术，加上节点之间的智能冗余机制，可以有效应对大部份的黑客入侵以及ddos的攻击，无形中给网站增加了一把保护伞，避免由于攻击带给网站的巨大损失。
3. 异地备援更可靠
   使用了cdn加速，当某一个节点服务器发生故障时，不会影响多数用户的访问，系统会判断并调用其它临近正常运行的服务器，这样的机制可以提供接近100%的可靠性，让你的网站做到永不宕机。
4. 减轻原服务器负载
   当内容分发自动缓存到其它服务器后，用户在访问网站时从临近的服务器上读取数据，减少原web服务器的带宽使用，分担网络流量、减少负载等好处。

• 不仅如此，cdn还有很多的优点，比如计费合理，平衡节点流量输出，减少费用开支等， 那么对SEO来讲好处主要是网站打开速度优化，稳定性更强，能承载大量蜘蛛访问抓取。

十八. 前端开发常见安全问题（SQL注入、XSS攻击、CSRF攻击）

1. SQL注入

• SQL攻击（SQL injection），简称注入攻击，是发生于应用程序之数据库层的安全漏洞。简而言之，是在输入的字符串之中注入SQL指令，在设计不良的程序当中忽略了检查，那么这些注入进去的指令就会被数据库服务器误认为是正常的SQL指令而运行，因此遭到破坏或是入侵。

• SQL注入攻击原理

  1. 寻找到SQL注入的位置
  2. 判断服务器类型和后台数据库类型
  3. 针对不通的服务器和数据库特点进行SQL注入攻击

• 防御措施：

  1. 永远不要信任用户的输入
     对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和双“-”进行转换等

  2. 永远不要使用动态拼装sql
     可以使用参数化的sql或者直接使用存储过程进行数据查询存取。哪怕参数是常量，也请用预编译语句PreparedStatement，同时用占位符，如： “select * from table where comment like ?”。
     注意：如果参数不是使用的占位符，即使用PreparedStatement执行时也并不是预编译。

  3. 永远不要使用管理员权限的数据库连接
     为每个应用使用单独的有权限的数据库连接，这样能降低数据库密码被泄漏而带来的破坏。

  4. 不要把机密信息直接存放
     加密或者hash掉密码和敏感的信息；如数据库连接密码、用户密码、设备密码需要加密存储。

  5. 应用的异常信息应该给出尽可能少的提示
     最好使用自定义的错误信息对原始错误信息进行包装。

2. XSS跨站脚本攻击

• XSS(Cross Site Scripting)跨站脚本攻击指攻击者在网页中嵌入客户端脚本(例如JavaScript)，当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的，比如获取用户的Cookie，导航到恶意网站，携带木马等

• 防御措施：

  1. 在cookie中不要存放一些敏感信息
     比如用户名、密码等安全信息，或者cookie中的信息采用加密的方式。最为有效的方式是将重要的cookie标记为http only，这样脚本中就不能访问这个cookie，就避免了XSS攻击利用JavaScript的document.cookie获取cookie：

  2. 输入过滤校验，对用户提交的数据进行有效性验证
     仅接受指定长度范围内并符合我们期望格式的的内容提交，阻止或者忽略除此外的其他任何数据。比如：电话号码必须是数字和中划线组成，而且要设定长度上限。过滤一些些常见的敏感字符，例如：< > ‘ “ & # \；过滤或移除特殊的Html标签， 例如: <script>, <iframe> , &lt; for <, &gt; for >, &quot for；过滤JavaScript 事件的标签，例如"οnclick=","onfocus"等等。这里的数据校验除了前台要做，后台也要做。

  3. DOM型的XSS攻击防御
     把变量输出到页面时要做好相关的编码转义工作，如要输出到<script>中，可以进行JS编码；要输出到HTML内容或属性，则进行HTML编码处理。根据不同的语境采用不同的编码处理方式。

3. CSRF（ Cross-site request forgery ）跨站点请求伪造

• CSRF（ Cross-site request forgery ）也被称为“one click attack”或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来很像XSS跨站脚本攻击，但是它于XSS完全不同。XSS是利用站点内的信任用户，而CSRF则是通过伪装来自受信任用户的请求来利用受信任的站点，从而在并未授权的情况下执行在权限保护之下的操作。与XSS相比，CSRF攻击不大流行和难以防范，所以比XSS更具危险性。

• CSRF攻击原理
  CSRF攻击原理比较简单，假设Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。

  1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
  2. 在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
  3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；
  4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
  5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

• 防御措施：

  1. 合理使用POST和GET
     GET方法提交数据很容易被拿来做CSRF攻击，使用POST只能降低攻击风险，并不能杜绝，攻击者在第三方页面构造一个form就可以用POST提交数据构成CSRF攻击。

  2. 使用验证码
     在通常情况下，验证码能很好遏制CSRF攻击。但是出于用户体验考虑，网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手段，不能作为主要解决方案。

  3. 检查Referer字段
     HTTP头中有一个Referer字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer字段应和请求的地址位于同一域名下。以上文银行操作为例，Referer字段地址通常应该是转账按钮所在的网页地址，应该也位于www.examplebank.com之下。而如果是CSRF攻击传来的请求，Referer字段会是包含恶意网址的地址，不会位于www.examplebank.com之下，这时候服务器就能识别出恶意的访问

  4. 添加校验token
     由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址，所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再执行CSRF攻击。这种数据通常是表单中的一个数据项。服务器将其生成并附加在表单中，其内容是一个伪乱数。当客户端通过表单提交请求时，这个伪乱数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪乱数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪乱数的值，服务器端就会因为校验token的值为空或者错误，拒绝这个可疑请求。

十九. Ajax工作原理

1. 创建XMLHttpRequest对象,也就是创建一个异步调用对象.
2. 创建一个新的HTTP请求,并指定该HTTP请求的方法、URL及验证信息.
3. 设置响应HTTP请求状态变化的函数.
4. 发送HTTP请求.
5. 获取异步调用返回的数据.
6. 使用JavaScript和DOM实现局部刷新.

二十. 死锁是什么

死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，双方都在等待对方停止运行，以获取系统资源，但是没有一方提前退出时，就称为死锁。永远在互相等待的进程称为死锁进程。

二十一. 自适应和响应式区别

两者都是优化适应互联网中越来越分化的视口.
应该说响应式的范畴更广一些。
响应式可以自动适应不同尺寸的屏幕，无论你的设备尺寸多么奇葩。响应式使用CSS media queries的方法，根据目标设备自动改变风格如显示类型,宽度、高度等，这能很好解决不同屏幕尺寸的显示问题。
是一个网站能够兼容多个终端而不是为每个终端做一个特定的版本，这个概念是为移动互联网浏览而诞生。
自适应设计是基于断点使用静态布局，一旦页面被加载就无法再进行自动适应，自适应会自动检测屏幕的大小来加载适当的工作布局，也就是说，当你要采用自适应设计网站时，你得一个一个设计6种常见的屏幕布局。[自适应设计要求为每一个布局单独开发和维护HTML和CSS代码]
1、320 2、480 3、760 4、960 5、1200 6、1600
自适应设计需要做更多的工作，你必须至少设计6种常见的布局。而响应式设计可以更好地适应复杂的媒体设备要求，能很好地解决显示和性能问题，修改相当麻烦。修改相当麻烦。

二十二. 谈谈你对前端性能优化的理解

1. 请求数量：合并脚本和样式表，CSS Sprites，拆分初始化负载，划分主域
2. 请求带宽：开启GZip，精简JavaScript，移除重复脚本，图像优化，将icon做成字体
3. 缓存利用：使用CDN，使用外部JavaScript和CSS，添加Expires头，减少DNS查找，配置ETag，使AjaX可缓存
4. 页面结构：将样式表放在顶部，将脚本放在底部，尽早刷新文档的输出
5. 代码校验：避免CSS表达式，避免重定向

二十三. 请说出三种减少页面加载时间的方法

1. 尽量减少页面中重复的HTTP请求数量
2. 服务器开启gzip压缩
3. css样式的定义放置在文件头部
4. Javascript脚本放在文件末尾
5. 压缩合并Javascript、CSS代码
6. 使用多域名负载网页内的多个文件、图片

二十四. 一个页面上有大量的图片（大型电商网站），加载很慢，你有哪些方法优化这些图片的加载，给用户更好的体验[性能优化]。

1. 图片懒加载，滚动到相应位置才加载图片。
2. 图片预加载，如果为幻灯片、相册等，将当前展示图片的前一张和后一张优先下载。
3. 使用CSSsprite，SVGsprite，Iconfont、Base64等技术，如果图片为css图片的话。
4. 如果图片过大，可以使用特殊编码的图片，加载时会先加载一张压缩的特别厉害的缩略图，以提高用户体验。

二十五. 什么叫优雅降级和渐进增强？

• 渐进增强 progressive enhancement：
  针对低版本浏览器进行构建页面，保证最基本的功能，然后再针对高级浏览器进行效果、交互等改进和追加功能达到更好的用户体验。
• 优雅降级 graceful degradation：
  一开始就构建完整的功能，然后再针对低版本浏览器进行兼容。

  渐进增强和优雅降级的区别：

1. 优雅降级是从复杂的现状开始，并试图减少用户体验的供给
2. 渐进增强则是从一个非常基础的，能够起作用的版本开始，并不断扩充，以适应未来环境的需要
3. 降级（功能衰减）意味着往回看；而渐进增强则意味着朝前看，同时保证其根基处于安全地带

二十六. 网站重构的理解

重构：在不改变外部行为的前提下，简化结构、添加可读性，而在网站前端保持一致的行为。

1. 使网站前端兼容于现代浏览器(针对于不合规范的CSS、如对IE6有效的)
2. 对于移动平台的优化，针对于SEO进行优化
3. 减少代码间的耦合，让代码保持弹性
4. 压缩或合并JS、CSS、image等前端资源

二十七. 谈谈以前端角度出发做好SEO需要考虑什么？

1. 了解搜索引擎如何抓取网页和如何索引网页
2. meta标签优化
3. 关键词分析
4. 付费给搜索引擎
5. 链接交换和链接广泛度（Link Popularity）
6. 合理的标签使用

二十八. 前端页面有哪三层构成，分别是什么？作用是什么？

1. 结构层：由 HTML 或 XHTML 之类的标记语言负责创建，仅负责语义的表达。解决了页面“内容是什么”的问题。
2. 表示层：由CSS负责创建，解决了页面“如何显示内容”的问题。
3. 行为层：由脚本负责。解决了页面上“内容应该如何对事件作出反应”的问题。

二十九. 系统访问量变高了，速度变慢了怎么办？

优化。
优化方式很多，如：读写分离、负载均衡
资源服务器和应用服务器分离，即应用部署在应用服务器上，资源部署在资源服务器上。这时候，js和css的引用就需要更改为绝对URL，指向对应的资源服务器。

三十. WEB应用从服务器主动推送Data到客户端有那些方式？

1. html5 websoket
2. WebSocket 通过 Flash
3. XHR长时间连接
4. XHR Multipart Streaming
5. 不可见的Iframe
6. 标签的长时间连接(可跨域)

三十一. 知道的网页制作会用到的图片格式有哪些？

png-8，png-24，jpeg，gif，svg
Webp：谷歌（google）开发的一种旨在加快图片加载速度的图片格式。图片压缩体积大约只有JPEG的2/3，并能节省大量的服务器带宽资源和数据空间。Facebook Ebay等知名网站已经开始测试并使用WebP格式。
Apng：全称是“Animated Portable Network Graphics”, 是PNG的位图动画扩展，可以实现png格式的动态图片效果。04年诞生，但一直得不到各大浏览器厂商的支持，直到日前得到 iOS safari 8的支持，有望代替GIF成为下一代动态图标准。

三十二. AMD和CMD 规范的区别？

AMD 提前执行依赖 - 尽早执行，requireJS 是它的实现
CMD 按需执行依赖 - 懒执行，seaJS 是它的实现

三十三. 前端 MV*框架的意义

• 早期前端都是比较简单，基本以页面为工作单元，内容以浏览型为主，也偶尔有简单的表单操作，基本不太需要框架。
• 随着 AJAX 的出现，Web2.0的兴起，人们可以在页面上可以做比较复杂的事情了，然后前端框架才真正出现了。
• 如果是页面型产品，多数确实不太需要它，因为页面中的 JavaScript代码，处理交互的绝对远远超过处理模型的，但是如果是应用软件类产品，这就太需要了。
• 长期做某个行业软件的公司，一般都会沉淀下来一些业务组件，主要体现在数据模型、业务规则和业务流程，这些组件基本都存在于后端，在前端很少有相应的组织。
• 从协作关系上讲，很多前端开发团队每个成员的职责不是很清晰，有了前端的 MV框架，这个状况会大有改观。
• 之所以感受不到 MV*框架的重要性，是因为Model部分代码较少，View的相对多一些。如果主要在操作View和Controller，那当然 jQuery 这类库比较好用了。

三十四. 对前端工程师这个职位是怎么看的？

前端是最贴近用户的程序员，比后端、数据库、产品经理、运营、安全都近。

1. 实现界面交互
2. 提升用户体验
3. 有了Node.js，前端可以实现服务端的一些事情

前景：

1. 前端是最贴近用户的程序员，前端的能力就是能让产品从 90分进化到 100 分，甚至更??
2. 参与项目，快速高质量完成实现效果图，精确到1px；
3. 与团队成员，UI设计，产品经理的沟通；
4. 做好的页面结构，页面重构和用户体验；
5. 处理hack，兼容、写出优美的代码格式；
6. 针对服务器的优化、拥抱最新前端技术。

三十五. 平时如何管理你的项目？

1. 先期团队必须确定好全局样式（globe.css），编码模式(utf-8) 等；
2. 编写习惯必须一致（例如都是采用继承式的写法，单样式都写成一行）；
3. 标注样式编写人，各模块都及时标注（标注关键样式调用的地方）；
4. 页面进行标注（例如 页面 模块 开始和结束）；
5. CSS跟HTML 分文件夹并行存放，命名都得统一（例如style.css）；
6. JS 分文件夹存放 命名以该JS功能为准的英文翻译。
7. 图片采用整合的 images.png png8 格式文件使用 尽量整合在一起使用方便将来的管理

三十六. 说说最近最流行的一些东西吧？常去哪些网站？

CSDN、SegmentFault、php.net、MDN、css参考手册、iconfont、underscore、github、Bootstrap、W3Shool、W3Cplus、caniuse