HTTP相关

GET和POST的请求的区别

POST 和 GET 是 HTTP 请求的两种方法，其区别如下：

应用场景

• GET请求是一个幂等的请求,一般用于对服务器资源不会产生影响的场景,比如获取一些静态资源;
• POST请求不是一个幂等的请求,一般用于对服务器资源会产生影响的场景,比如注册用户之类的操作;

tips:幂等是指一个请求方法执行多次和仅执行一次的效果完全相同 PUT请求也是幂等的。

是否缓存

因为两者应用场景不同，浏览器一般会对 Get请求缓存，但很少对 Post请求缓存

传参方式不同

GET请求通过查询字符串传参,Post请求一般通过请求体传参,当然也可以通过查询字符串传参,只是一般不这么用

安全性

GET请求是通过查询字符串传参的,这种方式将参数放入了url中一起发送到了服务端,这种做法是不太安全的,因为请求的url会被保留在记录中。因此,POST请求安全性比GET请求安全性更高。

请求长度

由于浏览器对url长度有限制,所以会影响GET请求发送数据时的长度;而POST请求将请求参数放在了请求体里,所以没有这个限制。

参数类型

get参数只允许ASCII字符，post 的参数传递支持更多的数据类型(如文件、图片)。

发送请求次数

GET请求只会发送一次请求,而POST会发送两次请求。

tip:为什么post请求会发送两次请求?

1、第一次请求为options预检请求,状态码为:204 那么发送options请求的目的是什么呢?主要有一下两个作用

• 询问服务器是否支持修改的请求头，如果服务器支持，则在第二次中发送真正的请求
• 检测服务器是否为同源请求,是否支持跨域

2、第二次为真正的post请求

常见的HTTP请求头和响应头

HTTP Request Header

• Accept:浏览器能够处理的内容类型
• Accept-Charset:浏览器能够显示的字符集
• Accept-Encoding：浏览器能够处理的压缩编码
• Accept-Language：浏览器当前设置的语言
• Connection：浏览器与服务器之间连接的类型
• Cookie：当前页面设置的任何Cookie
• Host：发出请求的页面所在的域
• Referer：发出请求的页面的URL
• User-Agent：浏览器的用户代理字符串

HTTP Responses Header

• Date：表示消息发送的时间，时间的描述格式由rfc822定义
• server:服务器名称
• Connection：浏览器与服务器之间连接的类型
• Cache-Control：控制HTTP缓存
• content-type:表示后面的文档属于什么MIME类型

常见的HTTP请求方法

• GET: 向服务器获取数据；
• POST：发送数据给服务器，通常会造成服务器资源的新增修改；
• PUT：用于全量修改目标资源(看接口，也可以用于添加)；
• PATCH：用于对资源进行部分修改
• DELETE：用于删除指定的资源；
• HEAD：获取报文首部，与GET相比，不返回报文主体部分；使用场景是比如下载一个大文件前，先获取其大小再决定是否要下载，以此可以节约宽带资源
• OPTIONS：(浏览器自动执行)、询问支持的请求方法，用来跨域请求、预检请求、判断目标是否安全；
• CONNECT：要求在与代理服务器通信时建立管道，使用管道进行TCP通信；(把服务器作为跳板，让服务器代替用户去访问其他网页，之后把数据原原本本的返回给用户)
• TRACE: 该方法会让服务器原样返回任意客户端请求的信息内容，主要⽤于测试或诊断

OPTIONS请求方法及使用场景

OPTIONS是除了GET和POST之外的其中一种 HTTP请求方法。(浏览器自动执行) OPTIONS方法是用于请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项。通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。该请求方法的响应不能缓存。

OPTIONS请求方法的主要用途有两个：

• 获取服务器支持的所有HTTP请求方法；
• 用来检查访问权限。例如：在进行 CORS 跨域资源共享时，对于复杂请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。

XMLHTTPRequest对象

Ajax的核心是XMLHTTPRequest。它是一种支持异步请求的技术。 XMLHTTPRequest使您可以使用JavaScript向服务器提出请求并处理响应，而不阻塞用户。可以在页面加载以后进行页面的局部更新

