技术

对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go细节 codereview mat使用 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 MVCC 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes自动扩容缩容 神经网络模型优化 直觉上理解机器学习 knative入门 如何学习机器学习 神经网络系列笔记 TIDB源码分析 《阿里巴巴云原生实践15讲》笔记 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 扩展Kubernetes 副本一致性 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全机制 jvm crash分析 Kubernetes监控 Kubernetes 控制器模型 Prometheus 学习 容器日志采集 容器狂占cpu怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes objects之编排对象 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 kubernetes实践 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 《深入剖析kubernetes》笔记 精简代码的利器——lombok 学习 编程语言的动态性 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 分布式计算系统的那些套路 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 mysql 批量操作优化 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS2——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 硬件对软件设计的影响 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记2 《mysql技术内幕》笔记1 log4j学习 为什么netty比较难懂? 回溯法 apollo client源码分析及看待面向对象设计 学习并发 docker 环境(主要运行java项目)常见问题 Scala的一些梗 OpenTSDB 入门 spring事务小结 事务一致性 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型 java exception Linux IO学习 network channel network byte buffer 测试环境docker化实践 netty(七)netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Macvlan Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker中涉及到的一些linux知识 hystrix学习 Linux网络源代码学习——整体介绍 zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty(六)netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 Redis概述 机器学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 异构数据库表在线同步 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM内存与执行 git spring rmi和thrift maven/ant/gradle使用 再看tcp 缓存系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 VPN(Virtual Private Network) Kubernetes存储 Kubernetes 其它特性 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 使用etcd + confd + nginx做动态负载均衡 如何通过fleet unit files 来构建灵活的服务 CoreOS 安装 CoreOS 使用 Go学习 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

标签


Nginx简单使用

2017年02月17日

简介

工作中常常用到Nginx 的location配置详解

Understanding Nginx Server and Location Block Selection AlgorithmsIn this guide, we will discuss some of the behind-the-scenes details that determine how Nginx processes client requests. Understanding these ideas can help take the guesswork(臆测、猜测) out of designing server and location blocks and can make the request handling seem less unpredictable.

Nginx logically divides the configurations (meant to serve different content) into blocks, which live in a hierarchical structure. nginx的内部结构是由核心部分和一系列的功能模块所组成。这样划分是为了使得每个模块的功能相对简单,便于开发,同时也便于对系统进行功能扩展。

The main blocks that we will be discussing are the server block and the location block.

  1. A server block is a subset of Nginx’s configuration that defines a virtual server used to handle requests of a defined type. Administrators often configure multiple server blocks and decide which block should handle which connection based on the requested domain name, port, and IP address. 通常一个server 配置对应一个域名
  2. A location block lives within a server block and is used to define how Nginx should handle requests for different resources and URIs for the parent server. The URI space can be subdivided in whatever way the administrator likes using these blocks. It is an extremely flexible model.

Alt text

比较重要的模块

  1. nginx core
  2. nginx事件模块。估摸着,类似netty
  3. nginx http内核模块

你观察nginx配置文件,也可以知道nginx的配置项是按照这个顺序组织的。

nginx配置

nginx 的默认配置文件位于/etc/nginx/nginx.conf。为了配置文件的可读性,很多项的配置可以单列一个配置文件,由nginx.conf来include这些文件。此处,我们将子配置文件放在/etc/nginx/conf.d目录下。

nginx http内核模块配置项

http{
	server{
		server_name www.domain1.com
		location /hello{
			proxy_pass http://ip:port/...
		}
		localtion /world{
		}
	}
	server{
		server_name www.domain2.com
		localtion{
			
		}
	}
}

用户在浏览器中键入http://www.domain1.com/hello

  1. 客户端将www.domain1.com解析成ip
  2. 访问ip:80www.domain1.com会作为host header设置在http请求中
  3. nginx 接到请求,根据Host header每个server的server_name进行匹配,选取server。
  4. 然后根据uri的剩余部分对localtion进行匹配

upstream负载均衡模块的配置项

