Nginx 学习笔记

nginx介绍

  • nginx是一个高性能的HTTP和反向代理web服务器

  • 静态资源服务器

  • 占有内存少,并发能力强,轻量级,高性能

操作nginx的命令

  • 启动nginx-windows test what is your name
start nginx.exe
  • 启动nginx-linux
sudo systemctl start nginx
  • 快速关闭nginx,可能不保存相关信息,并迅速终止web服务
nginx -s stop
  • 平稳关闭Nginx,保存相关信息,有安排的结束web服务。
nginx -s quit
  • 因改变了Nginx相关配置,需要重新加载配置而重载。
nginx -s reload
  • 重新打开日志文件。
nginx -s reopen
  • 为 Nginx 指定一个配置文件,来代替默认的。
nginx -c filename
  • 测试nginx的配置文件的语法是否通过,配置是否正确

  • 正确返回is OK和is successful

  • 错误返回test failed

nginx -t 

配置文件-nginx.conf

全局块

  • 从配置文件开始到events 块之间的内容,主要会设置一些影响nginx服务器整体运行的配置指令,主要包括配置运行 Nginx 服务器的用户(组)、允许生成的 worker process 数,进程 PID 存放路径、日志存放路径和类型以及配置文件的引入等。

events块

  • 主要影响 Nginx 服务器与用户的网络连接,常用的设置包括是否开启对多 work process 下的网络连接进行序列化,是否 允许同时接收多个网络连接,选取哪种事件驱动模型来处理连接请求,每个 work process 可以同时支持的最大连接数等

  • 这部分的配置对 Nginx 的性能影响较大,在实际中应该灵活配置

http块

  • http全局块

    • http全局块配置的指令包括文件引入、MIME-TYPE 定义、日志自定义、连接超时时间、单链接请求数上限等。
  • server块

    • server块定义一个虚拟主机的相关配置,一个物理主机可以配置多个虚拟主机。

    • location 块

      • 地址定向、数据缓存和应答控制

配置详解

全局块

  • user userName userGroup : Nginx用户及组:用户 组(window下不指定)
user nginx nginx
  • worker_processes Number | auto : 工作进程:数目。根据硬件调整,通常等于CPU数量或者2倍于CPU。
worker_processes  1;
worker_processes  auto;自动获取CPU核心数
  • error_log logFilePath [logLevel] : 日志:存储路径 日志级别,指定日志存储位置,可以根据日志级别设置不同的存储位置
error_log  logs/error.log;  存储路径写相对路径即可
error_log  logs/error.log  notice;
error_log  logs/error.log  info;
  • pid filePath : nginx进程的pid的存放路径(window系统不指定)
pid logs/nginx.pid;

events块

  • use epoll | kqueue :默认情况下,Nginx 会自动检测操作系统,并选择适合的事件驱动模型。Linux 系统建议选择 epoll;
use epoll;
  • worker_connections number :单个工作进程的最大连接数量,数量一般设置为2的n次方个
worker_connections 1024;
  • keepalive_timeout number :keepalive 超时时间。
keepalive_timeout 60;
  • client_header_buffer_size number :客户端请求头部的缓冲区大小

    • Nginx 在接收到客户端的请求时,需要将这些请求头信息存储在缓冲区中进行处理。

    • 如果请求头较大,如果设置过小的缓冲区大小,可能导致请求被截断或无法完全接收。但是,设置过大的缓冲区大小可能会浪费内存资源。

client_header_buffer_size number 4k;

http块

http全局块

  • include mime.types; 引入 mime.types文件

    • 在 Nginx 中,mime.types 文件是一个预定义的配置文件,其中包含了许多常见文件类型和对应的 MIME 类型。

    • 通过包含 mime.types 文件,Nginx 可以识别并正确设置响应头中的 Content-Type 字段,以确保客户端能够正确解析接收到的内容。这样可以避免客户端错误地将响应内容识别为其他类型,确保正确的渲染和处理。

    • 通常情况下,建议在 Nginx 的主配置文件中使用 include mime.types; 来引入默认的 MIME 类型配置。如果你有自定义的 MIME 类型需求,也可以在此处进行修改或扩展。

  • default_type application/octet-stream;

    • 当 Nginx 无法确定某个文件的确切 MIME 类型时,会使用默认的 MIME 类型来设置响应头中的 Content-Type 字段。

    • 默认为二进制方式处理文件

  • log_format formatName 'formatString'; 定义自己的日志格式

log_format main '$remote_addr - $remote_user [$time_local] "$request";
        $status $body_bytes_sent "$http_referer" ;
        "$http_user_agent" "$http_x_forwarded_for";
