推广 热搜:   公司  快速  企业  中国  设备    上海  行业  未来 

1.nginx-nginx和反向代理概念

   日期:2024-11-04     移动:http://dfvalve.xrbh.cn/mobile/quote/6877.html

代理(英语:Proxy),也称网络代理,是一种特殊的网络服务,允许一个网络终端(一般为客户端)通过这个服务与另一个网络终端(一般为服务器)进行非直接的连接。一些网关、路由器等网络设备具备网络代理功能。一般认为代理服务有利于保障网络终端的隐私或安全,防止攻击。

1.nginx-nginx和反向代理概念

提供代理服务的电脑系统或其它类型的网络终端称为代理服务器(英文:Proxy Server)。一个完整的代理请求过程为:客户端首先与代理服务器创建连接,接着根据代理服务器所使用的代理协议,请求对目标服务器创建连接、或者获得目标服务器的指定资源(如:文件)。

代理服务器英文全称是(Proxy Server),其功能就是代理网络用户去取得网络信息。形象的说:它是网络信息的中转站。代理服务器就好象一个大的Cache,这样就能显著提高浏览速度和效率。

在计算机网络中,反向代理是代理服务器的一种。服务器根据客户端的请求,从其关联的一组或多组后端服务器(如Web服务器,tomcat)上获取资源,然后再将这些资源返回给客户端,客户端只会得知反向代理的IP地址,而不知道在代理服务器后面的服务器簇的存在

与前向代理不同,前向代理作为客户端的代理,将从互联网上获取的资源返回给一个或多个的客户端,服务端(如Web服务器)只知道代理的IP地址而不知道客户端的IP地址;而反向代理是作为服务器端(如Web服务器)的代理使用,而不是客户端。客户端借由前向代理可以间接访问很多不同互联网服务器(簇)的资源,而反向代理是供很多客户端都通过它间接访问不同后端服务器上的资源,而不需要知道这些后端服务器的存在,而以为所有资源都来自于这个反向代理服务器。

Nginx (“engine x”) 是一个高性能的 HTTP反向代理 服务器,也是一个 IMAP/POP3/SMTP 代理服务器。

第一个公开版本0.1.0发布于2004年10月4日

其将源代码以类BSD许可证的形式发布,因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名

官方测试nginx能够支撑5万并发链接,并且cpu、内存等资源消耗却非常低,运行非常稳定

2011年6月1日,nginx 1.0.4发布。
apache httpd

Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,并在一个BSD-like 协议下发行。由俄罗斯的程序设计师Igor Sysoev所开发,

其特点是占有内存少,并发能力强,事实上nginx的并发能力确实在同类型的网页服务器中表现较好,中国大陆使用nginx网站用户有:新浪、网易、腾讯等。

