HTTP

1、HTTP1.0，1.1，2.0 的版本区别

HTTP 版本区别
HTTP是什么
有四个版本，HTTP0.9、1.0、1.1、2.0

HTTP/0.9

只有GET，通信时不指定版本号，不支持请求头。
只能发送HTML格式字符串。
由于不支持POST，client无法向server传递太多信息。
无状态，每个事务单独处理，处理结束就释放连接。

HTTP/1.0

特点：

• 可指定版本号；
• 支持GET、POST、HEAD等请求方法；
• 增加头信息；
• 支持多种数据格式，头信息中Content-Type。
• 开始支持cache（缓存）；
• 无持久连接。

比较点

• 短连接

1996年5月，HTTP/1.0 版本发布，为了提高系统的效率，HTTP/1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。
HTTP 1.0 版本的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。为了解决这个问题，有些浏览器在请求时，即在请求头部加上 Connection 字段，但是，这不是一个标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

HTTP/1.1

特点：

• 持久化连接
• 管道机制
• 分块传输编码，产生一块数据就发送一块，流模式取代缓存模式，需要知道数据长度，content-length。
• 新增请求方式PUT、PATCH、OPTIONS、DELETE 等
• 请求头信息新增host，指定服务器域名
• 支持文件断点续传

比较点

• 长连接

1999年诞生，相比1.0来，最主要的改进是引入了持久连接，即TCP连接默认不关闭，可以被多个请求复用。connection-type：keep-alive。双方发现对方一段时间没有活动可以主动关闭，规范方法是clinet发送connection：close，明确要求server关闭连接。

• 管道机制

还引入了管道机制（pipelining），即在同一个TCP连接里面，客户端可以同时发送多个请求。降低线路负载，提高传输速度。

HTTP/2.0

2015年
特点、比较点:

• 二进制协议

HTTP 1.1 版的头信息肯定是文本（ASCII 编码），数据体可以是文本，也可以是二进制。
HTTP 2.0 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为”帧”（frame）：头信息帧和数据帧。

• 多路复用

即在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。

• 头信息压缩

HTTP 协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如 Cookie 和 User Agent，浪费很多带宽，也影响速度。
HTTP 2.0的头信息压缩机制（header compression）。一方面，头信息使用 gzip 或c ompress 压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

• 服务端推送。

HTTP 2.0 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送（server push）。
当我们对支持 HTTP 2.0 的 web server 请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到客户端，存在客户端，免得客户端再次创建连接发送请求到服务器端获取，直接从本地加载即可，速度更快。
这种方式非常合适加载静态资源。

2、POST与GET区别，应用场景。

GET和POST两种基本请求方法的区别
HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。
GET和POST是HTTP协议中的两种发送请求的方法。
区别：

• 参数

GET 和 POST 的请求都能使用额外的参数，但是 GET 的参数是以查询字符串出现在 URL 中，而 POST 的参数存储在实体主体中，即Request Body中。
URL 只支持 ASCII 码，因此 GET 的参数中如果存在中文等字符就需要先进行编码。POST 参数支持标准字符集。即GET请求只能进行url编码，而POST支持多种编码方式。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

• 安全性

安全的 HTTP 方法不会改变服务器状态，GET 方法是安全的，而 POST 却不是，因为 POST 的目的是传送实体主体内容，这个内容可能是用户上传的表单数据，上传成功之后，服务器可能把这个数据存储到数据库中，因此状态也就发生了改变。
安全的方法除了 GET 之外还有：HEAD、OPTIONS。
不安全的方法除了 POST 之外还有 PUT、DELETE。
即GET比POST更不安全，因为参数直接暴露在URL上，不能用来传递敏感信息。

• 幂等性

幂等的 HTTP 方法，同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。
在正确实现的条件下，GET，HEAD，PUT 和 DELETE 等方法都是幂等的，而 POST 方法不是。
即GET在浏览器回退时是无害的，而POST会再次提交请求。

• 可缓存

