设为首页 收藏本站
查看: 1591|回复: 0

[经验分享] 对Nginx的理解 --相对于Apache

[复制链接]

尚未签到

发表于 2018-11-12 11:03:57 | 显示全部楼层 |阅读模式
  对Nginx的理解
  - -相对于Apache
  概要:nginx的源码安装,参数配置,make,nginx与Apache的区别,四层均衡负载均衡,七层负载均衡。线程与进程
  首先,我们还是通过实验对Nginx的配置进行剖析,了解Nginx都可以实现什么功能。
  第一部分:实验
  ##获得nginx包,并解压:
DSC0000.jpg

  README文件是自述文件。也就是服务该如何配置的文件,相当于使用指南:
DSC0001.jpg

DSC0002.jpg

  他说要到网上查看如何安装和配置:
  首先指导我们进行源代码安装:
DSC0003.jpg

  解压后文件是6.2M:
DSC0004.jpg

  用帮助查看怎么用源代码安装:
DSC0005.jpg

  帮助里会告诉我们怎么安装我们需要的服务,比如ssl,和http
DSC0006.jpg

  还可以指定nginx的用户和组:
DSC0007.jpg

  还有安装路径的前缀:
DSC0008.jpg

  然后就可以开始安装:
DSC0009.jpg

  安装完成后会显示需要依赖软件,所以,我们要安装依赖软件,并且结尾应该是devel:
DSC00010.jpg

  再安装,再查看依赖性,解决依赖:
DSC00011.jpg

  直到解决所有依赖性,然后就完成了第一步,接下来是
  Make  make install
  当然 这三步也可以一次完成:
DSC00012.jpg

  在第一步完成后会生成makefiel文件,指导make的运行:
DSC00013.jpg

DSC00014.jpg

DSC00015.jpg

  我们现在安装的nginx是5.5M,是因为debug(排除程序故障,是及其重要的编译操作)的原因。
DSC00016.jpg

  开启nginx,查看端口:
DSC00017.jpg

  用命令和浏览器可以查看现在nginx开启:
DSC00018.jpg

DSC00019.jpg

  关闭并且删除nginx:
DSC00020.jpg

DSC00021.jpg

  Make  clean  相当于删除makefiel然后把解压包也删了,从头开始做,
DSC00022.jpg

  解压,进入解压包:
DSC00023.jpg

  之前我们做的安装完成后,会有nginx的版本号,这样很不安全,下面是在安装时去除版本号:
DSC00024.jpg

DSC00025.jpg

DSC00026.jpg

  在下面的文件中编辑GCC,在安装过程中不进行Debug,这样nginx将会很小。
DSC00027.jpg

DSC00028.jpg

DSC00029.jpg

  然后就是源码安装:
DSC00030.jpg

DSC00031.jpg

  进入安装位置,查看端口:
DSC00032.jpg

  检查,可以访问,并且包很小:
DSC00033.jpg

  安装好之后,我们必须在nginx下的sbin下执行./nginx才能开启nginx,为了不麻烦,我们可以将要执行的目录链接到环境变量下,这样就可以在任何位置执行并开启nginx了
DSC00034.jpg

  当你再查询nginx的位置时显示的是链接的位置:
DSC00035.jpg

  这样我们就可以在任何位置进行nginx的开启,关闭看,重新加载。
  下面来配置nginx的动态模块,这样在你安装nginx的时候,如果是动态模块,那么你就可以在需要的时候打开,不需要的时候关闭。然而它支持的动态模块有限,这里我们以mail为例,相对于这一点,Apache的配置文件中是已经内置了动态模块:
DSC00036.jpg

DSC00037.jpg

DSC00038.jpg

  一个安装包可以安装多次但每次都必须make clean,目的是刷新删除makefile这个文件(这个文件是每次在第一步后在安装包中生成的,用来指导make,而不是在安装位置)
DSC00039.jpg

  Nginx  --help可以查看怎么设置安装:
DSC00040.jpg

  动态模块是在静态模块后面加上dynamic:
  这里我们安装两个动态库,并解决依赖性:
DSC00041.jpg

  Make  && make install
  这样在安装的目录下就会有modules的目录,并且在modules中有刚刚我们增加的动态模块,当我们需要启动服务时,就可以在nginx的主配置文件中加入:
