浏览器协议
get和POST的区别
1.get数据是存放在url之后，以？分割url和传输数据，参数之间以&相连； post方法是把提交的数据放在http包的Body中 2.get提交的数据大小有限制，（因为浏览器对url的长度有限制），post的方法提交的数据没有限制 3.get需要request.queryString来获取变量的值，而post方式通过request.from来获取变量的值 4.get的方法提交数据，会带来安全问题，比如登录一个页面，通过get的方式提交数据，用户名和密码就会出现在url上
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通过一个定时器（timer）采样了RTT并计算RTO，但是，如果网络上的延时突然增加，那么，TCP对这个事做出的应对只有重传数据，
然而重传会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这就导致了恶性循环，最终形成“网络风暴” —— TCP的拥塞控制机制就是用于应对这种情况。
首先需要了解一个概念，为了在发送端调节所要发送的数据量，定义了一个“拥塞窗口”（Congestion Window），
在发送数据时，将拥塞窗口的大小与接收端ack的窗口大小做比较，取较小者作为发送数据量的上限。
拥塞控制的算法是什么
拥塞控制主要是四个算法： //1.慢启动：意思是刚刚加入网络的连接，一点一点地提速，不要一上来就把路占满。 连接建好的开始先初始化cwnd = 1，表明可以传一个MSS大小的数据。 每当收到一个ACK，cwnd++; 呈线性上升 每当过了一个RTT，cwnd = cwnd*2; 呈指数让升 阈值ssthresh（slow start threshold），是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法”
//2.拥塞避免：当拥塞窗口 cwnd 达到一个阈值时，窗口大小不再呈指数上升，而是以线性上升，避免增长过快导致网络拥塞。 每当收到一个ACK，cwnd = cwnd + 1/cwnd 每当过了一个RTT，cwnd = cwnd + 1 拥塞发生：当发生丢包进行数据包重传时，表示网络已经拥塞。分两种情况进行处理： 等到RTO超时，重传数据包 sshthresh = cwnd /2 cwnd 重置为 1
//3.进入慢启动过程 在收到3个duplicate ACK时就开启重传，而不用等到RTO超时 sshthresh = cwnd = cwnd /2 进入快速恢复算法——Fast Recovery
//4.快速恢复：至少收到了3个Duplicated Acks，说明网络也不那么糟糕，可以快速恢复。 cwnd = sshthresh + 3 * MSS （3的意思是确认有3个数据包被收到了） 重传Duplicated ACKs指定的数据包 如果再收到 duplicated Acks，那么cwnd = cwnd +1 如果收到了新的Ack，那么，cwnd = sshthresh ，然后就进入了拥塞避免的算法了。
同步和异步的区别
其实同步和异步， 无论如何，做事情的时候都是只有一条流水线（单线程）， //同步和异步的差别就在于这条流水线上各个流程的执行顺序不同。 同步任务，只有前一个任务执行完毕，才能执行后一个任务； 异步任务指的是，不进入主线程、而进入"任务队列"（task queue）的任务， 只有等主线程任务执行完毕，"任务队列"开始通知主线程，请求执行任务，该任务才会进入主线程执行。
阻塞和非阻塞的区别
总结：同步、异步:只是对于热水壶。普通水壶代表同步；响水壶代表异步。虽然都能干活，但响水壶可以在自己完工之后，提示小杨水开了。 阻塞、非阻塞：仅仅代表小杨，立等的属于阻塞（1，3）；干别的事了属于非阻塞（2，4）。 所以在上述同步阻塞、同步非阻塞、异步阻塞、异步非阻塞中，异步非阻塞情况下效率较高。
OSI七层模型
TCP三次握手
HTTP协议是使用TCP协议作为其传输层协议的，在拿到服务器的IP地址后，浏览器客户端会与服务器建立TCP连接。该过程包括三次握手：
- 第一次握手：建立连接时，客户端向服务端发送请求报文
- 第二次握手：服务器收到请求报文后，如同意连接，则向客户端发送确认报文
- 第三次握手，客户端收到服务器的确认后，再次向服务器给出确认报文，完成连接。
三次握手主要是为了防止已经失效的请求报文字段发送给服务器，浪费资源。
详细版
SYN （同步序列编号）ACK（确认字符）
- 第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
- 第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
- 第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
TCP四次挥手
客户端与服务器四次挥手，断开tcp连接。
- 第一次挥手：客户端想分手，发送消息给服务器
- 第二次挥手：服务器通知客户端已经接受到分手请求，但还没做好分手准备
- 第三次回收：服务器已经做好分手准备，通知客户端
- 第四次挥手：客户端发送消息给服务器，确定分手，服务器关闭连接
详细版：
- 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
- 第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
- 第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
- 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，
所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。
http和https的区别
http传输的数据都是未加密的，也就是明文的，网景公司设置了SSL协议来对http协议传输的数据进行加密处理，
简单来说https协议是由http和ssl协议构建的可进行加密传输和身份认证的网络协议，比http协议的安全性更高。
主要的区别如下：
- Https协议需要ca证书，费用较高。
- http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
- 使用不同的链接方式，端口也不同，一般而言，http协议的端口为80，https的端口为443
http协议的理解说一下
1.超文本的传输协议，是用于从万维网服务器超文本传输到本地资源的传输协议 2.基于TCP/IP通信协议来传递数据（HTML，图片资源） 3.基于运用层的面向对象的协议，由于其简洁、快速的方法、适用于分布式超媒体信息系统 4.http请求信息request： 请求行（request line）、请求头部（header）,空行和请求数据四部分构成 请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本. 请求头部，用来说明服务器要使用的附加信息 空行，请求头部后面的空行是必须的 请求数据也叫主体，可以添加任意的其他数据。 5.http相应信息Response 状态行、消息报头、空行和响应正文 状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成 消息报头，用来说明客户端要使用的一些附加信息 空行，消息报头后面的空行是必须的 响应正文，服务器返回给客户端的文本信息。
https协议的工作原理
客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤，如图所示。
- 客户使用https url访问服务器，则要求web 服务器建立ssl链接。
- web服务器接收到客户端的请求之后，会将网站的证书（证书中包含了公钥），返回或者说传输给客户端。
- 客户端和web服务器端开始协商SSL链接的安全等级，也就是加密等级。
- 客户端浏览器通过双方协商一致的安全等级，建立会话密钥，然后通过网站的公钥来加密会话密钥，并传送给网站。
- web服务器通过自己的私钥解密出会话密钥。
- web服务器通过会话密钥加密与客户端之间的通信。
http请求无状态怎么解释？
正文：http协议无状态中的【状态】到底指的是什么？！
先来看这句话的另外两个概念：（标准的http协议是无状态的，无连接的）
标准的http协议指的是不包括cookies, session，application的http协议，他们都不属于标准协议，虽然各种网络应用提供商，实现语言、web容器等，都默认支持它
无连接指的是什么
每一个访问都是无连接，服务器挨个处理访问队列里的访问，处理完一个就关闭连接，这事儿就完了，然后处理下一个新的
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接
对于【无状态】，我看到很多隔着一层磨砂玻璃一样的模糊说法（官方或者教程里的说法），看着非常难受（但其实算是对的）
（后来我发现我为什么觉得它看着难受了，因为他们引入了很多新的，而且明显是一个可能用在很多地方的广义名词，这些词最大的作用就是，混淆概念，下面我标注了）
协议对于事务处理没有记忆能力【事物处理】【记忆能力】
对同一个url请求没有上下文关系【上下文关系】
每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求是无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况【无直接联系】【受直接影响】
服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器【状态】
https协议的优缺点
//优点 使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器； HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。 HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。 谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。 //缺点 https握手阶段比较费时，会使页面加载时间延长50%，增加10%~20%的耗电。 https缓存不如http高效，会增加数据开销。 SSL证书也需要钱，功能越强大的证书费用越高。 SSL证书需要绑定IP，不能再同一个ip上绑定多个域名，ipv4资源支持不了这种消耗。
htpp1.0与1.1和2.0的区别
//http1.1相比1.0有如下几点不同： 1.默认支持长连接; 2.带宽优化，并支持断点续传； 3.新增例如ETag，If-None-Match等更多的缓存控制策略; 4.Host头域; 5.新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除； //http2.0与1.1相比有如下几点不同： 1.多路复用，可以做到在一个连接并行的处理多个请求； 2.header压缩； 3.服务端推送； 4.解析格式不同。HTTP1.0和1.1的解析是基于文本，2.0的协议解析采用二进制格式，实现方便且健壮；
http2.0说一下
首先补充一下，http和https的区别，相比于http,https是基于ssl加密的http协议 简要概括：http2.0是基于1999年发布的http1.0之后的首次更新。 1、提升访问速度（可以对于，请求资源所需时间更少，访问速度更快，相比http1.0） 2、允许多路复用：多路复用允许同时通过单一的HTTP/2连接发送多重请求-响应信息。
改善了：在http1.1中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制（连接数量），超过限制会被阻塞。 3、二进制分帧：HTTP2.0会将所有的传输信息分割为更小的信息或者帧，并对他们进行二进制编码 4、首部压缩 5、服务器端推送
https的加密有哪两种方式
简洁版：
1.对称加密： 加密数据和解密数据的密钥一模一样，所以对于多个有数据交换需求的个体，两两之间共同维护一把密钥，这个带来的成本基本是不可接受的。（老百姓不会啊）
2.非对称加密：加密数据的（公钥），跟解密数据的（私钥）是不一样的。
通过公钥加密的数据，只能通过私钥解开。通过私钥加密的数据，只能通过公钥解开，所以非对称加密是单项安全的。
但是公钥，公开的密钥，谁都可以查到，所以非对称加密只有公钥向私钥发的那一条是安全的（单项）
详细版：
1.对称加密：甲和乙是一对生意搭档，他们住在不同的城市。由于生意上的需要，他们经常会相互之间邮寄重要的货物。
为了保证货物的安全，他们商定制作一个保险盒（即经过算法加密），将物品放入其中。
他们打造了两把相同的钥匙（双方持有对称、相同的秘钥）分别保管，以便在收到包裹时用这个钥匙打开保险盒，以及在邮寄货物前用这把钥匙锁上保险盒。
这样看来也印证上面所说的对称加密最重要的问题在于如何将“钥匙”安全的送达并保存。 2.非对称加密：A和B两家公司，需要交流重要信息（比如交易金额发起和交易结果通知）。
A需要保证自己的发起金额准确，必须进行信息加密，B公司是实际金额的操作者（帮A公司代收代付），A使用B给的公钥加密数据，B使用自己的私钥解密执行金额交易。
这样只有和B公司合作的并持有B公司发放的公钥才能发起交易。反之，A公司也只识别自己给了公钥的B公司加密的数据。这样就是最基本的非对称加密的用法。
但是有一个新的问题是，假如同样持有B公司公钥的C公司模拟或从中修改了A公司发起数据并加密传给了B，B不知道是C伪造的执行了操作就会给A带来经济损失。
所以新的问题出现了：身份认证和信息完整性必须验证！ A：将被发送文件用SHA编码加密产生128bit的数字摘要，用自己的私用密钥对摘要再加密，这就形成了数字签名。然后将使用B公钥加密的密文和加密的摘要同时传给B。 B：用A公共密钥对数字签名解密（这里保证了只有A的身份），同时对收到的密文使用自己的私钥解密，在用SHA编码加密产生又一摘要。
将解密后的摘要和用SHA编码加密产生的又一摘要相互对比。如两者一致，则说明传送过程中信息没有被破坏或篡改过（这里保证了数据的完整性）。 至此，AB互有一对公私钥，这样就保证了信息都是对方加密的密文，别人看不了，也无法修改。
但是有一个新的问题：假如拥有B公钥的C公司偷换了A放在B公司的A的公钥，换成自己的C的公钥，然后模拟A发送信息，这样一样会让B不知道是A发起的交易！
引入新的概念：数字证书。A的公钥经过了公证，这就可以保证B使用公钥解开的数字签名肯定是A的数字签名。
CA证书了解吗？
它的密钥是公有的还是私有的？（私有的）
如果是私有的会造成什么攻击呢？（中间人攻击）
网络攻击说一下
XSS和CSRF 一、XSS：跨站脚本攻击，是一种网站应用程序的安全漏洞攻击，是代码注入的一种。常见方式是将恶意代码注入合法代码里隐藏起来，再诱发恶意代码，从而进行各种各样的非法活动。 预防： 1、使用XSS Filter 输入过滤，对用户提交的数据进行有效性验证，仅接受指定长度范围内并符合我们期望格式的的内容提交，阻止或者忽略除此外的其他任何数据。 输出转义，当需要将一个字符串输出到Web网页时，同时又不确定这个字符串中是否包括XSS特殊字符，
为了确保输出内容的完整性和正确性，输出HTML属性时可以使用HTML转义编码（HTMLEncode）进行处理，输出到<script>中，可以进行JS编码。 使用 HttpOnly Cookie 将重要的cookie标记为httponly，这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段，但是在js脚本中却不能访问这个cookie，
这样就避免了XSS攻击利用JavaScript的document.cookie获取cookie。 二、CSRF：跨站请求伪造，也称 XSRF，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。
与 XSS 相比，XSS利用的是用户对指定网站的信任，CSRF利用的是网站对用户网页浏览器的信任。 //预防：用户操作限制——验证码机制 方法：添加验证码来识别是不是用户主动去发起这个请求，由于一定强度的验证码机器无法识别，因此危险网站不能伪造一个完整的请求。 优点：简单粗暴，低成本，可靠，能防范99.99%的攻击者。 缺点：对用户不友好。 请求来源限制——验证 HTTP Referer 字段 //方法：在HTTP请求头中有一个字段叫Referer，它记录了请求的来源地址。 服务器需要做的是验证这个来源地址是否合法，如果是来自一些不受信任的网站，则拒绝响应。 优点：零成本，简单易实现。 缺点：由于这个方法严重依赖浏览器自身，因此安全性全看浏览器。 额外验证机制——token的使用 //方法：使用token来代替验证码验证。由于黑客并不能拿到和看到cookie里的内容，所以无法伪造一个完整的请求。基本思路如下： 服务器随机产生token（比如把cookie hash化生成），存在session中，放在cookie中或者以ajax的形式交给前端。 前端发请求的时候，解析cookie中的token，放到请求url里或者请求头中。 服务器验证token，由于黑客无法得到或者伪造token，所以能防范csrf
跨域的方式，jsonp的具体实现
1、jsonp 尽管浏览器有同源策略，但是 <script> 标签的 src 属性不会被同源策略所约束，可以获取任意服务器上的脚本并执行。
jsonp 通过插入script标签的方式来实现跨域，参数只能通过url传入，仅能支持get请求。 实现原理: //Step1: 创建 callback 方法 //Step2: 插入 script 标签 //Step3: 后台接受到请求，解析前端传过去的 callback 方法，返回该方法的调用，并且数据作为参数传入该方法 //Step4: 前端执行服务端返回的方法调用 下面代码仅为说明 jsonp 原理，项目中请使用成熟的库。分别看一下前端和服务端的简单实现： //前端代码 function jsonp({url, params, cb}) { return new Promise((resolve, reject) => { //创建script标签 let script = document.createElement('script'); //将回调函数挂在 window 上 window[cb] = function(data) { resolve(data); //代码执行后，删除插入的script标签 document.body.removeChild(script); } //回调函数加在请求地址上 params = {...params, cb} //wb=b&cb=show let arrs = []; for(let key in params) { arrs.push(`${key}=${params[key]}`); } script.src = `${url}?${arrs.join('&')}`; document.body.appendChild(script); }); } //使用 function sayHi(data) { console.log(data); } jsonp({ url: 'http://localhost:3000/say', params: { //code }, cb: 'sayHi' }).then(data => { console.log(data); }); //express启动一个后台服务 let express = require('express'); let app = express(); app.get('/say', (req, res) => { let {cb} = req.query; //获取传来的callback函数名，cb是key res.send(`${cb}('Hello!')`); }); app.listen(3000);
2、jsonp 只能支持 get 请求，cors 可以支持多种请求。cors 并不需要前端做什么工作。 简单跨域请求: 只要服务器设置的Access-Control-Allow-Origin Header和请求来源匹配，浏览器就允许跨域 请求的方法是get，head或者post。 Content-Type是application/x-www-form-urlencoded, multipart/form-data 或 text/plain中的一个值，或者不设置也可以，一般默认就是application/x-www-form-urlencoded。 请求中没有自定义的HTTP头部，如x-token。(应该是这几种头部 Accept，Accept-Language，Content-Language，Last-Event-ID，Content-Type） //简单跨域请求 app.use((req, res, next) => { res.setHeader('Access-Control-Allow-Origin', 'XXXX'); }); //带预检(Preflighted)的跨域请求 不满于简单跨域请求的，即是带预检的跨域请求。服务端需要设置 Access-Control-Allow-Origin (允许跨域资源请求的域) 、
Access-Control-Allow-Methods (允许的请求方法) 和 Access-Control-Allow-Headers (允许的请求头) app.use((req, res, next) => { res.setHeader('Access-Control-Allow-Origin', 'XXX'); res.setHeader('Access-Control-Allow-Headers', 'XXX'); //允许返回的头 res.setHeader('Access-Control-Allow-Methods', 'XXX');//允许使用put方法请求接口 res.setHeader('Access-Control-Max-Age', 6); //预检的存活时间 if(req.method === "OPTIONS") { res.end(); //如果method是OPTIONS，不做处理 } });
3、nginx 反向代理 使用nginx反向代理实现跨域，只需要修改nginx的配置即可解决跨域问题。 A网站向B网站请求某个接口时，向B网站发送一个请求，nginx根据配置文件接收这个请求，代替A网站向B网站来请求。 nginx拿到这个资源后再返回给A网站，以此来解决了跨域问题。 例如nginx的端口号为 8090，需要请求的服务器端口号为 3000。（localhost:8090 请求 localhost:3000/say） nginx配置如下: server { listen 8090; server_name localhost; location / { root /Users/liuyan35/Test/Study/CORS/1-jsonp; index index.html index.htm; } location /say { rewrite ^/say/(.*)$ /$1 break; proxy_pass http://localhost:3000; add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Credentials' 'true'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; } # others }
跨域的回调函数在调用完之后会销毁吗？
跨域的话你怎么把用户信息带到后端呢？
怎么设置cookie不让浏览器进行操作
使用 HttpOnly Cookie
将重要的cookie标记为httponly，这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段，但是在js脚本中却不能访问这个cookie，
这样就避免了XSS攻击利用JavaScript的document.cookie获取cookie。
如何让浏览器记住用户的登录状态
保存用户登录状态。例如将用户id存储于一个cookie内，这样当用户下次访问该页面时就不需要重新登录了，现在很多论坛和社区都提供这样的功能。
cookie还可以设置过期时间，当超过时间期限后，cookie就会自动消失。因此，系统往往可以提示用户保持登录状态的时间：常见选项有一个月、三个 月、一年等。
cookie如何防范XSS攻击
XSS（跨站脚本攻击）是指攻击者在返回的HTML中嵌入javascript脚本，为了减轻这些攻击，需要在HTTP头部配上，set-cookie： //httponly-这个属性可以防止XSS,它会禁止javascript脚本来访问cookie。 //secure - 这个属性告诉浏览器仅在请求为https的时候发送cookie。
cookie的作用
1、保存用户登录状态。例如将用户id存储于一个cookie内，这样当用户下次访问该页面时就不需要重新登录了，现在很多论坛和社区都提供这样的功能。
cookie还可以设置过期时间，当超过时间期限后，cookie就会自动消失。因此，系统往往可以提示用户保持登录状态的时间：常见选项有一个月、三个 月、一年等。 2、跟踪用户行为。例如一个天气预报网站，能够根据用户选择的地区显示当地的天气情况。
如果每次都需要选择所在地是烦琐的，当利用了 cookie后就会显得很人性化了，系统能够记住上一次访问的地区，当下次再打开该页面时，它就会自动显示上次用户所在地区的天气情况。
因为一切都是在后 台完成，所以这样的页面就像为某个用户所定制的一样，使用起来非常方便 3、定制页面。如果网站提供了换肤或更换布局的功能，那么可以使用cookie来记录用户的选项，例如：背景色、分辨率等。当用户下次访问时，仍然可以保存上一次访问的界面风格。
手动实现cookie的读写操作
(function(){ var cookieObj = { //修改或是添加cookie 'add': function(name, value, hours) { var expire = ""; if(hours != null){ expire = new Date((new Date()).getTime() + hours * 3600000); expire = "; expires=" + expire.toGMTString(); } document.cookie = name + "=" + escape(value) + expire + ";path=/"; //如果指定域名可以使用如下 //document.cookie = name + "=" + escape(value) + expire + ";path=/;domain=findme.wang"; }, //读取cookie 'get': function(c_name){ if (document.cookie.length>0) { c_start = document.cookie.indexOf(c_name + "="); if (c_start != -1) { c_start=c_start + c_name.length+1; c_end=document.cookie.indexOf(";",c_start); if (c_end == -1) { c_end = document.cookie.length; } return unescape(document.cookie.substring(c_start,c_end)); } } return ""; } }; window.cookieObj=cookieObj; }());
cookie、localStorage、localSession的区别
共同点：都是保存在浏览器端，并且是同源的
Cookie：cookie数据始终在同源的http请求中携带（即使不需要），即cookie在浏览器和服务器间来回传递。
而sessionStorage和localStorage不会自动把数据发给服务器，仅在本地保存。
cookie数据还有路径（path）的概念，可以限制cookie只属于某个路径下,存储的大小很小只有4K左右。
（key：可以在浏览器和服务器端来回传递，存储容量小，只有大约4K左右）
sessionStorage：仅在当前浏览器窗口关闭前有效，自然也就不可能持久保持，localStorage：始终有效，窗口或浏览器关闭也一直保存，因此用作持久数据；
cookie只在设置的cookie过期时间之前一直有效，即使窗口或浏览器关闭。
（key：本身就是一个回话过程，关闭浏览器后消失，session为一个回话，当页面不同即使是同一页面打开两次，也被视为同一次回话）
localStorage：localStorage 在所有同源窗口中都是共享的；cookie也是在所有同源窗口中都是共享的。
（key：同源窗口都会共享，并且不会失效，不管窗口或者浏览器关闭与否都会始终生效）
Ajax请求过程和状态码意义
Ajax请求过程：
1)客户端产生js的事件
2)创建XMLHttpRequest对象
3)对XMLHttpRequest进行配置
4)通过AJAX引擎发送异步请求
5)服务器端接收请求并且处理请求，返回html或者xml内容
6)XML调用一个callback()处理响应回来的内容
7)页面局部刷新 在javascript里面写AJax的时，最关键的一步是对XMLHttpRequest对象建立监听，即使用“onreadystatechange”方法。
监听的时候，要对XMLHttpRequest对象的请求状态进行判断，通常是判断readyState的值为4且http返回状态status的值为200或者304时执行我们需要的操作。 readyState 属性表示Ajax请求的当前状态。
0 代表未初始化。 还没有调用 open 方法 1 代表正在加载。 open 方法已被调用，但 send 方法还没有被调用 2 代表已加载完毕。send 已被调用。请求已经开始 3 代表交互中。服务器正在发送响应 4 代表完成。响应发送完毕
常见的http的状态码说一下
2**开头 （请求成功）表示成功处理了请求的状态代码。 200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。 201 （已创建） 请求成功并且服务器创建了新的资源。 202 （已接受） 服务器已接受请求，但尚未处理。 203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。 204 （无内容） 服务器成功处理了请求，但没有返回任何内容。 205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。 206 （部分内容） 服务器成功处理了部分 GET 请求。 3** 开头 （请求被重定向）表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。 300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。 301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。 302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。 303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。 304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。 305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。 307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
302和307的区别：
02是http1.0的协议状态码，在http1.1版本的时候为了细化302状态码又出来了两个303和307，
你可以理解为303就是我们之前的302干的事情，临时重定向。
307有点意思：
如果这不是一个GET或者HEAD请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化
不是get或head，那比如我们提交一个post会怎么样。
**303重定向不会自动吧get，post的请求带到目标url去。
307重定向会把post的请求自动带到目标url，而对于get请求307也不会把参数带过去**
4**开头 （请求错误）这些状态代码表示请求可能出错，妨碍了服务器的处理。 400 （错误请求） 服务器不理解请求的语法。 401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。 403 （禁止） 服务器拒绝请求。 404 （未找到） 服务器找不到请求的网页。 405 （方法禁用） 禁用请求中指定的方法。 406 （不接受） 无法使用请求的内容特性响应请求的网页。 407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。 408 （请求超时） 服务器等候请求时发生超时。 409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。 410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。 411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。 412 （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。 413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。 414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。 415 （不支持的媒体类型） 请求的格式不受请求页面的支持。 416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。 417 （未满足期望值） 服务器未满足"期望"请求标头字段的要求。 5**开头（服务器错误）这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。 500 （服务器内部错误） 服务器遇到错误，无法完成请求。 501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。 502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。 503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。 504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。 505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。
304机制
1.服务器首先产生Etag,服务器可在稍后使用它来判断页面是否被修改。本质上，客户端通过该记号传回服务器要求服务器验证（客户端）缓存） 2.304是HTTP的状态码，服务器用来标识这个文件没有被修改，不返回内容，浏览器接受到这个状态码会去去找浏览器缓存的文件 3.流程：客户端请求一个页面A。服务器返回页面A，并在A上加一个Tage客服端渲染该页面，并把Tage也存储在缓存中。
客户端再次请求页面A并将上次请求的资源和ETage一起传递给服务器。服务器检查Tage.并且判断出该页面自上次客户端请求之后未被修改。直接返回304 last-modified: 客服端请求资源，同时有一个last-modified的属性标记此文件在服务器最后修改的时间，客服端第二次请求此url时，根据http协议。
浏览器会向服务器发送一个If-Modified-Since报头，询问该事件之后文件是否被修改，没修改返回304 //有了Last-Modified，为什么还要用ETag？ 1、因为如果在一秒钟之内对一个文件进行两次更改，Last-Modified就会不正确（Last—Modified不能识别秒单位的修改） 2、某些服务器不能精确的得到文件的最后修改时间 3、一些文件也行会周期新的更改，但是他的内容并不改变（仅仅改变修改的事件），这个时候我们并不希望客户端认为文件被修改，而重新Get //ETag，为什么还要用Last-Modified？ 1、两者互补，ETag的判断的缺陷，比如一些图片等静态文件的修改 2、如果每次扫描内容都生成ETag比较，显然要比直接比较修改时间慢的多。 //ETag是被请求变量的实体值（文件的索引节，大小和最后修改的时间的Hash值） 1、ETag的值服务器端对文件的索引节，大小和最后的修改的事件进行Hash后得到的。
涉及到的header的头部属性有哪些
400、401、403状态码产生原因，解决方法
//(1)400状态码：请求无效
产生原因：
前端提交数据的字段名称和字段类型与后台的实体没有保持一致
前端提交到后台的数据应该是json字符串类型，但是前端没有将对象JSON.stringify转化成字符串。
解决方法：
对照字段的名称，保持一致性
将obj对象通过JSON.stringify实现序列化
//(2)401状态码：当前请求需要用户验证
//(3)403状态码：服务器已经得到请求，但是拒绝执行
浏览器生成DOM解析页面过程
第一步：将载入的HTML文件解析成DOM树（DOM Tree），并且将各个标记标识解析成DOM树的各个节点；
在解析HTML的同时会将CSS样式解析成CSS规则（CSS Rules）。
第二步：将解析成的DOM树和CSS规则进行关联生成渲染树（Render Tree）。
第三步：进入布局阶段，为DOM树的每个节点分配在屏幕上出现的确切坐标（这一阶段还是渲染树）
第四步：进入绘制阶段，在这里渲染引擎的工作就结束了，接下来就给用户界面后端（UI Backend）对渲染树的每个节点进行绘制，呈现出页面效果。
输入URL之后的浏览器的解析过程详细说一下
1、浏览器地址栏输入url 2、浏览器会先查看浏览器缓存--系统缓存--路由缓存，如有存在缓存，就直接显示。如果没有，接着第三步 3、域名解析（DNS）获取相应的ip 4、浏览器向服务器发起tcp连接，与浏览器建立tcp三次握手 5、握手成功，浏览器向服务器发送http请求，请求数据包 6、服务器请求数据，将数据返回到浏览器 7、浏览器接收响应，读取页面内容，解析html源码，生成DOm树 8、解析css样式、浏览器渲染，js交互绑定多个域名，数量不限；
DNS域名解析说一下
当我们在浏览器中输入一个URL，例如”www.google.com”时，这个地址并不是谷歌网站真正意义上的地址。
互联网上每一台计算机的唯一标识是它的IP地址，因此我们输入的网址首先需要先解析为IP地址，这一过程叫做DNS解析。
DNS解析是一个递归查询的过程。例如，我们需要解析”www.google.com”时，会经历以下步骤：
- 在本地域名服务器中查询IP地址，未找到域名；
- 本地域名服务器回向根域名服务器发送请求，未找到域名；
- 本地域名服务器向.com顶级域名服务器发送请求，未找到域名；
- 本地域名服务器向.google.com域名服务器发送请求，找到该域名，将对应的IP返回给本地域名服务器。
浏览器缓存
浏览器缓存原理
原理：当浏览器再次访问一个已经访问过的资源时，它会这样做： 看看是否命中强缓存，如果命中，就直接使用缓存了。 如果没有命中强缓存，就发请求到服务器检查是否命中协商缓存。 如果命中协商缓存，服务器会返回 304 告诉浏览器使用本地缓存。 否则，返回最新的资源。
浏览器缓存
浏览器缓存分为强缓存和协商缓存。当客户端请求某个资源时，获取缓存的流程如下：
- 先根据这个资源的一些
http header判断它是否命中强缓存，如果命中，则直接从本地获取缓存资源，不会发请求到服务器； - 当强缓存没有命中时，客户端会发送请求到服务器，服务器通过另一些
request header验证这个资源是否命中协商缓存，称为http再验证，如果命中，服务器将请求返回，但不返回资源，而是告诉客户端直接从缓存中获取，客户端收到返回后就会从缓存中获取资源； - 强缓存和协商缓存共同之处在于，如果命中缓存，服务器都不会返回资源；
- 区别是，强缓存不对发送请求到服务器，但协商缓存会。
- 当协商缓存也没命中时，服务器就会将资源发送回客户端。
- 当
ctrl+f5强制刷新网页时，直接从服务器加载，跳过强缓存和协商缓存； - 当
f5刷新网页时，跳过强缓存，但是会检查协商缓存；
强缓存
- Expires（该字段是
http1.0时的规范，值为一个绝对时间的GMT格式的时间字符串，代表缓存资源的过期时间） - Cache-Control:max-age（该字段是
http1.1的规范，强缓存利用其max-age值来判断缓存资源的最大生命周期，它的值单位为秒）
协商缓存
- Last-Modified（值为资源最后更新时间，随服务器response返回）
- If-Modified-Since（通过比较两个时间来判断资源在两次请求期间是否有过修改，如果没有修改，则命中协商缓存）
- ETag（表示资源内容的唯一标识，随服务器response返回）
- If-None-Match（服务器通过比较请求头部的If-None-Match与当前资源的ETag是否一致来判断资源是否在两次请求之间有过修改，如果没有修改，则命中协商缓存）
协商缓存用到的http头属性有哪些
协商缓存 Last-Modified（值为资源最后更新时间，随服务器response返回） If-Modified-Since（通过比较两个时间来判断资源在两次请求期间是否有过修改，如果没有修改，则命中协商缓存） ETag（表示资源内容的唯一标识，随服务器response返回） If-None-Match（服务器通过比较请求头部的If-None-Match与当前资源的ETag是否一致来判断资源是否在两次请求之间有过修改，如果没有修改，则命中协商缓存）
如果当前已经有缓存了，客户端还会向服务器发送请求吗？
浏览器怎么查看缓存
回流与重绘
//reflow(回流) reflow翻译为回流，指的是页面再次构建render树。每个页面至少发生一次回流，就是第一次加载页面的时候 此外，当页面中有任何改变可能造成文档结构发生改变(即元素间的相对或绝对位置改变)，都会发生reflow，常见的有： 添加或删除元素(opacity:0除外，它不是删除) 改变某个元素的尺寸或位置 浏览器窗口改变(resize事件触发) //repaint(重绘) repaint翻译为重绘，它可以类比为上面的第四步，根据render树绘制页面，它的性能损耗比回流要小。每次回流一定会发生重绘。
此外，以下操作(不影响文档结构的操作，影响结构的会发生回流)也会发生重绘： 元素的颜色、透明度改变 text-align等
重绘与重排，什么情况会触发重绘和重排
重绘
部分渲染树（或者整个渲染树）需要重新分析并且节点尺寸需要重新计算。这被称为重排。注意这里至少会有一次重排-初始化页面布局。
重排
由于节点的几何属性发生改变或者由于样式发生改变，例如改变元素背景色时，屏幕上的部分内容需要更新。这样的更新被称为重绘。
什么情况会触发和重绘？
- 添加、删除、更新
DOM节点 - 通过
display: none隐藏一个DOM节点-触发重排和重绘 - 通过
visibility: hidden隐藏一个DOM节点-只触发重绘，因为没有几何变化 - 移动或者给页面中的
DOM节点添加动画 - 添加一个样式表，调整样式属性
- 用户行为，例如调整窗口大小，改变字号，或者滚动。
HTTP的keep-alive的作用是什么？
在早期的HTTP/1.0中，每次http请求都要创建一个连接，而创建连接的过程需要消耗资源和时间，为了减少资源消耗，缩短响应时间，就需要重用连接。
在后来的HTTP/1.0中以及HTTP/1.1中，引入了重用连接的机制，就是在http请求头中加入Connection: keep-alive来告诉对方这个请求响应完成后不要关闭，下一次咱们还用这个请求继续交流。
协议规定HTTP/1.0如果想要保持长连接，需要在请求头中加上Connection: keep-alive。 keep-alive的优点： 较少的CPU和内存的使用（由于同时打开的连接的减少了） 允许请求和应答的HTTP管线化 降低拥塞控制 （TCP连接减少了） 减少了后续请求的延迟（无需再进行握手） 报告错误无需关闭TCP连
