以下题目是根据网上多份面经收集而来的，题目相同意味着被问的频率比较高，有问题欢迎留言讨论，喜欢可以点赞关注。

常见Http请求头

Accept：指定客户端能够接收的内容类型。 Accept-Charset：浏览器可以接受的字符编码集。 Accept-Encoding：指定浏览器可以支持的web服务器返回内容压缩编码类型。 #####Accept-Language：浏览器可接受的语言。 Accept-Ranges：可以请求网页实体的一个或者多个子范围字段。 AuthorizationHTTP：授权的授权证书。 #####Cache-Control：指定请求和响应遵循的缓存机制。 Connection：表示是否需要持久连接。（HTTP 1.1默认进行持久连接） CookieHTTP：请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。 Content-Length：请求的内容长度。 #####Content-Type：请求的与实体对应的MIME信息。 #####Date：请求发送的日期和时间。 Expect：请求的特定的服务器行为。 From：发出请求的用户的Email。 Host：指定请求的服务器的域名和端口号。 If-Match：只有请求内容与实体相匹配才有效。 If-Modified-Since：如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码。 If-None-Match：如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变。 If-Range：如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。 If-Unmodified-Since：只在实体在指定时间之后未被修改才请求成功。 Max-Forwards：限制信息通过代理和网关传送的时间。 Pragma：用来包含实现特定的指令。 Proxy-Authorization：连接到代理的授权证书。 Range：只请求实体的一部分，指定范围。 Referer：先前网页的地址，当前请求网页紧随其后,即来路。

TE：客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息。 Upgrade：向服务器指定某种传输协议以便服务器进行转换（如果支持。 User-AgentUser-Agent：的内容包含发出请求的用户信息。 Via：通知中间网关或代理服务器地址，通信协议。 Warning：关于消息实体的警告信息

介绍http2.0

segmentfault.com/a/119000001…

什么是HTTP2.0

1、是HTTP协议的第二个主要版本，主要基于SPDY协议。大幅度提高了web性能。

SPDY是Speedy的昵音，意为“更快”。它是Google开发的基于TCP协议的应用层协议。目标是优化HTTP协议的性能，通过压缩、多路复用和优先级等技术，缩短网页的加载时间并提高安全性。SPDY协议的核心思想是尽量减少TCP连接数。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强

HTTP1.x的缺点

HTTP1.x有以下几个主要缺点：

1. HTTP/1.0一次只允许在一个TCP连接上发起一个请求，HTTP/1.1使用的流水线技术也只能部分处理请求并发，仍然会存在队列头阻塞问题，因此客户端在需要发起多次请求时，通常会采用建立多连接来减少延迟。
2. 单向请求，只能由客户端发起。
3. 请求报文与响应报文首部信息冗余量大。
4. 数据未压缩，导致数据的传输量大。

HTTP2.0特点

通过以上内容，你应该已经对HTTP2.0有了初步认识，并且了解了HTTP1.x的缺点。那么下面我们就来了解一下HTTP2.0的特点。

1、二进制传输

文本的表现形式有多样性，健壮性考虑 HTTP2.0中所有加强性能的核心是二进制传输，在HTTP1.x中，我们是通过文本的方式传输数据。基于文本的方式传输数据存在很多缺陷，文本的表现形式有多样性，因此要做到健壮性考虑的场景必然有很多，但是二进制则不同，只有0和1的组合，因此选择了二进制传输，实现方便且健壮。 在HTTP2.0中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。 为了保证HTTP不受影响，那就需要在应用层（HTTP2.0）和传输层（TCP or UDP）之间增加一个二进制分帧层。在二进制分帧层上，HTTP2.0会将所有传输的信息分为更小的消息和帧，并采用二进制格式编码，其中HTTP1.x的首部信息会被封装到Headers帧，而Request Body则封装到Data帧。

2、多路复用

即在一个TCP连接，即可以同时发送多个请求 在HTTP1.0中，我们经常会使用到雪碧图、使用多个域名等方式来进行优化，都是因为浏览器限制了同一个域名下的请求数量，当页面需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求时，资源需要等待其他资源请求完成后才能继续发送。 HTTP2.0中，有两个概念非常重要：帧（frame）和流（stream）。 帧是最小的数据单位，每个帧会标识出该帧属于哪个流，流是多个帧组成的数据流。 所谓多路复用，即在一个TCP连接中存在多个流，即可以同时发送多个请求，对端可以通过帧中的表示知道该帧属于哪个请求。在客户端，这些帧乱序发送，到对端后再根据每个帧首部的流标识符重新组装。通过该技术，可以避免HTTP旧版本的队头阻塞问题，极大提高传输性能。

3、Header压缩

使用文本的形式传输header，在header中携带cookie的话，开销大 在HTTP1.0中，我们使用文本的形式传输header，在header中携带cookie的话，每次都需要重复传输几百到几千的字节，这着实是一笔不小的开销。 在HTTP2.0中，我们使用了HPACK（HTTP2头部压缩算法）压缩格式对传输的header进行编码，减少了header的大小。并在两端维护了索引表，用于记录出现过的header，后面在传输过程中就可以传输已经记录过的header的键名，对端收到数据后就可以通过键名找到对应的值。

4、服务器Push

在HTTP2.0中，服务端可以在客户端某个请求后，主动推送其他资源。 可以想象一下，某些资源客户端是一定会请求的，这时就可以采取服务端push的技术，提前给客户端推送必要的资源，就可以相对减少一点延迟时间。在浏览器兼容的情况下也可以使用prefetch。

5、更安全

HTTP2.0使用了tls的拓展ALPN做为协议升级，除此之外，HTTP2.0对tls的安全性做了近一步加强，通过黑名单机制禁用了几百种不再安全的加密算法。

通过什么做到并发请求

使用异步Prmosie或者web worker

http1.1时如何复用tcp连接

其实这里就是要利用现有的服务端+keep-alive+浏览器实现： 0.合并请求 1.多文件合成流 2.多个流同时发送/接受 3.校验完整性、合并、执行

segmentfault.com/q/101000002…

Http报文的请求会有几个部分

http协议报文
    1.请求报文(请求行/请求头/请求数据/空行)
        请求行
            求方法字段、URL字段和HTTP协议版本
            例如：GET /index.html HTTP/1.1
                get方法将数据拼接在url后面，传递参数受限
            请求方法：
                GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT
        请求头(key value形式)
            User-Agent：产生请求的浏览器类型。
            Accept：客户端可识别的内容类型列表。
            Host：主机地址
        请求数据
            post方法中，会把数据以key value形式发送请求
        空行
            发送回车符和换行符，通知服务器以下不再有请求头
    2.响应报文(状态行、消息报头、响应正文)
        状态行
        消息报头
        响应正文

cookie放哪里，cookie能做的事情和存在的价值

cookie是存在浏览器上的一小段数据,来解决 HTTP无状态机制问题，比如记录某系页面关闭或者刷新后仍需要记录的信息。

属性 cookie可以使用js在浏览器直接设置，也可以在服务器端使用HTTP协议规定的set-cookie来设置。 一般cookie的容量为4k左右。 document.cookie查看当前浏览网站的cookie

运用 1、会话状态管理（如用户登录状态、购物车、游戏分数、其它需要记录的信息） 2、个性化设置（如用户自定义设置、主题等） 3、精准广告。（平常浏览网页时有时会推出商品刚好是你最近浏览过，买过的类似东西，这些是通过cookie记录的。）

cookie和token都存放在header里面，为什么只劫持前者

github.com/Advanced-Fr…

cookie 举例：服务员看你的身份证，给你一个编号，以后，进行任何操作，都出示编号后服务员去看查你是谁。 token 举例：直接给服务员看自己身份证

因为传统的cookie保存的session id，服务器会根据这个session id，确保服务器与客户端对话；这是的cookie是有状态的，意味着验证记录或者会话需要一直在服务端和客户端保持。而token是无状态的，服务器不记录哪些用户登录了或者哪些 JWT 被发布了，只判断token是否有效，通常我们都会给token设置有效时间，来确保不被劫持。所以劫持cookie比劫持token，更有效，毕竟cookie在某种情况下可以一直使用下去，而token不行。

cookie：登陆后后端生成一个sessionid放在cookie中返回给客户端，并且服务端一直记录着这个sessionid，客户端以后每次请求都会带上这个sessionid，服务端通过这个sessionid来验证身份之类的操作。所以别人拿到了cookie拿到了sessionid后，就可以完全替代你。 token：登陆后后端返回一个token给客户端，客户端将这个token存储起来，然后每次客户端请求都需要开发者手动将token放在header中带过去，服务端每次只需要对这个token进行验证就能使用token中的信息来进行下一步操作了。

cookie和session有哪些方面的区别

juejin.cn/post/684490…

Token被用户端放在Cookie中（不设置HttpOnly），同源页面每次发请求都在请求头或者参数中加入Cookie中读取的Token来完成验证。CSRF只能通过浏览器自己带上Cookie，不能操作Cookie来获取到Token并加到http请求的参数中。所以CSRF本质原因是“重要操作的所有参数都是可以被攻击者猜测到的”，Token加密后通过Cookie储存，只有同源页面可以读取，把Token作为重要操作的参数，CSRF无法获取Token放在参数中，也无法仿造出正确的Token，就被防止掉了

cookie的存放位置，删除机制。