功能:

  • web服务器
  • web reverse proxy
  • smtp reverse proxy
  • nginx相对于apache的优点:

    轻量级,同样起web 服务,比apache 占用更少的内存及资源

    抗并发,nginx 处理请求是异步非阻塞的,而apache 则是阻塞型的,在高并发下nginx 能保持低资源低消耗高性能

    高度模块化的设计,编写模块相对简单

    社区活跃,各种高性能模块出品迅速

    apache 相对于nginx 的优点:

    rewrite ,比nginx 的rewrite 强大

    模块超多,基本想到的都可以找到

    少bug ,nginx 的bug 相对较多

    Nginx 配置简洁, Apache 复杂

    最核心的区别在于apache是同步多进程模型,一个连接对应一个进程;nginx是异步的,多个连接(万级别)可以对应一个进程

    Tengine 是nginx的加强版,封装版,淘宝开源

    官网http://tengine.taobao.org/

    –动态模块加载(DSO)支持。加入一个模块不再需要重新编译整个Tengine;

    –支持SO_REUSEPORT选项,建连性能提升为官方nginx的三倍;

    –支持SPDY v3协议,自动检测同一端口的SPDY请求和HTTP请求;

    –流式上传到HTTP后端服务器或FastCGI服务器,大量减少机器的I/O压力;

    –更加强大的负载均衡能力,包括一致性hash模块、会话保持模块,还可以对后端的服务器进行主动健康检查,根据服务器状态自动上线下线,以及动态解析upstream中出现的域名;

    –输入过滤器机制支持。通过使用这种机制Web应用防火墙的编写更为方便;

    –支持设置proxy、memcached、fastcgi、scgi、uwsgi在后端失败时的重试次数

    –动态脚本语言Lua支持。扩展功能非常高效简单;

    –支持管道(pipe)和syslog(本地和远端)形式的日志以及日志抽样;

    –支持按指定关键字(域名,url等)收集Tengine运行状态;

    –组合多个CSS、Javascript文件的访问请求变成一个请求;

    –自动去除空白字符和注释从而减小页面的体积

    –…….

  • 依赖 gcc openssl-devel pcre-devel zlib-devel
  • 安装:yum install gcc openssl-devel pcre-devel zlib-devel
  • 创建用户和用户组。为了方便nginx运行而不影响linux安全
  • 创建组:groupadd -r nginx
  • 创建用户:useradd -r -g nginx -M nginx
  • -M 表示不创建用户的家目录。
  • https://www.cnblogs.com/chenxiaoge/p/configure

    –prefix=/usr/tengine-2.1

    make && make install

    第一步: https://www.cnblogs.com/chenxiaoge/p/configure –prefix=/opt/sxt/nginx 设置安装路径

    Error1:没有C语言编译器:yum install gcc

    Error2:没有PCRE:yum search pcre 用仓库搜索是否有对应的安装包

    yum install pcre-devel (自动匹配安装那个版本)

    Error3:没有openssl:yum install openssl-devel

    以上操作完成后再次执行安装操作(https://www.cnblogs.com/chenxiaoge/p/configure –prefix=/opt/sxt/nginx),安装成功后tengine-2.1.0中就自动生成Makefile文件。

    第二步,执行make命令,在源码的目录下。

    第三步,执行make install 命令

    安装完成后可以进入安装路径查看是是否存在可执行程序ngix

    启动web server: https://www.cnblogs.com/chenxiaoge/p/nginx

    浏览器访问对应IP,验证是否可以查看登录页面。端口号:80

    注意:此时应该将linux的防火墙关闭,否则无法在浏览器进行访问

    显示以下界面即安装成功

    在/etc/rc.d/init.d/目录中建立文本文件nginx

    在文件中粘贴下面的内容:

    修改nginx文件的执行权限

    chmod +x nginx

    添加该文件到系统服务中去

    chkconfig --add nginx

    查看是否添加成功

    chkconfig --list nginx

    启动,停止,重新装载
    service nginx start|stop|reload

    注意:修改路径,而且必须是在/etc/init.d、下面touch或者vi来新建

    虚拟主机是一种特殊的软硬件技术,它可以将网络上的每一台计算机分成多个虚拟主机,每个虚拟主机可以独立对外提供www服务,这样就可以实现一台主机对外提供多个web服务,每个虚拟主机之间是独立的,互不影响的

    通过nginx可以实现虚拟主机的配置,nginx支持三种类型的虚拟主机配置,

  • 基于ip的虚拟主机, (一块主机绑定多个ip地址)
  • 基于域名的虚拟主机(servername)
  • 基于端口的虚拟主机(listen如果不写ip端口模式)
  • 示例基于虚拟机ip的配置,这里需要配置多个ip

    nginx.conf下的配置

    nginx location匹配:用客户端的uri匹配location的uri

  • 先普通
  • 顺序无关
  • 最大前缀
  • 匹配规则简单
  • 打断:
    ^~
    完全匹配
  • 再正则
  • 不完全匹配
  • 正则特殊性:一条URI可以和多条location匹配上
  • 有顺序的
  • 先匹配,先应用,即时退出匹配
  • 语法

    因此,大类型可以分为三种:

    location = patt {} [精准匹配]

    location patt{} [普通匹配]

    location ~ patt{} [正则匹配]

    location [ = | ~ | ~* | ^~ ] uri { … }

    普通匹配

    注意:当普通 location 前面指定了“ ^~ ”,特别告诉 Nginx 本条普通 location 一旦匹配上,则不需要继续正则匹配;

    精准匹配

    正则匹配

    location ~ URI {}:
    location ~* URI {}:
    模式匹配URI,此处的URI可使用正则表达式,区分字符大小写,*不区分字符大小写;

    优先级:= 大于 ^~ 大于 | 大于 /|/dir/ *

    首先匹配 =,其次匹配^~, 其次是按文件中顺序的正则匹配,最后是交给 / 通用匹配。当有匹配成功时候,停止匹配,按当前匹配规则处理请求。

  • 先进行精准匹配,如果命中立即返回结果并结束解析的过程;
  • 精准匹配未命中判断普通匹配,如果命中多个会记录下"最长的"(最详细的URI)命中结果,但不会结束解析;
  • 继续判断正则匹配,按照正则匹配设置的规则正则表达式进行匹配,如果有多个正则匹配由上到下进行匹配,一旦匹配成功一个会立即返回结果并结束解析.
  • ps:普通匹配的前后顺序是无所谓的,因为记录的是最长(最精准)的结果,而正则匹配是按从上到下匹配的,这个需要注意

    注意

    location 的执行逻辑跟 location 的编辑顺序无关。

    矫正:这句话不全对,“普通 location ”的匹配规则是“最大前缀”,因此“普通 location ”的确与 location 编辑顺序无关;

    但是“正则 location ”的匹配规则是“顺序匹配,且只要匹配到第一个就停止后面的匹配”;

    “普通location ”与“正则 location ”之间的匹配顺序是?

    先匹配普通 location ,再“考虑”匹配正则 location 。

    注意这里的“考虑”是“可能”的意思,也就是说匹配完“普通 location ”后,有的时候需要继续匹配“正则 location ”,有的时候则不需要继续匹配“正则 location ”。两种情况下,不需要继续匹配正则 location :

    例子,有如下匹配规则:

    那么产生的效果如下:

    访问根目录/, 比如http://localhost/ 将匹配规则A

    访问 http://localhost/login 将匹配规则B,http://localhost/register 则匹配规则H

    访问 http://localhost/static/a.html 将匹配规则C

    访问 http://localhost/a.gif, http://localhost/b.jpg 将匹配规则D和规则E,但是规则D顺序优先,规则E不起作用,而 http://localhost/static/c.png 则优先匹配到 规则C

    访问 http://localhost/a.PNG 则匹配规则E, 而不会匹配规则D,因为规则E不区分大小写。

    访问 http://localhost/a.xhtml 不会匹配规则F和规则G,http://localhost/a.XHTML不会匹配规则G,因为不区分大小写。规则F,规则G属于排除法,符合匹配规则但是不会匹配到,所以想想看实际应用中哪里会用到。

    访问 http://localhost/category/id/1111 则最终匹配到规则H,因为以上规则都不匹配,这个时候应该是nginx转发请求给后端应用服务器,比如FastCGI(php),tomcat(jsp),nginx作为方向代理服务器存在。

    所以实际使用中,通常至少有三个匹配规则定义,如下:

  • host:决策server负责处理
  • uri:决策location
  • 反向代理:proxy_pass ip:port[uri];
  • 客户端请求:/ooxx/a.html

    Location的url:/ooxx/

  • proxy_pass的URI:http://node01
  • 将会被代理到http://node01/ooxx/a.html这个url
  • proxy_pass的URI:http://node01/
  • 将会被代理到http://node01/a.html
  • 1)没有时,location 可以匹配请求,也可以匹配等

    2)而有时,location 不能匹配请求,只能匹配这样的请求

    在nginx中配置proxy_pass时,当在后面的url加上了,相当于是绝对根路径,则nginx不会把location中匹配的路径部分代理走;

    如果没有,则会把匹配的路径部分也给代理走。

    如:客户端发出请求 ,location中的url为 ,location中匹配的路径为,且在proxy_pass的url后面加上了/(),则nginx不会把location中匹配的路径给代理走,最后代理走的路径为

    例子:
    下面四种情况分别用 http://192.168.1.4**/proxy/test.html** 进行访问。

    第一种(常用的配置)

    结论:会被代理到 http://127.0.0.1:81**/test.html** 这个url

    第二种(相对于第一种,最后少一个 )

    结论:会被代理到http://127.0.0.1:81**/proxy/test.html** 这个url

    第三种 (相对于第一种,转发到了 上)

    结论:会被代理到http://127.0.0.1:81**/ftlynx/test.html** 这个url。

    第四种(相对于第三种,转发到了 上 )

    本文地址:http://dfvalve.xrbh.cn/quote/6877.html    迅博思语资讯 http://dfvalve.xrbh.cn/ , 查看更多

    特别提示:本信息由相关企业自行提供,真实性未证实,仅供参考。请谨慎采用,风险自负。


    相关行业动态
    推荐行业动态
    点击排行
    网站首页  |  关于我们  |  联系方式  |  使用协议  |  版权隐私  |  网站地图  |  排名推广  |  广告服务  |  积分换礼  |  网站留言  |  RSS订阅  |  违规举报  |  粤ICP备2023022329号