DSC00042.jpg

DSC00043.jpg

  并且只能增加在第一行,否则 ./nginx  -t 会有语法错误。
DSC00044.jpg

  这样检测语法,重新加载就可以使用mail服务了。
  ##修改nginx的用户:
  默认是nobody
DSC00045.jpg

  在配置文件第一行修改:
  ###限制用户访问资源数:
  如果不限制用户访问资源数,会把内存消耗完,这样系统就会崩溃。
  把内存资源消耗完的命令:
DSC00046.jpg

  意思是一个请求接着一个请求。
  Ulimit:限制用户的最大进程数,
  Ulimit  -a显示当前的所有用户的进程限制。
DSC00047.jpg

  现在一个进程打开的文件个数是默认的1024个。
  我们新增一个用户,查看他的进程限制,还是 默认一个进程可以打开1024个文件。
  ##wxh可以打开最大的进程相互为100,当然,我们也可以设置最大的文件数:
DSC00048.jpg

DSC00049.jpg

  查看:
DSC00050.jpg

  再用shell炸弹去测,发现他是一个循环,最多占用100个进程,然后就退出,然后再进行炸弹。
  ##统计访问次数:
DSC00051.jpg

DSC00052.png DSC00053.png DSC00054.jpg

DSC00055.jpg

DSC00056.jpg

  ##手写网页跳转:
DSC00057.jpg

DSC00058.jpg

  生成证书:
DSC00059.jpg

DSC00060.jpg

DSC00061.jpg

DSC00062.jpg

DSC00063.jpg

DSC00064.jpg

  ###网页重定向:
  修改发布目录
DSC00065.png

DSC00066.png DSC00067.jpg DSC00068.jpg

  在主机上增加解析:
DSC00069.jpg

  有时会不停闪烁,加上就行了
DSC00070.jpg

  ###网页重写
DSC00071.png

DSC00072.png DSC00073.jpg DSC00074.jpg

  还要把之前做的重定向注释掉:
DSC00075.jpg DSC00076.jpg

  ###虚拟主机
DSC00077.jpg

DSC00078.jpg

DSC00079.jpg

DSC00080.jpg

  ##负载均衡:
  对westos.org做负载均衡
  在server3中开启http,将昨天vanish做的虚拟主机删除,修改发布目录:
DSC00081.jpg

  Server2也要修改发布目录:
DSC00082.jpg

  重启两个http,检测发布目录没错:
DSC00083.jpg

DSC00084.jpg

  这是在虚拟主机的基础上加了负载均衡,两者不牵扯:
DSC00085.jpg

DSC00086.jpg

DSC00087.jpg

DSC00088.jpg

  检测:
DSC00089.jpg

DSC00090.jpg

  负载均衡可以加权重:
DSC00091.jpg

  加完权重后的效果:
DSC00092.jpg

  Backup表示此台主机并不是负载均衡主机,而是当所有其他主机都挂掉后,显示这台主机的发布目录,我们可以在这一页写上“系统正在维护”等
  Nginx的发布目录是在nginx下的html下的index.html:
DSC00093.jpg

  还可以使用IP hash 和将某一台负载均衡器关了。
DSC00094.jpg

DSC00095.jpg

  增加sticky模块,把之前做的nginx删了,重新安装:
DSC00096.jpg

DSC00097.jpg

DSC00098.jpg