http{
	server{
		server_name www.domain1.com
		location /hello{
			# 将server节点下的location节点中的proxy_pass配置为:http:// + upstream名称
			proxy_pass http://backend1
		}		
	}
	upstream backend1 {
       server 10.0.6.108:7080;
       server 10.0.0.85:8980;
	}
}

location 配置

nginx location 误区

Understanding Nginx Server and Location Block Selection AlgorithmsLocation blocks live within server blocks and are used to decide how to process the request URI (the part of the request that comes after the domain name or IP address/port). PS:终于明确的知道URI 说的啥了。

location optional_modifier location_match {

	. . .

}

The location_match in the above defines what Nginx should check the request URI against. The existence or nonexistence of the modifier in the above example affects the way that the Nginx attempts to match the location block.

Syntax: location [ = | ~ | ~* | ^~ ] uri { ... }

modifier修饰符 描述 优先级
前缀匹配  
= 精确匹配 如果找到,立即停止搜索
~ 正则匹配,区分大小写  
~* 正则匹配,不区分大小写  
^~ 前缀匹配,不是带了~就是正则匹配了 如果找到,立即停止搜索
/ 通用匹配,任何请求都会匹配到  

几个原则:

  1. It is important to understand that, by default, Nginx will serve regular expression matches in preference to prefix matches. However, it evaluates prefix locations first, allowing for the administer to override this tendency by specifying locations using the = and ^~ modifiers. nginx 正则匹配优先于前缀匹配,但nginx 先进行前缀匹配再进行正则匹配,这样你可以在前缀匹配上 加 ` = or ^~ 来改变nginx 的优先规则。PS:可以猜测下,nginx 最早没有 = or ^~ ,只有前缀和正则匹配,正则优先级高。后来想给前缀匹配加一点例外,就有了 = or ^~`
  2. 前缀匹配 是匹配了最长的才算,所以即便当前location_match 匹配了,也不会立即结束。但正则匹配是一匹配就结束,所以对正则匹配location 来说,先后位置很重要。PS:更重要的是要知道,你加一个nginx映射,是会影响已有的映射的,加正则映射是高危操作,一个正则越”常见“(匹配范围越大),越危险,吃过亏的

proxy_pass

proxy_pass 整体上是两种情况

  1. If proxy_pass is specified without a URI, the request URI is passed to the server(下面的127.0.0.1) in the same form as sent by a client when the original request is processed, or the full normalized request URI is passed when processing the changed URI:

     location /some/path/ {
         proxy_pass http://127.0.0.1;
     }
    

    proxy_pass 只指定了127.0.0.1 但没有指定 访问127.0.0.1:80的具体地址,此时呢,http://domain/$path 就会全部 对接到 http://127.0.0.1/$path

  2. If the proxy_pass directive is specified with a URI, then when a request is passed to the server, the part of a normalized request URI matching the location is replaced by a URI specified in the directive:

     location /name/ {
         proxy_pass http://127.0.0.1/remote/;
     }
    

    http://domain/name/$other 会被映射到 http://127.0.0.1/remote/$other。 此处要注意,http://127.0.0.1http://127.0.0.1/ 是不一样的,前者没有指定uri地址,后者则指定了 /

nginx 之 proxy_pass详解

假设用户请求为 http://192.168.1.1/proxy/test.html 那nginx 转发给服务器的路径是啥呢?

		location /proxy/ {
			proxy_pass http://127.0.0.1/;
		}
		
http://192.168.1.1/proxy/test.html
http://127.0.0.1/test.html
		location /proxy/ {
    		proxy_pass http://127.0.0.1;
		}
		
http://192.168.1.1/proxy/test.html
http://127.0.0.1/proxy/test.html
		location /proxy/ {
		    proxy_pass http://127.0.0.1/aaa/;
		}
		
http://192.168.1.1/proxy/test.html
http://127.0.0.1/aaa/test.html
		location /proxy/ {
		    proxy_pass http://127.0.0.1/aaa;
		}
		