目前有些 Cookie 是临时的，有些则是持续的。临时的 Cookie 只在浏览器上保存一段规定的时间，一旦超过规定的时间，该 Cookie 就会被系统清除 [2]持续的 Cookie 则保存在用户的 Cookie 文件中，下一次用户返回时，仍然可以对它进行调用。在 Cookie 文件中保存 Cookie，有些用户担心 Cookie 中的用户信息被一些别有用心的人窃取，而造成一定的损害。其实，网站以外的用户无法跨过网站来获得 Cookie 信息。如果因为这种担心而屏蔽 Cookie，肯定会因此拒绝访问许多站点页面。因为，当今有许多 Web 站点开发人员使用 Cookie 技术，例如 Session 对象的使用就离不开 Cookie 的支持

Cookie在生成时就会被指定一个Expire值，这就是Cookie的生存周期，在这个周期内Cookie有效，超出周期Cookie就会被清除。有些页面将Cookie的生存周期设置为“0”或负值，这样在关闭浏览器时，就马上清除Cookie，不会记录用户信息，更加安全。

Cookie并不提供修改、删除操作。如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。如果要删除某个Cookie，只需要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。注意是0而不是负数。负数代表其他的意义。读者可以通过上例的程序进行验证，设置不同的属性。

注意：修改、删除Cookie时，新建的Cookie除value、maxAge之外的所有属性，例如name、path、domain等，都要与原Cookie完全一样。否则，浏览器将视为两个不同的Cookie不予覆盖，导致修改、删除失败。

为什么有时候删除不了cookie? 可能是因为删除cookie时没有指定该cookie的path和domain，导致找不到这个cookie来设置过期时间而无法删除

从输入URL到页面加载全过程

1.DNS解析，找到IP地址 2.根据IP地址，找到对应的服务器 3.建立TCP连接(里面有个 三次握手) 4.连接建立后，发出HTTP请求 5.服务器根据请求作出HTTP响应 6.浏览器得到响应内容，进行解析与渲染，并显示 7.断开连接(四次挥手)

从输入一个网址到浏览器显示页面的全过程详细分析

TCP属于哪一层

（1 物理层 -> 2 数据链路层 -> 3 网络层(ip)-> 4 传输层(tcp) -> 5 应用层(http)）

如何设计一个localStorage，保证数据的实效性

localStorage 是持久化的存储，不是缓存级别的，用于存储一些临时的离线数据，所以也就不存在什么超时时间的概念。只能手动清除，可以自己写一些业务逻辑去判断在什么时机清除

if (+new Date() > +new Date(2014, 11, 30)) {
    localStorage.removeItem("c");    //清除c的值
    // or localStorage.clear();
}

不过有一点，请不要用localStorage保存机密数据，即便你已加密，也不安全哟

介绍xss，csrf

xss：用户通过各种方式将恶意代码注入到其他用户的页面中。就可以通过脚本获取信息，发起请求，之类的操作。

csrf：跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。csrf并不能够拿到用户的任何信息，它只是欺骗用户浏览器，让其以用户的名义进行操作。

http缓存控制

浏览器缓存控制分为强缓存和协商缓存，协商缓存必须配合强缓存使用。 判断是否使用缓存主要是判断缓存是否在有效期内。

当浏览器对某个资源的请求命中了强缓存时，利用Expires或者Cache-Control这两个http response header实现。 Expires描述的是一个绝对时间，依据的是客户端的时间，用GMT格式的字符串表示，如Expires:Thu,31 Dec 2037 23:55:55 GMT，下次浏览器再次请求同一资源时，会先从客户端缓存中查找，找到这个资源后拿出它的Expires与当前时间做比较，如果请求时间在Expires规定的有效期内就能命中缓存，这样就不用再次到服务器上去缓存一遍，节省了资源。但正因为是绝对时间，如果客户端的时间被随意篡改，这个机制就实效了，所以我们需要Cache-Control Cache-Control描述的是一个相对时间，在进行缓存命中时都是利用浏览器时间判断。Expires和Cache-Control这两个header可以只启用一个，也可以同时启用，同时启用时Cache-Control优先级高于Expires

当浏览器对某个资源的请求没有命中强缓存（即缓存过期后），就会发起一个请求到服务器，验证协商缓存是否命中（即验证缓存是否有更新，虽然有效期过了，但我还能继续使用它吗？），如果命中则还是从客户端中加载。协商缓存利用的是Last-Modified,If-Modified-Since和ETag,If-None-Match这两对header来管理的Last-Modified,If-Modified-Since：原理和上面的Expires相同，服务器会响应一个Last-Modified字段,表示最近一次修改缓存的时间,当缓存过期后, 浏览器就会把这个时间放在If-Modified-Since去请求服务器,判断缓存是否有更新。区别是它是根据服务器时间返回的header来判断缓存是否存在，但有时候也会出现服务器上资源有变化但修改时间没有变化的情况，这种情况我们就需要ETag,If-None-Match。原理与上面相同，区别是浏览器向服务器请求一个资源，服务器在返回这个资源的同时，在response的header中加上一个Etag字段，这个字段是服务器根据当前请求的资源生成的唯一标识字符串，只有资源有变化这个串就会发生改动。当缓存过期后,浏览器会把这个字符串放在If-None-Match去请求服务器,比较字符串的值判断是否有更新,Etag的优先级比Last-Modified的更高, Etag的出现是为了解决一个缓存文件在短时间内被多次修改的问题,因为Last-Modified只能精确到秒。ETag,If-None-Match这么厉害我们为什么还需要Last-Modified,If-Modified-Since呢？有一个例子就是，分布式系统尽量关掉ETag，因为每台机器生成的ETag不一样，Last-Modified,If-Modified-Since和ETag,If-None-Match一般都是同时启用。

最快的请求是不必与服务器进行通信的请求：通过响应的本地副本，我们可以避免所有的网络延迟以及数据传输的数据成本。

如上例中所示，在使用了If-None-Match之后，服务器只需要很小的响应就可以达到相同的结果，从而优化了性能。

Cache-Control 头在 HTTP/1.1 规范中定义，取代了之前用来定义响应缓存策略的头（例如 Expires）。当前的所有浏览器都支持 Cache-Control，因此，使用它就够了。

需要注意的是，在max-age指定的时间之内，浏览器不会向服务器发送任何请求，包括验证缓存是否有效的请求，也就是说，如果在这段时间之内，服务器上的资源发生了变化，那么浏览器将不能得到通知，而使用老版本的资源。

Expires的值为服务端返回的到期时间，即下一次请求时，请求时间小于服务端返回的到期时间，直接使用缓存数据。(不过Expires 是HTTP 1.0的东西，现在默认浏览器均默认使用HTTP 1.1，所以它的作用基本忽略。)另一个问题是，到期时间是由服务端生成的，但是客户端时间可能跟服务端时间有误差，这就会导致缓存命中的误差。(所以HTTP 1.1 的版本，使用Cache-Control替代.)

private：客户端可以缓存 public：客户端和代理服务器都可缓存 max-age=xxx：缓存的内容将在 xxx 秒后失效 no-cache： 需要使用对比缓存来验证缓存数据 no-store：所有内容都不会缓存，强制缓存，对比缓存都不会触发（对于前端开发来说，缓存越多越好）

www.jianshu.com/p/975eb0c1f…

缓存相关的HTTP请求头

强缓存相关的HTTP header 的字段

**Cache-Control:**在响应头中设置,用于通知浏览器该资源需要被缓存 **Expires:**其作用也是设置缓存时间(什么时候过期),但是在设置了cache-control的情况下会被覆盖

协商缓存相关的HTTP header 的字段 Last-Modified 和 If-Modified-Since(让服务器去判断是否在此时间之后资源内容发生了变化) Etag和 If-None-Match(判断资源是否改变)

#####37、浏览器缓存读取规则 详细如下： www.cnblogs.com/shixiaomiao…

（a）浏览器判定是否有缓存 （b）缓存是否过期 （c）跟服务器协商是否使用缓存 （d）协商缓存

强缓存 用户发送的请求，直接从客户端缓存中获取，不发送请求到服务器，不与服务器发生交互行为。

协商缓存 用户发送的请求，发送到服务器后，由服务器判定是否从缓存中获取资源。

**两者共同点：**客户端获得的数据最后都是从客户端缓存中获得。 **两者的区别：**从名字就可以看出，强缓存不与服务器交互，而协商缓存则需要与服务器交互。

http缓存怎么优化

服务端缓存又分为 代理服务器缓存 和 反向代理服务器缓存（也叫网关缓存，比如 Nginx反向代理、Squid等），其实广泛使用的 CDN 也是一种服务端缓存，目的都是让用户的请求走”捷径“，并且都是缓存图片、文件等静态资源。浏览器缓存控制机制有两种：HTML Meta标签 vs. HTTP头信息

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

上述代码的作用是告诉浏览器当前页面不被缓存，每次访问都需要去服务器拉取。使用上很简单，但只有部分浏览器可以支持，而且所有缓存代理服务器都不支持，因为代理不解析HTML内容本身。

CDN （Content Delivery Network，内容分发网络）

CDN部署静态内容：指 JavaScript、CSS、图片、图标、Flash 等，不包括页面html。

－－CDN是什么？

CDN是一组分布在多个不同地理位置的Web服务器，用于更加有效地向用户发布内容。在优化性能时， 会根据距离的远近来选择。