DSC00099.jpg

  这样就增加了一个sticky模块。
  第二部分:相关知识的补充
  ##GUN的相关知识:
  GUN计划,又叫做革奴计划,目标是创建一套完全自由的操作系统,为保证GUN软件可以自由的使用,复制修改传播,就有了GUN通用公共许可证。
  GUN计划首先完成的是开发出了许多软件包,包括强大的文字编辑器emacs,GCC(GUN编译器集合,是一套由GUN开发的编程语言编译器),以及大部分UNIX系统的程序库和工具。唯一没有完成的就是操作系统与内核。
  然后李纳斯托沃兹开发出来linux操作系统内核,并与其它GUN软件结合,尽管如此,GUN计划还是开发出自己内核。
  ##Make理解:
  在我们用源码安装nginx时只需三步就可以,这里就用到了GUN的make工具,我们在shell提示符下只需要输入make命令就可以完成自动编译,极大的提高了效率,这是因为有makefile文件,makefile文件指出了整个工程所有文件的编译顺序,编译规则(哪些文件先编译,哪些文件后编译哪些需要重新编译),makefile有自己的书写格式,关键字,函数。
  只有linux中才有makefile,window中IDE(集成开发环境)已经将makefile这个工作给做了。在UNIX下的软件编译,就需要自己写makefile。
  Makefile就像shell脚本一样,其中也可以执行操作系统的命令。
  关于程序的编译(compile)连接(link):
  编译时,编译器只检测程序的语法,和函数,变量是否被声明,如果函数未被声明,会警告,但是,仍然会生成object file(-o在window中是obj)而在连接程序时,连接器会在所有的object file中找寻函数的实现,如果找不到,就会报错。
  我们在命令行输入make,他会在当前目录下找makefiel文件或Makefile。
  下面是makefiel的详细讲解:
  http://sc.qq.com/fx/u?r=PPKILEA
  ##一线互联网公司所使用的web服务器:
  网易(163,com),新浪(sina),360用的就是nginx
  百度用的是Apache


  基本筛选引擎(BFE)是一种管理防火墙internet协议安全(IPsec)策略以及实施用户模式筛选的服务。停止或禁用BFE服务将大大降低系统的安全。
  腾讯用的是squid:

  淘宝用的是自己阿里的tengine
  ##Nginx的master和worker的浅析:
  Nginx开启后会在后台运行,包括一个master进程和多个worker进程。可以让他前台运行也可以关掉master进程,让其以单进程方式运行。
  Nginx有single和master两种进程模块,single模型是单进程的,容错能力差,不适合生产场景,生产场景用的master模型,即一个master进程加上N个worker进程。Master进程负责管理worker进程是master进程fork出来的,用来处理请求。
  Worker数最多只能和CPU 数相等,查看系统CPU个数用licpu.
  Nginx之所以快是因为master-worker模块和七层负载均衡。
  七层负载均衡是vanish和nginx常用的。
  ###DNS四层负载均衡与nginx七层负载均衡的异同:
  四层负载均衡是用户将数据包发到四层服务器,然后到后端服务器,后端服务器直接将数据包返回给用户,并且更改了IP数据包的地址,实现分流。四层均衡器只是起到一个转发的作用,以TCP为例,三次握手但是建立在client和server上的, 七层是后端机器要将数据包先返回给七层服务器,在返回给用户,这样效率会差一点。Client和七层服务器之间,七层服务器和server指间都会有三次握手,七层服务器相当于一个代理。
  当有***时,四层会直接发送给后端,而七层会过滤掉,这样七层就比较安全。
  七层可以实现对流量的统计,能够将访问不同内容(文字or图片)的包分发给不同的服务器。
  下面是对四层和七层的详细讲解:
  http://shikezhi.com/html/2016/nginx_0407/1099813.html
  ##同步阻塞与异步非阻塞:
  Apache 本身采用同步阻塞,也有异步非阻塞,但是与自身冲突,所以不常用。
  Nginx采用异步非阻塞:一个线程注册多个IO事件,IO事件准备完就处理,如果如果没有准备完,则阻塞一段时间,在这段是间内,如果准备问就直接处理。提升了CPU利用率和高并发的处理能力。
  总得来说就是:
  同步阻塞:是CPU处理一个进程完后才能进行下一请求。
  非阻塞:是开多个线程,但是这样会在内存占用和线程切换之间浪费开销。
  异步非阻塞:一个线程上注册多个IO,一完就处理,如果没完就阻塞一段时间,再处理。不是在线程之间切换而是在请求之间切换,就不存在线程之间切换的开销。
  在传统的同步阻塞IO模型下,七层服务器每次向后端服务器发送请求需要等待响应结果,这样CPU大部分时间都在等待IO完成,效率非常低。为了解决这个问题可以采用非阻塞的方式,七层服务器开多个工作线程,每个工作线程通过轮询的方式去检查IO事件是否完成,如果没有完成则让出CPU让其他工作线程处理。这种方式比同步阻塞的方式要好,但是只有在工作线程很多的情况下效率才比较高,而工作线程一多带来的内存开销以及线程切换的开销也非常大,阻碍了进一步提升并发处理能力。这时可以采用异步非阻塞IO模型,也就是说不再开很多个工作线程,而是由一个工作线程注册很多个IO事件,如果有IO事件准备完毕,则可以直接处理。如果没有准备完毕,则阻塞一个固定超时时间,在这个时间之内如果有多个IO事件都准备完毕了,则可以依次处理这些IO事件。从整体上来看节省了上下文切换的开销,提升了CPU的利用率,因此也提升了并发处理能力。这也是当前select/poll/epoll/kqueue这些机制的基本原理。
  在传统的同步阻塞IO模型下,七层服务器每次向后端服务器发送请求需要等待响应结果,这样CPU大部分时间都在等待IO完成,效率非常低。为了解决这个问题可以采用非阻塞的方式,七层服务器开多个工作线程,每个工作线程通过轮询的方式去检查IO事件是否完成,如果没有完成则让出CPU让其他工作线程处理。这种方式比同步阻塞的方式要好,但是只有在工作线程很多的情况下效率才比较高,而工作线程一多带来的内存开销以及线程切换的开销也非常大,阻碍了进一步提升并发处理能力。这时可以采用异步非阻塞IO模型,也就是说不再开很多个工作线程,而是由一个工作线程注册很多个IO事件,如果有IO事件准备完毕,则可以直接处理。如果没有准备完毕,则阻塞一个固定超时时间,在这个时间之内如果有多个IO事件都准备完毕了,则可以依次处理这些IO事件。从整体上来看节省了上下文切换的开销,提升了CPU的利用率,因此也提升了并发处理能力。这也是当前select/poll/epoll/kqueue这些机制的基本原理。
  Nginx与七层负载均衡参考:
  http://blog.csdn.net/xiaoao89757/article/details/450582
  21
  四七层代理区别:
  http://hi.baidu.com/aking_roc/item/3f62cb0f57b49736a3332a9e
  Nginx平台初探:
  http://tengine.taobao.org/book/chapter_02.html
  第三部分:原理讲解
  Nginx与Apache的区别:
  最大的区别是nginx占用资源少,可处理高并发,epoll的IO模型使nginx性能更高,是异步非阻塞处理请求,还是高度模块化的,配置简洁,静态性能好,本身就是就是一个反向代理器,七层负载均衡。
  而Apache能够更加稳定,少BUG模块超级多,select的IO模型使他吃力请求相对较慢,配置相对麻烦,处理动态好,rewrite功能强。
  最核心的区别在于apache是同步多进程模型,一个连接对应一个进程;nginx是异步的,多个连接(万级别)可以对应一个进程 。
  好的模型是前端nginx抗高并发,后端Apache是Apache集群。
  下面是两者区别的详细介绍:
  1、nginx相对于apache的优点:
  轻量级,同样起web 服务,比apache 占用更少的内存及资源.
  抗并发,nginx 处理请求是异步非阻塞的,而apache 则是阻塞型的,在高并发下nginx 能保持低资源低消耗高性能.
  高度模块化的设计,编写模块相对简单.
  社区活跃,各种高性能模块出品迅速啊.
  apache 相对于nginx 的优点:
  rewrite ,比nginx 的rewrite 强大.
  模块超多,基本想到的都可以找到.
  少bug ,nginx 的bug 相对较多.
  超稳定.
  存在就是理由,一般来说,需要性能的web 服务,用nginx 。如果不需要性能只求稳定,那就apache 吧。后者的各种功能模块实现得比前者,例如ssl 的模块就比前者好,可配置项多。这里要注意一点,epoll(freebsd 上是 kqueue )网络IO 模型是nginx 处理性能高的根本理由,但并不是所有的情况下都是epoll 大获全胜的,如果本身提供静态服务的就只有寥寥几个文件,apache 的select 模型或许比epoll 更高性能。当然,这只是根据网络IO 模型的原理作的一个假设,真正的应用还是需要实测了再说的。
  2、作为 Web 服务器:相比 Apache,Nginx 使用更少的资源,支持更多的并发连接,体现更高的效率,这点使 Nginx 尤其受到虚拟主机提供商的欢迎。在高连接并发的情况下,Nginx是Apache服务器不错的替代品: Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一. 能够支持高达 50,000 个并发连接数的响应, 感谢Nginx为我们选择了 epoll and kqueue 作为开发模型.
  Nginx作为负载均衡服务器: Nginx 既可以在内部直接支持 Rails 和 PHP 程序对外进行服务, 也可以支持作为 HTTP代理 服务器对外进行服务. Nginx采用C进行编写, 不论是系统资源开销还是CPU使用效率都比 Perlbal 要好很多.
  作为邮件代理服务器: Nginx 同时也是一个非常优秀的邮件代理服务器(最早开发这个产品的目的之一也是作为邮件代理服务器), Last.fm 描述了成功并且美妙的使用经验.
  Nginx 是一个安装非常的简单 , 配置文件非常简洁(还能够支持perl语法), Bugs 非常少的服务器: Nginx 启动特别容易, 并且几乎可以做到7*24不间断运行,即使运行数个月也不需要重新启动. 你还能够不间断服务的情况下进行软件版本的升级 .
  3、Nginx 配置简洁, Apache 复杂
  Nginx 静态处理性能比 Apache 高 3倍以上
  Apache 对 PHP 支持比较简单,Nginx 需要配合其他后端用
  Apache 的组件比 Nginx 多
  现在 Nginx 才是 Web 服务器的首选
  4、最核心的区别在于apache是同步多进程模型,一个连接对应一个进程;nginx是异步的,多个连接(万级别)可以对应一个进程
  5、nginx处理静态文件好,耗费内存少.但无疑apache仍然是目前的主流,有很多丰富的特性.所以还需要搭配着来.当然如果能确定nginx就适合需求,那么使用nginx会是更经济的方式.
  6、从个人过往的使用情况来看,nginx的负载能力比apache高很多。最新的服务器也改用nginx了。而且nginx改完配置能-t测试一下配置有没有问题,apache重启的时候发现配置出错了,会很崩溃,改的时候都会非常小心翼翼现在看有好多集群站,前端nginx抗并发,后端apache集群,配合的也不错。
  7、nginx处理动态请求是鸡肋,一般动态请求要apache去做,nginx只适合静态和反向。
  8、从我个人的经验来看,nginx是很不错的前端服务器,负载性能很好,在老奔上开nginx,用webbench模拟10000个静态文件请求毫不吃力。apache对php等语言的支持很好,此外apache有强大的支持网路,发展时间相对nginx更久,bug少但是apache有先天不支持多核心处理负载鸡肋的缺点,建议使用nginx做前端,後端用apache。大型网站建议用nginx自代的集群功能
  9、Nginx优于apache的主要两点:1.Nginx本身就是一个反向代理服务器 2.Nginx支持7层负载均衡;其他的当然,Nginx可能会比apache支持更高的并发,但是根据NetCraft的统计,2011年4月的统计数据,Apache依然占有62.71%,而Nginx是7.35%,因此总得来说,Aapche依然是大部分公司的首先,因为其成熟的技术和开发社区已经也是非常不错的性能。
  10、你对web server的需求决定你的选择。大部分情况下nginx都优于APACHE,比如说静态文件处理、PHP-CGI的支持、反向代理功能、前端Cache、维持连接等等。在Apache+PHP(prefork)模式下,如果PHP处理慢或者前端压力很大的情况下,很容易出现Apache进程数飙升,从而拒绝服务的现象。
  11、可以看一下nginx lua模块:https://github.com/chaoslaw...apache比nginx多的模块,可直接用lua实现apache是最流行的,why?大多数人懒得更新到nginx或者学新事物
  12、对于nginx,我喜欢它配置文件写的很简洁,正则配置让很多事情变得简单运行效率高,占用资源少,代理功能强大,很适合做前端响应服务器
  13、Apache在处理动态有优势,Nginx并发性比较好,CPU内存占用低,如果rewrite频繁,那还是Apache吧
  Ulimit的讲解:
  http://www.linuxidc.com/Linux/2012-10/72782.htm
  线程与进程的区别:
  链接:
  来源:luoweifu
  链接:blog.csdn.net/luoweifu/article/details/46595285


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.iyunv.com/thread-634072-1-1.html 上篇帖子: Nginx 学习笔记 下篇帖子: nginx模块开发入门
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表