前端基础
2.1）对称加密也有缺陷，如何克服？
对称加密虽然简单性能也好，但是首次把密钥发送给对方时，很容易被拦截。
这里介绍非对称加密：
解决方案：结合两种加密方式，将对称加密的密钥，使用非对称加密的公钥进行加密，然后接收方只能用私钥解，最后双方可以使用对称加密来进行沟通。
但是还有缺陷，如果存在一个中间人把通信的公钥换成他自己的公钥，这样就可完全拿到通信的数据。这样需要一个安全的第三方证明身份，放置被中间人攻击。但是如果中间人篡改了证书，证书也就没用了。
终极武器：数字签名。先用Hash 算法对证书的内容进行Hash 得到一个摘要，再用CA的私钥加密，生成最终的数字签名。当别人把证书发过来的时候，用相同的hash 算法生成消息摘要，用CA的公钥对数字前面解密的得到消息摘要。两个消息摘要一对比，就知道是否被中间人篡改了。
2.2）基于哈希算法在信息安全中主要应用在？__网易
1、文件校验
2、数字签名： Hash 值，又称"数字摘要"进行数字签名。数字签名：私钥加密，公钥解密
3、鉴权协议：在传输信道是可被侦听，但不可被篡改的情况下，这是一种简单而安全的方法
3）https 协议的工作原理（三次握手）
客户端向服务器发送请求，服务端确认能收到客户端的信息（第一次）；服务端确认收到并返回给客户端带有公钥的网站证书（第二次），客户端与服务端协商SSL链接的安全等级，同时使用公钥来加密会话密钥并发送给服务端（第三次），服务端通过私钥解密会话密钥实现与客户端之间的通信。
3.1）四次挥手
1、客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。
2、服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。
3、服务器B关闭与客户端A的连接，发送一个FIN给客户端A。
4、客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。
3.2）三次握手, 四次挥手, 握手为什么不是三次, 挥手可以是三次吗? _字节
三次握手是为了：防止已失效的请求报文又突然传递给服务器。
当A客户端发出连接请求，这时因为网络节点长时间滞留了，而A未等到确认，于是A又发送了一个请求，此时建立了连接，等到第二个连接释放后才到达B。此时B会认为是一个新的连接请求，于是向A发送连接确认。但是此时A已经完成了数据请求，对B给的连接确认一脸懵逼，直接丢掉。当然此时B也不会一直在等A的请求，它有一个保活计时器，如果超过计时器的时间A还没发送请求过来，那就不会再等了。
四次挥手的TIME_WAIT 状态：
第一是为了保证最后一个 ACK 报文能到达B。这个ACK 报文有可能丢失，使得处于Last_Ack 状态得不到对已发送的Fin+Ack 报文的确认，B会超时重传这个Fin+Ack。而A 就能在Time_Wait 时间里收到这个重传的报文。A就可以重传一次确认。如果没有这个Time_Wait ，B重传的Fin_Ack ，可A 早就走了，不会再重发确认；B无法按照正常步骤进入 close 状态。
第二是防止“已失效的报文连接请求”，A在TIME_WAIT中，经过这2MSL的时间，就可以使本链接持续的时间内产生的所有连接消失，这样就可以使下一个新的连接中不会出现这样旧的连接请求报文段。
聪明的你会发现谁先关闭谁就有一个TIME_WAIT的状态；
在linux的网络编程中，如果服务器如果先关闭，你会发现，现在想要立马再次启动服务器，就会报错说这个端口号被占用着，那就是因为有这个TIME_WAIT，2msl的时间.那么怎么解决 ？
解决：setsockopt（）函数。在这就不多说了。
3.3）拥塞控制了解吗？_字节
拥塞：对资源的需求超过了可用的资源。
拥塞控制：防止过多的数据注入到网络中，使网络中的路由器或链路不至于过载。前提是：网络能够承受现有的网络负荷。
拥塞控制的方法：
慢开始+拥塞避免、快重传+快恢复
1、慢开始
发送方维持一个叫做拥塞窗口cwnd的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。如果还考虑接收方的接受能力，那么发送窗口还可能小于拥塞窗口。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就在增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减少一些，以减少注入到网络中的分组数。
慢开始算法的思路：当主机开始发送数据时，如果立即把大量数据字节注入到网络中，那么久有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。经验证明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口cwnd设置为一个最大报文段MSS数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加之多一个MSS的数值，用这样的方法逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。
使用慢开始算法后，每经过一个传输轮次，拥塞窗口cwnd就加倍
传输轮次：一个传输轮次所经历的时间其实就是往返时间RTT。把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。
2、慢开始门限ssthresh
为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量.
当cwnd < ssthresh 时，使用慢开始算法。
当cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当cwnd = ssthresh 时，即可使用慢开始算法，也可使用拥塞避免算法。
3、拥塞避免
拥塞避免算法的思路：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样，拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢的多。
无论在慢开始阶段还是拥塞避免阶段，只要发送方判断网络出现拥塞（没有按时收到确认），就要把慢开始门限ssthresh设置为出现拥塞时发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发送拥塞的路由器有足够的时间把队列中积压的分组处理完。
4、“乘法减小”和“加法增大”
“乘法减小”是指不论在慢开始阶段还是拥塞避免阶段，只要出现超时（即可能出现了网络拥塞），就把慢开始门限ssthresh的值减半，即设置为当前的拥塞窗口的一半（开始执行慢开始算法）
“加法增大”是指执行拥塞避免算法后，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。
上面两种方法合起来常称为AIMD算法（加法增大乘法减少）。
注意：“拥塞避免”并非指完全能避免了拥塞。利用以上的措施要完全避免拥塞还是不可能的，“拥塞避免”是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络不容易出现拥塞。
快重传和快恢复。
1、快重传
快重传算法首先要求接收方每收到一个失序的报文段就立即发出重复确认（为的是使发送方及早的知道有报文段没有到达对方）而不要等到自己发送数据时才捎带确认。
快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待为其设置的重传计时器到期。
2、快恢复
（1）当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限减半。这是为了预防网络发生拥塞，但不执行慢开始算法。
（2）由于发送方现在认为网络很可能没有发生拥塞（如果网络发生了严重拥塞，就不会一连有好几个报文段连续到达接收方，也就不会导致接收方连续发送重复确认）。因此与慢开始不同之处就是现在不执行慢开始算法（即拥塞窗口现在不设置为1）而是把拥塞窗口的值设置为慢开始门限减半后的值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。
注意：有的快重传实现是把开始时的拥塞窗口cwnd值再增大一些（增大3个报文段），即等于ssthresh + 3*MSS 这样做的理由是：既然发送方收到三个重复的确认，就表明有三个分组已经离开了网络。这三个分组不再消耗网络资源而是停留在接收方的缓存中。可见现在网络中并不是堆积了分组而是减少了三个分组。因此可以适当把拥塞窗口扩大些。
当采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络超时时才使用。
实际上接收方的缓存空间总是有限的，接收方根据自己的接收能力设定了接收窗口rwnd,并把这个窗口值写入TCP首部中的窗口字段，传送给发送方。因此，从接收方对发送方的流量控制的角度考虑，发送方的发送窗口一定不能超过对方给出的接收窗口值rwnd.那么，发送方的窗口的上限值应当取为接收方窗口rwnd和拥塞窗口cwnd这两个变量中较小的一个。
发送方窗口的上限值 = Min [rwnd ,cwnd]
当rwnd < cwnd 时，是接收方的接收能力限制发送方窗口的最大值
当rwnd > cwnd 时，则是网络的拥塞限制发送方窗口的最大值
3.4）流量控制_网易
拥塞控制：拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
流量控制解决的问题是如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。
两者的区别：流量控制是为了预防拥塞。如：在马路上行车，交警跟红绿灯是流量控制，当发生拥塞时，如何进行疏散，是拥塞控制。流量控制指点对点通信量的控制。
4）https 协议的优点 及 缺点
优点：可以认证用户与服务器，确保数据发送到正确的客户机与服务器，它比 http 协议更安全，防止数据传输过程中不被窃取、改变，保证数据的完整性。
缺点：握手阶段比较费时，增加耗电；会增加数据的开销；SSL 证书随着功能的强大费用越高；SSL 证书要绑定IP ，不能在同一个ip 上绑定多个域名
5）TCP 和 UDP（无连接不可靠：发送数据的时候，直接把UDP包往网络一扔就完事了，接不接受收到发送的就不理了；接受数据的时候，有发给本地的UDP包就照单全收，收完再看是谁发的。相比TCP，少了握手建立连接，维护连接，连接释放等一系列过程，因此具有很小的资源消耗和处理速度快的优点。） 的区别
TCP 是面向连接的，而udp 在发送数据前不需要先建立连接
TCP 提供的服务更可靠，可以保证数据的无差错，不丢失，不重复，因此适合传输大数据量的交换；而 udp 不能保证可靠交付
TCP 面向的是字节流，在出现网络拥塞时不会降低发送速率，而 udp 面向报文，在有拥塞时会导致丢包（字节就是散乱的数据 报文就是添加了标记,封装后的数据）
TCP 只能1对1传输数据，而 udp 支持1对多（Socket进行UDP通信）
TCP 的首部可以有20字节，而 udp 只有8字节
TCP 是可靠传输，而 udp 是不可靠的
TCP的优点： 可靠，稳定 TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。 TCP的缺点： 慢，效率低，占用系统资源高，易被攻击 TCP在传递数据之前，要先建连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的CPU、内存等硬件资源。 而且，因为TCP有确认机制、三次握手机制，这些也导致TCP容易被人利用，实现DOS、DDOS、CC等攻击。
UDP的优点： 快，比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快。没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的，比如：UDP Flood攻击…… UDP的缺点： 不可靠，不稳定 因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。 基于上面的优缺点，那么： 什么时候应该使用TCP： 当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。 在日常生活中，常见使用TCP协议的应用如下： 浏览器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件传输 ………… 什么时候应该使用UDP： 当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。 比如，日常生活中，常见使用UDP协议的应用如下： QQ语音 QQ视频 TFTP ……
6.1） Keep-alive的作用是什么？什么原理？_oppo
每次请求都会建立一次HTTP连接，也就是我们常说的3次握手4次挥手，这个过程在一次请求过程中占用了相当长的时间，而且逻辑上是非必需的，因为不间断的请求数据，第一次建立连接是正常的，以后就占用这个通道，下载其他文件，这样效率多高啊！你猜对了，这就是Keep-Alive。http 和 tcp 都有 keepalive。
tcp 的keep-alive 侧重保持客户端和服务端的连接，一方会不定期发送心跳包给另一方，没断的发送几次心跳包。如果间隔发送几次，对方返回的都是 RST ，而不是ACK ，那么就释放当前链接。这样可以及时释放服务器的资源。tcp 层的 keepalive 主要包括三个参数：最后一次的连接时间、多少间隔发送一次心跳包，发送probs 次心跳包未收到响应则关闭连接.
http 的keep-alive 一般中间都会带上横杠。客户端告诉服务端，这个连接之后还会继续使用，避免进行重复的三次握手和四次挥手环节。（http 没啥原理好讲的，主要就是 Connection: keep-alive 字段，关闭的时候用 Connection : close 关闭）
- 列举几个在web中实现长连接（keep alive: 又称持久连接，连接重用）的技术方案或手段
Keep-Alive解决的问题
Keep-Alive解决的核心问题：一定时间内，同一域名多次请求数据，只建立一次HTTP请求，其他请求可复用每一次建立的连接通道，以达到提高请求效率的问题。这里面所说的一定时间是可以配置的
优点：减少了连接请求，降低了 TCP 阻塞，减少了延迟，实时性较好
这里主要分两种长连接实现：[http 会一直占用线程，而 servlet3 不会一直占用]
【 http 】http1.0 需要在 request 中增加：”Connection : keep - alive ” 才能支持长连接；服务端收到请求后，根据 ”Connection : keep - alive ” 判断出是一个长连接，在 response 中也增加 ”Connection : keep - alive ” ，同时不管关闭已经建立的 tcp 连接；客户端收到带有 ”Connection : keep - alive ” 的response 后，也不会关闭这个连接，继续用这个连接向服务端发送request 。keep-alive 是为了保持 tcp socket 连接
【 http 】http 1.1 默认支持长连接。客户端发送请求后，服务端默认这是一个长连接，返回的response 中带有 ”Connection : keep - alive ” 不关闭连接；客户端收到字段”Connection : keep - alive ” 后也不会关闭连接 。加入 “Connection : close ” 才关闭
【 servlet3 】基于 Servlet 3 实现的长连接。Servlet3 可以实现：一旦请求被服务端接受，就不再关闭连接，直到超时事件发生时才重新建立新的连接。一旦服务端准备好了数据，不会再向客户端询问是否准备好。自动给客户端发送数据，不重建立新连接，也不会浪费带宽，又称 “Comet 流”(彗星流)
与后面 webSocket 的区别：
WebSocket: 客户端发送一次http websocket请求，服务器响应请求，双方建立持久连接，并进行双向数据传输，后面不进行HTTP连接，而是使用TCP连接。
长连接：在HTTP 1.1，客户端发出请求，服务端接收请求，双方建立连接，在服务端没有返回之前保持连接，当客户端再发送请求时，它会使用同一个连接。这一直继续到客户端或服务器端认为会话已经结束，其中一方中断连接。用的是 http 连接。
7）http1.1 的优缺点
目前为止市场上广泛使用的http 版本依然是1.1 ，从1997年发布至今还在使用
优点：
增加持久性连接。Connection : keep-alive
增加管道机制。http1.0 时的请求方式是：若有两个请求A 和B，首先发出A请求，B请求处于等待状态，B必须在A的响应返回之后才能发出，所以这个排队规则会造成资源的浪费。http1.1 改进了上述方式。也就是增加了管道机制：请求可以同时发出，但是响应必须要按照请求发出的顺序依次返回。
分块输出。http1.0 中的是，若服务器执行某次请求，需要等全部操作完成后才将数据一次性返回。1.1 就提出了分块输出，也就是会发送部分数据回来，减少了很多等待时间
增加host字段。为虚拟主机的租用或购买服务提供了便利，更适应网络的发展，尤其是对个人网站。有了Host 就可以租赁或购买虚拟主机，不需要购买昂贵的独立服务器，成本大大降低。
缺点
有较严重的网络延迟问题。虽然有持久性连接可以改善一点，但是每个请求的响应还是要排队。如果前面对响应的处理较为耗时间，同样会造成性能的耗费
虽然这个版本引进了管道机制，但是也有很多问题，且默认是关闭状态。
http 有哪些方法？他们的具体作用是什么？
HTTP1.0定义了三种请求方法： Get, Post 和 Head方法
HTTP1.1新增了五种请求方法：Options, Put, Delete, Trace 和 Connect
Get：请求服务器的发送某些资源
Post：发送数据给服务器
Head：请求资源的头部信息，并且与Get 方法请求时返回的一致。使用场景示例：下载一个大文件前，先获取其大小再决定是否要下载，因此可以节约带宽
Options：用于获取目的资源支持的通信选项
Put：给服务器新增资源或使用有效负载替换目标资源
Delete：删除指定的资源
Trace：回显服务器收到的请求，主要用于测试或诊断
Connect：HTTP1.1 中预留给将连接改为管道方式的代理服务器
8.1）HTTP1.0、HTTP1.1 和 HTTP2.0 的区别__美团
http1.0 和 http1.1 的区别
1、缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
2、带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
断点续传：当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础
3、错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
4、Host头处理，HTTP1.0是没有host域的，HTTP1.1才支持这个参数。在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。基于端口：Host 中可以指定不同的端口，用以区分不同的虚拟机；基于主机名：可以在不同虚拟机的conf 文件中，指定相同的地址，但是ServerName(域名)不一样
5、长连接，HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接，而HTTP1.1默认支持长连接。
HTTP是基于TCP/IP协议的，创建一个TCP连接是需要经过三次握手的,有一定的开销，如果每次通讯都要重新建立连接的话，对性能有影响。因此最好能维持一个长连接，可以用个长连接来发多个请求
http1.X 与 2.0 的区别(说一下http2.0)：
HTTP/2试图解决HTTP/1.1的许多缺点和不灵活之处。
2.0 比1.0 访问速度更快，允许多路复用：也就是允许通过单一的 http2 连接发送多重请求响应信息，而1.0 中的请求有一定的数量限制，超过限制会被阻塞。二进制分帧：2.0 会将所有传输的信息分割为更小的信息或帧，对他们进行二进制编码；同时还有首部压缩和服务器推送功能。
多路复用：多个请求可以同时在同一个TCP链接中，在耗时非常短的情况下成功发送，并且Response能够允许不按顺序被接收，在这过程中客户端与服务端不需要建立多个TCP链接。同时支持了流的优先级，也就是告诉服务器哪些内容是更优先的资源，先进行传输。
Header Compression头压缩：Http头压缩后，大小会被大大减小。头部压缩：http1.X 会在请求和响应中，重复地携带不常改变的、冗长的头部数据，给网络带来额外的负担。http2 HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。在客户端和服务端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不通过响应和请求发送。首部表在连接存续期内始终存在，由两端渐进更新（也是有更新的时候才发送，没更新的部分按照“首部表”来做），每个新的首部键，要么追加到当前表的末尾，要么替换表中之前的值。
Server Push推送：Server可以在客户端没有请求之前发送一些资源。服务器可以在发送页面时，主动推送其他资源，而不用等到浏览器解析到相应位置，发起请求再响应。服务端可以主动推送，客户端也有权利选择是否接收。如果推送的资源已经被缓存过了，浏览器也可以选择拒收。
2、二进制分帧：HTTP/2 引入二进制分帧层（Binary Framing），将每个请求和响应分割为更小的帧，并对它们进行二进制编码。帧是数据通信的最小单位消息，一个消息可以由一个或多个帧组成；流：是连接中的一个虚拟通道，流可以承载双向消息，每个流都有一个唯一的整数ID
11）http 的请求报文是什么样的？
请求报文有4部分组成：请求行、请求头、空行、请求体
请求行示例：GET /index.html HTTP/1.1。
请求头：头部关键字/值对，每行一对，关键字和值用英文冒号”:”分隔
示例：
1、User-Agent：产生请求的浏览器类型。
2、Accept：客户端可识别的内容类型列表。
3、Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。
请求体：
Post、put等请求携带的数据
http的响应报文是什么样的？
响应报文有4部分：响应行、响应头、空行、响应体
响应行：协议版本，状态码+状态码的原因短语。如：HTTP/1.1 200 OK
响应头：响应首部组成
响应体：服务器响应的数据
（报文的格式：响应/请求行、响应/请求头、空行、响应/请求体）
12）2、WebSocket 的实现和应用
什么是WebSocket ？
WebSocket 是H5 中的协议，支持持久连接，t建立在TCP协议之上，并且与HTTP协议有着良好的兼容性，客户端通过HTTP协议向服务端发送握手，服务端向客户端返回ACK，此时握手成功，建立连接并维持该连接；
后面服务端和客户端就可以基于建立的连接进行双向通信，直到连接关闭。
WebSocket 作用？
（1）ajax轮询（时间片轮询的方式，向服务端发起请求
）
ajax轮询的原理非常简单，让浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。
（2）long poll（长轮询）
long poll 其实原理跟 ajax轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端（对于PHP有最大执行时间，建议没消息，执行到一定时间也返回）。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。
从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，关闭HTTP协议，由于HTTP是非状态性的，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁。然后等待服务端处理，可以体现HTTP协议的另外一个特点，被动性。
何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起。从上面很容易看出来，不管怎么样，上面这两种都是非常消耗资源的。
ajax轮询 需要服务器有很快的处理速度和资源。（速度）long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小）
（3）Websocket解决了HTTP的这几个难题。首先，被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。解决了上面同步有延迟的问题。
解决服务器上消耗资源的问题：其实我们所用的程序是要经过两层代理的，即HTTP协议在Nginx等服务器的解析下，然后再传送给相应的Handler（php等）来处理。简单地说，我们有一个非常快速的 接线员（Nginx） ，他负责把问题转交给相应的 客服（Handler） 。Websocket就解决了这样一个难题，建立后，可以直接跟接线员建立持久连接，有信息的时候客服想办法通知接线员，然后接线员在统一转交给客户。
由于Websocket只需要一次HTTP握手（仍然需要至少一次的客户端服务端握手），所以说整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求，这样就解决了接线员要反复解析HTTP协议，还要查看identity info的信息。
直接给客户端发送数据；一旦连接建立，可以一直保持连接，避免了http 的非状态性。
http请求方法（GET、POST、HEAD、OPTIONS、PUT、DELETE、TRACE、CONNECT）
不同？
GET 请求指定的页面信息，并返回实体主体。GET方法提交数据，可能会带来安全性的问题，数据被浏览器缓存。
GET请求有长度限制。
head 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头。
OPTIONS允许客户端查看服务器的性能。
POST向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。POST请求可能会导致新的资源的建立和/或已有资源的修改。POST方式提交时，你必须通过Request.Form来访问提交的内容
PUT从客户端向服务器传送的数据取代指定的文档的内容。
DELETE请求服务器删除指定的页面。
TRACE回显服务器收到的请求，主要用于测试或诊断
PUT和POST都是给服务器发送新增资源，有什么区别？
通常情况下，Put 的URL 指向是具体单一资源，而Post 指向资源集合
使用场景举例。
PUT请求是向服务器端发送数据的，从而改变信息，该请求就像数据库的update操作一样，用来修改数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次PUT操作，其结果并没有不同。
POST请求同PUT请求类似，都是向服务器端发送数据的，但是该请求会改变数据的种类等资源，就像数据库的insert操作一样，会创建新的内容。几乎目前所有的提交操作都是用POST请求的。
10）PUT和PATCH都是给服务器发送修改资源，有什么区别？
put 和 patch 都是更新资源，而 patch 用来对已知资源进行局部更新
假设我们有一个UserInfo，里面有userId， userName， userGender等10个字段。可你的编辑功能因为需求，在某个特别的页面里只能修改userName，这时候的更新怎么做？
人们通常(为徒省事)把一个包含了修改后userName的完整userInfo对象传给后端，做完整更新。但仔细想想，这种做法感觉有点二，而且真心浪费带宽(纯技术上讲，你不关心带宽那是你土豪)。
于是patch诞生，只传一个userName到指定资源去，表示该请求是一个局部更新，后端仅更新接收到的字段。
而put虽然也是更新资源，但要求前端提供的一定是一个完整的资源对象，理论上说，如果你用了put，但却没有提供完整的UserInfo，那么缺了的那些字段应该被清空
对一个图片url 访问后直接下载怎样实现？
后台拿到图片的地址，读取图片后返回；
a 标签中新增属性 download ，但目前只有火狐和谷歌支持；
在 ie 中调用iframe的execCommand('saveAs')
说一下 web Quality(无障碍)
能够被残障人士使用的网站是一个易用的网站。也就是增加无法正常显示时的提示。比如 img 中的alt 属性，在语音浏览器中，浏览器可以根据设定的alt 属性，显示或者读出有关图像的描述。
几个使用的 BOM 属性对象方法？
什么是BOM ？ BOM 是浏览器对象
有哪些常用的BOM 属性？
location对象
location.href-- 返回或设置当前文档的URL
location.search -- 返回URL中的查询字符串部分。例如 http://www.dreamdu.com/dreamdu.php?id=5&name=dreamdu 返回包括(?)后面的内容?id=5&name=dreamdu
location.hash -- 返回URL#后面的内容，如果没有#，返回空
location.host -- 返回URL中的域名部分，例如www.dreamdu.com
location.hostname -- 返回URL中的主域名部分，例如dreamdu.com
ocation.pathname -- 返回URL的域名后的部分。例如 http://www.dreamdu.com/xhtml/ ?xxx返回/xhtml/
location.port -- 返回URL中的端口部分。例如 http://www.dreamdu.com:8080/xhtml/ 返回8080
location.protocol -- 返回URL中的协议部分。例如 http://www.dreamdu.com:8080/xhtml/ 返回(//)前面的内容http:
location.assign -- 设置当前文档的URL
location.replace() -- 设置当前文档的URL，并且在history对象的地址列表中移除这个URL location.replace(url);
location.reload() -- 重载当前页面
history对象
history.go() -- 前进或后退指定的页面数 history.go(num);
history.back() -- 后退一页
history.forward() -- 前进一页
navigator对象
navigator.userAgent -- 返回用户代理头的字符串表示(就是包括浏览器版本信息等的字符串)
navigator.cookieEnabled -- 返回浏览器是否支持(启用)cookiehistory 对象：go(num)前进多少页，back() 后退一页，forward() 前进一页
说一下 h5 的drag API
dragstart : 事件主体是被拖放元素，开始拖放时触发。
drag: 主体是拖放元素，正在拖放时触发
dragenter: 主体元素进入某元素时触发
dragover : 主体元素，在某元素内移动时触发
dragleave: 主体元素，移出某元素时触发
drop: 主体元素完全被某元素接受时触发
dragend : 整个拖放操作结束时触发
补充400 和401、403 状态码（聊一聊http 的状态码有哪些？）
100： Continue 继续，客户端继续其请求
101：切换协议，服务器根据客户端的请求切换协议，但只能更换到高级的协议
2XX 成功
200：OK 请求成功，表示从客户端发来的请求在服务端被正确处理
201：已创建，成功请求并创建了新的资源
202：已接受，接受请求但未处理完成
204：No content ，表示请求成功，但响应报文不含实体的主体部分
206：Partial Content ，进行范围请求
3XX 重定向（自动跳转）
301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
302 found，临时性重定向，表示资源临时被分配了新的 URL
303 see other，表示资源存在另一个 URL，应使用 GET 方法获取资源
304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况
307 temporary redirect，临时重定向，和302含义相同
4XX 客户端错误
400：请求无效
前端提交数据的字段名字段类型与实体没有一致
前端提交到后台应该是 json 字符串类型，但前端没有使用 JSON.stringfy 转化成字符串
解：保持字段名称类型一致性，通过JSON.stringfy 实现序列化。
401：当前请求需要用户验证
402：服务器已经得到请求，但拒绝执行
403: forbidden，表示对请求资源的访问被服务器拒绝
404: not found，表示在服务器上没有找到请求的资源
408 : Request timeout, 客户端请求超时
409 : Confict, 请求的资源可能引起冲突
5XX 服务器错误
500 internal sever error，表示服务器端在执行请求时发生了错误
501 Not Implemented 请求超出服务器能力范围，例如服务器不支持当前请求所需要的某个功能，或者请求是服务器不支持的某个方法
503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求
505 http version not supported 服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本
301 和 302 的区别：前者是资源的永久移动，302 是资源的临时移动。301常用于域名跳转，302常用于未登陆的用户访问用户中心，重定向到登陆页面
304 和 200 的区别：200 数据请求成功，如果没有被压缩的话，文件是多大传输回来的量就是多大。304 客户端发送一个带条件的GET 请求且请求被允许，此时服务器返回304，表明文档的内容没有被改变，让客户端使用的本地的缓存。比200完全拿全量的数据，服务器返回的数据量小了很多。
关于跨域
根据浏览器同源策略（协议、域名、端口一致为同源），凡是发送请求的源与当前页面的源不同的即为跨域。同源策略用于隔离潜在的恶意文件。
解决方式：
JSONP：只支持GET，不支持POST请求；
原理：浏览器只对XHR请求有同源限制，对script标签src属性，link标签ref属性和img标签src属性没有限制。
代理：使用代理去避开跨域请求，写一个后台接口，在后端去调用该不通源请求地址；
服务端修改：在服务端页面添加header限制：
Header(‘Access-Control-Allow-Origin:*’)//允许所有来源访问
Header(‘Access-Control-Allow-Method:POST,GET’)//允许访问的方式
使用js的fetch发送2次请求的原因
js还提供fetch来替代XMLHttpRequest，fetch 发送post 请求的时候，总是发送2次，一次状态码是204，第二次才成功，用fetch 的 post 请求的时候，fetch 第一次会发送一个 options 请求，询问服务器是否支持修改的请求头，如果支持，第二次才发送真正的请求。
cookie,sessionStorage，localStorage的区别__京东
同：都保存在浏览器端，且是同源的
Cookie：始终在同源的 http请求中携带，在服务器和客户端之间来回传递，同源敏感词共享。还可以限制cookie 仅存储在某个路径下，存储大小只有4K 左右，一般浏览器会限制一个站点最多保存20个 cookie 。在过期时间内有效。同源窗口共享，不是很安全，别人可以通过修改cookie 进行欺骗。保存用户的登陆状态，跟踪用户行为，定制页面（记录在·用户的选项等）。cookie 过多会影响网络请求性能。
cookie包括会话cookie和持久cookie。
持久cookie则是存储在硬盘上，不同的操作系统，不同的浏览器存储位置不一样，不管是浏览器退出或者电脑重启，持久cookie都存在。但需要注意的是，持久cookie有过期时间。
sessionStorage：仅在窗口关闭前有效，又称会话存储，不同窗口敏感词不共享，用来保存临时的数据，防止用户刷新后的数据丢失（可以保存5M 的信息）
localStorage：始终有效，窗口或浏览器关闭也一直保存，用作持久数据，除非手动删除，否则永久保存（也就是不能设置有效期）。在所有的同源窗口中敏感词共享的（可以保存5M 的信息），也是遵循同源策略，所以不同网站直接是不能共用相同的 localstorage
seesion 区别：在一定时间内存放在服务器上的，当访问较多时，会占用服务器性能
使用情况：能少用 cookie 就少用
11.1）localstorage使用的时候有什么注意点__字节
1、使用的时候先看浏览器能否支持 localstorage
2、存储的时候，localStorage 只能以string 格式存储。就算一开始是Int 类型，拿出来还是string 类型，所以使用的时候要做类型转换
3、localStorage.clear( ) 方法会将所有的内容清除，而不是某个键
4、删除localStorage 中的某个键值对：storage = window.localStorage ; storage.removeItem(“ a ”) ;
5、获取某键的值：localStorage .getItem(“ c”) 设定某键值 localStorage .setItem(“ b ” , 要设定的数值)；如果需要修改某个键的值，需要获取到再修改之后，重新设定
6、如果要将 json 存入localStorage ，则需要对 JSon 使用 JSON.stringify( data )。因为localStorage 中只能存储字符串。取出时再用json = localStorage .getItem(“ data ”) obj = JSON.parse( json ) ; 相应的其他类型读取出来也要做转换
11.2）描述cookie和localStorage的区别，为什么cookie的容量限制比localStorage小？__小米
Cookie和localStorage的区别有：
1. Cookie可以由服务端和js读写（如果设置了HttpOnly的话js无法读），localStorage只能是js读写。（5分）
2. Cookie会附带在HTTP请求头里，而localStorage不会。（5分）
3. Cookie可设置过期时间，而localStorage不能。（5分）
4. 同域名的http和https共享cookie（设置了Secure的除外）但是不共享localStorage。（5分）