1.将静态资源缓存到离用户很近的相同网络运营商的CDN节点上`。

优点：如果应用程序web服务器离用户更近，那么一个http请求的响应时间将缩短，另一方面，如果组件web服务器离用户更近，则多个http请求的响应时间将缩短 不同地区的用户会访问到离自己最近的相同网络线路上的CDN节点，当请求达到CDN节点后，节点会判断自己的内容缓存是否有效，一个地区内只要有一个用户先加载资源，在CDN中建立了缓存，该地区的其他后续用户都能因此而受益。

不同地区的用户访问同一个域名却能得到不同CDN节点的IP地址，这要依赖于CDN服务商提供的智能域名解析服务，浏览器发起域名查询时，这种智能DNS服务会根据用户IP计算并返回离它最近的同网络CDN节点IP，引导浏览器与此节点建立连接以获取资源。

2.加载静态资源使用与页面不同的域名［不是用独立的二级或三级域名，而是用独立的一级域名］

原理：当浏览器向服务器请求一个静态资源时,会先发送同域名下的 cookie，服务器对于这些 cookie 不会做任何处理。因此它们只是在毫无意义的消耗带宽。所以你应该确保对于静态内容的请求是无coockie的请求。

静态资源和主页面不同域，这样加载资源的http请求就不会带上主页面种的cookie等数据，减少了数据传输量。节省流量，提升上传效率

3.动静分离，减少核心服务器的压力

4.并发限制 原理：浏览器对同一个域名下的请求有并发的限制，（ie6为2个，其他为6个）设置单独域名服务器，可以提升请求并发数，也就是令浏览器并行下载更多资源，提高站点性能。

5.方便复用－－放在另一个服务器上，可以方便全局内其他产品的使用。利于客户端的缓存，比如你打开了taobao.com，缓存了t.js文件，那么再打开tmall的时候，由于请求的是同一文件，就不用再下载了

浏览器的缓存问题

gzip 的原理是什么

gzip 使用了 LZ77 算法与 Huffman 编码来压缩文件，重复度越高的文件可压缩的空间就越大。

可以对图片开启 gzip 压缩吗，为什么

不需要开启，如果开启的话，有可能使图片变的更大。如果你注意一些网站的 img 资源时，就会发现他们都没有开启 gzip

http 响应头中的 ETag 值是如何生成的？

由 etag 计算 Last-Modified 与 Content-Length，使用 js 计算如下，结果相符

如果 http 响应头中 ETag 值改变了，是否意味着文件内容一定已经更改？

不一定，由服务器中 ETag 的生成算法决定。详见 #112

比如 nginx 中的 etag 由 last_modified 与 content_length 组成，而 last_modified 又由 mtime 组成

当编辑文件却未更改文件内容时，或者 touch file，mtime 也会改变，此时 etag 改变，但是文件内容没有更改。

HTTP优化策略（博客）

压缩 缓存 多路复用 http1.1长连接 升级http2

压缩 压缩的程序取决于文件的类型。gzip是GUNzip的缩写，使用无损压缩，压缩效果最佳，已经成为使用最为普遍、支持的浏览器最多的数据压缩格式。目前国内的大型网站都使用的是这种方式（例如：淘宝、京东、腾讯等...）

为了选择采用的压缩算法，浏览器和服务器之间会使用主动协商机制。浏览器发送 Accept-Encoding首部，（其中包含它所支持的压缩算法，以及各自的优先级）。服务器则从中选择一种，使用该算法对响应的消息主体进行压缩，并且发送 Content-Encoding 首部来告知浏览器它选择了哪一种算法。由于该内容协商过程是基于编码类型来选择资源的展现形式的，在响应中， Vary(渲染引擎) 首部中至少要包含 Accept-Encoding ；这样的话，缓存服务器就可以对资源的不同展现形式进行缓存。

客户端（HTTP请求头）-->accept-encoding: gzip, deflate, sdch, br
服务器（HTTP响应头）-->content-encoding:gzip

由于压缩技术可以带来很大的性能提升，建议对除了已经经过压缩的文件如图片、音频和视频文件之外的其他类型的文件均进行应用。 和缓存

压缩优缺点 优点：减少HTTP响应时间，提升传输效率。 缺点：压缩过程占用服务器额外的CPU周期，客户端也要对压缩文件进行解压缩，这也需要占用部分时间。

请求头： user-agent：不同设备自动带上这个头，判断什么样的设备，重定向到相同的项目 响应头： Content-Type：给浏览器内容的类型 Location：重定向到某个地方

TCP复用 TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端的TCP连接上，HTTP复用是指一个一个客户端的多个HTTP请求通过一个TCP连接进行处理。

内容缓存 将经常用到的内容进行缓存起来，那么客户端就可以直接在内存中获取相应的数据了

压缩 将文本数据进行压缩，减少宽带SSL加速。使用SSL协议对HTTP协议进行加密，在通道内加密并加速

TCP缓冲 通过TCP缓冲技术，可以提高服务器端响应事件和处理效率，减少由于通信链路问题给服务器造成连接负担.

并行连接 可以通过建立多个 tcp连接通道来实现并行传输数据，提高页面响应速率。并行TCP连接的使用还能够一定程度上减轻RTT延迟和短连接缓启动延迟的影响。

长连接 HTTP/1.1默认开启 Keep-Alive 选项，并且是 pipeline（管线化）模式的。这样建立的 TCP 连接，可以在多次请求中复用。

pipeline目前只能用于GET和HEAD请求

HTTP/2.0 优化措施

头部压缩

将原来每次都要携带的大量 key value 在两端建立一个索引表，对相同的头只发送索引表中的索引。

多路复用和分帧

将一个TCP连接中，切分成多个流，每个流都有自己的ID，并且流可以是从客户端发往服务器的，也可以是从服务器发往客户端的。流有各自的优先级。

将所有的传输消息分割为更小的帧（常见的帧有Header帧，Data帧等；不同类别的帧属于不同的流）

通过以上两种机制，客户端可以将多个请求分散到不同的流中，然后将请求的内容拆分为帧，进行二进制传输。（帧可以乱序发送，服务器端根据帧首部的流标识符重新组装，并且可以根据流优先级决定流的处理顺序）

这么做的好处是什么呢？举一个例子：

假设一个页面要发送三个独立的请求，分别获取css、js、.jpg。如果是HTTP/1.，那么这三个请求就是串行的，但是经过HTTP/2.0的优化，这三个请求理论上就变成了并行的，可以在一个连接里，客户端和服务端都可以同时发送多个请求或回应，并且不用按照顺序一一发送。

HTTP/2.0成功解决了HTTP/1.1的队首阻塞问题，同时，也不需要通过HTTP/1.*的并行连接机制用多条TCP连接来实现并行请求与响应，从而减少了TCP连接数对服务器性能的影响。同时将页面的多个数据等通过一个数据连接进行传输，加快了页面组件的传输速度。

二进制编码

对帧进行二进制编码，压缩体积，提高传输效率。

HTTP/2.0的缺陷：

由于HTTP/2.0的底层是依赖TCP协议的，而TCP协议在处理包时是有严格顺序的。当一条连接其中一个数据包传输遇到问题时，TCP连接需要等待这个包完成重传后才能继续进行，所以虽然HTTP/2.0通过多个stream，使得逻辑上在一个TCP连接上进行多路数据传输，但是如果一前一后，前面的stream2的帧没有收到，stream1的帧也会因此阻塞，相当于又回到了串行传输。

自定义连接机制

HTTP/2.0是基于TCP协议的，而TCP协议规定的连接是由四元组（源IP，源端口号，目的IP，目的端口号）标识的。如果其中任何一个元素发生变化，就需要重新连接。而如果在网络不稳定的情况下，这种情况是会存在的。所以如果是HTTP/2.0协议，就会因为TCP的三次握手而增加时延。

QUIC是自己定义了维护连接的机制，即用一个64位的随机数作为ID来标识，而UDP是面向无连接的，所以当IP或者端口号发生变化的时候，只要ID不变，则不需要重新连接。

无阻塞的多路复用

同 HTTP/2.0一样，同一条 QUIC 连接上可以创建多个 stream，来发送多个 HTTP请求。但是 QUIC 是基于 UDP协议的，一个连接上的多个 stream 之间没有依赖。这样，加入 stream2 丢失了一个 UDP包，后面紧跟着 stream3 的一个 UDP 包，虽然 stream2 的那个包需要重传，但是 stream3 的包无需等待，就可以发送给客户端。

[HTTP前端性能优化(压缩与缓存)] (juejin.cn/post/684490…)

HTTP中的头（重点）

介绍下HTTP状态码 五星推荐

juejin.cn/post/684490…

403、301、302是什么 301 与 302 的区别以307 的区别 301 302 307 401 403 502 和 504的区别 状态码和方法，101

只要遵守状态码类别的定义，即使改变 RFC2616 中定义的状态码， 或服务器端自行创建状态码都没问题。仅记录在 RFC2616 上的 HTTP 状态码就达 40 种，若再加上 WebDAV(Web-based Distributed Authoring and Versioning，基于万维网 的分布式创作和版本控制)(RFC4918、5842) 和附加 HTTP 状态码 (RFC6585)等扩展，数量就达 60 余种。别看种类繁多，实际上经 常使用的大概只有 14 种。接下来，我们就介绍一下这些具有代表性 的 14 个状态码。

在响应报文内，随状态码一起返回的信息会因方法的不同而发生改 变。比如，使用 GET 方法时，对应请求资源的实体会作为响应返 回;而使用 HEAD 方法时，对应请求资源的实体首部不随报文主体 作为响应返回(即在响应中只返回首部，不会返回实体的主体部 分)。

1xx 表示临时响应并需要请求者继续执行操作的状态码。
100     //继续请求  请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。
101     //切换协议  请求者已要求服务器切换协议，服务器已确认并准备切换。
2xx
200（请求成功，正常返回信息）服务器已经成功处理了请求。通常，这表示服务器提供了请求的网页
201     //已创建  请求成功并且服务器创建了新的资源
202     //已接受  服务器已接受请求，但尚未处理
204（没有返回内容）服务器成功处理了请求，但没有返回任何内容
206（部分GET请求）服务器成功处理了部分GET请求，该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。断点续传原理

3xx
301（永久重定向）请求的网页已永久移动到新位置（URI）。服务器返回此响应（对GET或HEAD请求的响应）时，会自动将请求者转到新位置。301请求是可以缓存的， 即通过看status code，可以发现后面写着from cache。
302（临时重定向）服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求，所以以后访问还是旧的地址，返回码还是302
304（缓存，请求的网页未修改过）
307 会遵照浏览器标准，不会从 POST 变成 GET。但是，对于处理响
应时的行为，每种浏览器有可能出现不同的情况。
4xx——————————————
401（请求未授权，需要身份验证）对于需要登录的网页，服务器可能返回此响应
403（禁止访问）服务器拒绝请求  
404（找不到对应的资源）
405（请求方法不存在，不支持）禁用请求中指定的方法
5xx——————————————

500 服务器内部错误  服务器遇到错误，无法完成请求。也有可能是 Web 应用存在的 bug 或某些临时的故障。
502     //错误网关  服务器作为网关或代理，从上游服务器无法收到无效响应
504     //网关超时  服务器作为网关代理，但是没有及时从上游服务器收到请求
503  服务器不可用  服务器目前无法使用（由于超载或者停机维护）。通常，这只是暂时状态（负载均衡）

前后端通信使用什么方案

前后端实现通信的方式，即实现数据交互，靠的是HTTP（或者其他衍生类型，例如SSE、WS）

1、ajax（Asynchronous JavaScript + XML）技术：ajax的核心是XMLHttpRequest，通过对该对象的操作来进行异步的数据请求。有同源限制。

接触的最多的就是jQuery的封装，比如$.ajax   $.post   $.get
angular的话可以使用$htttp服务。

2、EventSource：就是SSE（服务端推送）技术，从HTTP演变而来

3、Web  Socket HTML5 WebSocket 设计出来的目的就是要取代轮询和Comet技术，使客户端浏览器具备像C/S架构下桌面系统的实时通讯能力。浏览器通过javascript向服务器发出建立WebSocket连接的请求，连接建立后，客户端和服务端就可以通过TCP连接直接交换数据。也就是我们可以使用web技术构建实时性的程序，比如聊天、游戏等应用。需要考虑兼容性。

4、navigator.sendBeacon：全新的异步数据上报api，专门用来做数据采集，浏览器会在合适的时候才执行数据上报。典型场景就是无阻塞的方式对出站行为进行采集上报。

5、服务端渲染 谈起服务端渲染，对于动态服务而言，这个世界 上跑的大多数页面都经过服务端的数据渲染，接口->前端赋值->模板渲染，这些都是在服务器完成的，在查看源码的时候，可以看到完整的html代码，包括每个数据值。

localStorage和cookie有什么区别

CORS如何设置

1.web缓存就是存在于客户端与服务器之间的一个副本、当你第一个发出请求后，缓存根据请求保存输出内容的副本 2.缓存的好处 （1）减少不必要的请求 （2）降低服务器的压力，减少服务器的消耗 （3）降低网络延迟，加快页面打开速度（直接读取浏览器的数据）

304是什么 五星推荐

如果面试官问http状态码，这个题被问的可能性非常高，本人在腾讯一面和其他面试中均有问到

网络的五层模型

介绍DNS解析

DNS( Domain Name System)是“域名系统”的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，它用于TCP/IP网络，它所提供的服务是用来将主机名和域名转换为IP地址的工作。DNS就是这样的一位“翻译官”，它的基本工作原理可用下图来表示。

①用户主机上运行着DNS的客户端，就是我们的PC机或者手机客户端运行着DNS客户端了 ②浏览器将接收到的url中抽取出域名字段，就是访问的主机名，比如http://www.baidu.com/, 并将这个主机名传送给DNS应用的客户端 ③DNS客户机端向DNS服务器端发送一份查询报文，报文中包含着要访问的主机名字段（中间包括一些列缓存查询以及分布式DNS集群的工作） ④该DNS客户机最终会收到一份回答报文，其中包含有该主机名对应的IP地址 ⑤一旦该浏览器收到来自DNS的IP地址，就可以向该IP地址定位的HTTP服务器发起TCP连接

DNS劫持

DNS劫持又称域名劫持，是指在劫持的网络范围内拦截域名解析的请求，分析请求的域名，把审查范围以外的请求放行，否则返回假的IP地址或者什么都不做使请求失去响应，其效果就是对特定的网络不能访问或访问的是假网址。其实本质就是对DNS解析服务器做手脚，或者是使用伪造的DNS解析服务器可以通过下图来展示

解决办法 DNS的劫持过程是通过攻击运营商的解析服务器来达到目的。我们可以不用运营商的DNS解析而使用自己的解析服务器或者是提前在自己的App中将解析好的域名以IP的形式发出去就可以绕过运营商DNS解析，这样一来也避免了DNS劫持的问题。

DNS 解析过程

juejin.cn/post/684490…

递归查询 迭代查询 在上一节中，我们知道了DNS的两种查询方法，但实际上，在DNS查询过程中，客户端和服务器也都会加入缓存的机制，这样可以减少查询的次数，加快域名解析过程。当我们在浏览器中输入一个网站时，会发生如下过程

1、浏览器中输入想要访问的网站的域名，操作系统会先检查本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。

2、如果hosts里没有这个域名的映射，客户端会向本地DNS服务器发起查询。本地DNS服务器收到查询时，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析。

3、如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置，采用递归或者迭代查询，直至解析完成。

这就是本文讲的DNS的解析过程内容啦，如果有什么地方不对，欢迎在评论去指正。

DNS解析会出错吗，为什么

会的 DNS是所谓的域名解析，就是把我们平常在浏览器输入的网址，解析成为IP地址，然后进行访问，DNS出错就是域名解析出错了，一般是要看你想要访问的网站是否符合你的DNS的访问条件，是否有在DNS进行注册，没有注册的网站是很容易出现DNS解析错误的，而本机的DNS设置也是会影响DNS解析的效果，还有就是DNS服务器本身也会出问题的，虽然几率不高。所以DNS错误要具体情况具体分析哦。

判断是否出现DNS解析故障的方法点击开始->运行->输入CMD”后回车，输入“nslookup”回车，在输入你的域名，如果出现DNS request timed out，timeout was 2 seconds的提示信息，则说明DNS确实出问题了，如果DNS解析正常的话，会反馈回正确的IP地址。

#####解决DNS解析错误的方法

1：更换本地DNS的方法

目前国内电信运营商通过使用DNS劫持的方法，干扰用户正常上网，使得用户无法访问，（例如弹出广告窗口），所以我一直在使用GoogleDNS，不仅可以解决中国的电信运营商的流氓行为，还可以解决域名无法访问的情况。

小技巧：点击开始->设置->网络连接->本地连接->属性->TCP/IP协议->使用下面的DNS服务器地址，在框中输入“8.8.8.8”和“8.8.4.4”断开，从新连接网络即可，并且没有电信、联通（原网通）等DNS劫持问题。

2：修改HOSTS文件的方法

如果我们希望把某个域名与某个IP绑定，就可以通过修改HOSTS文件的办法：“开始->搜索”，然后查找名叫hosts的文件。或路径为c: windows system32 drivers etc都可。用记事本打开，在下面加入要解析的IP和域名即可。（修改HOSTS文件则是在实在没有办法的时候在用）

小知识：每个windows系统都有个HOSTS文件，它的作用是加快域名解析，方便局域网用户，屏蔽网站，顺利连接系统等功能。

3：清除DNS缓存信息的方法

“开始->运行->输入CMD”，在ipconfig/?中有一个名为/flushdns的参数，这个就是清除DNS缓存信息的命令，执行ipconfig/flushdns命令，当出现“successfullyflushedthednsresolvercache”的提示时就说明当前计算机的缓存信息已经被成功清除。接下来所有的DNS缓存都会重新加载。

小知识：DNS解析就是把你的域名解析成一个ip地址，服务商提供的dns解析就是能够将你的域名解析成相应ip地址的服务器主机。这就是DNS域名解析。

关于DNS域名解析就写到这里了，虽然问题还没有解决，但从中确实也了解了不少DNS的知识，特地分享出来，如果以后哪位遇到这样的问题（最好别遇到），能顺利解决是最好的了。

cookie的引用为了解决什么问题

http无状态问题

常见的web安全及防护原理？

sql注入原理：是将sql代码伪装到输入参数中，传递到服务器解析并执行的一种攻击手法。 XSS（跨站脚本攻击）：往web页面插入恶意的html标签或者js代码。 CSRF(跨站请求伪装）：通过伪装来自受信任用户的请求

formData和原生的ajax有什么区别

与普通的Ajax相比，使用FormData 的最大优点就是可以异步上传二进制文件。

介绍下表单提交，和formData有什么关系

这是HTML5 中新增的API 优点：FormData不仅能读取表单数据，也能自行追加数据

介绍localstorage的API

localStorage, 是一个用来做本地持久化存储的Web Api。 localStorage以键值对的形式存储数据。用法很简单

// 设置
localStorage.setItem('myCat', 'Tom');
// 获取
let cat = localStorage.getItem('myCat');
// 移除
localStorage.removeItem('myCat');
// 移除所有
localStorage.clear();

有几个点需要注意

1、localStorage是以『源(origin)』为维度进行存储的。也就是说，跨域访问其他站点的localStorage是行不通的。 2、localStorage是以字符串的形式保存数据的。 3、对于每一个域，localStorage最多允许存储几M数量级的数据(具体数字因浏览器而异)。

localStorage可以用来做什么

存储登录token，用户信息等数据；本地持久化保存业务数据；保存代码，以提高网站性能。还有本文所要介绍的页面同步。

监听LocalStorage变化

localStorage被改变时(从无到有，从有到无，值改变)，会触发一个storage事件。我们可以在window上监听到这个事件。

window.addEventListener('storage', () => {
  ...
});

window.onstorage = () => {
  ...
};

这里需要注意的是，在改变localStorage的当前页面，是无法监听到storage事件的。如果我同时打开了多个同源的页面: A页面、B页面、C页面，当在A页面中修改localstorage时，B页面和C页面中都可以监听到storage事件，而A页面是不会触发storage事件的。

get和post有什么区别

（1）get在浏览器回退时是无害的，而post会再次提交请求。（记住） （2）get产生的url地址可以被收藏，而post不可以。 （3）get请求会被浏览器主动缓存，而post不会，除非手动设置。（记住） （4）get请求只能进行url编码，而post支持多种编码方式。 （5）get请求参数会被完整保留在浏览器历史记录里，而post中的参数不会被保留。（记住） （6）get请求在url中传送的参数是有长度限制的，而post没有限制。 （7）对参数的数据类型，get只接受ASCII字符，而post没有限制。 （8）get比post更不安全，因为参数直接暴露在url上，所以不能用来传递敏感信息。 （9）get参数通过url传递，post放在request body 中。（记住)

谈谈你对TCP三次握手和四次挥手的理解

详细介绍 juejin.cn/post/684490…

三次握手：

首先解析服务器DNS，找到IP，然后开始建立连接：

1.第一次握手: 建立连接，客户端A发送SYN=1、随机产生Seq=client_isn的数据包到服务器B，等待服务器确认。 2.第二次握手: 服务器B收到请求后确认联机(可以接受数据)，发起第二次握手请求，ACK=(A的Seq+1)、SYN=1，随机产生Seq=client_isn的数据包到A。 3.第三次握手: A收到后检查ACK是否正确，若正确，A会在发送确认包ACK=服务器B的Seq+1、ACK=1，服务器B收到后确认Seq值与ACK值，若正确，则建立连接。

第一次：客户端发送数据包 —— 通知建立链接 第二次：服务端收到请求——确认联机(可以接受数据) 再发送数据包到服务端 第三次：客户端接收到请求如果ACK正确，发送数据包，服务端收到若正确，则建立链接

四次挥手：

1.第一次挥手：TCP发送一个FIN(结束)标识，用来关闭客户到服务端的连接。 2.第二次挥手：服务端收到这个FIN标识，他发回一个ACK(确认)标识，确认收到序号为收到序号+1，和SYN一样，一个FIN将占用一个序号。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。（服务器端继续发送未发送完的数据） 3.第三次挥手：服务端发送一个FIN(结束)标识到客户端，服务端关闭客户端的连接。 4.第四次挥手：客户端发送ACK(确认)标识报文确认，并将确认的序号+1，这样关闭完成。

TCP 有哪些手段保证可靠交付

1、将数据截断为合理的长度。 应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据报长度将保持不变。 2、超时重发 当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。 3、对于收到的请求，给出确认响应 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒。(之所以推迟，可能是要对包做完整校验) 4、校验出包有错，丢弃报文段，不给出响应，TCP发送数据端，超时时会重发数据 TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。 如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。 （希望发端超时并重发） 5、对失序数据进行重新排序，然后才交给应用层 既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。 如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。 6、对于重复数据，能够丢弃重复数据 既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。 7、TCP还能提供流量控制。 TCP连接的每一方都有固定大小的缓冲空间。 TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。TCP使用的流量控制协议是可变大小的滑动窗口协议。

TCP提供一种面向连接的、可靠的字节流服务。 面向连接：意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中，仅有两方进行彼此通信。广播和多播不能用于TCP。 字节流服务：两个应用程序通过TCP连接交换8bit字节构成的字节流。TCP不在字节流中插入记录标识符。我们将这称为字节流服务（bytestreamservice）。 TCP对字节流的内容不作任何解释:TCP对字节流的内容不作任何解释。TCP不知道传输的数据字节流是二进制数据，还是ASCII字符、EBCDIC字符或者其他类型数据。对字节流的解释由TCP连接双方的应用层解释。

TCP如何做拥塞控制

blog.csdn.net/qq_41431406… 1.慢开始 2.拥塞控制 3.快重传 4.快恢复

什么事TCP粘包

什么是TCP粘包问题 TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。

造成TCP粘包的原因 （1）发送方原因 TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量），而Nagle算法主要做两件事。只有上一个分组得到确认，才会发送下一个分组。收集多个小分组，在一个确认到来时一起发送。Nagle算法造成了发送方可能会出现粘包问题

（2）接收方原因 TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

什么时候需要处理粘包现象？ 如果发送方发送的多组数据本来就是同一块数据的不同部分，比如说一个文件被分成多个部分发送，这时当然不需要处理粘包现象 如果多个分组毫不相干，甚至是并列关系，那么这个时候就一定要处理粘包现象了

如何处理粘包现象？ （1）发送方 对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。

（2）接收方 接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。

（2）应用层

`应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。

