nginx学习
常见web服务器
- 微软的IIS,主要是用于发布一些asp.net的项目
- 收费的
- J2EE模式开发
- Nginx的成本更低，配置简单，支持的并发比Apache更高；Apache出现的更早，以前很多公司用; Apache在超过百万级别并发的时候，性能会逐渐的下降
- 高性能服务器, 可以通过一些编码来构建无服务(聊天室...)
正向代理和反向代理
正向代理：代理的是客户端
- 客户端请求目标服务器之间的一个代理服务器
- 请求会先经过代理服务器，然后在转发请求到目标服务器，获得内容后最后响应给客户端。（访问慕课网，不会直接到慕课网会先经过电信或者是联通的服务器然后再到慕课网。电信的服务器就是正向代理服务器）
反向代理：代理的是服务器
- 用户请求目标服务器，具体访问哪一个IP由反向代理服务器决定。
反向代理的作用：
1、负载均衡
2、通过域名进行服务分发（路由）
Nginx
反向代理服务器
通过配置文件可以实现集群和负载均衡，可以热加载，不需要重启服务器就能生效。
可以把静态资源,css，图片等等这些虚拟化成一个服务
解析规则
进程模型
nginx采用单主进程，多子进程(nginx.conf worker_processes 默认为1)的模型
master管理worker，master接收外部请求或指令，分配给worker去执行
worker关闭时，会等待当前客户端连接释放后，才会关闭
多进程虽然会带来额外的内存开销，采用多进程而不采用多线程的原因:
- 进程之间相互独立，互不影响，某一个worker出问题不会影响其他worker，一个挂了不影响其他的，主进程只需要fork新的工作进程即可
- 不需要开发人员去额外关注线程安全性，和进行内存管理
- 假设被黑客攻击，可能攻击的只会是一个worker进程，那么只要关掉这一个进程即可，这也是多进程的好处
nginx worker抢占机制
Worker抢占机制，由worker去抢互斥锁，谁抢到了就是谁和client去连接，去处理请求，进行解析、处理、响应。
事件处理
传统服务器
同步阻塞模型 bio
- master->fork(调用) worker1,worker处理client1,2,3; (正常情况)
- 当其中有一个客户端(client)发生阻塞
2.1 master 会在 fork 一个新的客户端 worker2, 之前的worker1处理阻塞的客户端client1
(这种同阻塞的方式性能是非常低的 , 当并发量达到几千万/几百万, 会开很多进程去处理client,如果与客户端连接都是阻塞的话，资源开销会非常的高)
nginx服务器处理
并发数处理非常多
异步非阻塞模型
配置nginx的请求处理
{
#默认使用epoll，这是在linux上最适合的一种事件机制
use epoll;
#每个worker允许连接的客户端最大连接数, 不能配置太多，还是要根据硬件来，避免cpu负荷太高；太低用户请求数多就会阻塞
worker_connections 10240;
}
linux默认的就是使用epoll，设置每个worker允许连接的客户端最大连接数为10240个，通常情况下，可以将worker_connections设置为硬件可支持的最大连接数。
nginx高效的原因：抢占机制，采用epoll异步非阻塞通信模型，多路复用器（websocket聊天室也可用）；
当master接受到请求，worker处理阻塞时，不会等待，会执行下一个请求，不会使用很大的开销，一个worker可以处理多个client请求，高并发
可以通过nginx.conf中的worker_connections配置每个worker进程的最大连接数，worker_connections要根据服务器的配置进行设置，不能设置的太大，防止服务器压力过大
nginx常见命令
whereis nginx命令：查看nginx的安装路径
nginx常见命令：
./nginx：启动nginx
./nginx -s quit：优雅关闭nginx，等请求完毕再关闭nginx，针对http请求，不是则不行
./nginx -s stop：暴力停止nginx，对非法用户可以
./nginx -s reload：重新加载nginx的配置文件
./nginx -t：检查配置文件的配置是否正确
./nginx -v：检查版本号
./nginx -V：检查版本号详细
./nginx -?：帮助
./nginx -c：手动切换配置文件，配置文件可以根据环境配置多个
nginx.conf配置文件
1.整个配置项是一个main配置
2.整个配置中分为两种：配置指令和指令块。配置指令是单条的配置项，以;结束。指令块是以{}结束，没有;
5.注释使用#
6.$符号代表参数变量
https://class.imooc.com/lesson/1227#mid=28748
nginx日志切割
https://class.imooc.com/lesson/1227#mid=28749
现有的日志都会存在 access.log 文件中，但是随着时间的推移，这个文件的内容会越来越多，体积会越来越大，不便于运维人员查看，所以我们可以通过把这个大的日志文件切割为多份不同的小文件作为日志，切割规则可以以天为单位，如果每天有几百G或者几个T的日志的话，则可以按需以每半天或者每小时对日志切割一下。
具体步骤如下：
- 创建一个shell可执行文件：cut_my_log.sh，内容为：
#!/bin/bash LOG_PATH="/var/log/nginx/" RECORD_TIME=$(date -d "yesterday" +%Y-%m-%d+%H:%M) PID=/var/run/nginx/nginx.pid mv ${LOG_PATH}/access.log ${LOG_PATH}/access.${RECORD_TIME}.log mv ${LOG_PATH}/error.log ${LOG_PATH}/error.${RECORD_TIME}.log #向Nginx主进程发送信号，用于重新打开日志文件 kill -USR1 `cat $PID` - 为cut_my_log.sh添加可执行的权限：
chmod +x cut_my_log.sh - 测试日志切割后的结果:
./cut_my_log.sh
定时任务自动切割
https://class.imooc.com/lesson/1227#mid=28750
- crontab -e 编辑并添加一行新的任务：
*/1 * * * * /usr/local/nginx/sbin/cut_my_log.sh - 重启定时任务
service crond restart
静态资源映射
静态资源服务器的本质是：
可以通过web服务器将Linux服务上的任何文件对外开放
Ngnix实现静态资源服务器的方式是：
借助server配置，将location路由到要对外开放的文件上
可以使用alias定义别名，使用别名可以隐藏服务器的目录结构，防止用户通过服务器目录结构攻击服务器
location /static {
alias /usr/local/tomcat-frontend/webapps/imooc;
}
实际访问地址是：ip:port/static/audio/abc.mp3
注意：imooc被static覆盖了
location /imooc {
root /usr/local/tomcat-frontend/webapps/;
index index.html;
}
实际访问地址是：imooc会跟root的路劲拼接
location /imooc {
root /home;
}
location /static{
alias /home/imooc;
}
https://class.imooc.com/lesson/1227#mid=28751
压缩传输
# 开启压缩功能，提高传输效率，节约带宽
gzip on;
#限制最小压缩大小，单位字节，小于该大小的文件不会压缩
gzip_min_length 1;
#定义压缩的级别（压缩比，范围1~9，文件越大，压缩越多，但是cpu使用会越多）
gzip_comp_level 3;
#定义压缩文件类型
gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png application/json;
location匹配规则
● 匹配规则
◆ 空格：默认匹配——普通匹配
◆ =：精确匹配
◆ ~*:匹配正则表达式，不区分大小写
◆ ~:匹配正则表达式，区分大小写
◆ ^:以某个字符路径开头
● 匹配规则
◆ 空格：默认匹配——普通匹配
◆ =：精确匹配
◆ ~*:匹配正则表达式，不区分大小写
◆ ~:匹配正则表达式，区分大小写
◆ ^:以某个字符路径开头
https://class.imooc.com/lesson/1227#mid=28752
启动nginx失败异常解决
- 遇到启动失败报错：nginx: [emerg] open() "/var/run/nginx/nginx.pid" failed (2: No such file or directory)
解决：
第一步: 创建/var/run/nginx目录，使用命令mkdir /var/run/nginx
第二步: ./nginx -s reload重新加载nginx加载成功则可以正常使用nginx。 - 出现nginx: [error] invalid PID number "" in "/var/run/nginx/nginx.pid"报错则需进行第三步。
第三步：./nginx -c /usr/local/nginx/conf/nginx.conf 重新指定nginx安装目录的配置文件./nginx -s reload
nginx.conf配置默认的pid是放在 logs之下的; 也可以在logs目录下创建默认的pid文件
nginx设置允许跨域
https://zhuanlan.zhihu.com/p/51627189
跨域问题的本质：
两个站点域名不一样，就会出现跨域问题。(浏览器只允许JavaScript或Cookie访问同域下的内容)
所以跨域问题的本质是域名不同
跨域问题的出现是因为出于安全问题，W3C标准规范
#允许跨域请求的域，*代表所有
add_header 'Access-Control-Allow-Origin' *;
#允许带上cookie请求
add_header 'Access-Control-Allow-Credentials' 'true';
#允许请求的方法，比如 GET/POST/PUT/DELETE
add_header 'Access-Control-Allow-Methods' *;
#允许请求的header
add_header 'Access-Control-Allow-Headers' *;
静态资源防盗链
#对源站点验证
valid_referers *.imooc.com;
#非法引入会进入下方判断
if ($invalid_referer) {
return 404;
}
// imooc配置，使用这个配置出现主站404
#对源站点验证
valid_referers *.centres.top;
#非法引入会进入下方判断
if ($invalid_referer) {
return 404;
}
// 新配置，正常启用
#对源站点验证
valid_referers none block *.centres.top;
#非法引入会进入下方判断
if ($invalid_referer) {
return 404;
}
nginx的模块化体系
http是nginx当中的一个模块，
nginx core核心内容，实现了底层的通信协议，为其他的模块和nginx的进程提供运行时环境，类似JVM，协调其他的各个模块；
核心中的一部分；
event module 操作系统层的处理机制
各层含义
event module：事件模块 （linux默认的事件机制:epoll，是操作系统层面的事件处理机制）
phase handler：处理客户端请求和以及相应内容的响应，
output filter：内容响应后会经过output filter,会过滤一部分的内容，把内容再返回到浏览器，再去做响应。输出过滤，例如gzip，
upstream：反向代理模块，会把请求打到真正的服务器去处理，
load balancer：和upstream相关的就是load balancer,负载均衡器，它是实现集群、负载均衡的一些配置
extend module：继承模块，可以用到第三方模块
nginx安装目录解析
auto 自动检测操作系统，编译相关脚本
changes 历史版本号
changes.ru 由俄罗斯开发的,带ru的后缀
conf 安装完毕后,会把conf文件安装到使用目录里
configure 用于编译和配置
contrib 工具包（地理位置等）
html 存放默认的静态文件,也会拷贝到 我们安装目录里
License 协议和说明
Makefile 编译完会生成该文件
man Nginx的一些守则
obj 实现第三方的插件和模块的时候（ngx_module 引用三方插件时，可以将指针引入）
readme
src 源码
源码
core 核心模块代码
event 系统层机制，封装了相应的方法和模块，linux->epoll
http http模块相关
mail 作mail邮件的代理和收发
misc 辅助代码
os 操作系统相关代码的封装和调用
stream upstream相关策略
负载均衡
上游 web服务器
下游 请求客户端
四层/七层负载均衡
- 能够为企业网络设备或者服务器带来更好的服务
- 可以提高吞吐量，提高服务性能，以及服务器的处理性能；
- 可以提高服务器计算能力，使网络设备更加灵活
- 当并发大量请求的时候，负载均衡可以将请求分配到计算机的多个节点上，从而减轻服务器的并发压力, 缩减用户请求的等待时间
四层负载均衡 (传输层 : TCP/UDP) (常用 LVS)
四层是基于传输层的，主要基于tcp和udp
- 概念: 四层负载均衡是基于IP+端口的负载均衡
- 原理: 通过转发请求到后台服务器,只负责转发
- 长连接: 记录当前请求是由那一台服务器处理的，并且之后这个客户端发送的请求将会由这台服务器处理(相当于长连接，这个长连接一旦打开就会一直处理连接的状态，它的性能就会非常的高了)
四层负载均衡策略
- F5负载均衡: 基于硬件的硬负载均衡，功能强，性能高，稳定性好，贵也是很贵商业级别的负载均衡；
- LVS四层负载均衡: Linux内核的四层负载，和协议无关，主要是负责转发一些 请求的，它是基于CS端的
- Haproxy： 四层负载均衡，支持转发功能，除了做四层以外也能够做七层的负载均衡，灵活性高
- Nginx四层负载均衡: 新版本可以做四层负载均衡（可以用于实现四层协议的转发、代理等等）
- 一般来说还是做7层负载均衡，主要是基于http的一个负载均衡
- 在nginx1.9版本后，新增了一个基于stream的四层负载均衡
七层负载均衡（基本用语处理http协议的） (常用Nginx)
- 概念: 基于url/IP的负载均衡;基于应用层，基于http协议的负载均衡
- Nginx七层负载均衡: 对Http协议/mail协议做负载均衡，转发，性能强劲
- Haproxy: 四层/七层的负载转发功能，灵活性高
- apache: 灵活性不高，性能不如nginx高，并发达到百万级别性能会越来越差;
对比
七层: (售票处: 可以根据用户需求处理； 售票处需要提供一些 "身份信息")
- 适用与web服务器(Tomcat、Apache)
- 七层会处理请求，Nginx可以处理(压缩,缓存) js\css等这些内容
四层: (黄牛，只会把票卖你)
- 适用处理基于TCP/UDP转发请求
- 四层主要是转发请求，不会进行处理
总结
四层做负载一般会使用LVS，Nginx更适合做七层负载。七层一般用于处理http协议的，适用于web服务器；四层负载均衡主要适用于处理基于tcp、udp协议，重点是用于转发请求，并不是处理请求，七层是会处理请求的，比如它可以去处理静态资源的一些内容，可以进行压缩或者缓存
DNS地域负载均衡
由DNS服务器来识别，根据IP地址采用就近原则访问最近的服务器
负载均衡算法策略
轮询
负载均衡中最简单的；
也是默认的一种机制；
Nginx不会去管服务器的硬件性质，只会将请求平均的分配到每一台集群服务器上;
1、修改三台tomcat里面的index.jsp
/usr/local/tomcat-fronted/webapps/ROOT
vim index.jsp
在body标签中加入
<h1>hello tomcat1</h1>
2、页面多次请求www.tomcats.com来观察，显示结果会轮询到三台tomcat上面。
优点
工作量平均分配
适用于服务器性能配置一致的环境中
最基础的负载均衡策略
加权轮询
weight 值越大，权重越高;根据服务器的硬件配置，分配不同比例请求;
不配置的时候，所有默认都是1
数值越大，被分配的权重比例越大，请求被分配的会更多
upstream tomcats {
server 192.168.1.171:8080 weight=1; #通过weight配置权重
server 192.168.1.172:8080 weight=3;
server 192.168.1.173:8080 weight=2;
}
ip_hash
nginx的ip_hash算法只会使用ip的前三位进行hash
- 设置
upstream tomcats {
ip_hash;
server 192.168.1.173:8080;
server 192.168.1.174:8080 down;
server 192.168.1.175:8080;
}
1. 作用: 是同一个用户(状态不更改的情况下: 例如ip)，的所有请求会落到一台服务器上；
2. 目的: 提高用户请求性能，提高程序吞吐性；
3. 原理: (和HashMap类似)
将用户的ip，通过hash算法得到的值 去 % 当前能够使用的服务器数量得到一个下标值；
然后该下标值就决定用户请求落到哪一台服务器上；
4. 使用方法: upstream 中 配置 ip_hash;
5. 缺陷: 当使用ip_hash ，
1. 如果有一台用户机向服务器发送大量请求, 这台用户机的请求全部落到某一台服务器上，可能会导致这台服务器宕机；
2. 如果用户ip改变，用户的会话和服务器的缓存都会失效；
备注: 当使用 ip_hash, 需要停掉某一台服务器，不能直接删除，应该使用 down; 因为删除一台服务器，会重新计算hash算法, 会导致算法\会话\服务器缓存等等都会失效，
参考：http://nginx.org/en/docs/http/ngx_http_upstream_module.html#ip_hash
一致性hash算法
会访问到特定节点，就近原则
- hash算法带来的问题
- 问题: 当有服务宕机，或者新增某台服务器，会出现的问题；
- 造成原因: hash算法会重新进行计算，同时用户在这台服务器中的缓存也可能失效(所以实际上不会使用nginx的ip_hash来处理分布式会话的问题)；请求可能会集中到某一台机器。导致某台服务请求量剧增，其他机器可能空闲。
- 导致后果: 这样会导致，用户请求会比原来更慢了；
根据服务器的ip或者主机名进行hash，使服务器分布在0~2^32-1的圆环上，采用顺时针就近原则，用户会落到hash算法值后最近的节点；(要深入的理解，这个地方还是有问题，如果机器少的话，还是会有大量请求根据顺时针的就近原则请求到某一台机器，这个地方要有虚拟节点来使我们的服务能均匀的分布在这个圆环上才可以 )
当有服务器宕机(减少)或增加后，
其余大部分的用户不会有变动，而离宕机服务器或者新增服务器 节点 (hash算法值)更接近的用户才会有影响(这样保证了大部分用户请求服务器节点的稳定性,相对于ip_hash有一定的优化)
url_hash
根据url 进行哈希计算取模算出下标指向对应服务器处理，url后面带还是不带/，负载均衡到的服务器不一样；
和ip_hash类似
扩展: 假设在某一个业务(相对于某一url来说)，这个业务方法的并发量特别大；就可以将这台服务器的tomcat替换成 nginx，在做一个基于 该ul的集群就可以了
upstream tomcats {
# url hash
hash $request_uri;
# 最少连接数
# least_conn
server 192.168.1.173:8080;
server 192.168.1.174:8080;
server 192.168.1.175:8080;
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats;
}
}
least_conn
根据服务器的连接数来判断；
会请求到，当前所持连接数最少的一台服务器上
配置nginx反向代理/负载均衡
配置反向代理：配置一个server虚拟主机(server 块) 用来监听端口，用来接收http请求，location 配置为 proxy_pass(代理通过) 用来表示请求转发到上游服务器
upstream tomcats （upstream 块）上游服务器信息，内部包含{ sever 服务器ip对应端口} ，如果是多台会自动实现负载均衡。
proxy_pass http:// tomcats;
1、配置上游服务器
upstream tomcats {
server ip:端口；
server ip:端口；
server ip:端口；
}
server{
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats;
}
}
upstream的指令参数
weight
加权权重
max_conns
max_conns配置上游单台server服务器的最大连接数 默认值0，表示无限制，每个工作进程都能生效，保护避免过载，可以起到限流作用。（老版本要商业版才能使用）
# worker进程设置1个，便于测试观察成功的连接数
worker_processes 1;
upstream tomcats {
server 192.168.1.173:8080 max_conns=2;
server 192.168.1.174:8080 max_conns=2;
server 192.168.1.175:8080 max_conns=2;
}
示例
max_conn最大连接数,两个请求处理完才会处理之后的请求,保证一定的成功处理连续性
slow_start
一定时间后才增加权重（和weight一起使用）
代表缓慢的加入到集群中,当期望服务器加入到集群中不直接接受大量请求时使用
配合权重(weight)使用才有效,默认值为0秒,在配置的时间内,会把权重从0到配置的值进行递增
优点：
可以用来观察流量从少到多的一个过程
缺点：
- 负载均衡策略必须是均衡策略，是hash和random时无效
- 单个服务器无效，必须是集群(如果在upstream中只有一台server,则该参数失效)
- 旧的版本，必须是商业版本才有效，新版本可以使用
upstream tomcats {
server 192.168.1.173:8080 weight=6 slow_start=60s;
# server 192.168.1.190:8080;
server 192.168.1.174:8080 weight=2;
server 192.168.1.175:8080 weight=2;
}
down
标识某台服务器为不可用状态
upstream tomcats {
server 192.168.1.173:8080 down;
# server 192.168.1.190:8080;
server 192.168.1.174:8080 weight=1;
server 192.168.1.175:8080 weight=1;
}
backup
backup表示当前服务器节点是备用机，只有在其他的服务器都宕机以后，自己才会加入到集群中，被用户访问到：
backup参数不能使用在hash和random load balancing中。
upstream tomcats {
server 192.168.1.173:8080 backup;
# server 192.168.1.190:8080;
server 192.168.1.174:8080 weight=1;
server 192.168.1.175:8080 weight=1;
}
max_fails
达到最大的失败次数，剔除服务节点
fail_timeout
失败的时间段 ，多少时间后再次恢复、
最大失败超时时间，与上一个配合使用
在规定时间内允许最大失败次数，超过后会被认为宕机，nginx会停止将请求发送给该服务器，在fail_timeout时间后，再次尝试请求该服务器，如果还是失败，则重复动作直到重新运作为止
例如max_fails=2 fail_timeout=15s
表示在15秒内请求某一server失败达到2次后，则认为该server已经宕机了，随后再过15秒，这15秒内不会有新的请求到达刚刚挂掉的节点上，而是会请求到正常运作的server，15秒后会再有新请求尝试连接挂掉的server，如果还是失败，重复上一过程，直到恢复。
如何测试
可以jmeter测试前关闭tomcat1，测试时打开，观察最后请求是否有落在tomcat1上
错误码——502
服务器拒绝请求
http://nginx.org/en/docs/stream/ngx_stream_upstream_module.html
keepalive
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive
提高吞吐量
通过创建长连接，避免创建关闭http连接的损耗
keepalive 的作用是把所有连接中的一部分连接作为长连接，长连接大大减小了连接的创建、维护、关闭的损耗（有创建和关闭肯定是有网络的损耗的）
upstream tomcats {
# server 192.168.1.173:8080 max_fails=2 fail_timeout=1s;
server 192.168.1.190:8080;
# server 192.168.1.174:8080 weight=1;
# server 192.168.1.175:8080 weight=1;
keepalive 32;# 配置长连接数量
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats;
proxy_http_version 1.1; #设置长连接http版本为1.1，默认是1.0，1.0不支持长连接
proxy_set_header Connection ""; # 清空请求头信息，提高解析请求效率
}
}
proxy_set_header 代理头部信息
server {
listen 80;
server_name www.tomcats.com;
location /aa/bb/ {
proxy_set_header Cookie $http_cookie;
proxy_pass http://1.1.1.1/aa/bb/;
}
}
缓存
如上图，用户请求的时候会分为两个地方的缓存。只能缓存静态资源。
浏览器缓存
浏览器里面的缓存会加速单个用户的访问,
- 加速用户访问，提升单个用户（浏览器访问者）体验，缓存在本地
指令参数
对于浏览器的缓存，可以使用expires指令做一定的控制，主要是针对一些静态资源文件缓存，比如 html、css、js、图片等。
expires [time]
location / {
...
expires 10s;
}
然后请求的响应头部会多出属性
Cache-Control: max-age=10;# 相对过期时间。
可以发现 Exipires(过期时间) 的值 Date（当前时间） 的值恰好只差 10s
修改location 映射的资源之后，由于 修改时间 （响应头中的 Last_Modified）发生了更改，当再次请求时，就不会再使用缓存
expire @[time]指令可以指定一个以天为节点的过期时，绝对时间
location / {
...
expires @22h30m; #当天晚上10点30分
}
刷新浏览器之后，可以看到 Date 和 Expires 的时间差 等于 Cache-Control 中的 max-age
expires [time]
缓存多长时间到期
expire @[time]
以天为单位缓存
expires -[time] 表示负对应单位时间，标识在当前时间点之前的time时缓存已经过去，响应头中的 Cache-Control属性 是 no-cache
表示缓存提前过期；相当于手动清除缓存
expires epoch
表示 nocache，不设置 缓存（Response Headers中的expires的值是1970那个起始时间），响应头中的 Cache-Control属性 是 no-cache
expires off
expires 的默认设置，关闭状态，关闭并不代表没有 expires ，浏览器有默认的缓存机制，只不过是在Nginx 里面没有配置关于缓存（expires， Cache-Control）的内容，在响应头里面是看不到对应缓存两个字段。
expires max
设置缓存永不过期。Expires 会在 2037年过期。
状态: 304表示缓存(服务端文件时间没有变化，则去缓存，（浏览器是会观察文件的最后修改时间）);200表示重新拉取整个文件;
文件被修改，浏览器会重新请求加载页面；没有修改（通过修改时间判断）再去看expires参数设置缓存时间
Nginx缓存
nginx端的缓存会优化内网的传输 （nginx请求上游服务器的资源会有内网带宽的损耗 ，需要有一个请求和响应的时间。如果上游服务器的内容(静态文件)会被缓存到 nginx 端的话，内网的损耗就没那么大了，响应的也会减小用户整个请求的响应时间。 ）
- 缓存在nginx端，提升所有访问到nginx这一端的用户
- 提升访问上游（upstream）服务器的速度
- 用户访问仍然会产生请求流量
反向代理缓存
上游服务器静态文件缓存的设置
上面expire 确定的是浏览器中的缓存
nginx中也是可以进行静态资源缓存的，缓存目录不用创建，规定好路径后，nginx会直接创建
upstream tomcats {
}
# proxy_cache_path 设置缓存保存的目录, 会自动创建
# keys_zone=mycache:5 缓存可以使用的共享空间（名字，开辟出来的大小），设置共享内存以及占用的空间大小
# max_size 设置缓存大小
# inactive 超过此时间，则缓存自动清理
# use_temp_path 关闭临时目录，有可能造成性能影响
proxy_cache_path /usr/local/nginx/upstream_cache keys_zone=mycache:5 max_size=200g inactive=1m use_temp_path=off;
server {
listen 80;
server_name www.tomcats.com;
# 开启并使用缓存，和keys_zone一致
proxy_cache mycache;
# 针对200和304的状态码设置缓存过期时间
proxy_cache_valid 200 304 8h;
location / {
proxy_pass http://tomcats;
#proxy_cache mycache; 应该是写在上面下面都可以
#proxy_cache_valid 200 304 8h;
}
}
nginx配置ssl证书
记得测试是否重新安装会覆盖之前的nginx配置（比如ssl忘记装了，configure&make重新安装可以覆盖）
搜索ssl是否有
腾讯的帮助文档有
监听端口443
HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过
1、传输加密
2、身份认证
保证了传输过程的安全性 。
主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护。
安装SSL模块
要在nginx中配置https，就必须安装ssl模块，也就是: http_ssl_module。
进入到nginx的解压目录： /home/software/nginx-1.16.1
新增ssl模块(原来的那些模块需要保留)
./configure \
--prefix=/usr/local/nginx \
--pid-path=/var/run/nginx/nginx.pid \
--lock-path=/var/lock/nginx.lock \
--error-log-path=/var/log/nginx/error.log \
--http-log-path=/var/log/nginx/access.log \
--with-http_gzip_static_module \
--http-client-body-temp-path=/var/temp/nginx/client \
--http-proxy-temp-path=/var/temp/nginx/proxy \
--http-fastcgi-temp-path=/var/temp/nginx/fastcgi \
--http-uwsgi-temp-path=/var/temp/nginx/uwsgi \
--http-scgi-temp-path=/var/temp/nginx/scgi \
--with-http_ssl_module
- 编译和安装
make
make install
- 把ssl证书 *.crt 和 私钥 *.key 拷贝到/usr/local/nginx/conf目录中。
- 新增 server 监听 443 端口：
server {
listen 443;
server_name www.imoocdsp.com;
# 开启ssl
ssl on;
# 配置ssl证书
ssl_certificate 1_www.imoocdsp.com_bundle.crt;
# 配置证书秘钥
ssl_certificate_key 2_www.imoocdsp.com.key;
# ssl会话cache
ssl_session_cache shared:SSL:1m;
# ssl会话超时时间
ssl_session_timeout 5m;
# 配置加密套件，写法遵循 openssl 标准
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://tomcats/;
index index.html index.htm;
}
}
- reload nginx
./nginx -s reload
腾讯云Nginx配置https文档地址：https://cloud.tencent.com/document/product/400/35244
动静分离
以前静态资源渲染交由服务器渲染，动静分离后可以交由浏览器客户端渲染，减少服务器压力；由于动静分离，前后端也需要分开开发，解耦;
为多个跨平台的应用提供统一的对接服务，ios、安卓app，有一个接口就可以为所有前端提供服务；
动静分离本质就是分布式，将静态资源分离出来，静态资源是由缓存的，加快了用户的访问速度。
静态数据：css/js/images/audio/videos/..（不会变）
动态数据：得到的响应可能会和上一次不同
cdn静态分离
cdn对静态资源加速，提高用户访问速度；减少带宽损耗，减少服务器负载（例如大视频/图片加载比较耗时），需要注意cdn静态资源加速一般都交由云服务商提供，不会放在企业内部服务器(nginx)
Nginx
两种方式:
- 将静态资源缓存到nginx中;
- 在Nginx下方在部署一个Nginx upstream集群
- 通过一级域名和二级域名来区分访问静态资源还是动态资源;
使用动静分离策略所带来的问题:
- 跨域;(SpringBoot Cros、Nginx、jsonp)'
- 分布式会话;(分布式缓存中间件Redis);
DNS解析
TCP/IP通信都是基于IP的
DNS是将域名解析成IP地址的工具；DNS解析是由DNS服务器完成的，解析成Nginx的公网ip
NGINX可以对内网的Tomcat起到一个网关的作用，有一定的保护措施。
Tomcat应用服务器是部署在内网的，对外不开放，需要nginx反向代理
工具管理修改本地hosts
switchhosts可以管理DNS域名解析
osi网络模型
https://class.imooc.com/lesson/1227#mid=28755
jmeter并发数测试
jmeter调整页面字体大小，别的方法都没用，直接选项 ->放大 即可
判断服务器并发上限
jmeter工具可以用来进行压力测试，测试系统的并发量，windows上启动jmter，双击jmeter.bat
通过异常率来确定系统的并发量，比如异常率的临界值是20%，那么通过不断的增加用户数，当异常率达到20%时，就认为系统的并发量是当前用户数
补充
nginx到这承担了负载均衡、反向代理、网关、动静分离的作用
现阶段架构部署
登陆不了问题
原因：前端根据cookie来判断是否登录，登录后无法写入cookie而导致无法登录，由于后端使用nginx代理upstream集群，那么通过头部设置set-cookie会使用upstream的代理名作为域名，不在一个域则无法写入因为跨域了
解决方式1：将upstream的上游名改为和访问域名相同
解决方式2：proxy_cookie_domain tomcats imooc.com; 将代理名替换为访问的域名的域
(nginx反向代理，upstream取别名时 ，最好设置为域名，否则容易出现cookie获取不到的情况)
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· AI与.NET技术实操系列（二）：开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识（上）
· 浏览器原生「磁吸」效果！Anchor Positioning 锚点定位神器解析
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布：重大改进与新特性概览！
· AI与.NET技术实操系列（二）：开始使用ML.NET
· 单线程的Redis速度为什么快？