请求报文的 HTTP 方法本身是可缓存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可缓存，POST 在多数情况下不可缓存的。
响应报文的状态码是可缓存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
响应报文的 Cache-Control 首部字段没有指定不进行缓存。
即GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

• 传输数据长度

GET请求在URL中传送的参数是有长度限制的，而POST没有。

• 做书签

GET产生的URL地址可以被Bookmark，而POST不可以。

• 传输速度

post比get慢。Get产生一个TCP数据包；Post产生两个TCP数据包。
对于Get方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据），而对于Post，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
但是并不是所有的浏览器都会在POST中发送两个包，firefox就只发送一次。

使用场景：

1. 在做数据查询时，建议用Get方式；而在做数据添加、修改或删除时，建议用Post方式；
2. Get方式的安全性较Post方式要差些，包含机密信息的话，建议用Post数据提交方式；

   3、HTTP常见状态码

   
   1xx 信息
   100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。
   2xx 成功
   200 OK
   204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从
   客户端往服务器发送信息，而不需要返回数据时使用。
   206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体
   内容。
   3xx 重定向
   301 Moved Permanently ：永久性重定向
   302 Found ：临时性重定向
   303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
   304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。
   307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求
   的 POST 方法改成 GET 方法。
   4xx 客户端错误
   400 Bad Request ：请求报文中存在语法错误。
   401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果
   之前已进行过一次请求，则表示用户认证失败。
   403 Forbidden ：请求被拒绝。
   404 Not Found
   5xx 服务器错误
   500 Internal Server Error ：服务器正在执行请求时发生错误。
   503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求

   4、状态码301和302区别和用途

   301
   301重定向（301 Move Permanently），指页面永久性转移，表示为资源或页面永久性地转移到了另一个位置。301重定向是一种非常重要的”自动转向“技术，网址重定向最为可行的一种方法。
   什么时候需要
   网站目录结构调整、网页扩展名改变等导致网页地址改变，就需要跳转。
   优点
   有利于网站首选域的确定。网站权重和排名。
   302
   302重定向（302 Move Temporarily），指页面暂时性转移，表示资源或页面暂时转移到另一个位置，常被用作网址劫持，容易导致网站降权，严重时网站会被封掉，不推荐使用。
   区别
   302重定向是页面暂时性转移，搜索引擎会抓取新的内容而保存旧的网址并认为新的网址只是暂时的。

   5、HTTP方法有哪些？

   客户端发送的请求报文第一行为请求行，包含了方法字段。
   根据 HTTP 标准，HTTP 请求可以使用多种请求方法。
   HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。
   HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

6、GET中的URL编码、长度限制、参数写法固定吗？

URL编码
在GET请求中会对URL中的非西文字符进行编码，目的是避免歧义。特殊字符解析错误。
长度限制
HTTP 协议没有 Body 和 URL 的长度限制，大多是由于浏览器和服务器的原因。多数的服务器对GET请求的限制是8192个字节（8kb）。
服务器处理长URL要消耗较多资源，也防止恶意构造长URL攻击，为了性能和安全进行限制。
参数写法
在约定中，参数是写在 ? 后面，用 & 分割。
解析报文是通过获取TCP数据，用正则等工具从数据中获取header和body来提取参数。
因此可以自己约定参数的写法，只要服务器端可以解释。

7、POST比GET安全？产生两个数据包？最大数据长度？

安全？
相对安全，因为POST数据在地址栏上看不到，但在传输上他们都不安全，HTTP在网络上是明文传输的，在网络节点上捕获包就能完整获取数据报文。
想要安全传输，就加密，HTTPS。
两个数据包
这是指POST 会将 header 和 body 分开发送，先发送 header，服务端返回 100 状态码再发送 body。
HTTP协议并没有明确这样说。将header和body分开发送是部分浏览器和框架的请求方法，例如firefox就不会。
最大数据长度
GET传输数据的最大长度取决于服务器对URL的限制。
POST理论上没有，但事件取决于服务器的设置和内存大小。

8、HTTP长连接与短连接是什么，使用场景，一个TCP可对应几个HTTP，可以同时发送吗？