使用XHR

• 实例化ajax对象

const xhr = new XMLHttpRequest();

• 创建HTTP请求

/**
 * @params method 请求方法 GET|POST|PUT|DELETE
 * @params url    请求地址 String
 * @params async  是否是异步请求,可选,默认为true Boolean
 */
xhr.open("post", "http://localhost:3008/api/login",true);

• 设置请求头

/**
 * @params key    请求头的key    String
 * @params value  请求头的value  String
 */
xhr.setRequestHeader("Content-type","application/json");

• 注册回调函数

// 方式一
// onload事件 ：  接收服务器响应的数（一次请求，只会执行一次）
xhr.onload = function(){
    console.log(xhr.responseText);
}
// 方式二
/**
 * onreadystatechang事件 : 作用与onload事件一致（一次请求，会执行多次）
 * XMLHttpRequest对象的状态码 （xhr.readyState）
 * 0: 请求未建立  (创建了xhr对象，但是还没调用open)
 * 1: 服务器连接已建立
 * 2. 请求已接收  (send之后,服务器已经接收了请求)
 * 3. 请求处理中
 * 4. 请求已完成，且响应已就绪  (4状态码等同于onload事件)
 */
xhr.onreadystatechange = function() {
    if(xhr.readyState === 4){
        console.log(xhr.responseText);
    }
}

• 发送请求

/**
 * @params body    可选参数,请求主体,如果请求方法是 GET 或者 HEAD，则应将请求主体设置为 null
 */
xhr.send();

// 1.实例化ajax对象
const xhr = new XMLHttpRequest();
// 2.创建http请求
xhr.open("post", "http://localhost:3008/api/login",true);
// 3.设置请求头
xhr.setRequestHeader("Content-type","application/json");
// 4.设置回调函数
xhr.onreadystatechange = function() {
    if(xhr.readyState === 4){
        console.log(xhr.responseText);
    }
}
// 5.发送请求
xhr.send();

ajax请求如何取消

原生xhr取消请求

const xhr = new XMLHttpRequest();
xhr.abort();

axios取消请求

传递一个 executor 函数到 CancelToken 的构造函数来创建 cancel token

const CancelToken = axios.CancelToken;
let cancel;
​
axios.get('/user/12345', {
  cancelToken: new CancelToken(function executor(c) {
    // executor 函数接收一个 cancel 函数作为参数
    cancel = c;
  })
});
​
// cancel the request
cancel();

取消ajax请求的意义

• 已发出的请求可能仍然会到达后端
• 取消后续的回调处理，避免多余的回调处理，以及特殊情况，先发出的后返回，导致回调中的数据错误覆盖
• 取消loading效果，以及该请求的其他交互效果，特别是在单页应用中，A页面跳转到B页面之后，A页面的请求应该取消，否则回调中的一些处理可能影响B页面
• 超时处理，错误处理等都省去了，节约资源

HTTP 1.0 和 HTTP 1.1 之间有哪些区别？

连接方面

http1.0 默认使用非持久连接，而 http1.1 默认使用持久连接(Connection: Keep-Alive)。http1.1 通过使用持久连接来使多个 http 请求复用同一个 TCP 连接，以此来避免使用非持久连接时每次需要建立连接的时延。

资源请求方面

在 http1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，http1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

缓存方面

在 http1.0 中主要使用 header 里的 Expires 来做为缓存判断的标准，http1.1 则引入了更多的缓存控制策略，例如 cache-control、Etag、if-none-matched、last-modified、if-modified-since 等更多可供选择的缓存头来控制缓存策略

http1.1 中新增了 host 字段,用来指定服务器的域名

http1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名(hostname)。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址。因此有了 host 字段，这样就可以将请求发往到同一台服务器上的不同网站。

新增请求方法

http1.1 相对于 http1.0 还新增了很多请求方法，如 PUT、HEAD、OPTIONS 等

HTTP 2.0相对于HTTP 1.1 的新特性

二进制协议

