未使用强缓存只用协商缓存有效吗

1. 前端开发面试不能快速进入开发状态

从jQuery华丽谢幕到如今React、Vue、Angular三大框架入手。
Vue原理归根结底是考验应试者的JavaScript功底。想要看透源码，JavaScript基本功要扎实。而HTTP协议更是属于长半衰期的知识，我们要重点掌握，因为可能到了你40岁的时候，这些知识仍然不会变。在充满浮躁和焦虑的当下，如果我们认真思考，就会发现其实真正值钱的不是新技术，而是我们能够使用技术改变整个行业或者世界。
再说回性能优化，性能优化的方式有很多，从编码到打包构建，再到线上CDN缓存。Google浏览器为我们提供了Performance页面性能分析工具，Performance可以记录站点在运行过程中的一些相关性能数据，通过配置可以生成详细的报告页，我们拿到这些原始数据就可以分析出Web应用的性能问题了。关于缓存策略也是面试中的热门问题，其实缓存分为强缓存和协商缓存。当浏览器进行资源请求时，会判断是否命中强缓存，如果命中则直接从本地缓存读取，不会向服务器发送请求。当强缓存没有命中或者请求头中设置了不走强缓存时，会发送请求到服务器，判断协商缓存是否命中。如果命中，服务器将请求返回，加载浏览器缓存，如果没有命中，服务器则直接将资源返回。

2. 简述在tcp/ip体系中，流量控制和拥塞控制的不同

1. 利用滑动窗口实现流量控制
如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意，TCP的窗口单位是字节，不是报文段。TCP连接建立时的窗口协商过程在图中没有显示出来。再设每一个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值ack。

从图中可以看出，B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ，第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。B向A发送的三个报文段都设置了 ACK = 1 ，只有在ACK=1时确认号字段才有意义。
TCP为每一个连接设有一个持续计时器(persistence timer)。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口控测报文段（携1字节的数据），那么收到这个报文段的一方就重新设置持续计时器。
2. 必须考虑传输速率
可以用不同的机制来控制TCP报文段的发送时机。如： <1>. TCP维持一个变量，它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去。<2>. 由发送方的应用进程指明要求发送报文段，即TCP支持的推送( push )操作。<3>. 发送方的一个计时器期限到了，这时就把已有的缓存数据装入报文段(但长度不能超过MSS)发送出去。
Nagle算法：若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方接收对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段再发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。Nagle算法还规定：当到达的数据已达到 发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。
另，糊涂窗口综合证： TCP接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取1字节（这样就使接收缓存空间仅腾出1字节），然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报为40字节的的话）。接收，发送方又发来1个字节的数据（发送方的IP数据报是41字节）。接收方发回确认，仍然将窗口设置为1个字节。这样，网络的效率很低。要解决这个问题，可让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收方缓存已有一半空闲的空间。只要出现这两种情况，接收方就发回确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据报积累成足够大的报文段，或达到接收方缓存的空间的一半大小。

TCP的拥塞控制
1. 拥塞：即对资源的需求超过了可用的资源。若网络中许多资源同时供应不足，网络的性能就要明显变坏，整个网络的吞吐量随之负荷的增大而下降。
拥塞控制：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提：网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。
流量控制：指点对点通信量的控制，是端到端正的问题。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
拥塞控制代价：需要获得网络内部流量分布的信息。在实施拥塞控制之前，还需要在结点之间交换信息和各种命令，以便选择控制的策略和实施控制。这样就产生了额外的开销。拥塞控制还需要将一些资源分配给各个用户单独使用，使得网络资源不能更好地实现共享。
2. 几种拥塞控制方法
慢开始( slow-start )、拥塞避免( congestion avoidance )、快重传( fast retransmit )和快恢复( fast recovery )。
2.1 慢开始和拥塞避免
发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
慢开始算法：当主机开始发送数据时，如果立即所大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。

每经过一个传输轮次，拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过“传输轮次”更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。
另，慢开始的“慢”并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大cwnd。
为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量（如何设置ssthresh）。慢开始门限ssthresh的用法如下：
当 cwnd < ssthresh 时，使用上述的慢开始算法。
当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。
拥塞避免算法：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
如下图，用具体数值说明了上述拥塞控制的过程。现在发送窗口的大小和拥塞窗口一样大。