长连接如何实现的？
通过在头部（请求和响应头）设置 Connection: keep-alive，1.0是默认关闭，1.1后默认开启。
HTTP 一般会有 httpd 守护进程，里面可以设置 keep-alive timeout，当 tcp 链接闲置超过这个时间就会关闭，也可以在 HTTP 的 header 里面设置超时时间
TCP 的 keep-alive 包含三个参数，支持在系统内核的 net.ipv4 里面设置：当 TCP 链接之后，闲置了 tcp_keepalive_time，则会发生侦测包，如果没有收到对方的 ACK，那么会每隔 tcp_keepalive_intvl 再发一次，直到发送了 tcp_keepalive_probes，就会丢弃该链接。
（1）tcp_keepalive_intvl = 15s
（2）tcp_keepalive_probes = 5次
（3）tcp_keepalive_time = 1800s
实际上 HTTP 没有长短链接，只有 TCP 有，TCP 长连接可以复用一个 TCP 链接来发起多次 HTTP 请求，这样可以减少资源消耗，比如一次请求 HTML，可能还需要请求后续的 JS/CSS/图片等。
但Keep-Alive 并不是没有缺点。当长时间的保持 TCP 连接时容易导致系统资源被无效占用，若配置不当，可能损失更大。因此，要正确地设置 keep-alive timeout。
一个TCP连接可以对应几个HTTP请求？
保持连接时，可以多个。
可以同时发送这些HTTP请求吗？
1.1时，单个TCP连接同一时刻只能处理一个请求，存在 Pipelining 技术可以完成这个多个请求同时发送，但是由于浏览器默认关闭，故认为这是不可行的。在 HTTP2 中由于 Multiplexing 特点的存在，多个 HTTP 请求可以在同一个 TCP 连接中并行进行。
1.1浏览器如何提高页面加载效率？
维持已建立的连接，在同一连接上顺序处理多个请求；和服务器建立多个TCP连接。
浏览器对于同一host建立TCP连接的数量有无限制。
有，如谷歌 允许最多六个，不同浏览器不一样。
区别
在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次TCP连接， 任务结束就中断连接。 而从HTTP/1.1起，默认使用长连接，用以保持连接特性。
场景
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。例如： 数据库的连接用长连接， 如果用短连接频繁的通信会造成 socket 错误，而且频繁的 socket创建也是对资源的浪费。
而像 WEB 网站的 http 服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像 WEB 网站并发量大，但每个用户无需频繁操作情况下需用短连接。

9、请求报文和应答报文有什么字段？

HTTP 消息结构
HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。
一旦建立连接后，数据消息就通过类似Internet邮件所使用的格式[RFC5322]和多用途Internet邮件扩展（MIME）[RFC2045]来传送。
客户端请求消息
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据（请求体 request body）四个部分组成，下图给出了请求报文的一般格式。

如

GET /hello.txt HTTP/1.1 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 Host: www.example.com Accept-Language: en, mi

服务器响应消息
HTTP响应也由四个部分组成，分别是：状态行（status line）、消息报头（响应头response headers）、空行和响应正文（响应体response body）。

10、浏览器输入URL后经过了什么过程？