解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，但是如何判断每条数据的长度呢？ 格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。 发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。

UDP会不会产生粘包问题呢？ TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。

UDP则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。

举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。

TCP 与 UDP 的区别是什么，既然 TCP 是可靠的，那它有啥缺点

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接发邮件

2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付。Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。

3、UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。

4.每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

5、TCP对系统资源要求较多，UDP对系统资源要求较少。

UDP以其简单、传输快的优势，在越来越多场景下取代了TCP,如实时游戏 （1）网速的提升给UDP的稳定性提供可靠网络保障，丢包率很低，如果使用应用层重传，能够确保传输的可靠性。 （2）TCP为了实现网络通信的可靠性，使用了复杂的拥塞控制算法，建立了繁琐的握手过程，由于TCP内置的系统协议栈中，极难对其进行改进。 采用TCP，一旦发生丢包，TCP会将后续的包缓存起来，等前面的包·重传并接收到后再继续发送，延时会越来越大，基于UDP对实时性要求较为严格的情况下，采用自定义重传机制，能够把丢包产生的延迟降到最低，尽量减少网络问题对游戏性造成影响。

TCP 为什么是可靠的

因为它有 ACK，那 tpc 和 udp 相比的话，udp 有什么好处，虽然不可靠，但是为什么还有很多基于 udp 的协议。因为 upd 报文小，udp 头部8个字节，tcp 头部20个字节，而且有些协议也不需要太可靠。