<1>. 当TCP连接进行初始化时，把拥塞窗口cwnd置为1。前面已说过，为了便于理解，图中的窗口单位不使用字节而使用报文段的个数。慢开始门限的初始值设置为16个报文段，即 cwnd = 16 。
<2>. 在执行慢开始算法时，拥塞窗口 cwnd 的初始值为1。以后发送方每收到一个对新报文段的确认ACK，就把拥塞窗口值另1，然后开始下一轮的传输（图中横坐标为传输轮次）。因此拥塞窗口cwnd随着传输轮次按指数规律增长。当拥塞窗口cwnd增长到慢开始门限值ssthresh时（即当cwnd=16时），就改为执行拥塞控制算法，拥塞窗口按线性规律增长。
<3>. 假定拥塞窗口的数值增长到24时，网络出现超时（这很可能就是网络发生拥塞了）。更新后的ssthresh值变为12（即变为出现超时时的拥塞窗口数值24的一半），拥塞窗口再重新设置为1，并执行慢开始算法。当cwnd=ssthresh=12时改为执行拥塞避免算法，拥塞窗口按线性规律增长，每经过一个往返时间增加一个MSS的大小。
强调：“拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。“拥塞避免”是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

3. 什么叫做cache的写命中和写未命中，有什么区别可以通俗解释吗

1、cache的写命中和写未命中，就是磁盘或者内存上的存储区域之前有没有写过数据。

如果有，这次再写到相同的区域叫写命中；

如果写到其他区域，叫写未命中。

2、在数据恢复方面，如果写命中了，那之前的数据被覆盖，就很难再恢复回来；

如果写未命中，那么之前的数据就容易被找回。

(3)未使用强缓存只用协商缓存有效吗扩展阅读：

缓存命中率

终端用户访问加速节点时，如果该节点有缓存住了要被访问的数据时就叫做命中，如果没有的话需要回原服务器取，就是没有命中。取数据的过程与用户访问是同步进行的，所以即使是重新取的新数据，用户也不会感觉到有延时。 命中率=命中数/（命中数+没有命中数）， 缓存命中率是判断加速效果好坏的重要因素之一。

应用场景

是OLTP还是OLAP应用，即使是OLTP，也要看访问的频度，一个极少被访问到的缓存等于没有什么效果。一般来说，互联网网站是非常适合缓存应用的场景。

缓存的粒度

毫无疑问，缓存的粒度越小，命中率就越高，对象缓存是目前缓存粒度最小的，因此被命中的几率更高。

举个例子来说吧：你访问当前这个页面，浏览帖子，那么对于ORM来说，需要发送n条SQL，取各自帖子user的对象。很显然，如果这个user在其他帖子里面也跟贴了，那么在访问那个帖子的时候，就可以直接从缓存里面取这个user对象了。

缓存的容量

缓存太小，造成频繁的LRU，也会降低命中率，缓存的有效期太短也会造成缓存命中率下降。

所以缓存命中率问题不能一概而论，一定说命中率很低或者命中率很高。但是如果你对于缓存的掌握很精通，有意识的去调整应用的架构，去分解缓存的粒度，总是会带来很高的命中率的。

4. 浏览器缓存的清理方法

常用浏览器的清理方法：

网络浏览器

1.双击打开网络浏览器。

5. nginx如何设置不使用缓存

在开发调试web的时候，经常会碰到因浏览器缓存(cache)而经常要去清空缓存或者强制刷新来测试的烦恼，提供下apache不缓存配置和nginx不缓存配置的设置。

apache：
首先确定配置文件httpd.conf中确已经加载mod_headers模块。

LoadMole headers_mole moles/mod_headers.so

我们可以根据文件类型来让浏览器每次都从服务器读取，这里测试用css、js、swf、php、html、htm这几种文件。
<FilesMatch “\.(css|js|swf|php|htm|html)$”>
Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
Header set Pragma "no-cache"
</FilesMatch>

nginx:

location ~ .*\.(css|js|swf|php|htm|html )$ {
add_header Cache-Control no-store;
}

对于站点中不经常修改的静态内容（如图片，JS，CSS），可以在服务器中设置expires过期时间，控制浏览器缓存，达到有效减小带宽流量，降低服务器压力的目的。

