目录

1. HTTP状态码304是多好还是少好？

服务器为了提高网站访问速度，对之前访问的部分页面制定缓存机制，当客户端在此对这些页面进行请求，服务器会根据缓存内容判断页面与之前是否相同，若相同便直接返回304，此时客户端调用缓存内容，不必进行二次下载。

状态码304不应该认为是一种错误，而是对客户端有缓存情况下服务端的一种响应。

搜索引擎蜘蛛会更加青睐内容源更新频繁的网站。通过特定时间内对网站抓取返回的状态码来调节对该网站的抓取频次。若网站在一定时间内一直处于304的状态，那么蜘蛛可能会降低对网站的抓取次数。相反，若网站变化的频率非常之快，每次抓取都能获取新内容，那么日积月累，的回访率也会提高。

产生较多304状态码的原因：

  • 页面更新周期长或不更新
  • 纯静态页面或强制生成静态html

304状态码出现过多会造成以下问题：

  • 网站快照停止
  • 收录减少
  • 权重下降

2. 长连接与keep-alive

HTTP1.0 中默认是在一次每个请求/应答，客户端和服务器都要新建一个连接，完成之后立即断开连接，这就是短连接。当使用Keep-Alive模式时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接，这就是长连接。

  • HTTP1.0版本是默认没有Keep-alive的（也就是默认会发送keep-alive），所以要想连接得到保持，必须手动配置发送​​connection:keep-alive​​字段。若想断开keep-alive连接，需发送​​Connection:close​​字段
  • HTTP1.1规定了默认保持长连接，数据传输完成了保持TCP连接不断开，等待在同域名下继续用这个通道传输数据。如果需要关闭，需要客户端发送Connection：close首部字段。

Keep-Alive的建立过程：

  • 客户端向服务器在发送请求报文同时在首部添加发送Connection字段
  • 服务器收到请求并处理connection字段
  • 服务器回送Connection:Keep-Alive字段给客户端
  • 客户端接收到connection字段
  • Keep-Alive连接建立成功

服务端自动断开过程（也就是没有keep-alive）：

  • 客户端向服务器只是发送内容报文（不包含Connection字段）
  • 服务器收到请求并处理
  • 服务器返回客户端请求的资源并关闭连接
  • 客户端接收资源，发现没有Connection字段，断开连接

客户端请求断开连接过程：

  • 客户端向服务器发送Connection:close字段
  • 服务器收到请求并处理connection字段
  • 服务器回送响应资源并断开连接
  • 客户端接收资源并断开连接

开启Keep-Alive的优缺点：

  • 优点：Keep-Alive模式更加高效，因为避免了连接建立和释放的开销。
  • 缺点：长时间的Tcp连接容易导致系统资源无效占用，浪费系统资源。

3. session和JWT的区别

session和JWT（JSON Web Token）是两种用户认证的方式。

（1）基于session的认证流程如下

  • 用户输入其登录信息
  • 服务器验证信息是否正确，并创建一个session，然后将其存储在数据库中
  • 服务器为用户生成一个sessionId，将具有sesssionId的Cookie将放置在用户浏览器中
  • 在后续请求中，会根据数据库验证sessionID，如果有效，则接受请求
  • 一旦用户注销应用程序，会话将在客户端和服务器端都被销毁

（2）基于token（令牌）的用户认证

最常用的是JSON Web Token（jwt）：

  • 用户输入其登录信息，进行登录
  • 服务器验证信息是否正确，并返回已签名的token
  • token储在客户端，例如存在local storage或cookie中
  • 之后的HTTP请求都将token添加到请求头里
  • 服务器解码JWT，并且如果令牌有效，则接受请求
  • 一旦用户注销，令牌将在客户端被销毁，不需要与服务器进行交互一个关键是，令牌是无状态的。后端服务器不需要保存令牌或当前session的记录。

jwt的组成：

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

  • 头部：用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等。
{  "typ": "JWT",  "alg": "HS256"}
在这里，我们说明了这是一个JWT，并且我们所用的签名算法是HS256算法。
  • 载荷：可以用来放一些不敏感的信息。
  • 签名：将上面拼接完的字符串用HS256算法进行加密。在加密的时候，我们还需要提供一个密钥（secret）。加密后的内容也是一个字符串，最后这个字符串就是签名，把这个签名拼接在刚才的字符串后面就能得到完整的jwt。header部分和payload部分如果被篡改，由于篡改者不知道密钥是什么，也无法生成新的签名部分，服务端也就无法通过，在jwt中，消息体是透明的，使用签名可以保证消息不被篡改。

session和JWT的区别：

  • 对于用户的状态保存的位置：session是保存在服务端的，而jwt是保存在客户端的。
  • 对于安全性：由于jwt的payload是使用base64编码的，并没有加密，因此jwt中不能存储敏感数据。而session的信息是存在服务端的，相对来说更安全。
  • 对于两者长度：jwt太长，cookie的限制大小一般是4k，cookie很可能放不下，所以jwt一般放在local storage里面。而sessionId只是很短的一个字符串，因此使用jwt的http请求比使用session的开销大得多。
  • 对于使用时间： jwt是一次性的。如果想修改里面的内容，就必须签发一个新的jwt。
  • 对于扩展性：jwt可扩展性好，在应用程序分布式部署的情况下，session需要做多机数据共享，通常可以存在数据库或者redis里面。而jwt不需要。
  • 对于实用性：jwt的载荷中可以存储一些常用信息，用于交换信息，有效地使用 JWT，可以降低服务器查询数据库的次数。