http://192.168.1.1/proxy/test.html
http://127.0.0.1/aaatest.html

如何自定义一个nginx模块

模块如何和nginx交互

配置文件中,http,server,location 在ngx_conf_file.h中有定义,对应NGX_HTTP_MAIN_CONF, NGX_HTTP_SRV_CONF, NGX_HTTP_LOC_CONF, NGX_HTTP_UPS_CONF.在模块的回调函数中,会将这些配置解析为struct,并作为参数传给module。类似于j2ee servlet的init(ServletContext context)等方法。

模块里面的配置,如gzip on,gzip其实是一个命令(command),on是它的参数。下面的所有均是如此,命令即是由模块提供的!包括下面的listen,server_name等等。location /说明当服务器收到/的请求时,执行哪些命令而已。

毕竟插件的运行是基于nginx的,所以,很多基本功能函数,比如为一个结构体申请空间、打日志等都会ngx_xx方法与之对应,以确保大部分操作都在nginx的管理和规范之下。

接口

其实类似于java,nginx core预留好接口(一系列回调函数)交给自定义模块实现。比较重要的是以下三个结构体(包括数据和函数):

  1. ngx_command_s,也叫ngx_command_t
  2. 上下文struct,根据模块不同而不同,比如ngx_http_module_t
  3. 模块本身ngx_module_s,也叫ngx_module_t

以ngx_http_module_t为例,结构中的所有成员都是指向回调函数的函数指针,这些函数在HTTP类模块初始化过程的不同阶段调用。

  1. *preconfiguration指针指向的函数是在解析配置文件中的http块前调用,
  2. *postconfiguration指针指向的函数是在完成http块解析后调用,
  3. *create_main_conf指针指向的函数在初始化http块之前调用,
  4. *init_main_conf指针指向的函数在初始化http块时调用,
  5. *create_srv_conf指针指向的函数在初始化server块之前调用,
  6. *merge_srv_conf指针指向的函数实现合并server块和http块中相同指令的配置,
  7. *create_loc_conf指针指向的函数在初始化location块之前调用,
  8. *merge_loc_conf指针指向的函数实现合并location块和server块中相同指令的配置。

模块的执行时机

与j2ee fitler不同,对于请求的处理,不是每个模块提供一个filter(request),然后所有模块排好先后,依次执行。

默认情况下,struct NGX_HTTP_MAIN_CONF, NGX_HTTP_SRV_CONF, NGX_HTTP_LOC_CONF, NGX_HTTP_UPS_CONF便可以完成一次请求的处理,我们要做的,就是在一系列初始化回调方法中,更改上述结构体的相关数据,比如替换原有的方法,来实现对数据的特殊处理。

对于ngx_command_s,以hello world nginx 为例

location /helloworld{
    helloworld;
}
struct ngx_command_s {
    ngx_str_t             name;
    ngx_uint_t            type;
    char               *(*set)(ngx_conf_t *cf, ngx_command_t *cmd, void *conf);
    ngx_uint_t            conf;
    ngx_uint_t            offset;
    void                 *post;
};

nginx在解析配置文件时,会调用set函数(此处赋值为下文的ngx_http_helloworld_setup)。我们在set函数中,替换掉NGX_HTTP_LOC_CONF->handler,在ngx_http_helloworld_handler中,将返回的数据结构赋值为hello world。

char* ngx_http_helloworld_setup(ngx_conf_t *cf, ngx_command_t *cmd, void *conf){
    ngx_http_core_loc_conf_t *clcf;
 
    clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module);
    clcf->handler = ngx_http_helloworld_handler; /* handler to process the 'helloworld' directive */
 
    return NGX_CONF_OK;
}

小结

熟悉Nginx,为Nginx编写插件(一)中提到:”为某个东西写插件,还不如说是要更加深入地了解这个东西呢”,在了解了nginx的一些基本原理后,能够更好地操作nginx配置文件。

引用

Nginx开发从入门到精通

nginx自定义模块编写-实时统计模块

熟悉Nginx,为Nginx编写插件(一)