1. DNS 解析：浏览器查询 DNS，获取域名对应的 IP 地址：具体过程包括浏览器搜索自身的 DNS 缓存、搜索操作系统的 DNS 缓存、读取本地的 Host 文件和向本地 DNS 服务器进行查询等。对于向本地 DNS 服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地 DNS 服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个 IP 地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；
2. TCP 连接：浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立链接，发起三次握手；
3. 发送 HTTP 请求：TCP 连接建立起来后，浏览器向服务器发送 HTTP 请求；
4. 服务器处理请求并返回 HTTP 报文：服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
5. 浏览器解析渲染页面：浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。
6. 连接结束。

   11、HTTP缓存是什么，缓存机制介绍下，如何保证最新？

   http缓存
   概念
   http缓存指的是: 当客户端向服务器请求资源时，会先抵达浏览器缓存，如果浏览器有“要请求资源”的副本，就可以直接从浏览器缓存中提取而不是从原始服务器中提取这个资源。
   常见的http缓存只能缓存get请求响应的资源，对于其他类型的响应则无能为力，所以后续说的请求缓存都是指GET请求。
   http缓存都是从第二次请求开始的。第一次请求资源时，服务器返回资源，并在respone header头中回传资源的缓存参数；第二次请求时，浏览器判断这些请求参数，命中强缓存就直接200，否则就把请求参数加到request header头中传给服务器，看是否命中协商缓存，命中则返回304，否则服务器会返回新的资源。
   分类
   根据是否需要重新向服务器发起请求来分类，可分为强制缓存（状态码200），协商缓存（状态码304）。强制缓存如果生效，不需要再和服务器发生交互，而协商缓存不管是否生效，都需要与服务端发生交互。
   根据是否可以被单个或者多个用户使用来分类，可分为私有缓存，共享缓存。
   强制缓存
   强制缓存在缓存数据未失效的情况下，直接使用浏览器的缓存数据，不会再向服务器发送任何请求。
   强制缓存生效时，http状态码为200。
   这种方式页面的加载速度是最快的，性能也是很好的。
   但是在这期间，如果服务器端的资源修改了，页面上是拿不到的，因为它不会再向服务器发请求了。这种情况就是我们在开发种经常遇到的，比如你修改了页面上的某个样式，在页面上刷新了但没有生效，因为走的是强缓存，所以Ctrl + F5一顿操作之后就好了。 跟强制缓存相关的header头属性有（Pragma/Cache-Control/Expires）。
   Pragma和Cache-control共存时，Pragma的优先级是比Cache-Control高的。expires最低。
   强缓存情况下，只要缓存还没过期，就会直接从缓存中取数据，就算服务器端有数据变化，也不会从服务器端获取了，这样就无法获取到修改后的数据。解决办法有：在修改后的资源加上随机数,确保不会从缓存中取。
   协商缓存
   当第一次请求时服务器返回的响应头中没有Cache-Control和Expires或者Cache-Control和Expires过期还或者它的属性设置为no-cache时(即不走强缓存)，那么浏览器第二次请求时就会与服务器进行协商，与服务器端对比判断资源是否进行了修改更新。如果服务器端的资源没有修改，那么就会返回304状态码，告诉浏览器可以使用缓存中的数据，这样就减少了服务器的数据传输压力。如果数据有更新就会返回200状态码，服务器就会返回更新后的资源并且将缓存信息一起返回。跟协商缓存相关的header头属性有（ETag/If-Not-Match 、Last-Modified/If-Modified-Since）请求头和响应头需要成对出现。
   协商缓存的执行流程是这样的：当浏览器第一次向服务器发送请求时，会在响应头中返回协商缓存的头属性：ETag和Last-Modified,其中ETag返回的是一个hash值，Last-Modified返回的是GMT格式的最后修改时间。然后浏览器在第二次发送请求的时候，会在请求头中带上与ETag对应的If-Not-Match，其值就是响应头中返回的ETag的值，Last-Modified对应的If-Modified-Since。服务器在接收到这两个参数后会做比较，如果返回的是304状态码，则说明请求的资源没有修改，浏览器可以直接在缓存中取数据，否则，服务器会直接返回数据。
   注意：
   ETag/If-Not-Match是在HTTP/1.1出现的，主要是解决以下问题：
   (1)、Last-Modified标注的最后修改只能精确到秒级，如果某些文件在1秒钟以内，被修改多次的话，它将不能准确标注文件的修改时间
   (2)、如果某些文件被修改了，但是内容并没有任何变化，而Last-Modified却改变了，导致文件没法使用缓存
   (3)、有可能存在服务器没有准确获取文件修改时间，或者与代理服务器时间不一致等情形
   私有缓存
   私有缓存只能用于单独的用户：Cache-Control: Private,一般存储在用户浏览器中。
   共享缓存
   共享缓存可以被多个用户使用: Cache-Control: Public，一般存储在代理服务器中。
   为什么要用HTTP缓存
   1. 减少了冗余的数据传输，节省了网费。
   2. 缓解了服务器的压力， 大大提高了网站的性能
   3. 加快了客户端加载网页的速度。缓存通常位于内存中，读取缓存的速度更快。并且缓存服务器在地理位
   置上也有可能比源服务器来得近，例如浏览器缓存。
   实现