$remote_addr:客户端的 IP 地址。
$remote_user:客户端的用户名(如果设置了基本身份验证)。
$time_local:请求的时间和日期,以本地时间格式显示。
$request:完整的 HTTP 请求行,包括请求方法、请求路径和 HTTP 版本。
$status:HTTP 响应的状态码。
$body_bytes_sent:发送给客户端的响应体的字节数。
$http_referer:请求中的 Referer 头字段,表示当前请求的来源页面。
$http_user_agent:请求中的 User-Agent 头字段,表示发起请求的客户端应用程序或浏览器。
$http_x_forwarded_for:请求中的 X-Forwarded-For 头字段,表示客户端真实的 IP 地址(如果请求经过了代理服务器)。
  • access_log filePath formatName; 用了log_format指令设置了日志格式之后,需要用access_log指令指定日志文件的存放路径;
  • server_names_hash_bucket_size 128; : 参数用于指定服务器名称哈希表的桶大小。该哈希表用于匹配请求的主机头(Host Header)与 Nginx 配置中的服务器名称(Server Name)进行匹配。修改此参数可以影响到 Nginx 对请求的路由和处理。
  • sendfile on : 此指令启用了操作系统级的高效文件传输机制,用于加速文件的发送。通常建议将其设置为打开状态。
  • tcp_nopush on : 选项用于指定是否启用 TCP nopush 特性,用于优化网络数据传输。此选项仅在使用sendfile的时候使用
  • client_max_body_size 300m; : 设定通过nginx上传文件的大小
  • gzip on : Gzip 压缩是一种通过减小传输数据的大小来提高网页加载速度的技术。
    • 开启 Gzip 压缩后,当 Nginx 服务器向客户端发送响应时,会对响应内容进行压缩,并在传输过程中解压缩,从而减少传输数据的大小,提高传输速度。
    • 通过设置 gzip on;,你可以启用 Gzip 压缩功能。请注意,在启用 Gzip 压缩之前,确保服务器上已经安装了相应的 Gzip 压缩库。

upstream块

  • 配置一个上游服务器组

  • 例如,一个微服务系统部署了三个网关地址,此时请求发来以后就需要nginx来进行负载均衡,选择一个网关再转发请求。

  • 又或者是目标地址有多台服务,比如你需要将所有路径为/file/的代理到文件服务器,你的文件服务器又有多个,此时就需要配置一个上游服务器组,来将这些文件服务器地址列举出来,之后再配置一下负载均衡的规则,nginx就能根据规则来转发请求了。

  • 基础语法

    upstream 上游服务器组名称 {
    [负载规则]
    server IP:PORT | url;
    server IP:PORT | url;
    ...
    }
  • 后续使用时直接写: http://上游服务器组名称 即可。

  • 负载均衡策略

    • 轮询(默认)

      upstream gatewayserver{
         server 127.0.0.1:63010 ;
         server 127.0.0.1:63011 ;
         server 127.0.0.1:63012 ;
      }
    • 权重:根据权重分配请求

      upstream gatewayserver{
         server 127.0.0.1:63010 weight=2;
         server 127.0.0.1:63011 weight=3;
         server 127.0.0.1:63012 weight=5;
      }
    • 根据IP地址hash:相同的ip访问相同的服务

      upstream bakend {
         ip_hash;
         server 192.168.0.14:88;
         server 192.168.0.15:80;
      }
    • 根据url地址hash:按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。

      • 在upstream中加入hash语句,server语句中不能写入weight等其他的参数
      • hash_method是使用的hash算法
      upstream backend {
         server 192.168.0.14:3128;
         server 192.168.0.14:3128;
         hash $request_uri;
         hash_method crc32;
      }
    • 按后端服务器的响应时间来分配请求,响应时间短的优先分配。

      upstream bakend {
         fair;
         server 192.168.0.14:88;
         server 192.168.0.15:80;
      }
    • 其他写法:

      • down表示当前的server暂时不参与负载
      • backup 表示当前的server为备份server,只有在其他server都繁忙时才启用
      upstream bakend{
         server 127.0.0.1:9090 down;
         server 127.0.0.1:8080 weight=2;
         server 127.0.0.1:6060;
         server 127.0.0.1:7070 backup;
      }

server块

  • listen 80 : 设置监听的端口,请求这个端口的请求会被nginx根据规则进行响应处理

  • server_name domain domain1 ... 配置要监听的域名 | IP

    server_name  www.51xuecheng.cn localhost;

location块

负责配置反向代理,匹配哪些路径,代理到哪些路径,一个基本的location块长这样:

location /proxy/ {
    proxy_pass   http://test.yemao.com;
}