TCP通过校验和，确认应答,重发控制，序号标识，滑动窗口、实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。

如何在 linux 中拿到 TCP 的状态

在服务程序中,对于长连接的服务.经常会出现一些连接异常,比如常见的CLOSE_WAIT.我们可以同过getsockopt函数来获得某个socket的状态。#includestruct tcp_info optval;int nClientFd = CSockTool::connect("192.168.10.4", 8899);int ret= getsockopt(nClientFd, IPPROTO_TCP,TCP_INFO, &optval, &len);if(optval.tcpi_state==TCP_CLOSE_WAIT)//do something//这个方法是在linux上的，其他系统需要查手册。

HTTP 与 TCP 的区别

简单讲解一下http2的多路复用

即在一个TCP连接，即可以同时发送多个请求 在HTTP1.0中，我们经常会使用到雪碧图、使用多个域名等方式来进行优化，都是因为浏览器限制了同一个域名下的请求数量，当页面需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求时，资源需要等待其他资源请求完成后才能继续发送。 HTTP2.0中，有两个概念非常重要：帧（frame）和流（stream）。 帧是最小的数据单位，每个帧会标识出该帧属于哪个流，流是多个帧组成的数据流。 所谓多路复用，即在一个TCP连接中存在多个流，即可以同时发送多个请求，对端可以通过帧中的表示知道该帧属于哪个请求。在客户端，这些帧乱序发送，到对端后再根据每个帧首部的流标识符重新组装。通过该技术，可以避免HTTP旧版本的队头阻塞问题，极大提高传输性能。

http 状态码中 301，302和307有什么区别

介绍HTTPS

HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。

在HTTP协议中有可能存在信息窃取或身份伪装等安全问题 所以：HTTPS主要作用是： （1）对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全; （2）对网站服务器进行真实身份认证。

HTTPS怎么建立安全通道

HTTPS是如何实现加密

https加密过程,证书用途

SSL证书的作用就是实现网站HTTPS化，使网站可信，防劫持、防篡改、防监听。如果网站涉及输入用户名密码等敏感信息的那么https的强大作用就会发挥的淋漓尽致，加密数据并进行身份验证，但在这里一定要说一下，就是DV SSL证书，就是免费的SSL证书一定要慎重使用，我们一直在强调，SSL证书的两大作用加密和身份验证，但免费的SSL证书是没有身份验证这项功能的，因此，免费SSL证书是功能不完整的，使用需慎重。