HTTP2是一个二进制协议。在HTTP1.1中,报文的头信息必须是文本,数据体可以是文本也可以是二进制。HTTP2是则是一个彻底的二进制协议,头信息和数据体都是二进制,并且统称为帧,可以分为头信息帧和数据帧。帧的概念是它实现多路复用的基础。

为什么使用二进制协议

• 性能。二进制协议的解析效率超高,几乎没有解析代价
• 体积。二进制协议没有冗余字段,体积小,占用带宽少
• 压缩及HTTPS技术弱化了文本协议可读性好的价值

多路复用

HTTP2实现了多路复用。HTTP2仍然复用TCP连接,但是在一个连接里客户端和服务端都可以同时发送多个请求或响应,而且不用按照顺序一一发送,这样就避免了队头阻塞的问题。

什么是队头阻塞呢？

队头阻塞是指当多个HTTP请求同时存在时,如果队头的请求还在处理中时,那么后续的请求会被阻塞这样一种现象。队头阻塞是由 HTTP 基本的请求-应答模型所导致的。HTTP 规定报文必须是一发一收，这就形成了一个先进先出的串行队列。队列里的请求是没有优先级的，只有入队的先后顺序，排在最前面的请求会被最优先处理。如果队首的请求因为处理的太慢耽误了时间，那么队列里后面的所有请求也不得不跟着一起等待，结果就是其他的请求承担了不应有的时间成本，造成了队头堵塞的现象

队头阻塞的解决方案

• 并发连接。对于一个域名允许分配多个长连接，那么相当于增加了任务队列，不至于一个队伍的任务阻塞其它所有任务。
• 域名分片。将域名分出很多二级域名，它们都指向同样的一台服务器，能够并发的长连接数变多，解决了队头阻塞的问题。

数据流

HTTP2 使用了数据流的概念,因为 HTTP2 的数据包是不按顺序发送的,同一个连接里面连续的数据包，可能属于不同的请求。因此,必须要对数据包做标记,指出它属于哪个请求。HTTP2 将每个请求或回应的所有数据包,称为一个数据流。每个数据流都有一个独一无二的编号。数据包发送时,都必须标记数据流 ID ,用来区分它属于哪个数据流。

头信息压缩

HTTP2 实现了头信息压缩,由于 HTTP 1.1 协议不带状态,每次请求都必须附上所有信息。所以,请求的很多字段都是重复的,比如 Cookie 和 User Agent ,一模一样的内容,每次请求都必须附带,这会浪费很多带宽,也影响速度。HTTP2 对这一点做了优化,引入了头信息压缩机制。一方面,头信息使用 gzip 或 compress 压缩后再发送;另一方面,客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就能提高速度了。

服务器推送

HTTP2 允许服务器未经请求,主动向客户端发送资源,这叫做服务器推送。使用服务器推送提前给客户端推送必要的资源,这样就可以相对减少一些延迟时间。这里需要注意的是 HTTP2 下服务器主动推送的是静态资源,和 WebSocket 以及使用 SSE 等方式向客户端发送即时数据的推送是不同的。举个栗子,假如你向服务器请求index.html,那么服务器发下静态资源里有index.js和index.css,那么它会把这两个静态资源主动推送给你。

HTTP2的头部压缩算法

HTTP2的头部压缩是HPACK算法。在客户端和服务器两端建立字典,用索引号表示重复的字符串,采用哈夫曼编码来压缩整数和字符串,可以达到50%~90%的高压缩率。

具体来说是这样的：

• 在客户端和服务器端使用首部表来跟踪和存储之前发送的键值对,对于相同的数据,不再通过每次请求和响应发送;
• 首部表在HTTP2的连接存续期内始终存在,由客户端和服务器共同渐进地更新;
• 每个新的首部键值对要么被追加到当前表的末尾,要么替换表中之前的值;

HTTP 3.0简介

