什么是Nginx？

Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器，

Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。

Nginx有哪些应用场景

Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强

应用场景：

静态资源处理、动静分离 、反向代理、负载均衡。Tomcat集群。

正向代理和反向代理区别

- 正向代理是在客户端的。比如需要访问某些国外网站，我们可能需要购买vpn。并且vpn是在我们的用户浏览器端设置的(并不是在远端的服务器设置)。浏览器先访问vpn地址，vpn地址转发请求，并最后将请求结果原路返回来。

- 反向代理是作用在服务器端的，是一个虚拟ip。对于用户的一个请求，会转发到多个后端处理器中的一台来处理该具体请求

长连接和短连接区别

- 短连接：连接->传输数据->关闭连接，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。

- 长链接：连接->传输数据->保持连接 -> 传输数据-> ...........->直到一方关闭连接，多是客户端关闭连接。长连接指建立SOCKET连接后 不管是否使用都保持连接，但安全性较差。

HTTP和HTTPS区别

HTTP与HTTPS的区别:

　　1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。

　　2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

　　3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

　　4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

HTTP和HTTPS优缺点对比

HTTPS的优缺点:

优点：

1、使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

2、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。

3、HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

缺点：

1、HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；

2、HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

3、SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

4、SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

5、HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

什么是集群

同一个业务，部署在多个服务器上,对外提供相同的功能。

什么是负载均衡

将服务器接收到的请求按照规则分发的过程，称为负载均衡

Nginx负载均衡有哪些规则(算法）？

1. 轮询（默认）

2. 指定轮询几率

3. ip_hash

4. url_hash（第三方）

5. fair（第三方）

描述TCP和UDP区别

TCP应用场景：效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。例如：文件传输(准确高要求高、但是速度可以相对慢)、接受邮件、远程登录

　UDP应用场景：效率要求相对高，对准确性要求相对低的场景。例如：QQ聊天、在线视频、网络语音电话(即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制)、广播通信(广播、多播)。

集群/分布式环境下session处理策略

集群是个物理形态，分布式是个工作方式。

• 分布式：一个业务分拆多个子业务，部署在不同的服务器上
• 集群：同一个业务，部署在多个服务器上

为什么要处理session？

这个问题想必大多数朋友都知道，在搭建完集群或者分布式环境之后，如果不做任何处理的话，网站将频繁的出现用户未登录的现象。比如：集群中有A、B两台服务器，用户第一次访问网站时，Nginx将用户请求分发到A服务器，这时A服务器给用户创建了一个Session，当用户第二次访问网站时，假设Nginx将用户请求分发到了B服务器上，而这时B服务器并不存在用户的Session，所以就会出现用户未登录的情况，这对用户来说是不可忍受的。

所以我们在搭建集群/分布式环境之后，必须考虑的一个问题就是用户访问产生的session如何处理，即session的共享机制

解决方案

我们将处理Session的方式大致分为三种：

Session保持（也有人叫黏性Session）、

Session复制。

Session共享。

Session保持（或者叫黏性Session）

Session保持（会话保持）就是将用户锁定到某一个服务器上。比如上面说的例子，用户第一次请求时，负载均衡器（Nginx）将用户的请求分发到了A服务器上，如果负载均衡器（Nginx）设置了Session保持的话，那么用户以后的每次请求都会分发到A服务器上，相当于把用户和A服务器粘到了一块，这就是Session保持的原理。Session保持方案在所有的负载均衡器都有对应的实现。而且这是在负载均衡这一层就可以解决Session问题。

优点：非常简单，不需要对session做任何处理。 缺点：1、负责不均衡了：由于使用了Session保持，很显然就无法保证负载的均衡。 缺乏容错性：如果后端某台服务器宕机，那么这台服务器的Session丢失，被分配到这台服务请求的用户还是需要重新登录，所以没有彻底的解决问题。

实现方式：以Nginx为例，在upstream模块配置ip_hash属性即可实现粘性Session

Session复制

针对Session保持的容错性缺点，我们可以在所有服务器上都保存一份用户的Session信息。这种将每个服务器中的Session信息复制到其它服务器上的处理办法就称为会话复制。当任何一台服务器上的session发生改变时，该节点会把session的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要session，以此来保证Session同步。

优点：可容错，各个服务器间的Session能够实时响应。 缺点：将session广播同步给成员，会对网络负荷造成一定压力

Session共享

SpringSession+Redis方式实现