以Nginx服务器为例：
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
#过期时间为30天，
#图片文件不怎么更新，过期可以设大一点，
#如果频繁更新，则可以设置得小一点。
expires 30d;
}

location ~ .*\.(js|css)$ {
expires 10d;
}

6. 服务器的ssl会话缓存 可以被刷新吗

为什么在服务器负载非常重的时候会出现随机性的SSL协议错误?
可能有多种原因，但是最可能的原因是由于将SSLSessionCache指定为使用DBM会话缓存所致。因此，使用SHM会话缓存或者根本不使用SSL会话缓存有助于解决这个问题。
为什么服务器在处理SSL加密连接的时候负载会很重?
SSL使用的强加密算法需要消耗大量CPU资源进行大数运算。当你通过HTTPS访问一个页面时，每一个元素(包括图片和多媒体资源)都会被加密传输。所以，HTTPS流量越大，负载就会越重。
为什么在使用HTTPS协议的情况下，有时候需要花上30秒才能建立一个连接?
这通常是由于在使用read(2)读取SSLRandomSeed指定的/dev/random设备时，设备暂时无法提供足够多的随机位，操作被一直阻塞所致。更多细节可以参考手册中对SSLRandomSeed指令的详细说明。
mod_ssl支持哪些SSL加密算法?
通常，所有OpenSSL支持的SSL加密算法mod_ssl都支持，具体取决于你的OpenSSL是怎样编译的。可以使用下面的命令列出实际究竟可以使用哪些加密算法：
$ openssl ciphers -v
为什么使用匿名Diffie-Hellman(ADH)算法时会收到"no shared cipher"错误?
默认情况下，出于安全原因，OpenSSL并不启用ADH算法。仅在你确实明白了这个算法的副作用时，你才可以启用此算法。
为了使用匿名Diffie-Hellman(ADH)算法，你必须在编译OpenSSL时使用"-DSSL_ALLOW_ADH"配置选项，并在SSLCipherSuite指令中添加"ADH"。
为什么连接到新安装的Apache-SSL服务器时会收到"no shared ciphers"错误?
或者是SSLCipherSuite指令配置错误(你可以和预配置的httpd.conf-dist比 对一下)；或者是你在生成私钥的时候使用了DSA/DH算法而不是RSA，并且忽略了警告信息。如果使用了DSA/DH的话，那么你的服务器就不能使用基 于RSA的SSL加密算法进行通信(至少直到你配置了一个额外的RSA证书/密钥对为止)。现在的浏览器，比如NS或IE只能和使用RSA加密算法的 SSL服务器通信，这也是导致"no shared ciphers"错误原因之一。解决这个错误的最佳途径就是使用RSA算法重新生成服务器证书和密钥对。
为什么不能在基于域名的虚拟主机上使用SSL?
原因很技术化，有点类似于"鸡和蛋"的问题。SSL协议层位于HTTP协议层之下，HTTP协议是被封装在SSL协议中的，当一个SSL连接 (HTTPS)请求到来的时候，Apache/mod_ssl必须和客户端协商SSL协议参数(握手)，所以，mod_ssl必须查看虚拟主机的配置信息 (例如允许使用哪些加密算法、服务器证书是哪个等等)，然后才能完成SSL会话通道的建立；但另一方面，为了确切知道究竟应该查看哪个虚拟主 机，Apache又必须知道HTTP请求头的Host字段的内容，而这在完成SSL握手之前是不可能知道的。
为什么不可以使用基于域名的虚拟主机来标识不同的SSL虚拟主机?
基于域名的虚拟主机是用来标识不同虚拟主机的流行方法。这种方法允许多个不同的站点使用同一个IP地址和端口对。当人们将站点转移到SSL时，很自然的就认为可以使同相同的办法在同一台机器上运行多个SSL虚拟主机。
但事实是：没门！
原因在于SSL协议层位于HTTP协议层之下，HTTP协议是被封装在SSL协议中的，所以SSL会话必须在HTTP会话之前建立。因为在建立SSL会话的最初握手阶段，服务器无法知道HTTP请求头的Host字段的内容，也就无法确定究竟使用哪个虚拟主机的配置(例如允许使用哪些加密算法、服务器证书是哪个等等)，于是Apache就会使用匹配这个IP地址端口对的第一个主机的SSL配置。
当然，你也可以在同一个IP地址上使用基于域名的虚拟主机来标识多个非SSL虚拟主机(例如全运行在80端口)，同时再运行一个SSL虚拟主机(例如在443端口)。不过如果你确实这么做了的话，一定要确保在NameVirtualHost指令里明确指定端口号，像这样：
NameVirtualHost 192.168.1.1:80
另外一个解决方案：为不同的SSL虚拟主机使用不同的IP地址端口对。
如何启用SSL压缩?
虽然SSLv2和TLS规范定义了SSL压缩协商，但是直到2004年5月，RFC 3749才将DEFLATE定义为可协商的压缩方法。
从0.9.8版本开始，如果编译时使用了zlib选项，那么OpenSSL将默认支持SSL压缩。如果客户端和服务器同 时支持压缩，那么压缩将被启用。但是，当前的大多数客户端仍然会在建立SSL会话的最初尝试使用SSLv2，而SSLv2在握手阶段并不协商压缩算法，所 以对于使用SSLv2的客户端，实际上是无法使用压缩的。如果客户端使用SSLv3或TLS建立连接，那么就可以启用压缩。你可以使用%{SSL_COMPRESS_METHOD}x变量在日志中记录客户端是否利用了压缩功能。
当我通过HTTPS使用基本认证的时候，Netscape浏览器状态栏上的锁图标处于打开状态，这是否意味着我的用户名和密码是明文传递的?
非也！你的用户名和密码依然是加密传输的。浏览器上的图标事实上并没有和SSL/TLS同步，它仅在开始实际传输web页面的时候才锁上，这会给用 户带来一些困惑。基本认证是HTTP层的特性，而HTTP层位于SSL层之上(所以被称为HTTPS)，所以任何HTTP会话开始之前，SSL层已经完成 握手并建立了加密信道。所以不要被这个图标所迷惑。

