1、讲一讲三次握手四次挥手
- 客户端和服务端之间通过三次握手建立连接，四次挥手释放连接。
- 三次握手： 客户端先向服务端发起一个SYN包，进入SYN_SENT状态，服务端收到SYN后，给客户端返回一个ACK+SYN包，表示已经收到SYN，并进入SYN_RECEIVE状态，最后客户端再向服务端发送一个ACK包表示确认，双方进入连接状态。
- 延伸1：为什么不是两次握手而是三次？
答：如果客户端发出的一个请求报文并没有丢失，而是在某个网络结点长时间滞留，以致延误到连接释放以后的某个时间才到达客户端，本来这就是一个失效的报文段，但是服务端误认为这是客户端再次发出的一个新的连接请求，于是向客户端发出确认报文段，如果此时只需要两次握手，那么建立连接成功，服务端一直等待客户端发送的数据，实际上客户端并不会发送数据。这样服务端的资源就拜拜浪费了。
-
四次挥手： 首先客户端向服务端发送一个FIN包，进入FIN_WAIT1状态，服务端收到后，向客户端发送ACK确认包，进入CLOSE_WAIT状态，然后客户端收到ACK包后进入FIN_WAIT2状态，然后服务端把自己剩余没传完的数据发送到客户端，发送完毕后再发送一个FIN+ACK包，进入LAST_ACK（最后确认）状态，客户端收到FIN+ACK包后，再向服务端发送ACK包，再等待两个周期后关闭连接。
-
延伸2：为什么要等待两个周期？
答：之所以等待两个周期是因为最后向服务端发送的ACK包可能会丢失，如果不等待2个周期的话，服务端在没收收到ACK包之前，会不停的重复发送FIN包而不关闭，所以得等待两个周期
2、网络TCP/IP四层模型，TCP属于哪一层？
应用层、传输层、网络层、数据链路层 TCP属于传输层
3、http1.0、http1.1 、http2有什么区别？
-
http0.9只能进行get请求
-
http1.0增加了post、head、option、put、delete等
-
http1.1增加了长连接keep-alive，host域、新的状态码缓存头等。
-
长连接： 在一个TCP连接上可以传送多个http请求，减少了建立和关闭连接的消耗和延迟，在http1.1中默认开启长连接keep-alive，一定程度上弥补了http1.0每次请求都要创建连接的缺点，http1.0需要使用keep-alive参数告诉服务器需要建立一个长连接。
-
节省带宽： http1.0中存在一些浪费带宽的现象，例如客户端只需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。http1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了，从而节省了带宽。
-
host域： 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname），HTTP1.0没有host域。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误（400 Bad Request）。
-
缓存处理： 在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
-
错误通知的管理 在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
-
-
http2 二进制传输、 多路复用，头部压缩，服务器推送
-
二进制传输 HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x 的文本格式，二进制协议解析起来更高效。关键之一就是在应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层。在二进制分帧层中， HTTP2 会将所有传输的信息分割为更小的消息和帧(frame)，并对它们采用二进制格式的编码。
-
多路复用 HTTP/2的多路复用代替原来的 HTTP1.x的序列和阻塞机制，所有相同域名的请求的都可以通过一个 TCP 连接并发完成。 HTTP 1.x 中，如果想并发多个请求，必须使用多个 TCP 链接，且浏览器为了控制资源，还会对单个域名有 6-8个的TCP链接请求限制，在 HTTP/2 中，有了二进制分帧之后，HTTP /2 不再依赖 TCP 链接去实现多流并行了
-
头部压缩 在HTTP1.1中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。随着Web功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容，完全是一种浪费。
HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。同时客户端和服务器端同时维护一张头信息表，所有字段都记录在这张表中，这样后面每次传输只需要传输表里面的索引 Id 就行，通过索引 ID 就可以知道表头的值了
- 服务器推送 服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。
-
4、HTTP以及 HTTPs 的区别
-
HTTPs 协议需要到 CA 申请证书，一般免费证书较少，因而需要一定费用。
-
HTTP 是超文本传输协议，信息是明文传输，HTTPs 则是具有安全性的 SSL 加密或TLS加密的传输协议。
-
HTTP 和 HTTPs 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
-
HTTP 的连接很简单，是无状态的；即协议对客户端没有状态存储，对事物处理没有记忆功能，比如访问一个网站需要反复进行登录操。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。
-
延伸：针对无状态的一些解决策略？
- 通过cookie/session技术。
- http1.1的长连接 (keep-alive)，只要任意一端没有明确提出断开连接，则保持TCP连接状态，在请求首部字段中Connection: keep-alive即为表明使用了持久连接
5、https的实现原理？
1 客户端发起一个https的请求，把自身支持的一系列Cipher Suite（密钥算法套件，简称Cipher）发送给服务端
2 服务端，接收到客户端所有的Cipher后与自身支持的对比，如果不支持则连接断开，反之则会从中选出一种加密算法和HASH算法
以证书的形式返回给客户端 证书中还包含了 公钥 颁证机构 网址 失效日期等等。
3 客户端收到服务端响应后会做以下几件事
3.1 验证证书的合法性
颁发证书的机构是否合法与是否过期，证书中包含的网站地址是否与正在访问的地址一致等。证书验证通过后，在浏览器的地址栏会加上一把小锁(每家浏览器验证通过后的提示不一样 不做讨论)
3.2 生成随机密码
如果证书验证通过，或者用户接受了不授信的证书，此时浏览器会生成一串随机数，然后用证书中的公钥加密。
3.3 HASH握手信息
用最开始约定好的HASH方式，把握手消息取HASH值， 然后用 随机数加密 “握手消息+握手消息HASH值(签名)” 并一起发送给服务端。在这里之所以要取握手消息的HASH值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。
4 服务端拿到客户端传来的密文，用自己的私钥来解密消息取出随机数密码，再用随机数密码 解密 握手消息与HASH值，并与传过来的HASH值做对比确认是否一致。然后用随机密码加密一段握手消息(握手消息+握手消息的HASH值 )给客户端
5 客户端用随机数解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密 。因为这串密钥只有客户端和服务端知道，所以即使中间请求被拦截也是没法解密数据的，以此保证了通信的安全
- 延伸 ：Https哪些涉及对称算法和非对称算法？
-
非对称加密算法：RSA，DSA/DSS 。在客户端与服务端相互验证的过程中用的是非对称加密
-
对称加密算法：AES，RC4，3DES。客户端与服务端相互验证通过后，以随机数作为密钥时，就是对称加密
-
6、怎么删除cookie？
把它的Max-age设置为0，也就是立马失效，也就是删除
7、http缓存
缓存分为强缓存和协商缓存
强缓存：在浏览器请求加载资源时，服务器先看看请求头的cache-control里的max-age，判断数据有没有过期，如果没有直接使用该缓存 ，有些用户可能会在没有过期的时候就点了刷新按钮，这个时候浏览器就回去请求服务端，要想避免这样做，可以在cache-control里面加一个immutable.
- public 允许客户端和虚拟服务器缓存该资源，cache-control中的一个属性
- private 只允许客户端缓存该资源
- no-storage 不允许强缓存，可以协商缓存
- no-cache 不允许缓存
协商缓存就是先询问服务器缓存是否可以用，再判断是否用缓存
- 浏览器第一次请求，服务器在respone的header加上Last-Modified（最后修改时间）
- 浏览器再次请求，request的header上会加上If-Modified-Since,该值为缓存之前返回的Last-Modify
- 服务端拿到这两个值对比，如果相等的话，则命中缓存，返回304 Not Modified，但是不会返回资源内容，否则, 如果 Last-Modify > if-Modify-Since, 则会给出200响应，从服务器加载资源，并且更新Last-Modify为新的值。
8、列举三种禁止浏览器缓存的头字段，并写出响应的设置值
-
Expires：HTTP/1.0
Expires：0
告诉浏览器把回送的资源缓存多长时间 -1或0则是不缓存 简要：添加Expires头能有效的利用浏览器的缓存能力来改善页面的性能，能在后续的页面中有效避免很多不必要的Http请求，WEB服务器使用Expires头来告诉Web客户端它可以使用一个组件的当前副本，直到指定的时间为止。 例如：Expires：Thu，15 Apr 2010 20：00：00 GMT; 他告诉浏览器缓存有效性持续到2010年4月15日为止，在这个时间之内相同的请求使用缓存，这个时间之外使用http请求。
-
Cache-Control
Cache-Control：no-cache Cathe-Control：max-age=315360000
Expires有一个非常大的缺陷，它使用一个固定的时间，要求服务器与客户端的时钟保持严格的同步，并且这一天到来后，服务器还得重新设定新的时间。 HTTP1.1引入了Cathe-Control，它使用max-age指定组件被缓存多久，从请求开始在max-age时间内浏览器使用缓存，之外的使用请求，这样就可以消除Expires的限制， 如果对浏览器兼容性要求很高的话，可以两个都使用。
-
Pragma： HTTP/1.0
Pragma：no-cache
-
Etag / If-None-Match
（1）Etag是服务器响应请求时，返回当前资源文件的一个唯一标识/哈希值(由服务器生成的)
（2）If-None-Match是客户端再次发起该请求时，携带上次请求返回的唯一标识Etag值，通过此字段值告诉服务器该资源上次请求返回的唯一标识值。服务器收到该请求后，发现该请求头中含有If-None-Match，则会根据If-None-Match的字段值与该资源在服务器的Etag值做对比，一致则返回304，代表资源无更新，继续使用缓存文件；不一致则重新返回资源文件，状态码为200，如下。
注：Etag / If-None-Match优先级高于Last-Modified / If-Modified-Since，同时存在则只有Etag / If-None-Match生效。
-
延伸：ETag与Last-Modified/If-Modified-Since区别？
-
Etag是lastModifed的补充，Etag主要为了解决Last-Modified无法解决的一些问题。有些动态生成的内容就可以用hash做etag控制缓存了
-
生成Etag是需要后台写一个算法生成的，比如取文件的hashCode或MD5，需要多一点运算。而取文件的lastModified更快，并且是web服务器自动支持的。ETag可能会给服务器带来更大的开销，所以一般就用默认的Last-Modified就行。有需要的情况下才用Etag，什么是有需要的情况？
-
一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET；
-
某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)；
-
某些服务器不能精确的得到文件的最后修改时间。
-
-
9、讲讲304缓存
304是HTTP状态码，服务器用来标识这个文件没修改，不返回内容，浏览器在接收到个状态码后，会使用浏览器已缓存的文件。
10、tcp 和 udp 的区别和使用场景？
1）连接与无连接
TCP是面向连接的，需要三次握手四次挥手请求连接，UDP是面向无连接的。因此TCP更适合于消息的多播发布可以向多个点传送消息同时也导致UDP适用于快速传输的协议，对信息的时实性要求严格的协议。由于UDP的速度快，所以适合于在线视频媒体，电话视频聊天，qq聊天，电视广播，多人在线游戏这些项目。（为了时实性牺牲写可靠性，即使有包丢失，可能会导致语音不清楚，视频不清楚等问题，不过没有影响）
2）可靠性
TCP是可靠的传输协议，一旦传输过程中丢包的话会进行重传，UDP是不可靠的。因此导致UDP不适合金融支付这方面要求可靠性的项目。（因为UDP没有超时重传的机制不能保证可靠性）。
3）有序性
TCP协议可以保证有序性，UDP协议不保证。
消息将会以从服务端发出的顺序发送给客户端，尽管消息可能到网络的另一端时是无顺序的，TCP协议会为你排好序）但是即使UDP不可靠，无序，但是我们可以将这些要求转移给上层应用来实现，不仅降低了执行时间，而且使质量得到保证。（例如可以通过给UDP协议使用序列号和重传机制来改善它的这两个缺点）。
4）重量级与轻量级
TCP协议是重量级，UDP协议是轻量级
因为TCP要保证可靠性和有序性，所以TCP数据报报头的信息量大，报头大小是20个字节，UDP报头的大小是8个字节。所以TCP占用的系统的开销大。UDP实时性高，比TCP工作效率高。因为不需要建立连接，更不需要复杂的握手挥手以及复杂的算法，也没有重传机制
5）拥塞和流量控制
TCP有流量控制，UDP没有。
TCP通常在发送包之前会测试网络的快慢情况，就好比我们在linux中投的ping命令，通过往返的时间和丢包率来评估网路的状况，来调动滑动窗口的大小。（这项机制增加了TCP的可靠性）
6）数据边界
TCP协议没有数据边界，UDP有
因此TCP容易发生粘包的现象。在UDP中数据包是单独发送的，只有当他们到达时才会再次集成，包有明确的界限来判断哪些包已经收到。
- 延伸：TCP是通过什么机制保障可靠性的?
从四个方面进行回答，ACK确认机制、超时重传、滑动窗口以及流量控制
11、quic 基于 udp 怎么保证可靠性？
虽然UDP不提供可靠的传输，但QUIC在基于UDP之上增加了一层带来可靠性的层，它提供了数据包重传，拥塞控制，调整传输节奏，以及其它一些TCP中存在的特性。只要连接没有中断，从QUIC一端传输的数据迟早会出现在另一端，这是可靠的。
12、从浏览器输入url后都经历了什么？
- 先进行DNS域名解析，先查看本地hosts文件，查看有没有当前域名对应的ip地址，若有直接发起请求，没有的话会在本地域名服务器去查找，该查找属于递归查找，如果本地域名服务器没查找到，会从根域名服务器查找，该过程属于迭代查找，根域名会告诉你从哪个与服务器查找，最后查找到对应的ip地址后把对应规则保存到本地的hosts文件中。
- 应用层客户端发起http请求
- 传输层TCP传输报文(3次握手)
- 网络层IP协议查询MAC地址
- 数据到达数据链路层
- 服务器接收数据
- 服务器响应请求，可能返回304也可能返回200
- 返回304说明客户端缓存可用，直接使用客户端缓存即可
- 返回200的话会同时返回相应文件
- 客户端自上而下执行代码。进行DOM渲染和Render树渲染
- 获取html并解析为Dom树
- 解析css并形成一个cssom(css树)
- 将cssom和dom合并成渲染树(render树)
- 进行布局(layout)
- 进行绘制(painting)
- 回流重绘
13、CDN缓存原理介绍
CDN就是内容分发网络，各地部署多套静态存储服务，自动选择最近的节点内容，不再请求原始服务器，适合存储更新很少的静态内容。
传统访问：用户在浏览器输入域名发送请求-解析域名获取服务器IP地址-根据IP地址找到对应的服务器-服务器响应并返回数据
使用CDN访问：
- 用户输入 URL，浏览器调用域名解析库对域名进行解析
- 域名解析库 返回该域名对应的 CNAME，此时浏览器需要再次对获得的 CNAME 进行解析，才能得到 CDN 缓存服务器的 IP 地址。在此过程中全局负载均衡 DNS 解析服务器会将用户的访问请求定位到离用户最近、负载最轻的 CDN 缓存服务器上。这种技术也被称为“DNS 重定向”
- 再次解析后，浏览器得到 CDN 缓存服务器的实际 IP 地址，向缓存服务器发起请求。
- 缓存服务器根据浏览器提供的域名，通过内部 DNS 解析得到此域名源服务器的真实 IP 地址，再由缓存服务器向该服务器发起访问请求。
- 缓存服务器拿到数据后，一方面将数据发回浏览器，另一方面进行本地保存，以备后用。之后再次访问，数据将从 CDN 缓存服务器中被返回。CDN 不会永久保存数据，可以设置 CDN 的刷新频率，来达到数据的更新。
- 浏览器得到由缓存服务器发回的数据，并将其显示出来。至此，完成整个域名访问的过程。
14、npm 模块安装机制，为什么输入npm install就可以自动安装对应模块
- 发出npm install命令
- 查询node_modules目录之中是否已经存在指定模块
- 若存在，不再重新安装
- 若不存在
- npm 向 registry 查询模块压缩包的网址
- 下载压缩包，存放在根目录下的.npm目录里
- 解压压缩包到当前项目的node_modules目录
15、常见响应头
| 响应头 | 说明 |
|---|---|
| Allow | 服务器支持哪些请求方法（如GET、POST等）。 |
| Content-Encoding | 文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet应该通过查看Accept-Encoding头（即request.getHeader("Accept-Encoding")）检查浏览器是否支持gzip，为支持gzip的浏览器返回经gzip压缩的HTML页面，为其他浏览器返回普通页面。 |
| Content-Length | 表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入 ByteArrayOutputStream，完成后查看其大小，然后把该值放入Content-Length头，最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容。 |
| Content-Type | 表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。由于经常要设置Content-Type，因此HttpServletResponse提供了一个专用的方法setContentType。 |
| Date | 当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。 |
| Expires | 应该在什么时候认为文档已经过期，从而不再缓存它？ |
| Last-Modified | 文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。Last-Modified也可用setDateHeader方法来设置。 |
| Set-Cookie | 设置和页面关联的Cookie。Servlet不应使用response.setHeader("Set-Cookie", ...)，而是应使用HttpServletResponse提供的专用方法addCookie |
| WWW-Authenticate | 客户应该在Authorization头中提供什么类型的授权信息？在包含401（Unauthorized）状态行的应答中这个头是必需的。例如，response.setHeader("WWW-Authenticate", "BASIC realm=＼"executives＼"")。注意Servlet一般不进行这方面的处理，而是让Web服务器的专门机制来控制受密码保护页面的访问（例如.htaccess）。 |
| Refresh | 表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader("Refresh", "5"; URL="xxx")让浏览器读取指定的页面。注意这种功能通常是通过设置HTML页面HEAD区的＜META HTTP-EQUIV="Refresh" CONTENT=5;URL="xxx"＞实现，这是因为，自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。但是，对于Servlet来说，直接设置Refresh头更加方便。注意Refresh的意义是"N秒之后刷新本页面或访问指定页面"，而不是"每隔N秒刷新本页面或访问指定页面"。因此，连续刷新要求每次都发送一个Refresh头，而发送204状态代码则可以阻止浏览器继续刷新，不管是使用Refresh头还是＜META HTTP-EQUIV="Refresh" ...＞。注意Refresh头不属于HTTP 1.1正式规范的一部分，而是一个扩展，但Netscape和IE都支持它。 |
| Location | 表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。 |
16、请求头常见参数
| Header | 说明 |
|---|---|
| Accept | 指定客户端能够接收的内容类型 |
| Accept-Charset | 浏览器可以接受的字符编码集。 |
| Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 |
| Accept-Language | 浏览器可接受的语言 |
| Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 |
| Authorization | HTTP授权的授权证书 |
| Cache-Control | 指定请求和响应遵循的缓存机制 |
| Connection | 表示是否需要持久连接。（HTTP 1.1默认进行持久连接） |
| Cookie | HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。 |
| Content-Length | 请求的内容长度 |
| Content-Type | 请求的与实体对应的MIME信息 |
| Date | 请求发送的日期和时间 |
| Expect | 请求的特定的服务器行为 |
| Host | 指定请求的服务器的域名和端口号 |
| If-Match | 只有请求内容与实体相匹配才有效 |
| If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码 |
| If-None-Match | 如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变 |
| If-Range | 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag |
| If-Unmodified-Since | 只在实体在指定时间之后未被修改才请求成功 |
| Pragma | 用来包含实现特定的指令 |
| Proxy-Authorization | 连接到代理的授权证书 |
| Range | 只请求实体的一部分，指定范围 |
| Referer | 先前网页的地址，当前请求网页紧随其后,即来路 |
| User-Agent | User-Agent的内容包含发出请求的用户信息 |
| Via | 通知中间网关或代理服务器地址，通信协议 |
17、cookie具体怎么实现？
客户端请求服务器后，如果服务器需要记录用户状态，服务器会在响应信息中包含一个Set-Cookie的响应头，客户端会根据这个响应头存储Cookie信息。再次请求服务器时，浏览器会发送该Cookie（Cookie未到期时）到服务器，服务器对该凭据进行验证，合法时使用户不必输入用户名和密码就可以直接登录。
Cookie总时由用户客户端进行保存的（一般是浏览器），按其存储位置可分为：内存式Cookie和硬盘式Cookie。
- 内存式Cookie存储在内存中，浏览器关闭后就会消失，由于其存储时间较短，因此也被称为非持久Cookie或会话Cookie。
- 硬盘式Cookie保存在硬盘中，其不会随浏览器的关闭而消失，除非用户手工清理或到了过期时间。由于硬盘式Cookie存储时间是长期的，因此也被称为持久Cookie。
18、你了解哪些请求方法？
| 方法 | 描述 |
|---|---|
| Get | 请求页面信息，返回实体主体 |
| HEAD | 类似get请求，只不过返回的响应中没有具体内容，用于获取报头 |
| POST | 提交数据，数据被包含在请求体中，post请求可能会导致新的资源的建立或已有资源的修改 |
| PUT | 从客户端向服务器传送的数据取代指定的文档内容 |
| DELETE | 删除资源 |
| OPTIONS | 可以用于跨域的预请求，或者用来获取服务器支持的请求方式 |
| TEACE | 回显服务器收到的请求，主要用于测试或诊断 |
19、如何禁止js访问cookie
设置HttpOnly属性，这样js脚本将无法读取cookie信息，能够有效防止XSS攻击
20、怎么做DNS域解析？
DNS Prefetch 应该尽量的放在网页的前面，推荐放在<meta charset="UTF-8">后面。具体使用方法如下：
<meta http-equiv="x-dns-prefetch-control" content="on">
<!-- <meta>信息告诉浏览器，当前页面要做DNS预解析-->
<link rel="dns-prefetch" href="//www.zhix.net">
<!-- <link>标签来强制对DNS预解析； -->
<link rel="dns-prefetch" href="//api.share.zhix.net">
<link rel="dns-prefetch" href="//bdimg.share.zhix.net">
X-DNS-Prefetch-Control 头控制着浏览器的DNS预解析功能
- X-DNS_prefetch-Control: on|off
- on：启用DNS预解析。在浏览器支持DNS预解析的特性时即使不适用该标签浏览器依然会进行预解析。
- off：关闭DNS预解析。这个属性在页面上的链接并不是由你控制的或是你根本不想向这些域名引导数据时非常有用。
21、JWT和session的区别
相同点是，它们都是存储用户信息；然而
- Session是在服务器端的，而JWT是在客户端的。
- Session方式存储用户信息的最大问题在于要占用大量服务器内存，增加服务器的开销。
- 而JWT方式将用户状态分散到了客户端中，可以明显减轻服务端的内存压力。