HTTP3.0,也称作HTTP over QUIC。HTTP3.0的核心是QUIC(读音quick)协议，由Google在 2015年提出的SPDY v3演化而来的新协议,传统的HTTP协议是基于传输层TCP的协议,而QUIC是基于传输层UDP上的协议,可以定义成:HTTP3.0基于UDP的安全可靠的HTTP2.0协议。

QUIC 协议针对基于TCP和TLS的HTTP2.0协议解决了下面的问题:

• 减少了TCP三次握手及TLS握手时间。QUIC协议是基于UDP协议的,本身没有连接的概念,建立连接只需要一次交互,半个握手的时间。
• 多路复用丢包的线头阻塞问题
• 优化重传策略
• 流量控制
• 连接迁移

HTTP请求报文的是什么样的

请求报⽂有4部分组成:

请求行

请求⾏包括：请求⽅法字段、URL字段、HTTP协议版本字段。它们⽤空格分隔。例如，GET /index.html HTTP/1.1

请求头部

请求头部由关键字/值对组成，每⾏⼀对，关键字和值⽤英⽂冒号:分隔

• User-Agent：产⽣请求的浏览器类型。
• Accept：客户端可识别的内容类型列表。
• Host：请求的主机名，允许多个域名同处⼀个IP地址，即虚拟主机。

空行

请求体

post put等请求携带的数据

HTTP响应报文的是什么样的

请求报⽂有4部分组成

响应⾏

由网络协议版本,状态码和状态码的原因短语组成,例如 HTTP/1.1 200 OK

响应头

响应部⾸组成

空行

响应体

服务器响应的数据

HTTP状态码分别代表什么意思

类别	原因	描述
1xx	Informational(信息性状态码)	接受的请求正在处理
2xx	Success(成功状态码)	请求正常处理完毕
3xx	Redirection(重定向状态码)	需要进行附加操作以完成请求
4xx	Client Error(客户端错误状态码)	服务器无法处理请求
5xx	Server Error(服务端错误状态码)	服务器处理请求出错

2xx成功

• 200 OK，表示从客户端发来的请求在服务器端被正确处理
• 201 Created 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立。通常是在POST请求，或者是某些PUT请求之后创建了内容，进行的返回的响应。
• 202 Accepted 请求服务器已接受，但是尚未处理，不保证完成请求。适合异步任务或者说需要处理时间比较长的请求，避免HTTP链接一直占用。
• 204 No content，表示请求成功，但响应报文不含实体的主体部分
• 205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容

3XX 重定向

• 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
• 302 found，临时性重定向，表示资源临时被分配了新的 URL，支持搜索引擎优化
• 303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源
• 304 not modified，自从上次请求后，请求的网页内容未修改过。服务器返回此响应时，不会返回网页内容。(协商缓存)
• 307 temporary redirect，临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

4XX 客户端错误

• 400 bad request，请求报文存在语法错误(传参格式不正确)
• 401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息(没有权限)
• 403 forbidden，表示对请求资源的访问被服务器拒绝
• 404 not found，表示在服务器上没有找到请求的资源
• 408 Request Timeout 客户端请求超时
• 409 Confict 请求的资源可能引起冲突

5XX 服务器错误

• 500 internal sever error，表示服务器端在执行请求时发生了错误
• 501 Not Implemented，表示服务器不支持当前请求所需要的某个功能
• 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

介绍下304过程

验证强缓存

浏览器请求资源时首先命中资源的Expires 和 Cache-Control，Expires 受限于本地时间，如果修改了本地时间，可能会造成缓存失效，可以通过Cache-control: max-age指定最大生命周期，状态仍然返回200，但不会请求数据，在浏览器中能明显看到from cache字样

协商缓存,验证ETag

强缓存失效，进入协商缓存阶段，首先验证ETag。ETag可以保证每一个资源是唯一的，资源变化都会导致ETag变化。服务器根据客户端上送的If-None-Match值来判断是否命中缓存

协商缓存,验证Last-Modify

协商缓存Last-Modify/If-Modify-Since阶段，客户端第一次请求资源时，服务服返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间。再次请求该资源时，request的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存

HTTP协议的优缺点

