浏览器协议

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个字节

六、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（确认字符）

1. 第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
2. 第二次握手：Server收到数据包后由标志位SYN=1知道Client请求创建链接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认链接请求，Server进入SYN_RCVD状态。
3. 第三次握手：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的链接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

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以后的首次更新。

一、提高访问速度（能够对于，请求资源所需时间更少，访问速度更快，相比http1.0）

二、容许多路复用：多路复用容许同时经过单一的HTTP/2链接发送多重请求-响应信息。
改善了：在http1.1中，浏览器客户端在同一时间，针对同一域名下的请求有必定数量限制（链接数量），超过限制会被阻塞。

3、二进制分帧：HTTP2.0会将全部的传输信息分割为更小的信息或者帧，并对他们进行二进制编码

4、首部压缩

五、服务器端推送 

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

1、XSS：跨站脚本攻击，是一种网站应用程序的安全漏洞攻击，是代码注入的一种。常见方式是将恶意代码注入合法代码里隐藏起来，再诱发恶意代码，从而进行各类各样的非法活动。

预防：

1、使用XSS Filter

输入过滤，对用户提交的数据进行有效性验证，仅接受指定长度范围内并符合咱们指望格式的的内容提交，阻止或者忽略除此外的其余任何数据。
输出转义，当须要将一个字符串输出到Web网页时，同时又不肯定这个字符串中是否包括XSS特殊字符，
为了确保输出内容的完整性和正确性，输出HTML属性时可使用HTML转义编码（HTMLEncode）进行处理，输出到<script>中，能够进行JS编码。



使用 HttpOnly Cookie
将重要的cookie标记为httponly，这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段，可是在js脚本中却不能访问这个cookie，
这样就避免了XSS攻击利用JavaScript的document.cookie获取cookie。


2、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后就会显得很人性化了，系统可以记住上一次访问的地区，当下次再打开该页面时，它就会自动显示上次用户所在地区的天气状况。
由于一切都是在后 台完成，因此这样的页面就像为某个用户所定制的同样，使用起来很是方便


三、定制页面。若是网站提供了换肤或更换布局的功能，那么可使用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？
  一、由于若是在一秒钟以内对一个文件进行两次更改，Last-Modified就会不正确（Last—Modified不能识别秒单位的修改）
  2、某些服务器不能精确的获得文件的最后修改时间
  3、一些文件也行会周期新的更改，可是他的内容并不改变（仅仅改变修改的事件），这个时候咱们并不但愿客户端认为文件被修改，而从新Get

//ETag，为何还要用Last-Modified？
  1、二者互补，ETag的判断的缺陷，好比一些图片等静态文件的修改
  2、若是每次扫描内容都生成ETag比较，显然要比直接比较修改时间慢的多。


//ETag是被请求变量的实体值（文件的索引节，大小和最后修改的时间的Hash值）
  一、ETag的值服务器端对文件的索引节，大小和最后的修改的事件进行Hash后获得的。

涉及到的header的头部属性有哪些

400、40一、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

二、浏览器会先查看浏览器缓存--系统缓存--路由缓存，若有存在缓存，就直接显示。若是没有，接着第三步

3、域名解析（DNS）获取相应的ip

4、浏览器向服务器发起tcp链接，与浏览器创建tcp三次握手

5、握手成功，浏览器向服务器发送http请求，请求数据包

6、服务器请求数据，将数据返回到浏览器

7、浏览器接收响应，读取页面内容，解析html源码，生成DOm树

八、解析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连

防抖和节流

http长链接写一下