今天准备将一个镇羡php
demo放在IIS下运行，网站在IIS下的配置是这样的：
应用程序池是集成模式下的.net
framework
2.0(2.0或4.0没什么关系，因为php以fastCGI的方式在跑),
应用程序池标识配置为IIS内置的NETWORKSERVICE,
使用的认证方式为匿名身份验证。
打开本地的网站，访问php页面,
出现了500错误。
好吧，是权限问题，最简单的解决办法是把C:UsersAdministratorPhpstormProjectsphpDemo的权限设成Everyone,
并允许完全控制：
重新访问php页面，成功了：
上面的方法是够简单，但也太不安全了，平时本地搭个demo这样做没问题，真正上线的时候，这样做迟早出问题的。
于是重新设置，把该目录下的只读权限赋给NETWRORKSERVICE帐号再试一下
不过问题还是没有解决，访问的时候，出现了401错误
错误信息中包括显示登录用户为匿名，检查了网站下的身份验御做拍证(再点击
匿名身份验证->编辑),原来网站默认情况下，在登录方法为匿名时，使用的默认登录用户为IUSR(就是我们看胡判到的匿名登录用户了)
那么解决办法就是：
1.
将IUSR设置为C:UsersAdministratorPhpstormProjectsphpDemo的读权限，类似之前对NETWORKSERVICE的设置。
2.
或选择使用应用程序池标识即可。
经试验，方法1与2都成功。
Note:NETWORKSERVICE在IIS7中隶属于iis_iusers用户组，之前对NETWORKSERVICE的设置也可以改为对iis_iusers的设置，同样也可以解决问题，只是权限被进一步放宽了而已。
以上所述就是本文的全部内容了，希望大家能够喜欢。
前一段时间又重读了《HTTP权威指南》一书，觉得有一些理论知识还是蛮重要的，需要进行一番整理，让自己之后对整条web链路有个更清晰的认识。
当用户打开浏览器并输入一串url地址时，到最终页面内容呈现在用户眼前时，这之间的步骤可大致整理如下：
1）用户输入 http://www.lxlxw.me 。
2）浏览器解析出主机名。
3）浏览器查询这个主机名的ip地址如192.168.0.1（即dns解析）并获得端口号如80
4）浏览器发起到192.168.0.1:80的连接。（tcp连接握手）
5）浏览器向服务器发送一条http get或post报文。（有可能会先发送给proxy或gateway，再由它们转发给服务器，如nginx做反向代理以实现负载均衡）
6）浏览器从服务器读取http响应报文。
7）浏览器关闭连接。
以上便是一条http请求的大致过程，理论上所有的http通信都是由tcp/ip承载的，即http使用tcp连接，其保证了在资源传输过程中是可靠的／不会丢失或损坏的。
注：http和https比较，https就是在http层和tcp层之间接入了一个密码加密层，称之为TLS或SSL,常用于一些支付等安全性要求较高的网站。
注：关于http的性能优化，tcp连接的时延和瓶颈等，之后可能需要另整理一份。
web服务器可以用来表示web服务器的软件，也可以表示提供web页面的特定设备或机器。这边主要是指通用软件web服务器，如apache或nginx。
《http权威指南》中有一份用perl脚本写的web服务器的源码，实现了最简单的收发客户端报文的功能。
当然，实际的web服务器比这要复杂的多，核心步骤整理如下：
1）接受一个客户端（浏览器）连接，或者拒绝该客户端的连接并将其关闭。
2）接受请求，从网络中读取一条http请求报文并解析。
3）处理请求，对请求报文进行解析。
4）访问资源，访问报文中指定的资源，有可能是缓存好的html静态页面或图片资源，也有可能是动态资源，如php文件，此时web server会通过fastcgi请求php应用程序以此产生动态资源，下面会详细棚嫌讲。
5）创建http响应报文，并回送给客户端。
6）纪录链让手事务处理过程，即记log。
讲Fastcgi之前需要先讲CGI，CGI是为了保证web server传递过来的数据是标准格式的，它是一个协议，方便CGI程序的编写者。Fastcgi是CGI的更高级的一种方式，是用来提高CGI程序性能的。
web server（如nginx）只是内容的分发者。比如，如果请求/index.html，那么web server会去文件系统中找到这个文件，发送给浏览器，这里分发的是静态资源。
如果现在请求的是/index.php，根据配置文件，nginx知道这个不是静态文件，需要去找PHP解析器来处理，那么他会把这个请求简单处理后交给PHP解析器。此时CGI便是规定了要传什么数据／以什么格式传输给php解析器的协议。
当web server收到/index.php这个请求后，会启动对应的CGI程序，这里就是PHP的解析器。接下来PHP解析器会解析php.ini文件，初始化执行环境，然后处理请求，再以CGI规定的格式返回处理后的结果，退出进程。web server再把结果返回给浏览器。
那么CGI相较于Fastcgi而言其性能瓶颈在哪呢？CGI针对每个http请求都是fork一个新进程来进行处理，处理过程包括解析php.ini文件，初始化执行环境等，然后这个进程会把处理完的数据返回给web服务器，最后web服务器把内容发送给用户，刚才fork的进程也随之退出。 如果下次用户还请求动态资源，那么web服务器又再次fork一个新进程，周而复始的进行。
而Fastcgi则会先fork一滑困个master，解析配置文件，初始化执行环境，然后再fork多个worker。当请求过来时，master会传递给一个worker，然后立即可以接受下一个请求。这样就避免了重复的劳动，效率自然是高。而且当worker不够用时，master可以根据配置预先启动几个worker等着；当然空闲worker太多时，也会停掉一些，这样就提高了性能，也节约了资源。这就是Fastcgi的对进程的管理。大多数Fastcgi实现都会维护一个进程池。注：swoole作为httpserver，实际上也是类似这样的工作方式。
那PHP-FPM又是什么呢？它是一个实现了Fastcgi协议的程序,用来管理Fastcgi起的进程的,即能够调度php-cgi进程的程序。现已在PHP内核中就集成了PHP-FPM，使用--enalbe-fpm这个编译参数即可。另外，修改了php.ini配置文件后，没办法平滑重启，需要重启php-fpm才可。此时新fork的worker会用新的配置，已经存在的worker继续处理完手上的活。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）