HTTP 是超文本传输协议，它定义了客户端和服务器之间交换报文的格式和方式，默认使用 80 端口。它使用 TCP 作为传输层协议，保证了数据传输的可靠性。

HTTP协议具有以下优点：

支持客户端/服务器模式

简单快速

客户向服务器请求服务时，只需传送请求方法和路径。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。

无连接

无连接就是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。

无状态

HTTP 协议是无状态协议，这里的状态是指通信过程的上下文信息。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能会导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就比较快。

灵活

HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。

HTTP协议具有以下缺点

无状态

HTTP 是一个无状态的协议，HTTP 服务器不会保存关于客户的任何信息。

不安全

不安全的原因主要有以下几点：

• 通信使用明文（不加密），内容可能会被窃听
• 不验证通信方的身份，因此有可能遭遇伪装
• 无法证明报文的完整性，所以有可能已遭篡改

HTTP的两种连接模式

HTTP 协议是基于 TCP/IP，并且使用了请求-应答的通信模式。

持久连接(Connection: Keep-Alive)

持久连接下，TCP 连接默认不关闭，可以被多个请求复用。采用持久连接的好处是可以避免每次建立 TCP 连接三次握手时所花费的时间

非持久连接

非持久连接指的是服务器必须为每一个请求的对象建立和维护一个全新的连接

HTTP的keep-alive有什么作用

http1.0默认关闭，需要手动开启，http1.1后默认开启。

作用

使客户端到服务器端的链接持续有效(长连接)，当出现对服务器的后续请求时，keep-Alive功能避免了建立或者重新建立链接。

使用方法

在请求头中加上Connection: Keep-Alive

优点

• 较少的CPU和内存的占用(因为要打开的连接数变少了，复用了连接)
• 减少了后续请求的延迟(无需再进行握手)

缺点

本来可以释放的资源仍旧被占用。有的请求已经结束了，但是还一直连接着。

解决方法

服务器设置过期时间和请求次数，超过这个时间或者次数就断掉连接。

DNS协议是什么

概念

DNS 是域名系统 (Domain Name System) 的缩写，提供的是一种主机名到 IP 地址的转换服务，就是我们常说的域名系统。它是一个由分层的 DNS 服务器组成的分布式数据库，是定义了主机如何查询这个分布式数据库的方式的应用层协议。能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。

作用

将域名解析为IP地址，客户端向DNS服务器（DNS服务器有自己的IP地址）发送域名查询请求，DNS服务器告知客户机Web服务器的 IP 地址

DNS完整的查询过程

DNS服务器解析域名的过程:

• 首先会在浏览器的缓存中查找对应的IP地址，如果查找到直接返回，若找不到继续下一步
• 将请求发送给本地DNS服务器，在本地域名服务器缓存中查询，如果查找到，就直接将查找结果返回，若找不到继续下一步
• 本地DNS服务器向根域名服务器发送请求，根域名服务器会返回一个所查询域的顶级域名服务器地址
• 本地DNS服务器向顶级域名服务器发送请求，接受请求的服务器查询自己的缓存，如果有记录，就返回查询结果，如果没有就返回相关的下一级的权威域名服务器的地址
• 本地DNS服务器向权威域名服务器发送请求，域名服务器返回对应的结果
• 本地DNS服务器将返回结果保存在缓存中，便于下次使用
• 本地DNS服务器将返回结果返回给浏览器

简述一下TCP的三次握手

第一次握手

客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态

第二次握手

服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完成后便进入 SYN-RECEIVED 状态

第三次握手

当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功

TCP什么要三次握手呢？两次不行吗？

三次握手的必要性

为了确认双方的接收能力和发送能力都正常

两次握手为什么不行

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

简述一下TCP的四次挥手

第一次挥手

若客户端认为数据发送完成，则它需要向服务端发送释放连接请求

第二次挥手

服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。

第三次挥手

服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态

第四次挥手

客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态。

TCP为什么需要四次挥手呢

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，"你发的FIN报文我收到了"。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送，故需要四次挥手

token是什么

1、token也可以称做令牌，一般由 uid+time+sign(签名)+[固定参数] 组成

