You are here
马哥 23_01 _php相关概念及配置 有大用
MIME: .mp3 (其实是文本格式 要还原成mp3的)浏览器不能直接播放,
我们的浏览器有插件,或者我们的浏览器能够调用与之匹配的外部程序来对其进行解码的,
这使我们的浏览器处理文件的能力大大增加了,但是它有一个隐患 (如果对方发过来一个恶意代码,这段代码恰恰是主机上的某个程序可以执行的,结果很危险)
所以我们能够允许服务器发过来的仅仅是静态的网页
如果发给用户的是 C 语言编写的程序,客户端很显然无法识别,无法识别就不能直接去执行它,我们必须要调用一个外部程序来执行它,这样子就会安全很多.
动态网页 (html mp3音乐 jpg图 都不是动态 ) 在服务器端或客户端执行了一段脚本(程序),这个程序的执行结果根据不同用户 不同客户端 不同主机 不同的场景而不同 这种才叫动态网站 (动态网站就是能够根据用户请求做出对应响应,甚至对不同用户它返回的内容是不一样的,根据客户端的请求来返回不同的结果的)
客户端动态 服务器端开发的是一段程序,这段程序的源程序要下载到客户端本地,并且在客户端本地的运行环境中执行,并且将执行结果通过浏览器显示出来
服务器端动态 如果允许客户端随意执行脚本或程序的话,如果网站的制作者写了一段恶意代码或程序,用户就遭殃了,甚至于客户端机器被轻易的中上木马 因此一般来讲,我们不期望也不建议使用客户端动态 (早期windows上的一种技术 叫 ActiveX,这其实就是一种在客户端执行程序的一种机制,早期的 java 开发的Applet,这种程序也是在服务器端开发的,是用java语言所研发的小程序.这种小程序需要在java虚拟机上运行 (java也是一种类似于shell脚本的一样的程序,它的执行也需要一个解释器(不是解释器,可以理解为解释器,叫 JVM java虚拟机(Java Virtual Machine ))去执行)) (java虚拟机跟VMware虚拟机很接近,VMware只是虚拟硬件上的应用程序的,虚拟硬件的)(JVM就是虚拟java的运行boxes的,一个运行沙箱,一个运行盒子,这里面能够运行java的程序,它为什么能够提供这样一个沙箱呢?因为java程序的运行环境,它需要一个独特的运行时环境,需要装载java所需要的类,.所需要的库等等,它需要去管理整个java程序的生命周期,所以这是一个独特的专门设计用来运行java程序的一种虚拟化的环境,用这个虚拟化的环境还有一个好处:在服务端windows上的一个C程序,客户端是linux,通过浏览器,C到了客户端linux,未必能执行,所以说这种程序有个巨大的缺陷,它的移植是非常困难的,,,java程序把这种现状进行的改变 (一次编译,到处运行),java程序只能运行在java虚拟机上,其实它们底层的不同,java也是有环境依赖的,只不过它的环境依赖的不同之处,被虚拟机给隐藏起来了,)
java官方提供了各种平台不同版本的java虚拟机,虚拟机软件是紧紧跟底层系统和平台相结合的,但是java虚拟机软件向上提供的接口都是统一的
(Applet 能够让我们的 web程序语言 开发出来一段小程序,这段小程序能够直接放在我们的站点的目录当中,而后客户端可以直接访问这个小程序,把这个程序下载至本地,并在本地的java虚拟机上运行,所以这得有个要求,你得为你的浏览器安装java虚拟机插件,这样子这个程序下载至本地以后 就能够在这个虚拟机中运行了 我们说过在客户端运行程序,无论如何是不安全的,好在java的运行只能在java虚拟机中运行,想破坏的话,也只能破坏java虚拟机本身(这种限定其实都是理论上的), 正是Applet的出现,使得动态网站(java互联网开发)在当时流行一时,大约2000(2000 2001 2002)年左右,) (无论如何 Applet 还是要求我们的客户端要求配置有一个能够正常运行java虚拟机的环境才可以,所以这对客户端提出了比较高的要求 这是胖客户端时代,要求客户端要配置自己要能够具有完全使用它的环境,它才能够运行程序 对于众多入门级的用户来讲,显然是不能忍受的,打开一个网站访问不了,怎么都运行不成,虽然告诉我这网站很好看,但是我不知道怎么配置,不知道怎么去装java虚拟机插件,那用起来很困难,所以我们不能把 理性的假设建立在每一个终端用户身上,由此逐渐的仍然实现把所谓程序的运行机制给它返回至服务器端)
让服务器端执行程序的技术 叫 CGI
CGI是一种协议 这种协议能够让我们的前端web服务器进程能够根据对应的程序的不同,调用对应的执行环境来运行那个对应的程序文件,并且能够将对应的程序文件的运行结果重新取回至web进程的这么一种协议,叫做CGI
CGI背后是哪一种程序开发语言?
任何一个语言(C C++ bash perl python)基本都可以开发CGI程序
只不过有些语言(有些程序)更适合于开发web站点(web应用程序) (webapp)
(客户端访问页面的时候,这个页面不是直接返回给客户端的,而是服务器端先调用执行环境,执行以后,将结果格式化成html文档,然后再返回给客户端)
编程语言
静态语言:编译型语言 (强类型,先编译,后运行)
C C++ JAVA
优点 运行速度非常快( 效率高 性能好)
缺点 每一次运行都需要编译(编译可能要很长时间)(一改,要重新编译)
(静态语言的错误查找,错误追踪,调试等都是比较困难的,不如动态语言来得便捷)
(像C C++这种语言更适合开发底层应用,对实时场景,对性能要求非常高的场景,比如开发导弹的控制程序,要快;比如数据库服务器软件,操作系统,驱动程序等,一般使用C C++ 或汇编语言来开发,很困难,但是性能好,比解释性语言性能高至少30%以上) (但是C C++ 本身做的很底层,可以直接操作硬件,所以它性能好,以致于它们的用户接口不是那么的好,提供的库也不是那么的规范,所以众多的功能都得自己手动去造,比如造车,橡胶得自己种,铝材得自己生产,每一个片断都得自己去造)(开发周期长,维护成本大)
动态语言:解释型语言 (不需要编译,弱类型,变量可以在使用时直接拿来用,不用事先声明,在运行的时候我们拿了一个解释器去解释执行即可)
shell perl python
(像 perl python 有众多的别人开发好的模块,那就意味着轮子别人造好了,玻璃也造好了,可以拿来直接拼凑,一会儿一辆车就造好了,所以它的开发周期非常的短)(各种模块都可以共享,甚至互联网上像python 有 pti?库 perl 有cpy?库,众多此前程序员所开发的各种库,造的轮子都在那儿放着,各式各样的轮子)(因此程序员重要的哲理:没必要重新造一个轮子,只要别人有的,我们都可以拿来用 但问题是c c++别人造好的轮子未必适合我用,因为它过于底层,但是动态语言是非常接近用户的)
优点: 便于维护,众多共享模块,开发周期短(开发成本低),维护成本小
缺点: 性能差
哪一种语言更适合开发web站点 ( webapp )呢
动态语言-->(内部有个专门的工具,能够将动态语言转换成静态语言) 静态语言
php-->Hiphop(自己公司有个转换程序Hiphop,把php转换成 C++)-->C++-->(编译) 当作网站程序运行起来了 (用户访问的时候,是一个C++程序,而且是编译好的,在服务器端直接运行了,所以速度快)
并不是所有的动态语言都适合开发web页面 (比如 bash不适合 bash处理web功能的应用场景非常小)
(比如开发一个论坛,论坛里面众多用户要发贴要注册要在线讨论,这些数据放在哪里?bash怎么能够有效的跟这些数据进行交互呢?还有我们怎么能够使用bash能够快速的完成一些特定的动作,一些特殊的处理机制,比如统计一个今天有多少个用户在线,每个用户发了多少贴子,这比较困难)(所以bash这种脚本语言拿来实现系统自动化尚可,但是拿来开发web服务器程序不是不行,但是它的周期是很长的,不是适合于用来开发web服务器程序的,仅仅是为了实现系统自动化的,也有编程达人使用bash开发的很多众多的程序,比如俄罗斯方块,贪吃蛇,回头给我们看看源程序,在web服务器上,有人用bash开发一人博客,论坛 ,,,,不是说不能完成,只是说比较复杂,复杂程度不亚于C )
为什么互联网上有这么多开发语言 因为每一种语言都有它最适用的场景,没有任何一种语言可以到处用,,,,所以只有更适合 ,没有全面适合
哪些语言适合开发web站点呢
perl 早期也不适合,也是一种脚本语言,只不过比bash功能更强大的脚本语言而己,但是后来有人给perl做了的扩展,给perl提供了一种模块,这种模块提供以后,使得perl更能够快速构建web服务器站点了(python也是)
python 本身也不是说设计拿来就能够开发web站点的,但是有了某些模块以后,基于某些框架,它却能够快速开发web服务器了(java也是) python的专门用来开发web服务器站点的框架叫Django
java 本身是一种完整意义上的开发语言,不是有来设计开发web服务器站点,但是后来有人给java提供了一种特殊的类叫jsp类,使得java的生命周期完全可以在web容器中进行了,所以使得使用jsp这种语言也能够快速开发web服务器站点了 (它们都需要依赖于额外的框架)(包括ruby)
java的更快速的web服务器开发框架叫ssh(Struts+Spring+Hibernate)这三种不同的技术 让我们去构建web服务器站点的
ruby 本身也是一种脚本语言,开发服务器站点,它需要的一种框架叫rails ( 所以有一种语言叫 ruby on rails 简称为ror)
php 不需要框架,就能够开发web服务器站点的,因为它本身设计用来就是专门开发web服务器应用程序的
asp 丑陋,又不安全
当一个程序员,所需要学习的知识本身可能比做linux运维要简单的多,但是要成长为程序员,你要会写(成为一个作家,认识汉字挺简单,并不是认识汉字就完了) 程序员的苦和泪并不是在学习知识上,而在码代码上,不停的写代码,不停的去练习各种技巧,各种编程技巧,不停的去了解各种算法,
所以学程序
基本语法
算法,数据结构
编译原理 (运行原理)(底层运行原理)(了解计算机本身的特性来实现高性能程序开发)(有人程序性能好 有人程序性能差)(有人程序能够快速高效的利用cpu的寄存器而实现一种运算,而有人用不了) (学程序需要学的东西其实很少,但是后期需要长时间煎熬,才能成长出来) (而运维工作初期,事业足够大,动手能力足够的强,但最后不可避免的要么去了解系统原理,要么了解编程,只有这样才能知道,程序倒底是怎么运行的,好在我们理解它们怎么去运行的就成,不需要手动写程序,运维是利用别人开发的程序,为了更好的利用,最好要能读懂别人的程序,程序员是要写程序的)
马哥最后要讲python
Openstack (云计算框架)完全基本使用python开发的
游戏程序的控制程序 python 开发的
服务器自动化控制脚本 python 开发的
自动化运维框架 python 开发的
基本上 python 是一种趋势
php
作者 Rasmus Lerdorf 1994年开始开发php,早期建自己的个人站点,把自己个人简历放在网站上,投简历时把各种链接发送给各种雇主,他想看看有哪些人在收到他的简历的时候,查看浏览他的网站,在他的网站里放了一个计数器(记录他的站点被多少人访问过,有哪些用户对他的网站进行访问) 很多雇主对他的这种功能很有兴趣 对于http来讲,94年是蛮荒时期 (http协议是1990 1991年诞生) 早期他是使用perl语言开发的,,,后来他使用C语言将这些perl脚本重写为CGI程序,还为其增加了web表单(web forms)的能力以及与数据库交互的特性,将其重命名为 Personal Home Page /Forms Interpreter 或 "PHP/FI" 1994年 PHP/FI 己经可以用于开发简单的动态web程序了,这即是php 1.0. 1995年他把php发布于 comp.infosystems.www.authoring.cgi Usernet讨论组,从此php开始走进进公众视野. 1997年 2.0发布
1997年,两名以色列程序员 Zeev Suraski 和 Andi Gutmans 把 php分析器( parser )进行了完全的重写,这为php发展为3.0奠定了基础,而且从此将PHP重命名为 PHP: Hypertext Preprocessor. 重写的分析器后来被重命名成叫 Zend Engine (Zend Engine 1.0 在 1999年发布) (Zend 是Zeev Suraski 和 Andi Gutmans 各取两个字母 ) Zend Engine做成一个独立的程序,独立的工具了,它发布的时候 php4.0 诞生 2004年 php2.0发布 php进入php5的时代 php5包含的许多重要特性,比如增强的面向对象编程的支持,支持PDO(PHP Data Objects (php数据对象))扩展机制以及一系列对php性能的改进. (古老的站点,仍然都是运行php4.几的程序,这完全有可能) (主流和众多站点正在使用的是两码事)(像Oracle 数据库软件,目前,最主流是 10 11(11g) ,而企业中用得最多的还是9i) (学习的时候要学最新的,好在它兼容老的)
PHP is Hypertext Preprocessor. 超文本预处理器,能够将我们的超文本事先在本服务器上运行一下以后,再将结果返回给web服务器
bash,如果关键字写错,解释器会告知这里有语法错误,不给执行, 它怎么知道里面有语法错误? 任何一种语言(编译器也好,解释器也好,这种工具它得有几种能力:1)词法分析,把每一个语句,通过空格作为分割符给它们切开,切片,看看哪些是关键字,哪些是变量,哪些是数据,哪些是变量,哪些是控制结构等等,这叫词法分析 2)语法分析(句法分析),判断整个程序当中有没有语法上的错误 3)生成执行流(生成执行路径),也就意味着我们要把它转换成可执行格式 4)要么是编译,要么是解释执行)
parser就是个分析器,它能够做词法分析,句法分析的等等
PHP Zend Engine 是以色列理工学院(Technion) 的学生 Andi Gutmans 和 Zeev Suraski 所研发,
Zend的出现将php代码处理的过程分成了两个阶段:首先是分析php代码并将其转换成Zend opcode的二进制格式(类似于java的字节码),并将其存储于内存中 第二阶段,使用Zend Engine去执行这些转换后的Opcode
Opcode: ( operation code ) php的操作码
php解释型语言, 词法分析,语法分析,生成执行流,解释执行,这个速度是非常慢的
Zend Engine ( Zend 引擎 ) 要想让它快 将 php source code ( php源代码)--> 编译成二进制 (类似于编译过程,不是用户手动编译的,而是php的解释器编译的) --> 执行二进制格式程序
Zend 引擎 的出现将php的执行过程 由本来的只有一个阶段 解释执行 转换成了 1)词法分析,句法分析,编译 (编译后的结果叫opcode) 2)再执行 这样一个过程
意味着将来我们访问任何一个php页面的时候,首先是得编译一下,所以:第一次访问要慢,第二次访问直接执行编译好的二进制格式,所以第二次访问速度快得多 我们网站建好后,自己把所有的页面都访问一遍,就编译好了,用户访问时,速度会快很多
Opcode 接近于二进制格式,但是它不能独立执行 (像java的二进制,也只能在java虚拟机中运行)
可以把Zend理解成opcode或者说php的虚拟机,,,所以 Opcode 只能在 Zend 引擎当中运行
php的Opcode
Opcode 是一种php脚本编译后的中间语言(称为二进制格式,其实是不完全合适的,只是说类似于二进制格式),类似于java的ByteCode(字节码)或者 .NET的MSL
php执行php脚本代码一般经过以下4步骤
1)Scanning (Lexing) --- 扫描(词法分析) 将php代码转换为语言片断 (Tokens)
2)Parsing --- 语法分析 将 Token转换成简单而有意义的表达式(比如把数值赋值给变量等等这一过程)
3)Compilation ---编译 将表达式编译成Opcode
4)Execution ---执行 顺次执行Opcodes,每次一条,从而实现php脚本的功能
php所编译的Opcode,它每一次访问的时候,所编译的结果,存放的位置比较独特,opcode不是放在磁盘上的,而是放在内存中的,所以我们说这是一种动态编译的中间语言 源程序在磁盘上, 如果某一个用户访问的时候,它启动了一个php进程,Zend引擎编译后把opcode放在这个进程的地址空间当中,另外一个进程无法访问这个opcode(无法用到这个加速机制) 意味着每一个进程都要自我独立编译,这就使得php的执行效率仍然是比较慢的 (就算是编译了,在同一进程内部很快,但是其它进程访问同一个文件不会被加速) (能不能有一种机制,让另外的进程也能加速) (我们可以提供一个程序,它能够提供一个缓存,让任何一个进程所编译的opcode放在这个缓存里面(不放在自己的内存地址空间当中),而任何一个进程都可以到缓存中去取编译的结果 (这个缓存能够被众多的php进程所共享的)) 所以只要不涉及到私有数据(私有信息),这些进程之间都可以共享编译好的结果 这个提供缓存的程序就叫做php的加速器,或者叫做php opcode的缓存器
常见的php加速器(缓存器)有: (都是开源的)
1)APC Alternative PHP Cache (改变的可更换了 php 缓存 )
遵循php License的开源框架,php opcode缓存加速器,目前的版本不适用于php 5.4 项目地址 http://pecl.php.net/package/APC
2)eAccelerator
目前 encoder已经不再支持
所以 APC , eAccelerator 己经过期了
3)XCache 将来应该用它
快速而且稳定的php opcode缓存,经过严格测试且被大量用于生产环境 项目地址 http://xcache.lighttpd.net/
4)Zend Optimizer 和 Zend Guard Loader
(Zend Optimizer , Zend 优化器,它不是opcode的加速器,不是一个缓存器)
Zend Optimizer不是一个opcode加速器,而是由Zend Technologies 为php5.2及以前的版本提供的一个免费(网上可以下载使用) 闭源(编译好的)的php扩展,其能够运行在Zend Guard生成的加密的PHP代码或模糊代码 (php是网站程序,而源代码拿来执行的,卖给第一个公司后,他就可以做盗版了,为了避免盗版,把php编译或者php源代码加密,,加密后就是乱码了,不好盗版卖,可以给你一个使用码(授权码),把使用码(授权码)放在你公司里的服务器上能运行,问题是php加密后,就成一堆乱码了,php解释器当然不能解释运行了,Zend Optimizer它就能够识别加密后的php代码, (Zend Guard加密) (Zend Optimizer执行)) 后来 Zend Guard Loader 则是专为php5.3提供的类似于 Zend Optimizer 功能的扩展 项目地址 http://www.zend.com/en/products/guard/runtime-decoders
( 事实上 Zend 本身所提供的很多工具都有免费版(开源版) 商业版 两种版本,)
5) Nusphere PhpExpress
Nusphere是开源的,也有商业版,它支持装载通过 Nusphere PHP Encoder 编码的php程序文件,并能够实现对常规php文件的执行加速,项目地址: http://www.nusphere.com/products/phpexpress.htm
将来公司里工作的时候很有可能维护的要么是一个php服务器,要么是一个jsp服务器
知道原理,将来才能够知道如何优化服务器的执行的 为什么要装Xcache,它到底在多大程度上起到了加速的作用,怎么去调整Xcache的性能,既然有缓存了,它肯定有缓存空间,缓存空间有多大,缓存中的条目应该缓存多长时间,有效期怎么去管理等等,这一切都是跟php本身的运行的基本原理相关的 配置很简单 理解有点困难
php的官方站点 http://www.php.net
stable 稳定版
beta 公测版
下载到源程序后,要解压编译才能够运行的
php是解释性语言,但是php本身是一个需要编译成的运行程序(像bash一样,bash开发的脚本都是脚本,但bash本身是二进制程序)
php源码目录结构
php的源码在结构上非常清晰,其代码根目录中主要包含了一些说明文件及设计方案,并提供了如下子目录:
1)build---顾名思义,这里主要放置一些跟源码编译相关的文件,比如开始构建之前的buildconf脚本及一些检查环境的脚本等
2)ext---官方的扩展目录,包括了绝大多数PHP的函数的定义和实现,如array系列,pdo系列(php的数据对象),sp1系列等函数的实现.个人开发的扩展在测试时也可以放到这个目录,以方便测试等 (支持众多扩展,比如php能够使用一些加密库,将用户传送的数据,处理用户数据的时候进行加密等等)
3)main---这里存放的就是PHP最为核心的文件了,是实现PHP的基础设施,这里和Zend引擎不一样,Zend引擎主要实现语言最核心的语言运行环境
4)Zend---Zend引擎的实现目录,比如脚本的词法语法分析,opcode的执行以及扩展机制的实现等等
5)pear---PHP扩展与应用仓库,包含PEAR的核心文件
6)sapi---包含了各种服务器抽象层的代码,例如apache的mod_php,cgi,fastcgi以及fpm等等接口
7)TSRM--- PHP的线程安全是构建在TSRM库之上的，PHP实现中常见的*G宏通常是对TSRM的封装，TSRM(Thread Safe Resource Manager)线程安全资源管理器.(为php的线程安全提供了一个基本库)
8)tests---PHP的测试脚本集合，包含PHP各项功能的测试文件.
9)win32---这个目录主要包括Windows平台相关的一些实现(专用的实现)，比如socket的实现在Windows下和*Nix平台就不太一样，同时也包括了Windows下编译PHP相关的脚本
只要大致知道就可以了,将来万一我们需要找哪些源程序做一些简单修改,打一些补丁的时候,知道到哪里去找就OK了.
php既然是一个能够让我们开发web应用程序的webapp的这么一个重要的开发引擎,或者说开发语言,这种语言也只有在php的解释器中需要Zend引擎编译以后才能执行,它的编译结果怎么能够跟apache服务器结合起来
CGI
Common Gateway Interface
apache仅能提供静态(html css image mp3等)功能
apache自身不能执行php程序,要想执行php程序,得用php解释器
php的请求进行,apache进程通过cgi协议来调用php解释器执行php脚本
用户请求的时候一定是请求的web服务器对象(这个对象要么是纯文本文件,html文档 html css image mp3等)
(要么是php文档,这个php文档是个程序,这个程序需要执行,执行以后的结果是什么 是数据流,
HTML的格式
<html>
<head>
<title></title>
</head>
<body>
</body>
</html>
test.sh
#!/bin/bah
date 它时纯文本
如何在文本里面把标签同时返回给apache服务器
[root@localhost ~]# vim /etc/httpd/conf/httpd.conf
...............
LoadModule cgi_module modules/mod_cgi.so #说明apache支持cgi
...............
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" #就是用来定义在哪个目录当中可以执行CGI脚本的 (ALias 访问的路径,url 就是 /cgi-bin/ ) (目录是在 /var/www/cgi-bin/ )
...............
[root@localhost ~]# cd /var/www/cgi-bin/
[root@localhost cgi-bin]#
[root@localhost cgi-bin]# vim test.sh
#!/bin/bash
#
cat << EOF
Content-Type: text/html
<pre>
$(/bin/date)
</pre>
EOF
[root@localhost cgi-bin]# vim hello.sh
#!/bin/bash
#
/bin/date
[root@localhost cgi-bin]# chmod +x hello.sh
[root@localhost cgi-bin]# ./hello.sh
2019年 03月 05日 星期二 12:24:15 CST
[root@localhost cgi-bin]#
通过浏览器查看 http://192.168.1.45/cgi-bin/hello.sh
报错的话 看日志
[root@localhost cgi-bin]# tail -3 /var/log/httpd/error_log
[Mon Mar 04 10:13:31 2019] [error] [client 192.168.1.100] File does not exist: /web/html/favicon.ico, referer: http://192.168.1.45/
[Mon Mar 04 21:02:40 2019] [error] [client 192.168.1.100] File does not exist: /web/html/favicon.ico, referer: http://192.168.1.45/
[Tue Mar 05 12:25:34 2019] [error] [client 192.168.1.102] Premature end of script headers: hello.sh
有问题 执行不了 理解不了这个脚本
[root@localhost cgi-bin]#
[root@localhost cgi-bin]# vim test.sh
#!/bin/bash
#
cat << EOF
Content-Type: text/html
# 这里非要有空行,没空行不行 不知啥原因
<pre>
<h1>$(/bin/date)</h1>
</pre>
EOF
我们可以把 h1 标签放在一个独立的文件中 当前这个脚本只处理数据,最后通过一种方式把它们拼合起来
这就是MVC的机制,嵌入式web开发语言
MVC 模型视图控制,将业务逻辑和数据显示分离的一种编程技术
php可以完全实现开发MVC结构的应用程序的
index.php
<html>
<head></head>
<?php //只把这个框架内的指令交给php执行 (把php的代码嵌入到html里面去) ,html的标签不需要php自身去处理
?>
</html>
apache服务器 倒底怎么跟php交互
Apache( 通过CGI )负责php进程的启动 运行 销毁
同时 200个请求php进来 ,至少要400个进程) (因为每一个php启动一个进程)
( 假如一个php进程占用的空间是20M, 200个php进程就是4G,
一个apache进程( web的prefork进程 )需要2M, 200个prefork进程需要 400M 那么就需要 4.4G )
假设这200个用户的请求是随时在线的,
http是无状态的协议,每一个请求都是独立建立的,假如我们没有使用长连接,
我们随时在线访问的用户进程都有200个,那就意味着.........
创建一个进程 销毁一个进程速度很快 但是占用资源多
如果频繁的创建进程,删除进程,系统开销非常大,系统性能会显著降低
所以很显然 CGI 机制对于php来讲,并不是一个优良的机制(尤其是大量用户并发访问的时候)
(至少创建,删除CGI进程,这个生命周期的管理已经相当消耗时间了)
(把 web 进程 和 CGI 进程合二为一,至少一个进程的创建和删除要简单的多)
apache支持模块化的设计
DSO机制: dynamic shared object 动态共享对象
apache有众多模块,我们使用loadModule加载进来,不加载就不支持这个功能,要想使用这个功能加载进来就可以了,apache在启动的时候装载的模块越多,意味着它占据的内存空间就越大,所以我们用得着才装载,用不着就不装载了,,,,但是事实上完全可以把php做成apache的一个动态共享模块(把php编译成apache的模块 php_mod ,用到它的时候,直接把这个模块装载进来,去解释php的内容就OK了)(这就意味着在我们的apache进程的内部(apache有动态能力),在apache进程的内部,它就可以自己装载进来php模块,来完成对于php应用的加载,并且能够将加载的生成的结果(也不用在内部传递了,不用在进程间通信,因为它俩是同一进程,直接就给了前端的其它的处理程序(或者说返回到客户端吧)就OK了))
所以这样子,就算有200个用户同时访问,我们也只需要启动200个进程就OK了,当然这儿有一个坏处,这就是我们的apache进程既得处理静态内容,又得处理动态内容,这就比较麻烦,虽然说它已经大大的简化了我们的CGI模式所具有的缺陷,但是它依然有着性能上的缺陷
(比如我们的服务器最多允许有256个请求同时进来,假设在我们的峰值的并发时刻,已经有400个用户同时进来了,服务器不能应付这种情况了)
基于DNS 两条A记录做负载均衡,用户的请求有的到第一台服务器上,有的到第二台服务器上,这样子就会简单很多,
每一个服务器都能应付 200 多个用户了, 这样子 ,400个用户应付起来就绰绰有余
事实上每一个进程,既得处理动态的,又得处理静态的,不管有多少个用户在,它本身的由于进程过程很复杂,所以使得我们的整个服务器的改进
变得会非常困难
第三种让apache和php相结合的模式,,就是让apache的静态内容处理和动态内容处理相分离 ( apache临时创建CGI进程,速度太慢,要想让它加快怎么办?提前创建好 )
跟CGI一样,使用各自不同的进程来完成,但是是这样子来分离的
我们安装php的服务器,它不是一个解释器,它是一个服务器,自身它可以像apache的prefork一样,事先生成很多空闲进程,不需要apache来管理,什么时候销毁这个进程,什么时候生成这个进程,而由这个php服务器自我管理 前端的apache某一个进程,需要用到php功能了,它只需要向php服务器发起请求就行了,这一个php服务器找一个空闲进程分配给它(apache的进程)进行直接响应. 当apache的用户请求执行结束了, 那么php进程还被php服务器收回来. 需要销毁php进程的时候,是由php服务器管理来进行销毁 , 有点类似于prefork?
apache和后端服务器端的通信不再是CGI了,可以完全理解成是另外一种独立的服务器,客户端之间的协议,(这里apache服务器是客户端,,后面的php服务端是一个服务器,.这种机制,我们称之为 FastCGI )
(类似于我们刚才解释器的那种机制,在php5.4中已经自带了这种 FastCGI 功能,叫fpm ( fast php module 快速php模块) )
apache+php
1) CGI
2) Module # 这一种是最简单的 模块模式
3) FastCGI # 性能比较好,但是配置起来是麻烦一些,要独立的去配置php服务器的 要编译php里面的那个FPM功能才行,如果 apache 仅提供静态功能的话,比apache好的多的另外一台服务器叫Nginx
Nginx
比apache性能要好得多,处理静态内容的时候,如果不需要提供额外的其它功能的情况下
Nginx+fpm
通常使用fastcgi,(是使用Nginx+fpm,如果要分开的话),(如果不分开的话,就使用apache的模块的机制),,当然有些应用程序可能依赖于apache的某些模块所提供的能力,这个时候,可能还必须使用apache,,其实apache基于fpm的工作模式也完全是可以的
php是什么,php倒底是如何与apache结合工作的
如何配置我们的web服务器能够使用php的功能
php是一个很大的软件,我们的redhat把它做成了模块,而且有两个版本,跟bind一样,
有两个版本 php5.1.6 和 5.3.3(好像是不支持fpm的,好像是5.3.4开始,才支持fpm,当然5.4能直接支持fpm了,所以5.3.3要使用fpm,你得打补丁才行,所以这里5.3.3默认没有fpm的功能的 )
[root@localhost ~]# yum list all | grep php
[root@localhost ~]# yum list all | grep php
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
file:///media/cdrom/Server/repodata/repomd.xml: [Errno 5] OSError: [Errno 2] 没有那个文件或目录: '/media/cdrom/Server/repodata/repomd.xml'
Trying other mirror.
php.i386 5.1.6-40.el5_9 installed
php-cli.i386 5.1.6-40.el5_9 installed
php-common.i386 5.1.6-40.el5_9 installed
php-ldap.i386 5.1.6-40.el5_9 installed
php-bcmath.i386 5.1.6-40.el5_9 Cdrom_Base
php-dba.i386 5.1.6-40.el5_9 Cdrom_Base
php-devel.i386 5.1.6-40.el5_9 Cdrom_Base
php-gd.i386 5.1.6-40.el5_9 Cdrom_Base
php-imap.i386 5.1.6-40.el5_9 Cdrom_Base
php-mbstring.i386 5.1.6-40.el5_9 Cdrom_Base
php-mysql.i386 5.1.6-40.el5_9 Cdrom_Base #
php-ncurses.i386 5.1.6-40.el5_9 Cdrom_Base
php-odbc.i386 5.1.6-40.el5_9 Cdrom_Base
php-pdo.i386 5.1.6-40.el5_9 Cdrom_Base
php-pear.noarch 1:1.4.9-8.el5 Cdrom_Base
php-pgsql.i386 5.1.6-40.el5_9 Cdrom_Base
php-snmp.i386 5.1.6-40.el5_9 Cdrom_Base
php-soap.i386 5.1.6-40.el5_9 Cdrom_Base
php-xml.i386 5.1.6-40.el5_9 Cdrom_Base
php-xmlrpc.i386 5.1.6-40.el5_9 Cdrom_Base
php53.i386 5.3.3-21.el5 Cdrom_Base #这些模块 php 自身叫 php53 除此之外 php有很多自己独立的模块
php53-bcmath.i386 5.3.3-21.el5 Cdrom_Base
php53-cli.i386 5.3.3-21.el5 Cdrom_Base
php53-common.i386 5.3.3-21.el5 Cdrom_Base
php53-dba.i386 5.3.3-21.el5 Cdrom_Base
php53-devel.i386 5.3.3-21.el5 Cdrom_Base
php53-gd.i386 5.3.3-21.el5 Cdrom_Base
php53-imap.i386 5.3.3-21.el5 Cdrom_Base
php53-intl.i386 5.3.3-21.el5 Cdrom_Base
php53-ldap.i386 5.3.3-21.el5 Cdrom_Base #
php53-mbstring.i386 5.3.3-21.el5 Cdrom_Base # mbstring (multi bytes string) 多字节字符串,比如汉字,一个汉字可能为2个字节,也可能三个字节,这个模块是为了国际化支持的,所以这种模块一般都要装
php53-mysql.i386 5.3.3-21.el5 Cdrom_Base
php53-odbc.i386 5.3.3-21.el5 Cdrom_Base
php53-odbc64.i386 5.3.3-2.el5 Cdrom_Base
php53-pdo.i386 5.3.3-21.el5 Cdrom_Base
php53-pgsql.i386 5.3.3-21.el5 Cdrom_Base
php53-process.i386 5.3.3-21.el5 Cdrom_Base
php53-pspell.i386 5.3.3-21.el5 Cdrom_Base
php53-snmp.i386 5.3.3-21.el5 Cdrom_Base
php53-soap.i386 5.3.3-21.el5 Cdrom_Base
php53-xml.i386 5.3.3-21.el5 Cdrom_Base
php53-xmlrpc.i386 5.3.3-21.el5 Cdrom_Base
[root@localhost ~]#
现在的开发程序的新版本,都得依赖于53所提供的新特性,51不具备了, 所以我们安装 php53 吧
[root@localhost ~]# yum install php53 php53-mbstring
(自动解决依赖关系 php53-cli(命令行工作) 和 php53-common (通用组件) 都会装上去)
[root@localhost ~]# rpm -ql php53 (看看php53倒底给我们安装生成了哪些文件)
/etc/httpd/conf.d/php.conf # 这个配置文件 作为 web服务器的配置文件来使用的吧
/usr/lib/httpd/modules/libphp5.so # 把它编译成了httpd的一个模块叫做 libphp5.so (这是一个动态共享对象)
/var/lib/php/session # 这是php的会话数据的保存位置
/var/www/icons/php.gif
[root@localhost ~]#
[root@localhost ~]# cd /etc/httpd/conf.d/
[root@localhost conf.d]# pwd
/etc/httpd/conf.d
[root@localhost conf.d]# ls
manual.conf php.conf python.conf squid.conf webalizer.conf
perl.conf proxy_ajp.conf README ssl.conf welcome.conf.bak
[root@localhost conf.d]# vim php.conf
#
# PHP is an HTML-embedded scripting language which attempts to make it
# easy for developers to write dynamically generated webpages.
# 如果使用的是 prefork 或者 worker 模型 ,它使用的加载的模块是不是不一样(所依赖的php的模块,工作机制不一样的)
# 在 worker 模式下,php必须以 zts的方式工作
# 在 prefork 模式下,就是传统意义上的php的模块 libphp5.so
# 程序会判断倒底使用的是哪一种核心模块(MPM模块)((MPM 多道处理模块 multi path module,Multi-Processing Module) -),并且相应的给你加载合适的php5的模块
# libphp5-zts.so这个模块文件好像没有看到
<IfModule prefork.c>
LoadModule php5_module modules/libphp5.so
</IfModule>
<IfModule worker.c>
LoadModule php5_module modules/libphp5-zts.so
</IfModule>
#
# Cause the PHP interpreter to handle files with a .php extension.
#
AddHandler php5-script .php # AddHandler 就是添加一个处理器的,如果说你是以.php结尾的文件的话,那么我们就使用 php5-script 工具 来处理 ( php5-script 是apache 内置的一种处理勾子,它能够实现在内部完成怎么去识别这个文件的)
AddType text/html .php #增加了一种类别,这种类别 MIME TYPE 多媒体类型 是 text/html ,它仍然把 .php 识别成纯文本格式(当然纯文本格式要先执行的)
#
# Add index.php to the list of files that will be served as directory
# indexes.
#
DirectoryIndex index.php # 主页 默认的主页面
#
# Uncomment the following line to allow PHP to pretty-print .phps
# files as PHP source code:
#
#AddType application/x-httpd-php-source .phps
[root@localhost conf.d]# service httpd restart
停止 httpd： [确定]
启动 httpd： [确定]
[root@localhost conf.d]#
把 index.html 重命名为 index.php
php 配置文件目录 /etc
php 配置文件 /etc/php.ini (既然叫 ini 格式了,那么它的格式与 windows的格式是一样的了)
ini 文件的格式
[abc] #这里中括号 表示 下面的指令只对这一段生效 ( segment分段式的配置 ) 每一段只对这对应的段有效 (mysql的配置文件也支持这种格式) (为什么要这样定义呢?因为我们的php模块很多,每一个模块所需要用到的指令可能都不一样,所以它有全局的(对每一个模块都生效的)和局部的,对某个特定模块才生效的)
fadafds
[fdad]
fdaaa
[root@localhost conf.d]# vim /etc/php.ini
[PHP] # 对php生效的 注释 分号; 才是注释符
;;;;;;;;;;;;;;;;;;;
; About php.ini ;
;;;;;;;;;;;;;;;;;;;
; PHP's initialization file, generally called php.ini, is responsible for
; configuring many of the aspects of PHP's behavior.
; PHP attempts to find and load this configuration from a number of locations.
; The following is a summary of its search order:
; 1. SAPI module specific location.
; 2. The PHPRC environment variable. (As of PHP 5.2.0)
; 3. A number of predefined registry keys on Windows (As of PHP 5.2.0)
; 4. Current working directory (except CLI)
; 5. The web server's directory (for SAPI modules), or directory of PHP
; (otherwise in Windows)
; 6. The directory from the --with-config-file-path compile time option, or the
; Windows directory (C:\windows or C:\winnt)
; See the PHP docs for more specific information.
; http://www.php.net/manual/en/configuration.file.php
; The syntax of the file is extremely simple. Whitespace and Lines
; beginning with a semicolon are silently ignored (as you probably guessed).
; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future.
; Directives following the section heading [PATH=/www/mysite] only
; apply to PHP files in the /www/mysite directory. Directives
; following the section heading [HOST=www.example.com] only apply to
; PHP files served from www.example.com. Directives set in these
; special sections cannot be overridden by user-defined INI files or
; at runtime. Currently, [PATH=] and [HOST=] sections only work under
; CGI/FastCGI.
; http://www.php.net/manual/en/ini.sections.php
max_input_time 最大的输入等待时间
每一个指令都有特殊意义,一时半会不能全说清楚,大多数东西都不需要我们自己去关心和调整的,只是可能偶尔某一个指令需要我们去调整,红帽上很多指令对我们而言都是可以直接拿来使用的 所以我们不需要去修改 php.ini,所以我们的php就能够正常工作了
php 页面文件通常只是用来保存指令的,而不包含数据的, 数据通常我们需要另外一种机制进行专门保存.哪一种机制,以及如何到底与php进行交互,等一会儿再说