7. Http状态码是什么。都有哪些什么意思请详细的说下

HTTP状态码（HTTP Status Code）是用以表示网页服务器HTTP响应状态的3位数字代码。它由 RFC 2616 规范定义的，并得到RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918等规范扩展。

HTTP状态码全部以及代表的意思：

100 客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。

101 服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。 只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。
102 由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。
200 请求已成功，请求所希望的响应头或数据体将随此响应返回。
201 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话，应当返回 '202 Accepted'。
202 服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。 返回202状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。
203 服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如，包含资源的元数据可能导致原始服务器知道元信息的超级。使用此状态码不是必须的，而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。
204 服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。如果存在这些头部信息，则应当与所请求的变量相呼应。 如果客户端是浏览器的话，那么用户浏览器应保留发送了该请求的页面，而不产生任何文档视图上的变化，即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。 由于204响应被禁止包含任何消息体，因此它始终以消息头后的第一个空行结尾。
205 服务器成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后，立即重置表单，以便用户能够轻松地开始另一次输入。 与204响应一样，该响应也被禁止包含任何消息体，且以消息头后的第一个空行结束。
206 服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。 该请求必须包含 Range 头信息来指示客户端希望得到的内容范围，并且可能包含 If-Range 来作为请求条件。 响应必须包含如下的头部域： Content-Range 用以指示本次响应中返回的内容的范围；如果是 Content-Type 为 multipart/byteranges 的多段下载，则每一 multipart 段中都应包含 Content-Range 域用以指示本段的内容范围。假如响应中包含 Content-Length，那么它的数值必须匹配它返回的内容范围的真实字节数。 Date ETag 和/或 Content-Location，假如同样的请求本应该返回200响应。 Expires, Cache-Control，和/或 Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。 假如本响应请求使用了 If-Range 强缓存验证，那么本次响应不应该包含其他实体头；假如本响应的请求使用了 If-Range 弱缓存验证，那么本次响应禁止包含其他实体头；这避免了缓存的实体内容和更新了的实体头信息之间的不一致。否则，本响应就应当包含所有本应该返回200响应中应当返回的所有实体头部域。 假如 ETag 或 Last-Modified 头部不能精确匹配的话，则客户端缓存应禁止将206响应返回的内容与之前任何缓存过的内容组合在一起。 任何不支持 Range 以及 Content-Range 头的缓存都禁止缓存206响应返回的内容。
207 由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。
300 被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。 除非这是一个 HEAD 请求，否则该响应应当包括一个资源特性及地址的列表的实体，以便用户或浏览器从中选择最合适的重定向地址。这个实体的格式由 Content-Type 定义的格式所决定。浏览器可能根据响应的格式以及浏览器自身能力，自动作出最合适的选择。当然，RFC 2616规范并没有规定这样的自动选择该如何进行。 如果服务器本身已经有了首选的回馈选择，那么在 Location 中应当指明这个回馈的 URI；浏览器可能会将这个 Location 值作为自动重定向的地址。此外，除非额外指定，否则这个响应也是可缓存的。
301 被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。 新的永久性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。 如果这不是一个 GET 或者 HEAD 请求，因此浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。 注意：对于某些使用 HTTP/1.0 协议的浏览器，当它们发送的 POST 请求得到了一个301响应的话，接下来的重定向请求将会变成 GET 方式。
302 请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。 新的临时性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。 如果这不是一个 GET 或者 HEAD 请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。 注意：虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法，但是很多现存的浏览器将302响应视作为303响应，并且使用 GET 方式访问在 Location 中规定的 URI，而无视原先请求的方法。状态码303和307被添加了进来，用以明确服务器期待客户端进行何种反应。
303 对应当前请求的响应可以在另一个 URI 上被找到，而且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的 URI 不是原始资源的替代引用。同时，303响应禁止被缓存。当然，第二个请求（重定向）可能被缓存。 新的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。 注意：许多 HTTP/1.1 版以前的 浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动，302状态码应该可以胜任，因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。
304 如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。 该响应必须包含以下的头信息： Date，除非这个服务器没有时钟。假如没有时钟的服务器也遵守这些规则，那么代理服务器以及客户端可以自行将 Date 字段添加到接收到的响应头中去（正如RFC 2068中规定的一样），缓存机制将会正常工作。 ETag 和/或 Content-Location，假如同样的请求本应返回200响应。 Expires, Cache-Control，和/或Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。 假如本响应请求使用了强缓存验证，那么本次响应不应该包含其他实体头；否则（例如，某个带条件的 GET 请求使用了弱缓存验证），本次响应禁止包含其他实体头；这避免了缓存了的实体内容和更新了的实体头信息之间的不一致。 假如某个304响应指明了当前某个实体没有缓存，那么缓存系统必须忽视这个响应，并且重复发送不包含限制条件的请求。 假如接收到一个要求更新某个缓存条目的304响应，那么缓存系统必须更新整个条目以反映所有在响应中被更新的字段的值。
305 被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息，接收者需要重复发送一个单独的请求，通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。 注意：RFC 2068中没有明确305响应是为了重定向一个单独的请求，而且只能被原始服务器建立。忽视这些限制可能导致严重的安全后果。
306 在最新版的规范中，306状态码已经不再被使用。
307 请求的资源现在临时从不同的URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。 新的临时性的URI 应当在响应的 Location 域中返回。除非这是一个HEAD 请求，否则响应的实体中应当包含指向新的URI 的超链接及简短说明。因为部分浏览器不能识别307响应，因此需要添加上述必要信息以便用户能够理解并向新的 URI 发出访问请求。 如果这不是一个GET 或者 HEAD 请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。
400 1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。 2、请求参数有误。
401 当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。
402 该状态码是为了将来可能的需求而预留的。
403 服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应，假如它不希望让客户端获得任何信息。
404 请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。
405 请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。 鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。
406 请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。 除非这是一个 HEAD 请求，否则该响应就应当返回一个包含可以让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由 Content-Type 头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是，规范中并没有定义任何作出此类自动选择的标准。
407 与401响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。参见RFC 2617。
408 请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。
409 由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。 冲突通常发生于对 PUT 请求的处理中。例如，在采用版本检查的环境下，某次 PUT 提交的对特定资源的修改请求所附带的版本信息与之前的某个（第三方）请求向冲突，那么此时服务器就应该返回一个409错误，告知用户请求无法完成。此时，响应实体中很可能会包含两个冲突版本之间的差异比较，以便用户重新提交归并以后的新版本。
410 被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的，那么就应该使用404状态码。除非额外说明，否则这个响应是可缓存的。 410响应的目的主要是帮助网站管理员维护网站，通知用户该资源已经不再可用，并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样，410响应也被用于通知客户端在当前服务器站点上，原本属于某个个人的资源已经不再可用。当然，是否需要把所有永久不可用的资源标记为'410 Gone'，以及是否需要保持此标记多长时间，完全取决于服务器拥有者。
411 服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后，客户端可以再次提交该请求。
412 服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。
413 服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。 如果这个状况是临时的，服务器应当返回一个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。
414 请求的URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。这比较少见，通常的情况包括： 本应使用POST方法的表单提交变成了GET方法，导致查询字符串（Query String）过长。 重定向URI “黑洞”，例如每次重定向把旧的 URI 作为新的 URI 的一部分，导致在若干次重定向后 URI 超长。 客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操作请求的 URI，当 GET 后的参数超过某个数值后，可能会产生缓冲区溢出，导致任意代码被执行[1]。没有此类漏洞的服务器，应当返回414状态码。
415 对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。
416 如果请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回416状态码。 假如 Range 使用的是字节范围，那么这种情况就是指请求指定的所有数据范围的首字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时，包含一个 Content-Range 实体头，用以指明当前资源的长度。这个响应也被禁止使用 multipart/byteranges 作为其 Content-Type。
417 在请求头 Expect 中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect 的内容无法被满足。
421 从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。
422 从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。
422 请求格式正确，但是由于含有语义错误，无法响应。（RFC 4918 WebDAV）423 Locked 当前资源被锁定。（RFC 4918 WebDAV）
424 由于之前的某个请求发生的错误，导致当前请求失败，例如 PROPPATCH。（RFC 4918 WebDAV）
425 在WebDav Advanced Collections 草案中定义，但是未出现在《WebDAV 顺序集协议》（RFC 3658）中。
426 客户端应当切换到TLS/1.0。（RFC 2817）
449 由微软扩展，代表请求应当在执行完适当的操作后进行重试。
500 服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现。
501 服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。
502 作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
503 由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息，那么客户端应当以处理500响应的方式处理它。 注意：503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。
504 作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。 注意：某些代理服务器在DNS查询超时时会返回400或者500错误
505 服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。
506 由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用自己，因此在一个协商处理中不是一个合适的重点。
507 服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918)
509 服务器达到带宽限制。这不是一个官方的状态码，但是仍被广泛使用。
510 获取资源所需要的策略并没有没满足。（RFC 2774）