4. HTTP协议是无状态的，那如何判断用户的登录状态的？

个人理解，通过上面的两种方式session和JWT来判断用户登录，如果获取到用户的SessionId或者是能获得token值就可以判断用户登录了。

5. get 和 post 的区别？put 和 post 的区别 ？

（1）​​GET​​ 和 ​​POST​​请求之间的区别：

  • 从用途的角度，​​GET​​​方法主要用于请求从服务器获取资源，​​POST​​​方法主要用于向​​URI​​指定的资源提交数据。
  • 从缓存的角度，​​GET​​​请求会被浏览器主动缓存下来，留下历史记录，而​​POST​​不会缓存。
  • 从编码的角度，​​GET​​​请求只能进行​​URL​​​编码，只能接收​​ASCII​​字符，而POST没有限制。
  • 从TCP的角度，​​GET​​​ 请求会把请求报文一次性发出去，而​​POST​​​ 会分为两个​​TCP​​​ 数据包，首先发​​header​​​ 部分，如果服务器响应 100(continue)， 然后发​​body​​ 部分。(火狐浏览器除外，它的 POST 请求只发一个 TCP 包)。
  • 从幂等性的角度，​​GET​​​方法是幂等的，而​​POST​​不是。(幂等表示执行相同的操作，结果也是相同的)。
  • 从安全的角度，​​GET​​​方法是安全的，因为只会读取服务器上的数据，无论怎么操作，服务器数据都是安全的；而​​POST​​方法是新增或者提交数据，会修改服务器上的资源，每次提交都会创建资源，所以是不安全的。

（2）​​POST​​ 和 ​​PUT​​请求之间的区别：

  • PUT请求是向服务器端发送数据的，从而修改数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次PUT操作，其结果并没有不同。（可以理解为时更新数据）
  • POST请求是向服务器端发送数据的，该请求会改变数据的种类等资源，它会创建新的内容。（可以理解为是创建数据）

除此之外。post 是可以被缓存的，put 不能被缓存。

6. get方法URL长度限制的原因？

实际上HTTP协议规范并没有对get方法请求的url长度进行限制，这个限制是特定的浏览器及服务器对它的限制。

IE对URL长度的限制是2083字节(2K+35)。由于IE浏览器对URL长度的允许值是最小的，所以开发过程中，只要URL不超过2083字节，那么在所有浏览器中工作都不会有问题。

GET的长度值 = URL（2083）- （你的Domain+Path）-2（2是get请求中?=两个字符的长度）

下面看一下主流浏览器对get方法中url的长度限制范围：

  • Microsoft Internet Explorer (Browser)：IE浏览器对URL的最大限制为2083个字符，如果超过这个数字，提交按钮没有任何反应。
  • Firefox (Browser)：对于Firefox浏览器URL的长度限制为65,536个字符。
  • Safari (Browser)：URL最大长度限制为 80,000个字符。
  • Opera (Browser)：URL最大长度限制为190,000个字符。
  • Google (chrome)：URL最大长度限制为8182个字符。

再来看一下主流的服务器对get方法中url的长度限制范围：

  • Apache (Server)：能接受最大url长度为8,192个字符。
  • Microsoft Internet Information Server(IIS)：能接受最大url的长度为16,384个字符。

根据上面的数据，我们可以知道，get方法中的URL长度最长不超过2083个字符，这样所有的浏览器和服务器都可能正常工作。

7. ajax 和 axios 的区别 ？

在说两者的区别之前，先分别回忆一下这两个请求。

AJAX 是与服务器交换数据并更新部分网页的，在不重新加载整个页面的情况下。
Ajax = 异步 JavaScript 和 XML（标准通用标记语言的子集）。

Axios 是一个基于 promise 的 HTTP 库，可以用在浏览器和 node.js 中。其特点如下：

  • 从浏览器中创建 XMLHttpRequests
  • 从 node.js 创建 http 请求
  • 支持 Promise API
  • 拦截请求和响应
  • 转换请求数据和响应数据
  • 取消请求
  • 自动转换 JSON 数据
  • 客户端支持防御 XSRF

我们知道，这两者都是用来发起数据请求的，再来看一下两者的使用方法：

// ajax:

　$.ajax({
　　　　url: '接口地址',
　　　　type: 'get', //请求类型
　　　　dataType: 'json',
　　　　data: { // 要发送的请求参数
　　　　　　'username' : 'admin',
　　　　　　'password' : 'admin'
　　　　},
　　　　success : function (response) {
　　　　　　console.log(response); // 请求返回的数据
　　　　}
　　})

// axios:

　axios({
　　　　url: '接口地址',
　　　　method: 'get', //请求类型
　　　　responseType: 'json', //默认格式，如果就是 json 格式可以不写
　　　　data: {
　　　　　　'username' : 'admin',
　　　　　　'password' : 'admin'
　　　　}
　　}).then( function(response){ // 请求正确返回的数据
　　　　console.log(response);
　　　　console.log(response.data);
　　}).catch( function(error) { // 请求错误返回的数据
　　　　console.log(error);
　　})

其实两者在写法上是没有太大区别的，就是个别参数不一样。在这个大前端的时代，axios更适合在前端MVVM模式下使用，而ajax本身是针对MVC模式的编程。