• 让代理服务器进行缓存；
• 让客户端浏览器进行缓存。

如何保证最新
max-age 指令出现在请求报文，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓
存。 max-age 指令出现在响应报文，表示缓存资源在缓存服务器中保存的时间。

Cache-Control: max-age=31536000

Expires 首部字段也可以用于告知缓存服务器该资源什么时候会过期。

Expires: Wed, 04 Jul 2012 08:26:05 GMT

在 HTTP/1.1 中，会优先处理 max-age 指令；
在 HTTP/1.0 中，max-age 指令会被忽略掉。
禁用与确认
HTTP/1.1 通过 Cache-Control 首部字段来控制缓存。
禁止进行缓存：no-store 指令规定不能对请求或响应的任何一部分进行缓存。

Cache-Control: no-store

强制确认缓存 ：no-cache 指令规定缓存服务器需要先向源服务器验证缓存资源的有效性，只有当缓存资源有效时才能使 用该缓存对客户端的请求进行响应。

Cache-Control: no-cache

12、session和cookie是什么，对比? Token

session和cookie
Token
会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。
Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。
Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中。
Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。
Cookie可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。
原理
Cookie是存储由服务器发至客户端并由客户端保存的一段字符串。为了保持会话，服务器可以在响应客户端请求时将Cookie字符串放在Set-Cookie下，客户机收到Cookie之后保存这段字符串，之后再请求时候带上Cookie就可以被识别。
Cookie在客户端的保存形式可以有两种，一种是会话Cookie一种是持久 Cookie和会话Cookie。持久Cookie则是存储在客户端磁盘上，其有效时间在服务器响应头中被指定，在有效期内，客户端再次请求服务器时都可以直接从本地取出。会话cookie就是将服务器返回的Cookie字符串保持在内存中，关闭浏览器之后自动销毁。
session 的工作原理是客户端登录完成之后，服务器会创建对应的 session，session 创建完之后，会把session 的 id 发送给客户端，客户端再存储到浏览器中。这样客户端每次访问服务器时，都会带着session id，服务器拿到 session id 之后，在内存找到与之对应的 session 这样就可以正常工作了。Session ID作为Session文件的Hash键，通过这个值可以锁定具体的Session结构的数据，这个Session结构中存储了用 户操作行为。
cookie用途

• 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
• 个性化设置（如用户自定义设置、主题等）
• 浏览器行为跟踪（如跟踪分析用户行为等）

session使用

• 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
• 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
• 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
• 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从Redis 中取出用户信息，继续之前的业务操作。

session痛点
多个服务器，负载均衡，session存在哪里？ 三种方案：session复制、session粘连（固定机器）、共享session（存在如redis等中间件）
token
不需要中间件进行共享。
首先请求方输入自己的用户名，密码，然后 server 据此生成 token，客户端拿到 token 后会保存到本地，之后向 server 请求时在请求头带上此 token 即可。
token 只存储在浏览器中，服务端却没有存储，但是server 会有一套校验机制，校验这个 token 是否合法。
不像session 那样根据 sessionId 找到 userid ，token本身可以带 uid 信息，解密后就可以获取。
可以看到 token 主要由三部分组成 1. header：指定了签名算法 2. payload：可以指定用户 id，过期时间等非敏感数据 3. Signature: 签名，server 根据 header 知道它该用哪种签名算法，再用密钥根据此签名算法对 head + payload 生成签名，这样一个 token 就生成了。
当 server 收到浏览器传过来的 token 时，它会首先取出 token 中的 header + payload，根据密钥生成签名，然后再与 token 中的签名比对，如果成功则说明签名是合法的，即 token 是合法的。而且你会发现 payload 中存有我们的 userId，所以拿到 token 后直接在 payload 中就可获取 userid，避免了像 session 那样要从 redis 去取的开销。
这种方式有效地避免了 token 必须保存在 server 的弊端，实现了分布式存储。
token 一旦由 server 生成，它就是有效的，直到过期，无法让 token 失效，除非在 server 为 token 设立一个黑名单，在校验 token 前先过一遍此黑名单，如果在黑名单里则此 token 失效，但一旦这样做的话，那就意味着黑名单就必须保存在 server，这又回到了 session 的模式。所以一般的做法是当客户端登出要让 token 失效时，直接在本地移除 token 即可，下次登录重新生成 token 。
cookie缺点