8. XP蓝屏的原因

蓝屏故障和其它故障一样，根据成因大致可以分为软件和硬件两个方面。现在还是遵循先软后硬的原则来看看故障的成因和解决办法吧！
一、软件引起的蓝屏故障
1．重要文件损坏或丢失引起的蓝屏故障(包括病毒所致)。
实例：Win98中的VxD(虚拟设备驱动程序)或是．DLL�动态连接库之类的重要文件丢失，情况一般会比较严重，会出现“蓝屏警告”。
解决方法一：记下所丢失或损坏的文件名�用Win98启动盘中的“Ext”命令从Win98安装盘中提取和恢复被损坏或丢失的文件，步骤如下：
(1)用Win98启动盘引导计算机，在提示符下敲入“Ext”命令。
(2)在提示“Please enter the path to the Windows CAB files( a)：”后输入Win98安装压缩包所在的完整路径，如“F�＼Pwin98＼Win98”，完成后回车。
(3)在提示“Please enter the name(s)of the file(s) you want to extract：”后输入你记下的丢失文件名，如“Bios．Vxd”，回车。
(4)在解压路径提示“Please enter path to extract to(‘Enter’ for current directory)：”后输入文件将被解压到的完整路径，如“C� ＼Windows＼System”并敲回车。
(5)最后出现确认提示“Is this Ok？(y/n)：”，输入“y”后回车。“Ext”程序会自动查找安装盘中的CAB压缩包，并将文件释放到指定的位置。
(6)重新启动即可。
解决方法二：用杀毒软件杀毒。有的病毒可能会破坏注册表项�杀毒后注册表应恢复中毒之前的备份。
解决方法三：如果能启动图形界面，可以采取重装主板以及显卡的驱动程序，和进行“系统文件扫描”来恢复被破坏或丢失的文件。“系统文件扫描”的方法为�单击“开始/程序/附件/系统工具/系统信息/工具/系统文件检查器”，然后扫描改动过的文件即可。
2．注册表损坏导致文件指向错误所引起的蓝屏。
实例：注册表的擅自改动(包括人为地改动和软件安装时的自动替换)�其现象表现为开机或是在调用程序时出现蓝屏，并且屏幕有出错信息显示(包含出错的文件名)。
解决方法一：恢复备份。
(1)单击“开始/关机/重新启动计算机并切换到MS-DOS方式”，然后单击“是”；
(2)进入Windows目录下。例如，如果你的Windows安装在“C�＼Windows” 目录下，应键入以下内容�“CD C�＼WINDOWS”后回车；
(3)键入“SCANREG＼RESTORE”后回车。
(4)按照上述步骤，可以将注册表恢复到最近一次启动计算机时的状态。
解决方法二：删除键值。
如果是在卸载程序后出现蓝屏的话，笔者断定故障是由于程序卸载不完善造成的。解决这类问题非常简单，首先你要记下出错的文件名，然后再到注册表中找到以下分支“HKEY＿LOCAL＿MACHINE＼System
＼CurrentControlSet＼Services＼VxD”。在“查找”中输入刚才的文件名，把查到的键值删除即可。此时，千万不要忘记备份注册表哦！
典型案例：笔者在删除金山毒霸时中途死机，重新启动后刚看到桌面的图标就出现蓝屏，并伴有错误信息出现。错误信息中提到Kavkrnl．vxd文件找不到，笔者首先根据文件名的前两个字符确定该文件不是Win98的系统文件，ka开头的应是金山毒霸的虚拟设备驱动程序。基本判断为文件指向错误，于是决定删除它在注册表中相应键值。在注册表编辑器的查找中输入“Kavkrnl．vxd”，将它在“HKEY＿LOCAL＿
MACHINE＼System＼CurrentControlSet＼Services＼VxD”中的相应主键值删除，重启后故障消除。
3．System．ini 文件错误引起的“蓝屏”。
实例：软件卸载或是安装后未即时更新System．ini 文件所造成的错误。
解决方法：禁用注册表中该项或是重新安装相应的软件或驱动程序。
4．Win98自身的不完善造成的蓝屏。
实例：Win98的sp1和Microsoft的Vxd＿fix．exe补丁程序对Win98的稳定性起着至关重要的作用。
解决方法：快去下载吧，如华军网站南京站http�//nj．onlinedown．net/Win98SP1．htm�Win98sp1及http�//nj．onlinedown．net/Windows98VxDpatch．htm� Vxd＿fix．exe。
5．系统资源耗尽引起的蓝屏故障。
实例：蓝屏故障常常发生在进行一项比较大的工作时，或是在保存复制的时候，且往往发生得比较突然。这类故障的发生原因主要是与三个堆资源(系统资源、用户资源、GDI资源)的占用情况有关。
解决方法：打开你的资源状况监视器，看一下剩余资源，如果你的三种资源都在50%甚至更低，就很容易出现诸如“非法操作”、“蓝屏”或“死机”故障。为此，必须减少资源浪费，减少不必要的程序加载，避免同时运行大程序(图形、声音和视频软件)，例如加载计划任务程序，输入法和声音指示器，声卡的DOS驱动程序，系统监视器程序等等。
6．DirectX问题引起的蓝屏故障。
实例：(1)DirectX版本过低或是过高；(2)游戏与它不兼容或是不支持；(3)辅助重要文件丢失；(4)显卡对它不支持。
解决方法：升级或是重装DirectX。如果是显卡不支持高版本的DirectX那就说明你的显卡实在是太老了，尝试更新显卡的BIOS和驱动程序，否则，只好花钱升级显卡了。
二、硬件引起的蓝屏故障
1．内存超频或不稳定造成的蓝屏。
实例：随机性蓝屏。
解决方法：先用正常频率运行，若还有问题。找一根好的内存条进行故障的替换查找，一般可以解决。再就是应当注意当CPU离内存很近时内存的散热问题。
2．硬件的兼容性不好引起的蓝屏。
兼容机好就好在它的性价比较高，坏就坏在它在进行组装的时候，由于用户没有完善的监测手段和相应的知识，无法进行一系列的兼容性测试，从而把隐患留在了以后的使用过程中。
实例：升级内存时，将不同规格的内存条混插引起的故障。
解决方法：注意内存条的生产厂家、内存颗粒和批号的差异，往往就是因为各内存条在主要参数上的不同而产生了蓝屏或死机，甚至更严重的内存故障。也可以换一下内存条所插的插槽位置。如果内存条还是不能正常工作，那就只好更换了。此处，提醒各位：内存在整个微机系统中起着非常重要的作用，它的好坏将直接影响到系统的稳定性，所以在内存的选购时要注意，最好是有内行人陪伴，避免买到Remark过的条子或频率过低的条子。
3．硬件散热引起的“蓝屏”故障。
实例：在微机的散热问题上所出现的故障，往往都有一定规律，一般在微机运行一段时间后才出现，表现为蓝屏死机或随意重启。故障原因主要是过热引起的数据读取和传输错误。
解决方法：采取超频的应降频，超温的应降温。其实不一定所有的故障都那么复杂，有时候从简单的方面考虑，也能很好地解决问题�要学会触类旁通。
4．I/O冲突引起的蓝屏现象。
解决方法：这种现象出现得比较少，如果出现了，可以从系统中删除带！号或？号的设备名，重新启动计算机进行确认，或者请高手手动分配系统资源。
凡事要防患于未然，下面是笔者总结出来的一些经验，可供大家参考：
1定期对重要的注册表文件进行手工备份，避免系统出错后，未能及时替换成备份文件而产生不可挽回的错误。
2尽量避免非正常关机，减少重要文件的丢失。如．VxD ．DLL文件等。
3对普通用户而言，只要能正常运行，没有必要去升级显卡、主板的BIOS和驱动程序，避免升级造成的危害。
4定期检查优化系统文件，运行“系统文件检查器”进行文件丢失检查及版本校对。检查步骤参见前面相关介绍。
5减少无用软件的安装，尽量不用手工卸载或删除程序，以减少非法替换文件和文件指向错误的出现。
6如果不是内存特别大和其管理程序非常优秀，尽量避免大程序的同时运行，如果你发现在听MP3时有沙沙拉拉的声音，基本可以判定该故障是由内存不足而造成的。