其中 /proxy/表示需要匹配的路径,proxy_pass表示需要代理到那个路径。

  • location的匹配规则一 :没有使用正则表达式,只是简单的使用类似 /xxx/abc/ ,...
此时,需要判断是否以“/”结尾
如:
location /abc/def(没有“/”结尾时)
    匹配:
    /abc/def-ghi
    /abc/def/ghi
如:
location /abc/def/(有“/”结尾时)
    匹配:
    /abc/def/xxx
    /abc/def/xxx/xxx
    不匹配:
    /abc/defghi
  • location的匹配规则二:正则表达式
~ 表示该路径使用正则表达式匹配
~* 固定搭配,表示该路径使用正则表达式匹配,并且设置大小写不敏感
^ 匹配开头,以^开头的表达式,表示目标字符必须从一头就要符合规则
$ 匹配结尾
\ 转义符号,例如,.本身表示匹配任意一个字符,现在如果要匹配.html结尾的路径,必须是 \.html 对.转义
. 匹配任意的一个字符
* 贪婪的,匹配0或多个
*? 非贪婪
  • 案例:

此处请尤其注意 匹配到的部分匹配剩余的部分,在后续结合proxy_pass构建最终访问地址时非常重要!

访问的url为:http://my.yemao.com/proxy/index.html

当location为 /proxy/ 时:
http://my.yemao.com/proxy/   index.html
即:可以正常匹配到/proxy/,匹配剩余的内容为  index.html

当location为 /proxy 时:
http://my.yemao.com/proxy  /index.html
即:可以正常匹配到/proxy,匹配剩余的内容为  /index.html

当location为 /pro/  时:
不匹配

当location为 /pro  时:
http://my.yemao.com/pro  xy/index.html
即:可以正常匹配到/pro ,匹配剩余的内容为 xy/index.html
  • proxy_pass配置规则

  • proxy_pass代理的地址是纯url:IP,IP:PORT,域名,且末尾没有/号时:

    将location匹配到的,以及匹配剩下的,都拼接到proxy_pass之后

    纯url,例如:
    proxy_pass http://192.168.1.2;
    proxy_pass http://192.168.1.3:8090;
    proxy_pass http://www.xuecheng.com;
    proxy_pass http://file.xuecheng.com;
    proxy_pass http://gatewayserver; //这是使用了upstream上游服务器组的写法
    • 匹配案例
    假设源url为  http://my.yemao.com/proxy/index.html
    location块为:
    location /proxy/ {
      proxy_pass   http://test.yemao.com;
    }
    匹配到的部分为 /proxy/  匹配剩余的部分为 index.html
    那么按照规则,得到最终的url为
    http://test.yemao.com/proxy/index.html
  • 其他情况,只要不是纯url,就属于其他情况。

    将location匹配剩下的url,直接拼接到proxy_pass之后

    其他情况如:
    proxy_pass http://192.168.1.2/;
    proxy_pass http://192.168.1.3:8090/test/;
    proxy_pass http://192.168.1.3:8090/test;
    proxy_pass http://www.xuecheng.com/demo;
    proxy_pass http://file.xuecheng.com/api/;
    proxy_pass http://gatewayserver/;
    • 匹配案例
    假设源url为 http://my.yemao.com/proxy/index.html
    location块为:
    location /proxy/ {
         proxy_pass   http://test.yemao.com/;
    }
    匹配到的部分为 /proxy/  匹配剩余的部分为 index.html
    那么按照规则,得到最终的url为:
    http://test.yemao.com/index.html
    
    location块为:
    location /proxy/ {
         proxy_pass   http://test.yemao.com/test/;
    }
    匹配到的部分为 /proxy/  匹配剩余的部分为 index.html
    那么按照规则,得到最终的url为:
    http://test.yemao.com/test/index.html
    
    location块为:
    location /proxy/ {
         proxy_pass   http://test.yemao.com/test;
    }
    匹配到的部分为 /proxy/  匹配剩余的部分为 index.html
    那么按照规则,得到最终的url为:
    http://test.yemao.com/testindex.html
    
    location块为:
    location /proxy {
         proxy_pass   http://test.yemao.com/;
    }
    匹配到的部分为 /proxy/  匹配剩余的部分为 index.html
    那么按照规则,得到最终的url为:
    http://test.yemao.com//index.html
    浏览器会自动忽略不正确的//符号,所以对最终结果访问不影响
  • 最终url的分析步骤

    1.查看location末尾的/是否存在,分析出匹配url和剩余url

    2.查看porxy_pass字段是否为纯url:

    纯url -> 拼接匹配url和剩余url

    不是纯url -> 只拼接剩余url

    3.根据拼接规则得到最终url

暂无评论

发送评论 编辑评论


				
上一篇
下一篇