• Cookie 跨站是不能共享的，实现多应用（多系统）的单点登录（SSO）困难，单点登录，是指在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。用token容易，只要在 header 中的 authorize 字段（或其他自定义）加上 token 即可完成所有跨域站点的认证。
• 在移动端原生请求是没有 cookie 之说的，而 sessionid 依赖于 cookie，sessionid 就不能用 cookie 来传了，如果用 token 的话，由于它是随着 header 的 authoriize 传过来的，也就不存在此问题，换句话说 token 天生支持移动平台，天生就就支持所有平台，可扩展性好

综上所述，token 具有存储实现简单，扩展性好这些特点。
token缺点
1、 token 太长了
token 是 header, payload 编码后的样式，所以一般要比 sessionId 长很多，很有可能超出 cookie 的大小限制（cookie 一般有大小限制的，如 4kb），如果你在 token 中存储的信息越长，那么 token 本身也会越长，这样的话由于你每次请求都会带上 token，对请求来是个不小的负担。
2、 不太安全
token 是存在浏览器的哪里？既然它太长放在 cookie 里可能导致 cookie 超限，那就只好放在 local storage 里，这样会造成严重的安全问题，因为 local storage 这类的本地存储是可以被 JS 直接读取的，另外token 一旦生成无法让其失效，必须等到其过期才行，这样的话如果服务端检测到了一个安全威胁，也无法使相关的 token 失效。
所以 token 更适合一次性的命令认证，设置一个比较短的有效期。
对比
1，存储的位置不同，cookie：存放在客户端，容易被恶意查看session：存放在服务端的文件、数据库或者内存中，也可以在redis中。Session存储的数据比较安全 。
2，存储的数据类型不同。两者都是key-value的结构，cookie：value只能是字符串类型，session：value是Object类型 ，可以存储任何类型的数据。
3，存储的数据大小限制不同 。cookie：大小受浏览器的限制，很多是是4K的大小， session：理论上受当前内存的限制，
4，生命周期的控制 。cookie的生命周期当浏览器关闭的时候，就消亡了 ，cookie的生命周期是累计的，从创建时，就开始计时，20分钟后，cookie生命周期结束， session的生命周期是间隔的，从创建时，开始计时如在20分钟，没有访问session，那么session生命周期被销毁。
禁用时
客户端的浏览器禁用了 Cookie 时，使用URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数，服务端据此来识别用户。
适用场景

• Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时

首选 Session；

• Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密；
• 对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有 的用户信息都存储到 Session 中。

  13、HTTP和HTTPS区别

1. 开销：HTTPS 协议需要到 CA 申请证书，一般免费证书很少，需要交费；
2. 资源消耗：HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 ssl 加密传输协议，需要消耗更多的 CPU 和内存资源；
3. 端口不同：HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443；
4. 安全性：HTTP 的连接很简单，是无状态的；HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。
5. 响应速度：HTTP页面响应速度比HTTPS更快。

   14、HTTPS介绍，优缺点

   HTTPS 是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通 信，HTTPS 使用了隧道进行通信。通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。
   HTTP缺点

• 使用明文进行通信，内容可能会被窃听；
• 不验证通信方的身份，通信方的身份有可能遭遇伪装；
• 无法证明报文的完整性，报文有可能遭篡改。

HTTPS优点：

1. 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
2. HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中被窃取、改变，确保数据的完整性；
3. HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

HTTPS缺点：

1. HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近 50%，增加 10% 到 20% 的耗电；
2. HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
3. SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用；
4. SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗；
5. HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

   15、HTTPS工作过程

   HTTPS原理
   
   1.客户端请求 HTTPS 网址，然后连接到 server 的 443 端口 (HTTPS 默认端口，类似于 HTTP 的80端口)。
   2.服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。数字签名等
   3.客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
   4.如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY，并使用公钥A将其加密。
   5.客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。
   6.服务器在收到随机码 KEY 之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接。
   7.服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。
   8.双方使用对称加密传输所有数据。

   16、HTTPS加密方式

   HTTPS 采用混合的加密机制，使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率。

   17、对称加密与非对称加密，概念，对比

   简介

• 对称加密: 加密和解密的秘钥使用的是同一个.
• 非对称加密: 与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。

对称加密算法特点:
优点: 算法公开、计算量小、加密速度快、加密效率高
缺点: 无法安全地将密钥传输给通信方
常见的对称加密算法有: DES、3DES、Blowfish、IDEA、RC4、RC5、RC6 和 AES 。
非对称加密特点：
优点: 可以更安全地将公开密钥传输给通信发送方；
缺点: 速度较慢
常见的非对称加密算法有: RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）
Hash算法（摘要算法）
Hash算法特别的地方在于它是一种单向算法，用户可以通过hash算法对目标信息生成一段特定长度的唯一hash值，却不能通过这个hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。
常见的摘要算法有: MD2、MD4、MD5、HAVAL、SHA

18、数字签名与数字证书

数字证书
在非对称加密通信过程中，服务器需要将公钥发送给客户端，在这一过程中，可能会发生中间人攻击,公钥很可能会被第三方拦截并替换，然后这个第三方就可以冒充服务器与客户端进行通信。
通过受信任的第三方证书认证机构 (Certificate Authority, 简称 CA)将公钥合并到数字证书中，然后服务器会把公钥连同证书一起发送给客户端，私钥则由服务器自己保存以确保安全。这个证书是经由系统内置证书的备案的。数字证书一般包含以下内容：

1. 证书所有者的公钥
2. 证书所有者的专有名称
3. 证书颁发机构的专有名称
4. 证书的有效起始日期
5. 证书的过期日期
6. 证书数据格式的版本号
7. 序列号，这是证书颁发机构为该证书分配的唯一标识符

验证过程

• 拿到证书，得到明文T，数字签名S。
• 用CA机构的公钥对S解密，得到S’。（由于是浏览器信任的机构，浏览器保有它的公钥，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中有该CA机构的根证书，那就可以拿到它对应的可信公钥）
• 用证书里说明的hash算法对明文T进行hash（摘要）得到T’。
• 比较S’是否等于T’，等于则表明证书可信

数字签名
为了确保数据发送者的合法身份，也可以确保数据内容未遭到篡改，保证数据完整性。数字签名会随着文本数据的变化而变化。
数字签名的生成和验证流程如下：

1. 服务器对证书内容进行信息摘要计算 (常用算法有 SHA-256等)，得到摘要信息，再用私钥把摘要信息加密，就得到了数字签名。
2. 服务器把数字证书连同数字签名一起发送给客户端
3. 客户端用公钥解密数字签名，得到摘要信息
4. 客户端用相同的信息摘要算法重新计算证书摘要信息，然后对这两个摘要信息进行比对，如果相同，则说明证书未被篡改，否则证书验证失败

摘要
摘要，其实就是某种HASH算法。将信息明文转化为固定长度的字符，它具有如下特点：
①无论输入的消息有多长，计算出来的消息摘要的长度总是固定的；
②用相同的摘要算法对相同的消息求两次摘要，其结果必然相同；
③一般地，只要输入的消息不同，对其进行摘要以后产生的摘要消息也几乎不可能相同；
④消息摘要函数是单向函数，即只能进行正向的信息摘要，而无法从摘要中恢复出任何的消息；
⑤好的摘要算法，没有人能从中找到“碰撞”，虽然“碰撞”是肯定存在的。即对于给定的一个摘要，不可能找到一条信息使其摘要正好是给定的。或者说，无法找到两条消息，是它们的摘要相同。
目前主要的摘要算法有MD5和SHA1。
为什么需要进行hash一次？
非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加密解密就会快很多。