9. web前端有哪些性能优

一，关键资源字节数

字节数也就是我通常说的减少资源文件（js,css,image,video...）的大小

1，压缩

• 前端使用uglify混淆压缩

• 后端开启gzip

• 对图片进行压缩，使用压缩比例更高的格式（webP）

2，缓存

• 强缓存（http状态码：200），不用请求服务器直接使用本地缓存

• 协商缓存（http状态码：304），使用时先请求服务器若被告知缓存没过期则使用本地缓存，不用下载资源

• 使用localstorage对数据进行存储

3，针对首屏优化

对非关键资源延迟加载、异步加载，减少首屏资源大小

二，关键资源连接数

1，合并请求

• 使用http2.0的多路复用合并请求

• 配置combo，在无法使用http2.0的情况下作为一种合并资源请求的手段

2，减少图片请求数

• 使用spite图

• 使用svg-symbol

3，针对一些场景采用css、js内联的方式

4，使用强缓存减少了一次服务器请求

5，非关键资源延迟、异步加载，减少了首屏资源连接数

三，关键渲染路径

网上有张关于页面渲染路径的图，这里我就不放了，大家有兴趣自己网络下

1，bigpipe分块输出

这里主要是因为要完成一整个页面的输出后端需要处理很多个任务，我们可以将这些多个任务进行分块，谁先完成谁就先输出，最终通过JS回填的方式输出DOM节点。这种方式主要解决了直出页面阻塞的问题

2，bigrender分块渲染

常规的手段就是采用前端模板渲染页面，针对首屏时间主要减少了首次构建DOM树时的节点数

3，针对reflow，repaint，composit路径处理

4，涉及到动画时关于layer的概念render layer、graphics layer

5，css放在头部、js放底部避免阻塞DOM树的构建，

关于css、js的位置对于页面渲染的影响大家可以关注下相关的文章。
核心：css资源不会阻塞DOM树的构建但会阻塞DOM的渲染，JS会阻塞DOM树的构建，CSS会阻塞JS的执行