• uid: 用户唯一身份标识
• time: 当前时间的时间戳
• sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接
• 固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库

2、token 的认证流程

• 用户登录，成功后服务器返回Token给客户端。
• 客户端收到数据后保存在客户端
• 客户端再次访问服务器，将token放入headers中 或者每次的请求 参数中
• 服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

3、token可以抵抗csrf，cookie+session不行

4、session是有状态的，一般存于服务器内存或硬盘中，当服务器采用分布式或集群时，session就会面对负载均衡问题。负载均衡多服务器的情况，不好确认当前用户是否登录，因为多服务器不共享session

5、客户端登陆传递信息给服务端，服务端收到后把用户信息加密（token）传给客户端，客户端将token存放于localStroage等容器中。客户端每次访问都传递token，服务端解密token，就知道这个用户是谁了。通过cpu加解密，服务端就不需要存储session占用存储空间，就很好的解决负载均衡多服务器的问题了。这个方法叫做JWT(Json Web Token)

token是怎么加密的

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

cookie和token都放在header中，为什么会劫持cookie，不会劫持token

cookie

登陆后后端生成一个sessionid放在cookie中返回给客户端, 并且服务端一直记录着这个 sessionid, 客户端以后每次请求都会带上这个sessionid, 服务端通过这个sessionid来验证身份之类的操作。所以别人拿到了cookie就相当于拿到了sessionid ,就可以完全替代你。同时浏览器会自动携带cookie

token

同样是登录后服务端返回一个token，客户端保存起来，在以后http请求里手动的加入到请求头里，服务端根据token 进行身份的校验。浏览器不会自动携带token，所以不会劫持 token

token过期后，页面如何实现无感刷新

什么是无感刷新

后台返回的token是有时效性的，时间到了，你在交互后台的时候，后台会判断你的token是否过期（安全需要），如果过期了就会逼迫你重新登陆！

token无感刷新其本质是为了优化用户体验,当token过期时不需要用户跳回登录页重新登录,而是当token失效时,进行拦截,发送刷新token的ajax,获取最新的token进行覆盖,让用户感受不到token已经过期

实现无感刷新

方式一

后端返回过期时间，前端判断token过期时间,去调用刷新token接口

缺点：需要后端额外提供一个token过期时间的字段；使用了本地时间判断，若本地时间篡改，特别是本地时间比服务器时间慢时，拦截会失败。

方式二

写个定时器，定时刷新token接口 缺点：浪费资源,消耗性能,不建议采用

方式三

在响应拦截器中拦截，判断token 返回过期后，调用刷新token接口

OSI的七层模型

OSI(Open System Interconnection)，即开放系统互联。是ISO（国际标准化组织）制定的一个用于计算机或通信系统间互联的标准体系，一般称为OSI参考模型或七层模型。

物理层

为数据端设备提供原始的比特流的传输的通路。建立、维护、断开物理连接。 常见设备：网线、集线器、中继器、调制解调器。

数据链路层

在通信实体间建立数据链路连接、进行硬件地址（MAC地址）寻址、差错校验等。 常见设备：网卡、网桥、交换机。 主要协议：ARP地址解析协议、RARP逆向地址解析协议。

网络层

为数据在结点之间传输创建逻辑链路，并分组转发数据。 常见设备：路由器。 主要协议：ICMP（互联网控制信息协议）、IGMP（互联网和管理协议）、IP(IPv4、IPv6)（互联网协议）

传输层

提供应用进程之间的逻辑通信。定义传输数据的协议端口号，以及流控和差错校验。 主要协议：TCP传输控制协议、UDP用户数据报协议。

一些常见应用协议端口号：

会话层

建立、管理和终止会话（session）。 主要协议：SSL（安全套接字层协议）、TLS（传输层安全协议）

表示层

对应用层数据编码，提供数据格式转换服务。 定义数据格式：JPEG、ASCII、EBCDIC、DES、GIF等。

应用层