服务端配置证书 -> 传送证书 -> 客户端解析证书 -> 传送加密信息 -> 服务端解密信息 -> 传输加密后信息 -> 客户端解密信息

HTTP和HTTPS的区别

1、HTTP 的URL 以http:// 开头，而HTTPS 的URL 以https:// 开头 2、HTTP 是不安全的，而 HTTPS 是安全的 3、HTTP 标准端口是80 ，而 HTTPS 的标准端口是443 4、在OSI 网络模型中，HTTP工作于应用层，而HTTPS 的安全传输机制工作在传输层 5、HTTP 无法加密，而HTTPS 对传输的数据进行加密 6、HTTP无需证书，而HTTPS 需要CA机构wosign的颁发的SSL证书

介绍SSL和TLS

SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。 TLS：(Transport LayerSecurity，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。 SSL是Netscape开发的专门用户保护Web通讯的，目前版本为3.0。最新版本的TLS 1.0是IETF(工程任务组)制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，两者差别极小。

介绍 HTTPS 握手过程

1、建立服务器443端口连接 2、SSL握手：随机数，证书，密钥，加密算法 3、发送加密请求 4、发送加密响应 5、关闭SSL 6、关闭TCP

客户端如何验证证书的合法性

1、客户端取出提前内置在手机内部的认证机构的公钥 2、用认证机构的公钥去解密公钥证书里的数字签名 从而得到数字指纹 3、客户端对公钥证书的服务器公钥进行 数字摘要算法 从而生成数字指纹 4、对比客户端自己生成的数字指纹(第3步)和解密得到的数字指纹(第2步)是否一致 如果一致则公钥证书验证通过 就可以进行接下来的握手步骤了

介绍下如何实现 token 加密

JSON Web Token (JWT)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的 www.cnblogs.com/cjsblog/p/9…

1、需要一个secret（随机数） 2、后端利用secret和加密算法(如：HMAC-SHA256)对payload(如账号密码)生成一个字符串(token)，返回前端 3、前端每次request在header中带上token 4、后端用同样的算法解密

介绍下前端加密的常见场景和方法

base64加密、md5加密、sha1加密、des加密

前端加密的意义 在 HTTP 协议下，数据是明文传输，传输过程中网络嗅探可直接获取其中的数据。 如用户的密码和信用卡相关的资料，一旦被中间人获取，会给用户带来极大的安全隐患。另一方面，在非加密的传输过程中，攻击者可更改数据或插入恶意的代码等。HTTPS 的诞生就是为了解决中间人攻击的问题，但如今 HTTPS 的使用情况在国内并不乐观，基本是因为成本或者性能的考量。

将数据进行哈希或使用公钥加密。如果数据被中间人获取，拿到的则不再是明文。设想在如今公共 WIFI 流行的今天，一旦某一个 AP 的流量被攻击者劫持，如果密码和用户名都是明文，那么攻击者将轻而易举的使用这些资料进行 Replay 登录。更糟糕的是很多用户在不同的网站使用相同的账号信息，用户的隐私荡然无存。作为网站服务提供者，网站设计和开发人员应该为用户提供相对安全的服务，这是一种责任也是一种情怀。另外，如果前端使用哈希算法，不仅可以帮助后端分担部分计算压力，还可以增加撞库成本。具体的讨论将在下文继续。

一是使用哈希进行信息摘要，一种是使用非对称加密。在国内的知名站点中，这两种方式都有人使用。接下来我们分别来深入了解加密过程，探讨下如何应对不同的场景。

前端使用非对称加密原理很简单，前后端共用一套加密解密算法，前端使用公钥对数据加密，后端使用私钥将数据解密为明文。中间攻击人拿到密文，如果没有私钥的话是没办法破解的。可能有人会指出加密算法一旦被破解，这一套安全措施就没用了。况且 JavaScript 的生成安全随机数还是个问题，所以其实这是用不了 https 的权衡之计。在没有 https 的情况下，使用 JavaScript 非对称加密或者 插件加密通讯是比较好的替代方法，后者优于前者。

介绍下 HTTPS 中间人攻击

2.中间人攻击 ①SSLStrip （降级攻击）的工作原理及步骤 （1） 先进行中间人攻击来拦截 HTTP 流量。 （2） 将出现的 HTTPS 链接全部替换为 HTTP,同时记下所有改变的链接。 （3） 使用 HTTP 与受害者机器连接。 （4） 同时与合法的服务器建立 HTTPS。 （5） 受害者与合法服务器之间的全部通信经过了代理转发。 （6） 其中，出现的图标被替换成为用户熟悉的“小黄锁”图标，以建立信任。 （7） 这样，中间人攻击就成功骗取了密码、账号等信息，而受害者一无所知。 总而言之，SSLStrip是一种降级攻击。 ②sslsplit（解密攻击）工作原理 工具的主要原理是以中间人的身份将证书插入到客户端和服务器中间，从而截断客户端和服务器之间的数据。 之前我们大多数做的都是针对于80端口的欺骗（http），也就是说，只要是超越了80端口我们就会有点棘手：比如常用的443端口（https），比如465（smtps）和587端口，这些都是通过SSL加密进行数据传输的，简单的80端口监听肯定是什么都拿不到的。这个时候，就体现出SSL证书劫持的作用了。 总而言之，SSLSplit是一种伪造证书攻击。

既然HTTPS那么安全可靠，为何不所有的网站都使用HTTPS

首先，很多人还是会觉得HTTPS实施有门槛，这个门槛在于需要权威CA颁发的SSL证书。从证书的选择、购买到部署，传统的模式下都会比较耗时耗力。 其次，HTTPS普遍认为性能消耗要大于HTTP，因为与纯文本通信相比，加密通信会消耗更多的CPU及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。但事实并非如此，用户可以通过性能优化、把证书部署在SLB或CDN，来解决此问题。举个实际的例子，“双十一”期间，全站HTTPS的淘宝、天猫依然保证了网站和移动端的访问、浏览、交易等操作的顺畅、平滑。通过测试发现，经过优化后的许多页面性能与HTTP持平甚至还有小幅提升，因此HTTPS经过优化之后其实并不慢。除此之外，想要节约购买证书的开销也是原因之一。要进行HTTPS通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。 最后是安全意识。相比国内，国外互联网行业的安全意识和技术应用相对成熟，HTTPS部署趋势是由社会、企业、政府共同去推动的。

http 状态码 502 和 504 有什么区别

http proxy 的原理是什么

blog.csdn.net/hhthwx/arti…

随着 http2 的发展，前端性能优化中的哪些传统方案可以被替代

1、雪碧图 2、资源文件合并

http2 与 http1.1 有什么不同

http1 a、默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求 b、管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应 c、断点续传

实际上就是利用HTTP消息头使用分块传输编码，将实体主体分块传输

http2 1、二进制传输 2、多路复用 3、头部压缩 4、server push 5、更安全

既然 http 是无状态协议，那它是如何保持登录状态

通过 cookie 或者 Authorization header 来传递凭证，在服务端进行认证

在发送 http 请求报文时，Host 是必要的吗

在 Issue 中交流与讨论: 答案解析

是有必要的，因为我们不知道会途径会不会有代理出现， 如果直接到达服务器的话，服务器是可以通过路径知道资源在哪，但是如果通过代理的话，代理无法得知具体服务器是什么地址

http 响应头中如果 content-type 为 application/octet-stream，则代表什么意思

在 Issue 中交流与讨论: 答案解析

代表二进制流，一般用以下载文件

http 向 https 做重定向应该使用哪个状态码

在 Issue 中交流与讨论: 答案解析

一般用作 301 的较为多，但是也有使用 302，如果开启了 HSTS 则会使用 307

如知乎使用了 302，淘宝使用了 301

http 1.1 中的 keep-alive 有什么作用

在 Issue 中交流与讨论: 答案解析

在 http 1.1 中，在响应头中设置 keep-alive 可以在一个 TCP 连接上发送多个 http 请求

避免了重开 TCP 连接的开销 避免了刷新时重新建立 SSL 连接的开销 避免了QPS过大时，服务器的连接数过大

在服务器端使用响应头开启 keep-alive Connection: Keep-Alive Keep-Alive: timeout=5, max=1000

#####56、什么是Http协议无状态协议?怎么解决Http协议无状态协议?

无状态协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息。也就是说，当客户端一次HTTP请求完成以后，客户端再发送一次HTTP请求，HTTP并不知道当前客户端是一个”老用户“。

可以使用Cookie来解决无状态的问题，Cookie就相当于一个通行证，第一次访问的时候给客户端发送一个Cookie，当客户端再次来的时候，拿着Cookie(通行证)，那么服务器就知道这个是”老用户“。

URI和URL的区别

URI，全称是 Uniform Resource Identifiers，即统一资源标识符，用于在互联网上标识一个资源，而 URL 是uniform resource locator，即统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。URI 是一种语义上的抽象概念，可以是绝对的，也可以是相对的，而URL则必须提供足够的信息来定位，是绝对的。

URI = Uniform Resource Identifier 统一资源标志符URL = Uniform Resource Locator 统一资源定位符URN = Uniform Resource Name 统一资源名称大白话，就是URI是抽象的定义，不管用什么方法表示，只要能定位一个资源，就叫URI，本来设想的的使用两种方法定位：1，URL，用地址定位；2，URN 用名称定位。举个例子：去村子找个具体的人（URI），如果用地址：某村多少号房子第几间房的主人 就是URL， 如果用身份证号+名字 去找就是URN了。结果就是 目前WEB上就URL流行开了，平常见得URI 基本都是URL。

常用的HTTP方法有哪些？8种

1.GET
get方法请求指定的页面信息，返回实体主体。该请求是向服务器请求信息，请求参数会跟在url后面，因此，对传参长度有限制的，而且不同浏览器的上限是不同的（2k, 7~8k及其他）。由于get请求直接将参数暴露在url中，因此对于一些带有重要信息的请求可能并不完全合适。 2.POST
post请求是向指定资源提交数据进行处理请求，例如提交表单或者上传文件等。数据被包含在请求体中，POST请求可能会导致新的资源的建立和/或已有资源的修改。post方法没有对传递资源的大小进行限制，往往是取决于服务器端的接受能力，而且，该方法传参安全性稍高些 3.PUT PUT方法是从客户端向服务器传送的数据取代指定的文档的内容。PUT方法的本质是idempotent的方法，通过服务是否是idempotent来判断用PUT 还是 POST更合理，通常情况下这两种方法并没有刻意区分，根据语义使用即可 4.DELETE
请求服务器删除指定的页面，DELETE请求一般会返回3种状态码：200 (OK) - 删除成功，同时返回已经删除的资源202 (Accepted) - 删除请求已经接受，但没有被立即执行（资源也许已经被转移到了待删除区域）204 (No Content) - 删除请求已经被执行，但是没有返回资源（也许是请求删除不存在的资源造成的） 5.OPTIONS
允许客户端查看服务器的性能。（常见的是跨域预检Preflighted Reqeusts方法会采用该方法）。一般来说，开发中用到该方法是用来获取服务器支持的请求类型或者查看服务器类型，来确保接下来发送的请求够安全。该请求方法的响应不能缓存。如果该URI是一个星号（“*”），OPTIONS请求将试图应用于服务器，而不是某个指定资源；如果该URI不是星号，则只能用来获取该资源通信中可用的选项。 6.HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头7.CONNECTHTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器8.TRACE回显服务器收到的请求，主要用于测试或诊断。 7.CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器 8.TRACE 回显服务器收到的请求，主要用于测试或诊断。

HTTPS工作原理

一、首先HTTP请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥（RSA加密）等进行校验； 二、客户端如果校验通过后，就根据证书的公钥的有效， 生成随机数，随机数使用公钥进行加密（RSA加密）； 三、消息体产生的后，对它的摘要进行MD5（或者SHA1）算法加密，此时就得到了RSA签名； 四、发送给服务端，此时只有服务端（RSA私钥）能解密。 五、解密得到的随机数，再用AES加密，作为密钥（此时的密钥只有客户端和服务端知道）。

HTTP优化方案

1、TCP复用：TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端TCP连接上，而HTTP复用则是一个客户端的多个HTTP请求通过一个TCP连接进行处理。前者是负载均衡设备的独特功能；而后者是HTTP 1.1协议所支持的新功能，目前被大多数浏览器所支持。 2、内容缓存：将经常用到的内容进行缓存起来，那么客户端就可以直接在内存中获取相应的数据了。 3、压缩：将文本数据进行压缩，减少带宽 4、SSL加速（SSL Acceleration）：使用SSL协议对HTTP协议进行加密，在通道内加密并加速 5、TCP缓冲：通过采用TCP缓冲技术，可以提高服务器端响应时间和处理效率，减少由于通信链路问题给服务器造成的连接负担。

理解WebSocket协议的底层原理、与HTTP的区别

一、先来说一下Websocket是什么？(websocket与http有什么区别呢)

WebSocket是html5出的东西（协议），并且是一个持久化的协议（下面将会讲到什么是持久化协议） HTTP是不支持持久连接的（长连接，循环连接的不算）

首先HTTP有 1.1 和 1.0 之说，也就是所谓的 keep-alive ，把多个HTTP请求合并为一个，但是 Websocket 其实是一个新协议，简单的说它是HTTP协议上的一种补充，可以通过这样一张图理解

有交集，但是并不是全部。

2 WebSocket和Http的异同点

同：1建立在TCP之上，通过TCP协议来传输数据。 2 都是可靠性传输协议。 3 都是应用层协议。 异：1 WebSocket是HTML5中的协议，支持持久连接，HTTP不支持持久连接 2 HTTP是单向协议，只能由客户端发起，做不到服务器主动向客户端推送信息。

Accept 头部的作用什么，如果服务器不支持怎么办

Accept代表发送端（客户端）希望接受的数据类型 比如：Accept：text/xml; 代表客户端希望接受的数据类型是xml类型 / 表示任何类型，type/* 表示该类型下的所有子类型，type/sub-type。

"Accept",   "image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*"，一大段资源，在最后又加上了*/*，这是为什么？

可以依次制定多个，客户端支持这些类型，并指定了希望得到类型的优先级，如果没有，依次表达意愿 !

Content-Type代表发送端（客户端|服务器发送数据类型。 Content-Type：text/html;  代表发送端发送的数据格式是html。Content-Type：Internet Media Type，互联网媒体类型；也叫MIME类型，在Http协议消息头中，使用Content-Type来表示请求报文中的数据格式类型。

如果没有，就用默认的

CDN的作用和原理

CDN的用途 1、提高用户访问的速度。 2、减轻源站服务器的压力。 3、提升网站的稳定性和安全性。

CDN的原理 1.用户向浏览器输入www.web.com这个域名，浏览器第一次发现本地没有dns缓存，则向网站的DNS服务器请求； 2.网站的DNS域名解析器设置了CNAME，指向www.web.51cdn.com,请求指向了CDN网络中的智能DNS负载均衡系统； 3.智能DNS负载均衡系统解析域名，把对用户响应速度最快的IP节点返回给用户； 4.用户向该IP节点（CDN服务器）发出请求； 5.由于是第一次访问，CDN服务器会向原web站点请求，并缓存内容； 6.请求结果发给用户。 原理：当用户访问加入CDN服务的网站时，域名解析请求将最终交给全局负载均衡DNS进行处理，全局负载均衡DNS通过一组预先定义好的策略，将当时最接近用户的节点地址提供给用户，使用户能够得到快速的服务。

CDN分类 1、按内容区别     1）页面加速：只能加速静态资源，如HTML，CSS，JS，图片等。     2）流媒体加速：mp4/avi/mpeg等视频文件，通过流媒体服务器进行切片，存在视频文件服务器中，由plist.xml,1.ts,2.ts,切片加密。     3）大文件加速：安装包，补丁，安卓APK，压缩包等。     4）应用协议加速：BT下载工具通过多台分布各地的代理服务器，去源站下载数据问题，然后用户去代理服务器下载。

安装推送的类型     1）主动推送：由源站服务器，负责分发内容至CDN边缘节点，然后智能DNS引导用户去就近CDN节点。     2）被动推送：用户通过智能DNS，访问到就近CDN节点，然后索引文件，本地没发现该文件，然后本地就从源站请求数据，然后缓存到本地，再推送给用户。

介绍下数字签名的原理

www.cnblogs.com/yaowen/p/91…

签名的作用简单来说就是证明某个文件上的内容确实是我写的/我认同的，别人不能冒充我的签名（不可伪造），我也不能否认上面的签名是我的（不可抵赖）。那么数字签名又是靠什么保证不可伪造和不可抵赖两个特性呢？ 答案是利用公钥加密系统。常用的签名算法有

RSA，基于大整数分解问题 DSA，基于离散对数问题 ECDSA，属于DSA的一个变种，基于椭圆曲线上的离散对数问题

其中RSA是上述几个算法中最容易实现数字签名的。

网站认证 首先最常见的用处就是用来认证一个网站的身份。 比如我打开百度，百度是怎么保证显示在我眼前的网页就一定是百度生成的，不是其他人修改的呢？就是借助数字签名来实现的。用IE浏览器打开百度，点击地址栏旁边的小锁，再点击查看证书，就可以看到百度主页的数字签名证书了。所谓证书，其实是对公钥的封装，在公钥的基础上添加颁发者、有效期等信息。

但是数字签名不是万能的。事实上不管是浏览器的数字签名还是代码的数字签名，都依赖于系统或者浏览器内置的根证书（公钥），如果电脑本身已经中毒或者被入侵，那么这些根证书可以被轻易添加或者修改，这时的数字签名的安全性可以说是荡然无存了。

比特币 比特币是一种匿名的数字货币，它的身份认证是基于ECDSA。比特币的账户地址就是对公钥等信息计算摘要得到的，向全世界公布。比特币账户地址不包含你的个人信息（姓名、住址、电话号码之类的），确认你是账户拥有者的唯一办法就是看你有没有账户对应的私钥。如果账户私钥丢失，那么你将永远地失去里面的钱；一旦私钥被黑客盗取，账户里面的钱就完全归黑客所有。

RESTful常用的Method

1、GET[select]  请求会向数据库发索取数据的请求，从而来获取信息,其只是用来查询一下数据，不会修改、增加数据，不会影响资源的内容。无论进行多少次操作，结果都是一样的。 2、PUT[update]  请求是向服务器端发送数据的，从而改变信息，其用来修改数据的内容，但是不会增加数据的种类等，无论进行多少次PUT操作，其结果并没有不同。 3、POST[insert]请求同PUT请求类似，都是向服务器端发送数据的，但是该请求会改变数据的种类等资源.几乎目前所有的提交操作都是用POST请求的。 4、DELETE[delete]请求是用来删除某一个资源的。 POST主要作用在一个集合资源之上的（url），而PUT主要作用在一个具体资源之上的（url/xxx）.如URL可以在客户端确定，那么可使用PUT，否则用POST。

一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查，改，增，删4个操作。

JWT 细节，适用场景

JSON Web Token（JWT）是一个开放式标准（RFC 7519），它定义了一种紧凑（Compact）且自包含（Self-contained）的方式，用于在各方之间以JSON对象安全传输信息。这些信息可以通过数字签名进行验证和信任。可以使用秘密（使用HMAC算法）或使用RSA的公钥/私钥对对JWT进行签名。虽然JWT可以加密以提供各方之间的保密性，但我们将重点关注已签名的令牌。签名的令牌可以验证其中包含的索赔的完整性，而加密令牌隐藏来自其他方的索赔。当令牌使用公钥/私钥对进行签名时，签名还证明只有持有私钥的方是签名方。

Compact（紧凑） ：由于它们尺寸较小，JWT可以通过URL，POST参数或HTTP标头内发送。另外，尺寸越小意味着传输速度越快。Self-contained（自包含） :有效载荷（Playload）包含有关用户的所有必需信息，避免了多次查询数据库。

2. JWT适用场景 Authentication（鉴权） ：这是使用JWT最常见的情况。一旦用户登录，每个后续请求都将包含JWT，允许用户访问该令牌允许的路由，服务和资源。单点登录是当今广泛使用JWT的一项功能，因为它的开销很小，并且能够轻松地跨不同域使用。 Information Exchange（信息交换） ：JSON Web Tokens是在各方之间安全传输信息的好方式。因为JWT可以签名：例如使用公钥/私钥对，所以可以确定发件人是他们自称的人。此外，由于使用标头和有效载荷计算签名，因此您还可以验证内容是否未被篡改。注册验证 总结 在 web 应用中，使用 jwt 代替 session 存在不小的风险，你至少得解决本文中提及的那些问题，绝大多数情况下，传统的 cookie-session 机制工作得更好。jwt 适合做简单的 restful api 认证，颁发一个固定有效期的 jwt，降低 jwt 暴露的风险，不要对 jwt 做服务端的状态管理，这样才能体现出 jwt 无状态的优势。

JWT优缺点

www.cnblogs.com/yuanrw/p/10…

jwt的认证原理

一个jwt实际上就是一个字符串，它由三部分组成，头部、载荷与签名，这三个部分都是json格式。

头部（Header）:头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等。

{
  "typ": "JWT",
  "alg": "HS256"
}

在这里，我们说明了这是一个JWT，并且我们所用的签名算法是HS256算法。

载荷（Payload）

载荷可以用来放一些不敏感的信息。

{
    "iss": "John Wu JWT",
    "iat": 1441593502,
    "exp": 1441594722,
    "aud": "www.example.com",
    "sub": "jrocket@example.com",
    "from_user": "B",
    "target_user": "A"
}

这里面的前五个字段都是由JWT的标准所定义的。

• iss: 该JWT的签发者
• sub: 该JWT所面向的用户
• aud: 接收该JWT的一方
• exp(expires): 什么时候过期，这里是一个Unix时间戳
• iat(issued at): 在什么时候签发的

把头部和载荷分别进行Base64编码之后得到两个字符串，然后再将这两个编码后的字符串用英文句号.连接在一起（头部在前），形成新的字符串

签名（signature）

最后，我们将上面拼接完的字符串用HS256算法进行加密。在加密的时候，我们还需要提供一个密钥（secret）。加密后的内容也是一个字符串，最后这个字符串就是签名，把这个签名拼接在刚才的字符串后面就能得到完整的jwt。header部分和payload部分如果被篡改，由于篡改者不知道密钥是什么，也无法生成新的signature部分，服务端也就无法通过，在jwt中，消息体是透明的，使用签名可以保证消息不被篡改。

区别和优缺点

基于session和基于jwt的方式的主要区别就是用户的状态保存的位置，session是保存在服务端的，而jwt是保存在客户端的。

jwt的优点

1. 可扩展性好

应用程序分布式部署的情况下，session需要做多机数据共享，通常可以存在数据库或者redis里面。而jwt不需要。

2. 无状态

jwt不在服务端存储任何状态。RESTful API的原则之一是无状态，发出请求时，总会返回带有参数的响应，不会产生附加影响。用户的认证状态引入这种附加影响，这破坏了这一原则。另外jwt的载荷中可以存储一些常用信息，用于交换信息，有效地使用 JWT，可以降低服务器查询数据库的次数。

** jwt的缺点**

1. 安全性

由于jwt的payload是使用base64编码的，并没有加密，因此jwt中不能存储敏感数据。而session的信息是存在服务端的，相对来说更安全。

2. 性能

jwt太长。由于是无状态使用JWT，所有的数据都被放到JWT里，如果还要进行一些数据交换，那载荷会更大，经过编码之后导致jwt非常长，cookie的限制大小一般是4k，cookie很可能放不下，所以jwt一般放在local storage里面。并且用户在系统中的每一次http请求都会把jwt携带在Header里面，http请求的Header可能比Body还要大。而sessionId只是很短的一个字符串，因此使用jwt的http请求比使用session的开销大得多。

3. 一次性

无状态是jwt的特点，但也导致了这个问题，jwt是一次性的。想修改里面的内容，就必须签发一个新的jwt。

（1）无法废弃

通过上面jwt的验证机制可以看出来，一旦签发一个jwt，在到期之前就会始终有效，无法中途废弃。例如你在payload中存储了一些信息，当信息需要更新时，则重新签发一个jwt，但是由于旧的jwt还没过期，拿着这个旧的jwt依旧可以登录，那登录后服务端从jwt中拿到的信息就是过时的。为了解决这个问题，我们就需要在服务端部署额外的逻辑，例如设置一个黑名单，一旦签发了新的jwt，那么旧的就加入黑名单（比如存到redis里面），避免被再次使用。

（2）续签

如果你使用jwt做会话管理，传统的cookie续签方案一般都是框架自带的，session有效期30分钟，30分钟内如果有访问，有效期被刷新至30分钟。一样的道理，要改变jwt的有效时间，就要签发新的jwt。最简单的一种方式是每次请求刷新jwt，即每个http请求都返回一个新的jwt。这个方法不仅暴力不优雅，而且每次请求都要做jwt的加密解密，会带来性能问题。另一种方法是在redis中单独为每个jwt设置过期时间，每次访问时刷新jwt的过期时间。

可以看出想要破解jwt一次性的特性，就需要在服务端存储jwt的状态。但是引入 redis 之后，就把无状态的jwt硬生生变成了有状态了，违背了jwt的初衷。而且这个方案和session都差不多了。

总结

适合使用jwt的场景：

• 有效期短
• 只希望被使用一次

比如，用户注册后发一封邮件让其激活账户，通常邮件中需要有一个链接，这个链接需要具备以下的特性：能够标识用户，该链接具有时效性（通常只允许几小时之内激活），不能被篡改以激活其他可能的账户，一次性的。这种场景就适合使用jwt。

而由于jwt具有一次性的特性。单点登录和会话管理非常不适合用jwt，如果在服务端部署额外的逻辑存储jwt的状态，那还不如使用session。基于session有很多成熟的框架可以开箱即用，但是用jwt还要自己实现逻辑。

如何应对流量劫持

虽然互联网经过多年的发展，可是网站使用的底层协议仍是 HTTP，HTTP 作为一种明文传播协议，所有的传输数据都是明文，我们都知道在通信中使用明文(不加密) 内容可能会被窃听，同时网站存在被劫持的风险。面对 Web 流量劫持， 1、首先我们可以在网站层面限制读写权限，限制恶意代码的写入， 2、其次可以通过公有 DNS 和 HttpDNS 来防止恶意 DNS 劫持。 3、全站开启 HTTPS，加密数据传输，可以有效防止数据泄漏，同时解决流量劫持的问题。

cookie的存放位置，删除机制。

目前有些 Cookie 是临时的，有些则是持续的。临时的 Cookie 只在浏览器上保存一段规定的时间，一旦超过规定的时间，该 Cookie 就会被系统清除 [2]持续的 Cookie 则保存在用户的 Cookie 文件中，下一次用户返回时，仍然可以对它进行调用。在 Cookie 文件中保存 Cookie，有些用户担心 Cookie 中的用户信息被一些别有用心的人窃取，而造成一定的损害。其实，网站以外的用户无法跨过网站来获得 Cookie 信息。如果因为这种担心而屏蔽 Cookie，肯定会因此拒绝访问许多站点页面。因为，当今有许多 Web 站点开发人员使用 Cookie 技术，例如 Session 对象的使用就离不开 Cookie 的支持

Cookie在生成时就会被指定一个Expire值，这就是Cookie的生存周期，在这个周期内Cookie有效，超出周期Cookie就会被清除。有些页面将Cookie的生存周期设置为“0”或负值，这样在关闭浏览器时，就马上清除Cookie，不会记录用户信息，更加安全。

Cookie并不提供修改、删除操作。如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。如果要删除某个Cookie，只需要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。注意是0而不是负数。负数代表其他的意义。读者可以通过上例的程序进行验证，设置不同的属性。

注意：修改、删除Cookie时，新建的Cookie除value、maxAge之外的所有属性，例如name、path、domain等，都要与原Cookie完全一样。否则，浏览器将视为两个不同的Cookie不予覆盖，导致修改、删除失败。

为什么有时候删除不了cookie? 可能是因为删除cookie时没有指定该cookie的path和domain，导致找不到这个cookie来设置过期时间而无法删除