19、如何保证HTTPS中的公钥不被篡改

将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
数字签名和数字证书。验证身份和消息完整性。

20、SSL/TLS原理

SSL/TLS

SSL (Secure Sockets Layer 安全套接层)或 TLS (Transport Layer Security 安全传输层协议)
SSL 和 TLS 协议可以为通信双方提供识别和认证通道，从而保证通信的机密性和数据完整性。TLS 协议是从Netscape SSL 3.0协议演变而来的，不过这两种协议并不兼容，SSL 已经逐渐被 TLS 取代。
TLS 握手是启动 HTTPS 通信的过程，类似于 TCP 建立连接时的三次握手。 在 TLS 握手的过程中，通信双方交换消息以相互验证，相互确认，并确立它们所要使用的加密算法以及会话密钥 (用于对称加密的密钥)。
TLS握手
目的：是建立安全连接
过程发生了什么：

• 商定双方通信所使用的的 TLS 版本 (例如 TLS1.0, 1.2, 1.3等等)；
• 确定双方所要使用的密码组合；
• 客户端通过服务器的公钥和数字证书上的数字签名验证服务端的身份；
• 生成会话密钥，该密钥将用于握手结束后的对称加密。

详细过程

1. “client hello”消息：客户端通过发送”client hello”消息向服务器发起握手请求，该消息包含了客户端所支持的 TLS 版本和密码组合以供服务器进行选择，还有一个”client random”随机字符串。
2. “server hello”消息：服务器发送”server hello”消息对客户端进行回应，该消息包含了数字证书，服务器选择的密码组合和”server random”随机字符串。
3. 验证：客户端对服务器发来的证书进行验证，确保对方的合法身份，验证过程可以细化为以下几个步骤：
   1. 检查数字签名
   2. 验证证书链
   3. 检查证书的有效期
   4. 检查证书的撤回状态 (撤回代表证书已失效)
4. “premaster secret”字符串：客户端向服务器发送另一个随机字符串”premaster secret (预主密钥)”，这个字符串是经过服务器的公钥加密过的，只有对应的私钥才能解密。
5. 使用私钥：服务器使用私钥解密”premaster secret”。
6. 生成共享密钥：客户端和服务器均使用 client random，server random 和 premaster secret，并通过相同的算法生成相同的共享密钥 KEY。
7. 客户端就绪：客户端发送经过共享密钥 KEY加密过的”finished”信号。
8. 服务器就绪：服务器发送经过共享密钥 KEY加密过的”finished”信号。
9. 达成安全通信：握手完成，双方使用对称加密进行安全通信。

证书链 (certificate chain)：证书链，也称为证书路径，是用于认证实体合法身份的证书列表，具体到 HTTPS 通信中，就是为了验证服务器的合法身份。之所以使用证书链，是为了保证根证书 (root CA certificate)的安全，中间层可以看做根证书的代理，起到了缓冲的作用。
证书链从根证书开始，并且证书链中的每一级证书所标识的实体都要为其下一级证书签名，而根证书自身则由证书颁发机构签名。客户端在验证证书链时，必须对链中所有证书的数字签名进行验证，直到达到根证书为止。
密码规范和密码组合 (CipherSpecs 和 CipherSuites)：通信双方在安全连接中所使用的算法必须符合密码安全协议的规定，CipherSpecs 和 CipherSuites 正好定义了合法的密码算法组合。CipherSpecs 用于认证加密算法和信息摘要算法的组合，通信双方必须同意这个密码规范才能进行通信。而 CipherSuites 则定义了 SSL / TLS 安全连接中所使用的加密算法的组合，该组合包含三种不同的算法：

1. 握手期间所使用的的密钥交换和认证算法 (最常用的是 RSA 算法)
2. 加密算法 (用于握手完成后的对称加密，常用的有 AES、3DES等)
3. 信息摘要算法 (常用的有 SHA-256、SHA-1 和 MD5 等)