提供应用接口，为用户直接提供各种网络服务。 主要协议：HTTP/HTTPS（超文本传输协议）、FTP（文件传输协议）、SMTP（简单邮件传输协议）、TELNET（TCP/IP终端仿真协议）、DHCP（动态主机配置协议）、TFTP（简单文件传输协议）、SNMP（简单网络管理协议）

TCP/IP四层模型

网络接口层

实现了网卡接口的网络驱动程序，以处理数据在物理媒介（如以太网、令牌环等）上的传输。 这一层包含CSMA/CDCarrier Sense Multiple Access With Collision Detection(即载波侦听多路访问/冲突检测和CSMA/CA(Carrier Sense multipleAccess With Collision Avoidance),即载波监听多路访问/冲突避免，都是争用型的介质访问控制协议，位于数据链路层，前者用于有线网络而后者用于无线网络。

网际层（网络层）

本层主要包含IP协议、RIP路由信息协议，负责数据的包装、寻址和路由转发。同时还包含ICMP（互联网控制报文协议）用来提供网络诊断信息。本层还包含ARP地址解析协议和RARP逆向地址解析协议。它们实现了IP地址和主机物理地址（通常是MAC地址，以太网、令牌环和802.11无线网络都使用MAC地址）之间的转换。

传输层

为两台主机上的应用程序提供端到端的通信。与网际层使用的逐跳通信不同，传输层只关心通信的起始端和目的端，而不在乎数据包的中转过程。 主要包括TCP协议提供可靠的数据流运输服务和UDP协议提供不可靠的数据报服务。

应用层

负责处理应用程序的逻辑。

七层模型和四层模型对比

HTTPS相关

什么是HTTPS协议

超文本传输安全协议（Hypertext Transfer Protocol Secure，简称：HTTPS）是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，利用SSL/TLS来加密数据包。 HTTPS的主要目的是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

HTTP协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能，可以避免此类问题发生。

安全层的主要职责就是对发起的HTTP请求的数据进行加密操作和对接收到的HTTP的内容进行解密操作。

HTTP和HTTPS协议的区别

HTTP和HTTPS协议的主要区别如下：

• HTTPS协议需要CA证书，费用较高；而HTTP协议不需要
• HTTP协议是超文本传输协议，信息是明文传输的，HTTPS则是具有安全性的SSL加密传输协议
• 使用不同的连接方式，默认端口也不同，HTTP协议端口是80，HTTPS协议端口是443
• HTTP协议连接很简单，是无状态的；HTTPS协议是有SSL和HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP更加安全。

TLS/SSL的工作原理

TLS全称安全传输层协议（Transport Layer Security）及其前身安全套接层（Secure Sockets Layer，缩写作SSL） 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。

TLS/SSL的功能实现主要依赖三类基本算法：散列函数hash、对称加密、非对称加密。这三类算法的作用如下：

• 散列算法用来验证信息的完整性
• 对称加密算法采用协商的秘钥对数据加密
• 非对称加密实现身份认证和秘钥协商

对称加密

概念

对称加密的特点是文件加密和解密使用相同的密钥，即加密密钥也可以用作解密密钥，这种方法在密码学中叫做对称加密算法。对称加密算法使用起来简单快捷，密钥较短，且破译困难，通信的双⽅都使⽤同⼀个秘钥进⾏加密, 解密。⽐如，两个人事先约定的暗号，就属于对称加密。

优点

计算量小、加密速度快、加密效率高。

缺点

在数据传送前，发送方和接收方必须商定好秘钥，然后双方保存好秘钥。如果一方的秘钥被泄露，那么加密信息也就不安全了。 最不安全的地方, 就在于第一开始, 互相约定密钥的时候!!! 传递密钥!

使用场景

本地数据加密、https 通信、网络传输等

非对称加密

概念

通信的双方使用不同的秘钥进行加密解密，即秘钥对（私钥 + 公钥）。

特征: 私钥可以解密公钥加密的内容, 公钥可以解密私钥加密的内容

优点

非对称加密与对称加密相比其安全性更好

缺点

加密和解密花费时间长、速度慢，只适合对少量数据进行加密

使用场景

https 会话前期、CA 数字证书、信息加密、登录认证等

HTTPS是如何保证安全的

结合对称加密和非对称加密两种加密⽅式，将对称加密的密钥使⽤⾮对称加密的公钥进⾏加密，然后发送出去，接收⽅使⽤私钥进⾏解密得到对称加密的密钥，然后双⽅可以使⽤对称加密来进⾏沟通。 这个时候还需要⼀个安全的第三⽅颁发证书（CA），证明双方的身份，防⽌被中间⼈攻击。

为了防止中间人篡改证书，需要用到数字签名这个技术。

数字签名就是⽤CA⾃带的HASH算法对证书的内容进⾏HASH得到⼀个摘要，再⽤CA的私钥加密，最终组成数字签名。当别⼈把他的证书发过来的时候,我再⽤同样的Hash算法,再次⽣成消息摘要，然后⽤CA的公钥对数字签名解密,得到CA创建的消息摘要,两者⼀⽐,就知道中间有没有被⼈篡改了。这个时候就能最⼤程度保证通信的安全了。

数字证书

概念

使用一种 Hash 算法来对公钥和其他信息进行加密，生成一个信息摘要，然后让有公信力的认证中心（简称 CA ）用它的私钥对消息摘要加密，形成签名。最后将原始的信息和签名合在一起，称为数字证书。当接收方收到数字证书的时候，先根据原始信息使用同样的 Hash 算法生成一个摘要，然后使用公证处的公钥来对数字证书中的摘要进行解密，最后将解密的摘要和生成的摘要进行对比，就能发现得到的信息是否被更改了。

作用

现在的方法也不一定是安全的，因为没有办法确定得到的公钥就一定是安全的公钥。可能存在一个中间人，截取了对方发给我们的公钥，然后将他自己的公钥发送给我们，当我们使用他的公钥加密后发送的信息，就可以被他用自己的私钥解密。然后他伪装成我们以同样的方法向对方发送信息，这样我们的信息就被窃取了，然而自己还不知道。为了解决这样的问题，可以使用数字证书。

数字签名

数字签名就是先用CA自带的Hash算法来计算出证书内容的一个摘要，然后使用CA私钥进行加密，组成数字签名。

当别人把他的数字证书发过来时，接收方用同样的算法再次生成摘要，用CA公钥解密后得到CA生成的摘要，两者进行对比后，就能确定中间是否被人篡改。这样就能最大程度的保证通信的安全了。

HTTPS通信（握手）过程

HTTPS的通信过程如下：

• 客户端向服务器发起请求，请求中包含使用的协议版本号、生成的一个随机数、以及客户端支持的加密方法。
• 服务器端接收到请求后，确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数。
• 客户端确认服务器证书有效后，生成一个新的随机数，并使用数字证书中的公钥，加密这个随机数，然后发给服务器。并且还会提供一个前面所有内容的hash的值，用来供服务器检验。
• 服务器使用自己的私钥，来解密客户端发送过来的随机数。并提供前面所有内容的hash值来供客户端检验。
• 客户端和服务器端根据约定的加密方法使用前面的三个随机数，生成对话秘钥，以后的对话过程都使用这个秘钥来加密信息。

HTTPS的优缺点

优点

• 使用HTTPS协议可以认证用户和服务器，确保数据发送到正确的客户端和服务器;
• 使用HTTPS协议可以进行加密传输、身份认证，通信更加安全，防止数据在传输过程中被窃取、修改，确保数据安全性；
• HTTPS是现行架构下最安全的解决方案，虽然不是绝对的安全，但是大幅增加了中间人攻击的成本

缺点

• HTTPS需要做服务器和客户端双方的加密个解密处理，耗费更多服务器资源，过程复杂
• HTTPS协议握手阶段比较费时，增加页面的加载时间
• SSL证书是收费的，功能越强大的证书费用越高
• HTTPS连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本
• SSL证书需要绑定IP，不能再同一个IP上绑定多个域名

以上内容收藏于我的github,持续更新,欢迎star